De six mois à une semaine — 10× plus vite, vraiment ?

Le chiffre choque. Et pourtant, il est vérifiable — tant qu'on sait à quoi on le compare, et ce qu'il recouvre vraiment.

Ce que ça prenait, avant

Un projet classique d'application métier — disons un outil interne pour gérer un flux client — suivait un cycle à peu près fixe :

• Deux semaines de spécifications et d'ateliers.
• Deux à trois semaines de maquettes.
• Deux à trois mois de développement.
• Deux semaines de tests et de corrections.
• Deux semaines de déploiement et de formation.

Total : cinq à six mois. Sans compter les imprévus, les allers-retours fournisseurs, les bugs qu'on découvre le jour du lancement.

Ce que ça prend, aujourd'hui

Le même projet, conduit avec les bons outils agentiques et une discipline de revue, tient dans une semaine :

1. Cadrage (un jour). L'agent reformule, pose les questions qui dérangent, liste les contraintes. Je synthétise avec vous.
2. Architecture (un jour). Schémas, modèles, choix techniques. On tranche vite parce que l'agent génère plusieurs alternatives en parallèle.
3. Construction (deux jours). L'agent produit le code. Je lis, je corrige, je refactorise.
4. Tests (un jour). Cas nominaux et cas limites, générés ensemble.
5. Déploiement & documentation (un jour). CI/CD, logs, Dockerfile, manuel utilisateur.

Cinq à six jours. Littéralement dix fois plus vite que l'ancien cycle. Ce n'est pas une promesse commerciale — c'est l'ordre de grandeur mesuré sur mes propres chantiers depuis un an.

Ce qui a changé

Ce n'est pas un meilleur langage. Pas un framework magique. Ce sont les agents de code et la discipline qu'ils imposent.

• La spec est générée et challengée par l'agent avant toute ligne de code.
• Le squelette est produit en quinze minutes : typé, testé, documenté.
• Les tests sont écrits en parallèle du code, pas après coup.
• Le debug devient un dialogue : stack trace collée, correctif proposé.
• L'observabilité — logs, métriques, alertes — est câblée dès le premier jour.
• La CI/CD est générée : pipelines, Dockerfiles, scripts d'infrastructure.

Le développeur passe moins de temps à taper. Beaucoup plus à décider, à arbitrer, à relire. Le métier se rapproche du product owner — sauf qu'on a les deux casquettes à la fois.

La vitesse ne remplace pas la discipline. Elle l'exige plus que jamais.

Ce qui ne change pas

Le jugement. Le goût. La responsabilité.

L'agent ne choisit pas votre architecture à votre place. Il propose. Vous tranchez. Il ne sait pas quelle fonctionnalité est critique pour votre utilisateur final. Vous lui dites. Il ne voit pas le visage du client au bout du fil. Vous, oui.

Et sur certains sujets — algorithmes sensibles, décisions produit pures, questions juridiques ou de sécurité — le gain de vitesse est bien moindre. On est sur du 2× ou du 3×, pas du 10×. Autant être honnête.

Ce que ça change pour votre budget

Le vrai gain n'est pas sur le prix d'une application isolée. Il est sur la possibilité d'en construire dix au lieu d'une, dans le même trimestre.

Ce qui coûtait six mois de développeur coûte cinq jours. Ce qui semblait impossible parce que trop cher devient faisable. Vous pouvez tester une idée avant d'investir massivement dedans. Vous pouvez essayer trois approches au lieu d'une. Vous pouvez construire des outils internes qu'auparavant on jugeait « pas prioritaires » par manque de budget.

C'est un changement de régime, pas un gain marginal. Et c'est pour ça que ceux qui prennent ce virage maintenant prennent une vraie avance.