Équipes plus petites, rôles plus larges : jusqu'où hybrider Product, Design, Data et Engineering ?

Les mêmes signaux reviennent dans plusieurs entreprises : des Product Managers qui prototypent ou codent, des designers qui poussent des changements en production, des ingénieurs plus généralistes, des analyses data réalisées directement dans les équipes produit. Chez Instagram, une équipe type est même en train de passer d'une douzaine de spécialistes à un pod de six ou sept personnes.

Faut-il en conclure que la squad Product–Design–Data–Engineering est en train de disparaître au profit de quelques « super-builders » polyvalents ?

Les cas disponibles racontent une histoire plus intéressante, et plus exigeante. L'IA rend beaucoup plus poreuses les frontières de l'exécution. Elle ne fait pas disparaître pour autant le besoin de profondeur experte. Le vrai enjeu n'est donc probablement pas de fusionner quatre métiers en un, mais de distinguer ce que chacun peut désormais faire au-delà de son rôle, de ce qui continue d'exiger une expertise, une responsabilité et une capacité de jugement spécifiques.

En bref

• •L'hybridation des rôles apparaît dans plusieurs cas observés, mais reste classée en confiance moyenne : les équipes plus petites et généralistes constituent un signal, pas encore une norme de marché.
• •Instagram expérimente une unité produit de 6 à 7 personnes, avec 4 à 6 ingénieurs généralistes, un « product staff » et un spécialiste choisi selon le sujet. Le changement est récent et ne démontre pas que la spécialisation devient inutile.
• •Alan montre jusqu'où peut aller l'hybridation : designers et PM peuvent contribuer directement à la codebase. Mais le dispositif reste volontairement borné par le périmètre, la CI, les engineering buddies et la review humaine.
• •À l'inverse, Gorgias a créé un rôle de Machine Learning Analyst à l'interface entre produit et systèmes GenAI : l'IA peut donc produire de la généralisation à certains endroits et davantage de spécialisation à d'autres.
• •La question pertinente n'est pas « combien de rôles peut-on supprimer ? », mais : quelles frontières peut-on rendre poreuses sans perdre la profondeur qui protège la qualité des décisions ?

Les équipes plus petites existent. Mais ce n'est pas encore un nouveau standard

Le cas Instagram est probablement le signal le plus spectaculaire.

Adam Mosseri décrit une équipe historique proche de la « baker's dozen » : plusieurs ingénieurs Android, iOS et serveur, un PM, un data scientist et éventuellement un chercheur. La nouvelle unité cible compte plutôt quatre à six ingénieurs davantage généralistes, un membre du « product staff » combinant plusieurs dimensions historiquement réparties entre Product, Design, Data Science et Research, et un spécialiste adapté au problème traité. Mosseri présente lui-même cette évolution comme un changement majeur en train de se produire en 2026, pas comme un modèle stabilisé depuis plusieurs années.

Ce que cela montre : le coût organisationnel de la spécialisation systématique peut devenir moins acceptable lorsque des outils permettent à une même personne d'aller plus loin dans l'analyse, le prototypage ou l'exécution.

Ce que cela ne montre pas : qu'une équipe de six personnes est désormais optimale, que les spécialistes deviennent inutiles, ou que ce modèle fonctionnerait de la même manière dans une fintech réglementée, un produit B2B complexe ou une entreprise moins mature techniquement.

Cette prudence est importante : le modèle d'« équipe produit hybride » reste lui-même classé comme une expérimentation, observée dans une poignée de cas sélectionnés pour leurs signaux organisationnels et sans prétention de représentativité.

Et tous les cas ne vont pas dans la même direction. Lucca constitue précisément un contre-exemple : l'IA est intégrée à ses produits et à certains métiers, tandis que ses petites équipes produit restent structurées autour d'un fonctionnement proche de l'existant. Il serait donc prématuré de transformer le pod resserré en nouvel organigramme de référence.

Le phénomène le plus solide n'est pas la disparition des métiers, c'est l'élargissement de leur zone d'action

Il faut ici distinguer deux formes d'hybridation.

La première est une hybridation de l'exécution : un PM peut construire un prototype fonctionnel ; un designer peut corriger directement une interface ; un ingénieur peut conduire une analyse qui nécessitait auparavant l'intervention d'un analyste ; un spécialiste data peut produire davantage de logiciel.

La seconde serait une hybridation de la responsabilité : considérer qu'une même personne peut durablement porter la stratégie produit, la recherche utilisateur, la qualité de l'expérience, la définition des métriques, l'analyse statistique et l'architecture technique.

Les cas disponibles documentent beaucoup mieux la première que la seconde. C'est une distinction structurante : pouvoir réaliser une tâche ne signifie pas nécessairement avoir acquis toute l'expertise du métier qui la réalisait auparavant.

Product : le PM builder supprime des handoffs, pas nécessairement les autres métiers

L'évolution du Product Manager est particulièrement visible. L'IA réduit fortement la distance entre l'intention et un premier artefact : prototype, requête de données, spécification, interface, script ou parfois pull request. Chez Finary, une PM est ainsi capable de construire un périmètre d'écrans conforme au design system avec des agents, avant review. Alan permet également aux PM de contribuer directement à la codebase sur certains cas. Le gain organisationnel potentiel est évident : moins d'allers-retours pour transformer une idée en quelque chose que l'on peut réellement tester.

Mais Alan permet aussi de voir la limite du raisonnement. Les contributions des non-ingénieurs y passent par le même pipeline de qualité que le reste du code. Chaque non-ingénieur dispose d'un engineering buddy et l'ingénieur conserve la responsabilité du merge. Le dispositif a d'abord été borné au front-end, précisément pour éviter les changements de back-end et de modèle de données plus risqués.

Le programme a produit plus de 350 PR mergées par des designers et PM et plus de 1 000 tâches prises en charge par l'agent interne. Mais les équipes rapportent également des PR de qualité variable, des difficultés à tester certains états, des hallucinations difficiles à détecter pour les moins techniques et une augmentation de la charge de review. Aucun ROI global clair n'était encore disponible dans le retour d'expérience publié.

C'est presque une expérience contrôlée sur la frontière du rôle : le PM peut aller plus loin dans le « faire », mais le système ne supprime pas la responsabilité engineering. Il la déplace vers le cadrage, les garde-fous et la review.

La mauvaise conclusion serait donc : « le PM devient PM + designer + développeur ». Une formulation plus réaliste serait : le PM devient moins dépendant des autres fonctions pour transformer une hypothèse en première version testable. Ce n'est pas la même chose.

Design : quand l'exécution devient moins rare, le système et le jugement prennent plus de valeur

Le cas Finary pousse ce raisonnement du côté du design. Son Design System Engineer décrit un workflow dans lequel Claude Code s'appuie sur des règles et composants codifiés pour générer des écrans conformes au design system. Une Product Manager peut ainsi produire certaines interfaces sans passer par Figma. La distinction reste explicite : l'agent est performant sur l'exécution cadrée, beaucoup moins sur la création.

Cela suggère un paradoxe. Plus l'exécution graphique devient accessible à des non-designers, plus il devient important que les choix structurants aient été transformés en système : composants, règles, conventions, accessibilité, principes d'interaction, design tokens, critères de qualité.

L'IA ne rend donc pas nécessairement le design system moins important. Elle peut au contraire en faire l'infrastructure permettant à davantage de personnes de produire sans dégrader immédiatement la cohérence.

Le rôle du designer pourrait alors se déplacer partiellement.

Avant : produire lui-même une grande partie des écrans.

Demain, dans certaines équipes : définir les principes, explorer les solutions nouvelles, construire le système, traiter les situations ambiguës et contrôler ce qui sort du cadre.

Cela ouvre une possibilité d'équipes plus légères — mais uniquement si la profondeur design existe quelque part. Une organisation qui remplace ses designers par des PM capables de générer des écrans risque surtout de confondre conformité visuelle et qualité de conception.

Data : le self-service peut réduire certains handoffs et créer de nouvelles spécialités

La Data apporte probablement le meilleur contre-exemple à une lecture naïve de l'hybridation.

Dans le modèle décrit chez Instagram, une partie de l'analyse autrefois réservée à un data scientist peut remonter vers le rôle généraliste du product staff. Mais ailleurs, la sophistication des produits IA crée de nouveaux métiers spécialisés.

Gorgias documente ainsi la création du rôle de Machine Learning Analyst, chargé de faire l'interface entre la vision produit et l'architecture GenAI, les prompts, les API, les expérimentations et les boucles de feedback. L'arrivée des grands modèles de langage n'a donc pas seulement permis de distribuer davantage les capacités data : elle a aussi créé un nouveau besoin d'expertise.

Même prudence chez Qonto, qui montre un rapprochement marqué entre ML et software engineering : les Machine Learning Engineers y voient leur rôle évoluer vers l'AI Engineering, rapprochés des équipes back-end afin de renforcer leurs compétences de software engineering. Il est donc plus prudent de parler d'hybridation croissante ML–software que de disparition pure et simple de la spécialité ML.

La tendance plausible est alors double : les analyses courantes deviennent accessibles directement aux équipes Product et Engineering ; les équipes Data se concentrent davantage sur les problèmes où la profondeur reste difficile à distribuer — fiabilité, contexte, architecture, qualité des données, expérimentation et évaluation des systèmes.

L'hybridation ne réduit pas nécessairement la quantité d'expertise. Elle peut simplement la déplacer.

Engineering : généraliste ne veut pas dire superficiel

L'ingénieur généraliste revient dans plusieurs cas du corpus. Chez Instagram, les anciens découpages Android / iOS / serveur sont remplacés, dans les pods décrits par Mosseri, par des ingénieurs capables de couvrir un champ plus large. Chez Dust, l'organisation actuelle fonctionne sans Product Manager dédié : une vingtaine d'ingénieurs à forte culture produit portent directement une partie de la priorisation, tandis que la part de code attribuée aux agents est passée, selon son CTO, d'environ 20 % à près de 70 % entre décembre 2025 et février 2026.

Mais Dust fournit aussi son propre avertissement : son modèle concerne une entreprise d'environ une centaine de personnes, et ses dirigeants ne prétendent pas que l'absence de PM constitue une doctrine universelle. Le CTO insiste au contraire sur la nécessité de profils auxquels on peut donner une forte autonomie sans dégrader la codebase.

Les recherches plus larges sur le développement assisté par IA invitent également à la prudence. Lors du déploiement de Claude Code et de GitHub Copilot CLI auprès de dizaines de milliers d'ingénieurs Microsoft début 2026, les adopteurs ont fusionné environ 24 % de pull requests supplémentaires par rapport à l'estimation contrefactuelle des chercheurs — qui soulignent toutefois explicitement qu'une PR mergée n'est pas équivalente à la valeur produite.

Une conclusion complémentaire s'impose : l'IA agit comme un amplificateur des systèmes d'ingénierie existants. Elle peut améliorer le débit, mais une organisation disposant de fondations fragiles peut surtout produire plus rapidement les mauvais outputs ou dégrader sa stabilité.

Augmenter la capacité d'un ingénieur à toucher davantage de couches techniques ne rend pas moins nécessaires l'architecture, la sécurité, la performance ou la compréhension profonde de certains systèmes.

Le généraliste augmenté est probablement plus viable lorsque les spécialistes n'ont pas disparu, mais cessent simplement d'être affectés à temps plein à chaque petite équipe.

Le modèle qui se dessine : un noyau plus généraliste, une profondeur experte disponible autrement

À travers ces cas, une architecture organisationnelle commence à apparaître. Pas une équipe remplie de spécialistes travaillant chacun dans leur couloir. Pas davantage quatre métiers fusionnés dans un improbable « full-stack Product–Design–Data–Engineering ».

Mais plutôt :

• •un noyau permanent plus petit et plus polyvalent, capable d'aller rapidement de l'idée à l'exécution ;
• •des spécialistes sollicités là où la profondeur change réellement la qualité de la décision ;
• •des systèmes explicites de review et d'évaluation, pour éviter que l'augmentation du débit ne devienne une augmentation du rework ou du risque.

C'est d'ailleurs le modèle résumé pour « l'équipe produit hybride » : product staff ou PM builder, ingénieurs généralistes, agents spécialisés et expertise métier mobilisable à la demande. Ses risques identifiés sont précisément la perte de profondeur, la surcharge des rôles hybrides et la dilution de la responsabilité.

Jusqu'où hybrider ? Trois critères permettent de tracer la frontière

Une règle simple en découle : plus le travail est standardisable, observable et réversible, plus les frontières peuvent devenir poreuses. Plus il est ambigu, difficilement réversible ou dépendant d'une expertise tacite, moins il est raisonnable de supprimer la spécialisation.

Cette règle n'est pas une donnée issue directement d'une étude : c'est une déduction formulée à partir des cas observés.

Le risque caché : créer des rôles tellement larges qu'ils deviennent impossibles à tenir

L'hybridation possède également un coût humain rarement visible dans les organigrammes.

Si le PM doit simultanément faire de la discovery, analyser les données, prototyper, écrire des specs exécutables par agents et contribuer au code, où porte-t-il réellement son attention ? Si l'ingénieur devient développeur, architecte, reviewer de cinq agents, interlocuteur utilisateur et responsable produit, qu'est-ce qui est abandonné ? Si le designer devient chercheur, directeur artistique, responsable du design system, évaluateur d'agents et contributeur front-end, où trouve-t-il le temps nécessaire à l'exploration ?

Le problème d'un rôle hybride n'est pas seulement la compétence. C'est aussi la capacité attentionnelle.

Et les agents ne suppriment pas nécessairement cette contrainte. Une étude de 306 praticiens déployant des agents en production montre que la fiabilité reste leur principal défi : 74 % des systèmes étudiés reposent principalement sur une évaluation humaine et 68 % exécutent au maximum dix étapes avant intervention humaine.

La conséquence organisationnelle est importante : une personne capable de lancer davantage de travail peut également recevoir davantage de choses à vérifier, arbitrer et superviser. C'est déjà visible chez Alan, où l'augmentation du nombre de contributions fait émerger un problème de « review fatigue ».

Réduire le nombre de producteurs tout en oubliant de dimensionner la capacité de jugement serait une fausse économie.

Ce que les données ne permettent pas encore d'affirmer

• •On ne peut pas affirmer que les squads Product classiques vont devenir deux fois plus petites. Instagram est un cas récent, spectaculaire, mais encore isolé.
• •On ne peut pas affirmer que les PM remplaceront les designers ou les data analysts. Les cas documentent surtout une capacité accrue à réaliser certaines tâches autrefois dépendantes d'un autre métier.
• •On ne peut pas affirmer que l'IA rend les spécialistes moins importants. Gorgias montre exactement le phénomène inverse sur certaines compétences.
• •On ne peut pas déduire d'un débit de code supérieur qu'une équipe peut réduire proportionnellement ses effectifs. Les travaux disponibles mesurent des proxies variés et montrent que le contexte organisationnel conditionne fortement les résultats.
• •On ne peut pas davantage supposer qu'une organisation née autour de l'IA constitue la cible d'une scale-up historique. Cette limite de transposition est explicitement soulignée par les cas eux-mêmes.

Le corpus des trente entreprises observées a été construit pour identifier des signaux organisationnels, non pour fournir un échantillon représentatif du marché.

La conviction : hybrider les gestes avant d'hybrider les responsabilités

La transformation la plus crédible n'est probablement pas la disparition des métiers Product, Design, Data et Engineering. C'est la disparition progressive d'une partie de leurs monopoles d'exécution.

Le PM n'a plus nécessairement besoin d'attendre pour prototyper. Le designer n'a plus nécessairement besoin d'attendre pour corriger une interface. L'ingénieur n'a plus nécessairement besoin d'attendre une extraction pour explorer une question data. Le spécialiste Data peut construire davantage de logiciel sans créer autant de handoffs avec Engineering.

Cette évolution peut réellement permettre des équipes plus petites et plus rapides. Mais la frontière pertinente n'est pas celle de l'outil. Elle se situe au niveau du jugement et de la responsabilité.

Les meilleures équipes ne seront probablement pas composées de moins d'experts. Elles auront moins de spécialistes affectés en permanence à chaque pod, davantage de généralistes dans le noyau opérationnel, et une expertise profonde organisée comme une capacité accessible, avec des moments précis où elle reprend la main.

L'organigramme devient ainsi moins révélateur que trois autres questions : qui peut agir ? Qui doit vérifier ? Qui décide en dernier ressort ?

Auto-diagnostic : votre équipe peut-elle réellement devenir plus petite et plus hybride ?

Avant de fusionner des rôles ou de réduire la taille d'un pod, posez ces questions sur un produit concret.

Travail

• •Avons-nous identifié précisément les tâches qui peuvent désormais passer d'un métier à l'autre ?
• •Savons-nous distinguer une tâche plus facile à exécuter d'une expertise réellement devenue inutile ?
• •Les principales opérations déléguées à l'IA sont-elles réversibles et observables ?

Qualité

• •Avons-nous des standards suffisamment explicites : design system, métriques, tests, évaluations, règles d'architecture ?
• •La capacité de review augmente-t-elle au même rythme que la capacité de production ?
• •Mesurons-nous le rework et les erreurs, et pas seulement le nombre de prototypes, PR ou fonctionnalités produites ?

Expertise

• •Savons-nous quelles décisions nécessitent toujours un spécialiste Design, Data ou Engineering ?
• •Ces spécialistes peuvent-ils être mobilisés assez rapidement sans redevenir un goulot d'étranglement ?
• •Nos experts consacrent-ils davantage de temps aux problèmes difficiles, ou passent-ils désormais leurs journées à corriger les outputs des autres ?

Rôles

• •Les responsabilités finales restent-elles explicites malgré le chevauchement des tâches ?
• •Nos rôles hybrides ont-ils réellement le temps de maîtriser leur périmètre élargi ?
• •Évitons-nous de transformer un « PM builder » ou un « ingénieur produit » en quatre postes cumulés sous un seul intitulé ?

Organisation

• •Pouvons-nous tester une équipe plus resserrée sur un périmètre pendant 60 jours avant de réorganiser toute la fonction ?
• •Comparons-nous simultanément vitesse, qualité, satisfaction utilisateur et charge de review ?
• •Sommes-nous prêts à remettre un spécialiste dans le noyau si la qualité ou la vitesse de décision se dégrade ?

Si plusieurs réponses sont incertaines, le sujet n'est probablement pas encore de réduire l'équipe. Il est d'abord de rendre visibles les nouvelles frontières du travail.

Conclusion

Les équipes Product de demain seront peut-être plus petites. Plusieurs cas crédibles commencent à le montrer.

Mais leur caractéristique la plus importante sera probablement ailleurs : elles dépendront moins des frontières fonctionnelles pour agir, tout en devant être beaucoup plus explicites sur les endroits où l'expertise reste irremplaçable.

L'IA facilite la traversée des frontières. Elle ne supprime pas automatiquement ce que des années d'expérience permettent de voir de l'autre côté.

Le bon objectif n'est donc pas de fabriquer des généralistes capables de tout faire. C'est de construire une organisation dans laquelle davantage de personnes peuvent faire davantage de choses, sans perdre la profondeur nécessaire lorsque la décision compte vraiment.