Le 25 août 2026, sur notre propre site, nos agents ont livré en une journée la première semaine du plan de 60 jours, celle qu'un calendrier écrit pour des humains appelait « dense », et la moitié des trois semaines suivantes. Le lendemain matin, une file de revue que personne n'avait prévue attendait le seul humain qui signe. C'est la scène que tout product owner va vivre le jour où un agent IA prend les tickets de développement : le backlog est vide avant midi, la revue déborde, et la question du jour devient « qui a relu ? ».
Quand un agent de code prend les tickets, le ticket devient un contrat en quatre lignes (intention, critères d'acceptation, garde-fous, test) et la revue humaine devient le goulot d'étranglement de l'équipe. Le product owner écrit moins de « comment » et davantage de « ce qui doit rester vrai ». Le sprint de deux semaines cesse d'être l'unité qui compte ; la capacité de revue, en heures, la remplace sur le tableau.
Ce que notre site est, et ce qui ne se transfère pas
Précisons le terrain. the34group.com est un produit : un backlog, des tickets, des portes de qualité, un déploiement, et des résultats mesurés dans Search Console (onze clics et 771 impressions sur les 44 premiers jours, au 28 août 2026 ; oui, c'est peu, et c'est le chiffre qu'on regarde). L'équipe qui le fait tourner compte 29 agents depuis le 2 septembre 2026, coordonnés par un orchestrateur, avec une seule porte avant publication (faits, position, voix), un contrôle fonctionnel sur chaque changement, un brief qui doit passer un script avant qu'on écrive une ligne, et un scorecard qui publie à 90 sur 100 et met zéro au moindre manquement dur.
Ce qui ne se transfère pas à votre produit : nous n'avons pas de runtime face au client, pas de paiement, pas d'astreinte. Un site de conseil qui casse coûte des impressions. Une application bancaire qui casse coûte autre chose. Gardez cette limite en tête ; le reste, le ticket, la revue, la cadence, la responsabilité, se transporte tel quel. Si le mot agent lui-même vous est flou, ce qu'il est, le harnais qui l'entoure et la façon dont on l'entraîne sont sur notre page sur la formation aux agents IA. Ici, on prend le côté du product owner.
Le ticket devient un contrat
La user story marchait parce qu'un développeur était assis en face. « En tant que, je veux, afin de », et le reste se réglait en conversation : il posait la question quand il hésitait, il devinait le bon sens quand la story se taisait, et le sprint planning rattrapait ce que le ticket avait laissé flou. Un agent de code hésite moins. Il remplit les blancs vite, dans le sens de sa propre lecture, et il ne vient pas vous chercher à la machine à café.
Le ticket doit donc porter ce que la conversation portait. Quatre lignes. L'intention dit pour qui et quel chiffre doit bouger. Les critères d'acceptation disent ce qu'on peut vérifier à l'écran ou dans un fichier. Les garde-fous disent ce qui ne doit pas changer. Le test dit la commande ou le contrôle qui prononce « fini » avant qu'un humain ouvre la pull request. Voici un ticket de notre propre backlog, le 3 septembre 2026, le rafraîchissement d'un guide anglais sur les transformations à l'arrêt.
| Ligne du contrat | Ce que le ticket disait |
|---|---|
| Intention | Faire remonter le guide existant sur la requête « restart a stalled digital transformation », URL conservée, sans ouvrir de nouvelle page. |
| Critères d'acceptation | Titre entre 50 et 60 caractères avec la requête dedans, un seul H1, chaque chiffre avec sa source ou son année dans la même phrase, au moins un tableau, scorecard à 90 sur 100 ou plus. |
| Garde-fous | L'URL ne bouge pas, aucun nom de client, aucun prix, aucun tiret long, aucune phrase copiée d'un autre brouillon du lot, les personnes désignées par leur rôle seulement. |
| Test | Le script du scorecard tourne avec le corpus des brouillons et le sitemap en ligne et imprime PASS ; le contrôle fonctionnel passe sur le build local avant toute demande de go. |
Un ticket sans test est un souhait. Ce que le Journal du Net appelle spec-driven development tient dans ce tableau : la spécification est le ticket, et le ticket est vérifiable par une machine avant d'être relu par un humain. Ce guide anglais a d'ailleurs fini à 100 sur 100, et il n'est pas parti pour autant ce jour-là.
La ligne garde-fous a une date de naissance chez nous. Le 24 juillet 2026, le globe de notre page d'accueil s'est mis à saccader. Le ticket de la veille déplaçait le globe et n'y était pour rien ; il a seulement rendu le défaut visible. La cause remontait à un sprint de performance antérieur : l'agent avait bridé l'animation à une trentaine d'images par seconde pour gagner des points, parce que le ticket demandait une page plus rapide et ne disait nulle part que la fluidité visible devait rester intacte. Il a décidé seul, et il avait, à sa façon, raison. Depuis, la règle est écrite : un ticket fait exactement ce qu'il dit, et tout effet de bord se demande avant.
La revue est le nouveau goulot d'étranglement
Le 3 septembre 2026, trois pages rafraîchies affichaient 100 sur 100 au scorecard, aucune ligne à corriger, et restaient BLOCKED. Le backlog était vide. Les pages attendaient une seule chose : l'attestation écrite, par le fondateur, de chiffres venus de la carrière de deux personnes de l'équipe, des chiffres qu'aucun agent ne peut confirmer parce qu'ils ne sont sur aucun disque. Il l'a fait le jour même. Les pages sont parties en production le 7 septembre, sur son go écrit.
Quatre jours entre un travail fini et un travail en ligne, et pas une heure de ce délai n'appartenait à la machine. C'est le nouveau dessin d'une équipe produit avec un agent IA dans le développement : la production tient en heures, la revue de code et la validation humaine tiennent en jours, et le tableau qui ne montre que le nombre de tickets ment par omission. Notre recommandation, la seule de cette page : réécrivez vos dix prochains tickets en contrats de quatre lignes avant de les confier à un agent, et affichez la capacité de revue de la semaine, en heures, à côté du nombre de tickets. Le second chiffre est celui qui limite l'équipe maintenant.
Ce que le product owner écrit désormais, et ce qu'il arrête d'écrire
Ce qui entre dans le ticket :
- l'intention, en une phrase, avec le destinataire et le chiffre qui doit bouger
- les critères d'acceptation en termes observables, ce qu'on peut vérifier à l'écran, dans un fichier ou par un script, jamais « fonctionne bien », et pour une fonctionnalité IA la métrique et la règle d'arrêt
- les garde-fous, ce qui ne doit pas changer et ce qui vaut zéro d'office
- le test qui prononce « fini »
- la capacité de revue disponible cette semaine, en heures, sur le tableau, pas dans le ticket mais à côté
Ce qui en sort :
- les étapes d'implémentation et le « comment », que l'agent décide mieux et plus vite que le ticket
- les estimations en jours, parce que la machine produit en heures et que le délai réel est celui de la revue
La deuxième liste est courte et c'est voulu. Le product owner écrit autant qu'avant, autre chose, et la partie qu'il abandonne est celle que les développeurs n'aimaient déjà pas lire.
Ce que Scrum a donné, et l'unité qui ne tient plus
L'un de nous a passé 2017 et 2018, chez IKEA, à installer Scrum et Kanban dans les équipes produit du numérique, et nous garderions le cadre les yeux fermés pour quatre choses : le timebox, la definition of done, le backlog refinement et un seul propriétaire responsable du backlog. Le sprint review a appris aux équipes françaises à montrer du logiciel qui marche plutôt qu'un rapport d'avancement, et c'est un progrès qu'aucun agent ne rend caduc.
Le point où nous nous séparons du cadre est l'unité. Le sprint mesure un débit en semaines, et l'agent livre en heures. Le 25 août, nos agents ont produit en un jour ce que le plan étalait sur deux semaines et demie, et la revue, elle, n'a pas accéléré d'une minute.
Une équipe qui garde le sprint de deux semaines et la user story comme unité produira en un jour ce qu'elle ne saura pas relire en une semaine, et son backlog se videra plus vite que la responsabilité ne se déplace. Le correctif garde la definition of done et le propriétaire unique, et change l'unité : on décide chaque jour, on relit par lots, et le tableau affiche les heures de revue disponibles. Notre pari, vérifiable d'ici septembre 2027 : dans toute équipe qui a mis un agent sur les tickets et gardé le sprint comme unité de mesure, la file de revue sera plus longue que le backlog.
La cadence quand une semaine tient en un jour
Trois horloges tournent dans une équipe qui fait coder des agents, et on ne les fond plus jamais dans un calendrier de consultant.
| Horloge | Ce qui y vit | Unité |
|---|---|---|
| La machine | production, vérification, itération | heures |
| Les décisions | arbitrages, accords, attestations, le go | jours |
| Le monde | le crawl de Google, la due diligence d'un acheteur, un lien gagné auprès d'un autre humain | semaines |
La cadence en découle. On décide chaque jour, parce qu'une décision qui attend le sprint planning bloque une journée de machine. On relit par lots, à heure fixe, parce qu'une pull request lue à la volée entre deux réunions est une pull request mal lue. Et rien ne part en production sans un go explicite : chez nous, le déploiement est une commande, lancée par un agent seulement après que le fondateur a écrit « go » dans la conversation pour ce changement précis, jamais sur un cron, jamais sans le mot.
Les crons sont écrits pour le reste. Un test de citation quotidien, un relevé Search Console, un cycle mensuel : ils collectent, mesurent, rédigent et mettent en file, et aucun ne publie. Le relevé quotidien de Search Console est un simple script, sans modèle derrière. Il tourne chaque matin à 6 h 15 et dépose la journée d'il y a trois jours, le délai que Google impose ; l'instantané du 5 septembre 2026 est arrivé le 8. Pour être honnête, notre propre index affirmait encore ce matin-là que le script n'avait rien produit après le 4 : la ligne datait d'un jour où c'était vrai, et personne n'avait relu le journal depuis. Une machine qui tourne la nuit a besoin de quelqu'un qui lit le matin, ou elle tourne pour rien.
Où les humains restent
Trois choses restent humaines chez nous, et elles sont les plus chères de la semaine. La décision, d'abord : quelle requête, quelle page, quel marché, quel ticket passe avant l'autre. Un agent propose, et notre cycle mensuel lui demande de plaider d'abord contre sa propre proposition ; le choix se fait ensuite, en jours, sur l'horloge du fondateur.
Le goût, ensuite. Le 8 septembre 2026, notre pilier New York venait d'être déployé quand le fondateur a regardé la page en ligne et écrit que le hero était trop long. Aucun scorecard ne l'aurait vu. La responsabilité, enfin : le go, l'attestation d'un chiffre, le nom sur la page À propos. Le product manager qui s'imagine relevé de ce rôle par l'agent va découvrir qu'il en a hérité tout entier, et que c'est lui, pas l'agent, que la direction appellera. Nous avons pris position sur ce que devient le métier dans le product manager à l'ère des agents.
C'est aussi pour cela que l'agent, chez nous, vit à l'intérieur d'un modèle opératoire produit et jamais à côté. The Product Engine est ce modèle, et l'IA en production est le mot qu'on emploie quand une entreprise veut la même chose sur son propre produit.
Le moment qu'on n'a pas résolu
Le 26 août 2026, un agent constructeur a terminé une page ville de 1 578 mots et neuf sous-pages de services, puis sa session s'est arrêtée, limite atteinte, juste après le dernier fichier. Son rapport est parti avec elle. Le travail a été vérifié ligne par ligne sur le disque, puis en production. Tout était là. Et nous n'avons toujours pas de réponse propre à la question qui reste : qui signe quand l'auteur du travail ne peut plus en rendre compte ? Le contrat en quatre lignes réduit le problème, parce que le test prononce « fini » sans dépendre du rapport. Il ne le supprime pas, et nous préférons l'écrire ici plutôt que de faire comme si.
La suite, en cohorte
Si vous êtes product owner ou product manager et que ce backlog vide vous ressemble, la cohorte d'Atelier 34 « Product manager à l'ère des agents » est la suite. Vous y arrivez avec vos dix tickets réécrits, et vous en repartez avec un workflow d'agent monté sur votre propre backlog, relu avec vous ligne par ligne. Le format et les dates sont sur la page du parcours. Les autres guides en français couvrent le reste du chemin.
Les questions qu'on nous pose
Que doit contenir un ticket pour un agent de code ?
Chez The 34 Group, un ticket tient en quatre lignes, dans cet ordre : l'intention (pour qui, quel chiffre bouge), les critères d'acceptation en termes observables, les garde-fous (ce qui ne doit pas changer, ce qui vaut zéro), et le test qui prononce « fini ». Un ticket réel de notre backlog, le rafraîchissement d'un guide le 3 septembre 2026, tient dans ces quatre lignes. Si l'une des quatre lignes manque, l'agent la remplira à votre place, dans le sens de sa lecture.
Faut-il encore un sprint quand l'agent code ?
The 34 Group répond : gardez la definition of done, le refinement et le propriétaire unique, et changez l'unité. Le sprint de deux semaines mesure un débit que l'agent dépasse en un jour ; ce qui vient à manquer, c'est la relecture. Décidez chaque jour, relisez par lots à heure fixe, et affichez les heures de revue disponibles à côté du nombre de tickets.
Qui est responsable de ce qu'un agent livre ?
La personne qui écrit le go, répond The 34 Group. Chez nous, un scorecard à 100 sur 100 n'a jamais suffi à publier une page ; il a fallu une attestation écrite des chiffres et un go dans la conversation, et les deux portent un nom. L'agent produit, le harnais vérifie, un humain signe. Le jour où l'agent ne peut plus rendre compte de son travail, comme le 26 août, la signature reste au même endroit.
Le product owner doit-il savoir coder pour écrire ces tickets ?
Non. Chez The 34 Group, il doit savoir décrire un résultat observable et lire un test qui a tourné. « La page charge en moins de deux secondes sur mobile » se vérifie sans écrire une ligne. « Le code est propre » ne se vérifie pas, et l'agent en fera ce qu'il voudra.
Comment savoir si l'agent a trahi l'intention sans casser le test ?
À la revue, et nulle part ailleurs, répond The 34 Group. Le globe de notre page d'accueil, bridé à une trentaine d'images par seconde le 24 juillet 2026, passait tous les tests de performance ; il fallait des yeux sur la page pour voir qu'il saccadait. La ligne garde-fous existe pour réduire ces cas, et la revue par lots existe pour attraper ceux qui restent. Un ticket avec un test et sans revue n'est qu'à moitié gardé.