{"id":14616,"date":"2026-10-21T11:08:08","date_gmt":"2026-10-21T09:08:08","guid":{"rendered":"https:\/\/say-digital.io\/blog\/ia-accelere-code-projets-restent-lents\/"},"modified":"2026-10-21T11:08:17","modified_gmt":"2026-10-21T09:08:17","slug":"ia-accelere-code-projets-restent-lents","status":"publish","type":"post","link":"https:\/\/say-digital.io\/blog\/ia-accelere-code-projets-restent-lents\/","title":{"rendered":"L\u2019IA acc\u00e9l\u00e8re le code. Pourquoi vos projets restent-ils lents ?"},"content":{"rendered":"
\n

L\u2019IA acc\u00e9l\u00e8re le code. Pourquoi vos projets restent-ils lents ?<\/h1>\n

La fonctionnalit\u00e9 est d\u00e9velopp\u00e9e. Pourtant, personne ne sait encore si elle peut \u00eatre livr\u00e9e : le responsable m\u00e9tier n\u2019a pas arbitr\u00e9 une exception, les donn\u00e9es de test manquent et la validation attend la prochaine r\u00e9union. Le d\u00e9veloppeur a gagn\u00e9 du temps. Le projet attend toujours.<\/p>\n

L\u2019IA peut acc\u00e9l\u00e9rer la production du code sans r\u00e9duire autant le d\u00e9lai du projet.<\/strong> Quand le d\u00e9veloppement devient plus rapide, le cadrage, les d\u00e9pendances et la validation peuvent devenir les \u00e9tapes limitantes. Pour une entreprise, la bonne mesure est le temps entre un besoin identifi\u00e9 et un r\u00e9sultat r\u00e9ellement utilisable, \u00e0 qualit\u00e9 et p\u00e9rim\u00e8tre comparables.<\/p>\n

O\u00f9 part le temps que l\u2019IA ne fait pas gagner ?<\/h2>\n

Un outil interne ne commence pas au premier commit et ne se termine pas \u00e0 la derni\u00e8re ligne g\u00e9n\u00e9r\u00e9e. Il faut d\u00e9cider ce que l\u2019utilisateur doit pouvoir faire, obtenir les acc\u00e8s, clarifier les r\u00e8gles, tester les exceptions et autoriser la mise en service. Certaines t\u00e2ches avancent en parall\u00e8le ; d\u2019autres bloquent toute la suite.<\/p>\n

Si une \u00e9quipe attend une d\u00e9cision tarifaire, produire plus vite l\u2019\u00e9cran de facturation ne tranche pas la question. Si la personne qui valide n\u2019est disponible qu\u2019une fois par semaine, livrer davantage de propositions peut m\u00eame allonger sa file d\u2019attente. L\u2019acc\u00e9l\u00e9ration locale ne supprime pas la d\u00e9pendance : elle la rend plus visible.<\/p>\n

Ce m\u00e9canisme n\u2019explique pas tous les retards. Une int\u00e9gration complexe ou une migration risqu\u00e9e peut rester le principal obstacle technique. Il faut donc observer le parcours r\u00e9el du travail avant de conclure que le probl\u00e8me est forc\u00e9ment organisationnel.<\/p>\n

Ce que les \u00e9tudes permettent de dire \u2014 et pas davantage<\/h2>\n

Le rapport DORA 2024<\/a> rel\u00e8ve des b\u00e9n\u00e9fices individuels de l\u2019adoption de l\u2019IA, mais aussi une association d\u00e9favorable avec la stabilit\u00e9 et le d\u00e9bit de livraison. Il rappelle l\u2019importance de petits lots et de tests robustes. Ce r\u00e9sultat d\u2019enqu\u00eate ne prouve pas que l\u2019IA ralentit chaque \u00e9quipe ; il montre qu\u2019un gain individuel ne suffit pas \u00e0 pr\u00e9dire la performance de livraison.<\/p>\n

La mesure elle-m\u00eame \u00e9volue. Dans sa mise \u00e0 jour du 24 f\u00e9vrier 2026<\/a>, METR explique pourquoi son nouveau protocole donne un signal peu fiable : certains d\u00e9veloppeurs refusent de travailler sans IA, certaines t\u00e2ches sortent de l\u2019\u00e9chantillon et le travail avec plusieurs agents complique le suivi du temps. METR juge probable une acc\u00e9l\u00e9ration sup\u00e9rieure \u00e0 celle observ\u00e9e d\u00e9but 2025, sans pouvoir en \u00e9tablir solidement l\u2019ampleur.<\/p>\n

Ni ces travaux ni une d\u00e9monstration r\u00e9ussie ne donnent le d\u00e9lai de votre prochain projet. Ils invitent \u00e0 mesurer votre cha\u00eene de livraison, plut\u00f4t qu\u2019\u00e0 appliquer un pourcentage de productivit\u00e9 au planning entier.<\/p>\n

Un exemple : le code est pr\u00eat, la r\u00e8gle m\u00e9tier ne l\u2019est pas<\/h2>\n

Sc\u00e9nario illustratif, et non cas client mesur\u00e9.<\/em> Une PME veut automatiser les relances de factures. L\u2019IA aide \u00e0 construire l\u2019interface et \u00e0 pr\u00e9parer les messages. Au moment du test, trois questions apparaissent : faut-il relancer une facture contest\u00e9e ? Qui peut suspendre l\u2019envoi ? Quelle source fait foi pour le paiement ?<\/p>\n

Ces r\u00e9ponses changent le comportement du logiciel. Si elles arrivent apr\u00e8s le d\u00e9veloppement, l\u2019\u00e9quipe reprend les r\u00e8gles, les \u00e9crans et les tests. Le temps gagn\u00e9 \u00e0 produire la premi\u00e8re version finance alors une partie des corrections, au lieu de rapprocher la mise en service.<\/p>\n

Le bon cadrage n\u2019aurait pas consist\u00e9 \u00e0 tout documenter pendant des semaines. Il aurait r\u00e9uni le responsable du recouvrement, la personne qui conna\u00eet les donn\u00e9es et le d\u00e9veloppeur autour de quelques factures repr\u00e9sentatives. Leur livrable : un premier p\u00e9rim\u00e8tre, les exceptions bloquantes et le nom de la personne qui accepte le r\u00e9sultat. Pour transformer ces d\u00e9cisions en consignes de d\u00e9veloppement, un PRD et un design sprint cibl\u00e9<\/a> sont plus utiles qu\u2019une maquette dont les r\u00e8gles restent implicites.<\/p>\n

R\u00e9duire les attentes sans supprimer les contr\u00f4les<\/h2>\n

Face \u00e0 ces retards, la mauvaise r\u00e9ponse serait de retirer les validations pour \u00ab aller aussi vite que l\u2019IA \u00bb. Un envoi erron\u00e9 \u00e0 un client ou une \u00e9criture comptable incorrecte co\u00fbte davantage qu\u2019un arbitrage pr\u00e9par\u00e9 \u00e0 temps. Il faut rendre les contr\u00f4les disponibles et pr\u00e9cis, pas les effacer.<\/p>\n