Sandwich Team et Product Engineer : la nouvelle équipe 10x

La fin de la Pizza Team

Pendant une décennie, la Pizza Team a été le modèle organisationnel dominant du développement logiciel. Huit personnes maximum — « assez pour nourrir avec deux pizzas » selon la formule de Jeff Bezos. Un Product Owner, un Scrum Master, des développeurs front, back, un DevOps, un QA. Chaque spécialiste dans son couloir, chaque handoff une occasion de perdre du contexte.

En 2026, ce modèle est un frein. Non pas parce que les personnes sont incompétentes, mais parce que la prémisse a changé. Écrire du code est désormais un anti-pattern. La production manuelle de code — ligne par ligne, fichier par fichier — n'est plus un actif. C'est un coût. Le code est devenu une commodité, produit plus vite par des agents IA que par n'importe quelle équipe humaine, aussi talentueuse soit-elle.

Le problème de la Pizza Team n'est pas sa taille. C'est sa structure. Huit spécialistes qui se passent le relais génèrent huit points de friction, huit interprétations différentes du besoin, huit contextes partiels. Or, dans un monde où l'IA amplifie tout — le bon comme le mauvais — cette fragmentation du contexte est un multiplicateur de chaos.

Les données DORA 2025 le confirment : le code est produit en 3 heures, mais la revue prend encore 3 jours. Le bottleneck n'est plus la production. C'est la coordination, la compréhension partagée, la cohérence. Exactement ce que la Pizza Team, par design, dilue entre huit cerveaux.

La question n'est plus « combien de personnes faut-il pour livrer une feature ? ». La question est : combien de contextes fragmentés pouvez-vous vous permettre ?

Le modèle Sandwich Team : 1 + N

La Sandwich Team remplace la Pizza Team par un modèle radicalement plus simple : un App Owner augmenté qui couvre 80% du périmètre technique, assisté de contributeurs occasionnels qui interviennent sur les 20% restants via un contexte partagé.

Pourquoi « Sandwich » ? Parce que la valeur tient entre deux tranches : le contexte structuré au-dessus (specs, conventions, architecture), l'exécution IA en dessous. L'humain — l'App Owner — est la garniture qui donne le sens, la direction, le jugement.

La structure est volontairement asymétrique. Là où la Pizza Team répartissait la charge uniformément, la Sandwich Team concentre la responsabilité et distribue uniquement les interventions spécialisées. Ce n'est pas un retour au développeur héroïque des années 2000. C'est une nouvelle réalité : un ingénieur équipé des bons agents IA, opérant dans un contexte structuré, peut couvrir un périmètre qui nécessitait auparavant cinq à huit personnes.

Le « N » de la formule 1 + N n'est pas fixe. Certaines semaines, N = 0. L'App Owner pilote ses agents, produit, revoit, itère. D'autres semaines, un expert sécurité intervient pour un audit, un designer UX affine une interaction complexe, un data engineer optimise un pipeline. Ils arrivent, trouvent le contexte structuré dans le dépôt Git, contribuent, et repartent. Pas de ramp-up de deux semaines. Pas de « sprint de découverte ». Le contexte est là, versionné, à jour.

Ce modèle ne fonctionne que si le contexte est impeccable. C'est la condition sine qua non. Sans contexte structuré, la Sandwich Team est juste un développeur seul et débordé. Avec le bon contexte, c'est une équipe 10x.

L'App Owner augmenté : 80% du périmètre technique

L'App Owner n'est pas un développeur fullstack au sens classique. C'est un ingénieur augmenté qui coordonne la production totale d'une application, de l'UX à la sécurité, en s'appuyant sur des agents IA spécialisés pour chaque domaine.

Son périmètre couvre six dimensions :

UX — Il traduit les besoins utilisateurs en parcours, valide les wireframes, arbitre les compromis d'ergonomie. Les agents IA génèrent les variantes, il choisit et affine.

UI — Il maintient le système de design, décline les composants, assure la cohérence visuelle. Les agents produisent le code des composants, il valide l'intention et l'accessibilité.

Front-end — Il pilote l'architecture front, les performances, le SSR/SSG. Les agents écrivent le code, il structure le contexte qui garantit la cohérence entre les pages.

API — Il conçoit les contrats d'interface, valide les schémas, assure la rétrocompatibilité. Les agents génèrent les endpoints, il vérifie que le contrat business est respecté.

Back-end — Il architecture les services, les modèles de données, la logique métier. Les agents implémentent, il s'assure que l'architecture reste propre et évolutive.

Sécurité — Il définit les politiques, les contrôles d'accès, le chiffrement. Les agents auditent le code produit, il arbitre les risques et les remédiations.

L'analogie qui fonctionne le mieux est celle du bûcheron qui coordonne une machine. Il ne coupe plus les arbres un par un à la hache. Il pilote une abatteuse-ébrancheuse qui fait en une minute ce qui prenait une heure. Mais il doit comprendre la forêt — la pente, les essences, les contraintes environnementales — pour diriger la machine au bon endroit.

Le risque principal : la fatigue décisionnelle. Le rapport DORA 2025 identifie ce phénomène : quand le développeur passe de Créateur à Vérificateur, le volume de décisions par heure explose. L'App Owner doit donc s'appuyer sur des garde-fous automatisés — tests, linting, CI/CD ultra-robuste — pour réduire le nombre de décisions manuelles. 90% des vérifications doivent être automatiques pour que les 10% restants soient des décisions de jugement à haute valeur.

Le Product Engineer : la fusion des spécialités

Le Product Engineer est le nouveau rôle qui émerge de cette transformation. Ce n'est ni un développeur, ni un product manager, ni un tech lead. C'est une fusion des spécialités rendue possible par l'augmentation IA.

Le Product Engineer combine trois capacités historiquement séparées :

La vision produit — Il comprend le métier, les utilisateurs, le marché. Il sait pourquoi une feature existe, pas seulement comment la coder. Cette compréhension du « pourquoi » est ce que les agents IA ne peuvent pas (encore) fournir.

L'architecture technique — Il pense en systèmes, pas en tickets. Il voit les dépendances, anticipe les effets de bord, conçoit pour l'évolution. Son architecture est exprimée en contexte structuré que les agents peuvent consommer.

L'exécution augmentée — Il ne tape plus de code au kilomètre. Il rédige des spécifications précises, structure le contexte, pilote les agents, revoit les résultats. Son unité de travail est le cycle PLAN → WORK → REVIEW, pas la ligne de code.

Le passage de développeur à Product Engineer n'est pas un upgrade. C'est un changement de nature. La valeur ne réside plus dans la capacité technique à produire du code — cette capacité est désormais commoditisée. La valeur réside dans le discernement (juger la pertinence) et l'agentivité (décider d'agir), comme le souligne Charles Gorintin d'Alan.

Chez SFEIR, cette transition se traduit concrètement. Un Product Engineer SFEIR est évalué sur sa capacité à livrer un produit fonctionnel, pas sur sa maîtrise d'un framework. Il est mesuré sur la vélocité de son cycle complet — de l'idée au déploiement — pas sur le nombre de pull requests.

Le paradoxe de Jevons s'applique ici : quand le code devient moins cher à produire, la demande de logiciel explose. Le Product Engineer n'est pas menacé par l'IA. Il est libéré pour répondre à une demande qui était jusqu'ici impossible à satisfaire.

Contributeurs occasionnels : le 20% via contexte partagé

Le « N » de la Sandwich Team, ce sont les contributeurs occasionnels. Des experts qui interviennent ponctuellement sur un périmètre spécifique : un audit de sécurité, une optimisation de performance, une refonte UX, une migration de données.

Ce qui rend ce modèle viable, c'est le contexte partagé versionné dans Git. Quand un contributeur arrive sur le projet, il trouve :

La constitution du projet (Tier 1 — Hot Memory) : les conventions, les patterns architecturaux, les règles métier. Tout ce qui définit « comment on fait les choses ici ».

Les spécifications actives (Tier 2 — Warm Memory) : les features en cours, les décisions d'architecture récentes, les arbitrages techniques. Le contexte chaud du moment.

L'historique complet (Tier 3 — Cold Memory) : les post-mortems, les ADR (Architecture Decision Records), les specs passées. Le « pourquoi » derrière chaque choix.

Un contributeur occasionnel équipé de ce contexte est opérationnel en quelques heures, pas en quelques semaines. Il charge le contexte dans son agent IA, comprend les conventions, produit du code conforme, et soumet sa contribution. L'App Owner revoit, valide, intègre.

Le modèle du contributeur occasionnel résout un problème structurel de l'industrie : l'expertise pointue est rare et coûteuse. Avec la Sandwich Team, un expert sécurité n'est plus bloqué à temps plein dans une équipe qui n'a besoin de lui que 20% du temps. Il contribue à cinq ou six projets, guidé chaque fois par un contexte structuré qui lui permet d'être immédiatement pertinent.

La condition : le contexte doit être maintenu. Le Context Engineering enseigne que le contexte rot comme le code. Si vous expliquez la même chose deux fois à un contributeur, c'est un bug de documentation. Le budget de maintenance est de 1 à 2 heures par semaine — un investissement modeste pour un système qui s'améliore en continu.

Comment ça fonctionne en pratique : le workflow Compound Engineering

La Sandwich Team opère selon le workflow Compound Engineering : PLAN → WORK → REVIEW → COMPOUND → REPEAT. Ce n'est pas un processus théorique — c'est le cycle quotidien de l'App Owner et de ses contributeurs.

PLAN (40% du temps) — L'App Owner rédige les spécifications de la prochaine itération. Pas un ticket Jira de trois lignes. Des spécifications structurées qui alimenteront les agents IA : le contexte métier, les contraintes techniques, les critères d'acceptation, les cas limites. C'est ici que se joue la qualité du résultat. 80% du travail se fait avant le prompt.

WORK (20% du temps) — Les agents IA produisent le code sous supervision. L'App Owner lance les agents, monitore l'exécution, intervient quand le résultat dévie. Le code n'est pas écrit manuellement — il est généré, guidé par le contexte structuré de la phase PLAN.

REVIEW (30% du temps) — L'App Owner vérifie le résultat. Pas ligne par ligne — via des tests automatisés, des audits de sécurité automatiques, des métriques de performance. Il concentre son attention humaine sur les décisions que l'automatisation ne peut pas prendre : la cohérence métier, l'expérience utilisateur, les arbitrages stratégiques.

COMPOUND (10% du temps) — C'est la phase qui fait toute la différence. L'App Owner enrichit le contexte avec les leçons de l'itération : les patterns qui ont fonctionné, les erreurs à éviter, les clarifications de specs. Ce contexte enrichi sera consommé par les agents lors de la prochaine itération.

L'effet cumulatif est le cœur du modèle. L'ingénierie traditionnelle voit la complexité croître avec chaque feature — chaque ajout rend le suivant plus difficile. Le Compound Engineering inverse cette courbe : chaque itération enrichit le contexte, et chaque feature devient plus facile que la précédente.

En pratique, un cycle complet dure entre un et trois jours selon la complexité. L'App Owner peut enchaîner deux à trois cycles par semaine. Sur un mois, cela représente dix à douze itérations — là où une Pizza Team en Scrum classique en fait deux.

Le passage de Spec-Driven (2025) à Issue-Based (2026) accélère encore le processus. Plutôt que de demander des features isolées — comme « boulonner une salle de bains sur la façade » — l'App Owner signale des écarts et des anomalies. L'agent IA analyse le contexte existant et propose des corrections systémiques, cohérentes avec l'ensemble de l'application.

Le stack technique doit être AI-Ready pour que ce workflow fonctionne : typage fort, code explicite et verbeux, développement trunk-based. On évite la syntaxe compressée, les comportements implicites, la magie invisible. Les ingénieurs choisissent librement leurs outils, mais le contexte et le code en sortie sont standardisés.

Le SDLC 10x qui en résulte suit une chaîne rigoureuse : spécifications précises → construction IA sous surveillance → CI/CD ultra-robuste → monitoring métier proactif. Chaque maillon renforce les autres. Chaque cycle rend le système plus résilient.

La Sandwich Team n'est pas une réduction d'effectifs déguisée. C'est une amplification de l'impact humain. Un Product Engineer avec le bon contexte, les bons agents et le bon workflow produit plus de valeur qu'une équipe de huit — non pas parce qu'il travaille plus, mais parce que le contexte structuré élimine la friction qui consumait 80% de l'énergie d'une équipe traditionnelle.

Chez SFEIR, les premières Sandwich Teams en production montrent un facteur de vélocité de 5x à 10x par rapport aux équipes Scrum classiques. Le secret n'est pas l'IA. Le secret est le contexte.