Mettre l'agentique adaptative en production, illustration avec RAISE (Partie 1)

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

Nous posons 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, 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.

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

Nous passons à 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

Nous passons à 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 la première partie, nous avons posé le diagnostic : l'agentique actuelle échoue à passer du POC à la production, faute de fiabilité, d'observabilité et de capacité d'apprentissage.

Dans la deuxième partie, nous avons présenté la vision : l'agentique adaptative et ses principes fondamentaux (auto-observabilité, les trois piliers cognitifs, mémoire organisationnelle vivante, architecture multi-agents, human in the middle évolutif).

Dans cette troisième partie, nous passons à la concrétisation : comment ces principes se traduisent dans une plateforme IA, en l’occurrence RAISE, la plateforme d'IA générative du groupe SFEIR. Des fonctionnalités opérationnelles aux démonstrations concrètes.

Parce qu'entre avoir raison sur le papier et faire tourner un système en production, il y a toute l'implémentation. Et c'est précisément là que tout se joue. Comment mettre en place un système agentique IA, démonstration avec une implémentation AI4Ops !

RAISE : un accélérateur d'implémentation, pas un framework de plus

Soyons clairs dès le départ : RAISE n'est pas un énième framework AI qui vient grossir la cohorte des solutions disponibles.

RAISE est avant tout un accélérateur d'implémentation. Une plateforme qui permet de mettre en production un grand nombre de briques et de frameworks de manière fiable et maîtrisée, avec une architecture cohérente qui facilite les extensions.

Cette architecture propre et modulaire constitue un atout majeur. Lorsque j’ai rejoint WEnvision et le Groupe SFEIR, et découvert leur vision du SI conversationnel et l’approche hexagonale / modulaire de RAISE, je me suis dit que nous n’aurions pas à tout reconstruire. De fait, l'architecture de RAISE nous a permis d'implémenter facilement ces nouveaux concepts agentiques de façon naturelle, par extension plutôt que par refonte.

C'est cette capacité d'extension qui fait la différence entre un POC et un système production-ready. Vous ne reconstruisez pas tout à chaque évolution. Vous étendez, vous composez, vous orchestrez.

Voyons maintenant concrètement comment nous avons traduit les principes de l'agentique adaptative en fonctionnalités opérationnelles dans RAISE, pour du support IT.

Auto-observabilité : voir ce que pense l'agent

La première fonctionnalité que nous avons implémentée, c'est l'auto-observabilité systématique. Pas comme une option. Comme une brique fondamentale, présente sur chaque réponse de n'importe quel assistant ou agent d'un réseau à disposition des administrateurs, gestionnaires et superviseurs d’agents adaptifs.

Interface RAISE : la "Pensée de l'agent" expose automatiquement son raisonnement, son auto-évaluation et son plan d'action

Ce que vous voyez

À chaque fois qu'un agent répond, il génère automatiquement une observation de son propre raisonnement. Cette observation n'est pas visible par défaut dans la conversation (pour ne pas polluer l'échange), mais elle est accessible via un simple toggle, et surtout en base pour les analyses futures.

Quand vous l'activez, vous voyez une carte compacte qui expose :

Carte d'auto-observation : pensée de l'agent, auto-évaluation (9/10), raisonnement détaillé et plan d'action projeté

La synthèse : "L'utilisateur demande à débloquer un pipeline CI/CD qui échoue. Le problème semble venir d'une dépendance manquante."

L'auto-évaluation : une note de 0 à 10 que l'agent se donne sur sa réponse.

• 8/10 : "J'ai accès aux logs et au contexte, mais je n'ai pas encore vérifié la configuration."
• 3/10 : "Je manque d'informations sur l'architecture de ce projet."

L'humeur détectée : "L'utilisateur semble pressé et frustré."

La pensée interne : "Le pipeline échoue probablement à l'étape de tests. L'utilisateur a mentionné que ça marchait hier, donc c'est probablement lié à un changement récent."

Le plan :

1. Analyser les logs du pipeline
2. Vérifier les changements récents dans les dépendances
3. Proposer une solution de contournement si nécessaire

La prochaine étape : "Attendre que l'utilisateur me donne accès aux logs Jenkins ou me confirme quel pipeline est concerné."

Pourquoi c'est essentiel ?

Sans cette observabilité, vous êtes aveugle. L'agent répond, mais vous ne savez pas :

• S'il a bien compris votre demande.
• S'il est confiant dans sa réponse.
• Où il hésite.
• Quel plan il a en tête.
• Ce qui lui manque pour mieux répondre.

Avec l'observabilité systématique, chaque interaction devient transparente. Vous pouvez voir quand l'agent perd confiance, quand il fait des suppositions hasardeuses, quand son plan est bancal.

Et surtout : vous pouvez analyser les patterns. "Pourquoi l'agent se met systématiquement 4/10 sur ce type de question ?" → Il manque d'information dans le graphe de connaissances. Vous enrichissez le graphe, et soudain la confiance remonte à 8/10.

Sans cette visibilité, vous ne pouvez pas améliorer. Avec elle, chaque problème devient identifiable et adressable.

Le réseau d'agents de base : penser en parallèle

L'observabilité, c'est voir. Mais pour agir intelligemment, il faut une architecture qui permette de raisonner en parallèle, de fusionner les contextes, de prendre des décisions éclairées.

Voici comment fonctionne le réseau d'agents de base dans RAISE pour tout agent adaptatif.

Trois rôles, un objectif

Configuration multi-agents : 1 Front Agent (Orchestrator) + 2 Back Agents parallèles (Knowledge Keeper, Mission Strategist) + 1 on-demand (Code Builder)

Le Front Agent est votre point de contact. C'est lui qui reçoit vos messages, qui orchestre le travail, qui vous répond. Mais il ne fait pas tout le raisonnement seul.

Quand vous lui posez une question, il la dispatche en parallèle à deux agents spécialisés :

• Le Knowledge Keeper connaît votre organisation. Il sait qui fait quoi, quelle est votre stack technique, comment vous travaillez, quelles décisions ont été prises par le passé. Quand vous dites "contacte quelqu'un de la compta", c'est lui qui sait qui contacter.
• Le Mission Strategist connaît vos objectifs. Il sait sur quels projets vous travaillez, quelles sont les tâches en cours, où en sont les différentes missions. Quand vous demandez "où en est le projet X", c'est lui qui a la réponse.

Pourquoi en parallèle ?

Parce que c'est comme ça que vous raisonnez naturellement. Quand nous vous posons une question professionnelle, vous ne pensez pas d'abord au contexte organisationnel, puis ensuite à votre mission. Vous faites les deux en même temps.

"Qui peut m'aider sur ce sujet ?" → Vous pensez simultanément aux compétences des gens (contexte org) et à qui est disponible / aligné avec les priorités (contexte mission).

Le Front Agent reçoit les deux analyses, les fusionne, et construit une réponse qui a du sens à la fois organisationnellement et stratégiquement.

Ce n'est pas une cascade d'appels API. C'est une vraie collaboration cognitive.

Cette approche déclenche plusieurs appels LLM pour une entrée utilisateur, mais ce fractionnement permet d’utiliser des modèles légers, rapides, et dont le coût est plus intéressant que les gros LLM classiques.

Les graphes de connaissances : deux mémoires spécialisées

Ces agents ne raisonnent pas sur rien. Ils s'appuient chacun sur une structure de connaissances qui évolue avec votre organisation.

Le Knowledge Keeper Graph : la mémoire organisationnelle

Le Knowledge Keeper maintient un graphe qui structure trois dimensions de votre organisation :

• L'organisation humaine : qui fait partie de quelle équipe ? Qui est responsable de quoi ? Comment les services s'articulent ?
• La dimension technique : quelle stack utilisez-vous ? Comment votre infrastructure est architecturée ? Où trouver la documentation ?
• La culture et l'histoire : comment prenez-vous les décisions ? Quelles sont vos conventions de travail ? Pourquoi avez-vous fait tel choix il y a 6 mois ?

Ce graphe se construit progressivement. Au fil des conversations, l'agent détecte les informations structurantes : "Ah, tu mentionnes que Sarah a rejoint l'équipe DevOps. Je peux ajouter ça au graphe ?" Vous validez. Le graphe grandit. L'agent devient de plus en plus pertinent.

L'utilisateur envoie un organigramme fictif de WEnvision au système

Le Knowledge Keeper interprète les informations organisationnelles

Visualisation du Knowledge Graph (Live) : 23 entités et 26 relations représentant la structure organisationnelle de WEnvision

Le Mission Strategist Graph : la vision mission et workflow

Le Mission Strategist, lui, maintient un graphe différent :

• Les missions : quels sont vos objectifs ? Quelles sont les priorités ? Que cherchez-vous à accomplir ce trimestre ?
• Les tâches : comment décomposez-vous le travail ? Quelles sont les tâches du sprint ? Qui est assigné à quoi ?
• Le workflow : comment les choses s'enchaînent ? Quel est votre processus de validation ? Comment passez-vous d'une phase à l'autre ?

Ce graphe évolue vite. Un projet avance, des tâches sont terminées, de nouvelles missions apparaissent. C'est une mémoire dynamique qui suit le rythme de votre activité.

L'utilisateur (administrateur) définit une mission de support pour l'agent adaptatif

Le Mission Strategist capte les informations et les transcrit dans un GraphRag orienté process/workflow

L'auto-observation reste essentielle et est enrichie d'informations sur les outils utilisés

Pourquoi deux graphes ?

Parce que les rythmes d'évolution sont différents. Votre organisation change lentement (quelques recrutements par mois, une réorganisation par an). Vos missions changent vite (nouveaux sprints, nouvelles tâches, nouvelles priorités chaque semaine).

Séparer les graphes permet d'adapter les stratégies de mise à jour et les mécanismes de validation. Et surtout, chaque agent peut se concentrer sur une structure optimisée pour son rôle.

Fin de la Partie 1. Retrouvez la suite de cet article dans la Partie 2.