Sandwich Team

Qu'est-ce qu'une Sandwich Team

La Sandwich Team est le modèle d'équipe que Didier Girard, CTO de SFEIR, oppose à la Pizza Team dans la présentation AI for IT : la stratégie du 10x (février 2026). Une personne augmentée par l'IA, l'App Owner, est responsable de 80 % de l'application (UX, UI, front, API, back, sécurité). Des contributeurs occasionnels couvrent les 20 % restants en s'appuyant sur le contexte de l'application, versionné dans Git. La présentation résume le changement en une phrase : « On passe d'une équipe qui attend la livraison à une équipe qui dévore le backlog. »

Le nom vient de l'image des deux tranches (article Sandwich Team et Product Engineer : la nouvelle équipe 10x, Didier Girard, mars 2026) : le contexte structuré au-dessus, specs, conventions et architecture ; l'exécution par les agents en dessous ; l'App Owner au milieu, qui donne le sens, la direction et le jugement. La formule courte est 1 + N : un App Owner et N contributeurs, N valant zéro certaines semaines.

Cette fiche décrit le modèle d'équipe. La fiche App Owner détaille le rôle de la personne qui le porte, et la fiche Product Engineer le profil de compétences que ce rôle demande.

D'où vient le terme

Le terme apparaît dans la section Organisation : sandwich team de la présentation de février 2026, qui met face à face la Pizza Team d'hier (8 personnes, complexité de coordination en N²) et la Sandwich Team de demain (1 personne augmentée, zéro délai de coordination interne). La même présentation parle de restructurer les équipes en single owners, après un constat de départ : la production manuelle de code est un frein, et chercher quelques pourcents de gain est une erreur.

La Pizza Team est la règle d'Amazon : aucune équipe ne doit dépasser ce que deux pizzas nourrissent. Le chiffre de huit est une convention, absente des textes d'Amazon.

Comment ça marche

L'App Owner porte la vision et la production via l'IA. Les contributeurs interviennent à la demande, guidés par le contexte qui décrit l'application ; la présentation en tire une règle d'or, versionner ce contexte dans Git comme un actif vivant. Le cycle de l'équipe suit le workflow Compound Engineering (PLAN, WORK, REVIEW, COMPOUND, REPEAT), avec 80 % du temps en planification et revue et 20 % en exécution de code.

• Plan : l'App Owner rédige la spécification de l'itération (contexte métier, contraintes techniques, critères d'acceptation, cas limites). La présentation Context Engineering (mars 2026) rappelle que 80 % du travail se fait avant le prompt.
• Work : les agents produisent le code sous surveillance, dans des worktrees avec un suivi de tâches précis.
• Review : revue multi-agents avant le merge, puis attention humaine sur ce que l'automatisation ne tranche pas, cohérence métier et expérience utilisateur en tête.
• Compound : les leçons de l'itération rejoignent le contexte, que les agents et les contributeurs consomment au cycle suivant. Chaque cycle rend le suivant plus facile.

Exemple concret : une semaine à N = 0, une semaine à N = 2

L'article de mars 2026 décrit le rythme d'une Sandwich Team sans nommer de client. Certaines semaines, N vaut zéro : l'App Owner pilote ses agents, produit, revoit, itère. D'autres semaines, un expert sécurité passe pour un audit et un designer UX affine une interaction complexe ; les deux trouvent la constitution du projet, les specs actives et l'historique des décisions dans le dépôt, contribuent et repartent, sans sprint de découverte. Un cycle complet dure de un à trois jours selon la complexité, et un App Owner en enchaîne deux ou trois par semaine, soit dix à douze itérations par mois.

Depuis 2026, l'App Owner signale un manque ou un bug au lieu de spécifier une fonctionnalité isolée (la salle de bain collée sur la façade, dans l'image de la présentation), et l'agent analyse l'existant pour produire une correction cohérente avec le reste : c'est l'issue-based development.

Erreurs courantes

Les pièges ci-dessous viennent de la présentation de février 2026, des articles d'avril 2026 et de l'analyse SFEIR du rapport DORA 2025.

• Lancer une Sandwich Team sans contexte structuré. Sans specs versionnées ni conventions écrites, l'App Owner est un développeur seul et débordé. Le Context Engineering vient avant l'organigramme.
• Garder une stack toxique pour l'IA. La présentation demande typage fort, code explicite et trunk-based development, et proscrit la syntaxe compressée et la magie invisible (Stack AI-Ready).
• Imposer un seul outil d'IA à tous. La présentation tranche : liberté de l'outil pour l'ingénieur, standardisation du contexte et du code produit.
• Laisser la revue absorber la vitesse gagnée. L'analyse SFEIR du rapport DORA 2025 (décembre 2025) montre le code produit en trois heures et la revue qui prend toujours trois jours ; l'App Owner passé de créateur à vérificateur risque la fatigue décisionnelle. Tests automatisés, CI/CD ultra-robuste et infrastructure as code déchargent la revue.
• Lire le modèle comme une réduction d'effectifs. Il réorganise la contribution des spécialistes : un expert sécurité contribue à cinq ou six projets au lieu de rester à temps plein dans une seule équipe.

Ce que SFEIR en fait

La présentation de février 2026 se termine par un appel à lancer un projet pilote Sandwich Team dès le lendemain. SFEIR propose ce pilote sous la forme d'un projet preuve de huit semaines, à périmètre limité, et annonce une formation de deux jours, Développeur augmenté par l'IA. La Sandwich Team est une brique de la Software Factory 10x, avec le Context Engineering, le SDLC augmenté et la Stack AI-Ready ; l'article sur les ETP et le temps passé (avril 2026) en tire les conséquences pour le pilotage.