Projet Preuve : livrer un premier résultat IA en 8 semaines
Le constat qui dérange : l'amélioration continue ne suffit plus
Combien de fois avons-nous entendu cette promesse dans les salles de réunion ? « Avec cette nouvelle méthodologie, nous allons gagner 15 % de productivité. » Les équipes s'enthousiasment, les sprints se succèdent, les rétrospectives s'accumulent — et pourtant, le backlog reste obstinément plein. Les délais de livraison stagnent. La dette technique grossit silencieusement.
Chez SFEIR, nous avons une conviction qui peut surprendre au premier abord : chercher des gains marginaux est une erreur de stratégie. Non pas parce que l'optimisation est inutile, mais parce qu'elle répond à la mauvaise question. À l'heure où l'IA générative redessine fondamentalement ce que signifie « produire un logiciel », viser quelques pourcents de gain revient à polir les roues d'une calèche pendant qu'on invente l'automobile.
La vraie question n'est pas comment coder plus vite, mais comment changer d'échelle dans la création de valeur métier. C'est précisément l'ambition du Projet Preuve : livrer un premier résultat IA tangible, en production, en huit semaines. Pas une démonstration. Pas un POC éphémère. Un résultat réel, avec une équipe restructurée et une méthodologie reproductible.
Pourquoi « écrire du code » est devenu un anti-pattern
La formulation choque, et c'est voulu. Didier Girard, CTO de SFEIR, le pose clairement : « Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. »
Pour comprendre cette affirmation, il faut distinguer deux philosophies de production radicalement différentes.
Dans l'approche traditionnelle, le développeur est un artisan : il produit du code ligne à ligne, corrige les sorties au fil des itérations, et consacre l'essentiel de son énergie à la finition des pièces. L'IA, dans ce schéma, est un outil d'assistance ponctuelle — un autocomplete glorifié.
Dans l'approche IA agentique, le paradigme s'inverse. Le développeur configure la machine en amont, travaille les « réglages » — autrement dit, les prompts et le contexte — et garantit la conformité dès la production, plutôt que de corriger après coup. Il passe du rôle d'exécutant à celui d'architecte du contexte.
Ce changement de posture n'est pas cosmétique. Il implique une refonte complète de ce que l'on considère comme la compétence centrale d'une équipe technique. Et c'est là qu'intervient le concept clé sur lequel repose toute notre approche : le Context Engineering.
Le Context Engineering : le nouvel actif stratégique de l'IT
Si le code n'est plus la valeur principale, qu'est-ce qui la remplace ? La réponse tient en deux mots : le contexte.
Le Context Engineering, c'est l'art de construire un environnement structuré — spécifications en markdown, règles métier explicites, décisions d'architecture documentées, exemples de patterns attendus — pour permettre à l'IA de produire un code cohérent, maintenable et exempt des hallucinations qui polluent les projets moins rigoureux.
Concrètement, cela signifie qu'avant d'écrire la moindre ligne de code, une équipe appliquant cette méthode investit du temps pour :
- Transformer les idées et les exigences métier en plans d'implémentation détaillés (phase PLAN)
- Exécuter via des worktrees et un task tracking précis (phase WORK)
- Organiser une revue de code multi-agents avant tout merge (phase REVIEW)
- Documenter les apprentissages pour les cycles futurs (phase COMPOUND)
Ce dernier point est crucial, et souvent négligé. Chaque cycle ne produit pas seulement du code — il produit du contexte capitalisable. C'est la différence entre une IA qui accumule de la dette technique et une ingénierie qui s'améliore de manière cumulative.
Une règle d'or s'impose dans ce cadre : le Context Engineering doit être versionné. Les fichiers de contexte, les specs, les règles métier — tout cela doit vivre dans Git, au même titre que le code source. Non par formalisme, mais parce que c'est ce contexte qui permet à n'importe quel contributeur futur — humain ou agent IA — de comprendre les intentions derrière le système.
Spec-Driven vs Issue-Based : une distinction qui change tout
Pour illustrer concrètement la maturité du Context Engineering, prenons un exemple parlant. Imaginez qu'un client souhaite ajouter une fonctionnalité de gestion des notifications à son application.
En mode Spec-Driven — la pratique courante en 2024-2025 — on demande à l'IA d'ajouter cette fonctionnalité isolément. L'IA produit quelque chose qui fonctionne en apparence, mais qui a été « collé » sur l'architecture existante sans en comprendre les contraintes. Résultat : une verrue logicielle, un module orphelin qui diverge des conventions du projet et qui sera douloureux à maintenir.
En mode Issue-Based — la cible 2026 — on ne demande pas une feature. On signale un manque, un comportement attendu non satisfait. L'IA analyse l'existant, exploite le contexte versionné, comprend les patterns de l'application et produit une solution cohérente avec l'ensemble du système. Le résultat n'est plus une addition, c'est une intégration.
La différence entre ces deux approches, c'est précisément la richesse du contexte disponible au moment de la génération.
Le Compound Engineering : quand chaque cycle accélère le suivant
L'une des idées les plus puissantes — et les moins intuitives — de cette méthodologie est celle du Compound Engineering, ou ingénierie cumulative.
Dans un projet traditionnel, chaque nouvelle feature ajoute une couche de complexité. Le codebase grossit, les interdépendances se multiplient, la vélocité ralentit. C'est la courbe naturelle de tout projet logiciel mal maîtrisé : on avance vite au début, on rampe à la fin.
Le Compound Engineering inverse cette dynamique. Chaque unité de travail est conçue pour rendre les suivantes plus faciles. Comment ? En codifiant systématiquement le savoir acquis — décisions d'architecture, patterns validés, edge cases rencontrés — dans le contexte partagé de l'équipe. Ce contexte, réutilisable par l'IA comme par les humains, devient un multiplicateur de vélocité.
La répartition du temps s'en trouve radicalement modifiée : 80 % du temps est consacré au planning et à la revue, 20 % à l'exécution du code. Pour un développeur habitué à « coder » comme activité principale, c'est un renversement complet. Mais la logique est implacable : maintenir une qualité maximale aujourd'hui, c'est garantir la vélocité de demain.
L'analogie industrielle aide à comprendre le principe. Imaginez un bûcheron qui abat des arbres, un débardeur qui les transporte, un scieur qui les transforme — chacun attendant l'autre, générant des temps morts et des frictions. C'est le modèle en silos que connaissent la plupart des DSI. Avec le Compound Engineering et les outils IA, la machine abat, ébranche et sort le bois seule. Le bûcheron coordonne la production totale. L'objectif : supprimer les temps morts, pas les humains.
La Sandwich Team : repenser l'organisation pour débloquer le x10
Si la méthodologie change, l'organisation doit changer avec elle. C'est là qu'intervient le concept de Sandwich Team — probablement la proposition la plus disruptive de cette stratégie, et celle qui génère le plus de débats.
L'héritage organisationnel de l'IT, c'est la Pizza Team : une équipe de 6 à 8 personnes, découpée par spécialités (front, back, data, QA, DevOps...), qui se coordonne via des tickets, des stand-ups et des sprints. Ce modèle a été conçu pour une époque où chaque spécialité représentait un goulot d'étranglement irréductible.
Mais cette organisation a un coût invisible considérable : la complexité de coordination. Chaque handoff entre spécialistes est une source de délai, de perte d'information et de friction. Un développeur front attend le contrat d'API du back. Le back attend les specs UX. L'UX attend le retour métier. La somme de ces attentes représente, dans beaucoup de projets, plus de temps que le développement lui-même.
La Sandwich Team répond à ce problème par une proposition radicale : un seul développeur augmenté, l'App Owner, doit être responsable de 80 % de l'application — UX, UI, front, API, back et sécurité. L'IA est le partenaire constant qui comble ses lacunes sur les domaines qu'il maîtrise moins. Les contributeurs spécialisés interviennent ponctuellement, pour les 20 % restants, guidés par le contexte versionné qui leur permet de s'intégrer sans friction.
L'App Owner : un nouveau métier à inventer
Ce rôle d'App Owner est la fusion de deux figures jusqu'alors distinctes : le Product Engineer et le Software Engineer. Il ne s'agit pas d'un développeur full-stack au sens classique — quelqu'un qui code dans toutes les couches. Il s'agit d'un profil qui comprend toutes les couches suffisamment pour configurer l'IA de manière pertinente sur chacune d'elles, et qui porte la vision de cohérence de l'ensemble.
C'est une évolution profonde des métiers de l'IT. Les silos par spécialités ne disparaissent pas — l'expertise reste nécessaire — mais ils ne structurent plus le flux de travail quotidien. On passe d'une équipe qui attend la livraison à une équipe qui dévore le backlog.
Pour nos clients, cela se traduit concrètement par une question RH et organisationnelle autant que technique : comment identifier, former et positionner ces App Owners ? Comment accompagner les experts spécialisés dans cette évolution vers un rôle de contributeur contextuel plutôt que d'exécutant séquentiel ? C'est un chantier de transformation que SFEIR accompagne en parallèle de la transformation technique.
Le Projet Preuve : 8 semaines pour démontrer le possible
La théorie est séduisante. Mais la vraie question est : est-ce que ça marche, en conditions réelles, sur un vrai projet client ?
C'est précisément l'objet du Projet Preuve, la modalité d'engagement que SFEIR propose pour incarner cette stratégie. L'objectif n'est pas de vendre une transformation pluriannuelle abstraite. C'est de livrer un premier résultat concret en 8 semaines, qui démontre la viabilité du modèle et crée une irréversibilité positive dans l'organisation.
Le déroulé type d'un Projet Preuve se décompose en trois phases distinctes.
Phase 1 — Cadrage et construction du contexte (semaines 1-2)
Avant de toucher à la moindre ligne de code, l'équipe investit deux semaines entières dans la construction du contexte. On audite l'existant technique et métier, on formalise les règles de gestion en markdown structuré, on documente les décisions d'architecture, on définit les patterns attendus. Ce travail est versionné dans Git dès le premier jour.
C'est aussi pendant cette phase que l'on identifie l'App Owner — le profil qui sera le pivot humain du projet — et que l'on configure l'environnement IA agentique : choix des outils, des modèles, des pipelines de revue automatisée.
Phase 2 — Cycles de développement agentique (semaines 3-6)
Les quatre semaines suivantes sont organisées en cycles courts de PLAN → WORK → REVIEW → COMPOUND. Chaque cycle produit du code, mais aussi et surtout du contexte enrichi. L'App Owner pilote, les agents exécutent, la revue multi-agents garantit la qualité avant tout merge.
La mesure de vélocité est suivie cycle après cycle. L'effet Compound Engineering commence à se manifester à partir du deuxième ou troisième cycle : le contexte accumulé permet à l'IA de produire des solutions mieux intégrées, nécessitant moins de corrections, en moins de temps.
Phase 3 — Livraison et capitalisation (semaines 7-8)
Les deux dernières semaines sont consacrées à la mise en production du résultat, à la stabilisation, et surtout à la documentation de la méthodologie appliquée. L'objectif est que l'organisation cliente soit autonome pour reproduire l'approche sur d'autres périmètres. Le contexte versionné, les patterns validés, les décisions documentées — tout cela reste dans le repository et appartient au client.
Ce point est important : le Projet Preuve ne crée pas de dépendance. Il crée de la capitalisation.
Ce que les équipes vivent concrètement : les résistances et comment les dépasser
Il serait malhonnête de présenter cette transformation comme sans friction. Dans les projets que nous accompagnons, plusieurs résistances reviennent systématiquement, et il est utile de les nommer.
La résistance identitaire des développeurs expérimentés. Pour un senior qui a construit son expertise sur dix ans de code maîtrisé, entendre que « coder manuellement est un anti-pattern » peut se vivre comme une dévalorisation. Il est essentiel de recadrer : ce qui est valorisé, c'est la compréhension profonde du système, la capacité à définir des contextes riches, le jugement sur la qualité de ce que l'IA produit. L'expertise technique reste indispensable — elle s'exprime différemment.
La tentation de revenir au code manuel sous pression. Quand un délai se resserre, le réflexe naturel est de « reprendre la main » et de coder directement. C'est presque toujours une erreur dans ce modèle : le code produit hors contexte crée une dette qui ralentit les cycles suivants. La discipline du Compound Engineering exige de maintenir la rigueur du processus même — surtout — sous pression.
La sous-estimation du travail de contexte. Beaucoup d'équipes démarrent en pensant que la construction du contexte est une formalité qu'on expédie en quelques heures. La réalité est que c'est la partie la plus exigeante intellectuellement, et celle qui détermine la qualité de tout ce qui suit. SFEIR accompagne systématiquement cette phase avec des facilitateurs expérimentés.
La perspective SFEIR : accompagner la transformation, pas juste les outils
Il existe une tentation répandue de réduire cette révolution à une question d'outils : « Il suffit d'adopter Cursor, ou Claude, ou Copilot, et on obtient le x10. » C'est une erreur que nous voyons régulièrement.
Les outils sont nécessaires, mais insuffisants. Ce qui fait la différence, c'est la combinaison d'une méthodologie rigoureuse (le Context Engineering, le Compound Engineering), d'une organisation adaptée (la Sandwich Team, le rôle d'App Owner) et d'un accompagnement humain pour traverser la période de transformation.
Chez SFEIR, notre rôle dans un Projet Preuve est triple. Nous apportons l'expertise méthodologique — comment structurer le contexte, comment configurer les pipelines agentiques, comment mesurer la vélocité réelle. Nous apportons l'expertise organisationnelle — comment identifier et développer les App Owners, comment faire évoluer les rôles existants. Et nous apportons la continuité : nous restons jusqu'à ce que l'équipe soit autonome, pas jusqu'à ce que la démonstration soit satisfaisante.
Avec plus de 850 consultants spécialisés en IA, Cloud et Data, SFEIR a la capacité d'intervenir sur l'ensemble de la chaîne — des choix d'infrastructure qui supportent les agents, aux pratiques de développement, en passant par la gouvernance des données qui nourrit le contexte. Cette vision intégrée est un avantage concret pour les clients qui veulent éviter les transformations en silos.
Le moment est maintenant
L'urgence du shift n'est pas une posture commerciale. Elle est structurelle. Les organisations qui engagent cette transformation aujourd'hui ne construisent pas seulement une meilleure façon de livrer des logiciels — elles construisent un avantage compétitif cumulatif. Chaque cycle de Compound Engineering qui passe enrichit leur contexte, accélère leur vélocité, et creuse l'écart avec ceux qui continuent à optimiser marginalement leurs pratiques actuelles.
À l'inverse, attendre que « la technologie soit plus mature » ou que « les équipes soient prêtes » est une stratégie de retard déguisée en prudence. La technologie est suffisamment mature aujourd'hui pour livrer des résultats réels en huit semaines. Les équipes se préparent en faisant, pas en attendant.
Le Projet Preuve est conçu précisément pour répondre à cette hésitation légitime : avant de s'engager dans une transformation de grande ampleur, voyez ce que le modèle produit sur un périmètre réel, en conditions réelles, avec vos équipes réelles. Si le résultat est là au bout de huit semaines — et notre conviction est qu'il le sera — la décision de la suite devient beaucoup plus simple.
La production manuelle de code n'est pas près de disparaître du jour au lendemain. Mais elle est en train de devenir ce qu'était la compilation manuelle dans les années 80 : une curiosité historique pour les générations futures, qui se demanderont comment on a pu travailler autrement.
La question n'est pas si votre organisation va faire cette transition. C'est quand, et dans quel ordre par rapport à vos concurrents.