Produire plus vite ne suffit pas.

Le paradoxe des chiffres

L’adoption est acquise. Selon le rapport DORA 2025 de Google Cloud, désormais consacré au développement logiciel assisté par l’IA, environ 90% des professionnels de la tech utilisent l’IA dans leur travail, et une large majorité estime y gagner en productivité.

Les données de livraison racontent une histoire plus nuancée. DORA constate pour la première fois une relation positive entre adoption de l’IA et débit de livraison, ce qui inverse le résultat de 2024. Mais cette même adoption reste associée à une instabilité accrue : davantage de changements qui échouent, davantage de reprises après déploiement.

CircleCI, qui analyse les pipelines d’intégration continue de ses clients, apporte une mesure directe. Son rapport 2026, fondé sur plus de 28 millions de workflows, relève une hausse moyenne de 59% de l’activité, la plus forte jamais observée dans cette série. Pour l’équipe médiane, pourtant, l’activité progresse de 15% sur les branches de fonctionnalités et recule de 7% sur la branche principale, celle qui part en production. Le taux de succès des builds sur cette branche tombe à 70,8%, son plus bas niveau depuis plus de cinq ans, loin des 90% recommandés par CircleCI.

On écrit donc beaucoup plus de code. On n’en livre pas forcément davantage.

Où se loge le ralentissement

Une étude contrôlée du laboratoire METR, publiée en juillet 2025, éclaire le phénomène à l’échelle individuelle. Seize développeurs open source expérimentés ont réalisé 246 tâches réelles sur des projets qu’ils connaissaient bien, avec ou sans outils d’IA. Avec l’IA, ils ont mis en moyenne 19% de temps en plus. Avant l’expérience, ils anticipaient un gain de 24%. Après coup, ils estimaient encore avoir été 20% plus rapides.

METR le souligne lui-même : ce résultat ne se généralise pas à toutes les situations. Il porte sur des développeurs très familiers de grands projets matures, avec les outils du début 2025. Il révèle néanmoins un écart entre perception et mesure que l’on retrouve ailleurs. Le temps gagné à générer est en partie reperdu à relire, corriger, intégrer et vérifier.

Ce coût de vérification se concentre en aval. La revue de code devient le goulot d’étranglement, les suites de tests sont sollicitées plus souvent, les conflits d’intégration se multiplient. La confiance reste d’ailleurs limitée : selon DORA, environ 30% des répondants ne font que peu ou pas confiance aux résultats produits par l’IA. Cette prudence est saine, mais elle a un prix si l’organisation n’a pas prévu le temps qu’elle exige.

L’IA amplifie le système existant

La conclusion la plus utile du rapport DORA tient en un mot : amplificateur. L’IA renforce les équipes qui disposent déjà de bonnes pratiques et expose les faiblesses des autres. DORA a d’ailleurs publié un modèle des capacités qui rendent l’IA bénéfique. On y trouve une position claire et communiquée sur l’usage de l’IA, des données internes saines et accessibles, une gestion de versions rigoureuse, le travail par petits lots, l’attention portée aux utilisateurs et une plateforme interne de qualité.

Aucune de ces capacités n’est propre à l’IA. Ce sont des fondamentaux de l’ingénierie logicielle. L’IA ne les remplace pas. Elle rend leur absence plus coûteuse, et plus visible. Le rapport de DORA sur le retour sur investissement de l’IA, publié en 2026, va dans le même sens en situant les gains dans le système d’ingénierie plutôt que dans les outils eux-mêmes.

Ce que cela implique pour un site ou une plateforme

Pour une entreprise ou une institution, la question n’est pas de savoir si son prestataire utilise l’IA. Il l’utilise très probablement. La question est de savoir ce qui garantit la qualité de ce qui est livré.

Un site institutionnel ou une plateforme métier vit plusieurs années. Le code généré rapidement devra être compris, maintenu, mis à jour et sécurisé par d’autres personnes, parfois par d’autres équipes. Une architecture incohérente, des dépendances ajoutées sans réflexion ou des composants qui contournent les conventions du CMS, qu’il s’agisse de TYPO3, de Statamic ou de WordPress, produisent une dette invisible au lancement. Elle apparaît à la première montée de version.

L’accessibilité et la sécurité sont particulièrement exposées. Un assistant de code reproduit volontiers les modèles les plus courants, y compris les modèles courants et défaillants : boutons sans nom accessible, formulaires sans labels, dépendances superflues. Sans contrôle automatisé ni revue informée, ces défauts passent en production.

Une méthode raisonnable

Quelques principes permettent de capter le gain sans payer la facture plus tard.

• Travailler par petits lots, pour que chaque changement reste relisible et réversible.

• Faire des tests automatisés une condition de fusion, et non une étape facultative.

• Fixer des règles explicites d’usage de l’IA : outils autorisés, données partageables, niveau de revue humaine selon la criticité du code.

• Mesurer la livraison plutôt que la production : délai de mise en production, taux d’échec des changements, temps de restauration, taux de succès de la branche principale.

• Réserver le temps de vérification dans la planification, au lieu de le considérer comme une perte.

Ces principes ne ralentissent pas les équipes. Ils évitent que la vitesse apparente d’aujourd’hui devienne la lenteur réelle de demain.

Questions fréquentes

L’IA rend-elle les développeurs plus productifs ?

Les données sont contrastées. DORA 2025 associe l’adoption de l’IA à un débit plus élevé, mais aussi à davantage d’instabilité. Une étude contrôlée de METR a mesuré des développeurs expérimentés 19% plus lents sur des projets qu’ils connaissaient bien. Le résultat dépend fortement du contexte et des pratiques de l’équipe.

Quels indicateurs suivre ?

Les métriques DORA (fréquence de déploiement, délai de mise en production, taux d’échec des changements, temps de restauration) et le taux de succès de la branche principale, plutôt que le volume de code ou le nombre de demandes de fusion.

Faut-il interdire l’IA dans les projets sensibles ?

Plutôt l’encadrer : définir les outils autorisés, les données qui peuvent être partagées et le niveau de revue humaine requis selon la criticité du code.