Aller au contenu
Tous les articles

De 7 ans à 7 jours grâce à l’IA agentique

par Ghazi Triki · 12 min de lecture

De sept ans à sept jours
Dans cet article

Si vous avez déjà vu un tableur COCOMO II prédire 33 mois calendaires pour un projet que votre équipe a livré en deux sprints, vous connaissez déjà le problème : tous les modèles d’estimation utilisés aujourd’hui en production ont été calibrés dans un monde où les développeurs tapent chaque ligne, où chaque changement de contexte a un coût et où le calendrier s’arrête à 17 h. Ce monde n’existe plus. Nous avons récemment développé à partir de zéro une application de 286 KLOC, répartie en 672 fichiers et plusieurs sous-systèmes (couche protocolaire, couche de données, moteur de rendu, intégration aux plateformes), et atteint une version alpha prête à être testée en 7 jours. L’ensemble des modèles (COCOMO Basic, Intermediate et Post-Architecture, points de fonction, référence SLOC, Putnam/SLIM) a donné une prédiction médiane de 30,3 mois calendaires. Le multiplicateur de productivité médian : 4 240×. Même la référence la plus prudente (25 SLOC par jour-développeur pour les systèmes complexes) s’est trompée d’un facteur 1 433×. Les modèles ne sont pas faux : ils sont mal appliqués. Vous trouverez ci-dessous l’analyse modèle par modèle, l’étalonnage empirique sur un même auteur, et ce que disent réellement les essais contrôlés randomisés publiés de 2024 à 2026 sur les situations où l’IA agentique réduit les délais, et celles où elle ne les réduit pas.

Le projet qui a fait voler les estimations en éclats

Chez RIADVICE, nous avons récemment développé une application complexe et riche en fonctionnalités, de celles qui coordonnent plusieurs sous-systèmes au sein d’une architecture distribuée, sous la forme d’un environnement natif multiplateforme ciblant le mobile et le poste de travail à partir d’une base de code unique, pour répondre à des exigences du marché qui imposaient une nouvelle implémentation. La base de code en dit long sur l’ampleur du projet :

  • 286 662 SLOC (environ 286 KLOC) répartis sur 672 fichiers source
  • 1 329 399 lignes de churn total : 862 488 insertions et 466 911 suppressions
  • 700 commits en 7 jours de développement actif pour atteindre la première version alpha prête à être testée
  • Une internationalisation complète dans des dizaines de langues
  • Plusieurs sous-systèmes sans aucun lien entre eux (gestion des protocoles, gestion des données, rendu et intégration aux plateformes), tous construits à partir de zéro pour l’environnement cible

Il ne s’agissait ni d’une surcouche ni d’un simple habillage. C’était une implémentation native entièrement nouvelle, conçue pour satisfaire des exigences du marché que les solutions existantes ne pouvaient pas remplir. Avant d’écrire la moindre ligne, j’ai intégré au projet un outil d’analyse sur mesure qui applique l’ensemble des modèles d’estimation de l’effort logiciel reconnus par l’industrie à la base de code au fil de sa croissance. L’objectif était honnête : mesurer l’écart entre ce que prédisent les modèles classiques et ce que produit réellement une réalisation assistée par l’IA. Les résultats ne relèvent pas de l’erreur d’arrondi. Ils marquent une rupture de catégorie.

Ce que les modèles d’estimation prédisaient, et ce qui s’est réellement passé

L’outil exécute tous les grands modèles d’estimation de la littérature du génie logiciel : COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached et Embedded, ajustés), COCOMO II Post-Architecture (ajusté), les points de fonction, la référence de productivité SLOC et Putnam/SLIM, calibrés selon le type de projet à l’aide des constantes publiées dans la littérature d’origine.

Modèle d’estimationEffort préditDurée calendaire préditeAccélération par rapport au réel
COCOMO Basic (Organic)913 mois-personnes33,3 mois2 282×
COCOMO Basic (Semi-Detached)1 696 mois-personnes33,7 mois4 240×
COCOMO Basic (Embedded)3 200 mois-personnes33,1 mois8 000×
COCOMO Intermediate (Semi-Det., ajusté)1 259 mois-personnes30,4 mois3 148×
COCOMO Intermediate (Embedded, ajusté)2 376 mois-personnes30,1 mois5 940×
COCOMO II Post-Architecture (ajusté)1 703 mois-personnes30,3 mois4 257×
Points de fonction (estimation sommaire)17,9 mois-personnes7,5 mois45×
Référence de productivité SLOC (25 SLOC/jour-dév.)573 mois-personnes573,3 mois1 433×
Putnam/SLIMignoré (durée inférieure à 30 jours ; T 4/3 diverge)s.o.s.o.

Le multiplicateur de productivité médian, tous modèles confondus, est de 4 240×. Même le modèle le plus prudent prédit un délai de livraison environ 1 400 fois plus long que la réalité. Le plus optimiste, celui des points de fonction, prédisait encore 7,5 mois calendaires, soit une durée 45 fois plus longue que les 7 jours réels. Selon les modèles, ce projet aurait dû prendre entre 7 mois et 47 ans. Une version alpha était prête à être testée en 7 jours.

Les modèles se contredisent, d’un facteur 50 à 8 000

Ces modèles ne s’accordent pas entre eux. Sur cette même base de code, les prédictions vont de 17,9 à 3 200 mois-personnes, soit un écart de 178×. L’évaluation comparative SEAA 2013 de COCOMO II, SEER-SEM, SLIM et TruePlanning sur 51 projets réels a relevé une MMRE de 50 à 100 %. Une évaluation de 2023 menée sur le jeu de données NASA de COCOMO a relevé une MMRE proche de 1,0 et un PRED(0,25) = 0,0 : pas un seul projet 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 l’écart, même en tenant compte de l’imprécision des modèles, montre que quelque chose de structurel a changé.

Ce que dit réellement la recherche sur l’IA agentique et la productivité des développeurs

Le chiffre de 4 240× est extrême, et je ne veux pas en exagérer la portée. Le développement d’un projet entièrement nouveau gonfle le churn, et le nombre de SLOC est un indicateur imparfait de la valeur produite. Examinons donc la littérature évaluée par les pairs. Les assistants de type Copilot apportent des gains modestes mais réels. Peng et al. (2023) ont constaté que les développeurs assistés d’un programmeur IA en binôme accomplissaient une tâche 55,8 % plus vite (IC à 95 % : 21 à 89 %). L’essai contrôlé randomisé Microsoft/Accenture/Fortune 100 (2025), la plus vaste étude à ce jour avec n = 4 867, a relevé une hausse de 26 % des tâches accomplies. L’essai contrôlé randomisé interne de Google (2024) a mesuré une réduction d’environ 21 % du temps consacré à la tâche. L’expérience de terrain BIS/Ant Group (2024) a mesuré une hausse de 55 % de la production de code chez les profils juniors. En résumé, honnêtement : de 1,26× à 1,56× sur les tâches adaptées. C’est réel, mais pas transformateur. L’IA agentique fonctionne dans un tout autre régime. Le bilan 2025 de Devin publié par Cognition fait état de résultats clients de 10× sur les migrations ETL, 14× sur les migrations de version Java et 20× sur les correctifs de sécurité. Nubank a annoncé un gain d’efficacité de 12× et des économies de coûts de 20× sur une refonte de plusieurs millions de lignes, précédemment estimée à un chantier de plusieurs années mobilisant un millier d’ingénieurs. Notre portage se situe précisément dans cette fourchette : l’histogramme des commits montre des pics denses à 22 h, minuit et 1 h du matin, la signature de sessions pilotées par des agents. Les éléments contraires sont bien réels. L’essai contrôlé randomisé de Metr.org en 2025 (16 développeurs expérimentés, 246 tâches sur des projets matures) a montré que l’IA augmentait le temps de réalisation de 19 % : elle a ralenti des développeurs expérimentés sur des bases de code qu’ils connaissaient. Une étude en différence de différences publiée en 2026 sur 807 dépôts GitHub ayant adopté des outils d’IA (He et al., MSR ’26) a constaté un gain de vélocité « transitoire » et une hausse « persistante » de la complexité du code, entraînant un ralentissement à long terme. Le titre résume tout : Speed at the Cost of Quality. Le consensus : l’IA aide beaucoup pour les projets nouveaux et le développement structuré, aide modestement pour les tâches de complétion, et peut nuire à la vélocité sur les bases de code matures. La dette de qualité est bien réelle.

Pourquoi les modèles échouent : trois changements structurels

Aucun des facteurs de coût des modèles classiques ne prévoit le cas où « le développeur dispose d’un agent autonome qui ne dort jamais et garde toute la base de code en contexte ». Trois changements font s’effondrer la courbe des délais :

  1. Le goulet d’étranglement de la saisie a disparu.

Les modèles supposent qu’une part importante de l’effort est mécanique : code passe-partout, échafaudage, refontes répétitives, ressources de localisation et autres données structurées. Dans ce portage, une grande partie du volume est constituée de texte et de câblage très réguliers, qu’un agent peut générer ou transformer en masse. Le code écrit à la main lui-même (échafaudage, constructeurs, liaisons avec les plateformes) est désormais généré par rafales, et non plus saisi ligne par ligne.

  1. Le coût du changement de contexte s’effondre.

Un humain qui passe de la couche protocolaire à la couche de données puis au moteur de rendu paie à chaque fois un coût de remise en contexte. Un agent qui a lu l’intégralité du dépôt de 672 fichiers ne le paie qu’une fois. Cette asymétrie se cumule rapidement sur une base de code de cette taille.

  1. Le calendrier n’est plus le facteur limitant.

Les modèles convertissent les mois-personnes en mois calendaires au moyen d’une équation d’effectifs qui suppose une journée de travail humaine. Les sessions d’agents tournent toute la nuit. L’histogramme des commits montre une production soutenue de 7 h à 1 h du matin : 18 heures actives, et non 8.

L’étalonnage empirique sur un même auteur

Les modèles paramétriques divergeant de plusieurs ordres de grandeur, j’ai également réalisé un étalonnage empirique inter-projets comparant mon propre churn de code par jour-personne avant et après l’adoption d’un outil d’IA agentique, sur trois autres dépôts de production du même écosystème :

ProjetChurn/jour-dév. avant l’IAChurn/jour-dév. à l’ère de l’IAMultiplicateur
Projet A (équilibreur de charge)6732 0563,1×
Projet B (service de rapports)2392 1278,9×
Projet C (service de traitement)1 3229820,7×
Agrégat (moyenne / médiane)s.o.s.o.4,2× / 3,1×

Même auteur, même domaine, véritable travail de maintenance. Le multiplicateur empirique est de 3 à 9×, bien plus prudent que le chiffre de 4 240× obtenu sur un projet nouveau, et cohérent avec le haut de la fourchette de la recherche publiée sur l’IA agentique. Un projet a même ralenti : les gains dépendent de la tâche, ils ne sont pas universels.

Ce que cela implique pour la planification des projets

Si vous estimez encore vos projets logiciels avec des modèles non étalonnés et une référence de 25 SLOC par jour, vous vous tromperez d’un à trois ordres de grandeur sur les travaux assistés par l’IA. Voici ce que nous faisons chez RIADVICE :

  1. Étalonner sur votre propre historique. Comparez votre propre production de code par jour-personne avec et sans IA. C’est moins coûteux, plus honnête, et cela donne une fourchette de 3 à 9× que vous pouvez défendre dans un plan de projet.
  2. Distinguer les projets nouveaux de la maintenance. Le multiplicateur de l’IA agentique est maximal sur les projets nouveaux et le développement structuré, et minimal (parfois négatif) sur la maintenance de bases de code matures. N’appliquez pas un chiffre unique aux deux.
  3. Prévoir un budget pour la dette de qualité. La vélocité apportée par l’IA s’accompagne d’une hausse persistante de la complexité. Planifiez une phase de consolidation et instrumentez-la : suivez la complexité cyclomatique et lancez une détection de copier-coller à chaque version.
  4. Estimer toute la courbe, pas seulement son début. Un gain de vélocité de 10× qui double votre densité de défauts n’est pas un gain de 10× : c’est un calendrier avancé au prix d’une phase de stabilisation plus longue.

En définitive

Un projet qui, selon tous les modèles d’estimation, aurait dû prendre entre 7 mois et 47 ans a atteint une version alpha prête à être testée en 7 jours. Le multiplicateur médian de 4 240× ne devrait servir de plan de projet à personne. Mais c’est un signal clair : la durée du développement de logiciels complexes est en train d’être comprimée par la même force qui comprime l’effort. La recherche publiée montre que l’IA apporte tantôt un léger coup de pouce de 1,26×, tantôt un bond de 20×, avec un risque réel de rendements négatifs sur les bases de code matures et un coût mesurable en qualité. Les modèles qui nous annonçaient des décennies pour ce projet sont ceux-là mêmes qui tournent encore aujourd’hui dans les tableurs d’estimation des entreprises. La question n’est pas de savoir si l’IA agentique modifie la durée des projets : la recherche y a 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 calibré sur du COBOL et de l’assembleur, il est temps de procéder à un nouvel étalonnage, ou du moins de cesser de croire le calendrier qu’il produit.

« There is still significant room for improvement in order to better address the prediction challenges faced in practice. »

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Expertise reconnue en ingénierie et en cloud

RIADVICE, votre partenaire de confiance en génie logiciel

Nous concevons, développons et déployons des systèmes logiciels complexes avec la rigueur d’ingénierie et l’outillage nécessaires pour livrer à l’ère de l’IA : dans les délais, dans le budget et avec la qualité attendue.

En savoir plus sur nos services →

📚 Sources et lectures complémentaires

Cet article s’appuie sur des travaux de recherche évalués par les pairs, des essais contrôlés randomisés et des retours d’expérience de l’industrie portant sur la productivité du développement logiciel assisté par l’IA et sur l’estimation de l’effort logiciel :

⚡ RIADVICE.com propose une ingénierie de confiance, une expertise du cloud et des solutions logicielles de niveau entreprise : dans les délais, dans le budget et avec la qualité attendue.

Partager cet article

Articles liés