Perdu dans Slack : cherchable ne veut pas dire trouvable
Votre équipe a trop de canaux Slack et ne trouve rien. Pourquoi la recherche seule ne suffit pas – et ce qui fonctionne vraiment.
By Ellis Keane · 2026-03-17
Combien de canaux Slack votre équipe a-t-elle en ce moment ? Pas le nombre dans la barre latérale, parce que vous en avez mis la plupart en sourdine. Le nombre réel, y compris ceux que quelqu'un a créés pour un projet terminé il y a six mois, ceux dont les noms sont si similaires que vous n'êtes jamais sûr du bon, et la poignée de canaux où des choses vraiment importantes se passent et que vous ne retrouverez jamais parce que vous ne saviez pas qu'elles s'y passaient à ce moment-là.
Je suppose que vous ne connaissez pas ce nombre. Nous non plus, honnêtement. Et c'est un peu le sujet.
Le conseil habituel face à la surcharge de canaux Slack consiste à réorganiser, à créer des conventions de nommage, à archiver ce dont vous n'avez pas besoin, peut-être à effectuer un nettoyage trimestriel (le genre de rituel qui semble productif pendant environ un après-midi, puis qui se défait lentement sur les six semaines suivantes). Ce conseil est correct, jusqu'à un certain point, mais il traite le symptôme plutôt que le mécanisme. Si votre équipe a trop de canaux Slack et ne trouve rien, ce n'est pas parce que vous êtes mauvais en organisation (enfin, peut-être un peu) – c'est parce que Slack a été conçu pour les conversations, pas pour la connaissance, et le fossé entre ces deux choses est l'endroit où tout votre contexte important va mourir.
Cherchable ne signifie pas trouvable
C'est là que la plupart des équipes trébuche. La recherche Slack est en réalité assez bonne dans ce qu'elle fait. Vous tapez un mot, elle trouve les messages contenant ce mot, elle les classe même par pertinence et vous permet de filtrer par canal, personne et plage de dates. Si vous savez ce que vous cherchez et à peu près quand cela s'est passé, la recherche Slack vous y amènera.
Le problème est que « trouvable » et « cherchable » décrivent des capacités fondamentalement différentes – et Slack n'en offre qu'une seule.
« Cherchable et trouvable décrivent des capacités fondamentalement différentes – et Slack n'en offre qu'une seule. » – Ellis Keane
Cherchable signifie : j'ai un mot-clé précis et je veux voir tous les messages qui le contiennent. Trouvable signifie : je me souviens qu'une conversation a eu lieu, je sais à peu près de quoi il s'agissait, mais je ne me rappelle pas les mots exacts utilisés, dans quel canal cela s'est passé, ni précisément quand. Ce second cas représente, selon notre expérience, environ 80 % des tentatives réelles de récupération d'information dans Slack.
Pensez à la dernière fois que vous avez essayé de trouver quelque chose dans Slack. Avez-vous tapé un mot-clé exact, ou avez-vous essayé différentes variantes, parcouru des canaux, vérifié des DM, et finalement demandé à quelqu'un : « hé, tu te souviens où on a parlé de… ? » Si c'était la seconde option (et je parierais de l'argent réel que c'est le cas la plupart du temps), alors la recherche Slack n'est pas cassée. Elle résout simplement un problème différent de celui que vous avez réellement.
Comment les canaux se multiplient et le contexte se fragmente
Voici ce qui se passe réellement dans la plupart des équipes que nous avons observées. Cela commence de façon anodine : vous créez des canaux pour les équipes (#engineering, #design, #product), des canaux pour les projets (#project-atlas, #project-beacon), des canaux pour les fonctions (#standup, #deployments, #incidents) et peut-être quelques canaux sociaux (#random, #watercooler). Ça fait environ 15 à 20 canaux et ça fonctionne à merveille pendant environ trois mois.
Puis les contours commencent à se brouiller. Quelqu'un lance dans #engineering une conversation sur un problème de déploiement qui devrait vraiment être dans #incidents. Une conversation de revue de design s'étale sur #design, #project-atlas et un fil de DM. Quelqu'un crée #project-atlas-design parce qu'il veut un espace spécifiquement pour les retours de design sur ce projet, et maintenant il y a deux endroits où les décisions de design d'Atlas pourraient se trouver – mieux vaut vérifier les deux si vous voulez le tableau complet.
Le nombre de canaux n'est pas vraiment le problème, même si c'est ce qu'on ressent (je ne peux pas le prouver pour chaque équipe, mais c'est vrai pour chaque équipe à qui j'en ai parlé). Le problème, c'est que chaque canal devient une poche isolée de contexte sans connexions avec les autres poches. Une conversation dans #project-atlas référence un doc Notion qui référence un issue Linear qui a été discuté dans #engineering, et aucune de ces références n'est un lien lisible par une machine. Ce sont des raccourcis humains : « comme on en a discuté », « selon le doc », « pour faire suite à ce fil ». Une personne qui était dans toutes ces conversations peut suivre la piste. Une personne qui n'y était pas – ou une personne qui y était, six mois plus tard – ne le peut tout simplement pas.
Ce que les conventions de nommage résolvent réellement (et ce qu'elles ne résolvent pas)
Je ne veux pas rejeter complètement les conventions de nommage, car elles aident pour une chose précise : elles vous aident à trouver le bon canal où chercher. Un modèle cohérent comme team-engineering, proj-atlas, func-deploys rend la barre latérale navigable. C'est une vraie valeur ajoutée, même si la convention survit environ jusqu'à la troisième personne qui n'a pas lu le wiki et crée atlas-design-feedback au lieu de proj-atlas-design.
Mais les conventions de nommage ne résolvent pas le problème de trouvabilité, parce que la trouvabilité ne consiste pas à savoir dans quel canal chercher. Elle consiste à retrouver une conversation répartie sur trois canaux et un DM, et aucune convention de nommage au monde ne vous le dira. L'architecture de l'information de Slack est plate par conception, et cette planéité est en réalité l'une de ses forces pour la conversation en temps réel (vous ne voulez pas de hiérarchie quand vous avez besoin de contacter rapidement quelqu'un à propos d'un déploiement), mais c'est un désastre pour la récupération d'information.
Le problème des « trop nombreux canaux » est en réalité un problème de « contexte piégé dans les canaux ». Réduire le nombre de canaux aide à la navigation, mais ne résout pas la fragmentation sous-jacente.
Pourquoi vous avez trop de canaux Slack et ne trouvez rien
Supposons que vous essayiez de retrouver la conversation où votre équipe a décidé de passer de REST à GraphQL pour l'API interne. Voici à quoi ça ressemble concrètement :
- Vous cherchez « GraphQL » dans Slack. Vous obtenez environ 250 résultats dans une douzaine de canaux. La plupart viennent de #engineering, certains de #random (quelqu'un partageant un article de blog), quelques-uns de #project-beacon où quelqu'un a demandé si le changement allait les affecter.
- Vous affinez à #engineering. Il y a encore des dizaines de résultats. La décision elle-même ne s'y trouve pas, parce que lorsque votre ingénieur principal a dit « on y va », il a simplement écrit « ça me semble bien, allons-y » en réponse à un message de deux jours avant.
- Vous cherchez « REST API » en espérant trouver la discussion de comparaison. Ensemble de résultats différent, seulement un chevauchement partiel. Certains des messages les plus importants du fil de décision ne contiennent ni « REST » ni « GraphQL » parce qu'ils discutaient de l'expérience développeur et de la sécurité des types en termes généraux.
- Vous abandonnez et demandez dans #engineering : « quelqu'un se souvient quand on a décidé de passer à GraphQL ? » Quelqu'un répond avec un lien vers un issue Linear. L'issue Linear renvoie vers un RFC Notion. Le RFC Notion référence un fil Slack (mais le lien est mort parce que le canal a été archivé). Et le moment réel de la décision s'est passé dans un huddle sans aucune trace écrite.
Ce n'est pas un problème de recherche. C'est un problème de graphe de connaissances. Et c'est la vraie raison pour laquelle les équipes ayant trop de canaux Slack ne trouvent rien, peu importe à quel point la recherche Slack s'améliore.
Ce qui fonctionne vraiment
Après avoir observé ce schéma dans notre propre équipe (et entendu des histoires remarquablement similaires d'autres responsables techniques), nous avons identifié quelques choses qui aident réellement :
Acceptez que Slack est une boîte de réception, pas une archive. Le changement de modèle mental le plus utile. Slack est l'endroit où les conversations se déroulent en temps réel, pas là où les décisions sont stockées. Si quelque chose d'important a été décidé dans Slack, cela doit être capturé quelque part de durable : un issue Linear, un doc Notion, un ADR, voire un message de commit. Slack, c'est la conversation ; ces autres outils sont le registre.
Utilisez les fils de manière systématique. Les fils sont la meilleure fonctionnalité de Slack pour la trouvabilité, car ils maintiennent une conversation complète dans une unité adressable. Un fil a un lien permanent. Une conversation éparpillée sur la timeline principale d'un canal n'en a pas. Si la culture de votre équipe consiste à répondre dans le canal principal (et beaucoup le font, parce que cela semble plus immédiat), vous rendez la récupération d'information considérablement plus difficile.
Créez des canaux de décisions, pas des canaux de projets. C'est contre-intuitif, mais écoutez-moi. À la place de (ou en plus de) #project-atlas, essayez #decisions ou #decisions-engineering. Un canal dont le seul but est d'enregistrer les décisions avec un contexte bref. Il ne contiendra pas la discussion complète (qui peut vivre là où elle se déroule naturellement), mais il vous donnera un journal chronologique et consultable de ce qui a été décidé et un lien vers l'endroit où la discussion a eu lieu. Considérez-le comme un journal de commits pour la réflexion de votre équipe. Le mécanisme d'application qui fonctionne vraiment (selon notre expérience) : en faire partie de votre modèle de PR. Avant de faire le merge, ajoutez un lien vers le post de décision pertinent. C'est léger, vérifiable lors de la revue, et cela crée une piste qui ne dépend pas de la mémoire ou de la discipline de qui que ce soit.
Connectez les points automatiquement. C'est la partie où je vais mentionner ce que nous construisons, parce que c'est directement pertinent. Sugarbug ingère les messages Slack aux côtés de vos issues Linear, PRs GitHub, docs Notion et commentaires Figma, et construit un graphe de connaissances de la façon dont ils se relient tous les uns aux autres. Quand ces connexions existent, vous n'avez pas besoin de vous souvenir dans quel canal une conversation a eu lieu, parce que vous pouvez partir de la tâche ou du document et suivre la piste jusqu'à chaque conversation pertinente, peu importe où elle se trouvait. Nous cherchons encore la meilleure façon de présenter tout cela (honnêtement, l'UX pour la récupération inter-outils est plus difficile que l'ingestion), mais l'approche centrale – connecter le contexte plutôt que de le réorganiser – est ce qui, selon nous, fait vraiment bouger les choses.
Arrêtez de chercher dans cinq canaux et de repartir les mains vides. Sugarbug connecte Slack au reste de vos outils pour que les décisions restent trouvables.
Q: Combien de canaux Slack, c'est trop ? A: Il n'existe pas de chiffre magique, mais si votre équipe ne retrouve plus régulièrement où une conversation a eu lieu, ou si les gens se replient sur les DM parce que les canaux semblent écrasants, vous avez probablement franchi la ligne. Les équipes de 10 à 20 personnes avec plus de 80 à 100 canaux actifs se heurtent souvent à ce mur – bien que cela dépende beaucoup de la discipline de votre équipe concernant le rôle des canaux et l'archivage.
Q: Sugarbug aide-t-il à gérer la surcharge de canaux Slack ? A: Sugarbug ne gère pas vos canaux directement, mais il résout le problème de trouvabilité que crée la surcharge de canaux. Il ingère les messages Slack aux côtés de vos issues Linear, PRs GitHub, docs Notion et commentaires Figma dans un graphe de connaissances, de sorte que lorsque vous cherchez une décision ou une conversation, vous cherchez une seule fois et la trouvez quel que soit le canal (ou l'outil) où elle a eu lieu.
Q: Pourquoi je ne trouve rien dans Slack même avec la recherche ? A: La recherche Slack trouve les messages contenant vos mots-clés exacts, mais la plupart des décisions en milieu professionnel utilisent des mots différents à différentes étapes. Quelqu'un pourrait dire « l'option Redis » dans un fil et « BullMQ » dans un autre, en référence à la même décision, et ces fils ne se référencent jamais mutuellement. La recherche trouve des correspondances de texte. Retrouver une piste de décision nécessite de comprendre les connexions entre les conversations, ce qui est une capacité fondamentalement différente.
Q: Sugarbug peut-il remplacer les canaux Slack par quelque chose de mieux ? A: Non, et il ne devrait pas essayer. Slack est excellent pour la conversation en temps réel, et c'est une vraie valeur. Le problème n'est pas Slack lui-même, mais le fait que le contexte important reste piégé dans les conversations sans moyen de le connecter aux tâches, documents et code associés. Sugarbug crée ces connexions automatiquement pour que vous n'ayez pas à vous souvenir où les choses ont été discutées.