L'agentique qui marche presque ne marche pas

Comprendre les systèmes agentiques adaptatifs

L'agentique est partout. Nous en parlons, nous en faisons, nous en vendons. Mais entre les démos impressionnantes et les systèmes qui tiennent en production, il y a un gouffre que peu franchissent.

Cette série en trois parties explore ce gouffre, et comment le traverser.

Partie 1 - L'agentique qui marche presque ne marche pas

On pose les fondations conceptuelles. Pourquoi l'agentique actuelle passe difficilement du POC à la production, quels sont les pièges systématiques, et sur quels principes construire pour les éviter. Le problème n'est pas que ça plante, c'est que cela marche "à peu près", et pour arriver à l'étape de la production, cela n'atteint pas le niveau de fiabilité voulu. Et surtout, on ne sait pas comment l'améliorer parce qu'on n'a pas outillé le système pour ça dès le départ.

Partie 2 - L'agentique adaptative : les principes d'une IA qui grandit

On passe à la vision. Les principes de l'agentique adaptative, comment construire des systèmes qui ne se contentent pas d'exécuter mais qui observent, apprennent, et grandissent. Nous explorons les piliers architecturaux qui rendent cette vision possible.

Partie 3 - Mettre l'agentique adaptative en production, illustration avec RAISE

→ Partie 3a : Architecture, conception et opérationnalisation

→ Partie 3b : Orchestration multi-agents et knowledge graph dynamique

On passe à l'implémentation. Comment ces principes se traduisent concrètement dans RAISE, la plateforme d'IA générative du groupe SFEIR. Quelles architectures, quels choix de design, quelles mécaniques mettre en place. Du concept à la réalité opérationnelle.

Parce qu'entre avoir raison sur le papier et faire tourner un système en production, il y a tout un monde. Et c'est précisément ce monde-là que nous allons explorer.

Dans cette première partie de notre série d'articles sur les systèmes agentiques, nous posons le diagnostic : pourquoi l'agentique actuelle passe difficilement du POC à la production, quels sont les pièges systématiques qui la condamnent. Le problème n'est pas que ça plante, c'est que cela marche "à peu près", et pour arriver à l'étape de la production, cela n'atteint pas le niveau de fiabilité voulu. Et surtout, nous ne savons pas comment l'améliorer parce que nous n'avons pas outillé le système pour ça dès le départ.

Le problème que nous refusons de voir

J'ai vu passer beaucoup de démos ces derniers mois. Des architectures impressionnantes : 12 agents spécialisés, 47 embranchements conditionnels, des graphes qui prennent tout l'écran. Ça tourne parfaitement (enfin presque). Du moins, le système agentique fait en apparence ce qu'on lui demande.

Et trois mois plus tard, c'est toujours pareil. Ça marche dans les mêmes cas, ça coince sur les mêmes limites. Le système n'a rien appris.

Même constat pour les solutions sur étagère vendues comme des agents autonomes. L'autonomie est souvent très relative. Le système apprend peut-être, mais la maîtrise de cet apprentissage reste côté concepteur, pas côté client. Vous ne pouvez pas l'adapter à votre contexte, le faire évoluer selon vos besoins. C'est de l'autonomie sous contrainte.

Et surtout, c'est une autonomie qui ne survit pas à la réalité du terrain. Le système est autonome jusqu'à ce qu'il ne le soit plus…

"L'important c'est pas la chute, c'est l'atterrissage" - Hubert, La Haine

Le système n'a rien appris, ou a appris d'une façon qu'on ne maîtrise pas. Il n'a pas évolué comme on l'aurait voulu. Il s'est contenté d'exécuter, encore et encore, la même logique figée dans son architecture. C'est beau à regarder, mais c'est mort à l'intérieur.

Voilà le vrai problème de l'agentique aujourd'hui : on construit des systèmes qui agissent, mais qui n'apprennent pas, ou apprennent mal. Et qui ne survivent pas au passage à l'échelle.

Le piège du POC qui marche presque

Il y a donc ce piège, peut-être le plus vicieux de tous dans l’exploration de l’IA générative : la facilité trompeuse du POC.

Mettre en place un système agentique qui marche presque, c'est incroyablement facile aujourd'hui. En quelques heures, vous avez une démo qui impressionne. L'agent répond, il enchaîne les actions, il a l'air de comprendre.

Vous testez 5-6 cas d'usage : "Crée-moi une entité client", "Récupère les infos du projet X", "Génère un rapport sur Y". Ça passe. L'agent crée l'entité, trouve le projet, produit le rapport. Tout le monde est content.

Et puis vous essayez de passer en production.

C'est là que le rêve se fracasse sur le réel.

Un utilisateur demande : "Crée-moi un client pour le projet Mercure avec les mêmes infos que le client du projet Apollo". L'agent cherche Apollo, ne le trouve pas (il s'appelle "Apollo 2024" dans la base), demande une clarification. L'utilisateur reformule. L'agent crée le client, mais oublie de copier l'adresse de facturation parce que le workflow n'avait pas prévu cet aller-retour de clarification. Trois échanges pour un truc qui aurait dû passer en un. Et le pire : le système n'a pas détecté qu'il avait déjà fait cette erreur avec d'autres utilisateurs la semaine dernière, n'a rien notifié, et encore moins corrigé tout seul.

Pourquoi ce use case précis, que vous n'aviez pas anticipé, fait planter le système ? Pourquoi cet utilisateur obtient-il une réponse complètement à côté alors que la question semble évidente ? Vous changez de modèle (GPT vers Gemini, ou l'inverse) et soudain, tout se comporte différemment. Certaines choses s'améliorent, d'autres se dégradent. Mais lesquelles exactement ?

Vous ajustez un prompt. Ça semble mieux sur le cas qui posait problème. Mais êtes-vous certain que vous n'avez pas cassé 10 autres cas sans vous en rendre compte ?

Le problème, c'est que vous n'avez aucune visibilité sur ce qui compte vraiment.

Bien sûr, vous avez mis en place les mesures standards des solutions de supervision LLM : les performances générales du modèle (vitesse de traitement, utilisation des ressources), le time to first token (le temps que met le modèle à commencer à générer sa première réponse, indicateur clé de réactivité perçue), la gestion des pouces en l'air/en bas sur les réponses. Mais dans le cadre de l'agentique, ça ne suffit pas. Vous n'avez pas de métriques sur la qualité du raisonnement, pas de baseline sur les décisions prises, pas de tests de régression sur les patterns d'interaction, pas de système qui vous alerte quand la qualité décroche vraiment.

Vous itérez à l'aveugle, en croisant les doigts pour que ça tienne. Et ça ne tient jamais longtemps.

Le gouffre entre POC/DEMO et PRODUCTION : un challenge qui fait tomber la plupart des projets agentiques

Il y a un monde (un gouffre) entre marche presque et "production ready". Et ce gouffre, c'est celui de l'observabilité et de la mesure. Sans instrumentation, sans évaluation systématique, sans capacité à comprendre pourquoi le système fait ce qu'il fait, vous construisez sur du sable.

C'est pour ça que la plupart des POCs agentiques meurent avant d'atteindre la production, ou font transpirer leurs concepteurs une fois la porte de la prod franchie. Pas parce que la techno ne marche pas. Mais parce que nous n'avons pas construit les conditions de la fiabilité.

Faire agir un LLM : le "if / then" tue la plasticité décisionnelle

Dès que nous avons voulu faire agir un modèle de langage (au-delà du simple échange conversationnel), nous avons dû lui donner des outils, un cadre d'action, une façon d'interagir avec le système d'information. C'est logique. Un LLM seul ne peut rien faire dans le monde réel.

Mais quelque chose de pervers s'est produit.

Nous avons commencé à modéliser ces interactions : définir les étapes, les conditions, les embranchements. Nous avons voulu créer des workflows. Et nous avons ramené ces modèles (conçus pour raisonner) dans notre vision algorithmique classique, celle des if/then, des boucles, des états et des conditions.

En gros, nous les avons traités comme des API "intelligentes".

Le résultat ? Des systèmes qui ressemblent à des diagrammes gonflés aux stéroïdes.

Cette capacité à s'adapter, à improviser, à trouver des solutions que nous n'avions pas programmées.

Ou pour le dire autrement :

Ou pour le dire dans les termes des data scientists : nous avons sacrifié la valeur stochastique des LLM sur l'autel du déterminisme procédural.

Pattern vs anti-pattern : où sont vos boucles de feedback ?

L'agentique ouvre un champ d'expérimentation passionnant. Mais c'est aussi un terrain miné.

Le pattern vertueux, c'est un système qui apprend de lui-même. Où les agents partagent un but, se corrigent, s'enrichissent mutuellement. Où l'humain reste dans la boucle, pas pour tout contrôler, mais pour guider, arbitrer, donner du sens.

L'anti-pattern, lui, se cache souvent derrière des architectures qui impressionnent. Des dizaines d'agents reliés par des embranchements logiques. Ça tourne, ça exécute, ça a l'air vivant.

Mais il n'y a ni mémoire, ni apprentissage, ni boucle de supervision claire. Le système se répète. Il ne progresse pas. Et plus nous le complexifions, plus nous rendons son fonctionnement opaque et sa qualité difficile à mesurer.

Pattern vertueux (système qui grandit) vs Anti-pattern (belle mécanique sans évolution)

J'ai vu des systèmes qui tournaient en boucle fermée, sans humain dans le circuit. Nous les vendions comme "autonomes". En réalité, c'étaient des illusions : le système n'apprenait rien, il rejouait la même partition indéfiniment. Comme un élève livré à lui-même, sans feedback, sans correction, sans direction.

Soyons clairs : l'autonomie immédiate est un mirage.

Les agents réellement autonomes n'existent pas encore. Pas parce que la techno n'est pas là, mais parce que nous avons sauté l'étape cruciale : l'apprentissage supervisé évolutif. Un système ne peut s'améliorer que s'il est observé, évalué et guidé, et qu'il gagne en autonomie de façon harmonieuse avec ses utilisateurs.

Conclusion : il nous faut des principes fondamentaux

Nous avons posé le diagnostic. L'agentique actuelle souffre de quatre maux systémiques :

1. Le syndrome du POC impressionnant : des démos qui marchent sur 5 cas, mais s'effondrent sur le 6e que nous n'avions pas prévu.
2. La perte de plasticité : des architectures rigides qui ont tué la plasticité cognitive de l’IA générative au nom de la prévisibilité.
3. L'absence d'observabilité : nous itérons à l'aveugle, sans comprendre pourquoi ça passe ou pourquoi ça casse.
4. Le mirage de l'autonomie immédiate : des systèmes vendus comme autonomes qui n'apprennent rien.

Pour franchir le gouffre entre POC et production, il ne suffit pas d'ajouter plus d'agents, plus de conditions, plus de complexité. Il faut repenser les fondations.

Il nous faut des principes architecturaux qui permettent à un système d'apprendre, de s'adapter, de grandir.

C'est ce que nous détaillons dans la deuxième partie : les principes de l'agentique adaptative.