AI Champions : comment SFEIR forme 850 consultants augmentés

Le constat qui dérange : l'amélioration continue ne suffit plus

Il y a quelques mois, Didier Girard, CTO de SFEIR, a posé une affirmation qui a fait l'effet d'une douche froide dans les équipes techniques : "Écrire du code est désormais un anti-pattern." Pas une hyperbole. Pas une formule de scène. Une conviction stratégique profonde, qui structure aujourd'hui toute l'approche de SFEIR pour 2026.

Le raisonnement est implacable. Chercher à gratter quelques pourcents de productivité sur les workflows existants, c'est optimiser un modèle fondamentalement dépassé. Les équipes qui se contentent d'intégrer Copilot pour auto-compléter du code, ou qui demandent à ChatGPT de rédiger des fonctions isolées, ne font qu'accélérer une machine mal réglée. Elles accumulent de la dette technique plus vite, sans changer la nature du problème.

La vraie question n'est pas comment aller un peu plus vite ? Elle est comment changer complètement d'échelle ? Et la réponse de SFEIR tient en un chiffre : 10x.

Ce n'est pas un objectif marketing. C'est une philosophie de transformation qui implique de repenser le rôle du développeur, la structure des équipes, la nature même de ce qu'on versionne dans Git. Et pour que cette transformation soit réelle — pas seulement théorique — SFEIR a décidé de la vivre de l'intérieur, en formant ses 850 consultants à devenir ce que nous appelons des AI Champions.

De la production de code au Context Engineering

Le premier basculement conceptuel à opérer est peut-être le plus difficile, car il touche à l'identité même du développeur. Pendant des décennies, la valeur d'un ingénieur logiciel s'est mesurée à sa capacité à produire du code : proprement, rapidement, avec les bons patterns. Cette compétence reste précieuse. Mais elle n'est plus le cœur de la valeur créée.

Dans un paradigme IA agentique, le cœur de la valeur se déplace vers le contexte. Ce que l'on appelle le Context Engineering, c'est l'art de construire un environnement structuré — fichiers markdown, spécifications métier, règles d'architecture, contraintes de sécurité — qui permet à un agent IA de produire du code conforme, cohérent, et directement intégrable. Sans hallucinations. Sans retouches interminables.

La différence avec l'approche traditionnelle est fondamentale :

• Approche traditionnelle : on écrit du code, on corrige les sorties de l'IA ("l'ébarbage"), on passe du temps à finir les pièces une par une.
• Approche IA agentique : on configure la machine en amont, on travaille les réglages (prompts, contexte, règles), et on garantit la conformité dès la production.

Concrètement, cela signifie qu'un consultant SFEIR formé à cette approche passera moins de temps à écrire des fonctions et plus de temps à architecturer le contexte dans lequel l'IA va les produire. Les fichiers de contexte — spécifications, décisions d'architecture, contraintes métier — deviennent des actifs stratégiques versionnés dans Git, au même titre que le code lui-même. Ce n'est pas une commodité : c'est la règle d'or.

Le Compound Engineering : quand chaque sprint rend le suivant plus rapide

Il y a une tendance naturelle, quand on utilise l'IA pour développer, à traiter chaque tâche de manière isolée. On ouvre une conversation, on génère du code, on ferme. Cette approche produit certes du code rapidement, mais elle manque l'essentiel : l'effet cumulatif.

Le Compound Engineering — ou ingénierie cumulative — est l'un des concepts centraux de la stratégie SFEIR. L'idée est simple mais puissante : chaque unité de travail doit rendre les suivantes plus faciles, pas plus complexes. C'est l'exact opposé de ce qui se passe quand l'IA est mal utilisée, où chaque feature ajoutée devient un nouveau vecteur de dette technique.

Le workflow qui incarne cette philosophie s'articule en cinq temps :

• PLAN : transformer les idées en plans d'implémentation détaillés avant toute ligne de code.
• WORK : exécuter via des worktrees et un task tracking précis, en laissant l'IA opérer dans un contexte bien balisé.
• REVIEW : soumettre le code à une revue multi-agents avant le merge — l'IA peut aussi jouer le rôle du reviewer.
• COMPOUND : documenter les apprentissages, les décisions, les patterns émergents pour enrichir le contexte futur.
• REPEAT : chaque cycle informe et accélère le suivant.

Ce que ce workflow produit, c'est une forme de mémoire institutionnelle augmentée. Le contexte s'enrichit sprint après sprint. Les agents IA disposent d'une base de connaissance de plus en plus précise sur le produit, l'architecture, les contraintes métier. La vélocité augmente non pas malgré la qualité, mais grâce à elle.

La répartition du temps en découle logiquement : 80% sur le planning et la revue, 20% sur l'exécution du code. Un ratio qui surprend les équipes habituées à l'inverse, mais qui fait toute la différence entre un codebase qui vieillit bien et un codebase qui devient un frein.

Pour accompagner concrètement cette approche, SFEIR s'appuie notamment sur des outils open source comme le Compound Engineering Plugin, qui matérialise ce workflow dans l'environnement de développement quotidien.

La Stack AI-Ready : les fondations techniques d'un consultant augmenté

Parler de paradigme et de philosophie, c'est nécessaire. Mais pour que 850 consultants opèrent réellement en mode augmenté, il faut des fondations techniques concrètes. C'est ce que SFEIR appelle la Stack AI-Ready — l'ensemble des pratiques, outils et réflexes qui permettent à un ingénieur de travailler efficacement avec des agents IA sur des projets réels, en production.

Cette stack repose sur plusieurs piliers :

Des environnements de contexte structurés

La première brique, c'est apprendre à construire des dossiers de contexte robustes. Un consultant AI-Ready sait qu'un agent IA est aussi bon que le contexte qu'on lui fournit. Il maîtrise la rédaction de fichiers de spécifications en markdown, la structuration des règles métier, la documentation des décisions d'architecture (ADR). Ces documents ne sont pas des livrables de fin de projet : ce sont des inputs permanents pour les agents.

La distinction Spec-Driven vs Issue-Based

Un anti-pattern courant en 2025 : demander à l'IA d'ajouter une fonctionnalité isolée sans considération pour le reste du système. On obtient ce que l'on pourrait appeler une verrue logicielle — une feature collée sur la façade qui ne s'intègre pas organiquement à l'existant.

L'approche Issue-Based, que SFEIR privilégie, part du problème : on signale un manque, un bug, une opportunité d'amélioration. L'agent analyse l'existant, utilise le contexte disponible, et propose une solution cohérente avec l'ensemble du système. Le résultat n'est pas une feature ajoutée — c'est une cohérence systémique préservée.

La maîtrise des agents et des worktrees

Un consultant AI-Ready ne se contente pas d'utiliser un LLM en mode chat. Il sait orchestrer des agents sur des tâches parallèles, utiliser les worktrees Git pour isoler les branches de travail, configurer des pipelines de revue multi-agents. Ce sont des compétences d'infrastructure de développement, pas seulement de prompt engineering.

Le versioning du contexte comme discipline

Enfin — et c'est peut-être la discipline la plus difficile à installer — la stack AI-Ready implique de versionner systématiquement tout ce qui constitue le contexte : spécifications, prompts système, règles métier, décisions d'architecture. Le contexte est un asset vivant. Ne pas le versionner, c'est perdre la mémoire de la machine.

Le Product Engineer : la fusion des silos en un seul rôle augmenté

L'une des transformations les plus profondes que la stratégie AI for IT implique, c'est l'évolution des métiers. Pendant des années, les équipes IT ont fonctionné en silos spécialisés : frontend, backend, UX, API, sécurité, DevOps. Chaque spécialiste gérait sa portion du système, et le travail passait de main en main — avec les temps d'attente, les frictions de communication, les incompréhensions qui en découlent.

L'image qu'utilise Didier Girard est parlante : "Le bûcheron abat, le débardeur transporte, le scieur transforme... chacun attend l'autre." Ce modèle a du sens quand chaque opération requiert une expertise humaine irremplaçable. Mais quand une machine IA peut combler les lacunes d'un généraliste sur la plupart des spécialités techniques, l'équation change radicalement.

Émerge alors le concept de Product Engineer — une évolution du Software Engineer traditionnel vers un profil qui embrasse l'ensemble de la chaîne : UX, UI, frontend, API, backend, sécurité. Non pas parce qu'il est expert en tout, mais parce qu'il est capable de coordonner l'IA sur l'ensemble de ces dimensions.

La métaphore s'inverse : "La machine abat, ébranche et sort le bois seule. Le bûcheron coordonne la production totale."

Ce n'est pas la mort du spécialiste. C'est la naissance d'un nouveau rôle de coordination et de vision, où l'expertise technique reste indispensable — mais s'exprime différemment. Le Product Engineer n'écrit pas chaque ligne. Il dirige la machine, maintient la cohérence du système, prend les décisions d'architecture, et assume la responsabilité de la qualité finale.

La Sandwich Team : repenser la structure des équipes

Si le Product Engineer redéfinit le rôle individuel, la Sandwich Team redéfinit la structure collective. Et là encore, le changement est radical.

La Pizza Team — popularisée par Amazon — était la réponse aux équipes trop grandes des années 2000 : garder les équipes suffisamment petites pour les nourrir avec deux pizzas. Huit personnes environ. Agile, autonome, pluridisciplinaire. C'était une bonne réponse pour l'époque.

La Sandwich Team pousse le curseur beaucoup plus loin. Dans ce modèle, un seul développeur augmenté — l'App Owner — prend en charge 80% de l'application : UX, UI, frontend, API, backend, sécurité. L'IA est son partenaire constant, qui comble ses lacunes et exécute ce qu'il orchestre. Des contributeurs spécialisés interviennent ponctuellement sur les 20% restants, guidés par le contexte partagé dans Git.

Ce modèle présente des avantages considérables :

• Zéro délai de coordination interne : pas de handoff, pas de réunions de synchronisation entre silos, pas d'attente.
• Vision cohérente : une seule personne porte la vision produit et technique, ce qui élimine les frictions d'interprétation.
• Vélocité maximale : on passe d'une équipe qui attend la livraison à une équipe qui dévore le backlog.
• Contexte toujours disponible : puisque le contexte est versionné dans Git, les contributeurs ponctuels peuvent intervenir sans phase longue d'onboarding.

Pour nos clients, cela se traduit par une capacité à livrer plus de valeur métier en moins de temps, avec des équipes plus petites et plus alignées. C'est aussi un changement de posture : l'App Owner n'est plus un exécutant qui attend les specs. C'est un entrepreneur du produit, responsable de bout en bout.

AI Champions : comment SFEIR embarque 850 consultants dans la transformation

Théoriser une transformation est une chose. La déployer à l'échelle de 850 consultants en est une autre. C'est précisément le défi que SFEIR s'est donné avec le programme AI Champions.

L'idée fondatrice est simple : on ne peut pas accompagner nos clients dans une transformation que l'on n'a pas soi-même vécue. Avant de devenir des accélérateurs de la transformation IA de nos clients, les consultants SFEIR doivent eux-mêmes opérer en mode augmenté, avoir tâtonné, échoué, appris, et développé des réflexes solides.

Le programme AI Champions s'articule autour de plusieurs axes :

Une formation par la pratique, pas par le concept

Les consultants ne suivent pas des modules théoriques sur l'IA générative. Ils travaillent sur des projets réels, avec de vrais agents, de vrais contextes, de vrais problèmes à résoudre. Les apprentissages sont documentés, partagés, et alimentent le contexte collectif de SFEIR — une mise en pratique concrète du Compound Engineering à l'échelle de l'entreprise.

Des AI Champions comme vecteurs de diffusion

Dans chaque practice, dans chaque communauté de compétences, des AI Champions sont identifiés. Ce sont des consultants qui ont atteint un niveau de maîtrise suffisant pour former leurs pairs, challenger les patterns existants, et maintenir la dynamique d'apprentissage. Ils ne sont pas des évangélistes : ce sont des praticiens qui transmettent par l'exemple.

Un référentiel de compétences AI-Ready

SFEIR est en train de construire un référentiel clair de ce que signifie être AI-Ready en 2026 : quelles compétences de Context Engineering, quels réflexes de Compound Engineering, quelle maîtrise des outils agentiques. Ce référentiel permet de mesurer la progression, d'identifier les lacunes, et d'orienter les parcours de formation individuels.

Une communauté de pratique vivante

Au-delà des formations formelles, SFEIR investit dans les espaces d'échange informels où les consultants partagent leurs découvertes, leurs erreurs, leurs configurations de contexte qui fonctionnent. Ces échanges sont structurés pour que les apprentissages soient capitalisés — et pas perdus dans des fils de discussion sans lendemain. C'est le Compound Engineering appliqué à la connaissance collective.

Ce que cela change pour nos clients

In fine, le programme AI Champions n'est pas un projet interne de SFEIR. C'est un investissement dans la qualité et la pertinence de l'accompagnement que nous apportons à nos clients.

Concrètement, qu'est-ce que cela change pour une DSI ou une équipe produit qui fait appel à SFEIR en 2026 ?

D'abord, des consultants qui ne se contentent pas d'implémenter des features. Un Product Engineer SFEIR formé au Context Engineering et au Compound Engineering apporte une vision systémique. Il pense en termes de cohérence de codebase, de qualité à long terme, de documentation vivante. Il ne livre pas des fonctionnalités : il construit un actif qui vieillit bien.

Ensuite, une capacité à accélérer réellement, et pas seulement à aller un peu plus vite. Le facteur 10x n'est pas garanti dès le premier sprint — la réalité est toujours plus nuancée que les promesses de slide. Mais les équipes qui adoptent réellement le paradigme du Context Engineering et du Compound Engineering observent une courbe d'accélération qui se confirme dans le temps. Chaque sprint est plus rapide que le précédent, parce que le contexte s'enrichit.

Enfin, un accompagnement dans la transformation organisationnelle. Passer à la Sandwich Team, former des App Owners, restructurer les pratiques de delivery autour du context engineering — ce sont des changements qui touchent les individus, les équipes, les cultures. SFEIR ne vend pas uniquement de la technique : nous accompagnons aussi le changement humain que cette transformation implique.

Parce que la vraie difficulté n'est pas d'apprendre à utiliser un nouvel outil. C'est de changer de regard sur ce que signifie créer de la valeur technique — et d'avoir le courage de lâcher des pratiques confortables pour en adopter de nouvelles, moins familières, mais beaucoup plus puissantes.

C'est exactement ce que SFEIR s'est engagé à faire — pour lui-même d'abord, pour ses clients ensuite.