Le développeur devient architecte de contexte

Quand le code devient une commodité

Il y a quelques années encore, la valeur d'un développeur se mesurait principalement à sa capacité à produire du code : lignes par jour, fonctionnalités livrées, bugs corrigés. Cette époque est révolue. Le TechRocks Summit 2025, dont SFEIR a orchestré la restitution via les solutions Google Cloud, l'a acté sans détour : nous sommes entrés dans l'ère de l'industrialisation de l'IA, et cette transition redéfinit en profondeur ce que signifie être développeur.

Charles Gorintin l'a formulé avec une clarté désarmante lors du sommet : "le code devient une commodité, la valeur se réfugie dans l'intention et le contrôle". Une phrase courte, mais dont les implications pour nos métiers sont considérables. Si un agent IA peut générer en quelques secondes ce qui prenait jadis des heures à écrire, alors la compétence différenciante ne réside plus dans l'acte de coder — elle réside dans la capacité à cadrer, structurer et piloter ce que la machine produit.

C'est précisément ce que Patrick Debois et Arthur Magne ont nommé, lors de leurs interventions respectives, le rôle d'architecte de contexte. Un titre qui mérite qu'on s'y attarde sérieusement.

Le "Context Engineering" : la nouvelle discipline fondamentale

Le terme peut sembler abstrait au premier abord. Pourtant, le Context Engineering désigne une réalité très concrète : l'art de fournir à un système d'IA exactement les bonnes informations, au bon moment, dans le bon format, pour qu'il produise un résultat utile et fiable.

Un modèle de langage, aussi puissant soit-il, est aveugle sans contexte. Il ne connaît pas votre domaine métier, vos conventions de nommage, vos contraintes réglementaires, l'historique de vos décisions d'architecture, les particularités de votre base de code legacy. Livré à lui-même, il hallucine, généralise, produit du code fonctionnel mais inadapté. Comme l'a souligné Céline Thooris lors du sommet, "l'IA est aveugle sans un jumeau numérique de l'entreprise et des métadonnées propres : sans structure, les agents échouent".

Le Context Engineering, c'est donc la discipline qui consiste à construire et maintenir ce socle de connaissance structurée. Concrètement, cela recouvre plusieurs dimensions :

• La documentation structurée : écrire des spécifications, des ADR (Architecture Decision Records), des guides de style en Markdown exploitable par les agents — pas pour les humains seuls, mais pour les machines qui vont agir sur cette base.
• Les métadonnées métier : annoter les données, les APIs, les composants avec des informations sémantiques qui permettent aux agents de comprendre ce qu'ils manipulent.
• La définition des contraintes : encadrer explicitement ce que l'agent peut et ne peut pas faire, quels patterns sont acceptables, quelles règles de sécurité s'appliquent.
• L'ingénierie des prompts système : concevoir les instructions de base qui orientent durablement le comportement d'un agent dans un contexte donné.

Ce n'est pas du prompt engineering au sens superficiel du terme — trouver la bonne formule magique pour obtenir une réponse satisfaisante. C'est une discipline d'ingénierie à part entière, qui demande rigueur, méthode et une compréhension fine à la fois du domaine métier et du fonctionnement des systèmes d'IA.

Du développeur au Product Engineer : une mutation, pas une disparition

Face à cette évolution, une crainte légitime s'exprime dans les équipes techniques : le développeur est-il en train de devenir obsolète ? La réponse est non — mais à condition de comprendre vers quoi le métier mute réellement.

Le concept de Product Engineer émerge comme la figure centrale de cette transition. Là où le développeur traditionnel s'inscrivait dans une chaîne de valeur linéaire — on lui donnait des specs, il codait, il livrait — le Product Engineer possède une vision plus large et plus intégrée. Il comprend le problème métier autant que la solution technique. Il est capable de dialoguer avec les parties prenantes pour définir ce qui doit être construit, puis de piloter les outils — y compris les agents IA — pour le construire efficacement.

La rupture de vélocité illustrée par Didier Girard et Marie Crappe au TechRocks Summit 2025 est parlante : des applications complètes déployées en quelques minutes, des migrations de code massives automatisées par des usines logicielles. Ce n'est pas de la science-fiction — c'est ce qui se passe dès aujourd'hui dans les équipes qui ont su s'organiser pour en tirer parti. Mais derrière ces démonstrations impressionnantes, il y a des ingénieurs qui ont fait un travail considérable en amont : définir les invariants, structurer les données, spécifier les comportements attendus, mettre en place les garde-fous.

Le Product Engineer, c'est celui qui fait ce travail amont. Il est à la fois :

• Stratège produit : il comprend la valeur métier et sait la traduire en problèmes techniques bien posés.
• Architecte de contexte : il construit et maintient la base de connaissance structurée qui permet aux agents d'agir efficacement.
• Orchestrateur : il conçoit les workflows agentiques, choisit les bons outils, définit les interactions entre composants.
• Garant de la qualité : il définit les critères d'acceptance, met en place les tests, valide que ce qui a été produit — par lui ou par un agent — est conforme aux attentes.

C'est une évolution exigeante. Elle ne demande pas moins de compétences, elle en demande davantage — et des compétences différentes. Paradoxalement, comme l'a souligné le consensus du sommet, l'automatisation par l'IA exige plus de rigueur humaine, pas moins.

La revanche de la structure et de la documentation

Il y a quelque chose d'ironique dans cette évolution. Pendant des années, la documentation a été le parent pauvre du développement logiciel. Les équipes la bâclaient, la négligeaient, la différaient indéfiniment. "On documentera plus tard" était la promesse jamais tenue de milliers de projets. Les pratiques agiles elles-mêmes, mal comprises, ont parfois servi d'alibi pour s'en dispenser.

L'IA générative est en train d'imposer une forme de revanche de la structure. Arthur Magne et Patrick Debois ont été clairs sur ce point lors du TechRocks Summit : il faut former les équipes à écrire de la documentation structurée en Markdown, qui servira de code pour les agents. Ce n'est plus une bonne pratique facultative — c'est un prérequis fonctionnel.

Concrètement, cela signifie que les équipes doivent repenser leur rapport à la documentation :

• Les spécifications fonctionnelles doivent être suffisamment précises et structurées pour qu'un agent puisse en dériver du code sans ambiguïté majeure.
• Les décisions d'architecture doivent être documentées avec leur contexte, leurs alternatives considérées, leurs contraintes — pas seulement le résultat final.
• Les conventions de code doivent être explicites et versionnées, accessibles aux agents qui vont contribuer à la base de code.
• Les règles métier doivent être extériorisées du code implicite et rendues lisibles, pour humains et machines.

C'est ici qu'intervient le rôle d'"Urbaniste de la donnée" évoqué par Céline Thooris — un profil qui pense l'architecture de l'information de l'entreprise comme une infrastructure critique, au même titre que le réseau ou le cloud. Sans ce travail de fond sur la qualité et la structure des données et des connaissances, les agents les plus sophistiqués restent des outils inefficaces, voire contre-productifs.

Les pièges à éviter : du POC-isme à l'illusion du modèle magique

La transition vers ce nouveau paradigme n'est pas sans embûches. Le TechRocks Summit 2025 a été l'occasion de mettre en garde contre plusieurs dérives observées sur le terrain.

Le syndrome du POC sans lendemain

Arnaud Guérin a nommé un phénomène que de nombreuses DSI reconnaîtront : le "POC-isme". L'accumulation de preuves de concept impressionnantes en démo, mais qui ne passent jamais en production, ne génèrent jamais de valeur réelle, et finissent par épuiser les équipes et éroder la crédibilité des initiatives IA en interne.

Ce piège est d'autant plus dangereux qu'il est confortable. Un POC réussi donne l'illusion du progrès sans exposer aux difficultés réelles de l'industrialisation : la gestion des cas limites, l'intégration avec les systèmes existants, la sécurisation, la maintenance dans la durée, la formation des utilisateurs finaux.

L'antidote est de définir dès le départ les critères qui permettront de passer d'un POC à une solution en production — et de s'y tenir.

La quête du modèle magique

Une autre dérive fréquente consiste à passer l'essentiel de son énergie à tester les derniers modèles disponibles, en espérant que le prochain sera suffisamment bon pour compenser la médiocrité du contexte fourni. C'est une impasse.

Le message des intervenants du sommet est univoque : cessez de chercher le modèle magique et concentrez-vous sur vos données. Un excellent contexte avec un modèle moyen donnera de meilleurs résultats qu'un mauvais contexte avec le meilleur modèle du marché. La valeur est dans la préparation, pas dans la puissance brute du LLM.

La délégation cognitive aveugle

Laurence Devillers a soulevé un risque plus profond et moins souvent discuté : le risque cognitif. En déléguant progressivement notre réflexion critique — ce que les psychologues appellent le "Système 2", la pensée lente et délibérative — à des machines probabilistes, nous risquons d'atrophier les compétences mêmes qui nous permettent de vérifier, questionner et corriger ce que ces machines produisent.

Pour un développeur devenant architecte de contexte, cela a une implication directe : il est impératif de maintenir une compréhension profonde des systèmes que l'on construit, même lorsque c'est un agent qui en écrit le code. Valider n'est pas la même chose que comprendre, et la différence peut coûter cher en production.

Sécurité et souveraineté : les angles morts de l'enthousiasme

L'enthousiasme pour les capacités des systèmes agentiques ne doit pas faire oublier deux dimensions critiques que le TechRocks Summit a mis en lumière avec insistance.

Du côté de la sécurité, Julien Mangeard et Marc Marchal de Corny ont alerté sur un phénomène préoccupant : les attaquants utilisent eux aussi l'IA pour industrialiser leurs offensives. La fraude automatisée, les deepfakes à grande échelle, le phishing hyper-personnalisé — ces menaces rendent les méthodes de défense classiques partiellement obsolètes. Dans un contexte où les agents IA ont accès à des systèmes critiques et peuvent exécuter des actions autonomes, la surface d'attaque s'élargit considérablement. Le Context Engineering doit donc intégrer une dimension sécurité dès la conception : quelles actions peuvent être déléguées à un agent ? Avec quels niveaux de validation humaine ? Comment détecter une injection de prompt malveillante ?

Du côté de la souveraineté, Asma Mhalla a rappelé le contexte géopolitique dans lequel ces technologies s'inscrivent. La guerre froide technologique entre les États-Unis et la Chine place l'Europe dans une position délicate, dépendante d'infrastructures et de modèles qu'elle ne contrôle pas. Pour les architectes de contexte que nous devenons, cette dimension n'est pas abstraite : elle se traduit par des choix concrets sur les fournisseurs de cloud, les modèles utilisés, la localisation des données, et la capacité à migrer si nécessaire.

Comment SFEIR accompagne cette mutation

Chez SFEIR, nous observons et vivons cette transformation de l'intérieur, à travers les missions menées avec nos clients. Ce que le TechRocks Summit a formalisé en concepts, nos équipes le rencontrent concrètement au quotidien : des organisations qui ont expérimenté, qui voient le potentiel, mais qui peinent à industrialiser parce que les fondations — données, documentation, architecture — ne sont pas au rendez-vous.

Notre approche s'articule autour de plusieurs axes complémentaires.

Construire les fondations du Context Engineering

Avant d'outiller, nous aidons nos clients à structurer. Cela passe par des missions d'audit de la maturité de leur patrimoine de données et de documentation, l'identification des lacunes critiques, et la mise en place de pratiques d'urbanisme de la donnée. Le travail n'est pas spectaculaire — il ne se prête pas aux démonstrations en live — mais c'est lui qui détermine si les agents déployés ensuite seront efficaces ou non.

Former les équipes au nouveau paradigme

La transition vers le rôle de Product Engineer et d'architecte de contexte est une transformation culturelle autant que technique. Nos programmes de formation accompagnent les développeurs dans cette évolution : comprendre le fonctionnement des LLMs et leurs limites, maîtriser le Context Engineering, concevoir des architectures agentiques robustes, intégrer la sécurité dès la conception. L'objectif n'est pas de former des utilisateurs de chatbots, mais des ingénieurs capables de construire des systèmes IA fiables.

Industrialiser sans brûler les étapes

Nous aidons nos clients à sortir du POC-isme en définissant des trajectoires d'industrialisation réalistes. Cela implique de choisir les bons cas d'usage — ceux où l'IA apporte une valeur mesurable et où les prérequis sont réunis — plutôt que de se disperser. Cela implique aussi de mettre en place les dispositifs de mesure qui permettront de démontrer le ROI et d'ajuster en continu.

Sécuriser l'architecture agentique

Nos experts en sécurité et en architecture cloud travaillent conjointement avec les équipes de développement pour intégrer les contraintes de sécurité dans la conception des systèmes agentiques. Dans un monde où les agents peuvent déclencher des actions autonomes sur des systèmes critiques, cette dimension n'est pas optionnelle.

Ce que cela change, concrètement, dès demain

Il serait réducteur de conclure que "tout change" sans donner de prise concrète. Voici ce que la mutation vers l'architecte de contexte implique pratiquement pour les équipes de développement.

Revoir les rituels d'équipe. Les cérémonies agiles doivent évoluer pour intégrer le travail de contextualisation. Le refinement n'est plus seulement l'occasion de découper des stories — c'est l'occasion de formaliser les connaissances métier qui alimenteront les agents. La définition of done doit inclure la documentation structurée.

Investir dans les compétences rédactionnelles. Écrire des spécifications précises, des ADR clairs, de la documentation exploitable par des machines — c'est une compétence qui s'apprend et se travaille. Les équipes qui s'y investissent maintenant prendront une avance durable.

Penser en termes de systèmes, pas de fonctionnalités. Le Product Engineer pense à l'impact et à la cohérence d'ensemble, pas à la ligne de code suivante. Cette vision systémique est ce qui permet de concevoir des architectures agentiques qui restent maintenables et évolutives.

Maintenir une culture de l'exigence technique. L'automatisation ne dispense pas de la rigueur — elle l'exige davantage. Les standards de qualité, les tests, la revue de code : ces pratiques restent essentielles, et leur périmètre s'étend maintenant au code généré par les agents.

La transition est engagée. Elle n'est ni linéaire ni sans friction. Mais les organisations qui sauront accompagner leurs développeurs dans cette mutation — en leur donnant les compétences, les outils et le temps nécessaires pour devenir architectes de contexte — seront celles qui transformeront la promesse de l'IA en avantage compétitif durable. Les autres accumuleront des POCs.