Écrire du code est un anti-pattern : la provocation qui change tout
La provocation qui remet tout en question
« Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. »
Cette phrase, prononcée par Didier Girard, a de quoi faire bondir n'importe quel développeur. Elle semble absurde, voire provocatrice. Et pourtant, si on accepte de la prendre au sérieux quelques minutes, elle ouvre une perspective qui change radicalement la façon dont on conçoit le développement logiciel en 2025 et au-delà.
Chez SFEIR, nous accompagnons depuis des années les équipes techniques dans leur transformation. Et ce que nous observons chez nos clients — grands comptes, scale-ups, organisations publiques — c'est que l'IA générative ne s'intègre pas dans les pratiques existantes comme un simple outil de productivité. Elle les remet en cause dans leurs fondements. Ce n'est pas une amélioration continue. C'est un changement de paradigme.
Cet article explore ce changement : pourquoi viser x10 plutôt que quelques pourcents de gain, ce que signifie concrètement le Context Engineering, comment le Compound Engineering transforme la vélocité des équipes dans le temps, et ce que le SDLC augmenté implique pour les organisations qui veulent rester compétitives.
Oublier l'amélioration marginale : pourquoi x10 ou rien
Le réflexe naturel face à un nouvel outil est de chercher comment il peut améliorer ce qu'on fait déjà. On intègre GitHub Copilot dans l'IDE. On automatise quelques tests. On génère des maquettes plus vite. On gagne 15%, peut-être 20% de temps sur certaines tâches. C'est bien. Mais c'est insuffisant.
Le problème de l'optimisation marginale, c'est qu'elle conserve la structure de coût sous-jacente. On fait la même chose un peu plus vite. On reste dans le même modèle mental : un développeur produit du code, un relecteur le valide, un testeur le vérifie, un ops le déploie. Chaque étape attend la précédente. Le backlog grossit. La coordination coûte de l'énergie. La dette technique s'accumule.
La vraie question n'est pas « comment utiliser l'IA pour écrire du code plus vite ? » mais « comment l'IA peut-elle changer l'échelle de création de valeur métier ? » C'est là que le facteur x10 prend tout son sens. Non pas comme un objectif marketing, mais comme un signal : si votre démarche d'adoption de l'IA ne change pas profondément la structure de vos équipes et de vos processus, vous passez à côté de l'essentiel.
Ce changement de perspective implique de questionner ce qui était jusqu'ici considéré comme une évidence : le code écrit manuellement comme principale activité d'un développeur. Et c'est précisément là que l'anti-pattern entre en scène.
Écrire du code : comprendre l'anti-pattern
Un anti-pattern, dans le vocabulaire du génie logiciel, désigne une pratique apparemment logique qui produit en réalité des effets négatifs. Écrire du code manuellement n'était pas un anti-pattern tant que c'était la seule option disponible. Ça l'devient dès lors qu'une alternative existe qui produit un résultat équivalent ou supérieur, plus rapidement, avec moins de risques d'erreur — et surtout, avec une meilleure capitalisation sur le long terme.
La production manuelle de code présente plusieurs travers souvent sous-estimés :
- Le coût de la finition : la majorité du temps n'est pas passée à écrire des algorithmes complexes, mais à gérer des détails — nommage, formatage, cohérence des conventions, gestion des cas limites. Des tâches à faible valeur cognitive, répétitives, sources d'erreurs.
- La dette de contexte : chaque développeur porte en tête une représentation partielle du système. Cette connaissance tacite ne se transfère pas bien. Quand quelqu'un quitte l'équipe, ou qu'un nouveau rejoint, on repart souvent de zéro.
- L'effet de fragmentation : dans une organisation classique, une feature passe entre plusieurs mains — product, design, dev, test, ops. Chaque passage génère un délai, une perte d'information, un risque de désalignement.
L'approche IA agentique renverse cette logique. Au lieu de produire du code, on configure la machine qui va le produire. Au lieu de corriger des bavures en aval, on travaille les réglages en amont — les prompts, le contexte, les règles métier. La conformité est intégrée dès la production, pas rattrapée ensuite.
C'est un glissement fondamental : de l'artisan qui taille la pierre à l'ingénieur qui programme la fraiseuse à commande numérique.
Context Engineering : le nouvel actif stratégique de l'IT
Si écrire du code n'est plus le cœur du métier, qu'est-ce qui le remplace ? La réponse tient en deux mots : Context Engineering.
Le Context Engineering, c'est l'art de construire et de maintenir l'environnement structuré dans lequel l'IA va opérer. Il ne s'agit pas de rédiger un prompt efficace à la volée. Il s'agit de constituer, de manière rigoureuse et versionnée, un ensemble d'éléments qui permettent à l'IA de comprendre profondément le système sur lequel elle intervient :
- Les spécifications fonctionnelles : qu'est-ce que le système doit faire, dans quel contexte métier ?
- Les règles d'architecture : quels patterns sont utilisés, quelles contraintes techniques sont imposées ?
- Les conventions de code : nommage, structure des modules, gestion des erreurs, tests associés.
- Les décisions passées : pourquoi a-t-on fait tel choix ? Quelles alternatives ont été écartées et pourquoi ?
- Les contraintes métier : réglementation, SLA, contraintes de sécurité, dépendances critiques.
Ce corpus, stocké typiquement sous forme de fichiers Markdown versionnés dans Git, constitue la mémoire vivante du projet. Il ne sert pas seulement à l'IA : il sert aussi à l'humain. Un nouveau membre de l'équipe peut monter en compétence en s'appuyant dessus. Un auditeur peut comprendre l'histoire du système. Un architecte peut évaluer la cohérence de l'ensemble.
La règle d'or : le context engineering doit être considéré comme un asset vivant, versionné au même titre que le code source. Ce n'est pas de la documentation morte. C'est le carburant de la machine IA.
L'un des bénéfices les plus concrets du Context Engineering est la réduction drastique des hallucinations. Quand un agent IA dispose d'un contexte riche, précis et cohérent, il produit des sorties qui s'inscrivent dans l'architecture existante. Il ne réinvente pas la roue. Il ne contredit pas les conventions établies. Il ne propose pas des solutions qui violent des contraintes métier non documentées. Le contexte est l'antidote à l'IA qui improvise.
Chez SFEIR, nous accompagnons nos clients dans la construction de ces corpus contextuels. C'est souvent le premier chantier que nous recommandons avant même de déployer des agents de génération de code : formaliser ce qui est implicite, structurer ce qui est épars, versionner ce qui est volatile.
Le SDLC augmenté : un cycle de développement qui s'auto-améliore
Le SDLC augmenté — Software Development Life Cycle augmenté par l'IA — ne se contente pas d'accélérer les étapes existantes. Il restructure le cycle lui-même autour d'une logique d'amélioration cumulative.
Le workflow se décompose en cinq phases :
- PLAN : transformer les idées, les signaux métier et les contraintes techniques en plans d'implémentation détaillés. C'est ici que l'agent IA joue un rôle d'architecte assistant — il propose des approches, identifie les risques, suggère des décompositions en tâches.
- WORK : exécuter les tâches via des worktrees et un tracking précis. L'IA génère le code, les tests, la documentation inline. L'humain supervise, arbitre, valide les choix stratégiques.
- REVIEW : une revue de code multi-agents intervient avant le merge. Plusieurs perspectives automatisées — sécurité, performance, cohérence architecturale — complètent la revue humaine sans la remplacer.
- COMPOUND : les apprentissages du cycle sont documentés et intégrés au contexte. Ce qui a bien fonctionné est codifié. Ce qui a échoué est analysé et annoté.
- REPEAT : chaque cycle informe et accélère le suivant. Le contexte s'enrichit. La machine devient plus performante sur ce projet spécifique. La vélocité augmente de manière organique.
C'est cette boucle vertueuse qui distingue fondamentalement le SDLC augmenté d'une simple automatisation ponctuelle. On ne cherche pas à aller vite sur un sprint. On construit une infrastructure de production qui s'améliore de manière continue — non pas par des optimisations manuelles, mais par l'accumulation structurée du savoir.
Un détail qui a son importance : ce modèle s'oppose frontalement à l'approche spec-driven qui prévalait encore récemment. Dans une logique spec-driven, on demande à l'IA d'ajouter une fonctionnalité isolée, sans égard pour l'existant. Le résultat est souvent une verrue logicielle — fonctionnelle en isolation, incohérente dans le système. L'approche issue-based, au contraire, signale un manque, un bug, une amélioration. L'IA analyse l'existant, utilise le contexte pour produire une solution systémiquement cohérente. La différence de qualité est considérable sur la durée.
Compound Engineering : capitaliser plutôt qu'accumuler
Le Compound Engineering est la philosophie qui sous-tend le SDLC augmenté. Le mot « compound » est emprunté à la finance : l'intérêt composé, c'est la magie de la capitalisation — chaque gain génère lui-même des gains futurs.
Appliqué au développement logiciel, cela signifie : chaque unité de travail doit rendre les suivantes plus faciles. Ce principe s'oppose à une tendance bien connue : l'accumulation de dette technique.
L'IA mal utilisée est une machine à dette technique. Elle génère du code vite, mais sans cohérence. Elle colle des fonctionnalités les unes aux autres sans tenir compte de l'architecture. Chaque feature ajoute de la complexité. Le codebase devient progressivement un frein à la vélocité — l'exact opposé de l'effet recherché.
Le Compound Engineering inverse cette logique en imposant une discipline stricte : 80% du temps doit être consacré au planning et à la review, 20% à l'exécution et à la production de code. Cette répartition peut sembler contre-intuitive. Elle est pourtant le secret de la vélocité durable. Maintenir une qualité maximale aujourd'hui, c'est garantir la vitesse de demain.
Concrètement, cela signifie :
- Ne jamais merger du code qui dégrade le contexte existant sans documenter pourquoi.
- Traiter chaque revue comme une opportunité d'enrichir le corpus contextuel.
- Refactorer activement le contexte quand l'architecture évolue — pas seulement le code.
- Codifier les patterns émergents pour qu'ils soient réutilisables par l'IA sur les itérations futures.
Le projet GitHub compound-engineering-plugin développé par EveryInc illustre comment outiller cette philosophie dans un workflow concret. Chez SFEIR, nous expérimentons et adaptons ce type d'approche pour nos clients, en tenant compte de leurs contraintes organisationnelles et de leurs stacks techniques existants.
La Sandwich Team : quand une personne augmentée remplace une pizza team
Le changement de méthodologie entraîne inévitablement un changement d'organisation. Et c'est sans doute là que la rupture est la plus visible — et la plus difficile à accepter.
Le modèle traditionnel, souvent appelé « pizza team » — une équipe qui tient autour d'une pizza, soit 6 à 8 personnes — repose sur une logique de spécialisation. Un designer, un product owner, un ou deux développeurs front, un développeur back, un ingénieur DevOps, un testeur. Chaque rôle est distinct. Le travail circule de main en main. La coordination est un métier à part entière.
Ce modèle a des vertus réelles : profondeur de compétence, réduction du bus factor, spécialisation pointue. Mais il a un coût souvent sous-estimé : la latence de coordination. Chaque passage entre rôles est un délai potentiel, une perte d'information, une source de friction. Dans un monde où le backlog grossit plus vite que la capacité de livraison, cette latence est un goulot d'étranglement structurel.
La Sandwich Team propose une alternative radicale : un seul développeur augmenté — l'App Owner — capable de couvrir 80% de l'application de manière autonome. UX, UI, front, API, back, sécurité. Non pas parce qu'il est expert dans chacun de ces domaines, mais parce que l'IA comble ses lacunes ponctuelles tout en s'appuyant sur son expertise profonde du contexte métier et architectural.
Les 20% restants sont couverts par des contributeurs qui interviennent ponctuellement, guidés par le contexte qui a été sauvegardé dans Git. Ils n'ont pas besoin d'une longue phase d'onboarding. Le contexte leur fournit les repères nécessaires pour contribuer efficacement sans perturber la cohérence du système.
Cette évolution redéfinit les métiers de l'IT. On assiste à une fusion entre le Product Engineer — qui comprend le besoin métier, pense l'expérience utilisateur, arbitre les priorités — et le Software Engineer — qui maîtrise les fondements techniques, les patterns, les contraintes d'architecture. Ces deux figures, longtemps séparées par des silos organisationnels, convergent vers un profil unique : le Software Product Engineer, augmenté par une machine IA performante qui gère la chaîne de production complète.
La métaphore du bûcheron illustre bien ce glissement : là où autrefois le bûcheron abattait, le débardeur transportait et le scieur transformait — chacun attendant l'autre — la machine IA abat, ébranche et sort le bois seule. Le bûcheron coordonne la production totale. Les temps morts disparaissent. La valeur est produite en flux continu.
Ce que cela change pour les équipes et les organisations
Adopter cette philosophie ne se fait pas du jour au lendemain. Elle implique des changements profonds à plusieurs niveaux.
Au niveau des compétences
Les développeurs qui réussiront dans ce nouveau modèle ne seront pas nécessairement ceux qui écrivent le code le plus propre à la main. Ce seront ceux qui comprennent le mieux les systèmes dans leur globalité, qui savent formaliser et structurer le contexte, qui ont le recul pour évaluer la qualité des sorties de l'IA, et qui peuvent arbitrer entre des approches architecturales concurrentes. La compétence de jugement prend le pas sur la compétence de production.
Au niveau des processus
Les rituels agiles classiques — standup, sprint planning, rétrospective — ne disparaissent pas, mais leur contenu change. On passe moins de temps à synchroniser sur qui fait quoi. On passe plus de temps à enrichir le contexte, à valider la cohérence des productions de l'IA, à identifier les patterns réutilisables. Le Definition of Done s'enrichit : une feature n'est pas terminée quand le code est mergé, mais quand le contexte a été mis à jour pour intégrer les apprentissages du cycle.
Au niveau de la gouvernance
Le contexte versionné dans Git devient un asset stratégique de l'organisation. Il doit être protégé, auditable, maintenu avec la même rigueur que le code de production. La question du ownership du contexte — qui peut le modifier, selon quel processus de validation — devient une question de gouvernance IT à part entière.
Au niveau culturel
C'est sans doute le chantier le plus difficile. La fierté du développeur est souvent liée à son code — son style, ses patterns, ses optimisations. Passer à un modèle où l'IA génère le code et où la valeur est dans le contexte demande une révision profonde de ce que signifie « bien faire son travail ». Ce n'est pas une dévalorisation du métier. C'est une élévation vers un niveau d'abstraction supérieur.
Comment SFEIR accompagne cette transformation
Chez SFEIR, nous ne nous contentons pas d'observer ces tendances de loin. Nous les expérimentons en interne, avec nos propres projets, et nous les mettons en œuvre chez nos clients à travers des missions concrètes.
Notre approche repose sur trois piliers :
- Le diagnostic : avant de recommander un outillage ou une réorganisation, nous analysons la maturité de l'équipe, la qualité du contexte existant, et les points de friction dans le SDLC actuel. Un audit de la dette de contexte — souvent plus handicapant que la dette technique classique — est souvent le point de départ.
- L'implémentation du Context Engineering : nous aidons les équipes à construire leur premier corpus contextuel — spécifications, règles d'architecture, conventions, décisions passées. Nous formons les développeurs à maintenir ce corpus dans le temps, à l'intégrer dans leurs workflows Git, à l'utiliser efficacement avec les agents IA.
- L'adoption du Compound Engineering : nous accompagnons les équipes dans l'internalisation de la discipline 80/20 — planifier plus, produire mieux. Nous les aidons à instrumenter leur SDLC pour mesurer la qualité du contexte, identifier les dérives, et s'améliorer de cycle en cycle.
Nous sommes convaincus que les organisations qui réussiront cette transition ne seront pas celles qui ont adopté le plus d'outils IA, mais celles qui ont repensé en profondeur leur rapport à la production logicielle — en plaçant le contexte au centre, en capitalisant sur les apprentissages, et en faisant confiance à des App Owners augmentés pour créer de la valeur métier à une échelle nouvelle.
Conclusion : la provocation comme boussole
« Écrire du code est un anti-pattern. » Cette phrase n'est pas une vérité absolue. C'est une provocation utile. Elle nous force à sortir du cadre, à questionner des habitudes si profondément ancrées qu'elles semblent naturelles.
Ce qu'elle pointe réellement, c'est que dans un monde où les agents IA peuvent générer du code de qualité production en quelques secondes, la valeur humaine ne réside plus dans la production manuelle de lignes de code. Elle réside dans la capacité à définir avec précision ce que le système doit faire, pourquoi, dans quel contexte, avec quelles contraintes. Elle réside dans le jugement, la cohérence, l'arbitrage — tout ce que l'IA ne peut pas encore faire seule.
Le Context Engineering, le Compound Engineering et le SDLC augmenté ne sont pas des gadgets technologiques. Ils sont la réponse structurée à une question stratégique : comment créer dix fois plus de valeur avec les mêmes équipes, non pas en travaillant plus vite, mais en travaillant différemment ?
La transformation est exigeante. Elle demande de la rigueur, de la discipline, et une remise en question profonde des rôles et des pratiques. Mais les organisations qui franchissent ce cap ne reviennent pas en arrière. Parce qu'une fois qu'on a goûté à la vélocité compound — celle qui s'amplifie cycle après cycle — l'amélioration marginale ne suffit plus.
Vous souhaitez explorer comment ces principes s'appliquent à votre contexte ? Les équipes SFEIR sont là pour vous aider à poser les premières pierres de votre transformation.