Squad et product à l'ère de l'IA : ce qui bouge, ce qui reste, ce qui se renforce

Ce que la redéfinition des rôles et des responsabilités dans les squads augmentées par l'IA déplace vraiment, et ce qu'elle laisse intact

Ces toutes dernières semaines, une même demande revient dans mes échanges avec des grands groupes — presque mot pour mot. Ce n'est plus « aidez-nous à déployer l'IA générative ». C'est « aidez-nous à réorganiser nos squads pour qu'elles créent vraiment plus de valeur ». Plusieurs sollicitations de ce type en quelques semaines à peine, sur des secteurs qui n'ont rien en commun entre eux — retail, luxe, industrie, édition. Je ne crois pas beaucoup au hasard statistique sur un échantillon aussi mince et aussi resserré dans le temps. Je crois à un signal.

Ce qui bouge dans le rôle produit, ce qui reste, ce qui s'en trouve même renforcé — je ne suis pas la seule à essayer de démêler ça en ce moment.

Le retour aux deux pizzas, en plus petit encore

Chez Amazon Web Services, Swami Sivasubramanian, vice-président en charge de l'IA agentique, racontait début juin à GeekWire comment sa division était revenue à l'organisation en « équipes à deux pizzas » — le principe fondateur d'Amazon, ces équipes assez réduites pour être nourries de deux pizzas, que l'entreprise avait largement abandonné en grandissant jusqu'à 1,5 million de salariés. Sauf que la taille a encore changé. Des projets qui mobilisaient trente à quarante personnes se traitent désormais à six ou huit. Et les rôles, à l'intérieur de ces équipes, se sont mélangés d'une manière qui mérite qu'on s'y arrête. « Les product managers écrivent du code, et les développeurs prennent des décisions produit », observe Sivasubramanian. Sur l'équipe qui a construit l'outil Kiro, c'est un product manager qui a livré lui-même la première version d'un tableau de bord de suivi des coûts.

Les équipes qui ont restructuré leur façon de travailler autour de l'IA, plutôt que de simplement y ajouter des outils, ont vu leur productivité multipliée par 4,5 en moyenne, parfois par dix. Le chiffre impressionne. Il ne dit presque rien, en revanche, de la question qui m'intéresse le plus. Une fois que l'exécution ne coûte presque plus rien, qui décide encore de la direction ?

Une image qui circule, sans qu'on s'accorde sur son sens

Lors d'un atelier auquel j'ai participé début juin, consacré aux nouveaux cycles de développement à l'ère agentique, une image m'est restée davantage que les autres. Celle de la squad comme un sandwich. Une couche haute, humaine, porte l'intention : la spécification, les priorités, les arbitrages. Une couche médiane, faite d'agents, exécute en parallèle — code, tests, documentation, migrations. Une couche basse, humaine à nouveau, porte la responsabilité, la revue, la validation, la garantie avant que quoi que ce soit ne parte en production. La couche du milieu peut grossir autant qu'elle veut. Les deux tranches humaines, elles, ne disparaissent jamais.

On appelle déjà cette structure la sandwich team, et l'expression ne m'appartient pas. J'ai cherché d'où elle venait avant de la reprendre, et j'ai fini par trouver une piste solide. Le 22 avril, dans le podcast AI & I d'Every, Dan Shipper la glisse presque par hasard en écoutant Kieran Klaassen, GM de Quora et créateur du « compound engineering », décrire où l'humain doit rester dans la boucle face à des agents codeurs. Au tout début, pour cadrer le problème. Tout à la fin, pour valider et polir. Au milieu, l'exécution peut être largement automatisée. « Les humains sont le pain du sandwich, et l'IA est au milieu », résume Shipper dans l'échange. L'atelier auquel j'ai participé début juin a prolongé cette image d'un individu face à ses agents vers l'équipe entière, et lui a donné trois portes précises plutôt que deux tranches génériques — spécifier, arbitrer, garantir. Mais l'image elle-même a un peu plus de deux mois, un père identifiable, et une origine qui n'a rien à voir avec le product management. Un détail amusant, au passage : le même jeu de mots avait déjà été envisagé par Amazon dans les années 2000 comme nom alternatif à la pizza team, pour la même taille d'équipe, sans aucun rapport avec la structure en couches. Le mot a une vie propre, indépendante du sens qu'on lui prête aujourd'hui.

Sur l'ensemble d'un cycle de développement qui compte, dans le détail, une dizaine d'étapes, il n'en reste plus, au fond, que trois où un humain doit encore se prononcer pour que la suite ait un sens. Spécifier ce qu'on construit. Arbitrer ce qu'on priorise. Garantir, avant la mise en production, que ce qui a été livré tient debout.

La sandwich team : ce qui reste humain, ce qui devient parallèle

Ce qui bouge, c'est le volume de ce qu'un product manager doit encore faire de ses mains. Ce qui reste, ce sont ces trois gestes-là, précisément. Et ce qui s'en trouve renforcé, c'est le poids de chacun. Une spécification imprécise ne produit plus un aller-retour poli avec un développeur qui demande à clarifier. Elle produit, avec assurance, mille lignes de code qui tournent très bien dans la mauvaise direction.

Je concluais, il y a quelques semaines, un article sur la fausse promesse du « product builder », en écrivant que le vrai chantier n'était pas de recruter un rôle nouveau, mais de décider, à chaque phase, qui mobilise quelle compétence. La sandwich team est peut-être la première tentative un peu sérieuse de répondre à cette question, côté organisation du travail. Elle reste, à ce stade, largement incomplète.

Deux réponses qui ne se ressemblent pas

Ce qui me frappe, en regardant au-delà de mes propres missions, c'est le désaccord. Randy Silver, consultant produit qui anime la newsletter Out of Owls, posait début mai la question dans toute sa crudité. Faut-il encore des product managers ? Sa réponse tient dans une phrase qui a au moins le mérite de l'honnêteté. « Les choses changent beaucoup trop vite pour qu'il y ait des réponses, mais nous commençons à poser les bonnes questions. » Il va jusqu'à suggérer que la fonction produit, en tant que département séparé du reste de l'entreprise, était peut-être elle-même une solution provisoire — utile un temps, pas nécessairement pour toujours.

À l'inverse, un consultant nord-américain, Pooya Golchian, propose déjà un acronyme et une thèse ferme sur le même sujet. Son cadre, qu'il baptise AIDLC (AI Development Life Cycle), découpe le cycle en huit phases — Frame, Spec, Scaffold, Generate, Eval, Harden, Ship, Operate. Les deux premières reviendraient presque intégralement au product manager. Frame fixerait le problème, l'utilisateur et l'unique métrique qui prouve que le système mérite d'exister. Spec transformerait ce cadrage en un contrat assez précis pour qu'un agent codeur puisse construire dessus sans poser de question en retour. Dans ce cadre, le product manager cesse d'être « propriétaire du backlog » pour devenir « auteur de spécifications exécutables ». Le goulot d'étranglement ne serait plus l'implémentation, mais la précision de ce qu'on demande à l'agent de construire.

Je trouve cette seconde thèse séduisante. Elle recoupe une intuition que je développais récemment à propos du vibe coding, sur le prix très différent que prend un même geste selon la phase du cycle où il se pose. Mais je me méfie de la vitesse à laquelle elle se referme déjà sur un acronyme et une méthode qui se vend — avant même que la plupart des organisations aient posé le diagnostic de leur propre problème.

Ce que je vois quand la couche haute est vide

J'ai un exemple plus modeste, et plus inconfortable, à apporter au débat. L'une de nos plateformes internes a été pilotée de bout en bout sans aucun product manager — pas sur une fonctionnalité isolée, sur l'ensemble de l'outil, depuis son origine. La part la plus opérationnelle du rôle, la rédaction de tickets détaillés, ne se justifiait plus vraiment. Des consultants prompt-augmentés livraient directement des propositions fonctionnelles, brique après brique. Le geste marchait.

Ce qui a manqué n'est apparu qu'après coup, et c'est bien tout le problème avec ce genre de manque. Une brique qui pousse à côté de ce qu'on avait décidé collectivement. Une autre qui répond à un vrai besoin, mais dans une logique différente du reste de l'outil. Rien d'alarmant, pris isolément. Mais mises bout à bout, sur la durée entière du produit et non sur un sprint, une incohérence fonctionnelle diffuse — le genre qui ne casse rien tout de suite, qui use lentement la confiance des utilisateurs dans la cohérence de l'ensemble. Personne, à aucun moment, n'avait activement décidé cette direction. Elle s'était simplement additionnée, semaine après semaine, sans qu'aucune couche haute ne vienne la reprendre en main.

Ce n'est sans doute pas un hasard si 38 % des projets d'agents autonomes ont été mis en pause faute de gouvernance, selon une étude Deloitte récente. Je ne suis pas certaine que la gouvernance manquante soit toujours celle qu'on imagine spontanément — process, sécurité, conformité. Dans notre cas, à tout le moins, ce qui manquait ressemblait surtout à une vision. Quelqu'un qui aurait tenu la cohérence d'ensemble, pendant que la couche du milieu, elle, tournait à plein régime.

Ce que je ne sais pas encore

Je ne sais pas encore si la sandwich team est le bon mot. Je ne sais pas non plus si les trois portes que j'y vois — spécifier, arbitrer, garantir — sont le bon découpage, ni si elles suffiront à tenir la cohérence d'un produit dans la durée. J'y reviendrai plus précisément, schéma à l'appui, dans un prochain article.

Ce dont je suis sûre, en revanche, c'est que la question qui monte dans mes échanges avec les grands groupes a changé de nature. Ce n'était plus, ce printemps, comment déployer l'IA dans nos squads. C'est devenu où se crée encore la valeur, maintenant que l'exécution ne coûte presque plus rien — et qui, chez nous, en tient le fil. Amazon a une réponse partielle, construite sur le terrain. Randy Silver n'en a pas, et l'assume publiquement. Un consultant vend déjà la sienne, en acronyme.

Et vous, dans votre organisation — qui est en train de répondre à cette question, et sur quelle certitude, quand personne, au fond, n'en a encore une qui tienne vraiment ?

---

Article nourri d'un retour d'expérience anonymisé sur nos plateformes internes, et de sources externes citées ci-dessus : GeekWire (Todd Bishop, 16 juin 2026), Every — podcast AI & I (Dan Shipper et Kieran Klaassen, 22 avril 2026), All Things Distributed (Werner Vogels, 30 juin 2026), Out of Owls (Randy Silver, 1er mai 2026), Pooya Golchian (7 et 9 juin 2026), Deloitte.