Valeur et agentivité : pourquoi le code devient une commodité

Le code ne vaut plus ce qu'il valait

Il y a encore quelques années, savoir écrire du code propre, performant, bien testé, était une compétence rare et précieuse. Les équipes techniques passaient des semaines à implémenter des fonctionnalités que l'on peut désormais générer en quelques minutes. Ce n'est pas une exagération : au TechRocks Summit 2025, Didier Girard et Marie Crappe ont illustré concrètement cette rupture de vélocité, montrant comment des applications complètes sont déployées en quelques minutes, et comment des migrations de code massives sont automatisées par de véritables usines logicielles.

Ce constat n'est pas alarmiste. Il est simplement factuel. Et il pose une question fondamentale pour toutes les directions des systèmes d'information, toutes les équipes produit, tous les ingénieurs : si le code devient une commodité, où se réfugie la valeur ?

C'est précisément ce que SFEIR observe au quotidien auprès de ses clients. La transformation en cours n'est pas une simple évolution des outils de développement. C'est une recomposition profonde de ce que signifie créer de la valeur technique dans une organisation.

De la hype à la réalité opérationnelle : un changement de paradigme

L'édition 2025 du TechRocks Summit a acté quelque chose d'important : la phase de découverte ludique de l'IA générative est terminée. Nous entrons dans l'ère de l'industrialisation, sans les bullshits rassurants qui permettaient d'explorer sans vraiment s'engager.

Pendant deux ans, beaucoup d'organisations ont multiplié les preuves de concept, les expérimentations en silo, les démonstrations impressionnantes dans des contextes contrôlés. Ce "POC-isme", comme l'a nommé Arnaud Guérin lors du sommet, constitue aujourd'hui un piège mortel pour le ROI. Accumuler des POCs sans impact mesurable, sans passage à l'échelle, sans intégration dans les processus métier réels, c'est brûler du capital — budgétaire, humain et politique — sans construire quoi que ce soit de durable.

La réalité opérationnelle, elle, ressemble à ceci : des agents autonomes qui orchestrent des tâches complexes, des migrations de code massives automatisées, des systèmes capables d'agir dans des environnements applicatifs réels. Le consensus technique s'est déplacé des simples chatbots vers les systèmes agentiques, orchestrés par de nouveaux standards comme le Model Context Protocol (MCP). Cette évolution change radicalement la nature du travail d'ingénierie.

Quand le code devient commodité : comprendre la mutation

Charles Gorintin l'a formulé avec clarté au TechRocks Summit : le code devient une commodité, la valeur se réfugie dans l'intention et le contrôle. Cette phrase mérite qu'on s'y arrête.

Une commodité, au sens économique, c'est un bien interchangeable, produit en masse, dont le prix tend vers son coût marginal de production. Le blé est une commodité. La bande passante réseau en est une autre. Demain — et pour certains usages, c'est déjà aujourd'hui — le code fonctionnel de qualité correcte rejoint cette catégorie.

Cela ne signifie pas que l'ingénierie logicielle disparaît. Cela signifie que la compétence différenciante se déplace. Les tâches qui consistaient à traduire mécaniquement une spécification en lignes de code sont désormais largement automatisables. Ce qui reste irréductiblement humain, c'est :

• La capacité à formuler le bon problème, pas seulement la bonne solution
• La compréhension des contraintes métier, des enjeux organisationnels, des arbitrages de valeur
• Le jugement sur ce qui mérite d'être construit, et ce qui ne mérite pas de l'être
• La responsabilité du contrôle sur les systèmes automatisés
• L'architecture de contexte qui permet aux agents de fonctionner correctement

Patrick Debois et Arthur Magne l'ont exprimé d'une manière qui résonne profondément : le développeur ne doit plus "pisser du code", mais devenir un architecte de contexte et de spécifications. C'est une mutation identitaire aussi bien que technique.

L'émergence du Product Engineer : l'ingénieur amplifié

Cette mutation donne naissance à un nouveau profil, que l'on commence à appeler le Product Engineer. Ce n'est pas un chef de produit qui sait coder, ni un développeur qui fait de la gestion de produit à mi-temps. C'est une figure nouvelle, née de la convergence entre l'accélération de l'IA et la demande croissante d'ingénieurs capables de raisonner en termes de valeur business, pas seulement en termes de complexité technique.

Le Product Engineer possède plusieurs caractéristiques distinctives :

• Il pense en systèmes de valeur, pas en fonctionnalités. Il est capable de relier une décision d'architecture à un impact mesurable pour l'utilisateur final ou pour l'organisation.
• Il maîtrise l'amplification par l'IA. Il ne subit pas les outils d'assistance au développement, il les orchestre. Il sait quand déléguer à un agent, comment structurer un prompt efficace, et surtout, comment relire, valider et contrôler ce que la machine produit.
• Il est architecte de contexte. Il comprend que pour qu'un agent IA fonctionne bien, il faut lui fournir le bon contexte — des données structurées, une documentation claire, des spécifications précises. La qualité de son travail de structuration conditionne directement la qualité de ce que produit l'IA.
• Il garde la main sur l'intention. Formuler le problème correctement, s'assurer que la solution produite correspond réellement au besoin, maintenir la cohérence globale d'un système : ce sont des responsabilités qui ne se délèguent pas à une machine probabiliste.

C'est en ce sens que l'on parle d'amplification par l'IA plutôt que de simple automatisation. L'IA n'ampute pas le rôle de l'ingénieur : elle l'amplifie, à condition que cet ingénieur soit prêt à évoluer vers des compétences de plus haut niveau. Un Product Engineer équipé d'agents IA n'est pas un développeur remplacé. C'est un ingénieur dont la capacité de production et d'impact est démultipliée — à condition de savoir exercer ce levier.

La revanche de la structure : pourquoi la rigueur devient stratégique

Il y a un paradoxe apparent dans cette transformation, que Céline Thooris a mis en lumière avec force au TechRocks Summit : l'automatisation par l'IA exige plus de rigueur humaine, pas moins.

Les agents IA sont puissants, mais ils sont aveugles sans un "jumeau numérique" de l'entreprise et des métadonnées propres. Sans structure, sans données de qualité, sans documentation exploitable, les agents échouent. Ou pire : ils produisent des résultats qui semblent corrects mais qui sont silencieusement faux, parce qu'ils ont opéré dans un contexte mal défini.

Cela a des implications concrètes pour les DSI et les équipes engineering :

• La qualité des données n'est plus un prérequis technique, c'est un impératif stratégique. Les organisations qui n'ont pas investi dans leur urbanisme de données vont se retrouver à la traîne, non pas parce que leurs développeurs manquent de compétences, mais parce que leurs agents travaillent dans le noir.
• La documentation structurée devient du code. Magne et Debois l'ont explicité : former les équipes à écrire de la documentation structurée en Markdown, c'est leur apprendre à programmer les agents de demain. Une spec bien rédigée n'est plus seulement utile pour les humains — elle est directement consommable par des systèmes automatisés.
• Le "context engineering" devient une discipline à part entière. Savoir structurer l'information pour qu'elle soit exploitable par des agents, définir les bons périmètres de contexte, éviter les hallucinations par une architecture de prompt rigoureuse : ce sont des compétences qui se construisent et qui se transmettent.

Chez SFEIR, nous accompagnons nos clients sur exactement ce point de jonction. La question n'est pas "quel modèle IA choisir ?" mais "comment structurer votre contexte pour que n'importe quel modèle soit efficace ?". Cessez de chercher le modèle magique et concentrez-vous sur vos données : c'est le conseil le plus pragmatique que l'on puisse donner à une DSI en 2025.

Les risques réels de la transition : ce qu'on ne dit pas assez

La transformation en cours n'est pas sans risques. Et plusieurs intervenants du TechRocks Summit ont eu le courage de les nommer clairement, là où il aurait été plus confortable de rester dans l'enthousiasme.

Le risque organisationnel : le piège du POC-isme

Arnaud Guérin a mis le doigt sur une pathologie organisationnelle répandue : l'accumulation de preuves de concept qui n'aboutissent jamais à une mise en production réelle. Chaque POC représente du budget consommé, des équipes mobilisées, des attentes créées. Quand ces POCs ne débouchent sur rien de concret, la désillusion est proportionnelle à l'enthousiasme initial — et les directions métier finissent par se fermer aux initiatives futures. La transition vers l'industrialisation exige de se donner des critères clairs de passage à l'échelle, et le courage de stopper ce qui ne passe pas ces critères.

Le risque sécuritaire : des attaquants eux aussi amplifiés

Julien Mangeard et Marc Marchal de Corny ont rappelé une vérité inconfortable : l'IA amplifie aussi les capacités offensives. Les attaquants utilisent l'IA pour industrialiser la fraude, créer des deepfakes convaincants, automatiser des attaques de phishing personnalisées à grande échelle. Les méthodes de défense classiques, conçues pour un monde où les attaques étaient artisanales, deviennent obsolètes face à cette industrialisation du côté obscur. Les architectures de sécurité doivent évoluer en conséquence, avec la même urgence que les architectures techniques.

Le risque cognitif : la délégation silencieuse de notre pensée

Laurence Devillers a formulé peut-être l'alerte la plus profonde de l'événement : en déléguant 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 notre propre compétence. Un ingénieur qui ne sait plus raisonner sans l'assistance de l'IA est un ingénieur qui ne peut plus exercer le contrôle que son rôle exige. La formation, le maintien de pratiques de réflexion autonome, la culture du questionnement critique sur les outputs de l'IA : ce sont des enjeux qui dépassent la technique et touchent à la posture professionnelle.

Comment les DSI doivent se repositionner

Pour les directions des systèmes d'information, cette transformation redistribue les cartes de manière significative. Le rôle de la DSI ne peut plus se limiter à livrer des projets dans les délais et les budgets. Elle doit devenir l'architecte de l'agentivité organisationnelle — c'est-à-dire la capacité de l'organisation à agir, à automatiser, à décider avec efficacité dans un monde où les systèmes autonomes prolifèrent.

Quelques axes d'action concrets se dégagent :

• Investir dans le capital "contexte". Recruter des urbanistes de la donnée, structurer les référentiels métier, mettre en place les métadonnées qui permettront aux agents de naviguer dans le système d'information. Ce travail, souvent ingrat et peu visible, conditionne pourtant l'ensemble des gains futurs.
• Industrialiser l'architecture agentique. Sortir de l'expérimentation en silo pour construire des plateformes d'orchestration réutilisables, des patterns sécurisés, des cadres de gouvernance pour les systèmes autonomes. La démo impressionnante ne vaut rien si elle ne peut pas passer en production.
• Requalifier les équipes engineering. La montée en compétence vers le profil Product Engineer ne se décrète pas : elle se construit par des parcours de formation délibérés, des pratiques de mentoring, des missions qui sortent les ingénieurs de leur zone de confort technique pour les exposer aux enjeux métier.
• Mettre en place des garde-fous cognitifs et sécuritaires. Définir ce qui peut être délégué à un agent et ce qui doit rester sous contrôle humain. Construire des revues systématiques des outputs IA. Traiter la sécurité des architectures agentiques comme un premier-class citizen, pas comme une afterthought.

La dimension géopolitique n'est pas à négliger non plus. Asma Mhalla l'a rappelé avec force : l'IA est désormais une infrastructure géopolitique majeure, et les entreprises européennes doivent penser leur souveraineté numérique dans ce contexte de tension entre les États-Unis et la Chine. Le choix des fournisseurs de modèles, des plateformes cloud, des protocoles d'orchestration : ce sont des décisions stratégiques qui engagent l'organisation sur le long terme.

La perspective SFEIR : accompagner la mutation, pas seulement l'accélération

Chez SFEIR, nous refusons le discours qui réduit la transformation IA à une question d'outillage. Nos 850+ consultants spécialisés en IA, Cloud et Data le constatent chaque jour sur le terrain : les organisations qui réussissent leur transition ne sont pas celles qui adoptent le plus d'outils, mais celles qui réussissent à transformer la manière dont leurs équipes pensent et travaillent.

Concrètement, notre approche sur ces sujets s'articule autour de trois niveaux :

• Le niveau architecture. Nous aidons nos clients à construire des plateformes agentiques robustes, gouvernées, sécurisées — pas des POCs séduisants mais fragiles. L'industrialisation exige une rigueur architecturale que nos équipes apportent avec les patterns Cloud et les bonnes pratiques d'intégration.
• Le niveau data et contexte. Nous accompagnons la structuration des données, la mise en place des métadonnées exploitables par les agents, la construction des "jumeaux numériques" dont les systèmes automatisés ont besoin pour opérer correctement. Sans ce fondement, les investissements en IA produisent des résultats décevants.
• Le niveau humain et organisationnel. Nous formons les équipes engineering à évoluer vers le profil Product Engineer — en cultivant la capacité à formuler des problèmes, à spécifier des contextes, à exercer un contrôle critique sur les outputs de l'IA. L'amplification ne fonctionne que si les humains dans la boucle sont à la hauteur de leur nouveau rôle.

Ce que le TechRocks Summit 2025 a confirmé, et que nous portons dans notre pratique quotidienne, c'est que l'IA industrielle n'est pas un projet, c'est une transformation. Elle ne s'achète pas dans un catalogue de fonctionnalités. Elle se construit, avec rigueur, avec une vision claire de la valeur que l'on cherche à créer, et avec le courage de ne pas se contenter de démonstrations impressionnantes.

Conclusion : l'agentivité comme nouvel avantage concurrentiel

La commoditisation du code n'est pas une menace à conjurer. C'est une réalité à intégrer pour se concentrer sur ce qui compte vraiment : l'agentivité, c'est-à-dire la capacité à agir avec intention, discernement et contrôle dans un monde où les systèmes automatisés prolifèrent.

Les organisations qui vont tirer leur épingle du jeu dans les prochaines années ne seront pas nécessairement celles qui auront déployé le plus d'agents IA. Ce seront celles qui auront su construire des équipes de Product Engineers capables d'exercer un jugement de haut niveau, des architectures de contexte qui permettent à l'IA de produire des résultats fiables, et une gouvernance qui maintient les humains responsables là où la responsabilité ne peut pas être déléguée.

La valeur ne disparaît pas avec la commoditisation du code. Elle se déplace vers l'intention, vers le contrôle, vers la capacité à formuler les bons problèmes. C'est là que les ingénieurs, les DSI, et les organisations qui les accompagnent doivent investir leurs efforts — maintenant, pas après le prochain POC.