30 développeurs, 3 semaines, temps de livraison divisé par deux

Le point de départ

Une équipe de 30 développeurs, des licences Claude payées depuis six mois, et un constat que leur CTO résumait sans détour : « rien n'a changé dans nos délais ».

Le diagnostic tenait en trois lignes. Trois power users produisaient des résultats remarquables — dans leur coin, avec des prompts personnels que personne d'autre ne savait utiliser. Les 27 autres avaient essayé, obtenu des réponses génériques, et étaient retournés à leurs habitudes. Et les revues de code, elles, continuaient de s'empiler : le vrai goulot d'étranglement n'avait pas bougé.

Le problème n'était pas Claude. C'était l'absence de système autour de Claude.

Semaine 1 — Audit d'immersion

Trois jours sur site. Cartographie des flux de travail réels : où passait le temps entre une spécification validée et une mise en production. Le résultat était sans appel — la revue de code et la reprise de tickets mal spécifiés consommaient à elles seules près de 40 % du cycle.

Livrable de fin de semaine : la cartographie de maturité IA et une liste de cas d'usage classés par ROI. Les deux premiers étaient évidents : revue de code aux standards maison, et spécification assistée branchée sur leurs conventions.

Semaine 2 — Build du Harness

Nos architectes ont construit la couche d'orchestration sur leur stack existante : repos, CI, conventions de code, historique des décisions d'architecture.

• Contextes métier : produits, conventions internes, vocabulaire de l'équipe — plus rien à réexpliquer à chaque session.
• Skills versionnés : revue de code aux standards maison, rédaction de spécifications, génération de tests aux patterns de l'équipe.
• Garde-fous validés avec la DSI : périmètres de lecture, données qui restent en interne, accès par rôle.
• Tableau de bord : consommation de tokens, taux d'adoption, temps par étape du cycle de livraison.

Semaine 3 — Déploiement et formation

Formation BMAD de toute l'équipe — pas « comment utiliser une IA », mais comment faire évoluer leur propre système : modifier un contexte, versionner un skill, lire le tableau de bord.

Transfert complet des clés en fin de semaine. Le contrat prévoyait notre départ ; il a été honoré.

Les résultats, mesurés sur leur tableau de bord

Trente jours après la fin du sprint, les chiffres venaient de leur propre pilotage — pas du nôtre : 100 % des développeurs utilisaient le Harness au quotidien, et le temps entre spécification et mise en production avait été divisé par deux.

Le savoir-faire des trois power users initiaux est devenu le standard des trente. Et il survivra à leur départ : il est dans les contextes et les skills, plus dans des historiques de chat personnels.