Agent-oriented development : ne pas reproduire les mécanismes du passé

De l'assistant au décideur : une rupture silencieuse mais profonde

Pendant des années, nous avons appris à travailler avec nos outils. Les IDE, les frameworks, les pipelines CI/CD : autant de leviers que le développeur maîtrisait, orchestrait, dirigeait. L'IA générative est d'abord arrivée dans cette continuité — sous la forme du copilote, du suggéreur, de l'assistant qui complète une ligne, propose une fonction, anticipe un pattern.

Puis quelque chose a changé. Pas progressivement. Brutalement.

En février 2025, le lancement de Claude Code a matérialisé un basculement que beaucoup pressentaient sans vraiment l'avoir formulé : l'IA ne suggère plus, elle agit. Elle manipule des fichiers, exécute des commandes, interagit avec l'environnement de développement, enchaîne des tâches complexes sans attendre de validation à chaque étape. Le développeur, lui, glisse vers un rôle de superviseur et d'architecte d'intention. C'est une rupture opérationnelle, pas un gain de productivité incrémental.

Cette rupture pose une question que beaucoup d'équipes techniques esquivent encore : comment construire des systèmes logiciels à l'ère des agents autonomes sans reproduire les erreurs architecturales du passé ? Car l'histoire de l'ingénierie logicielle est pavée de bonnes intentions technologiques transformées en dettes colossales. Le risque, aujourd'hui, est de plaquer des réflexes hérités de l'architecture monolithique ou même des premiers microservices sur des paradigmes fondamentalement différents.

Ce que l'on entend vraiment par "développement orienté agent"

L'agent-oriented development n'est pas simplement l'utilisation d'outils comme Claude Code, OpenAI Codex CLI ou Gemini CLI dans un workflow existant. C'est une manière de concevoir des systèmes dans lesquels des entités autonomes — les agents — perçoivent leur environnement, prennent des décisions, exécutent des actions et collaborent pour accomplir des objectifs complexes.

Ce paradigme repose sur quelques principes fondateurs :

• L'autonomie partielle : un agent n'attend pas d'instruction explicite pour chaque micro-décision. Il dispose d'un objectif, d'un contexte, et d'une capacité d'action.
• La réactivité : l'agent perçoit les changements dans son environnement et adapte son comportement en conséquence.
• La proactivité : il initie des actions pour atteindre ses objectifs, sans se contenter de répondre à des stimuli externes.
• La sociabilité : les agents interagissent entre eux, se délèguent des tâches, négocient des résultats.

Ce dernier point est crucial. Un agent isolé reste un outil sophistiqué. Un réseau d'agents qui collaborent — ce que l'on commence à appeler un Agentic Mesh — devient une infrastructure capable de traiter des flux de travail d'une complexité inédite. Et c'est précisément là que les mécanismes du passé peuvent devenir dangereux si on les applique sans discernement.

Le piège des vieilles architectures dans des habits neufs

L'histoire du génie logiciel est marquée par des transitions douloureuses. Le passage du monolithe aux microservices a libéré les équipes de certaines contraintes de déploiement et de scalabilité, mais il a aussi engendré une complexité distribuée que beaucoup d'organisations n'avaient pas anticipée : explosion du nombre de services, difficultés de traçabilité, couplage implicite via les événements, enfer de la configuration.

Aujourd'hui, on observe des signaux inquiétants chez certaines équipes qui abordent le développement agentique avec les mêmes réflexes :

• Concevoir des agents comme des microservices glorifiés, sans penser à leur autonomie réelle ni à leurs mécanismes de coordination.
• Orchestrer de façon centralisée et rigide des workflows qui devraient être fluides et adaptatifs.
• Ignorer les questions de gouvernance, de traçabilité et d'observabilité jusqu'à ce qu'elles deviennent un problème de production.
• Traiter le prompt engineering comme un simple remplacement du code fonctionnel, sans structure ni versionning.

Le résultat, dans ces cas, est prévisible : des systèmes agentiques qui fonctionnent en démo, mais qui s'effondrent en production sous la pression de cas limites, de comportements non déterministes, ou d'interactions inter-agents imprévues. L'IA agentique n'est pas un microservice qui appelle un LLM. Elle nécessite un cadre architectural pensé pour l'autonomie, l'incertitude et la collaboration.

L'IA Mesh : penser en réseau, pas en silo

Pour dépasser ces écueils, un concept émerge avec force dans les réflexions architecture de 2025-2026 : celui d'IA Mesh. À l'image du service mesh qui a résolu les problèmes de communication inter-services dans les architectures microservices, l'IA Mesh propose une couche d'infrastructure dédiée à la coordination, à la communication et à la gouvernance des capacités d'intelligence artificielle distribuées dans le système d'information.

L'IA Mesh ne désigne pas un produit, mais une vision architecturale. Elle postule que les capacités IA — modèles de langage, agents spécialisés, pipelines de traitement de données, outils d'inférence — doivent être traitées comme des citoyens de première classe de l'architecture d'entreprise, au même titre que les APIs REST ou les services de messagerie.

Concrètement, cela implique :

• Un registre de capacités : savoir quels agents existent, ce qu'ils font, quelles sont leurs limites et leurs garanties de service.
• Des protocoles de communication standardisés : des formats d'échange entre agents qui permettent l'interopérabilité, sans couplage fort.
• Une observabilité native : tracer les décisions, les appels, les coûts et les résultats de chaque agent pour pouvoir auditer, déboguer et améliorer.
• Des mécanismes de fallback et de supervision : quand un agent échoue ou produit un résultat incertain, le système doit savoir quoi faire.

L'IA Mesh est, en ce sens, une réponse architecturale à la question : comment faire fonctionner des dizaines ou des centaines d'agents de façon fiable, auditable et évolutive ?

L'Agentic Mesh : quand les agents se coordonnent d'eux-mêmes

Si l'IA Mesh désigne l'infrastructure qui supporte les agents, l'Agentic Mesh désigne le modèle d'organisation et de collaboration de ces agents eux-mêmes. C'est un concept plus dynamique, plus organique : il s'agit de la façon dont les agents se découvrent, se délèguent des tâches, négocient des priorités et produisent des résultats collectifs sans orchestration centrale rigide.

La distinction est importante. Dans un modèle d'orchestration classique, un agent maître décompose un problème et distribue les tâches à des agents esclaves. Ce modèle est lisible, mais fragile : il crée un point de défaillance unique et manque de flexibilité face à des situations imprévues.

L'Agentic Mesh propose une alternative : des agents qui chorégraphient leur collaboration plutôt que de la recevoir d'en haut. Un agent qui rencontre une tâche hors de ses compétences peut solliciter dynamiquement un agent pair plus adapté. Des agents peuvent se superviser mutuellement, vérifier les résultats les uns des autres, escalader vers un humain quand le niveau de confiance est insuffisant.

Ce modèle est bien plus proche de la façon dont les organisations humaines performantes fonctionnent — en mode réseau plutôt qu'en mode hiérarchique strict. Et c'est précisément ce parallèle qui doit alerter les architectes : une organisation humaine en réseau ne s'improvise pas, elle se conçoit. Elle nécessite des rôles clairs, des protocoles de communication, des mécanismes de résolution de conflits, et une culture partagée. Il en va de même pour un Agentic Mesh.

Des standards comme MCP (Model Context Protocol) d'Anthropic ou le protocole A2A (Agent-to-Agent) de Google commencent à poser les bases de cette interopérabilité. Mais la standardisation reste embryonnaire, et les équipes qui construisent aujourd'hui des Agentic Meshes doivent faire des choix d'architecture qui engageront leurs systèmes pour plusieurs années.

La Stack AI-Ready : ce que "prêt pour l'IA" signifie vraiment

On entend souvent des organisations déclarer qu'elles sont "AI-ready". Dans la pratique, cette affirmation recouvre des réalités très disparates. Avoir intégré un chatbot dans son intranet n'est pas être AI-ready. Avoir un data lake bien structuré est une condition nécessaire mais pas suffisante. Une stack vraiment AI-ready pour l'ère agentique est une stack conçue pour accueillir, coordonner et gouverner des systèmes autonomes.

Chez SFEIR, nous avons formalisé cette notion autour de plusieurs dimensions :

1. La couche données

Les agents ont besoin de données fraîches, contextualisées et fiables. Cela implique des pipelines de données qui vont bien au-delà du batch traditionnel : ingestion en quasi-temps réel, gestion des métadonnées sémantiques, vecteurisation pour la recherche par similarité, et surtout une gouvernance de la qualité qui soit automatisable. Un agent qui raisonne sur des données périmées ou incohérentes produit des décisions dangereuses.

2. La couche modèles

La Stack AI-Ready ne choisit pas un seul modèle de langage. Elle est capable d'en orchestrer plusieurs selon les cas d'usage : un modèle léger pour les tâches à fort volume et faible complexité, un modèle puissant pour le raisonnement complexe, un modèle spécialisé pour un domaine métier particulier. Cette orchestration multi-modèles est une compétence en soi, avec ses propres enjeux de coût, de latence et de cohérence.

3. La couche orchestration et runtime

C'est ici que réside la majorité de la complexité architecturale. Comment planifier les tâches des agents ? Comment gérer leur état entre les interactions ? Comment implémenter des mécanismes de retry, de timeout et de supervision ? Des frameworks comme LangGraph, CrewAI ou AutoGen proposent des réponses, mais chacun avec ses compromis. Le choix n'est pas anodin et doit être aligné sur la philosophie d'orchestration vs. chorégraphie adoptée par l'équipe.

4. La couche observabilité et gouvernance

C'est probablement la dimension la plus sous-estimée. Un système agentique qui n'est pas observable est un système non gouvernable. Cela signifie : tracer chaque appel de modèle avec son coût et sa latence, logguer les décisions des agents avec leur contexte, implémenter des garde-fous pour détecter les comportements anormaux ou les dérives éthiques, et produire des rapports d'audit utilisables par des équipes non techniques.

5. La couche sécurité et souveraineté

Des agents autonomes qui ont accès à des systèmes critiques représentent une surface d'attaque considérable. La Stack AI-Ready doit intégrer nativement des mécanismes de contrôle d'accès fin (un agent ne doit pouvoir accéder qu'aux ressources dont il a besoin), de détection d'injection de prompt, et de conformité avec les exigences réglementaires — RGPD, AI Act européen, politiques internes de sécurité.

L'évolution du métier d'ingénieur logiciel

Si les architectures changent, les métiers changent aussi. Et c'est sans doute là que le sujet devient le plus vertigineux pour les équipes techniques.

Claude Code et ses successeurs — OpenAI Codex CLI, Gemini CLI, Mistral Code et d'autres qui émergeront inévitablement — transforment la chaîne de valeur du développement logiciel. Les équipes techniques passent progressivement de la rédaction syntaxique à l'ingénierie d'intention et à la supervision de qualité. Ce ne sont pas des mots pour rassurer : c'est une description précise d'un nouveau partage des responsabilités.

L'ingénierie d'intention, c'est la capacité à formuler clairement ce qu'un système doit accomplir — au niveau fonctionnel, aux limites, aux cas d'erreur — de façon suffisamment précise pour qu'un agent puisse l'exécuter de façon fiable. C'est une compétence qui ressemble davantage à la rédaction de spécifications fonctionnelles rigoureuses qu'à de la programmation au sens classique. Elle valorise la clarté de pensée, la connaissance du domaine métier, et la capacité à anticiper les comportements inattendus.

La supervision de qualité, elle, demande de savoir évaluer un code ou un système produit par un agent : identifier les failles logiques, les problèmes de performance, les risques de sécurité, les dettes architecturales que l'agent a pu introduire. C'est une compétence de senior engineer appliquée à un volume de production considérablement augmenté.

Pour les organisations, cela implique d'investir massivement en conduite du changement. Non pas pour rassurer les équipes que "leurs emplois sont saufs" — ce discours paternaliste ne convainc personne — mais pour leur donner concrètement les outils, les formations et les espaces d'expérimentation pour développer ces nouvelles compétences.

Comment SFEIR accompagne cette transition

Chez SFEIR, nous avons fait le choix de ne pas rester spectateurs de cette transformation. Nous l'expérimentons d'abord sur nos propres projets, nos propres pratiques, nos propres outils internes — avant de l'emmener chez nos clients.

Nos équipes d'architectes et d'ingénieurs travaillent depuis plusieurs mois sur des missions concrètes qui matérialisent ces concepts :

• Audit et refactoring de stacks existantes vers une posture AI-Ready : évaluation de la maturité des pipelines de données, identification des couplages qui empêcheront l'intégration fluide d'agents, recommandations d'outillage pour l'observabilité IA.
• Conception d'Agentic Meshes métier : accompagnement d'équipes produit dans la définition des agents nécessaires, de leurs périmètres de responsabilité, de leurs protocoles d'interaction et de leurs mécanismes de supervision humaine.
• Formation et montée en compétences des équipes techniques sur les nouveaux paradigmes — prompt engineering structuré, évaluation de systèmes non déterministes, tests d'agents autonomes.
• Cadres de gouvernance IA : co-construction avec les équipes sécurité, juridique et conformité de politiques pratiques pour déployer des agents en production dans des contextes réglementés.

Ce qui ressort de ces missions, c'est un constat récurrent : les organisations qui réussissent leur transition vers le développement agentique ne sont pas celles qui ont adopté les outils le plus vite, mais celles qui ont pris le temps de poser les bonnes questions architecturales dès le départ. Qui contrôle quoi ? Comment audite-t-on les décisions des agents ? Quel niveau d'autonomie est acceptable dans quel contexte ? Comment forme-t-on les équipes à superviser ce qu'elles ne produisent plus directement ?

Ce sont des questions d'ingénierie, certes. Mais aussi des questions d'organisation, de culture et de gouvernance. C'est pourquoi, dans nos missions, nous associons systématiquement les dimensions technologiques et humaines.

Construire pour demain sans sacrifier aujourd'hui

L'agent-oriented development n'est pas une mode. C'est une évolution structurelle de la façon dont les systèmes logiciels seront conçus, construits et exploités dans les années à venir. Comme toutes les évolutions structurelles, elle crée de la valeur considérable pour ceux qui la comprennent vraiment — et des risques sérieux pour ceux qui l'adoptent superficiellement.

Le danger principal n'est pas de rater le train. C'est de monter dedans trop vite, avec les mauvaises cartes en main, et de reproduire les erreurs architecturales qui ont coûté des années de refactoring à toute une génération d'équipes techniques.

L'IA Mesh, l'Agentic Mesh, la Stack AI-Ready ne sont pas des concepts abstraits. Ce sont des réponses concrètes à des problèmes concrets que les équipes rencontrent dès aujourd'hui en production : comment faire travailler des agents ensemble de façon fiable ? Comment gouverner des systèmes autonomes sans les rendre imprévisibles ? Comment construire une infrastructure qui supporte l'intelligence artificielle comme elle supporte déjà le reste du système d'information ?

Répondre à ces questions demande de l'expertise, de l'humilité intellectuelle — accepter que les modèles mentaux hérités ne s'appliquent pas toujours — et une volonté sincère d'apprendre collectivement. C'est dans cet esprit que SFEIR aborde le sujet, avec ses clients comme en interne.

L'avenir du développement logiciel sera agentique. La question n'est pas si, mais comment. Et le comment, c'est maintenant qu'il se décide.