Pendant des années, on a jugé la qualité d’un backlog produit à son épaisseur. Des centaines de user stories bien rédigées, des critères d’acceptation partout, une roadmap découpée jusqu’à la fin de l’année : ça rassurait le management et ça donnait l’illusion de maîtriser l’avenir. Puis l’IA générative est arrivée. Aujourd’hui, un product owner peut produire cinquante user stories propres en une après-midi, et un agent de code peut les implémenter à la chaîne. Question légitime : à quoi sert encore un backlog ?

Mike Cohn, l’un des auteurs de référence sur Scrum et les user stories, vient de publier sur Mountain Goat Software une réflexion qui remet les pendules à l’heure : AI Changes What Makes a Product Backlog Valuable. Sa thèse tient en une phrase : l’IA aide les équipes à construire plus vite, elle ne décide pas de ce qui vaut la peine d’être construit. On a lu, on a digéré, et voici la version Corporate Mavericks, sans bullshit et avec ce que vous pouvez changer dès votre prochain sprint.

Qu’est-ce qu’un backlog produit (et ce qu’il n’a jamais été)

Un backlog produit, c’est la liste ordonnée de tout ce que l’équipe pourrait faire pour faire avancer un produit : nouvelles fonctionnalités, corrections, améliorations, expériences, tâches techniques. Dans le framework Scrum, le product backlog est placé sous la responsabilité du product owner, qui l’ordonne en fonction de la valeur et du product goal. L’équipe de développement y pioche, à chaque sprint planning, les éléments du backlog qui formeront le backlog de sprint.

Jusque là, rien de neuf. Le problème, c’est la confusion qui s’est installée dans beaucoup d’organisations entre deux choses très différentes :

• Un inventaire : un stock de travail futur, détaillé longtemps à l’avance, dont la taille prouve qu’on « sait où on va ».
• Un outil de décision : la meilleure pensée actuelle de l’équipe sur ce qu’il faut construire ensuite, et pourquoi.

Comme le rappelle Cohn, un backlog n’a jamais tiré sa valeur de sa taille. L’idée d’un gros inventaire détaillé était déjà un mythe avant l’IA. Simplement, quand le détail se génère en quelques secondes, ce mythe devient impossible à défendre. En revanche, la valeur du backlog comme trace de décisions produit réfléchies, et comme liste des prochaines choses à apprendre, augmente.

Le piège : transformer un backlog en file d’attente pour occuper l’IA

Les organisations ont toujours eu la tentation de traiter le backlog comme une file d’attente dont la mission est d’occuper les développeurs. Quelqu’un a fini ? Hop, ticket suivant. Le sprint se vide ? On remplit. Cette logique de taux d’occupation est l’un des plus vieux anti-patterns de la gestion de projet, agile ou pas.

L’IA pousse ce travers jusqu’à la caricature. Un agent de code termine une tâche en vingt minutes, on lui donne la suivante, puis encore la suivante. Et quand le backlog commence à s’épuiser ? Pas de souci : l’IA génère elle-même une douzaine de nouvelles user stories plausibles pour que la machine ne s’arrête jamais. On obtient une usine à fonctionnalités parfaitement huilée, qui produit énormément de logiciel. Et pas forcément un produit qui marche.

Parce que le but du développement produit n’a jamais été de maximiser la production de fonctionnalités. Le but, c’est de résoudre des problèmes qui comptent, d’apprendre des utilisateurs et de prendre de bonnes décisions sur la suite. Si votre product backlog ne sert plus ces décisions, ce n’est plus un outil agile : c’est un tapis roulant. On en parlait déjà dans notre article sur le slop IA et le travail plus rapide mais pas meilleur : la vitesse sans discernement produit surtout du volume.

Conduire de nuit : un backlog doit voir assez loin, pas jusqu’au bout

Mike Cohn reprend une image du romancier E.L. Doctorow, qui comparait l’écriture d’un roman à la conduite de nuit : on ne voit que jusqu’où portent les phares, mais on peut faire tout le trajet comme ça. Appliqué au produit, c’est limpide. Un backlog doit permettre de voir assez loin devant. Il n’a pas besoin d’éclairer toute la route jusqu’à la sortie du produit, encore moins jusqu’à sa fin de vie.

Concrètement, les éléments proches de l’implémentation doivent être assez clairs pour que l’équipe puisse en discuter, les estimer et les construire. Les éléments plus lointains peuvent rester gros et flous. À mesure que les priorités bougent et que l’équipe apprend, ces éléments sont affinés, remplacés ou supprimés. C’est le principe du backlog refinement « juste à temps, juste assez ».

L’IA rend cette approche progressive encore plus pertinente. Si l’équipe peut générer en quelques minutes des exemples, des critères d’acceptation et des découpages possibles, elle n’a plus aucune raison d’investir lourdement dans du détail qui sera obsolète avant d’être utilisé. La capacité à produire du détail à bas coût n’est pas un argument pour en mettre partout. C’est un argument pour en ajouter au moment où il devient utile.

Quand faut-il allumer les pleins phares ?

Toutes les équipes n’ont pas besoin de voir aussi loin. Une équipe lente peut se contenter de cinq ou dix éléments clairs, qui l’occuperont des mois. Une équipe rapide (et l’IA rend beaucoup d’équipes plus rapides) a besoin de davantage de travail prêt pour ne pas rattraper son backlog. Les dépendances jouent aussi. Il vous faut un horizon plus long quand votre travail implique :

• du matériel physique ou de la fabrication ;
• une validation réglementaire, une revue sécurité ou juridique ;
• de la formation utilisateurs, du marketing ou une préparation commerciale ;
• des fournisseurs, des partenaires externes ou d’autres équipes ;
• une migration de données ou des experts rares ;
• des décisions coûteuses et difficiles à défaire.

Cohn cite l’exemple d’équipes qui développaient une calculatrice scientifique programmable, avec son matériel et ses applications web, iOS et Android, toutes soumises à une stricte parité fonctionnelle. Ces équipes avaient besoin de phares plus puissants, parce que plusieurs produits devaient converger vers la même release. Mais même elles n’avaient pas besoin de décrire en détail toutes les stories possibles. L’horizon de planification dépend de la vitesse de livraison, de l’incertitude, du risque et des dépendances. Jamais de l’envie de faire paraître le backlog « complet ».

User stories : l’IA permet-elle enfin des stories plus grosses ?

Depuis vingt ans, on répète aux équipes agiles de découper leurs user stories toujours plus finement, pour les terminer vite et obtenir du feedback tôt. Le conseil reste valable, mais l’IA y ajoute une nuance importante. Si une équipe peut désormais terminer en deux jours une fonctionnalité qui lui prenait deux semaines, faut-il encore la découper juste pour respecter une vieille norme sur la taille « normale » d’une story ?

Pas forcément. Ce qui compte, ce n’est pas une définition abstraite de « petit », c’est le temps écoulé et le risque. Une story plus grosse peut se justifier quand :

• le résultat attendu est bien compris ;
• l’équipe dispose de preuves solides que les utilisateurs en ont besoin ;
• l’implémentation reste rapide ;
• les utilisateurs peuvent la valider peu après sa livraison ;
• le coût d’une erreur reste acceptable.

À l’inverse, dès que le besoin, la solution ou le résultat attendu restent incertains, une story plus petite ou une expérience préalable reste le choix le plus sage. L’IA change la quantité de travail qui tient dans une fenêtre de feedback courte. Elle ne supprime pas cette fenêtre. Une grosse story n’a de sens que si l’équipe accepte toujours de s’arrêter pour regarder avant de construire la suivante.

Le vrai risque : construire les mauvaises fonctionnalités plus vite

Le développement assisté par IA apporte des bénéfices réels : explorer des alternatives, prototyper, générer des tests, livrer du logiciel fonctionnel en un temps record. Mais il permet aussi de transformer une idée mal réfléchie en code en production avant que quiconque ne l’ait sérieusement questionnée. C’est, selon Cohn, le plus grand danger : construire les mauvaises fonctionnalités plus vite.

Construire la mauvaise chose coûte du temps et de l’argent. Ça abîme le moral d’une équipe qui a investi de l’énergie dans quelque chose dont personne ne veut. Et ça peut nuire à la réputation du produit quand les utilisateurs tombent sur des fonctionnalités confuses, inutiles ou mal adaptées. Deux phrases à afficher dans toutes les salles de sprint review :

• Qu’une fonctionnalité ait été peu coûteuse à implémenter grâce à l’IA ne la rend pas utile.
• « L’IA a construit exactement ce qu’on a demandé » ne prouve pas qu’on a demandé la bonne chose.

C’est là que le rôle du product owner devient plus important, pas moins. Quand le coût de production s’effondre, le goulot d’étranglement se déplace vers le jugement : savoir prioriser, dire non, et arbitrer entre le product owner, les parties prenantes et l’équipe sur ce qui mérite d’exister.

De l’idée à la preuve : utiliser la vitesse de l’IA au bon endroit

Le meilleur usage de l’IA, ce n’est pas d’aller plus vite de l’idée au code. C’est d’aller plus vite de l’idée à la preuve. Concrètement, pour chaque élément important de votre backlog produit :

1. Validez le problème : entretiens, observation, analytics, données du support, données opérationnelles.
2. Testez une solution possible avec un croquis, un prototype, un exemple ou un parcours utilisateur déroulé à voix haute.
3. Identifiez les hypothèses qui feront réussir ou échouer l’idée, et décidez à l’avance quelle preuve les confirmera ou les tuera.
4. Construisez juste ce qu’il faut au regard de l’incertitude et du risque.
5. Mettez du logiciel fonctionnel devant de vrais utilisateurs, tôt.
6. Arrêtez, modifiez ou simplifiez quand la preuve est faible.

Le point 5 est le plus souvent sacrifié. Si l’IA vous permet de créer quelque chose d’utile plus tôt, profitez en pour le montrer plus tôt aux utilisateurs, pas pour ajouter cinq fonctionnalités de plus avant que quiconque l’ait vu. Le feedback doit accélérer au même rythme que le développement. Sinon, vous accumulez simplement plus vite du travail non validé.

Backlog refinement : ce qu’on délègue à l’IA, ce qui reste humain

Le backlog refinement ne disparaît pas avec l’IA, il change de nature. Moins de temps passé à rédiger, plus de temps passé à décider. Voici une répartition saine entre la machine, le product owner et l’équipe de développement :

Mike Cohn insiste d’ailleurs dans un autre article sur un point clé : l’IA peut écrire des éléments de backlog, elle ne crée pas de compréhension partagée. Une user story générée et jamais discutée reste un ticket, pas une conversation. La valeur des user stories a toujours résidé dans l’échange entre le product owner et l’équipe, pas dans le texte de la carte.

Backlog produit et backlog de sprint : remettre chaque outil à sa place

Avec l’accélération, la frontière entre les deux s’est brouillée dans beaucoup d’équipes. Rappel utile :

• Le backlog produit (product backlog) est la vision ordonnée et évolutive de ce qui pourrait faire progresser un produit. Il appartient au product owner. Il contient des possibilités, pas des engagements.
• Le backlog de sprint (sprint backlog) est le plan de l’équipe pour le sprint en cours : l’objectif de sprint, les éléments sélectionnés et la façon de les livrer. Il appartient à l’équipe de développement.

Si l’IA rend votre équipe deux fois plus rapide, le réflexe naturel est de remplir le sprint deux fois plus. Mauvais réflexe. La bonne question est : quelle preuve voulons-nous obtenir d’ici la fin du sprint ? Un sprint réussi, en méthode agile, n’est pas celui où l’on a coché le plus de tickets, c’est celui où l’on a le plus appris sur la valeur réelle de ce qu’on livre. Si vos objectifs eux-mêmes sont trop nombreux, notre article sur les OKR et l’excès d’objectifs qui tue la vision devrait vous parler.

Ce qu’il faut retenir : de l’entrepôt d’exigences à l’outil d’apprentissage

À mesure que l’IA réduit le coût du détail, les bonnes équipes choisiront paradoxalement d’en maintenir moins. Leur backlog, guidé par une direction produit claire, contiendra :

• un ensemble raisonnable de possibilités futures, à gros grain ;
• des éléments à court terme clairement priorisés ;
• juste assez de détail pour soutenir les prochaines décisions utiles ;
• les preuves et hypothèses qui restent à tester ;
• des éléments affinés peu avant que leur détail devienne utile.

C’est exactement ce que devait être un backlog agile depuis le début : passer d’un entrepôt d’exigences prédites à un outil qui guide l’apprentissage et la livraison. L’IA ne fait que rendre la différence impossible à ignorer. Elle rend plus facile de construire plus. Un bon backlog aide l’équipe à savoir quand « plus » est vraiment mieux.

Si vous sentez que votre organisation confond encore vitesse et valeur, c’est souvent un sujet de pilotage et de management bien plus que d’outil. Vous pouvez réserver un appel stratégique pour en parler.

FAQ : backlog produit et IA