Cas d'usage · TechUne IA qui sait pourquoi chaque ligne de code existe.
Vos développeurs ont Claude Code ou Cursor, et un dépôt. Ce qui manque à ces outils, c'est le reste : le ticket, le client qui l'a demandé, la décision d'architecture, l'incident de l'an dernier, la réunion où cela s'est décidé. Nous relions tout cela dans une mémoire d'entreprise exposée en MCP, et nous construisons avec votre équipe les agents qui préparent les incidents, tiennent la documentation à jour et rendent un nouveau développeur opérationnel en une journée.
Cinq questions que votre équipe se pose chaque semaine.
Le code dit ce que le système fait. Pourquoi il le fait, ce qui a déjà cessé de fonctionner et ce qui a été décidé sont répartis entre les tickets, Slack, les post-mortems et quelques personnes. Voici ce que change une mémoire qui les relie.
| Aujourd'hui | Avec la mémoire d'entreprise | |
|---|---|---|
| À quoi est reliée cette fonctionnalité ? | Un commit, un ticket sans contexte, une page Notion périmée, sans lien entre eux. | Le ticket, le client qui l'a demandée, la réunion où elle s'est décidée et la pull request, reliés. |
| Ce bug est-il déjà connu, et comment l'avions-nous corrigé ? | Des tickets similaires sans lien entre eux, le correctif dans une pull request que personne ne retrouve. | Les incidents comparables, leur cause racine, le correctif et la pull request, reliés au service concerné. |
| Pourquoi cette architecture, et qui l'a décidée ? | Une décision prise dans un fil Slack ou une réunion, connue des deux personnes qui l'ont prise, dont une est partie. | La décision, ses alternatives écartées, sa raison et sa date, retrouvées avec leur source. |
| Quelle est la documentation à jour pour ce service ? | Un README périmé, trois pages Notion, et la vraie réponse dans un fil Slack. | La version qui fait foi, reliée au code et aux décisions récentes, avec ce qui a changé depuis sa rédaction. |
| Que doit lire un développeur qui arrive lundi sur ce service ? | Deux semaines à lire des documents périmés et à poser des questions sur Slack. | Le dossier de prise en main du service : architecture, décisions, incidents récents, personnes à connaître, sourcé. |
Les outils de l'équipe tech.
Nous ne remplaçons rien. Les outils que votre équipe utilise déjà alimentent la mémoire en continu, avec les droits de chaque dépôt, et vos IA l'interrogent par le MCP.
GitHub- GitLab
- Bitbucket
Linear
Jira
Notion
Confluence- Notion
Google Drive
- Datadog
- Sentry
- PagerDuty
- Grafana
Slack
Microsoft Teams
Google Meet
Claude Code- Cursor
Copilot
Un outil absent de cette liste ? Nous le rendons accessible lors du déploiement.
Ce que cela change pour l'équipe tech.
Des IA de code qui connaissent l'entreprise, pas seulement le dépôt.
Claude Code, Cursor et vos agents partent avec le contexte complet par le MCP : le ticket, le client, la décision, l'incident passé. Le code produit répond au besoin réel, pas seulement à la consigne.
Des incidents résolus avec l'historique, pas de mémoire.
À l'ouverture d'un incident, les cas comparables, le correctif précédent, les derniers déploiements et la décision d'architecture arrivent avant que l'ingénieur d'astreinte ne les cherche. La mémoire se met à jour seule : plus de post-mortem à retrouver dans un dossier.
Une documentation qui ne périme plus en silence.
Chaque page garde sa date et sa source. Quand le code ou une décision change, la page concernée est signalée, et les notes de version s'écrivent depuis ce qui a réellement été livré.
Vos processus tech, tels qu'ils se font réellement.
Avant de construire quoi que ce soit, nos agents d'interview parlent à chaque membre de l'équipe et cartographient le processus réel, pas celui du wiki : les étapes, les outils, qui décide, et où cela bloque.
L'incident, de l'alerte au post-mortem.
Qui est prévenu, où l'on cherche l'historique, comment le correctif est validé et déployé, ce qui est écrit après, et ce qui ne l'est pas. Y compris les étapes que personne n'a documentées.
La décision technique, du fil Slack à la mise en production.
Comment une question d'architecture se pose, qui tranche, où la décision est écrite (ou non), comment elle se transmet à ceux qui n'étaient pas là, et ce qu'il en reste six mois plus tard.
Les points de friction.
Le bug corrigé deux fois par deux personnes, la décision prise dans Slack et perdue, la documentation que plus personne ne lit parce qu'elle est fausse, le nouveau développeur qui pose les mêmes questions que le précédent : c'est là que les agents sont construits en premier.
Les agents que nous construisons avec votre équipe.
Aucun agent sur étagère. Chaque agent est conçu avec votre équipe tech, pour un besoin précis, sur une mémoire où toutes les données sont déjà reliées. Quatre exemples parmi beaucoup d'autres.
Contexte d'incident
Les incidents comparables et leur correctif, les derniers déploiements sur le service, la décision d'architecture qui l'explique, le runbook à jour et les personnes qui connaissent le sujet, réunis en quelques secondes dans le canal de l'incident.
Qui garde la main. L'ingénieur d'astreinte décide. L'agent ne touche pas à la production.
Contexte de revue
Le ticket et la demande client d'origine, les décisions d'architecture concernées, les incidents passés sur le même module et les conventions de l'équipe, joints à la pull request pour que le relecteur juge le fond, pas seulement la forme.
Qui garde la main. Le relecteur approuve. L'agent ne fusionne rien.
Notes de version et documentation
Les notes de version rédigées depuis les pull requests, les tickets et les décisions, dans le registre de chaque destinataire (clients, support, commerciaux), et les pages de documentation concernées signalées ou mises à jour.
Qui garde la main. L'équipe relit avant publication.
Prise en main d'un service
Un dossier par service : l'architecture et ses raisons, les décisions récentes, les incidents des six derniers mois, les parties fragiles, les personnes à connaître, et les questions que les précédents arrivants ont posées. Construit depuis la mémoire, à jour le jour de l'arrivée.
Qui garde la main. Le responsable technique relit avant de le transmettre.
Ces quatre agents ne sont qu'un échantillon. Une fois les données de l'équipe reliées, un agent se construit pour chaque tâche qui le mérite : questionnaires de sécurité et volets techniques des appels d'offres, revue de la dette et des dépendances, suivi des engagements pris en post-mortem, réponses du support sur un comportement du système. Dites-nous ce qui mobilise le temps de votre équipe, nous construisons l'agent correspondant.
Les questions de chaque rôle.
Posées à la mémoire depuis Claude Code, Cursor ou l'IA que l'équipe utilise déjà, par le MCP, ou à vos agents. Chaque réponse cite ses sources.
Développeur
Retrouve la raison d'être d'un code et l'historique d'un service sans solliciter l'équipe.
- À quoi est reliée cette fonctionnalité : ticket, client, réunion, pull request ?
- Comment avons-nous corrigé ce type d'incident la dernière fois ?
- Quelle est la décision d'architecture derrière ce choix, et qui l'a prise ?
- Quelle documentation est encore valable pour ce service ?
- Qui connaît ce module, et où en est-il ?
Ingénieur d'astreinte
Arrive sur un incident avec l'historique, pas avec une page blanche.
- Avons-nous déjà eu cette alerte, et qu'est-ce qui l'avait causée ?
- Qu'est-ce qui a été déployé sur ce service depuis hier ?
- Quel est le runbook à jour pour ce service, et qui l'a modifié en dernier ?
- Quels services dépendent de celui-ci ?
- Qui dois-je prévenir, et qu'avons-nous dit aux clients la dernière fois ?
Responsable technique
Voit la dette, les incidents et les décisions en cours sans attendre le point hebdomadaire.
- Quels incidents de ce trimestre ont la même cause racine ?
- Quelles décisions d'architecture attendent un arbitrage ?
- Quels engagements du post-mortem du mois dernier ne sont pas tenus ?
- Quelles promesses faites aux clients ont un impact technique non planifié ?
- Que doit lire un développeur qui arrive lundi sur ce service ?
Commencez par la tech. La même mémoire sert ensuite les autres.
Le Company Brain n'est pas un outil de développement : c'est la mémoire de l'entreprise. Le code, les décisions et les incidents reliés pour l'équipe tech servent aussi au produit qui priorise, au support qui répond sur un comportement du système et aux commerciaux qui remplissent un questionnaire de sécurité. Un premier périmètre, un résultat mesuré, puis la décision d'élargir.
Questions fréquentes
Les questions que posent les équipes tech avant de commencer. Si la vôtre n'y figure pas, posez-la-nous directement.
Ils continuent. La mémoire est exposée en MCP : leurs outils l'interrogent directement, avec leurs droits, et partent avec le contexte de l'entreprise, le ticket, le client, la décision, l'incident passé, au lieu du seul dépôt ouvert.
Pas sans votre accord. Vous choisissez les modèles, y compris des modèles open source hébergés chez vous. La mémoire relie le code au reste, elle ne le copie pas ailleurs, et chaque accès respecte les droits du dépôt.
Rien ne vous y oblige. La différence est l'entretien : nos agents d'ingestion maintiennent les connexions, les droits par personne et par agent, et la provenance de chaque fait, sans mobiliser l'équipe chaque semaine. Si votre outil répond au besoin, nous nous y connectons.
Non, c'est le cas le plus fréquent. La mémoire part de ce qui est vrai aujourd'hui, le code, les tickets, les décisions récentes, et nos agents d'interview reconstituent le reste avec l'équipe. La documentation redevient un résultat, pas un préalable.
Le plus souvent par un service, avec le contexte d'incident et la prise en main pour les nouveaux arrivants : deux cas où le gain se mesure dès le premier incident et la première arrivée. Nous mesurons, puis nous élargissons.
Parlons de votre équipe tech.
Trente minutes : vos outils, vos services, et le premier agent qui rendrait du temps à votre équipe.