SFEIR
App Owner Concept

App Owner

Notion de février 2026 : une personne augmentée par l'IA qui porte 80 % de l'application. La doctrine SFEIR a depuis évolué vers le binôme.

SFEIR AI · Publié le 16 juillet 2026 · Mis à jour le 21 octobre 2026

Qu'est-ce qu'un App Owner

L'App Owner est le nom que la présentation AI for IT : la stratégie du 10x (Didier Girard, Directeur Général de SFEIR, février 2026) donne à la configuration à une personne de la Sandwich Team : un seul développeur augmenté est owner de 80 % de l'application, soit l'UX, l'UI, le front, l'API, le back et la sécurité. Il est responsable de la vision et de la production via l'IA, décrite comme le partenaire constant qui comble ses lacunes. Les contributeurs, 20 %, interviennent à la demande via le contexte qui guide l'application, que la présentation demande de sauvegarder dans Git.

Cette configuration est une étape que la doctrine SFEIR a dépassée. À la conférence Reboot with AI (Montpellier, 1er octobre 2026), Didier Girard décrit la Sandwich Team comme un binôme de deux Product Engineers, l'un au barycentre métier, l'autre au barycentre ingénierie, avec une brigade d'agents entre eux. La personne seule reste la configuration la plus productive, et il explique pourquoi il ne la retient pas : elle est performante mais pas robuste. Son code n'est pas reprenable, et un seul regard au passe (le moment où l'on goûte ce que les agents ont produit avant de l'envoyer) ne suffit pas. À deux, l'équipe perd un peu de performance et gagne beaucoup en robustesse. SFEIR présente ce choix comme une configuration observée sur le terrain, et non comme une règle universelle.

Cette fiche garde la trace de la notion telle que les textes de février à avril 2026 l'ont posée. Le modèle d'équipe actuel est décrit dans la fiche Sandwich Team, et le profil qui tient chacune des deux places dans la fiche Product Engineer ; l'article Product Engineer : le nouveau rôle qui fusionne toutes les spécialités (avril 2026) écrivait que le Product Engineer devient ce que la stratégie SFEIR appelle un App Owner.

D'où vient le terme, et pourquoi la doctrine a évolué

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 (8 personnes, coordination en N²) et une équipe construite autour d'une seule personne augmentée, avec zéro délai de coordination interne. La présentation parlait de restructurer les équipes en single owners.

L'article Sandwich Team et Product Engineer : la nouvelle équipe 10x (Didier Girard, mars 2026) donnait au modèle sa première image : le contexte structuré au-dessus (specs, conventions, architecture), l'exécution par les agents en dessous, l'App Owner au milieu pour le sens et le jugement. La formule courte était 1 + N, un App Owner et N contributeurs occasionnels, N valant zéro certaines semaines, où l'App Owner pilotait seul ses agents, produisait, revoyait, itérait, en cycles de un à trois jours.

Observée sur le terrain, cette configuration s'est révélée performante mais fragile, et SFEIR a posé le binôme comme cible. L'article d'Olivier Rafal (WEnvision, le cabinet de conseil du groupe SFEIR) dans CIO-Online, le 1er juin 2026, décrit des binômes resserrés, expert métier et tech lead augmenté, qui pilotent environ 80 % de la chaîne de production avec l'expertise centrale en appui. La slide présentée à Reboot with AI en octobre 2026 fixe la forme actuelle : deux tranches humaines, le métier et la tech, et la brigade d'agents au milieu.

Ce que couvrait le rôle

L'article de mars 2026 détaille les six dimensions du périmètre confié à l'App Owner. Dans chacune, il décide et valide, les agents produisent.

  • UX : il traduit les besoins utilisateurs en parcours et arbitre les compromis d'ergonomie ; les agents génèrent les variantes, il choisit et affine.
  • UI : il maintient le système de design ; les agents produisent le code des composants, il valide l'intention et l'accessibilité.
  • Front : il pilote l'architecture front et les performances ; les agents écrivent le code, il structure le contexte qui tient les pages ensemble.
  • API : il conçoit les contrats d'interface et garantit la rétrocompatibilité ; les agents génèrent les endpoints, il vérifie que le contrat métier est respecté.
  • Back : il architecture les services, les modèles de données et la logique métier ; les agents implémentent, il garde l'architecture propre et évolutive.
  • Sécurité : il définit les politiques, les contrôles d'accès et le chiffrement ; les agents auditent le code produit, il arbitre les risques et les remédiations.

Comment le rôle fonctionnait

Dans la présentation de février 2026 et l'article de mars 2026, le temps de l'App Owner suit le partage du Compound Engineering : 80 % en planification et revue, 20 % en exécution. Il rédige la spécification de l'itération, lance les agents, vérifie le résultat par les tests automatisés et les audits, puis enrichit le contexte avec les leçons du cycle. La présentation le compare au bûcheron qui coordonne une machine : la machine abat, ébranche et sort le bois seule, lui dirige la production totale et doit connaître la forêt pour l'envoyer au bon endroit. Le binôme d'aujourd'hui suit le même workflow, avec deux regards au passe au lieu d'un (voir la fiche Sandwich Team).

Erreurs courantes

L'analyse SFEIR du rapport DORA 2025 (décembre 2025) décrit le développeur passé de créateur à vérificateur, le cerveau en mode contrôle et critique, et nomme le risque : la fatigue décisionnelle, quand relire des milliers de lignes par jour use l'attention. L'article de mars 2026 en tire une règle pour l'App Owner : 90 % des vérifications doivent être automatiques (tests, linting, CI/CD ultra-robuste), pour que les 10 % restants soient des décisions de jugement.

Deuxième piège, lire le titre comme celui d'un développeur full-stack. Le mot owner désigne une responsabilité, la vision et la production de l'application. L'expertise de chaque couche vient de l'IA, qui comble les lacunes en temps réel à condition que le contexte soit assez riche pour la guider (article La Sandwich Team : 1 App Owner pour 80% du périmètre technique, avril 2026).

Troisième piège, celui qui a fait évoluer la doctrine : rester à une personne. C'est la configuration la plus productive et la moins robuste, avec un code non reprenable et un seul regard au passe. Depuis Reboot with AI (octobre 2026), le binôme de deux Product Engineers est la cible.

Ce que SFEIR en fait

En février 2026, SFEIR faisait de ce rôle l'unité de base de la Software Factory 10x. L'unité de base est aujourd'hui le binôme de deux Product Engineers décrit dans la fiche Sandwich Team. Les deux portes d'entrée restent les mêmes : un projet pilote à périmètre limité, le projet preuve de huit semaines, et la formation de deux jours Développeur augmenté par l'IA, annoncée dans la présentation de février 2026 et adaptée à l'environnement technologique du client.

Questions fréquentes

Qu'est-ce qu'un App Owner ?

Le nom donné, dans la présentation AI for IT de février 2026, à la configuration à une personne de la Sandwich Team : un développeur augmenté par l'IA porte environ 80 % de l'application (UX, UI, front, API, back, sécurité), des contributeurs occasionnels complétant les 20 % restants via un contexte partagé. La doctrine SFEIR a depuis évolué vers un binôme de deux Product Engineers.

Pourquoi SFEIR est-il passé de l'App Owner au binôme ?

Parce qu'une personne seule est performante mais pas robuste : son code n'est pas reprenable et un seul regard au passe ne suffit pas. À deux, l'équipe perd un peu de performance et gagne beaucoup en robustesse. Didier Girard l'a expliqué à Reboot with AI (Montpellier, 1er octobre 2026) ; SFEIR le présente comme une configuration observée, non comme une règle universelle.

L'App Owner est-il un développeur full-stack ?

Le titre désigne une responsabilité, la vision et la production de 80 % de l'application, et non une expertise de chaque couche. L'IA comble les lacunes techniques en temps réel, à condition que le contexte versionné soit assez riche pour la guider.

Quelle différence entre App Owner et Product Engineer ?

L'App Owner désignait, en février 2026, la configuration à une seule personne responsable de 80 % de l'application ; l'article d'avril 2026 écrivait que le Product Engineer devient ce que la stratégie SFEIR appelle un App Owner. Aujourd'hui, la Sandwich Team réunit deux Product Engineers, l'un au barycentre métier, l'autre au barycentre ingénierie, et le Product Engineer est le profil qui tient chacune des deux places.

Que couvraient les 20 % restants ?

Les sujets pointus où un spécialiste intervient à la demande : audit de sécurité avancée, infrastructure critique, domaine métier complexe. Le contributeur trouve le contexte dans Git, contribue et repart, sans onboarding coûteux. Le binôme d'aujourd'hui garde ce principe : il pilote environ 80 % de la chaîne et l'expertise centrale reste en appui.

Quel est le principal risque pour un App Owner ?

La fatigue décisionnelle, identifiée par l'analyse SFEIR du rapport DORA 2025 : passé de créateur à vérificateur, il relit des milliers de lignes par jour. La parade est d'automatiser 90 % des vérifications pour réserver son attention aux décisions de jugement.

Pourquoi le contexte doit-il être sauvegardé dans Git ?

Parce que les contributeurs occasionnels interviennent via ce contexte : specs, conventions, décisions d'architecture. Versionné dans Git, il les rend opérationnels sans que l'App Owner ait à réexpliquer l'historique de chaque décision.

Sources

App Owner dans vos projets

Échanger avec SFEIR

Articles liés