Agile, Scrum, Shape Up face à l'IA : ce qui change vraiment, PM Pathfinder

Le rituel du lundi matin dont on peut réinterroger l'utilité

Neuf heures du matin. L'équipe ouvre Zoom. Quelqu'un partage un tableau Jira. Chacun récite : « Hier j'ai travaillé sur le ticket #4521, aujourd'hui pareil, pas de bloqueur. » Quinze minutes plus tard, personne n'a pris de décision, aucun plan n'a changé. Les mêmes bloqueurs de la semaine dernière sont toujours là.

Ce n'est pas l'IA qui a vidé ce daily stand-up de son sens. Il l'avait perdu bien avant.

Mais c'est l'IA qui l'a mis en évidence d'une façon difficile à ignorer. Quand un agent peut lire en temps réel chaque commit Git, chaque ticket Jira et chaque conversation Slack pour détecter les blocages avant que l'équipe ne se lève le matin [1], la question se pose de façon directe mais posée : à quoi sert encore cette réunion ?

C'est le point de départ de cet article. Non pas « l'IA va-t-elle remplacer le PM ? », débat téléologique qui tourne en rond depuis deux ans, mais une question plus inconfortable : les méthodologies de delivery sur lesquelles repose le Product Management depuis vingt ans résistent-elles à l'accélération de l'IA ?

Scrum : de la libération à la bureaucratie

En 2001, le Manifeste Agile naît d'une frustration précise. Les équipes software étouffaient sous des processus waterfall rigides, des spécifications de 200 pages et des cycles de livraison de dix-huit mois. Scrum promettait la liberté : des sprints courts, des équipes autonomes, une adaptation constante au réel.

Vingt ans plus tard, le constat invite à la nuance. Dans bien des contextes, la promesse s'est éloignée de son intention initiale. McKinsey, dans ses analyses de transformations agiles sur plus de 800 organisations, observe que seuls 31 % parviennent à des transformations « hautement réussies » [2]. Ce qui était censé libérer les équipes est devenu, dans un grand nombre de contextes, une nouvelle couche de bureaucratie.

Les symptômes sont documentés et reconnus par les praticiens eux-mêmes [3] :

Les story points, conçus pour mesurer l'effort, sont devenus une arme de mesure de la productivité individuelle. Les équipes apprennent à les gonfler pour « paraître » productives.
Le backlog, conçu pour être vivant et priorisé, se transforme en cimetière de fonctionnalités : des centaines de tickets qu'on ne supprimera jamais « au cas où ».
Les sprints de deux semaines créent un rythme frénétique qui laisse peu de place à la pensée stratégique. On court après le prochain train avant même d'avoir compris où on va.
Les cérémonies s'accumulent. Planning, daily, review, retrospective, backlog grooming : dans certaines équipes, jusqu'à une journée entière par semaine passe en réunions Scrum [3].

Mon point de vue : Ce qu'on formule rarement à voix haute dans les organisations : Scrum a souvent été détourné par le management intermédiaire comme outil de reporting et de contrôle. Le daily stand-up glisse alors vers un reporting quotidien plus que vers de la collaboration. La vélocité, utilisée comme KPI, peut décourager l'honnêteté. Au fond, ce n'est pas tant un problème d'outil qu'un enjeu d'organisation et de pouvoir.

L'entrée de l'IA : accélérateur ou révélateur ?

L'industrie présente l'IA comme un accélérateur de productivité. Les chiffres sont effectivement frappants : selon une étude Harness auprès de 900 ingénieurs et responsables techniques conduite en août 2025, 63 % des organisations déclarent shipper du code en production plus fréquemment depuis l'adoption des outils d'IA [4].

Mais le même rapport introduit un concept qui mérite l'attention de tout PM qui structure encore son roadmap autour de sprints : l'AI Velocity Paradox.

Le paradoxe est le suivant : l'IA accélère massivement la production de code (51 % des workflows de coding sont automatisés), mais les processus en aval, tests, sécurité, déploiement, compliance, n'ont pas suivi. Résultat : 45 % des déploiements impliquant du code généré par IA introduisent des problèmes en production. Et 72 % des organisations ont déjà subi au moins un incident de production directement causé par du code généré par IA [4].

Traduction pour le PM : l'IA ne fait pas que produire du code plus vite. Elle inonde le pipeline de delivery avec un flux de code que les équipes QA, ops et sécurité ne peuvent pas absorber au rythme des sprints actuels. Le sprint de deux semaines, déjà sous tension, devient un goulot d'étranglement supplémentaire.

La recherche empirique complique encore le tableau. En juillet 2025, METR (Model Evaluation & Threat Research) publie une étude en conditions contrôlées, un essai randomisé avec 16 développeurs expérimentés sur leurs propres projets open-source. Résultat contre-intuitif : lorsque les développeurs utilisent des outils d'IA, ils prennent 19 % de temps supplémentaire pour compléter leurs tâches par rapport à quand ils n'en utilisent pas [5]. Plus frappant encore : les développeurs eux-mêmes estimaient être accélérés de 20 %, un écart de 40 points entre la perception et la réalité.

Cette étude a depuis été nuancée par METR elle-même en février 2026 [6] : les données plus récentes (fin 2025) suggèrent probable une accélération, mais les effets de sélection dans l'échantillon empêchent de conclure avec certitude. Ce que l'on sait avec certitude : la relation entre IA et productivité développeur est complexe, contextuelle, et résiste aux généralisations enthousiastes.

Mon point de vue : Ce que cette recherche METR révèle va au-delà de la productivité individuelle. Elle pointe vers un phénomène organisationnel : l'IA génère de la vitesse brute, mais la vitesse brute sans structure d'apprentissage crée de la dette, technique, décisionnelle, méthodologique. C'est exactement ce que j'appelle la dette méthodologique : adopter des outils IA sur des processus Scrum non réformés, c'est injecter du carburant dans un moteur grippé.

Shape Up : une méthodologie qui apporte des réponses pertinentes

En 2019, Ryan Singer, alors responsable stratégie produit chez Basecamp, publie Shape Up : Stop Running in Circles and Ship Work that Matters [7]. Le livre est disponible gratuitement en ligne. Son adoption est restée confidentielle pendant quelques années. Depuis 2024-2025, on assiste à une accélération notable de l'intérêt des équipes produit pour cette approche [8].

Shape Up repose sur quelques principes radicalement différents de Scrum :

Cycles de six semaines, pas de sprints de deux semaines. Six semaines, c'est « assez long pour livrer quelque chose de significatif, assez court pour sentir la deadline dès le début », explique Singer [7]. La durée n'est pas arbitraire : elle force une vraie priorisation.

L'appétit, pas l'estimation. Au lieu de demander « combien de temps ça prend ? », Shape Up demande « combien de temps ça vaut ? » Si une fonctionnalité vaut six semaines d'effort, on shape une version de cette fonctionnalité qui tient dans six semaines, quitte à couper du scope. C'est l'inverse exact du backlog infini de Scrum.

Pas de backlog. Shape Up supprime le backlog. Les idées qui ne sont pas sélectionnées à la « betting table » disparaissent. Si elles reviennent, c'est qu'elles étaient vraiment importantes. Si elles ne reviennent pas, le problème n'était pas réel.

Le circuit breaker. Si un projet ne livre pas dans un cycle, il ne s'étend pas automatiquement, il est annulé par défaut. Cette règle oblige à de vraies décisions plutôt qu'à des prolongations indéfinies.

Des équipes comme Process Street rapportent avoir réduit leur time-to-ship d'une feature de 6 mois à 6 semaines après l'adoption de Shape Up [8]. Alex Debecker, fondateur tech, documente dans Mind the Product son expérience de passage de Scrum à Shape Up : « Nous étions toujours en retard, cramant des tickets dans des sprints courts qui débordaient inévitablement, épuisés, et après tout cet effort, ne shippant pas grand-chose de substantiel » [9]. Sa conclusion après plusieurs cycles : l'équipe a livré plus en se concentrant sur moins.

GitHub, Shopify et Buildkite font partie des entreprises qui ont adopté ou expérimenté des éléments de Shape Up dans leur workflow [8].

Les rituels qui perdent leur sens face à l'IA

Revenons aux cérémonies Scrum à l'épreuve de l'IA.

Le daily stand-up. Sa raison d'être originelle : inspecter l'avancement vers l'objectif du sprint et adapter le plan pour les 24 heures à venir. Ce qu'il est devenu dans la majorité des équipes : un reporting de statut ticket par ticket, orienté vers le Scrum Master plutôt que vers l'équipe, sans adaptation réelle. Target Agility documente ce glissement avec précision : les mêmes bloqueurs répétés d'un jour sur l'autre, des décisions reportées « après l'appel » [1]. Quand une IA peut monitorer Git, Jira et le CI/CD en continu et détecter les risques de sprint avant que l'équipe se lève, la question est légitime : si la seule valeur du daily est la « visibilité », l'IA vient de le rendre redondant.

Les story points et l'estimation. L'IA génère du code. Elle génère aussi des tests, de la documentation, des spécifications. La notion de vélocité en points, calibrée sur le rythme humain, perd son étalon de référence quand une partie du code est co-produite par des agents.

La sprint review. Présentée comme un moment de feedback avec les stakeholders, elle est souvent réduite à une démo en interne. Dans un monde où le CI/CD permet le déploiement continu et où les feature flags permettent des rollouts progressifs, l'idée de « montrer ce qu'on a fait en deux semaines » toutes les deux semaines mérite d'être questionnée.

Ce qui résiste, en revanche ? Les principes de feedback loops, d'inspection et d'adaptation, le cœur de l'agilité. David Sabine, sur Scrum.org, le formule bien : « L'IA recâble les équipes Scrum, mais pas Scrum » [10]. Les guardrails empiriques de Scrum, transparence, inspection, adaptation, deviennent plus importants, pas moins, quand l'IA amplifie la capacité de production. La vitesse sans feedback est la recette de la catastrophe à grande échelle.

La vraie tension : vitesse vs apprentissage

Au fond, ce débat sur les méthodologies révèle une tension structurelle que l'IA rend aiguë.

Scrum a été conçu pour l'apprentissage : des boucles courtes pour échouer vite et corriger. Mais dans la pratique, les sprints ont souvent été pilotés par la vitesse de livraison, pas par la qualité de l'apprentissage. L'apprentissage a été sacrifié sur l'autel de la vélocité.

Shape Up inverse la proposition : il ralentit délibérément le rythme (six semaines vs deux) pour approfondir la réflexion en amont, le « shaping », et livrer quelque chose de véritablement fini. La qualité du problème posé compte autant que la vitesse de la réponse.

L'IA pousse dans les deux directions simultanément. Elle accélère le code (potentiellement). Elle devrait aussi, si on l'utilise intelligemment, améliorer la qualité du shaping, en synthétisant la recherche utilisateur, en simulant des scénarios, en identifiant les risques cachés d'un pitch. Mais si on l'utilise seulement pour aller plus vite dans des sprints Scrum inchangés, on obtient la combinaison la plus dangereuse : plus de code mal spécifié, shipper plus vite vers la production, avec moins de temps pour apprendre des erreurs.

L'étude Harness est éclairante sur ce point : seulement 6 % des organisations ont un pipeline de déploiement continu pleinement automatisé [4]. Pour les autres, l'IA crée simplement une pression accrue en aval, là où les processus restent manuels et fragiles.

Mon point de vue : La vraie question pour un PM en 2026 n'est pas « Scrum ou Shape Up ? » C'est : mon organisation a-t-elle la maturité processuelle pour absorber l'accélération que l'IA promet ? Si la réponse est non, et c'est le cas pour la grande majorité des startups et scaleups, alors adopter des outils IA sur une base méthodologique non réformée, c'est choisir la dette méthodologique. Les outils changent vite. Les organisations, lentement. La méthode est le pont. Sans refonte de la méthode, il n'y a pas de pont.

Ce qu'il faut retenir

L'IA ne rend pas Scrum obsolète par magie. Elle révèle ce qui était déjà dysfonctionnel. Les équipes qui avaient de bons rituels, des dailys où des décisions sont prises, des sprints guidés par un objectif clair, une vélocité utilisée comme signal et non comme arme, ne sont pas menacées par l'IA. Elles vont en bénéficier.

Les autres, celles dont les cérémonies Scrum sont devenues des rituels dont l'utilité mérite d'être réinterrogée, dont le backlog s'est transformé en cimetière de tickets, dont les story points servent surtout à rassurer la direction, auront un choix à poser : réformer la méthode, ou laisser l'IA amplifier ces points de friction à grande vitesse.

Shape Up n'est pas la solution universelle. C'est une méthodologie exigeante, qui demande une vraie compétence de shaping en amont et une discipline organisationnelle que peu d'équipes ont d'emblée [9]. Mais ses principes, appétit plutôt qu'estimation, problème shapé avant exécution, scope variable dans un temps fixe, sont des réponses pertinentes aux pressions que l'IA fait peser sur les cycles de delivery.

La bonne méthodologie en 2026 n'est pas celle qui est à la mode. C'est celle qui permet à votre équipe de rester en boucle d'apprentissage réelle, même quand les outils s'emballent.

Sources

Daily Scrum Is Dead. AI Just Proved It., Target Agility (déc. 2025), Étaie l'obsolescence des dailys Scrum comme rituels de visibilité et leur remplacement par l'alignement continu via IA.
Enterprise agility: Measuring the business impact, McKinsey & Company, Étaie le taux de succès limité (31 % « hautement réussies ») des transformations agiles sur un échantillon de 838 organisations.
The Death of Agile: Why Big Tech Is Ditching Scrum and What They Use Instead, Ibrahim Irfan, Medium (juil. 2025), Documente les critiques praticiennes de Scrum (réunions, story points, scalabilité) et les alternatives adoptées.
The State of AI in Software Engineering, The AI Velocity Paradox, Harness / Coleman Parkes, 900 répondants (août 2025), Source des statistiques clés : 63 % shippent plus vite, 45 % des déploiements IA causent des problèmes, 6 % de CD pleinement automatisé, 72 % d'incidents de production liés à l'IA.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR (juil. 2025), Essai randomisé contrôlé avec 16 développeurs : +19 % de temps avec IA vs sans IA, écart perception/réalité de 40 points.
We are Changing our Developer Productivity Experiment Design, METR (fév. 2026), Mise à jour nuançant les résultats de l'étude précédente : effets de sélection importants, probable accélération nette en fin 2025, mais non mesurable avec certitude.
Shape Up: Stop Running in Circles and Ship Work that Matters, Ryan Singer / Basecamp (2019, disponible gratuitement en ligne), Source primaire pour les principes de Shape Up : cycles 6 semaines, appétit, betting table, circuit breaker.
Shape Up vs Scrum: Is the Shape Up Method the Future of Product Development?, Project Manager Template, Comparatif et exemples d'adoption (Buildkite, GitHub, Process Street).
7 lessons from trialling Basecamp's 'Shape Up' methodology, Alex Debecker / Mind the Product (avr. 2024), Retour d'expérience praticien sur l'implémentation de Shape Up, limites et apprentissages.
AI Is Rewiring Scrum Teams, But Not Scrum, David Sabine / Scrum.org, Position institutionnelle de Scrum.org : les guardrails empiriques de Scrum restent pertinents face à l'IA, ce sont les cérémonies mal appliquées qui posent problème.