Au cœur d'un gain de vélocité de 3×

Toutes les études de cas souffrent du même biais : l'entreprise qui a réussi semble, avec le recul, avoir toujours été destinée à le faire. Pour contrer cela, voici une mission réelle que nous avons menée fin 2025 — noms confidentiels sous NDA, mais les chiffres sont exactement ceux que nous avons enregistrés.

Le point de départ

Notre client était une SaaS en série B, avec 30 ingénieurs répartis sur trois squads produit. Dix-huit mois plus tôt, ils livraient vite. Au moment où ils nous ont contactés, le cycle PR était passé de 1,6 à 4,2 jours, l'astreinte épuisait visiblement les équipes et deux seniors avaient donné leur démission dans le trimestre. La direction savait que quelque chose clochait. Elle n'arrivait pas à se mettre d'accord sur quoi.

L'audit (semaine 1)

Nous avons passé une semaine à observer les standups, lire les cent dernières PR et interviewer chaque ingénieur pendant quarante-cinq minutes. Trois schémas sont apparus.

1. La revue de code était le goulot d'étranglement. Les relecteurs étaient seniors, surchargés et lents. Une PR typique attendait 36 heures avant sa première revue.
2. L'onboarding était tribal. Les nouvelles recrues mettaient 7 semaines à livrer leur première feature non triviale, principalement parce que rien n'était documenté.
3. Les tests étaient un cimetière. La suite faisait 9 minutes, flaky, et sautait discrètement la moitié des chemins critiques.

Le plan (semaine 2)

Nous avons choisi trois interventions, séquencées pour un effet cumulatif :

• Déployer une couche de revue de code assistée par IA qui signalait les problèmes de style, les tests manquants et les bugs évidents avant qu'un humain n'ouvre la PR.
• Construire un petit système RAG sur le code, les runbooks et deux ans de décisions d'architecture, exposé comme un outil de chat interne à toute l'entreprise.
• Pairer chaque ingénieur avec Claude Code pendant deux semaines d'exercices structurés autour de la génération de tests et du refactoring.

Le déploiement (semaines 3 à 8)

Nous ne croyons pas aux jours de bascule. La couche de revue IA est partie derrière un feature flag et a tourné en mode shadow pendant cinq jours, le temps d'ajuster le bruit. Le RAG interne a démarré comme un bot Slack utilisé par deux squads, et n'a été ouvert à toute l'entreprise qu'une fois la qualité de retrieval validée sur 200 questions. Les formations étaient programmées par blocs de 90 minutes sur deux semaines, sans jamais bloquer les engagements de sprint.

Trois choses nous ont surpris :

• Le RAG a connu sa plus forte adoption auprès du support, pas de l'engineering. Le support a commencé à se servir lui-même sur des questions qui remontaient aux seniors depuis des mois.
• La couche de revue IA a détecté en semaine 4 un nœud de race conditions subtiles qui causait silencieusement des incidents en production depuis six mois.
• Deux seniors ouvertement sceptiques en semaine 1 sont devenus les défenseurs les plus convaincus en semaine 6, après avoir vu leur file de relecture tomber de moitié.

Les chiffres (semaine 12)

Douze semaines après le début de la mission, nous avons mesuré les mêmes métriques que celles capturées en semaine 1.

• Cycle PR : 4,2 jours → 1,3 jour (−69 %)
• Latence de première revue : 36 heures → 8 heures
• Délai première feature pour un nouveau : 7 semaines → 3 semaines
• Durée de la suite de tests : 9 minutes → 4 minutes (couverture élargie)
• Incidents en production : 11 / mois → 4 / mois
• NPS interne des ingénieurs : 6 → 32

Les pièges évités (et celui qu'on n'a pas évité)

Ce qu'on a évité : remplacer entièrement la revue humaine. La couche IA s'installe avant le relecteur humain, jamais à sa place. Les équipes qui sautent la revue humaine sur les PR « propres » signalées par l'IA perdent leur cohérence architecturale en un trimestre. À ne surtout pas faire.

Ce qu'on n'a pas évité : sous-investir dans l'observabilité des outils IA eux-mêmes. À la sixième semaine, nous nous sommes rendu compte que nous n'avions aucune télémétrie sur les échecs de retrieval du RAG, et avons dû la rétrofiter. Si nous refaisions cette mission, l'instrumentation serait en semaine 2, pas en semaine 8.

Ce qu'il faut en retenir

• Les gains de vélocité se cumulent le plus vite quand vous visez le goulot d'étranglement, pas l'outil le plus brillant.
• L'adoption est un problème social. Trouvez vos sceptiques-devenus-défenseurs tôt.
• Mesurez avant, pendant et après. Les métriques de vanité ne survivront pas à la conversation avec votre CFO.
• L'augmentation par l'IA fonctionne le mieux quand elle s'installe à côté des humains, pas à leur place.

Cette mission n'avait rien d'un coup d'éclat. C'était une succession de petites décisions bien instrumentées, répétées sur douze semaines. Voilà la méthode. Les outils changent tous les six mois ; la méthode, non.