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

Gouvernance : qui décide de quoi ?

Question cruciale : qui peut modifier ces graphes ? Les agents, les humains, les deux ?

Dans RAISE, nous avons implémenté plusieurs stratégies de gouvernance que vous pouvez choisir selon votre niveau de maturité :

Stratégie 1 : apprentissage ouvert

Tous les agents peuvent proposer des modifications aux deux graphes. Vous validez tout. C'est idéal en phase initiale, quand le système découvre votre organisation et qu'il faut enrichir rapidement.

Stratégie 2 : connaissance ouverte, mission protégée

Les agents peuvent enrichir librement le graphe organisationnel (l'organisation évolue lentement, les erreurs sont faciles à corriger). Mais seuls les administrateurs peuvent modifier le graphe de mission (les priorités sont stratégiques, nous ne voulons pas qu'un agent change les objectifs).

Gestion des permissions sur les outils : distinction entre outils en lecture seule et outils d'écriture, avec droits Administrateur vs Utilisateur

Stratégie 3 : verrouillage complet

Les graphes sont en lecture seule pour les agents. Seuls des humains autorisés peuvent les modifier. Utile pour des environnements très régulés ou des systèmes encore immatures.

Stratégie 4 : délégation progressive

La plus intéressante. Au départ, validation humaine systématique. Puis, au fur et à mesure que le système mûrit, certains types de modifications deviennent automatiques.

Exemple :

Cette stratégie incarne parfaitement le principe du "human in the middle évolutif" : on fait grandir l'autonomie progressivement, selon des règles claires.

Appel et génération dynamique de sous-agents : invoquer ce dont on a besoin

Les agents de RAISE ne sont pas que des exécutants. Ils peuvent utiliser ou même créer d'autres agents quand c'est nécessaire.

Configuration multi-agents : ajout d'un agent Code Builder en mode On-Demand, appelable par le Mission Strategist

Comment ça fonctionne ?

Imaginez : un utilisateur vous demande "Peux-tu créer un script Python qui me calcule les métriques de performance de nos pipelines CI/CD ?"

Le Mission Strategist détecte qu'il ne doit pas générer du code lui-même (ce n'est pas son rôle). Il appelle alors un sous-agent spécialisé : un "Code Builder".

Ce Code Builder :

• Est configuré pour générer du code propre et testé.
• A accès aux outils nécessaires (système de fichiers, exécution de tests).
• Dialogue avec le Mission Strategist pour obtenir le contexte manquant.

Le dialogue se passe en coulisses :

• Code Builder : "J'ai besoin de savoir où sont stockés les logs des pipelines."
• Mission Strategist interroge le Knowledge Keeper → obtient la réponse → la transmet.
• Code Builder génère le code, le teste, retourne le résultat.

Le Front Agent reçoit le résultat de l’échange et présente le résultat à l’utilisateur. Mission accomplie. Le Code Builder est libéré.

Pourquoi c'est puissant ?

Vous évitez deux écueils :

• L'explosion combinatoire : créer à l'avance tous les agents possibles pour tous les cas d'usage. C'est ingérable.
• Le prompt surchargé : faire tout faire par un seul agent. Le prompt devient illisible, la qualité se dégrade, les erreurs se multiplient.

Avec la génération dynamique, vous créez les agents dont vous avez besoin, quand vous en avez besoin, avec le contexte nécessaire. Ni plus, ni moins.

Subprompts : des instructions contextuelles à la demande

Créer des agents qui fonctionnent bien pose un défi technique majeur : la taille des prompts.

Le problème des prompts monolithiques

Un agent comme le Mission Strategist a besoin de beaucoup d'instructions :

• Comment créer des entités dans le graphe.
• Quelles propriétés sont obligatoires.
• Comment structurer des workflows séquentiels.
• Comment gérer les relations entre tâches.
• Comment répondre aux questions de l'utilisateur.
• Comment gérer les erreurs.

Si vous mettez tout cela dans un seul prompt, vous vous retrouvez avec 1 000 lignes de texte chargées à chaque interaction. Résultat :

• Énorme coût en tokens : vous payez pour recharger les mêmes instructions encore et encore.
• Perte de pertinence : plus le prompt est long, plus l'agent a du mal à se concentrer sur ce qui compte vraiment pour la tâche en cours.
• Maintenance cauchemardesque : modifier une instruction nécessite de naviguer dans un fichier immense.

La solution : des instructions modulaires

Dans RAISE, nous avons implémenté un système de subprompts : des fragments d'instructions modulaires que l'agent charge dynamiquement selon le contexte.

Interface de gestion des SubPrompts : fragments d'instructions modulaires chargés dynamiquement par les agents selon le contexte

Voici comment ça fonctionne :

Le prompt principal de l'agent est minimal (environ 250 lignes). Il contient :

• l'identité de l'agent ;
• la structure du système adaptatif (les autres agents, son rôle parmi eux) ;
• les outils disponibles ;
• les subprompts disponibles par catégorie.

Les instructions détaillées sont dans des subprompts :

• entity_creation_rules : toutes les règles pour créer des entités dans le graphe
• workflow_patterns : les patterns de workflows séquentiels
• query_optimization : comment interroger efficacement le graphe
• cross_agent_communication : comment dialoguer avec d'autres agents

Création d'un SubPrompt "entity_creation_rules" : règles détaillées pour créer des entités dans le graphe de connaissances

L'agent charge ce dont il a besoin, quand il en a besoin

Exemple :

Pourquoi c'est puissant

• Économie de tokens : au lieu de charger 1 000 lignes à chaque fois, on charge 250 lignes + les 200 lignes pertinentes. Gain : 55% de tokens économisés.
• Fiabilité accrue : l'agent reçoit exactement les instructions dont il a besoin pour la tâche en cours. Pas de dilution, pas de confusion. La pertinence monte en flèche.
• Maintenance facilitée : vous voulez améliorer les règles de création d'entités ? Modifiez le subprompt entity_creation_rules. Tous les agents qui l'utilisent bénéficient immédiatement de l'amélioration.
• Réutilisabilité : un subprompt peut être utilisé par plusieurs agents. Les règles de communication inter-agents ? Partagées entre tous les agents du réseau.

C'est un des mécanismes clés qui permet à RAISE de passer à l'échelle tout en maintenant une haute qualité de raisonnement.

La boîte à outils : étendre sans reconstruire

Pour que les agents soient utiles, ils doivent pouvoir agir. Lire des fichiers, interroger des bases de données, appeler des API, exécuter du code.

Dans RAISE, nous avons implémenté une boîte à outils dynamique qui permet aux agents de découvrir et utiliser des outils sans que vous ayez à reconfigurer toute la plateforme.

Boîte à outils : catalogue d'outils disponibles avec historique d'exécutions et audit complet (Fibonacci Calculator exemple)

Le principe

Les outils sont des fonctions avec une description claire. Les agents peuvent lister les outils disponibles, comprendre ce qu'ils font, et les appeler quand c'est pertinent.

Exemple d'outil :

L'agent voit cet outil, comprend qu'il peut l'utiliser pour répondre à "Comment va le pipeline X ?", et l'appelle avec le bon paramètre.

L'extensibilité

Vous voulez connecter RAISE à votre système de tickets ? Créez un outil create_ticket. Vous voulez interroger votre Elasticsearch ? Créez un outil search_logs. Vous voulez intégrer un service externe ? Créez un outil passerelle.

Les outils s'ajoutent sans toucher au core de RAISE. Les agents les découvrent automatiquement, apprennent à les utiliser. Le système s'étend naturellement.

Connexion à l'externe

Ces outils peuvent aussi bien être :

• des fonctions locales simples ;
• des passerelles vers des API externes ;
• des connecteurs vers des protocoles standard (MCP - Model Context Protocol).

L'agent ne voit pas la différence. Il appelle un outil, obtient un résultat. La complexité est masquée.

L'agent d'observabilité : le système qui se regarde lui-même

Nous avons parlé de l'auto-observabilité (chaque agent observe son propre raisonnement). Mais il y a un niveau au-dessus : l'observation du système dans son ensemble.

C'est le rôle de l'agent d'observabilité.

Une interface dédiée

Cet agent n'est pas dans le flux conversationnel normal. Il a sa propre interface qui combine deux dimensions :

1) La conversation : vous dialoguez avec l'agent d'observabilité comme avec n'importe quel assistant. Mais ses réponses sont ancrées dans les données réelles du système.

Vous posez des questions :

• "Pourquoi ce thread a mal tourné ?"
• "Quelles améliorations suggères-tu pour le Knowledge Keeper ?"
• "Montre-moi les cas où l'auto-évaluation est inférieure à 5."
• "Compare les performances avant et après le changement de prompt."

Agent d'Observabilité : dialogue intelligent avec visualisations contextuelles (score 2.5/10, analyse comparative, détection de sous-performance)

2) Les visualisations : en parallèle, l'interface affiche des dashboards qui s'actualisent selon le contexte de votre conversation.

Quand vous demandez "analyse ce thread", les graphiques se focalisent sur ce thread : évolution de la confiance, humeur détectée, temps de réponse, outils utilisés. Quand vous demandez "compare les deux versions", les courbes montrent l'avant/après : taux de succès, nombre de clarifications demandées, satisfaction utilisateur.

C'est cette combinaison qui fait la différence. Vous n'êtes pas coincé entre "lire des logs bruts" et "consulter des dashboards génériques". Vous avez une conversation intelligente enrichie de données visuelles pertinentes.

Ce qu'il détecte

Les patterns problématiques :

• "L'agent demande trop souvent des clarifications sur ce type de requête" → Graphique montrant la fréquence sur les 30 derniers jours.
• "La note d'auto-évaluation est systématiquement basse quand l'utilisateur demande X" → Liste des threads concernés.
• "Le Mission Strategist ne trouve pas les informations dans 30% des cas sur ce projet" → Cartographie des zones manquantes.

Diagnostic avancé : performance par agent, erreur Mission Strategist détectée, tendance catégorie sur 30 jours

Les suggestions d'amélioration :

• "Le prompt du Front Agent manque d'orientation sur quand déléguer au Mission Strategist. Ajouter cette clarification devrait réduire les aller-retours de 40% (basé sur l'analyse de 150 threads similaires)."
• "Le Knowledge Keeper Graph manque d'informations sur l'équipe X. Dans 12 threads récents, l'agent a dû demander ces informations à l'utilisateur."

Chaque suggestion est accompagnée de données : combien de threads sont impactés, quelle est l'ampleur du problème, quel serait l'impact estimé d'un changement.

Les anomalies en temps réel : si la qualité décroche soudainement, l'agent d'observabilité vous alerte immédiatement :

• Le moment de la dégradation (timeline annotée).
• Les threads affectés (cliquables pour analyse).
• Les hypothèses de causes (changement de prompt ? nouveau type de requête ?).
• Les métriques d'impact (combien d'utilisateurs touchés, quelle perte de qualité).

Vous ne découvrez pas les problèmes trois semaines après. Vous les voyez en temps réel, avec le contexte pour agir vite.

Alertes en temps réel : dégradation critique détectée avec hypothèses de causes, métriques d'impact et 12 threads affectés identifiés

L'exploration libre

Vous pouvez aussi explorer sans question précise :

• "Montre-moi tous les threads où l'utilisateur semblait frustré."
• "Quels sont les sujets sur lesquels nous avons le plus de mal ?"
• "Analyse l'évolution du système depuis le début du mois."

Quality Monitor - Exploration Libre : analyse de frustrations utilisateurs (+80% vs mois précédent) avec causes identifiées et recommandations

L'agent génère les visualisations pertinentes, commente les tendances, attire votre attention sur les signaux importants.

Évolution du système - Octobre 2025 : qualité moyenne 7.2/10, satisfaction 72%, 428 threads traités avec timeline des alertes détectées

C'est le pilotage intelligent de la qualité dont nous avons parlé dans le deuxième article de notre série implémenté et opérationnel. Pas juste des métriques dans un coin. Une véritable co-analyse entre vous et le système.

Conclusion : les conditions de la fiabilité

Nous avons fait le chemin complet. Du constat des limites de l'agentique actuelle (Partie 1), à la vision de l'agentique adaptative (Partie 2), jusqu'à sa concrétisation dans RAISE (Partie 3).

Ce que nous avons construit, ce ne sont pas des démos qui impressionnent en réunion. Ce sont des fonctionnalités opérationnelles qui tiennent en production :

✅ L'observabilité systématique : chaque agent expose son raisonnement, sa confiance, son plan. On ne navigue plus à l'aveugle.

✅ La base cognitive structurée : les trois piliers (contexte utilisateur, mission, information) incarnés dans des graphes spécialisés qui évoluent avec l'organisation.

✅ L'architecture multi-agents coopérative : des agents qui raisonnent en parallèle, fusionnent leurs apports, dialoguent entre eux. Pas une cascade d'API, mais une vraie collaboration cognitive.

✅ La gouvernance flexible : des stratégies de protection des graphes qui s'adaptent au niveau de maturité. L'humain reste dans la boucle au bon niveau.

✅ L'extensibilité maîtrisée : génération dynamique de sous-agents, boîte à outils évolutive, architecture cohérente. Le système grandit sans s'effondrer sous sa propre complexité.

✅ Le pilotage intelligent de la qualité : un agent d'observabilité qui analyse, suggère, alerte. L'amélioration continue est intégrée dans le système.

Les conditions de la fiabilité ne sont pas un mystère. Elles sont là, implémentées, testées, prêtes à être déployées.

L'agentique qui "marche presque" ne marche pas. Mais l'agentique adaptative, elle, tient en production. Parce que nous lui avons donné les conditions pour grandir.

Et après ?

RAISE n'est pas une fin en soi. C'est une plateforme, un accélérateur, un terrain fertile.

Ce que nous venons de présenter, ce sont les fondations. Les fonctionnalités de base qui permettent de construire des systèmes agentiques fiables.

Mais le vrai jeu commence maintenant : les déclinaisons concrètes.

Nous travaillons actuellement sur des applications sectorielles qui exploitent ces fondations :

AI4Ops : l'agentique adaptative au service des opérations

• Détection proactive d'incidents.
• Analyse de root cause automatisée.
• Recommandations d'optimisation d'infrastructure.
• Génération de runbooks dynamiques.

AI4HR : l'agentique adaptative au service des ressources humaines

• Assistant de recrutement qui comprend la culture et les besoins.
• Analyse de satisfaction et détection de signaux faibles.
• Recommandations de formations personnalisées.
• Facilitation de mobilité interne.

Ces déclinaisons ne sont pas des POC jetables. Ce sont des systèmes opérationnels qui héritent de toute la robustesse de RAISE : architecture hexagonale, “secureGPT” / “enterprise ready”, pas de vendor locking, intégration de modèles de tous les fournisseurs, couplé à toutes ces additions : observabilité, graphes de connaissance, multi-agents, workflows dynamiques adaptatifs, gouvernance, et pilotage de la qualité.

Nous les présenterons prochainement, avec des cas d'usage réels, des métriques de production, des retours d'expérience terrain.

Parce qu'au fond, c'est là que tout se joue : dans la capacité à tenir sur la durée, à s'adapter aux cas imprévus, à grandir avec l'organisation.

L'agentique adaptative n'est pas une promesse. C'est une réalité opérationnelle.

Et elle ne fait que commencer.