Outils d’IA pour coder : l’impact réel reste à prouver

Les gains de productivité annoncés par les outils de codage de l’IA ne sont pas cohérents

Il y a beaucoup de bruit autour des outils d’intelligence artificielle comme GitHub Copilot, Cursor et d’autres plateformes similaires qui prétendent augmenter la productivité des développeurs. L’histoire est souvent la même : codage plus rapide, suggestions plus intelligentes, livraison accélérée. Pourtant, si l’on s’éloigne du marketing et que l’on se penche sur les flux de travail réels des équipes d’ingénieurs, les résultats sont beaucoup plus limités. Selon le rapport 2025 Engineering Leadership Report de LeadDev, seuls 6 % des 617 responsables techniques interrogés ont observé des gains de productivité substantiels grâce à ces outils.

Telles sont les données. Seulement 6 %.

Comparez maintenant ces chiffres aux messages des fournisseurs eux-mêmes. GitHub affirme que 88 % des utilisateurs de Copilot « se sentent » plus productifs. Le directeur de l’ingénierie de Jit, Daniel Koch, a déclaré que son équipe était jusqu’à trois fois plus rapide à livrer des fonctionnalités grâce à Cursor. Lori Beer, DSI mondial de JPMorgan Chase, a fait part d’une amélioration de 10 à 20 % au sein des équipes d’ingénieurs internes utilisant un assistant d’IA maison. Ces chiffres semblent excellents et, dans des environnements isolés et contrôlés, ils peuvent même être exacts. Mais « se sentir » productif et atteindre une productivité durable et mesurable sont deux choses différentes.

Vous pouvez avoir l’impression d’aller vite, mais avancez-vous réellement plus vite et dans la bonne direction ?

Comme pour toute nouvelle technologie, le succès perçu peut être rapidement gonflé, en particulier lorsqu’il est piloté par le sommet sans que l’exécution quotidienne ne fasse l’objet d’un examen approfondi. Ce décalage commence à se faire sentir. Les développeurs utilisent les outils, mais les bonds spectaculaires promis par le battage médiatique sur l’IA n’apparaissent pas dans les métriques de livraison, les performances des sprints ou les résultats plus généraux. Dans la plupart des cas, nous constatons des améliorations progressives, voire inexistantes. Et pour les responsables de l’ingénierie chargés d’améliorer les performances à grande échelle, les réussites isolées ne suffisent pas. Ils ont besoin d’une valeur composée dans l’ensemble de l’organisation.

C’est là que le discours actuel sur les outils de codage de l’IA s’effondre. Nous recherchons l’échelle à partir d’exemples qui pourraient ne pas l’être. Ce n’est pas que les outils n’ont pas de potentiel, ils en ont clairement. Mais la productivité réelle ne se produit pas simplement parce que quelqu’un a gagné cinq minutes en écrivant une fonction. Elle se produit lorsque les systèmes évoluent, que les frictions sont éliminées et que les équipes résolvent les problèmes plus rapidement. Nous n’en sommes pas encore là.

Les dirigeants doivent considérer ces premiers résultats comme des signaux et non comme des solutions. Investissez, répétez, restez proche de vos ingénieurs de première ligne. Oubliez le bruit. Concentrez-vous sur ce qui fait réellement avancer l’aiguille.

Les outils de codage de l’IA sont principalement axés sur la génération de code et les tâches connexes.

Il ne fait aucun doute que les outils d’IA font de plus en plus partie de l’environnement quotidien des développeurs. Les outils d’IA font de plus en plus partie de l’environnement quotidien des développeurs. Depuis la sortie de ChatGPT fin 2022, des outils comme GitHub Copilot et Cursor ont été intégrés directement dans l’espace de travail de codage, au sein d’IDE populaires comme VS Code et JetBrains. Les développeurs les utilisent pour ce qu’ils savent faire : la génération de code, le remaniement, la documentation. C’est là que se situe l’essentiel de l’utilisation. Selon le rapport LeadDev Engineering Leadership Report, 47 % des responsables de l’ingénierie ont indiqué que leurs équipes utilisent l’IA pour la génération de code, 45 % pour le remaniement et 44 % pour la documentation.

Ces tâches sont utiles. Elles permettent de gagner du temps et de réduire la charge répétitive. Mais ce n’est pas là que se trouvent les plus gros problèmes. Les contraintes les plus fortes se situent ailleurs, dans les boucles de retour d’information des tests, les retards de déploiement et les lacunes de communication entre les équipes d’ingénierie et les autres équipes. L’utilisation de l’IA dans des domaines tels que la correction des bogues ne représente que 22 %. La communication interne ? À peine 28 %. C’est là que l’on perd du temps. C’est là que les progrès s’arrêtent.

Lorsque le code est facile à écrire mais lent à livrer, vous n’avez pas résolu le vrai problème.

De nombreux outils se concentrent aujourd’hui sur les parties visibles du processus de développement. Ils ne s’attaquent pas aux inefficacités sous-jacentes qui allongent les délais et réduisent l’élan. Rebecca Murphey, directrice technique de Swarmia, a souligné que les retards ne sont souvent pas dus à la saisie du code, mais à l’attente, l’attente de la réussite des tests, de l’achèvement de la construction, de la finalisation des approbations. Il ne s’agit pas de problèmes de codage. Il s’agit d’inefficacités du système. Et l’IA n’est actuellement pas utilisée de manière suffisamment stratégique pour les résoudre.

Voici la nuance : L’IA appliquée dans un cadre étroit n’a qu’un impact limité. Les organisations qui considèrent l’IA comme une amélioration des fonctionnalités obtiendront des gains au niveau des fonctionnalités. Celles qui souhaitent débloquer des améliorations exponentielles doivent être prêtes à relever les défis fondamentaux, là où se trouvent les vraies frictions. Cela signifie que les équipes doivent aller au-delà de la question de savoir comment l’IA peut les aider à écrire du code plus rapidement, et commencer à se demander où elles perdent du temps dans l’ensemble du processus de livraison de logiciels.

Les dirigeants qui cherchent à accroître l’efficacité de l’ingénierie doivent repenser la manière dont les outils d’IA sont déployés. Il ne s’agit pas d’automatiser des tâches isolées pour les développeurs, mais de résoudre des frictions persistantes et structurelles. Concentrez vos efforts là où les cycles humains sont gaspillés, et pas seulement là où l’IA peut remplir automatiquement une fonction. Les gains les plus importants se situent dans les coulisses.

L’adoption descendante des outils d’IA

Nous observons une tendance dans de nombreuses organisations : Les outils d’IA sont introduits par les équipes dirigeantes qui veulent des améliorations rapides, mais les développeurs, les personnes qui font le travail, sont souvent laissés à l’écart du processus de prise de décision. Le résultat est clair. Les outils sont déployés pour résoudre des problèmes qui ne ralentissent pas réellement les équipes, tandis que les véritables obstacles sont ignorés ou laissés de côté.

Andrew Zigler, Senior Developer Advocate chez LinearB, a mis le doigt sur le problème principal : la plupart des outils mis en place aujourd’hui se concentrent uniquement sur l’écriture du code. Ce n’est qu’une partie du processus. Lorsque vous introduisez des outils sans l’avis des développeurs, vous risquez de résoudre des problèmes qui ne sont pas prioritaires ou d’introduire de nouvelles frictions là où il n’y en avait pas.

Pour que l’IA ait un impact réel, elle doit être intégrée là où la douleur est réelle. Cette intégration ne commence pas par le choix d’un outil, mais par l’identification de ce qui est cassé ou inefficace dans vos flux de travail. Laura Tacho, directrice technique de DX, a clairement souligné ce point : les dirigeants doivent cesser de présenter l’IA comme une solution miracle. Au lieu de cela, ils doivent cartographier précisément les endroits où les développeurs perdent du temps ou se heurtent à des obstacles, et aligner les capacités d’IA sur ces points.

L’adoption précoce penche souvent en faveur d’un enthousiasme descendant. Il s’agit d’une dynamique courante : les outils sont présentés comme des outils de transformation, puis achetés et distribués. Mais en l’absence d’une validation ascendante de la part des ingénieurs, le déploiement perd de sa force. Rebecca Murphey, directrice technique de Swarmia sur le terrain, l’a confirmé. Vous ne commencez pas par une solution. Vous commencez par identifier le point de friction exact, vous y travaillez, puis vous répétez ce processus jusqu’à ce que vous ayez réduit les contraintes réelles.

La nuance pour les cadres est simple : ne laissez pas la vision l’emporter sur la perspicacité. Oui, il incombe aux dirigeants de viser haut et d’investir dans l’innovation. Mais la réalisation d’un changement significatif dans l’ingénierie, en particulier avec l’IA, n’est pas une question de distribution de masse. C’est une question de précision. Trouvez les goulets d’étranglement. Écoutez vos développeurs. Faites-les intervenir très tôt. Si vous ne le faites pas, vous risquez de mettre en œuvre des outils qui offrent peu de valeur et ajoutent des frais généraux de gestion.

Adopter l’IA parce que c’est la tendance n’est pas une stratégie. Résoudre le problème exact auquel votre équipe est confrontée, puis étendre cette solution, crée un véritable effet de levier.

L’intégration réussie de l’IA dans l’ingénierie nécessite une approche collaborative

L’IA dans le développement de logiciels ne transformera pas votre organisation si elle est traitée comme un déploiement de licences. Les outils seuls ne résolvent rien. Ce qui compte, c’est la manière dont ils sont utilisés et, plus important encore, la raison pour laquelle ils sont utilisés. Si vos équipes de développement ne sont pas impliquées dans cette conversation dès le départ, tout ce que vous ferez, c’est dépenser du budget pour des logiciels qui ne s’intégreront peut-être jamais de manière significative à la façon dont vos employés travaillent.

Laura Tacho, directrice technique de DX, a été claire sur ce point : si vous voulez un changement dans l’ensemble de l’organisation, vous avez besoin de contributions de l’ensemble de l’organisation. Cela commence par l’ancrage de votre stratégie d’IA dans le retour d’information réel des développeurs qui comprennent les goulots d’étranglement et les points de friction au sein de leurs sprints, de leurs systèmes et de leurs équipes. Il ne s’agit pas de distribuer des accès et de voir ce qui colle, mais de coordonner et d’aligner les efforts autour d’une voie d’amélioration claire.

Rebecca Murphey, directrice technique de Swarmia, l’a également souligné. La plupart des efforts échouent parce que les dirigeants passent directement au mode solution. Mais la valeur réelle se révèle lorsque vous commencez par un diagnostic détaillé du problème : qu’est-ce qui ralentit les équipes, où les systèmes se cassent-ils, et comment supprimer progressivement ces points d’inefficacité ? C’est la bonne séquence. Tout le reste ne fait qu’ajouter de la complexité.

La nuance pour les dirigeants : les déploiements ne sont pas synonymes de résultats. Vous ne visez pas une adoption superficielle. Vous visez des gains de performance mesurables. Cela se produit lorsque les développeurs ont confiance dans le fait que les outils introduits sont construits pour résoudre quelque chose d’important, et qu’ils ne leur sont pas simplement donnés parce que quelqu’un au sommet a vu une démo. L’IA peut conduire à une livraison plus rapide, à des logiciels de meilleure qualité et à moins d’épuisement professionnel, mais seulement lorsqu’elle est appliquée avec précision et soutenue par une appropriation partagée au sein de l’organisation.

Agissez délibérément. Ne jetez pas la technologie aux équipes en espérant un impact. Partez de la base, alignez les équipes et exécutez les éléments qui font évoluer les indicateurs de résultats. Ensuite, passez à l’échelle supérieure. C’est ainsi que l’IA permet d’obtenir un véritable effet de levier dans le domaine de l’ingénierie.

Principaux faits marquants

• Les affirmations relatives à la productivité de l’IA sont exagérées : La plupart des responsables de l’ingénierie (94 %) ne constatent pas de gains de productivité significatifs grâce aux outils de codage de l’IA, malgré le marketing des fournisseurs. Les dirigeants devraient remettre en question les affirmations exagérées et se concentrer sur les mesures de performance internes avant d’adopter l’IA à plus grande échelle.
• Les outils d’IA s’attaquent à des tâches superficielles, mais pas à des problèmes fondamentaux : Alors que l’adoption est élevée pour la génération de code et le remaniement, l’IA a rarement un impact sur des problèmes plus profonds tels que les retards dans les tests ou la communication au sein de l’équipe. Les dirigeants devraient cibler l’IA sur les goulets d’étranglement réels du flux de travail pour obtenir des gains significatifs.
• L’adoption du haut vers le bas risque d’entraîner un désalignement : Le déploiement de l’IA sans l’apport des développeurs conduit souvent à une mauvaise intégration et à des opportunités manquées. Les dirigeants devraient impliquer les équipes d’ingénieurs dès le début pour s’assurer que les outils répondent aux problèmes réels là où ils fonctionnent.
• L’impact nécessite un alignement à l’échelle de l’organisation : Donner aux développeurs des outils d’IA sans flux de travail clairs ou objectifs partagés limite le retour sur investissement. Les initiatives en matière d’IA devraient être liées à des efforts interfonctionnels axés sur la résolution des inefficacités fondamentales avec une validation ascendante.