Mesurer l’impact réel de l’IA sur le travail des développeurs suppose de distinguer ce qui relève du ressenti et ce qui tient à des données vérifiables. Les outils de génération de code se multiplient, les promesses de gains de productivité aussi. Le rapport DORA 2025 et plusieurs essais contrôlés récents permettent de confronter ces promesses aux résultats observés sur le terrain.
Productivité IA et stabilité logicielle : ce que le rapport DORA 2025 mesure
Le rapport DORA 2025 établit un lien positif entre l’adoption de l’IA et le débit de livraison. Les équipes qui utilisent des assistants de code livrent davantage de fonctionnalités sur une période donnée.
Ce même rapport identifie un lien négatif persistant avec la stabilité des mises en production. Autrement dit, produire plus vite ne garantit pas de produire mieux. Les incidents après déploiement ne diminuent pas proportionnellement au code livré.
Un point souvent ignoré dans les analyses concurrentes : l’IA tend à amplifier les pratiques déjà présentes dans une équipe. Une équipe dotée de bonnes pratiques de revue et de tests voit ses résultats progresser. Une équipe dont les processus sont fragiles voit ses faiblesses s’aggraver. L’outil n’est pas correcteur, il est amplificateur. Des ressources comme codyx.org permettent d’explorer les différentes approches de génération de code dans ce contexte.
Essais contrôlés sur la génération de code : résultats contradictoires
Les études disponibles ne convergent pas vers une conclusion unique. Le tableau ci-dessous résume les écarts observés entre deux types d’essais récents.
| Type d’essai | Contexte | Résultat observé |
|---|---|---|
| Essai METR 2025 | Développeurs expérimentés, projets open source familiers | Durée mesurée des tâches en augmentation malgré un ressenti d’accélération |
| Essais de terrain (3 entreprises) | Tâches de développement courantes, accès à Copilot | Davantage de tâches terminées sur la période observée |
L’essai METR met en lumière un décalage frappant : les développeurs estimaient que l’IA les avait accélérés, alors que la durée réelle avait augmenté. Ce biais perceptif pose un problème méthodologique pour toute entreprise qui évaluerait l’IA uniquement sur le ressenti de ses équipes.
Les essais de terrain, eux, montrent un gain mesurable en volume de tâches complétées. Ces résultats ne mesurent pas la même chose et ne se généralisent pas à tous les contextes. Le type de projet, la familiarité avec le codebase et le niveau d’expérience du développeur changent radicalement la donne.
Sécurité du code généré par l’IA : un angle sous-évalué
La plupart des analyses de productivité se concentrent sur la vitesse d’écriture. La sécurité du code produit reste un angle opérationnel peu traité.
La vérification de sécurité et la revue humaine peuvent absorber une partie du temps gagné à l’écriture initiale. Un développeur qui génère une fonction en quelques secondes mais passe ensuite vingt minutes à vérifier qu’elle ne contient pas de faille d’injection ou de mauvaise gestion des permissions n’a pas forcément gagné du temps net.
Ce phénomène crée un déplacement de charge plutôt qu’une réduction. Le temps d’écriture diminue, le temps de revue augmente. Pour les équipes travaillant sur des applications sensibles (santé, finance, infrastructure), ce transfert mérite d’être quantifié avant de proclamer des gains globaux.
- La génération automatique ne vérifie pas la conformité aux normes de sécurité spécifiques au projet
- Les tests unitaires générés par l’IA couvrent souvent les cas nominaux mais négligent les cas limites et les scénarios d’attaque
- La revue de code humaine reste le dernier rempart, et son temps augmente quand le volume de code produit s’accroît
Mesurer la sécurité séparément de la vitesse
Évaluer un outil de génération de code uniquement par le nombre de lignes produites ou de tâches fermées revient à mesurer la vitesse d’un véhicule sans vérifier ses freins. Les métriques de sécurité (vulnérabilités détectées post-génération, taux de correction avant déploiement) devraient figurer dans tout tableau de bord d’adoption de l’IA.
Ressenti développeur contre données mesurées : comment évaluer l’IA
Le décalage identifié par l’essai METR entre perception et mesure pose une question pratique pour les responsables techniques. Sur quels indicateurs fonder une décision d’adoption ou de renouvellement de licence ?
- Le volume de tâches terminées par sprint donne un signal sur le débit, mais pas sur la qualité du code livré
- Le taux de rollback après déploiement (métrique DORA) capture la stabilité réelle mieux que le ressenti d’équipe
- Le temps de revue de code par pull request, mesuré avant et après adoption de l’IA, révèle si le gain d’écriture se transforme en surcharge de vérification
Une évaluation fiable combine au minimum trois indicateurs : débit, stabilité et temps de revue. Se fier uniquement au ressenti ou au volume de code produit expose à des conclusions erronées.
Le rapport DORA 2025 montre que les équipes qui progressent réellement sont celles qui disposaient déjà de pratiques solides de tests automatisés et de revue systématique. L’IA n’a pas remplacé ces pratiques, elle les a rendues plus productives. Pour les autres, l’outil a surtout accéléré la production de dette technique.
L’enjeu pour les prochains mois n’est pas de savoir si l’IA génère du code plus vite. Elle le fait. La question qui reste ouverte concerne le coût réel de ce code une fois déployé, maintenu et sécurisé sur la durée.
