De 7 ans à 7 jours avec l'IA agentique

Si vous avez déjà fixé un tableur COCOMO II et l'avez vu prédire 33 mois calendaires pour un projet que votre équipe a livré en deux sprints, vous connaissez déjà le problème : chaque modèle d'estimation en production aujourd'hui a été calibré sur un monde où les développeurs écrivent chaque ligne, le changement de contexte a un coût, et le calendrier s'arrête à 17 heures. Ce monde n'existe plus. Nous avons récemment développé de zéro une application de 286 000 lignes de code (KLOC), répartie sur 672 fichiers et multi-sous-systèmes — couche protocolaire, couche de données, moteur de rendu, intégration de plateforme — et avons atteint un état alpha prêt pour les tests en 7 jours. Le panneau complet du modèle (COCOMO de base/intermédiaire/post-architecture, points de fonction, ligne de base SLOC, Putnam/SLIM) a renvoyé une prédiction médiane de 30,3 mois civils. Le multiplicateur de productivité médian : 4,240×. Même la référence la plus conservatrice (25 SLOC/dev-jour pour les systèmes complexes) était erronée de 1,433×.Les modèles ne sont pas faux. Ils sont mal appliqués. Voici l'analyse détaillée modèle par modèle, la calibration empirique par un même auteur, et ce que la littérature des essais contrôlés randomisés (RCT) de 2024 à 2026 dit réellement sur les domaines où l'IA agentique réduit la durée — et ceux où elle ne le fait pas.

Le projet qui a explosé les estimations

Chez RIADVICE, nous avons récemment développé une application complexe et riche en fonctionnalités — du type de celles qui coordonnent plusieurs sous-systèmes au sein d’une architecture distribuée — sous la forme d’un environnement natif multiplateforme ciblant à la fois les appareils mobiles et les ordinateurs de bureau à partir d’une base de code unique, en réponse aux exigences du marché qui nécessitaient une nouvelle implémentation. La base de code en témoigne :

• 286 662 SLOC (~286 KLOC) répartis sur 672 fichiers source
• 1 329 399 lignes de résiliation totale — 862 488 insertions et 466 911 suppressions
• 700 commits terminé 7 jours de développement actifs pour atteindre la première version alpha prête pour les tests
• Internationalisation complète dans des dizaines de langues locales
• Plusieurs sous-systèmes profondément indépendants — gestion des protocoles, gestion des données, rendu et intégration de la plateforme — tous construits à partir de zéro pour l'environnement cible

Ce n'était pas un habillage ou une simple mise à jour cosmétique. Il s'agissait d'une implémentation native conçue à partir de zéro pour répondre aux exigences du marché que les solutions existantes ne pouvaient pas satisfaire. Avant d'écrire une seule ligne, j'ai intégré dans le projet un outil d'analyse personnalisé qui exécute le ensemble complet de modèles d'estimation de l'effort logiciels standard de l'industrie contre la base de code à mesure qu'elle grandit. L'objectif était honnête : mesurer l'écart entre ce que les modèles classiques prédisent et ce qu'une livraison assistée par IA produit réellement. Les résultats ne relèvent pas d'une erreur d'arrondi. Ils marquent une rupture de catégorie.

Ce que les modèles d'estimation prédisaient par rapport à ce qui s'est réellement produit

Cet outil prend en charge tous les principaux modèles d’estimation issus de la littérature en génie logiciel : COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached et Embedded, optimisé), COCOMO II Post-Architecture (optimisé), les points de fonction, la référence de productivité SLOC et Putnam/SLIM — calibrés en fonction du type de projet à l’aide de constantes publiées issues de la littérature source originale.

Modèle d'estimation	Effort prévu	Calendrier prévisionnel	Accélération vs. réel
COCOMO de base (Organique)	913 hommes-mois	33,3 mois	2,282×
COCOMO de base (Semi-détaché)	1 696 mois-personnes	33,7 mois	4,240×
COCOMO de base (Intégré)	3 200 hommes-mois	33,1 mois	8,000×
COCOMO Intermédiaire (Semi-détaché, ajusté)	1 259 mois-personnes	30,4 mois	3,148×
COCOMO Intermédiaire (Intégré, ajusté)	2 376 mois-personnes	30,1 mois	5,940×
COCOMO II Post-Architecture (ajusté)	1 703 mois-personnes	30,3 mois	4,257×
Points de fonction (estimation grossière)	17,9 hommes-mois	7,5 mois	45×
Ligne de base de productivité en SLOC (25 SLOC/développeur-jour)	573 hommes-mois	573,3 mois	1,433×
Putnam/SLIM	ignoré (durée < 30 jours; T4/3 explose	—	—

Le le multiplicateur de productivité médian pour tous les modèles est de 4 240×. Même le modèle le plus conservateur prédit un délai de livraison d'environ 1 400 fois plus long que ce qui s'est réellement passé. Les plus optimistes, les points de fonction, prévoyaient encore 7,5 mois calendaires — 45× plus long que les 7 jours réels. Les modèles disent que ce projet aurait dû prendre entre 7 mois à 47 ans. Une version alpha était prête à être testée en 7 jours.

Les modèles sont en désaccord entre eux — d'un facteur de 50 à 8 000

Ces modèles ne sont pas d'accord entre eux. Sur cette même base de code, les prédictions varient de 17,9 à 3 200 hommes-mois — un écart de 178×. Le benchmark SEAA 2013 de COCOMO II, SEER-SEM, SLIM et TruePlanning sur 51 projets réels a trouvé un MMRE de 50–100%. Une évaluation de 2023 sur l'ensemble de données COCOMO NASA a révélé un MMRE proche de 1.0 et PRED(0.25) = 0.0 — pas un seul projet n’a été estimé dans la marge d’erreur de 25%. Ces modèles n’ont jamais été conçus pour un projet assisté par l’IA. Mais l’ampleur de cet écart — même en tenant compte de l’imprécision des modèles — nous indique qu’un changement structurel s’est produit.

Ce que disent vraiment les recherches sur l'IA agentique et la productivité des développeurs

Le chiffre de 4 240× est extrême, et je ne veux pas le surestimer. L'échafaudage de projets nouveaux (« greenfield ») gonfle le taux de résiliation, et le SLOC est un indicateur faible de la valeur. Examinons donc la littérature évaluée par les pairs. Les assistants de type Copilot offrent de modestes gains réels. Peng et al. (2023) ont constaté que les développeurs utilisant un assistant de programmation IA ont accompli une tâche 55,81 TP3T plus rapide (95% CI : 21–89%). L'essai contrôlé randomisé (ECR) Microsoft/Accenture/Fortune 100 (2025) — la plus grande étude menée à ce jour, n = 4 867 — a révélé un 26% : augmentation du nombre de tâches achevées. L'essai contrôlé randomisé interne de Google (2024) a révélé environ21% réduction du temps de tâche. L'expérience de terrain de la BRI / Ant Group (2024) a mesuré une Augmentation de la production de code du modèle 55% pour le personnel subalterne. Le résumé honnête : 1,26×–1,56× sur les tâches appropriées. Réel, mais pas transformateur. L'IA agentique fonctionne dans un autre registre. La revue 2025 de Devin par Cognition a fait état de résultats clients de 10× sur les migrations ETL, 14× sur les migrations de versions Java, et 20× sur les correctifs de sécurité. Nubank a annoncé Amélioration de l'efficacité par 12 et Économies de coûts multipliées par 20 sur une refactorisation de plusieurs millions de lignes estimée auparavant comme un effort de plusieurs années par un millier d'ingénieurs. Notre portage se situe exactement dans cette fourchette — l'histogramme des commits montre de denses pics à 22h00, 00h00 et 01h00, la signature de sessions pilotées par des agents. Les contre-preuves sont réelles. L'essai contrôlé randomisé de Metr.org pour 2025 (16 développeurs expérimentés, 246 tâches sur des projets matures) a révélé que l'IA augmentation du temps d'exécution de 19% — le ralenti des développeurs expérimentés sur des bases de code familières. Une étude de type différences des différences de 2026 portant sur 807 dépôts GitHub adoptant des outils d'IA (He et al., MSR ’26) a révélé une accélération “ transitoire ” de la vélocité et une augmentation “ persistante ” de la complexité du code qui a entraîné un ralentissement à long terme. Le titre résume tout : La vitesse au détriment de la qualité. Le consensus : L'IA est d'une grande aide pour les projets de développement entièrement nouveaux et structurés, apporte une aide modeste pour les tâches de finalisation, et peut nuire à la vitesse de développement sur des bases de code matures. La dette de qualité est bien réelle.

Pourquoi les modèles ne tiennent plus la route : trois changements structurels

Aucun des inducteurs de coûts des modèles classiques ne dispose d'un paramètre pour “ le développeur dispose d'un agent autonome qui ne dort jamais et garde l'intégralité de la base de code en contexte ”. Trois changements font s'effondrer la courbe des durées :

L'étalonnage empirique par le même auteur

Les modèles paramétriques présentent des écarts de plusieurs ordres de grandeur ; j'ai donc également effectué un étalonnage empirique inter-projets en comparant le volume de code produit par jour-personne dans mon propre code avant et après l'adoption d'un outil d'IA agentique, sur trois autres dépôts de production au sein du même écosystème :

Projet	Journée de développement et de réduction du taux de désabonnement pré-IA	Taux de désabonnement / jour de développement à l'ère de l'IA	Multiplicateur
Projet A (équilibreur de charge)	673	2,056	3.1×
Projet B (service de reporting)	239	2,127	8.9×
Projet C (service de traitement)	1,322	982	0.7×
Données agrégées (moyenne / médiane)	—	—	4.2× / 3.1×

Même auteur, même domaine, véritable travail de maintenance. Le multiplicateur empirique est 3–9× — un chiffre bien plus prudent que celui de 4 240 × en phase de démarrage, et qui correspond à la fourchette haute des résultats publiés dans le domaine de la recherche sur l’IA agentique. Un projet a même atteint plus lent — les bénéfices dépendent de la tâche à accomplir ; ils ne sont pas universels.

Ce que cela implique pour la planification des projets

Si vous continuez à estimer vos projets logiciels à l'aide de modèles non calibrés et d'une valeur de référence de 25 SLOC par jour, vos estimations seront erronées de un à trois ordres de grandeur pour les travaux assistés par l'IA. Voici comment nous procédons chez RIADVICE :

1. Calibrez selon votre propre histoire. Comparez votre propre rendement en termes de code par jour-personne, avec et sans IA. Cette méthode est moins coûteuse, plus fiable et permet d'obtenir une fourchette comprise entre 3 et 9 fois supérieure, que vous pourrez justifier dans un plan de projet.
2. Distinguer les projets « greenfield » de la maintenance. Le multiplicateur d’Agentic AI est le plus élevé dans le cadre de développements entièrement nouveaux et structurés, et le plus faible (voire négatif) lors de la maintenance de bases de code matures. Il ne faut pas appliquer un seul et même chiffre aux deux cas.
3. Prévoir un budget pour un endettement de qualité. Le développement rapide de l'IA s'accompagne d'une augmentation constante de la complexité. Prévoyez une phase de renforcement de la sécurité et mettez-la en œuvre : surveillez la complexité cyclomatique et effectuez une détection des copier-coller à chaque version.
4. Évaluez la courbe dans son ensemble, et non pas seulement la partie avant. Un gain de vitesse de 10 fois qui double la densité des défauts ne correspond pas à un gain de 10 fois : il s’agit d’un calendrier avancé au prix d’une phase de stabilisation plus longue.

En résumé

Un projet dont tous les modèles d'estimation prévoyaient une durée comprise entre 7 mois et 47 ans a abouti à une version alpha prête à être testée en seulement 7 jours. Ce multiplicateur médian de 4 240 × ne devrait figurer dans le plan de projet de personne. Mais cela montre clairement que le durée du développement de logiciels complexes est en train d'être recomprimé par la même force qui recomprime le effort.Les recherches publiées montrent que l'IA offre entre 1,26× coup de pouce à un Surtension multipliée par 20, avec un risque réel de rendements négatifs sur des bases de code matures et une taxe de qualité mesurable. Les modèles qui nous affirmaient que ce projet prendrait des décennies sont les mêmes qui continuent de tourner dans les feuilles de calcul d'estimation des entreprises aujourd'hui. La question n'est pas de savoir si l'IA agentique modifie la durée des projets — la recherche a déjà répondu. La question est de savoir si vos pratiques d'estimation ont rattrapé les faits. Si vos chiffres proviennent encore d'un modèle de 1981 étalonné sur COBOL et l'assembleur, il est temps de les réétalonner — ou du moins d'arrêter de croire au calendrier qu'ils génèrent.

“ Il reste encore beaucoup à faire pour mieux relever les défis liés à la prévision auxquels on est confronté dans la pratique. ”