Sur le papier, la productivité des développeurs n’a jamais été aussi haute. Les assistants de code écrivent des fonctions entières en quelques secondes, génèrent les tests, résument la documentation et proposent des correctifs avant même qu’on ait fini de lire le message d’erreur. Les directions ont signé les licences Copilot, Cursor ou équivalent, les tableaux de bord d’adoption sont au vert. Et pourtant, dans beaucoup d’équipes, les fonctionnalités n’arrivent pas plus vite chez les utilisateurs.

Le rapport State of Developer Experience 2026 d’Atlassian, publié cette semaine, met des chiffres sur ce malaise. Dans l’article qui accompagne sa sortie, Andrew Boyagi, Head of DevOps Evangelism chez Atlassian, résume le problème en une phrase : l’IA rend les développeurs plus rapides, mais elle expose aussi tout ce qui est cassé dans la livraison logicielle.

Pour un manager, un CTO ou un dirigeant, c’est une excellente nouvelle déguisée. Le goulot d’étranglement n’est pas (ou plus) le clavier du développeur. Il est dans l’organisation. Et ça, ce n’est pas une licence supplémentaire qui va le régler.

Productivité des développeurs et IA : le paradoxe en chiffres

Les données du rapport dessinent un tableau contre-intuitif. L’usage de l’intelligence artificielle explose, la sensation de vitesse aussi, mais le temps réellement gagné recule et la friction ne baisse pas.

Le chiffre le plus frappant est celui du temps gagné. En 2025, 68 % des répondants déclaraient économiser plus de 10 heures par semaine. Un an plus tard, alors que les modèles se sont nettement améliorés, ils ne sont plus que 25 %. Les outils sont meilleurs, et pourtant le gain ressenti fond. La question qu’il faut se poser n’est pas « l’IA fonctionne-t-elle ? », mais « où part le temps que l’IA nous fait gagner ? ».

Pourquoi coder plus vite ne fait pas livrer plus vite

Andrew Boyagi travaille avec l’écurie Atlassian Williams de Formule 1, et il en tire une analogie limpide : améliorer une pièce d’une monoplace ne rend pas forcément la voiture plus rapide. Cela peut même créer de nouvelles contraintes ailleurs et dégrader la performance globale. L’objectif est une voiture plus performante, pas une pièce plus performante.

Dans le développement logiciel, c’est exactement la même mécanique. L’écriture de code n’est qu’une étape d’un flux qui comprend la compréhension du besoin, la conception, la revue de code, les tests, la sécurité, le déploiement, le support. Si vous accélérez uniquement l’étape « coder », vous produisez plus de lignes de code qui viennent s’empiler devant les étapes suivantes. Les revues s’allongent, les files d’attente gonflent, la dette technique grossit et les équipes en aval se noient.

C’est la vieille leçon de la théorie des contraintes d’Eliyahu Goldratt : toute amélioration faite ailleurs qu’au goulot d’étranglement est une illusion. Boyagi raconte d’ailleurs le cas d’un responsable d’ingénierie qui lui demandait comment l’IA pourrait aider son équipe à absorber une charge en forte hausse. En creusant, le problème venait des équipes en amont, qui produisaient beaucoup plus grâce à l’IA. Répondre à ce flot de travail généré par l’IA avec encore plus d’IA aurait simplement déplacé le goulot vers l’équipe suivante.

Où passe vraiment le temps des développeurs ?

Malgré des investissements massifs dans l’IA, le classement des irritants ne bouge presque pas d’une année sur l’autre. En 2026, les cinq premières sources de friction citées par les développeurs sont :

1. Trouver l’information : savoir où est la bonne documentation, quelle décision a été prise, qui détient la connaissance.
2. Les réunions : trop nombreuses, mal préparées, souvent organisées pour « rester alignés » faute d’un système d’information lisible.
3. Le changement de contexte : passer d’un ticket à un incident, puis à une revue, puis à une question sur Slack, et perdre son état de flow à chaque bascule.
4. La dette technique : un code fragile qui ralentit chaque nouvelle fonctionnalité, et que l’IA générative peut aggraver si personne ne prend le temps de relire.
5. Les exigences floues : on code vite, mais on code la mauvaise chose, puis on recommence.

Aucun de ces problèmes ne se règle en tapant plus vite. Ce sont des problèmes de coordination, de clarté et de conception de l’organisation. Boyagi pose la question qu’il adresse depuis des années aux dirigeants tech : quelle part de votre capacité sert à coordonner le travail, par rapport à celle qui sert à faire le travail ?

L’exemple de l’écurie de F1 est parlant : pour un groupe de 150 personnes, l’équipe a économisé plus de 863 heures de réunions à faible valeur ajoutée par mois, sans aucune IA. Simplement en comprenant pourquoi ces réunions existaient et en installant des pratiques qui traitaient la cause. Gérer la friction n’est pas la même chose que la supprimer.

Le piège de l’IA performative : quand l’usage devient un KPI

C’est le résultat que l’auteur juge lui-même le plus inquiétant. Seuls 17 % des développeurs et 23 % des leaders affirment que leur organisation a une stratégie IA clairement communiquée et réellement mise en œuvre. En parallèle, 60 % des développeurs disent que l’usage de l’IA est considéré comme un signal de productivité, et 41 % reconnaissent l’utiliser parfois plus que nécessaire parce qu’ils sentent qu’on l’attend d’eux.

Relisez ces chiffres. Beaucoup d’entreprises n’ont pas défini ce qu’elles veulent obtenir avec l’IA, mais elles mesurent déjà combien leurs équipes l’utilisent. On a vu ce film avec le nombre de story points, le taux d’occupation ou le nombre de commits : c’est la loi de Goodhart. Quand une mesure devient un objectif, elle cesse d’être une bonne mesure.

Les effets de bord sont concrets :

• Un coût inutile : des requêtes et des tokens consommés pour cocher une case, pas pour créer de la valeur.
• Du travail en plus pour les autres : l’équipe amont paraît « productive » pendant que l’équipe aval absorbe un volume de revues, de tests et de corrections qui ralentit tout le système.
• Une perte de confiance : les développeurs savent qu’ils sont observés, et apprennent à jouer avec l’indicateur plutôt qu’à améliorer le produit.

À l’inverse, les développeurs dont l’entreprise a une stratégie IA claire sont deux fois plus susceptibles de ressentir moins de friction qu’avant l’arrivée de l’IA. La différence ne vient pas de l’outil. Elle vient de l’intention : savoir quels problèmes on veut résoudre avec, et lesquels on ne veut pas lui confier.

Développement logiciel : où l’IA booste vraiment les devs

Rien de tout cela ne veut dire que l’IA est inutile. Bien utilisée, elle permet aux développeurs de gagner du temps là où le travail est le moins gratifiant. Les cas où l’IA comme assistant apporte une valeur ajoutée nette sont assez bien identifiés :

• Les tâches répétitives : code d’infrastructure, migrations, squelettes de tests, conversions de formats. L’automatisation de ces tâches libère de l’attention pour les problèmes plus complexes.
• La documentation et la recherche d’information : résumer un module inconnu, retrouver une décision d’architecture, expliquer un vieux programme à un nouvel arrivant. C’est la première source de friction du rapport, donc le meilleur gisement.
• Le débogage : un LLM aide à formuler des hypothèses sur un bug, à lire une trace ou à proposer un test qui reproduit le problème.
• Apprendre plus vite : un dev qui découvre un langage ou un framework progresse plus vite avec un assistant qui explique, à condition de relire et de comprendre ce qu’il accepte.

À l’inverse, l’IA booste peu, voire dégrade, les tâches où le jugement est central : arbitrer une architecture, découper un besoin flou, décider de ce qu’il ne faut pas construire. C’est là que les développeurs seniors restent irremplaçables, et c’est souvent eux qui passent le plus de temps à relire le code généré par les autres. Avoir les bons outils (GitHub Copilot, Cursor ou autres) ne suffit pas : il faut un environnement de travail et un flux de travail qui leur laissent la place de servir les utilisateurs.

Comment mesurer la productivité des développeurs sans se mentir

Si l’adoption n’est pas un bon indicateur, que mesurer ? La réponse tient en une règle : mesurer des résultats, pas de l’activité. Quelques repères éprouvés :

• Les métriques DORA : fréquence de déploiement, délai de mise en production, taux d’échec des changements, temps de restauration. Elles regardent le flux de bout en bout, pas une étape isolée.
• Le framework SPACE (Satisfaction, Performance, Activité, Communication et collaboration, Efficacité et flow) : il rappelle qu’aucun chiffre unique ne résume la productivité, et que le ressenti des devs fait partie des données.
• Le temps d’attente : combien de temps une tâche passe à attendre une revue, une validation, un environnement de test ou une réponse. C’est souvent là que se cache le vrai gisement.
• Le taux de reprise : quelle part du code généré doit être corrigée, réécrite ou supprimée après coup. Avec 65 % des développeurs qui corrigent régulièrement l’IA, ce coût caché mérite d’être visible.
• La valeur livrée : les fonctionnalités réellement utilisées, les irritants clients résolus, les incidents évités.

Pour les managers, la bonne question n’est donc pas « combien de code avons-nous produit grâce à l’IA ? » mais « les tâches qui comptent avancent-elles plus vite, avec moins d’efforts gaspillés ? ». Une ligne de code générée en trois secondes peut coûter des heures de relecture et de maintenance sur tout son cycle de vie.

Le nombre de lignes de code, lui, reste ce qu’il a toujours été : un indicateur trompeur. Avec l’IA, il devient même dangereux, car produire du code n’a jamais coûté aussi peu, alors que le maintenir coûte toujours aussi cher.

Questions fréquentes sur la productivité des développeurs et l’IA

En résumé

L’IA générative tient une partie de ses promesses : les développeurs codent plus vite. Mais la productivité d’une équipe logicielle ne se joue pas au clavier. Elle se joue dans la clarté des priorités, la circulation de l’information, la qualité des revues et la capacité de l’organisation à absorber ce qui est produit. Tant que ces fondamentaux restent cassés, chaque gain de vitesse en amont se transforme en embouteillage en aval.

Le rapport Atlassian envoie un message simple aux leaders : soyez délibérés sur les problèmes que vous confiez à l’IA, et mesurez les résultats, pas l’activité. Le reste est du théâtre.

Vous voulez identifier les vrais goulots d’étranglement de vos équipes tech et bâtir une stratégie IA qui tienne debout ? Réservez un appel stratégique avec Corporate Mavericks.