Les tâches oubliées ne sont pas un problème humain
Pourquoi les tâches oubliées en gestion de projet ne sont pas une question de discipline – et quand votre équipe a besoin d'un système pour les détecter.
By Ellis Keane · 2026-03-17
Si votre équipe est suffisamment petite pour déjeuner ensemble (ou pourrait le faire hypothétiquement, si vous vous trouviez un jour dans la même ville au même moment), vous n'avez probablement pas besoin de lire ceci. Fermez cet onglet. Allez construire quelque chose. Le problème des tâches oubliées à votre échelle n'est qu'un rappel Slack un mercredi après-midi d'être résolu – et je le pense sincèrement.
Toujours là ? Bien. Parlons donc des tâches oubliées dans la gestion de projet – et plus précisément de pourquoi les conseils habituels ne fonctionnent plus dès que l'équipe atteint une certaine taille.
Avant d'aller plus loin
Nous développons un outil qui s'attaque à ce problème (Sugarbug – je mentirais en prétendant le contraire), mais la réponse honnête est que la plupart des équipes qui lisent ceci n'ont pas encore besoin de ce que nous construisons. Peut-être jamais. Ce dont elles ont besoin, c'est de comprendre pourquoi les tâches sont oubliées en premier lieu, car la solution dépend de la cause – et la cause n'est presque jamais ce que les gens pensent.
Pourquoi les tâches sont oubliées
Demandez à la plupart des managers pourquoi des tâches sont oubliées et vous entendrez une liste familière : quelqu'un a oublié, quelqu'un n'a pas fait attention, quelqu'un n'a pas suivi le processus. La solution serait donc de meilleurs processus, plus de rappels, peut-être un bot de standup qui relance les gens chaque matin.
Et oui, parfois c'est véritablement le problème. Si votre développeur a oublié de mettre à jour le ticket Linear et que votre PM n'a pas vérifié avant la revue de sprint, c'est un manquement humain et une lacune de processus. Ajoutez une liste de contrôle. Passez à autre chose.
Mais ce n'est pas le type de tâche oubliée qui empêche les engineering managers de dormir. Celle qui fait vraiment mal, c'est celle où tout le monde a fait son travail, a suivi son processus, a mis à jour ses outils – et quelque chose est quand même passé à travers les mailles. Parce que la faille n'est pas entre une personne et sa tâche. Elle est entre un outil et un autre.
Voici ce que je veux dire. Un développeur envoie une PR qui ferme un issue GitHub. L'issue était lié à un ticket Linear, et le ticket passe à « Terminé ». Bien. Sauf que la demande initiale venait d'une conversation Slack il y a trois semaines, dans laquelle le PM avait également mentionné une exigence complémentaire que personne n'a jamais enregistrée comme tâche distincte. Cette exigence vit dans un fil Slack de février. Elle n'est pas dans Linear. Elle n'est pas dans GitHub. Elle n'est dans aucun sprint. C'est techniquement une tâche oubliée – mais aucune personne en particulier ne l'a laissé tomber. Elle est passée à travers la faille structurelle entre Slack et le gestionnaire de tâches.
Ce schéma apparaît partout dès qu'on commence à y prêter attention. Un designer laisse un commentaire dans Figma signalant qu'un cas limite contredit le spec dans Notion, mais le développeur qui travaille sur la fonctionnalité ne consulte jamais Figma et le PM ne voit jamais le commentaire parce qu'il vit dans Linear. Un responsable customer success promet une fonctionnalité lors d'un appel, la résume dans un e-mail, et elle n'atteint jamais le backlog technique parce que personne ne fait le pont sur cette lacune précise. Un post-mortem d'incident identifie trois points de suivi, le document est partagé dans Slack, et deux des trois ne deviennent jamais des tâches suivies parce que la personne qui le fait habituellement était en arrêt maladie cette semaine-là.
Les tâches oubliées les plus dommageables en gestion de projet surviennent dans les interstices entre les outils, pas dans les interstices entre les personnes et leurs listes de tâches.
La solution par les processus (et où elle cesse de fonctionner)
Je crois sincèrement que de bons processus résolvent la plupart de ces problèmes pour la plupart des équipes. Voici ce qui fonctionne, et je le partage sans arrière-pensée parce que (pour être honnête) nous sommes en pré-lancement et la meilleure chose que nous puissions faire maintenant est de créer de la confiance en étant utiles.
La revue hebdomadaire. Une personne – idéalement le PM ou l'engineering lead – passe 30 minutes chaque vendredi à passer en revue les fils Slack, les notes de réunions et les e-mails pour attraper tout ce qui a été discuté mais jamais consigné. Fastidieux ? Absolument. Efficace ? Étonnamment oui, jusqu'à un certain point.
Le journal de décisions. Chaque décision issue d'un fil Slack ou d'une réunion est collée dans un document partagé (Notion, Google Docs, peu importe) avec la date, qui a décidé et quel est le suivi. Cela semble simple, et ça l'est – jusqu'à ce que vous preniez quinze décisions par semaine dans quatre canaux et que personne ne se souvienne lesquelles ont été consignées.
La discipline de liaison. Chaque PR référence son ticket Linear. Chaque ticket Linear renvoie au fil Slack où l'exigence a été discutée. Chaque spec Notion renvoie à son epic Linear. Si quelqu'un rompt la chaîne – et quelqu'un le fera, c'est inévitable –, la visibilité se rompt avec elle.
Ce sont toutes de bonnes pratiques. Nous en utilisons nous-mêmes des versions. Mais elles ont un mode d'échec commun : elles dépendent du fait que les humains effectuent de façon constante une petite tâche ennuyeuse, à chaque fois, pour toujours. Et les données à ce sujet ne sont pas encourageantes – inutile de citer des recherches. Si vous avez géré une équipe de plus de cinq personnes, vous le savez déjà.
Quand la solution par les processus cesse de passer à l'échelle
Il existe un seuil, et j'aimerais pouvoir vous donner un chiffre précis, mais nous ne l'avons pas encore déterminé (honnêtement, il varie probablement selon l'équipe et la discipline de ses membres). Notre heuristique de travail – et je veux être clair : c'est une heuristique, pas des données de référence – est que les choses commencent à se dégrader quelque part autour de quatre ou cinq outils, une dizaine de personnes et plusieurs flux de travail parallèles.
Pas parce que quelqu'un est devenu paresseux. Pas parce que le processus était mauvais. Mais parce que le volume de connexions entre les outils dépasse la capacité de toute personne à les suivre manuellement. La revue hebdomadaire prend 90 minutes au lieu de 30, et le PM commence à survoler. Le journal de décisions se périme parce que la personne qui le tenait est partie en vacances et personne n'a pris le relais. La discipline de liaison tient pour Linear et GitHub mais s'effondre pour Slack et Figma parce que ces outils n'ont pas le même type de références structurées.
C'est – et je veux être clair là-dessus – un problème d'échelle, pas un problème de discipline. J'ai vu d'excellents PMs et engineering leads lutter avec cela – des gens qui gèrent des équipes rigoureuses et qui se soucient profondément de ne rien laisser passer. À une certaine échelle, le problème dépasse la solution. Ce n'est pas un échec de la personne – c'est un échec de l'écosystème d'outils à se connecter entre lui-même.
"La récompense pour être sophistiqué dans l'utilisation de ses outils est une surface de défaillance plus complexe pour les tâches oubliées. Je trouve ça profondément ironique." – Ellis Keane
Et voici la partie que je trouve véritablement injuste : plus votre équipe est bonne dans l'utilisation de ses outils, plus vous avez de surface pour les failles inter-outils. Une équipe qui utilise Linear religieusement, maintient les specs Notion à jour, fait des revues actives dans Figma et communique dans des canaux Slack bien organisés a plus de points de transfert qu'une équipe qui n'utilise que l'e-mail et un tableur.
Pourquoi vos outils ne peuvent pas aider
Voici ce que je trouve vraiment intéressant dans tout ce problème, et qui n'est selon moi pas assez discuté : vos outils font exactement ce pour quoi ils ont été conçus. Linear est excellent pour suivre les issues Linear. GitHub est excellent pour suivre les changements de code. Notion est excellent pour organiser des documents. Slack est excellent pour... être Slack (pour le meilleur ou pour le pire).
Mais aucun d'eux n'a été conçu pour suivre les connexions entre eux. Et le travail – le vrai travail – ne se déroule pas dans un seul outil, il circule à travers tous. Les points de transfert entre outils sont là où les choses disparaissent, et aucune amélioration d'un outil individuel ne résout cela. Vous pouvez rendre Linear meilleur pour suivre les issues, mais ça n'aide pas quand l'issue aurait dû être créé en premier lieu sur la base d'une conversation Slack qui s'est produite dans un canal que l'engineering lead ne surveille pas.
Ce qui résoudrait vraiment le problème
J'ai été délibérément vague sur les aspects produit dans cet article, et c'est intentionnel – je voulais que ce soit utile que vous utilisiez ou non ce que nous construisons. Mais puisque vous avez lu jusqu'ici (et je l'apprécie), permettez-moi d'être honnête sur ce que je pense être la vraie solution.
Ce n'est pas un meilleur gestionnaire de tâches. Ce n'est pas un meilleur processus. Ce n'est pas un bot de standup, une revue hebdomadaire ou un tableur partagé. Tout cela aide, et à petite échelle c'est suffisant – mais tous traitent le symptôme.
La vraie solution est quelque chose qui observe les connexions entre vos outils et signale quand quelque chose ne concorde pas. Quand une décision Slack ne devient pas un ticket. Quand une PR GitHub ferme un issue mais qu'il y a des commentaires non résolus. Quand un spec Notion fait référence à une exigence qui a été déprioritisée lors d'une conversation que l'auteur du spec n'a jamais vue.
Pour concrétiser : imaginons que votre système surveille à la fois Slack et Linear. Il voit une conversation dans #engineering où quelqu'un dit « on devrait aussi gérer le cas où l'utilisateur n'a pas vérifié son e-mail » – c'est une nouvelle exigence. Si cette exigence n'apparaît pas comme ticket Linear dans, disons, 48 heures, le système la signale. Pas avec une notification qui crie (personne n'en a besoin de plus), mais comme entrée dans une vue « décisions pas encore suivies » que le PM peut consulter lors de sa revue du vendredi. Même principe pour les PRs GitHub qui ferment des tickets Linear mais ont encore des commentaires de revue ouverts, ou pour les specs Notion qui font référence à des fonctionnalités déprioritisées depuis la rédaction du spec.
Que vous construisiez cela en interne (certaines équipes le font, avec des webhooks, une file de messages et un peu de code de colle), que vous utilisiez quelque chose d'existant, ou que vous acceptiez simplement les tâches oubliées comme un coût opérationnel – c'est votre décision. Nous construisons une version de cette réponse, mais ce n'est pas la seule, et pour beaucoup d'équipes ce n'est pas encore la bonne.
Si vous voulez savoir quand ce pourrait être la bonne pour vous, voici mon heuristique honnête : si votre revue hebdomadaire prend plus de 30 minutes et que des choses passent encore à travers les mailles, vous avez dépassé l'approche manuelle.
---
Quand la revue hebdomadaire prend plus de 30 minutes et que des choses passent encore à travers les mailles, vous avez dépassé l'approche manuelle. Sugarbug surveille les interstices automatiquement.
Q: Comment Sugarbug évite-t-il les tâches oubliées dans la gestion de projet ? A: Sugarbug construit un graphe de connaissances à travers vos outils – Linear, GitHub, Slack, Figma, Notion – et suit les tâches, conversations et décisions au fil de leurs déplacements. Quand quelque chose se bloque ou perd le lien avec la demande initiale, Sugarbug le fait remonter avant qu'il ne tombe dans les interstices. Ce n'est pas un système de rappels – il comprend les relations entre les éléments dans tous les outils et signale quand ces relations se brisent.
Q: Sugarbug peut-il détecter les tâches discutées dans Slack mais jamais enregistrées ? A: Oui. Sugarbug surveille les conversations Slack et identifie quand une décision ou un point d'action est discuté mais n'apparaît jamais comme tâche dans Linear ou ticket dans GitHub. Il signale l'écart afin que quelqu'un puisse agir. Nous affinons encore la fréquence de signalement (personne ne veut de fatigue des outils en plus du reste), mais la détection de base fonctionne.
Q: Ai-je besoin d'un outil pour résoudre les tâches oubliées, ou s'agit-il d'un problème de processus ? A: Honnêtement, cela dépend de l'échelle. Les petites équipes avec deux ou trois outils peuvent généralement résoudre cela avec de meilleures habitudes – une revue hebdomadaire, un document partagé, une discipline de liaison. Mais dès que vous dépassez quatre ou cinq outils et une dizaine de personnes, l'approche manuelle ne passe plus à l'échelle et vous avez besoin de quelque chose qui suit les connexions automatiquement. Le seuil varie selon l'équipe, mais vous le saurez quand vous l'aurez atteint.
Q: Quelle est la différence entre un gestionnaire de tâches et un système d'intelligence des signaux pour la gestion de projet ? A: Un gestionnaire de tâches enregistre ce que vous lui dites. Un système d'intelligence des signaux observe ce qui se passe réellement dans tous vos outils et signale quand quelque chose ne concorde pas – une tâche marquée comme terminée mais avec des commentaires non résolus, une décision prise dans Slack mais jamais reflétée dans le spec. Il capture les choses que les humains oublient de consigner, ce qui, d'après notre expérience, est là où la plupart de ces lacunes trouvent leur origine.