L’IA accélère le code. Pourquoi vos projets restent-ils lents ?

La fonctionnalité est développée. Pourtant, personne ne sait encore si elle peut être livrée : le responsable métier n’a pas arbitré une exception, les données de test manquent et la validation attend la prochaine réunion. Le développeur a gagné du temps. Le projet attend toujours.

L’IA peut accélérer la production du code sans réduire autant le délai du projet. Quand le développement devient plus rapide, le cadrage, les dépendances et la validation peuvent devenir les étapes limitantes. Pour une entreprise, la bonne mesure est le temps entre un besoin identifié et un résultat réellement utilisable, à qualité et périmètre comparables.

Où part le temps que l’IA ne fait pas gagner ?

Un outil interne ne commence pas au premier commit et ne se termine pas à la dernière ligne générée. Il faut décider ce que l’utilisateur doit pouvoir faire, obtenir les accès, clarifier les règles, tester les exceptions et autoriser la mise en service. Certaines tâches avancent en parallèle ; d’autres bloquent toute la suite.

Si une équipe attend une décision tarifaire, produire plus vite l’écran de facturation ne tranche pas la question. Si la personne qui valide n’est disponible qu’une fois par semaine, livrer davantage de propositions peut même allonger sa file d’attente. L’accélération locale ne supprime pas la dépendance : elle la rend plus visible.

Ce mécanisme n’explique pas tous les retards. Une intégration complexe ou une migration risquée peut rester le principal obstacle technique. Il faut donc observer le parcours réel du travail avant de conclure que le problème est forcément organisationnel.

Ce que les études permettent de dire — et pas davantage

Le rapport DORA 2024 relève des bénéfices individuels de l’adoption de l’IA, mais aussi une association défavorable avec la stabilité et le débit de livraison. Il rappelle l’importance de petits lots et de tests robustes. Ce résultat d’enquête ne prouve pas que l’IA ralentit chaque équipe ; il montre qu’un gain individuel ne suffit pas à prédire la performance de livraison.

La mesure elle-même évolue. Dans sa mise à jour du 24 février 2026, METR explique pourquoi son nouveau protocole donne un signal peu fiable : certains développeurs refusent de travailler sans IA, certaines tâches sortent de l’échantillon et le travail avec plusieurs agents complique le suivi du temps. METR juge probable une accélération supérieure à celle observée début 2025, sans pouvoir en établir solidement l’ampleur.

Ni ces travaux ni une démonstration réussie ne donnent le délai de votre prochain projet. Ils invitent à mesurer votre chaîne de livraison, plutôt qu’à appliquer un pourcentage de productivité au planning entier.

Un exemple : le code est prêt, la règle métier ne l’est pas

Scénario illustratif, et non cas client mesuré. Une PME veut automatiser les relances de factures. L’IA aide à construire l’interface et à préparer les messages. Au moment du test, trois questions apparaissent : faut-il relancer une facture contestée ? Qui peut suspendre l’envoi ? Quelle source fait foi pour le paiement ?

Ces réponses changent le comportement du logiciel. Si elles arrivent après le développement, l’équipe reprend les règles, les écrans et les tests. Le temps gagné à produire la première version finance alors une partie des corrections, au lieu de rapprocher la mise en service.

Le bon cadrage n’aurait pas consisté à tout documenter pendant des semaines. Il aurait réuni le responsable du recouvrement, la personne qui connaît les données et le développeur autour de quelques factures représentatives. Leur livrable : un premier périmètre, les exceptions bloquantes et le nom de la personne qui accepte le résultat. Pour transformer ces décisions en consignes de développement, un PRD et un design sprint ciblé sont plus utiles qu’une maquette dont les règles restent implicites.

Réduire les attentes sans supprimer les contrôles

Face à ces retards, la mauvaise réponse serait de retirer les validations pour « aller aussi vite que l’IA ». Un envoi erroné à un client ou une écriture comptable incorrecte coûte davantage qu’un arbitrage préparé à temps. Il faut rendre les contrôles disponibles et précis, pas les effacer.

• Avant de construire : choisir un résultat observable, un responsable métier et les cas qui bloqueraient la mise en service.
• Pendant la production : limiter le nombre de sujets ouverts et présenter de petites unités testables. Une demande de décision doit contenir les options, leurs conséquences et une recommandation.
• Avant la mise en service : réserver le créneau de validation et préparer les données nécessaires. « À valider » doit désigner une personne et une question, pas une colonne sans propriétaire.
• Après le déploiement : vérifier l’usage et les erreurs, puis corriger le prochain obstacle. Le travail n’est pas terminé parce que le code est en production.

Les contrôles dépendent du risque. Une modification de texte réversible ne demande pas la même revue qu’une automatisation de paiement. En revanche, une génération rapide ne justifie jamais de sauter les tests ou d’élargir silencieusement les permissions. Notre guide sur le développement MVP, les tests et le déploiement contrôlé détaille ce passage de la preuve à un outil exploitable.

Quel tableau de bord regarder à la place du volume de code ?

Conservez les indicateurs techniques qui aident l’équipe. Mais ne confondez ni lignes générées ni nombre de tâches fermées avec un résultat métier. Suivez quelques besoins de leur formulation à leur première utilisation effective, avec la même définition du départ et de l’arrivée.

• Délai besoin → résultat utilisable : combien de temps s’écoule avant que l’utilisateur accomplisse la tâche prévue ? Distinguez l’attente de priorisation du travail engagé.
• Temps en attente et cause : décision, accès, données, revue ou disponibilité d’un tiers. Une attente longue mérite un responsable, pas seulement un statut.
• Reprises après validation : quelles modifications viennent d’un défaut, d’une règle découverte trop tard ou d’un changement de périmètre ? Les remèdes ne sont pas les mêmes.
• Qualité et usage : l’outil est-il utilisé, avec quelles erreurs et quel effet sur le processus visé ? Un délai plus court obtenu en livrant moins fiable n’est pas le gain recherché.

Comparez des lots similaires et regardez leur dispersion, pas seulement une moyenne. Une évolution d’accès et une refonte du système de facturation ne constituent pas deux unités équivalentes. Le but est d’identifier une attente récurrente sur laquelle agir, non de classer les développeurs.

La décision à prendre sur votre prochain projet

Avant d’acheter un nouvel assistant de code ou de demander davantage de production, reprenez quelques fonctionnalités récemment livrées. Où ont-elles attendu ? Quelle décision aurait pu être prise plus tôt ? Qui devait accepter le résultat ? Si le développement reste le poste dominant, améliorez-le. Si le travail s’accumule en validation, produire plus ne résoudra pas la file.

Dans le Say Digital Framework, le cadrage sert à rendre un premier résultat testable ; le prototype vérifie les hypothèses ; les tests et la CI/CD — l’intégration et la livraison continues — sécurisent le passage vers un déploiement contrôlé. La mesure d’usage indique ensuite ce qu’il faut reprendre. Chaque étape doit lever une incertitude nécessaire à la suivante, pas ajouter un dossier de plus.

Votre projet produit vite mais n’avance pas ? Say Digital peut vous aider à identifier l’attente qui bloque, cadrer une première tranche utile et organiser sa validation jusqu’à la mise en service. Parlons de votre projet : l’objectif est un outil utilisé, pas une démonstration de vitesse de génération.

Sources et limites

• DORA, Accelerate State of DevOps Report 2024 : résultats d’enquête, associations et recommandations de livraison ; pas une prévision universelle du gain IA.
• METR, We are Changing our Developer Productivity Experiment Design, 24 février 2026 : limites de sélection et de mesure dans une étude de développeurs open source. Les anciens résultats ne décrivent pas à eux seuls les outils actuels.

La grille de pilotage et le scénario de relance proposés ici constituent une méthode d’analyse, pas des résultats expérimentaux ni une promesse de délai.