Insights
Ce que le sommet State of AI SDLC nous apprend sur le passage en prod
94 % ont l'agent, 6 % ont le système. Contexte, décision, coût : ce que le sommet State of AI SDLC d'Atlassian dit du passage de l'IA en prod.
L’adoption de l’IA est faite. Le système qui va avec, non. Et c’est lui (contexte, décision, coût) qui bloque le passage en production.
Le 22 septembre 2026, Atlassian a réuni en ligne des dirigeants et des praticiens autour d’une seule question : comment passer d’un développeur aidé par un agent de code à un cycle de développement vraiment « AI-native », à l’échelle d’une organisation [1].
Six sessions, avec Atlassian, DX, Vercel, Dropbox, Lovable, Honeycomb et 1Password. J’en ai tiré une série de posts LinkedIn. Cet article réunit les quatre premiers, parce qu’ils racontent la même histoire, vue sous quatre angles.
1. 94 % ont l’agent, 6 % ont le système
En ouverture, Mike Cannon-Brookes, CEO d’Atlassian, a posé deux chiffres tirés de la dernière enquête d’Atlassian [2] :
- 94 % des organisations utilisent déjà un agent de code pour des tâches individuelles ;
- seules 6 % des équipes disent disposer des systèmes d’un cycle de développement réellement AI-native.
Les données DX citées dans la même session vont dans le même sens. Chez les clients DX, plus de 90 % des pull requests sont désormais assistées par l’IA. Mais la plupart ne déclarent que 10 à 20 % de gain d’efficacité.
Ce que ça dit
L’adoption n’est plus le sujet. Un développeur outillé n’est pas une organisation outillée.
Cannon-Brookes le résume avec un exemple simple : un agent de revue générique, sans le contexte de l’organisation, produit une revue générique. Pour lui et pour Guillermo Rauch (Vercel), la différence se joue sur la conception de « l’usine » : ce qui entre, le contexte partagé, les skills, et le contrôle qualité en sortie.
Et sur la mesure. Rauch insiste : ce qui compte n’est pas de produire du code, mais de le livrer jusqu’au client.
2. Le code ne représente qu’environ 16 % du travail
Chez Atlassian, 6 000 ingénieurs et plus d’un million de sessions d’agents, Matt Canham et Ming Wu ont partagé un constat qui recadre beaucoup de feuilles de route IA [3] : l’écriture du code ne pèse qu’environ 16 % du travail.
Les 84 % restants se répartissent sur tout le cycle :
- la planification (exigences, alignement) ;
- le travail autour du code (tests instables, builds cassés) ;
- la revue ;
- l’exploitation et le tri des bugs.
D’après les données longitudinales de DX qu’ils citent, le débit plafonne donc autour de 10 % dans la plupart des organisations, alors même que la part de PR assistées approche 100 %.
Trois défaillances systémiques
Atlassian a fait le diagnostic chez elle. L’adoption de l’IA allait plus vite que le changement organisationnel, avec trois défaillances :
- un contexte fragmenté, que les humains copiaient-collaient entre outils et agents ;
- aucune orchestration centrale : pas de routage standard entre agents, pas de points d’approbation, pas d’audit ;
- une friction entre produit, design et ingénierie : au début du programme, seuls 48 % des membres de l’équipe trouvaient que l’IA les accélérait vraiment.
Leur réponse tient en deux piliers, contexte et orchestration. Deux résultats internes l’illustrent. Les agents qui s’appuient sur un contexte connecté donnent des réponses de 44 % meilleure qualité avec 48 % de tokens en moins. Et un relecteur IA aligné sur les standards de l’équipe a réduit de 45 % le temps de cycle des PR.
Leur formule mérite d’être retenue : l’agent est interchangeable, le système d’enregistrement et le contexte ne le sont pas.
Si votre stratégie IA se résume à un agent de code, vous optimisez la plus petite partie du problème.
3. Le nouveau goulot, c’est la décision
La session sur le coût des décisions produit [4] est celle qui m’a le plus parlé, avec mon profil produit.
Tamar Yehoshua, Chief Product and AI Officer d’Atlassian, l’a dit sans détour : quand on construit aussi vite, les PM deviennent le goulot d’étranglement. Il faut choisir quoi construire, et s’assurer que c’est la bonne chose.
Elena Verna, Head of Growth de Lovable, va plus loin. Pour elle, construire n’a jamais été le vrai blocage. Le blocage, c’était la décision : des réunions interminables pour trancher entre des opinions. Et surtout, le coût d’une mauvaise décision s’effondre. On ne débat plus, on prototype, on teste sur le marché, on garde ce qui marche.
Ce qui change dans le métier de PM
- Moins de rédaction, plus de définition. Le travail de « paperasse » recule au profit de la stratégie.
- Les evals deviennent l’outil n°1. Tamar Yehoshua les décrit comme le nouveau meilleur ami du PM, avec des parcours utilisateurs de bout en bout (les « golden journeys » d’Atlassian).
- Un objectif explicite. Sans objectif détaillé, les agents produisent quelque chose de moyen, et personne ne veut d’un logiciel moyen.
- L’impact client avant l’activité. Elena Verna se méfie du nombre de PR ou de tokens consommés. Lovable suit une seule métrique Nord-Star : le nombre quotidien d’applications actives.
Uma Namasivayam (Dropbox) ajoute une piste concrète dans une autre session [5] : avec la capacité libérée, un PM devrait pouvoir produire une idée rapidement et la tester auprès de 10 ou 15 clients, à partir d’un backlog d’expérimentations.
Construire va vite. Décider, moins. C’est là que se joue la valeur.
4. Tokens ×28, innovation +1 %
C’est le chiffre le plus inconfortable du sommet. Selon les données DX présentées par Justin Reock [5], sur la période :
- la dépense en tokens a été multipliée par environ 28 ;
- le débit des équipes a progressé d’environ 25 %, avec une qualité stable ;
- le ratio d’innovation n’a gagné qu’environ 1 %.
Un détail aggrave le tableau : selon DX, cette dépense reste subventionnée, chaque token étant encore vendu sous son coût réel.
Où passe la capacité gagnée ?
Chez Dropbox, Uma Namasivayam l’observe très concrètement : les ingénieurs s’attaquent enfin aux montées de version de paquets et aux migrations Python restées longtemps dans le backlog. D’abord la dette, l’innovation ensuite.
Elle y voit une phase de transition, et je partage cette lecture. Ce n’est pas un échec, c’est une phase. Mais une phase qui peut durer très longtemps si personne ne pilote la dépense.
La « tokenomics » selon Dropbox
Dropbox a créé une pratique de tokenomics en s’appuyant sur son savoir-faire de pilotage des coûts d’infrastructure. La question n’est pas de limiter la dépense, mais de vérifier qu’elle sert les bons problèmes. Concrètement :
- de la visibilité sur la destination des dépenses ;
- des budgets globaux plutôt que des quotas qui brident les équipes ;
- un routage automatique vers le modèle adapté à chaque tâche ;
- un ROI relié au travail : lignes de code, PR et tickets Jira, pour calculer un coût par PR et un impact par ticket.
Nous avons détaillé ces leviers dans AI FinOps : maîtriser les coûts LLM à l’échelle.
Le fil rouge : le système, pas l’outil
Mises bout à bout, les quatre idées dessinent le même diagnostic.
| Constat | Ce qui bloque | Le levier |
|---|---|---|
| 94 % d’adoption, 6 % de maturité | L’organisation | Concevoir l’« usine » : entrées, contexte, contrôle qualité |
| Le code ≈ 16 % du travail | Le contexte et l’orchestration | Relier tickets, specs, code et revue |
| Le PM devient le goulot | La décision | Prototypes, evals, impact client |
| Tokens ×28, innovation +1 % | Le coût non piloté | Visibilité, routage, coût par PR |
Aucun de ces blocages ne se règle en changeant de modèle. Ils se règlent en travaillant le système autour : ce que nous appelons le harness.
Le point de départ recommandé par Dropbox et DX est d’ailleurs peu glamour : cartographier la chaîne de valeur (value stream mapping) et définir les métriques de chaque étape. C’est fastidieux, mais c’est ce qui permet de justifier les investissements.
Position yowe
L’IA ne manque pas aux équipes. Ce qui leur manque, c’est le système qui transforme l’usage individuel en résultat livré : un contexte partagé, des décisions plus rapides que la construction, et une dépense qu’on sait relier à la valeur.
C’est exactement ce passage que nous accompagnons, du prototype qui impressionne en démo au cas d’usage qui tient en production. Nous commençons rarement par le modèle. Nous commençons par la chaîne de valeur, le contexte et la mesure.
Votre équipe est dans les 94 % ou dans les 6 % ? Parlons-en : réserver un créneau · contact@yowe.ai
Sources
- Atlassian, State of AI SDLC, sommet en ligne du 22 septembre 2026, bibliothèque des replays : https://webinars.atlassian.com/series/state-of-ai-sdlc-content-library/landing_page
- Session Context Over Code: The Next Tech Frontier, Mike Cannon-Brookes (Atlassian) et Guillermo Rauch (Vercel). Replay : https://webinars.atlassian.com/recordings/7c489b0685ad
- Session 6K Engineers. 1M Agents. Scaling the AI SDLC at Atlassian., Matt Canham et Ming Wu (Atlassian). Replay : https://webinars.atlassian.com/recordings/fc1111357636
- Session The New Cost of Product Decisions, Tamar Yehoshua (Atlassian) et Elena Verna (Lovable). Replay : https://webinars.atlassian.com/recordings/3c86247427c0
- Session Capacity, Not Horsepower: Rethinking How We Measure AI’s Impact on Engineering, Justin Reock (DX) et Uma Namasivayam (Dropbox). Replay : https://webinars.atlassian.com/recordings/40a722f72334
Les chiffres sont ceux annoncés par les intervenants (enquêtes Atlassian, données DX, mesures internes d’Atlassian et de Dropbox) et n’ont pas été vérifiés de manière indépendante. Les propos des intervenants sont traduits et reformulés à partir des enregistrements en anglais.