La Sandwich Team : 1 App Owner pour 80% du périmètre technique

De la Pizza Team à la Sandwich Team : un changement de paradigme

Pendant des années, l'industrie du logiciel a optimisé à la marge. On a affiné les cérémonies agiles, réduit les cycles de sprint, introduit le DevOps, automatisé les pipelines CI/CD. Chaque itération apportait quelques pourcents de gain. Et pourtant, la dynamique fondamentale restait inchangée : des équipes de 6, 8, parfois 12 personnes, organisées en silos de spécialités, se passant le travail de main en main comme des relayeurs dans un couloir trop étroit.

Ce modèle touche à sa fin. Pas parce qu'il est mauvais en soi, mais parce qu'un nouveau rapport de force est apparu. L'IA générative agentique ne fait pas juste accélérer l'écriture de code — elle remet en question la nécessité même d'une grande partie de cette organisation.

Chez SFEIR, nous observons cette transformation chez nos clients depuis plusieurs mois. Ce que nous voyons émerger, c'est un nouveau modèle organisationnel que nous appelons la Sandwich Team : une architecture humain-IA où un seul développeur augmenté peut assumer la responsabilité de 80 % du périmètre technique d'une application. Ce n'est pas de la science-fiction. C'est une direction stratégique concrète, avec ses méthodes, ses outils et ses nouvelles exigences de compétences.

Le problème avec l'amélioration continue

Il y a une erreur de raisonnement confortable dans laquelle beaucoup d'organisations tombent : celle de croire que l'IA doit venir s'insérer dans les processus existants pour les rendre un peu plus rapides. On intègre un copilote ici, un assistant là, on gagne 15 % sur la vitesse d'écriture de boilerplate, et on appelle ça une transformation.

Le problème, c'est que chercher des gains marginaux sur un modèle fondamentalement limité ne change pas l'échelle de ce qu'on peut produire. Comme le formule Didier Girard, CTO de SFEIR : "Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement."

C'est une affirmation qui peut sembler provocatrice, mais elle pointe quelque chose de précis. La valeur d'un ingénieur logiciel n'a jamais résidé dans sa capacité à taper des caractères sur un clavier. Elle réside dans sa capacité à comprendre un problème, à modéliser une solution, à anticiper les contraintes et à garantir la cohérence d'un système dans le temps. L'IA peut prendre en charge la partie mécanique de la production de code. Ce qui reste — ce qui devient plus précieux que jamais — c'est le jugement, le contexte, la vision.

L'objectif stratégique que nous fixons n'est pas un gain de 20 % ou même de 50 %. C'est un facteur 10x sur la capacité à créer de la valeur métier. Ce saut d'échelle n'est pas atteignable en optimisant l'existant. Il nécessite de revoir la méthode de travail, le rôle des personnes, et la structure des équipes.

Context Engineering : le nouvel actif stratégique

Si on ne produit plus de code manuellement, que produit-on ? La réponse tient en deux mots : du contexte.

Le Context Engineering est la discipline qui consiste à construire et maintenir l'environnement structuré dans lequel l'IA va opérer. Cela englobe les spécifications fonctionnelles rédigées en langage naturel, les règles métier formalisées, les décisions d'architecture documentées, les contraintes de sécurité, les conventions de code, les tests de référence. Tout ce qui, traditionnellement, existait de manière implicite dans les têtes des développeurs ou dispersé dans des wikis désynchronisés.

Concrètement, un bon environnement de Context Engineering se présente comme un ensemble de fichiers versionnés — des fichiers Markdown, des specs, des règles — qui décrivent l'application non pas comme elle est (le code source), mais comme elle doit être et pourquoi. C'est ce référentiel qui permet à un agent IA de produire du code cohérent, sans hallucination, aligné avec les intentions de l'équipe.

La distinction avec l'approche traditionnelle est nette :

• Approche traditionnelle : on configure l'humain pour produire du code, puis on corrige les écarts.
• Approche IA agentique : on configure la machine en amont, on travaille les "réglages" (prompts, contexte, contraintes), et on garantit la conformité dès la production.

Ce changement de posture a des implications profondes. Le développeur ne passe plus 80 % de son temps à écrire du code et 20 % à le spécifier. C'est l'inverse : 80 % de son temps va à la planification et à la revue, 20 % à l'exécution. Il devient un architecte de contexte plutôt qu'un producteur de lignes de code.

Un point crucial, souvent sous-estimé : ce contexte doit être versionné dans Git. Il n'est pas optionnel, il n'est pas secondaire. C'est un actif vivant, qui évolue avec l'application, qui doit être relu, challengé et enrichi à chaque cycle. Une organisation qui ne versionne pas son Context Engineering perd l'essentiel de la valeur de cette approche.

Compound Engineering : l'effet cumulatif comme moteur de vélocité

L'une des critiques récurrentes adressées à l'IA dans le développement logiciel est celle-ci : "Certes, elle accélère sur une feature isolée, mais elle accumule de la dette technique. Le codebase devient ingérable au bout de quelques mois."

Cette critique est juste — si l'IA est mal utilisée. Elle devient fausse lorsqu'on applique les principes du Compound Engineering.

Le Compound Engineering, c'est l'ingénierie cumulative : chaque unité de travail rend les suivantes plus faciles, pas plus difficiles. Chaque feature produite enrichit le contexte, documente les patterns adoptés, clarifie les règles implicites. Le savoir se codifie dans des formats réutilisables par l'IA et par les humains.

Concrètement, le workflow se structure autour de quatre phases qui se répètent et se renforcent mutuellement :

• Plan : transformer les intentions en plans d'implémentation détaillés, ancrés dans le contexte existant.
• Work : exécuter via des agents, avec un suivi précis des tâches et des décisions.
• Review : faire passer le code produit par une revue multi-agents avant tout merge — pas pour valider la syntaxe, mais pour vérifier la cohérence systémique.
• Compound : documenter les apprentissages, mettre à jour le contexte, capitaliser pour les cycles suivants.

C'est la phase Compound qui change tout. Dans un workflow traditionnel, une feature livrée, c'est un dossier fermé. Dans le Compound Engineering, c'est une contribution au capital de connaissance du projet. La vélocité ne stagne pas — elle s'accélère avec le temps.

Il existe une opposition utile pour illustrer cette différence :

• Spec-Driven (2025) : on demande à l'IA d'ajouter une fonctionnalité isolée. Sans contexte suffisant, elle la "colle" en façade. Le résultat : une verrue logicielle qui fragilise la cohérence de l'ensemble.
• Issue-Based (2026) : on signale un manque, un bug, un axe d'amélioration. L'IA analyse l'existant, mobilise le contexte versionné, et produit une solution qui respecte l'architecture et les conventions établies. Le résultat : une cohérence systémique maintenue cycle après cycle.

La règle d'or du Compound Engineering est simple : "Maintenir une qualité maximale aujourd'hui pour garantir la vélocité de demain." Ce qui semble être un investissement supplémentaire à court terme devient le principal facteur d'accélération sur la durée.

La Sandwich Team : anatomie d'un nouveau modèle organisationnel

Tout ce qui précède — Context Engineering, Compound Engineering, workflows agentiques — converge vers une réorganisation profonde de la manière dont on structure les équipes de développement.

La Pizza Team, popularisée par Amazon, reposait sur l'idée qu'une équipe ne devait pas dépasser ce qu'on pouvait nourrir avec deux pizzas — soit 6 à 8 personnes. C'était un progrès par rapport aux grandes équipes projet de l'ère waterfall. Mais c'est encore un modèle fondé sur la multiplication des spécialistes : un frontend, un backend, un data engineer, un DevOps, un product manager, un designer.

La Sandwich Team pose une question différente : combien de ces rôles peuvent être assumés par une seule personne augmentée par l'IA ?

La réponse, selon notre vision stratégique : 80 % du périmètre technique. Un seul développeur augmenté — l'App Owner — peut prendre la responsabilité de l'UX, de l'UI, du frontend, de l'API, du backend et d'une grande partie de la sécurité applicative. Ce n'est pas qu'il maîtrise toutes ces disciplines au niveau expert. C'est que l'IA comble en temps réel les lacunes techniques, à condition que le contexte soit suffisamment riche pour la guider.

L'image du "sandwich" est volontairement évocatrice :

• La couche supérieure : l'App Owner, porteur de la vision, responsable du contexte, décisionnaire sur l'architecture et la direction produit.
• Le cœur : l'IA agentique, moteur de production, capable de traverser les couches techniques sans friction.
• La couche inférieure : les contributeurs spécialisés (les 20 %), qui interviennent ponctuellement sur des sujets pointus — sécurité avancée, infrastructure critique, domaines métier complexes — mais ne constituent plus le flux principal de livraison.

Ce modèle supprime le principal ennemi de la vélocité : les délais de coordination interne. Quand une décision doit traverser 4 profils différents avant d'aboutir à une ligne de code, chaque interface est une source de friction, de perte de contexte et d'attente. Avec une Sandwich Team, l'Owner prend la décision, configure le contexte, et la machine exécute. Le délai entre l'intention et la production s'effondre.

Le Product Engineer : un nouveau profil pour un nouveau rôle

La Sandwich Team ne peut fonctionner que si l'App Owner est un profil différent de ce que l'industrie a formé jusqu'ici. Ce profil porte un nom : le Product Engineer.

Là où le Software Engineer traditionnel est un spécialiste d'une couche technique — expert frontend, expert backend, expert data — le Product Engineer est un généraliste augmenté. Sa valeur ne réside pas dans la profondeur de sa maîtrise d'un framework particulier, mais dans sa capacité à :

• Comprendre les enjeux métier et les traduire en intentions techniques claires.
• Construire et maintenir un environnement de Context Engineering robuste.
• Piloter des agents IA sur l'ensemble de la chaîne de valeur technique.
• Exercer un jugement critique sur les outputs de l'IA — déceler les incohérences, identifier les dettes cachées, valider la conformité systémique.
• Documenter les décisions pour capitaliser sur les cycles futurs.

Pour reprendre une métaphore du contexte source : là où le bûcheron traditionnel abattait lui-même, ébranchait, transportait — chaque spécialiste attendant le précédent — le Product Engineer coordonne une machine qui gère l'ensemble de la chaîne en continu. Son rôle n'est pas de disparaître dans l'opérationnel, mais d'orchestrer la production totale.

Ce profil exige un renouvellement des compétences. Ce ne sont pas tant les compétences techniques pures qui deviennent prioritaires — même si elles restent nécessaires pour exercer le jugement critique — mais les compétences de contexte : rédaction de specs précises, modélisation d'architectures, formalisation des règles métier, maîtrise des workflows agentiques. Des compétences à mi-chemin entre le product management et l'ingénierie logicielle, qui justifient pleinement ce titre de "Product Engineer".

Chez SFEIR, nous accompagnons nos clients dans cette transition de compétences — pas seulement en outillant les équipes, mais en les aidant à redéfinir les trajectoires de carrière, les critères d'évaluation et les modèles de recrutement qui permettent de faire émerger ces profils.

Les silos meurent, le flux s'impose

L'un des effets les plus significatifs de la Sandwich Team est la dissolution progressive des silos organisationnels. Le découpage traditionnel par spécialités — une équipe frontend, une équipe backend, une équipe infrastructure — est né d'une nécessité : la complexité technique de chaque couche nécessitait une expertise à plein temps. Ce découpage avait un coût invisible : le travail devait passer de main en main, générant des files d'attente, des réunions de synchronisation, des malentendus et des retravaux.

Dans le modèle Sandwich Team, ce découpage n'est plus la structure de base — il devient une ressource d'appoint. Les experts des 20 % restants interviennent en mode consultation, apportant leur spécialité au moment précis où elle est nécessaire, guidés par le contexte qui leur permet de contribuer sans phase d'onboarding coûteuse. C'est précisément pour cette raison que le contexte sauvegardé dans Git est une condition non négociable : il permet aux contributeurs ponctuels d'être opérationnels immédiatement, sans avoir besoin que l'Owner leur explique l'historique de chaque décision.

La métaphore de la chaîne de production forestière illustre bien cette évolution. Autrefois, plusieurs corps de métier se succédaient : le bûcheron abattait, le débardeur transportait, le scieur transformait — chacun attendant l'autre, chacun optimisant son propre segment sans vision de l'ensemble. Aujourd'hui, une machine moderne peut intégrer l'ensemble de ces opérations en un flux continu, piloté par un seul opérateur qui surveille, ajuste et coordonne. La valeur ne réside plus dans la vitesse de chaque étape isolée, mais dans la fluidité du flux total.

C'est exactement ce que vise la Sandwich Team : supprimer les temps d'attente inter-rôles, non pas en supprimant les rôles, mais en les fusionnant dans un flux piloté par l'intelligence — humaine et artificielle combinées.

Comment SFEIR accompagne la transition vers ce nouveau modèle

La Sandwich Team n'est pas un modèle qu'on déploie en claquant des doigts. Elle suppose une transformation à plusieurs niveaux que nos équipes accompagnent au quotidien chez nos clients.

Le premier niveau est l'outillage et l'environnement. Mettre en place un workflow de Context Engineering robuste, choisir les bons agents, configurer les pipelines de revue multi-agents, intégrer les outils de compound (comme le compound-engineering-plugin développé par la communauté) — tout cela représente un travail d'ingénierie en soi, qui demande de l'expérience et une vision claire des standards.

Le deuxième niveau est la montée en compétences. Former des Software Engineers à devenir des Product Engineers est un processus progressif. Il ne s'agit pas seulement d'apprendre à "utiliser ChatGPT pour coder". Il s'agit de changer de posture — passer de producteur à orchestrateur — et de maîtriser des disciplines nouvelles : rédaction de specs vivantes, gestion du contexte comme actif versionné, pilotage de workflows agentiques complexes.

Le troisième niveau est la transformation organisationnelle. Définir qui est l'App Owner d'une application, comment s'articulent les 80 % et les 20 %, comment les contributeurs spécialisés interviennent sans casser la fluidité du flux — ce sont des questions de design organisationnel qui touchent aux responsabilités, aux processus de gouvernance et aux modèles de collaboration. SFEIR intervient à ce niveau pour aider les DSI et les CTO à concevoir des structures d'équipes adaptées à leur contexte, leur culture et leurs contraintes.

Enfin, le quatrième niveau est la mesure de l'impact. L'objectif n'est pas d'être "moderne" — c'est de livrer plus de valeur métier, plus vite, avec une meilleure qualité systémique. Cela suppose de définir des indicateurs adaptés : pas seulement la vélocité sprint, mais la réduction des délais de coordination, la qualité du Context Engineering (couverture, précision, fraîcheur), la trajectoire de la dette technique dans le temps.

Ce que ce changement signifie pour l'avenir du développement logiciel

La Sandwich Team, le Product Engineer, le Compound Engineering — ce ne sont pas des concepts isolés. Ils forment un système cohérent qui répond à une question fondamentale : quelle est la nature du travail de développement logiciel à l'ère des agents IA ?

La réponse qui se dessine est celle-ci : le développement logiciel devient une activité principalement cognitive et stratégique. La partie mécanique — écrire du code, assembler des composants, tester des configurations — se délègue progressivement à la machine. Ce qui reste irréductiblement humain, c'est la compréhension du problème, la définition des contraintes, le jugement sur la qualité, et la responsabilité des décisions d'architecture.

Cela ne signifie pas que les développeurs disparaissent — bien au contraire. Cela signifie que leur rôle monte en abstraction et en valeur. Un bon Product Engineer dans une Sandwich Team produit potentiellement autant de valeur qu'une équipe entière d'hier — non pas parce qu'il travaille plus, mais parce qu'il travaille à un niveau d'abstraction différent, avec des outils qui démultiplient son impact.

Pour les organisations, l'enjeu est de saisir cette opportunité sans tomber dans deux erreurs symétriques : ne rien changer (et perdre le bénéfice d'un saut de productivité historique) ou changer trop vite et trop brutalement (et créer de la désorganisation sans construire les nouvelles fondations). La trajectoire raisonnable est une transformation progressive, outillée, accompagnée — avec une vision claire de la cible et une discipline rigoureuse sur la méthode.

C'est exactement la mission que SFEIR se donne avec sa stratégie AI for IT : aider les organisations à passer du code à la valeur, des silos au flux, de la production à l'orchestration. Pas en dix ans. Maintenant.