Home | Blog | Guide

Recherche multi-outils: le code n'est pas le bon endroit

La plupart des décisions de développement vivent en dehors du code. Comment construire une recherche multi-outils sur Slack, Linear, GitHub et Notion.

By Ellis Keane · 2026-03-17

Votre codebase est l'endroit le moins utile pour chercher pourquoi une décision a été prise.

Je sais que ça semble à l'envers. On passe des années à apprendre les flags de ripgrep, à configurer la recherche dans l'IDE, à mémoriser des patterns regex – et rien de tout ça n'aide quand la question n'est pas « où est cette fonction? » mais « pourquoi avons-nous choisi cette approche plutôt que les trois alternatives dont nous avons discuté? » La réponse à cette deuxième question se trouve presque jamais dans le code. Elle est dans un fil Slack d'il y a quatre mois, un commentaire Linear enterré sous des mises à jour de statut, un doc Notion que quelqu'un a commencé et n'a jamais terminé, et une revue de PR où le vrai débat s'est déroulé dans une réponse à une réponse à une réponse.

C'est le problème de la recherche multi-outils pour les développeurs – le contexte des décisions est éclaté entre les outils sans chemin de requête unifié. On dispose de recherches qui fonctionnent bien dans chaque outil – la recherche Slack est correcte, la recherche de code GitHub est excellente, Linear a des filtres pour tout – mais rien qui ne recherche à travers tous. Les décisions qui ont façonné votre architecture vivent dans cinq endroits différents, et on vous demande de vous souvenir où chercher.

Voilà – comment construire une recherche multi-outils avec ce que vous avez déjà. Aucun nouvel outil requis (enfin, presque – j'en mentionnerai un à la toute fin, mais ça fonctionne sans lui).

L'anatomie d'une décision dispersée

Laissez-moi parcourir quelque chose de concret. L'année dernière, nous décidions entre BullMQ et Temporal pour notre file d'attente de tâches. Voici où cette décision vivait réellement:

Slack (#engineering): Trois fils séparés sur deux jours. Le premier était un lien que quelqu'un avait partagé vers un article de blog Temporal. Le deuxième était un débat sur la question de savoir si nous avions besoin d'une exécution durable. Le troisième (une semaine plus tard, canal différent) était quelqu'un qui demandait « attends, on a décidé pour la file d'attente? »
Linear: Une issue intitulée « Evaluate job queue options » avec six commentaires, dont un tableau comparatif qu'un de nos ingénieurs avait passé une après-midi à rédiger.
GitHub: Une description de PR pour l'implémentation BullMQ qui disait « as discussed » avec zéro lien vers où ça avait été discuté.
Notion: Un architecture decision record à moitié terminé qui couvrait les avantages de Temporal mais qui n'a jamais été mis à jour avec le choix final.
Google Docs: Notes de réunion d'un appel où nous avons réellement pris la décision, enterrées dans des points de liste entre deux points de l'ordre du jour sans rapport.

Cinq outils. Une décision. Et si vous aviez cherché dans n'importe quel outil seul, vous auriez trouvé un fragment – jamais l'image complète. Le PR vous dit ce que nous avons choisi. Les fils Slack vous disent ce que nous avons envisagé. L'issue Linear vous dit les compromis. Le doc Notion vous dit la moitié du raisonnement. Les notes de réunion vous disent le moment où c'a été finalisé.

Ce n'est pas inhabituel. C'est, d'une certaine façon, l'état de l'art de la façon dont les équipes d'ingénierie suivent les décisions en 2026. Nous avons de l'IA qui génère du code et des moteurs de recherche qui indexent tout Internet, mais découvrir pourquoi votre équipe a choisi BullMQ plutôt que Temporal nécessite de vérifier cinq applications et d'espérer que la mémoire de quelqu'un tient le coup.

Ce qui rend la recherche multi-outils difficile pour les développeurs

Ce n'est pas un problème d'API – chaque outil que nous utilisons a une API de recherche parfaitement correcte. Le problème est plus bizarre que ça:

Des formes de données différentes. Slack retourne des messages avec des horodatages et des IDs de canal. Linear retourne des issues avec des états et des étiquettes. GitHub retourne des commits, des PRs et des correspondances de code dans des formats de réponse complètement différents. Fusionner tout ça dans une chronologie cohérente nécessite une normalisation que personne ne prend la peine de construire (parce que, honnêtement, c'est le genre de travail qui n'apparaît pas dans les démos de sprint).

Fragmentation du contexte. Un message Slack disant « allons avec l'option B » est sans signification sans le fil qui a défini les options A, B et C. Mais la recherche Slack retourne des messages individuels, pas des arcs de conversation. Vous trouvez la conclusion sans le raisonnement.

Dérive temporelle. Le processus de décision s'étend souvent sur des jours ou des semaines, avec des lacunes où rien ne s'est passé parce que tout le monde était concentré sur d'autre travail. Une recherche par mots-clés pourrait faire remonter le début et la fin d'une conversation tout en manquant le milieu crucial, simplement parce que des mots différents ont été utilisés à différentes étapes.

La recherche multi-outils pour les développeurs n'est pas un problème d'API – chaque outil a un endpoint de recherche parfaitement correct. C'est un problème de contexte: les décisions sont éparpillées entre les outils sous des formes incompatibles, fragmentées par des arcs de conversation et séparées par la dérive temporelle. La recherche par mots-clés trouve des fragments; seul le contexte connecté trouve l'image complète.

Construire une recherche multi-outils avec ce qu'on a

Voici la partie pratique. Pour trois ou quatre outils avec une recherche en lecture seule, comptez une demi-journée pour avoir une version MVP fonctionnelle – la majeure partie consacrée à la configuration de l'authentification et à la normalisation des réponses plutôt qu'à la logique de recherche elle-même.

Configurer l'accès à l'API

Vous aurez besoin de tokens pour chaque outil:

Slack: Un token utilisateur avec le scope search:read (les méthodes de recherche de Slack nécessitent des tokens utilisateur, pas des tokens bot – créez-les via la page d'applications de l'API Slack)
Linear: Une clé d'API personnelle depuis Paramètres, puis API
GitHub: Un PAT à granularité fine avec accès en lecture à vos dépôts
Notion: Un token d'intégration interne depuis Paramètres, puis Connexions

Le script de requête fan-out

Le schéma de base est ridiculement simple – envoyer la même requête de recherche à chaque API et collecter les résultats:

```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }

async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);

return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```

Chaque fonction search* encapsule l'API respective. Pour Slack, c'est search.messages. Pour Linear, c'est une requête GraphQL contre leurs champs de recherche. Pour GitHub, c'est l'endpoint de recherche REST. Pour Notion, c'est l'endpoint de recherche avec un paramètre query.

Normaliser et dédupliquer

La partie délicate n'est pas la recherche – c'est de rendre les résultats utiles. Vous voudrez:

Normaliser les horodatages entre les outils (Slack utilise des epochs Unix, Linear utilise des strings ISO, GitHub utilise ISO avec des décalages de fuseau horaire)
Regrouper les résultats liés – si le même fil Slack apparaît trois fois parce que trois messages correspondaient, les regrouper en un seul résultat avec l'URL du fil
Classer par pertinence – la plupart des APIs retournent leurs propres scores de pertinence, mais ils ne sont pas comparables entre les outils. Une heuristique simple: les correspondances exactes de mots-clés dans les titres se classent au-dessus des correspondances dans le corps, et les résultats plus récents se classent au-dessus des plus anciens à pertinence égale

Envelopper dans un CLI

J'utilise Commander.js pour ça (principalement par habitude, mais n'importe quoi fonctionne):

```bash $ cross-search "bullmq vs temporal"

Found 14 results across 4 tools:

[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...

[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342

[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289

[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```

Quatorze résultats, triés par date, sur quatre outils. Vous pouvez voir l'arc complet de la décision en un seul endroit: le doc Notion a été démarré en premier, puis la discussion Slack a eu lieu, puis l'issue Linear a été créée pour le suivi, et enfin le PR a atterri une semaine plus tard.

Le rendre vraiment bon

La version de base ci-dessus fonctionne, mais elle a quelques angles frustrants. Voici comment l'améliorer:

Expansion des fils pour Slack. Quand vous trouvez un message correspondant, récupérez le fil entier avec conversations.replies. Le message correspondant pourrait être « ouais, allons avec BullMQ » – pas utile sans les 40 messages précédents de débat. Affichez un extrait du fil, pas seulement le message correspondant.

Commentaires de revue de PR. L'API de recherche de GitHub ne fait pas remonter les commentaires de revue quand vous recherchez des PRs – vous aurez besoin d'un appel séparé à l'endpoint des revues de pull request pour les récupérer. C'est là que vit la vraie discussion technique.

Backlinks. Quand vous trouvez une issue Linear, vérifiez si des messages Slack contiennent l'URL de cette issue. La recherche Slack prend en charge les filtres has:link combinés avec des mots-clés. Cela fait remonter la discussion informelle qui a eu lieu autour du suivi formel.

Mise en cache. Si votre équipe génère beaucoup de contenu (et quelle équipe n'en génère pas), vous allez vite atteindre les limites de débit. Mettez les résultats en cache localement avec un TTL de 30 minutes – la plupart des décisions historiques n'évoluent pas si vite.

Quand la recherche textuelle atteint ses limites

C'est là que je serai honnête sur les limitations. La recherche par mots-clés entre outils vous amène étonnamment loin, et puis elle se heurte à un mur.

Le mur est celui-ci: les décisions évoluent. Le fil Slack sur les « files d'attente de tâches » pourrait ne jamais mentionner « BullMQ » par son nom – à la place, quelqu'un a partagé un lien, quelqu'un d'autre a dit « j'aime l'option basée sur Redis », et une troisième personne a dit « d'accord, allons avec ça ». Votre recherche de « BullMQ » passe à côté de tout le fil parce que le mot n'a jamais été utilisé. Les gens dans le fil savaient ce que « l'option basée sur Redis » signifiait. Votre recherche, non.

C'est fondamentalement un problème de graphe, pas un problème de texte. Ce que vous voulez réellement, c'est: « montre-moi tout ce qui est connecté à la décision qui a mené au PR #289. » Ça implique de comprendre que le PR référence une issue Linear, qui a été créée après une discussion Slack, qui a commencé parce que quelqu'un avait lu un doc Notion. Les connexions sont implicites – les humains les ont faites en copiant des URLs et en disant « as discussed » – et une recherche par mots-clés ne peut pas les reconstruire.

Vous pouvez partiellement résoudre ça en suivant les liens. Parser les URLs des messages Slack, des descriptions de PR et des commentaires Linear. Construire une liste d'adjacence simple: ce fil Slack pointe vers cette issue Linear, qui est référencée dans ce PR. Ensuite quand quelqu'un cherche, vous pouvez étendre les résultats pour inclure les éléments liés même s'ils ne correspondent pas au mot-clé.

Cette approche de liste d'adjacence est essentiellement un graphe de connaissances rudimentaire – et c'est là que vit la vraie valeur de la recherche multi-outils pour les développeurs. Pas à trouver des messages individuels, mais à suivre le fil d'une décision à travers chaque outil qu'elle a touché. C'est moins de la « recherche » et plus de la gestion des connaissances pour développeurs – comprendre comment l'information circule entre vos outils pour pouvoir reconstruire le contexte quand vous en avez besoin.

Le problème de la maintenance (et un raccourci)

L'approche par script fonctionne brillamment pendant environ trois mois, et ensuite quelqu'un change l'espace de travail Slack, ou Linear met à jour son schéma GraphQL, ou vous ajoutez un nouvel outil et personne ne pense à mettre à jour le script de recherche. J'ai construit exactement la même chose deux fois et je l'ai abandonnée deux fois (ce qui en dit probablement plus sur mon engagement envers la maintenance que sur l'approche elle-même).

Si vous voulez une recherche multi-outils pour les développeurs qui reste à jour sans surveillance constante, c'est pour ça que des outils comme Sugarbug ont été créés – il maintient le graphe de connaissances automatiquement et garde les connexions vivantes au fil de l'évolution de vos outils. Mais la version DIY ci-dessus est vraiment utile si vous êtes prêt à la maintenir.

Arrêtez de chercher dans cinq outils séparément. Sugarbug construit le graphe de connaissances pour que vous puissiez trouver n'importe quelle décision, discussion ou commit en un seul endroit.

Q: Comment rechercher simultanément dans plusieurs outils de développement? A: Vous pouvez construire une recherche multi-outils légère en combinant l'API de chaque outil – search.messages de Slack, issueSearch de Linear et l'endpoint de recherche de code de GitHub – dans un seul script qui distribue les requêtes et fusionne les résultats par horodatage. Les exemples de code ci-dessus vous permettront de démarrer en une après-midi. Le principal défi n'est pas la recherche elle-même, mais la normalisation des différents formats de réponse en une chronologie cohérente.

Q: Sugarbug propose-t-il une recherche multi-outils pour les développeurs? A: Oui. Sugarbug ingère des signaux de Linear, GitHub, Slack, Figma, Notion et d'autres outils dans un graphe de connaissances, afin que vous puissiez rechercher une décision ou une discussion et trouver chaque fil, issue et commit connectés en un seul endroit. Il gère la normalisation, la déduplication et le suivi des liens automatiquement – les parties qui rendent l'approche DIY fragile au fil du temps.

Q: Pourquoi ne puis-je pas trouver les décisions d'architecture dans ma codebase? A: Parce que la plupart des décisions se prennent dans des fils Slack, des commentaires Linear, des docs Notion et des revues de PR – pas dans le code lui-même. Le code enregistre le résultat d'une décision (la fonction existe, la bibliothèque a été choisie), mais le raisonnement, les compromis et les alternatives discutées vivent éparpillés dans vos outils de communication. Un git blame vous dit qui a changé une ligne et quand, mais pas pourquoi ils ont choisi cette approche plutôt que les alternatives.

Q: Sugarbug peut-il remplacer les documents ADR pour le suivi des décisions? A: Sugarbug ne remplace pas les ADRs, mais il capture les décisions qui n'y figurent jamais. La plupart des équipes écrivent des ADRs pour peut-être 10% de leurs choix architecturaux – le reste se dissout dans des fils Slack et des commentaires de PR. Sugarbug les fait remonter en connectant les conversations aux changements de code qu'ils ont produits, afin que vous obteniez un suivi des décisions pour les 90% restants sans changer le flux de travail de personne.