L'IA a généré 90 % du code. Les cycles de livraison ont à peine bougé

Un chiffre résume l'essentiel de cette histoire, et ce n'est pas celui dont l'équipe est la plus fière. À la conférence Yunqi de septembre dernier, Wang Shuxin, de la plateforme d'applications de grands modèles AMAP d'Alibaba, a fait état d'un taux de génération de code par IA de 53 % sur les phases de conception technique et de développement. Six mois plus tard, la même équipe atteint 80 à 90 % et au-delà. Le chiffre a presque doublé. Les cycles de livraison ne se sont pas raccourcis de manière notable. La charge de travail des développeurs n'a pas diminué. « Nous avons découvert un fait déroutant : les gains d'efficacité n'étaient pas évidents », a déclaré Wang dans une présentation publiée sur le blog Alibaba Cloud Community.

C'est dans l'écart entre ces deux faits que se trouve la leçon. L'IA a écrit une plus grande partie du code et le logiciel a été livré au même rythme. Le diagnostic auquel l'équipe de Wang est arrivée sert aussi d'argument contre la métrique que la plupart du secteur du codage par IA présente comme un progrès.

Pourquoi une métrique doublée n'a rien apporté

La première raison tient à une arithmétique que l'industrie du logiciel connaît depuis The Mythical Man-Month. Le développement est une étape d'une longue chaîne : proposition de produit, revue produit-ingénierie, conception de la solution, développement, revue de code, tests, intégration, lancement. Chaque étape comporte des coûts de communication, des temps d'attente et un risque d'erreur. Si vous optimisez le codage de 50 % et que le codage représente 30 % de la chaîne, le gain global est de 15 %.

La deuxième raison, c'est le coût caché. Le code généré par IA entraîne plus de temps de revue de code, plus de débogage, plus de retouches. Le cas concret de l'équipe : l'IA a modifié l'ordre des paramètres d'une interface centrale, tous les tests unitaires ont réussi, et après le lancement, cela a cassé trois services en aval. Il a fallu une journée entière pour retrouver la cause.

La troisième, c'est le contexte. Les grandes tâches ne tiennent pas en une seule fois dans la tête d'un modèle. Une opération de refactorisation qui touche une douzaine de modules front-end et back-end ne peut pas survivre à une seule conversation ; l'attention de l'IA se disperse et les contraintes énoncées au départ disparaissent. La conclusion de Wang est sans détour : dans les applications legacy, la programmation par IA doit passer des « vibes » aux « conventions », avec des critères d'acceptation clairs.

La solution : la spécification comme source de vérité

Wang définit le vibe coding comme une « programmation par les vibes » : balancer négligemment quelques prompts à l'IA et la laisser générer des milliers de lignes de code en quelques secondes. Parfait pour les nouveaux projets et les petits scripts, soutient-il. C'est sur les applications legacy que cela casse : elles portent un héritage historique, des dépendances implicites et des connaissances métier intégrées dans le code, et une solution d'IA à l'apparence plausible peut être incompatible avec tout cela.

La réponse d'AMAP, construite sur son outil Qoder, est le développement piloté par les spécifications (Specification-Driven Development). La spécification cesse d'être un guide en prose qui devient obsolète. Elle devient un « code d'intention » structuré que les agents exécutent précisément, et la source de vérité unique à laquelle le code doit correspondre. Le mode Quest Spec de Qoder guide les développeurs à travers les détails, et c'est sur les critères d'acceptation que cela devient testable. « L'utilisateur est redirigé vers la page d'accueil après une connexion réussie » est vague, explique Wang. « Après une connexion réussie, l'utilisateur est redirigé vers la page d'accueil en moins de 3 secondes, et la page d'accueil affiche le pseudonyme de l'utilisateur » est quelque chose qu'un test peut réellement vérifier. Le flux de travail se déroule en quatre étapes :

Parallèlement au SDD, AMAP applique ce qu'elle appelle le Harness Engineering. L'image est celle d'un cheval sauvage : le modèle a une puissance énorme, et sans harnais, on ne peut pas le monter. Le harnais repose sur quatre piliers : l'ingénierie de contexte, qui maintient une source de vérité unique ; des contraintes architecturales qui bloquent les violations avant soumission, de sorte que le code de la couche UI n'a pas le droit de toucher directement à la couche de base de données ; des boucles de rétroaction où les tests s'exécutent, où l'agent lit les journaux d'erreurs et se corrige, et où les corrections de bugs apportées par les humains se figent en règles ; et une supervision humaine pour ce que Wang appelle les 5 % de logique ambiguë que l'IA ne peut pas juger. Le déploiement ferme la boucle via les outils MCP fournis par Aone, la plateforme CI/CD interne d'Alibaba.

Le problème de métrique que personne ne corrige

Tout cela ne signifie pas que le codage par IA a échoué. Cela signifie que le taux de génération de code n'a jamais été le bon tableau de bord. Une équipe qui a presque doublé son taux sans rien gagner prouve que ce chiffre mesure l'activité, pas le débit. Ce qu'AMAP suit désormais, c'est toute la chaîne, de l'exigence au lancement, avec l'IA comme infrastructure plutôt qu'une autocomplétion glorifiée.

Les questions ouvertes de Wang sont honnêtes sur le chemin qui reste à parcourir : la génération de spécifications exige encore une intervention humaine et devrait devenir plus conversationnelle ; les équipes d'agents ont besoin d'une collaboration plus riche, notamment d'itérations multi-tours et d'une attribution dynamique des rôles ; la gestion des connaissances a besoin d'une extraction et d'une réutilisation plus intelligentes. Tant que ces points ne s'amélioreront pas, l'écart entre ce que promettent les taux de génération et ce que livrent les cycles de livraison continuera d'apparaître dans les données PMO.

Personne ne livre un taux de génération de code.