Comment retrouver d'anciennes décisions dans Slack (quand la recherche ne suffit pas)
Comment retrouver d'anciennes décisions dans Slack quand la recherche par mots-clés échoue. Pourquoi les décisions disparaissent, pourquoi les journaux de décisions ne tiennent pas et à quoi ressemble un système orienté décisions.
By Ellis Keane · 2026-03-14
Vite : où votre équipe a-t-elle décidé d'utiliser des webhooks plutôt que le polling? Pas ce que vous avez décidé – où cette décision est-elle écrite en ce moment, dans un endroit où quelqu'un qui rejoint l'équipe le mois prochain pourrait la trouver?
Si vous êtes comme nous, la réponse honnête se situe quelque part entre « un fil Slack, probablement » et « je crois que c'était dans #eng-backend, il y a peut-être trois semaines, et je suis presque sûr que deux ou trois personnes étaient impliquées, mais je ne me souviens vraiment plus lesquelles. » Ce qui est un état de fait fascinant quand on y réfléchit, car la décision elle-même était assez importante pour changer le fonctionnement de l'ensemble du système, mais apparemment pas assez importante pour que quelqu'un la note dans un endroit qui ne soit pas un flux de conscience organisé par horodatage. Et c'est, en résumé, le problème lorsqu'on essaie de retrouver d'anciennes décisions dans Slack – l'information est toute là, elle n'est simplement pas organisée d'une manière qui permette de la récupérer en tant que décision.
Je creuse depuis un moment la question de comment retrouver d'anciennes décisions dans Slack, et plus j'approfondis le sujet, plus je pense que le problème fondamental n'est ni la discipline, ni l'habitude, ni aucune des autres choses que les gens incriminent. C'est un problème d'architecture. La recherche Slack a été conçue pour trouver des messages, et les décisions ne sont pas des messages – ce sont des significations qui se trouvent exprimées à travers des messages, une distinction qui semble pédante jusqu'à ce qu'on ait passé vingt minutes à faire défiler des résultats de recherche pour essayer de déterminer laquelle des dix-sept mentions de « webhooks » était celle où l'équipe s'était réellement engagée à les utiliser.
Comment la recherche Slack fonctionne réellement (et où elle échoue)
Soyons précis, car « la recherche Slack est mauvaise » n'est pas le bon diagnostic – la recherche Slack est en réalité assez performante dans ce qu'elle fait. Le problème, c'est que ce qu'elle fait et ce que vous avez besoin qu'elle fasse lorsque vous cherchez une décision sont deux choses fondamentalement différentes.
Slack indexe les messages comme du texte avec des métadonnées : horodatage, expéditeur, canal et (si vous avez un abonnement payant) le contexte complet du fil. Quand vous cherchez « webhook », Slack retourne fidèlement chaque message contenant ce mot, classé par une combinaison de récence et de pertinence. Vous pouvez affiner les résultats avec des opérateurs de recherche – in:#eng-backend from:@sarah before:2026-02-15 – mais vous ne faites que filtrer la même liste plate de messages par métadonnées. C'est de la récupération par mots-clés, et pour trouver un message spécifique dont vous vous souvenez à moitié, ça fonctionne bien.
Mais une décision n'est pas un mot-clé. Une décision est une relation entre une question, un ensemble d'options, un ensemble de personnes et un moment où le groupe a convergé vers une option. Le texte réel de la décision pourrait être « ouais, faisons avec les webhooks, l'approche par polling épuise notre limite de débit » – ce qui est conversationnel, contextuel et n'a de sens que si vous connaissez déjà le fil dans lequel il est apparu. Ou bien ce pourrait être « ça marche, laisse-moi faire un prototype », qui ne contient aucun mot-clé lié à la décision technique qu'il représente.
C'est l'incompatibilité architecturale : Slack stocke les messages chronologiquement et les récupère par mots-clés. Les décisions sont sémantiques (elles portent sur le sens) et relationnelles (elles se connectent aux tâches, aux personnes et aux résultats). Vous demandez à un système de stockage chronologique d'effectuer une récupération sémantique, et il ne peut pas, parce qu'il n'a jamais été conçu pour ça. L'écart entre « consultable » et « retrouvable » s'avère énorme – chaque message de votre historique Slack est techniquement consultable, mais cela ne signifie pas que la décision dont vous avez besoin est retrouvable dans un sens pratique quelconque.
« Slack a créé l'un des plus grands référentiels de prise de décision organisationnelle de l'histoire, et presque rien de tout cela n'est récupérable en tant que décisions – chaque mot parfaitement conservé et presque entièrement introuvable. » – Ellis Keane
Ce qui se passe quand vous essayez de retrouver d'anciennes décisions dans Slack
Voici à quoi ressemble l'incompatibilité en pratique. Disons que votre équipe a décidé il y a trois semaines de passer du polling aux webhooks pour une intégration GitHub. Vous vous souvenez que la discussion a eu lieu dans #eng-backend et impliquait quelques ingénieurs. Vous cherchez donc « webhook » dans ce canal.
Ce qui revient : chaque message qui a jamais mentionné les webhooks dans #eng-backend. Des rapports de bugs vieux de six mois. Quelqu'un posant une question sur la logique de nouvelle tentative des webhooks dans un contexte complètement différent. Un lien que quelqu'un a partagé vers un article de blog sur les meilleures pratiques des webhooks (qui, dans une belle ironie, se classe probablement plus haut dans les résultats de recherche que la décision réelle à côté de laquelle il se trouve). La décision elle-même – une réponse dans un fil où quelqu'un a dit que l'approche par polling atteignait les limites de débit – est enfouie quelque part en page trois, ressemblant exactement à tous les autres messages autour d'elle.
Et c'est le scénario où vous vous souvenez à peu près des mots utilisés. La moitié du temps, les décisions utilisent un langage tellement contextuel qu'il pourrait aussi bien être chiffré. « Allons avec l'option B » ne contient pas du tout le mot « webhook », même si l'option B était les webhooks. « Ça marche, laisse-moi faire un prototype » ne contient même pas le mot « option ». Le moment réel de la décision est souvent le message le plus court et le moins riche en mots-clés de tout le fil, parce qu'à ce stade, tout le monde dans la conversation a déjà le contexte et ils ne font que confirmer l'alignement.
Je trouve cela vraiment intéressant comme problème d'architecture de l'information (bon, intéressant et aussi légèrement frustrant quand c'est vous qui cherchez). Slack a créé l'un des plus grands référentiels de prise de décision organisationnelle de l'histoire, et presque rien de tout cela n'est récupérable en tant que décisions – chaque mot parfaitement conservé, et presque entièrement introuvable.
Pourquoi les journaux de décisions sont un cimetière avec une meilleure signalétique
Le conseil standard, si vous cherchez des solutions, est de tenir un journal de décisions. Une base de données Notion, un canal Slack dédié (dont l'ironie échappe apparemment aux personnes qui le recommandent), une page wiki – un seul endroit où les décisions sont enregistrées au fur et à mesure.
Nous avons essayé. Ça a duré environ six semaines. Les deux premières semaines étaient formidables – tout le monde était engagé, les entrées étaient détaillées, le journal était vraiment utile. À la troisième semaine, les entrées ont commencé à devenir irrégulières. À la cinquième semaine, une personne le mettait encore à jour, écrivant des choses comme « décision prise sur l'auth » sans liens, sans contexte, et sans indication de qui était impliqué ou quelles étaient les alternatives. À la sixième semaine, nous avons discrètement arrêté de faire semblant.
Le problème n'est pas que notre équipe manque de discipline (enfin, peut-être, mais ce n'est pas le problème pertinent ici). Le problème, c'est que la tenue d'un journal de décisions impose une charge exactement au mauvais moment. Vous venez d'avoir une discussion productive, vous avez atteint un accord, quelqu'un est prêt à commencer à construire – et maintenant vous devez vous arrêter, ouvrir un autre outil, rédiger un résumé, taguer les personnes concernées et créer un lien vers la conversation d'origine. C'est de trois à cinq minutes par décision, et pour une équipe prenant cinq à dix décisions significatives par jour entre canaux et fils, la charge s'accumule en quelque chose que personne ne veut assumer.
Et le système ne fonctionne qu'avec 100 % de conformité. Un journal de décisions avec 70 % des décisions est à certains égards pire qu'aucun journal, parce que vous vérifiez maintenant deux endroits et ne faites confiance à aucun. Vous regardez dans le journal, la décision n'y est pas, donc vous cherchez quand même dans Slack – et vous êtes revenu à la case départ, sauf que vous avez aussi perdu deux minutes à vérifier le journal en premier.
Les décisions ne sont pas des événements – ce sont des gradients
Une partie de la raison pour laquelle la journalisation manuelle échoue est qu'elle suppose que les décisions sont des moments discrets et identifiables. En réalité, la plupart des décisions émergent progressivement à travers la conversation, et le « moment de la décision » est souvent genuinement ambigu.
Considérez comment une décision d'ingénierie typique se déroule réellement. Quelqu'un soulève une préoccupation dans un commentaire Figma : « ce schéma d'interaction pourrait ne pas fonctionner sur mobile. » Un ingénieur répond dans un fil Slack, en référençant le commentaire d'origine : « ouais, j'ai examiné ça – la bibliothèque de composants ne le supporte pas. » Un designer suggère une approche alternative dans le même fil. L'ingénieur dit « ça marche, laisse-moi faire un prototype. » Deux jours plus tard, une PR est ouverte pour implémenter l'alternative, et le ticket Linear est mis à jour.
Où la décision a-t-elle été prise? Était-ce le commentaire Figma qui a identifié le problème? Le fil Slack où l'alternative a été proposée? Le moment où l'ingénieur a dit « ça marche »? La PR qui l'a implémenté? En pratique, la décision était distribuée sur ces quatre moments, s'étendant sur deux outils et trois jours. Ce n'était pas un événement que vous pouviez consigner – c'était un gradient qui s'est résolu en un résultat, et la seule raison pour laquelle nous savons qu'une décision a été prise, c'est que le code a changé.
C'est (je pense) la partie que la plupart des conseils sur le « suivi des décisions » se trompe. Elle traite les décisions comme des choses que vous capturez, comme noter un numéro de téléphone. Mais la plupart des vraies décisions sont des choses que vous reconstruisez – vous regardez ce qui a changé, vous remontez en arrière à travers les conversations qui ont mené là, et vous reconstituez le raisonnement après coup. Ce qui signifie que le système dont vous avez besoin n'est pas un journal. C'est un graphe.
Ce qu'un graphe vous donne qu'un journal ne peut pas
Un graphe connecte des signaux entre outils et dans le temps. Au lieu que quelqu'un écrive manuellement « nous avons décidé d'utiliser les webhooks à cause des limites de débit », le graphe relie le fil Slack où les limites de débit ont été discutées, le ticket Linear qui suivait le travail d'intégration, la PR qui a implémenté les webhooks, et les personnes impliquées dans la conversation. La décision n'est pas enregistrée – elle est reconstituable à partir des connexions entre des choses qui se passaient déjà.
La différence pratique apparaît dans un scénario spécifique. Trois semaines après la décision sur les webhooks, un nouvel ingénieur rejoint l'équipe et demande : « pourquoi utilisons-nous des webhooks plutôt que du polling pour GitHub? Le polling semble plus simple. » Sans système connecté, quelqu'un dit « oh, c'est quelque chose qu'on a décidé il y a un moment », personne ne se souvient du canal, quelqu'un passe quinze minutes à chercher dans Slack, et il trouve soit la réponse, soit (plus probablement) reconstruit le raisonnement de mémoire, ce qui est risqué parce que la mémoire est peu fiable et que le raisonnement original était presque certainement plus nuancé que ce dont quelqu'un se souvient trois semaines plus tard.
Avec un graphe, l'ingénieur consulte la tâche d'intégration GitHub. Chaque signal qui a touché cette tâche est lié : la discussion originale sur les limites de débit, le fil où polling vs. webhooks a été évalué, la PR qui a implémenté le changement. La piste complète de la décision, du début à la fin, sans que personne n'ait cherché quoi que ce soit et sans que personne n'ait rien consigné.
L'écart n'est pas entre « bonne recherche » et « mauvaise recherche » – il est entre la récupération par mots-clés et la récupération par relation. Les décisions sont définies par leurs connexions aux tâches, aux personnes et aux résultats, pas par les mots utilisés pour les exprimer.
Les coûts qui n'apparaissent dans aucun tableau de bord
Je suis honnêtement sceptique envers quiconque prétend avoir des chiffres précis pour des coûts immatériels comme ceux-ci (le genre de statistiques « les équipes perdent X heures par semaine » donne toujours l'impression d'avoir été obtenu en remontant à partir d'une conclusion souhaitée), mais voici ce que nous avons observé dans notre propre équipe.
Le coût le plus évident est la re-litigation – quand personne ne peut retrouver la décision originale, les équipes la rouvrent simplement, parfois parce que les gens ne s'en souviennent vraiment plus et parfois parce qu'un nouveau membre de l'équipe a des questions légitimes auxquelles personne ne peut répondre avec précision. Nous rouvrions régulièrement des questions réglées avant d'avoir un moyen de remonter les décisions à leur source, et chaque re-litigation entraîne son propre surcoût : le temps de réunion, la fatigue émotionnelle de discuter de quelque chose dont vous êtes presque sûr qu'il avait déjà été résolu, le doute persistant que le raisonnement original était plus nuancé que ce dont quelqu'un se souvient.
Le coût plus subtil est ce qui se passe pendant l'intégration. Chaque question « pourquoi ça a été fait comme ça? » d'un nouveau membre de l'équipe interrompt quelqu'un qui était présent lors de la décision originale, et la réponse est reconstituée de mémoire à chaque fois que quelqu'un pose la question, dérivant légèrement du raisonnement original à chaque répétition – comme un jeu du téléphone arabe, sauf que le téléphone est un logiciel d'entreprise et le message est « pourquoi l'architecture fonctionne-t-elle comme ça ». Et il y a un déficit de crédibilité qui s'accentue avec le temps : « on a choisi les webhooks » a moins de poids que « on a choisi les webhooks parce que le polling consommait 40 % de notre limite de débit de l'API GitHub et que nous subissions du throttling pendant les heures de pointe. » Le raisonnement est ce qui permet aux futurs ingénieurs d'évaluer si une décision tient toujours dans des circonstances modifiées, et ce raisonnement se trouve quelque part dans un fil Slack, parfaitement conservé et pratiquement invisible.
Arrêtez de perdre des décisions dans le défilement Slack. Sugarbug retrace la piste complète de la décision – du fil Slack au ticket Linear jusqu'à la PR – automatiquement.
Q: Pourquoi est-il si difficile de retrouver d'anciennes décisions dans Slack? A: Slack stocke les messages chronologiquement, pas par sens. Une décision enfouie dans un fil ressemble à n'importe quelle autre réponse – la recherche Slack peut correspondre à des mots-clés, mais elle ne peut pas distinguer « nous avons décidé d'utiliser Redis » de « devrions-nous utiliser Redis? » sans lire le contexte conversationnel complet. Plus le temps passe, plus c'est difficile, parce que vous perdez les indices contextuels (qui était impliqué, quel canal, quelle semaine) qui rendent la recherche viable en premier lieu.
Q: Sugarbug suit-il automatiquement les décisions prises dans Slack? A: Oui. Sugarbug classifie les signaux entrants de Slack et d'autres outils connectés, identifiant des schémas ressemblant à des décisions – des fils qui font référence à des tâches, impliquent des personnes assignées et aboutissent à des changements de statut ou des PRs. Ceux-ci sont liés à la tâche concernée dans le graphe de connaissances, afin que vous puissiez retracer la piste de la décision à partir de la tâche plutôt que de fouiller dans l'historique Slack.
Q: Quelle est la différence entre un journal de décisions et un graphe de connaissances pour les décisions? A: Un journal de décisions exige que quelqu'un enregistre manuellement chaque décision au fur et à mesure – la remarquer, s'arrêter, la résumer, la taguer, la lier. Un graphe de connaissances déduit les décisions à partir des signaux qui circulent dans vos outils et les relie automatiquement aux tâches, personnes et conversations. L'un dépend de la discipline constante de chaque membre de l'équipe; l'autre fonctionne en arrière-plan à partir de l'activité déjà en cours.
Q: Sugarbug peut-il faire remonter des décisions d'outils autres que Slack? A: Sugarbug se connecte à Slack, GitHub, Figma, Linear, Notion, la messagerie et les calendriers. Les décisions s'étendent souvent sur plusieurs outils (un commentaire Figma mène à un fil Slack qui mène à une PR), et le graphe de connaissances relie les signaux de toutes les surfaces connectées. Vous voyez la piste complète quel que soit l'outil dans lequel la conversation a commencé.
Q: En quoi est-ce différent d'utiliser simplement la recherche intégrée de Slack? A: La recherche Slack trouve des messages contenant des mots-clés spécifiques. Un graphe de connaissances trouve les relations entre messages, tâches et personnes. Quand vous cherchez une décision, vous ne cherchez que rarement un mot – vous cherchez le moment où une équipe a choisi une approche plutôt qu'une autre, et ce moment est défini par ses connexions à d'autres signaux, pas par les mots utilisés pour l'exprimer.
---
Si les décisions continuent de disparaître dans votre historique Slack, le problème n'est pas Slack – c'est qu'aucun système ne surveille les moments qui comptent et ne les connecte au travail qu'ils ont façonné. C'est l'écart que nous construisons Sugarbug pour combler.