Chez Accenture, une grande partie des prototypes a été produite en coding agentique : Claude Code orchestré en boucles, où l'IA est traitée comme une équipe logicielle structurée, pas comme un assistant de complétion.
La boucle
Plan → Execute → Check → Validate, déclinée à deux échelles : une boucle macro par fonctionnalité, des boucles micro par story. L'humain intervient en entrée avec une fiche de fonctionnalité, puis reprend la main à chaque fin de boucle : relecture du plan, du code produit et du rapport d'inspection avant validation.
Trois règles de discipline
1. Un fichier = une story. Une story qui déborde de son fichier était mal découpée. 2. Des critères Given / When / Then avant tout code. Ça déplace l'effort de réflexion en amont, là où il coûte le moins cher. 3. Un point de contrôle humain systématique. Non négociable, même quand la boucle tourne la nuit.
L'environnement
- Mémoire persistante : un CLAUDE.md global (mes conventions), un CLAUDE.md par projet (versionné, partagé avec l'équipe), et un serveur MCP connecté à Obsidian pour capitaliser décisions d'architecture et retours d'expérience d'une session à l'autre. - Hooks déterministes : blocage d'actions destructives, normalisation de formats, déclenchés avant ou après chaque appel d'outil. La différence entre une consigne et une garantie : une instruction en langage naturel reste probabiliste, un hook ne l'est pas. - Sous-agents : revue de sécurité, rédaction de tests, documentation, isolés dans des contextes dédiés pour ne pas polluer la session principale.
Les gains, chiffrés
- Validation d'une fonctionnalité : de trois jours en scénario classique à environ six heures, avec un agent configuré en effort maximal et des runs de nuit ; le matin, il restait à arbitrer et valider. - MVP : de 4 à 6 mois à environ 1 mois. - Prototype léger fonctionnel : de 2 mois à 2 semaines.
La condition : l'architecture est validée en amont. Les agents exécutent un plan, ils ne le remplacent pas.
Les limites, honnêtes
Le risque principal n'est pas le code manifestement faux, les tests le détectent : c'est le code plausible, conforme en apparence aux critères d'acceptation mais bâti sur une hypothèse implicite erronée. Le second risque est la dette de compréhension : produire vite du code qu'on n'a pas construit soi-même expose à ne plus savoir le faire évoluer. Les critères explicites et la revue de fin de boucle sont les garde-fous ; ils coûtent du temps, et c'est précisément ce coût qui rend le gain net défendable.