Le contexte
Un dev senior arrive lundi. Pendant les 12 premières semaines, il pose en moyenne 80 questions par semaine : « comment on parse les webhooks Stripe ici ? », « pourquoi cette migration utilise un trigger PG plutôt qu'un job ? », « qui faut-il pinger sur le module billing ? », « il y a une convention pour les noms de feature flags ? ».
Chaque question coûte 15 à 30 minutes à un autre dev qui se déconcentre, perd son flow, et reprend ensuite plus lentement. Les estimations classiques (Atlassian, GitLab) chiffrent ce coût caché à 20 à 30 k€ par hire, en plus du salaire et de la formation.
Et la qualité des réponses dépend de qui est disponible : si le sénior qui a écrit le module il y a 3 ans n'est plus là, le nouveau dev récupère une version partielle, parfois mythifiée, du « pourquoi ».
Le mécanisme LMbox
Le nouveau dev branche Cursor (ou Claude Code) sur la Box, ajoute le serveur MCP lmbox dans son .cursor/mcp.json, et tape ses questions normalement.
Sous le capot :
- Le serveur MCP indexe GitLab/GitHub (tous les repos accessibles, code + commits + PRs + ADRs en
docs/adr/), Confluence (architecture, runbooks), Slack (canaux #engineering, #infra, #incidents sur 3 ans), Jira (tickets résolus avec leurs commentaires). - Quand le dev tape
@lmbox.search "comment parser les webhooks Stripe", le tiermedium(Qwen 2.5 Coder 32B) traite la requête. - Le serveur retourne une réponse type :
« Pour parser les webhooks Stripe, tu utilises notre lib interne
payments/webhook.py. Elle a été refacto par @sophie en commita3f1c8après le bug#4521(Slack thread du 12 mars 2025). Si tu touches au retry, lis l'ADR-2025-08 — Sophie y explique pourquoi on n'utilise pas le retry natif de Stripe. Le testtest_webhook_idempotency.pycouvre les cas tordus. Pour la prod, le canal Slack #payments est le bon point de contact pour les questions urgentes. »
Chaque assertion est citée et cliquable. Le dev peut vérifier en un clic, lire le contexte historique complet, et comprend non seulement quoi faire mais *pourquoi* — exactement comme s'il discutait avec Sophie.
Le calcul de ROI
Pour une équipe de 30 dev qui hire 4 nouveaux/an (turnover + croissance) :
| Métrique | Avant LMbox | Avec LMbox |
|---|---|---|
| Questions/semaine aux séniors par new hire | 80 | 24 (−70 %) |
| Temps senior perdu/new hire/semaine | 20 h | 6 h |
| Productivité du new hire en semaine 4 | ≈ 40 % | ≈ 75 % |
| Coût caché par hire | 25-30 k€ | 8-10 k€ |
| Économie sur 4 hires/an | — | 70 à 80 k€/an |
Bénéfices secondaires non chiffrés mais réels :
- Les séniors restent concentrés → moins de bugs introduits par interruptions, livraisons accélérées
- Les devs partis continuent de « répondre » via leurs commits et threads — la mémoire institutionnelle ne fuit plus avec le turnover
- Les juniors prennent confiance plus vite parce qu'ils peuvent vérifier eux-mêmes plutôt que demander
- Les ADRs anciens redeviennent vivants (l'IA les sort spontanément, alors qu'ils étaient enterrés dans Confluence)
Les pré-requis
- Connecteurs GitLab ou GitHub indexés sur 36 mois minimum, avec accès aux PRs et issues (pas seulement le code)
- Connecteur Confluence sur les espaces engineering (architecture, ADRs, runbooks). Les ADRs sont énormément plus utiles si vous en faites — sinon l'IA reconstitue moins bien le « pourquoi »
- Connecteur Slack sur 3 ans des canaux engineering (avec consentement RGPD adapté — Slack sync nécessite une politique RH claire sur la durée de rétention)
- Connecteur Jira sur les tickets engineering
- Postes dev avec Cursor 0.49+ ou Claude Code 1.6+ (les deux supportent MCP nativement)
- 1 demi-journée d'évangélisation côté équipe pour les 3 premières utilisations (sinon les séniors continuent de répondre eux-mêmes par habitude)
Le déploiement
- J+1 → J+7 : indexation initiale de tous les connecteurs. Sur un repo de 5-10 ans, prévoir 12-36 h de sync (pas pénalisant — c'est en arrière-plan).
- J+8 : 2 ou 3 séniors testent le copilot sur des questions qu'ils savent déjà résoudre. Calibrage des prompts par type de question (architecture vs ops vs business logic).
- J+15 : le prochain new hire utilise LMbox dès jour 1. Mesure : nombre de questions/semaine vs baseline.
- J+30 → J+90 : extension à toute l'équipe (les séniors aussi : eux gagnent du temps sur leurs propres recherches archéologiques sur du code qu'ils ont oublié).
Les limites & ce que ça ne fait pas
- L'IA n'écrit pas le code à la place du dev. Elle l'oriente, lui donne le contexte. La PR reste signée du dev, avec sa responsabilité.
- Sur du code récemment ajouté (< 1 semaine), l'IA peut manquer de contexte. Re-sync 4 h plus tard règle le problème mais c'est un défaut sur du turnover de code très rapide.
- L'IA ne remplace pas le pair-programming sur les sujets délicats (sécurité, performance critique, architecture nouvelle). C'est un complément, pas un substitut.
- Si votre culture d'équipe est faible en documentation (peu d'ADRs, peu de PRs commentées, Slack à minima), l'IA aura peu de matière. Elle révélera le manque, ne le compensera pas magiquement.