Les projets logiciels sont en retard parce que le code n'a jamais été le goulot d'étranglement. Les développeurs passent environ 16 % de leur semaine à écrire du code. Les 84 % restants partent en recherche d'informations, en attente de décisions et en bascules entre outils. L'IA accélère les 16 %. Le retard vit dans les 84 % — et presque personne n'a pointé un outil dessus.
Soixante-huit pour cent des développeurs disent que l'IA leur fait gagner plus de dix heures par semaine.
Cinquante pour cent disent en perdre plus de dix par semaine à cause de la friction organisationnelle.
Même enquête. Même année. Mêmes 3 500 développeurs dans six pays. Atlassian a publié les deux chiffres dans son rapport State of Developer Experience 2025 et en a tiré la seule conclusion disponible : « nous sommes revenus exactement au point de départ ».
Une journée de travail complète, offerte à vos ingénieurs par une machine — et discrètement récupérée par votre propre entreprise avant vendredi.
Si vous avez validé un budget d'outillage IA l'an dernier et que vos dates de sortie n'ont pas bougé depuis, voilà pourquoi. Pas parce que les outils ont sous-livré. Ils ont livré exactement ce qu'ils annonçaient. Ils l'ont livré dans un système qui n'a jamais été limité par la vitesse de frappe.
Pourquoi l'IA ne rend-elle pas les projets plus rapides ?
Demandez à un directeur financier ce que fait un ingénieur logiciel toute la journée : il écrit du code. Demandez à un VP Engineering : vous obtiendrez quelque chose de plus sophistiqué avec la même arithmétique en dessous — la capacité se compte en jours-développeur, et les jours-développeur sont supposés être des jours de construction.
Ils ne le sont pas. Le rapport 2025 d'Atlassian situe le codage à 16 % de la semaine de travail d'un développeur — un chiffre tiré d'un IDC Survey Spotlight publié en février 2025. Six heures et demie sur quarante. Les trente-trois heures et demie restantes vont tout à fait ailleurs : traquer la doc d'API qui était juste en mars, attendre que quelqu'un à trois fuseaux horaires confirme si un champ est nullable, assister au standup qui existe parce que celui de la semaine dernière n'a rien résolu.
Maintenant, lâchez un assistant de codage IA dans cette semaine. C'est un bon outil. Supposez — sans preuve, par pure générosité — qu'il rende la partie codage trente pour cent plus rapide.
Trente pour cent de 16 %, c'est moins de 5 % de la semaine. Deux heures.
Vous n'avez pas acheté un projet plus rapide. Vous avez acheté un mardi après-midi.
Rien de tout cela n'a surpris Atlassian. Leur responsable de l'évangélisation DevOps avait fait l'argument un an plus tôt — en signalant à l'époque que c'était controversé : un assistant de codage peut améliorer le ressenti de la journée d'un développeur sans que l'organisation livre plus vite. Le codage n'a jamais été la friction. Affûter le seul outil qui n'était pas émoussé ne fait rien pour celui qui l'est. Douze mois et 3 500 répondants plus tard, les chiffres de 2025 ont clos le débat en sa faveur.
Le paradoxe de la productivité des développeurs, c'est ce qui arrive quand les ingénieurs individuels deviennent mesurablement plus rapides et que l'organisation qui livre le logiciel ne l'est pas. Ce n'est pas un mystère. C'est un ratio.
| Part de la semaine du développeur | Ce qu'un outil de codage IA en fait | |
|---|---|---|
| Écrire du code | 16 % | L'accélère, substantiellement |
| Tout le reste — trouver l'information, s'adapter aux nouvelles technologies, changer de contexte, coordonner entre équipes, attendre des décisions | 84 % | Essentiellement rien |
L'IA vise 16 % du problème. Sources : IDC Survey Spotlight (fév. 2025) ; Atlassian State of DevEx 2025.
Et pendant que vous achetiez ce mardi après-midi, le goulot a déménagé. La dette technique — la ligne présente sur toutes les feuilles de route d'ingénierie jamais écrites — est sortie du top cinq des sources de friction d'Atlassian en 2025. La collaboration inter-équipes a grimpé. La plupart des organisations financent encore le goulot de l'an dernier avec le budget de cette année — puis mesurent le résultat en story points.
Il y a un résultat plus discret dans le même rapport, qui devrait vous déranger davantage que tous les chiffres de une.
Atlassian a demandé aux développeurs ce qu'ils font réellement du temps que l'IA leur rend. La réponse : améliorer la qualité du code, construire de nouvelles fonctionnalités, écrire de la documentation.
Relisez cette liste. Presque tout y siège dans les 16 %.
Le dividende de la partie codage est réinvesti, quasi intégralement, dans la partie codage. Non que les ingénieurs manquent de vision. C'est la seule partie de la semaine qu'on leur permet de toucher. La documentation est le seul élément de la liste qui atteigne les 84 % — et c'est la première chose coupée quand le sprint se resserre.
Vous avez donc donné dix heures par semaine à votre équipe, et elle les a dépensées sur le sixième du métier qui fonctionnait déjà. Elle a eu raison. Personne ne lui a donné la permission de les dépenser ailleurs.
Où va vraiment le temps ?
Avant la liste, un chiffre qui compte plus que les cinquante pour cent : quatre-vingt-dix pour cent des développeurs perdent au moins six heures par semaine à cela. Six heures, c'est presque une journée. Ce n'est donc pas une frange d'entreprises mal gérées dont vous pouvez confortablement vous exclure. C'est la distribution. Si votre entreprise est normale, elle est dans ces données.
Le top trois d'Atlassian, dans l'ordre : trouver l'information. S'adapter aux nouvelles technologies. Changer de contexte entre outils.
Relisez-les. Aucun n'est un problème de code. Chacun est un problème de localisation du savoir. L'information existe. Quelqu'un chez vous l'a. Elle est presque certainement écrite quelque part. Votre développeur ne peut simplement pas la trouver dans les dix-neuf minutes qu'il a avant le prochain call.
Voici un mardi.
Un développeur doit savoir si le webhook de paiement réessaie sur un 500. La réponse existe. Elle est dans un fil Slack d'il y a quatorze mois, dans un canal archivé pendant une réorg, écrite par quelqu'un parti en avril. Alors le développeur fait la chose rationnelle : il demande dans le canal d'équipe, n'obtient rien pendant quatre heures — et commence autre chose en attendant.
Cette tâche n'a pas coûté quatre heures. Elle a coûté quatre heures plus un changement de contexte — et le changement a coûté plus cher que la question. Multipliez sur chaque développeur, chaque jour, un trimestre entier. Voilà votre date de livraison.
Et remarquez quelle friction a grimpé dans la liste d'Atlassian l'année même où la dette technique en sortait : la collaboration avec les autres équipes.
Celle-là compte, parce que c'est la seule catégorie de la liste qu'un développeur ne peut pas toucher. Un ingénieur peut refactorer un mauvais module de sa propre initiative un vendredi calme. Il ne peut pas faire prioriser le changement d'API par l'équipe plateforme. Il ne peut pas avancer la validation conformité. Il ne peut pas arracher une décision à une réunion reportée trois fois. La friction qui grandit le plus vite est précisément celle qui siège au-dessus de son niveau — c'est-à-dire au vôtre.
Comment répare-t-on vraiment un projet en retard ?
Rien de tout cela n'exige d'embaucher. Cela exige de regarder une partie de la semaine que vous n'avez jamais mesurée.
-
Mesurez l'attente, pas le travail. Vous suivez déjà les story points, la vélocité, le cycle time. Tous mesurent les 16 %. Commencez plutôt à consigner un chiffre : les heures entre le moment où un développeur est bloqué et celui où il est débloqué. Il ne vous plaira pas. C'est le but — on ne discute pas un chiffre qu'on a collecté soi-même.
-
Donnez à chaque question bloquante un humain nommé et une horloge. Pas un canal. Pas un comité. Une personne, avec un délai maximal de réponse convenu. La plupart des attentes de quatre heures ne sont pas des attentes de décision. Ce sont des attentes que quelqu'un remarque qu'une décision était nécessaire.
-
Écrivez la réponse là où la prochaine personne trébuchera dessus. La réponse sur le webhook resservira en novembre. Si elle vit dans une réponse Slack, elle est perdue. Mettez-la à côté du code — un journal de décisions dans le dépôt, un commentaire sur l'endpoint. La règle n'est pas « tout documenter ». C'est : « quand une question coûte quatre heures, sa réponse reçoit une adresse permanente ».
-
Pointez l'IA sur les 84 %. Vous possédez déjà les outils. Tournez-les vers la partie de la semaine qui saigne vraiment — chercher dans la doc interne, résumer le fil, rédiger la spec que personne n'a le temps d'écrire. Les agents IA visant les flux internes manquent de glamour à côté d'un assistant de codage — et ils touchent cinq fois plus de la semaine. Le cadrage d'Atlassian lui-même : l'IA améliore l'expérience développeur quand elle vise de vrais points de friction — pas la seule tâche qui n'en a jamais été un.
-
Demandez à vos développeurs. Vraiment. L'étape un d'Atlassian — et c'est l'étape un parce qu'elle est gratuite. Les gens qui perdent les dix heures peuvent vous dire exactement où elles partent. Personne ne le leur a demandé.
La partie inconfortable
Soixante-trois pour cent des développeurs disent désormais que leurs dirigeants ne comprennent pas leurs difficultés. L'an dernier, c'était 44 %.
Dix-neuf points en douze mois. Les mêmes douze mois où l'adoption de l'IA est devenue quasi universelle et où les gains de temps déclarés ont bondi.
Ce n'est pas une coïncidence, et la lecture d'Atlassian est brutale : les dirigeants empochent les économies de l'IA et laissent la friction exactement où elle était. L'ingénieur reçoit l'outil. Obtient le gain. Le regarde s'écouler dans la même file où il s'est toujours écoulé. Puis on lui demande pourquoi la date a bougé.
Selon les chiffres du rapport, une organisation de 500 développeurs y perd quelque chose comme 7,9 M$ par an — un chiffre modélisé plutôt que mesuré, mais le modèle n'est pas généreux.
L'outillage s'achète parce que l'outillage est achetable. On peut l'approuver un mardi et l'annoncer un mercredi. Réparer qui possède une décision, ou tuer l'attente de quatre heures sur un champ nullable, signifie changer la façon dont votre entreprise fonctionne. Aucun vendeur ne vend ça. Aucune facture n'arrive. Personne n'écrit de communiqué de presse dessus.
Alors l'argent va là où la facture peut aller.
Commencez par la question, pas par l'outil
Vos ingénieurs savent déjà où va le temps. Ils le savent depuis des années. L'enquête n'a rien découvert qu'ils n'auraient pu vous dire autour d'un café — et 63 % d'entre eux disent de toute façon que leurs dirigeants ne le comprennent pas.
Alors demandez. Pas la feuille de route. La dernière chose qui les a fait attendre, assis.
Réparez cette seule chose. Puis regardez ce que ça fait à la date.
Questions fréquentes
Pourquoi les projets logiciels sont-ils encore en retard si l'IA écrit le code ?
Parce qu'écrire du code n'est que 16 % de la semaine d'un développeur. Les 84 % restants partent en recherche d'informations, en attente de décisions et en bascules entre outils. L'IA accélère la partie codage — qui n'a jamais été la contrainte. Le retard siège dans les 84 %, intact.
L'IA améliore-t-elle vraiment la productivité des développeurs ?
Oui, individuellement. Dans l'enquête 2025 d'Atlassian auprès de 3 500 développeurs, 99 % rapportent un gain de temps et 68 % plus de 10 heures par semaine. Mais 50 % en perdent aussi plus de 10 par semaine en friction organisationnelle — le gain atteint donc rarement la date de livraison.
Quelle est la plus grande cause de retard des projets en 2026 ?
La friction organisationnelle, pas la capacité d'ingénierie. Les données 2025 d'Atlassian classent en tête : trouver l'information, s'adapter aux nouvelles technologies, changer de contexte entre outils. Fait notable : la dette technique est sortie du top cinq — le goulot a déménagé, la plupart des budgets non.
Combien l'inefficacité des développeurs coûte-t-elle à une entreprise ?
Le rapport 2025 d'Atlassian modélise, pour une organisation de 500 développeurs, environ 7,9 M$ de pertes annuelles dues à l'inefficacité organisationnelle — sur la base d'environ 10 heures perdues par développeur et par semaine. Une estimation modélisée, pas une mesure — mais aux hypothèses prudentes.
Le remède n'est pas un outil, c'est la façon de conduire le travail — c'est pourquoi notre pratique de delivery livre à périmètre et prix fixes. Si votre projet en cours dérive, un second avis ne coûte rien.
