Les outils de codage de l’IA peuvent réduire la productivité des développeurs expérimentés
L’industrie technologique est convaincue que les outils de développement de l’IA sont essentiels à la réussite de l’entreprise. outils de développement de l’IA rendent les développeurs expérimentés plus rapides. Cette croyance ne tient pas face à la réalité que nous observons dans les environnements de production réels. Les récentes conclusions de Model Evaluation & Threat Research (METR) montrent que les développeurs expérimentés utilisant des outils d’IA tels que Cursor Pro et Claude sont 19 % plus lents à effectuer des tâches de codage dans le monde réel qu’en effectuant le travail manuellement.
Il ne s’agit pas d’une observation fortuite. Elle provient d’un essai contrôlé randomisé bien mené, auquel ont participé 16 développeurs chevronnés qui ont travaillé sur des bases de code complexes et vivantes, des projets qu’ils connaissaient déjà très bien. La leçon est simple : Les suggestions de l’IA ne correspondent pas toujours à la manière dont ces experts travaillent déjà. Dans les systèmes logiciels matures et à grande échelle, le contexte et la qualité comptent plus que les suggestions brutes. Lorsque l’IA ne comprend pas vraiment l’architecture globale en jeu, elle devient une interruption, et non une amélioration.
Cela ne signifie pas que les outils d’IA n’ont aucune valeur. Ce que cela signifie, c’est que les gains de productivité apportés par ces outils ne sont pas universels. Les dirigeants doivent comprendre les environnements dans lesquels ils déploient l’IA. S’il s’agit d’une base de code mature gérée par des experts qui exécutent déjà des flux de travail hautement optimisés, l’intégration de l’IA dans ce mélange peut introduire des étapes supplémentaires au lieu de les éliminer.
Pour les entreprises qui investissent dans l’IA pour le développement à grande échelle, l’efficacité ne consiste pas seulement à écrire du code plus rapidement. Il s’agit de tout ce qui vient après, la révision, le renouvellement et les intégrations. Si nous nous intéressons à la productivité réelle, nous devons compter la quantité de travail que l’IA crée en aval, et pas seulement ce qu’elle produit.
Il existe un écart de perception important entre les performances attendues et réelles de l’IA
Avant le début de l’étude METR, les développeurs s’attendaient à ce que les outils d’IA réduisent de 24 % la durée de leurs tâches. Même après avoir terminé l’étude, et bien qu’ils aient été objectivement 19 % plus lents, ils ont déclaré que l’IA les avait rendus 20 % plus productifs. Ce type de déconnexion n’est pas seulement dangereux, il fausse la façon dont nous mesurons le succès.
Cet excès de confiance ne se limite pas aux développeurs. Selon l’étude, les économistes prévoyaient une amélioration de 39 % de la productivité grâce à l’IA. Les spécialistes de l’apprentissage automatique l’ont estimée à 38 %, soit un peu moins. Les chiffres sont bons sur le papier, mais les pressions de la réalité sont plus importantes. La perception de la rapidité ou de l’amélioration de la productivité semble être davantage liée à la sensation d’utilisation de l’IA qu’à ce qu’elle apporte réellement. Les outils réduisent l’effort mental, c’est certain. Mais cela ne se traduit pas directement par une plus grande efficacité.
Pour les dirigeants qui gèrent des opérations technologiques ou qui supervisent des projets de transformation, il s’agit d’un coup de semonce. Ne confondez pas la satisfaction des utilisateurs avec les résultats réels. Un développeur qui dit qu’il « se sent plus productif » n’expédie peut-être pas un code plus rapide ou de meilleure qualité. Vous ne pouvez pas laisser des récits internes sur la productivité s’exprimer sans contrôle lorsque les données disent autre chose.
Pour aller de l’avant, il faut commencer par mesurer les performances, les performances réelles, et non les sentiments. Ne vous fiez pas à ce que les gens pensent des outils. Attachez-vous à des résultats qui s’étendent à l’ensemble des équipes et qui sont directement liés aux indicateurs de l’entreprise.
Les développeurs modifient fréquemment le code généré par l’IA, ce qui limite ses gains d’efficacité
Lorsque des développeurs expérimentés utilisent des outils de codage de l’IAils acceptent rarement les résultats à leur juste valeur. L’étude METR montre que les développeurs acceptent moins de 44 % des suggestions de code fournies par l’IA. En outre, 75 % d’entre eux ont examiné chaque ligne et 56 % ont déclaré avoir apporté des modifications significatives aux propositions. Cela vous indique que l’IA n’automatise pas les parties difficiles du développement logiciel, mais qu’elle y participe simplement.
C’est là que les hypothèses sur l’automatisation s’effondrent. Écrire du code, ce n’est pas seulement taper des caractères. Les développeurs maintiennent des conventions de style, appliquent des pratiques de sécurité et travaillent au sein d’architectures hautement personnalisées. Les outils d’IA ne comprennent pas suffisamment ce contexte, de sorte qu’une révision humaine devient nécessaire. Le code peut être compilé, mais cela ne signifie pas qu’il est adapté.
Pour les entreprises qui consacrent des ressources à l’adoption de l’IA, ce point est important. Si vos équipes sont encore en train de nettoyer le code de l’IA, de modifier les structures et d’effectuer des révisions supplémentaires, vous augmentez la charge de travail au lieu de la réduire. Même de simples erreurs commises par l’IA peuvent entraîner un surcroît de travail par la suite. Les grands systèmes ne peuvent pas se permettre des corrections fréquentes causées par des suggestions de code non contextuelles ou incohérentes.
La bonne façon de déployer l’IA dans ces scénarios est ciblée. Utilisez-la là où la précision de la suggestion importe moins, dans la documentation, les échafaudages de test, les modèles standard, mais limitez-la dans les domaines qui requièrent de la profondeur. Le temps passé à corriger les erreurs de l’IA pourrait être mieux utilisé à faire le travail correctement dès le départ.
L’IA a du mal à s’intégrer dans des bases de code complexes et matures
Les outils d’IA montrent de réelles limites lorsqu’ils sont utilisés dans des bases de code importantes et bien établies. Ces bases de code s’accompagnent d’interdépendances profondes, de normes strictes et de modèles d’architecture évolués. L’étude du METR a confirmé que les développeurs subissaient le plus grand ralentissement lorsqu’ils travaillaient sur des projets qu’ils connaissaient déjà très bien, ce qui indique que l’IA perturbe plutôt qu’elle ne soutient leur travail dans ces environnements.
Le problème principal est la compréhension du contexte. L’IA génère rapidement des suggestions, mais les grandes bases de code exigent une précision adaptée à l’historique, aux contraintes de l’architecture et aux préférences de l’équipe. Lorsque l’IA n’offre pas cette précision, les développeurs expérimentés interviennent pour interpréter, ajuster et corriger. Il en résulte un ralentissement de l’exécution des tâches et une augmentation des coûts de commutation mentale.
Cela a des implications stratégiques. Pour les DSI et les directeurs techniques qui cherchent à intégrer des outils d’IA dans les systèmes d’entreprise, la valeur dépend de l’endroit et de la manière dont ces outils sont appliqués. Laisser tomber l’IA dans des systèmes existants ou des environnements critiques sans évaluation structurée se retournera probablement contre vous, par des retards, des bogues ou des pertes de temps d’ingénierie.
Il n’est pas nécessaire de rejeter entièrement l’IA. Il suffit de faire preuve de discernement. Identifiez les domaines où les enjeux sont moindres, où la complexité architecturale est minimale et où l’IA peut aider sans introduire de nettoyage. C’est ainsi que vous éviterez une régression déguisée en innovation.
Des tests rigoureux et contrôlés renforcent la crédibilité des résultats de la productivité de l’IA.
La plupart des affirmations relatives à la productivité de l’IA s’appuient sur des scénarios limités ou idéalisés. L’étude METR se distingue par l’utilisation d’un essai contrôlé randomisé dans des conditions réelles. Il ne s’agissait pas d’un environnement de laboratoire. Les développeurs se sont vu confier de véritables tâches de codage sur des référentiels auxquels ils contribuaient depuis des années, avec en moyenne plus d’un million de lignes de code et plus de 22 000 étoiles GitHub. Les tâches n’étaient pas des exercices abstraits. Il s’agissait de véritables travaux de production.
Cette distinction est importante. La plupart des autres études qui présentent des chiffres optimistes concernant le développement assisté par l’IA s’appuient sur des tâches simples et isolées. Elles ne tiennent pas compte de l’échelle organisationnelle, de la complexité de la base de code ou de la familiarité des développeurs. L’approche de METR, elle, en tient compte. Les développeurs ont utilisé Cursor Pro en combinaison avec Claude 3.5 et 3.7 Sonnet entre février et juin 2025, chaque session étant enregistrée à l’écran pour capturer l’ensemble de leur flux de travail. Les tâches ont duré en moyenne deux heures chacune, ce qui permet d’obtenir des données réelles sur l’engagement, et non des spéculations.
Pour les dirigeants qui évaluent les initiatives d’IA dans la livraison de logiciels, ce type de test fixe la barre. Il vous indique les conditions dans lesquelles l’IA ajoute ou soustrait de la valeur. Les références des fournisseurs et les auto-évaluations des développeurs ne vous donnent pas de clarté opérationnelle. Des expériences contrôlées avec des contraintes réalistes le font.
Si votre objectif est d’optimiser le rendement de l’ingénierie, vous ne pouvez pas vous fier à des mesures superficielles. Commencez à exiger des essais contextuels, cohérents et liés à des résultats commerciaux. Toute autre méthode ne tiendra pas la route dans les systèmes réels.
Des données sectorielles plus larges soulignent les problèmes de confiance et de performance liés aux outils d’IA.
Au-delà du METR, les données industrielles à plus grande échelle soulèvent plus de questions que de confirmations lorsqu’il s’agit de la productivité de l’IA dans le développement de logiciels. Le rapport 2024 DORA de Google, qui a interrogé plus de 39 000 professionnels de la technologie, montre un décalage évident. Alors que 75 % des personnes interrogées ont déclaré qu’elles se sentaient plus productives en utilisant des outils d’IA, les mesures de performance du système sous-jacent ont baissé.
Lorsque l’adoption de l’IA augmente de 25 %, la vitesse de livraison diminue de 1,5 %. Plus inquiétant encore pour quiconque assure la maintenance de systèmes à grande échelle, la stabilité du système diminue de 7,2 %. Il ne s’agit pas de petits écarts. Ils signalent une dégradation mesurable de la qualité des livraisons à mesure que l’implication de l’IA augmente. En outre, 39 % des développeurs ont déclaré avoir peu ou pas confiance dans le code produit par l’IA. Cette hésitation ralentit les processus de révision et d’approbation, ce qui a un impact supplémentaire sur le temps de cycle.
L’idée selon laquelle l’IA rend les équipes plus rapides et plus intelligentes est séduisante, mais incomplète. Les améliorations de la productivité basées sur la perception ne sont pas toujours en corrélation avec de meilleurs résultats pour le système. Si la confiance fait défaut, la vitesse ralentit. Si le code généré introduit des bogues ou des inefficacités, vous accumulez une dette technique cachée.
Cela souligne la nécessité d’intégrer l’IA dans le cadre de normes mesurables et applicables. Ne partez pas du principe que la satisfaction est synonyme de succès. Surveillez les mesures, la livraison, la fiabilité du système et le délai d’examen. L’IA doit gagner sur ces points, sinon elle n’aide pas votre entreprise.
Malgré le ralentissement de la productivité, les développeurs continuent d’apprécier les outils d’IA
Même après avoir constaté un ralentissement de l’exécution des tâches (19 % en moyenne), les développeurs ont continué à utiliser les outils d’IA. Plus précisément, 69 % des participants à l’étude ont choisi de continuer à utiliser Cursor Pro après la conclusion de l’étude METR. Cela indique quelque chose d’important : les développeurs voient dans les outils d’IA une valeur qui va au-delà de la simple vitesse.
Les outils réduisent la charge cognitive. Ils facilitent les tâches mineures mais fréquentes telles que le formatage du code, la documentation ou l’échafaudage des tests. Ces cas d’utilisation à faible effort donnent aux développeurs plus de bande passante mentale, même s’ils ne se traduisent pas directement par une exécution plus rapide. Dans la pratique, cela se traduit par une perception d’amélioration du flux de travail, même si les données montrent le contraire.
Pour les chefs d’entreprise, cela met en lumière un aspect subtil mais essentiel. L’adoption de l’IA par les développeurs peut être motivée par des avantages qualitatifs qui n’apparaissent pas immédiatement sur les tableaux de bord. La satisfaction, la facilité de traitement mental et le sentiment de fluidité sont tous importants, mais ils n’équivalent pas nécessairement à une efficacité mesurable. Si ces outils améliorent le moral ou réduisent la fatigue sans nuire à la qualité, ils apportent une valeur ajoutée. Mais si vous vous concentrez sur la production, ces hypothèses doivent être rigoureusement testées.
Vous ne pouvez pas ignorer que la majorité des développeurs ont voté avec leurs actions et ont continué à utiliser les outils. Mais les décideurs devraient se demander dans quels cas ces outils sont réellement utiles, et dans quels cas les avantages ne sont qu’une douce perception. Cette distinction influe sur la manière dont les outils d’IA doivent être achetés, évalués et étendus à l’ensemble des équipes.
Les entreprises doivent adopter une approche nuancée et contextuelle lors de l’intégration de l’IA
Traiter l’IA comme une solution unique pour le développement de logiciels ne correspond pas à la façon dont les équipes travaillent réellement. Sanchit Vir Gogia, PDG et analyste en chef de Greyhound Research, l’a clairement expliqué : l’automatisation doit être spécifique et stratégique. Les copilotes de l’IA sont utiles, mais uniquement dans les domaines où ils amplifient la capacité cognitive sans dégrader la productivité ou la qualité du code.
La documentation, le code standard et la génération de tests sont des domaines où l’IA peut fonctionner de manière fiable. Mais dans les segments du flux de travail qui dépendent fortement du contexte, de l’architecture du système ou de la connaissance du domaine, l’IA risque d’ajouter des frictions. M. Gogia a exhorté les entreprises à accroître la rigueur de leurs cadres d’évaluation. Cela signifie qu’il faut aller au-delà des notes de satisfaction internes ou des études de cas des fournisseurs, et obtenir des mesures de productivité réelles et quantifiables liées aux délais de livraison, aux cycles d’examen par les pairs et à la reprise des travaux.
Les DSI, les directeurs techniques et les responsables de l’ingénierie doivent aborder cette question dans une optique de portefeuille. Utilisez l’IA là où elle est utile. Retenez-la là où elle ne l’est pas. Assurez-vous que votre stratégie de déploiement comprend des mécanismes permettant de déterminer si les outils d’IA créent ou réduisent la charge de travail. Les mesures de haute précision sont plus importantes que l’adoption à grande échelle.
La gouvernance est essentielle. Placer des outils d’IA dans des chemins critiques sans politique, structure ou surveillance introduit un risque caché. Si vous augmentez l’automatisation, vous avez besoin d’une couche de mesure qui va au-delà de la fréquence d’utilisation ou de la perception, et qui montre réellement où va la courbe de performance.
En conclusion
L’IA dans le codage est un outil. Et comme tout outil, l’endroit et la manière dont vous l’utilisez déterminent la valeur que vous en retirez. Pour les développeurs expérimentés qui travaillent sur des systèmes complexes et matures, l’IA peut introduire plus de frictions que de rapidité. Cela ne signifie pas qu’il faille l’abandonner. Cela signifie que vous devez rester réfléchi.
La satisfaction, l’adoption et la productivité perçue sont faciles à mesurer. Ce qui importe davantage, c’est ce qui se passe en aval, la stabilité du système, les délais de révision du code, les reprises, la vitesse de livraison. Si vous ne suivez pas ces éléments, vous n’avez pas une vue d’ensemble.
L’approche intelligente est l’intégration sélective. Déployez des copilotes d’IA dans les bonnes parties de votre pile, dans la documentation, dans les tâches standard, dans les travaux d’assurance qualité répétitifs, mais évitez de les intégrer aveuglément dans les flux de travail critiques. Développez la gouvernance, pas seulement l’enthousiasme.
