Un débat ouvert sur la taille des squads IA

Avec la montée en puissance des agents de codage, un débat s'est ouvert sur la taille des squads IA. Une partie du marché considère que la squad pourra à terme se réduire au seul Product Builder, qui gérerait la roadmap produit et piloterait lui-même les agents chargés de produire le code.

Cette perspective n'est pas absurde. Notre propre lecture des niveaux de l'IA engineering montre une réduction progressive des équipes :

7 à 10
ETP dans une feature team traditionnelle, avant l'IA
4 à 6
ETP avec les agents de codage
2
ETP avec les réseaux d'agents

Nos retours d'expérience confirment aussi que les gains sont plus élevés sur des équipes très réduites. Le modèle de factory autonome, avec un seul pilote, figure dans notre trajectoire, mais à l'horizon 2029-2030 et sous condition de maturité de la gouvernance et de la gestion du risque.

Sans chercher à préempter l'avenir, trois réalités nous rendent aujourd'hui sceptiques sur la viabilité d'une squad reposant sur une seule personne.

1. La réalité de la squad : une pression qui se concentre sur l'humain

L'automatisation accélère la production, mais elle ne supprime pas le travail humain : elle le déplace. Avec des cycles de 2,5 jours à 1 semaine, le goulot n'est plus le développement mais la spécification, la validation et l'arbitrage. Ces étapes restent humaines : l'IA produit, le Product Builder vérifie avant de livrer, et rien n'est partagé sans cette relecture.

Plus l'usine accélère, plus la charge de revue et d'arbitrage augmente pour ceux qui la supervisent. Nous le constatons déjà sur des squads de deux personnes (un Product Builder, un développeur), où la pression du quasi temps réel est forte et le risque d'épuisement réel. Avec une seule personne, il n'y a plus de double regard sur la production de l'IA, et chaque absence devient un risque pour la continuité du produit.

2. La réalité des compétences : deux exigences rarement réunies

Product Builder et AI Engineer sont de nouveaux métiers. Le Product Builder doit aller plus loin que le PO de l'ère agile : vision produit, discovery jusqu'au prototypage, design opérationnel, pilotage du delivery et de l'adoption. L'AI Engineer doit maîtriser l'architecture, la qualité et la sécurité pour être en mesure de valider ce que produisent les agents. Une squad d'une personne suppose de réunir ces deux niveaux d'exigence dans un même profil.

Or, depuis cinq éditions du Baromètre Niji, les organisations soulignent la difficulté à disposer de PO/PM de bon niveau dans le mode agile. En 2025, seules 36 % d'entre elles déclaraient maîtriser les compétences produit. L'exigence étant plus élevée dans un modèle IA, ces profils devront être construits (filières, parcours, coaching) plutôt qu'attendus.

3. La réalité des entreprises : un arbitrage entre optimum et risque

Les factories produisent et maintiennent le SI qui fait fonctionner l'entreprise : du chiffre d'affaires, des processus et de la production en dépendent. Le Baromètre 2026 identifie comme premier risque l'écart entre la vitesse d'évolution de l'IA et le temps nécessaire à l'adaptation des organisations. En 2026, seules 23 % anticipent l'impact de l'IA sur leurs compétences, et une sur six seulement a construit un plan de transformation. La question la plus complexe sera donc la transformation des équipes et la définition de la GPEC associée, bien avant celle de la taille idéale de la squad IA.

Dans ce contexte, il nous paraît peu probable que les entreprises passent directement d'une feature team de 8 à 10 personnes à une équipe d'une personne, responsable seule de la continuité de l'activité. La taille des équipes sera un compromis entre l'optimisation idéale (une ou deux personnes) et la maîtrise du risque. Dans un premier temps, passer de 8-10 à 3-4 personnes constitue déjà une évolution importante, tout en restant un facteur de réassurance.

Ce qu'il faut en retenir

Notre modèle cible repose sur des squads resserrées de 3 à 4 personnes (Product Builder, AI Lead Engineer, AI Engineer), appuyées par une Design Authority et un cockpit de pilotage mutualisés pour l'architecture, le design system, la cybersécurité, le FinOps et le support. Le déploiement se fait par paliers, en démarrant par une factory dédiée en parallèle des factories existantes. La taille des squads a vocation à être réévaluée à chaque palier, à mesure que la gouvernance, les compétences et l'outillage démontrent leur solidité.

Autrement dit, tout se joue dans le rythme. Jusqu'où réduire les équipes compte moins que la vitesse à laquelle l'organisation peut absorber cette réduction sans mettre en risque ni les équipes, ni l'activité.