Rendre un logiciel métier « agent-ready » : ce qu'un jeu vidéo nous apprend sur la souveraineté IA

Le marché qu'on propose aujourd'hui aux entreprises

Quand une organisation veut ajouter de l'IA à son ERP, son CRM ou son outil métier, la proposition est presque toujours la même : embarquer un modèle dans le produit, faire remonter les données vers ce modèle, et s'engager sur ce choix pour plusieurs années.

Trois renoncements en une seule décision. La souveraineté d'abord — les données quittent l'organisation. La liberté ensuite — le modèle est imposé, et il sera probablement dépassé dans dix-huit mois. La réversibilité enfin — l'intégration repose sur un connecteur propriétaire, donc en sortir coûte cher.

Pour une entreprise privée, c'est un compromis discutable. Pour une collectivité, un établissement de santé ou une administration, c'est souvent rédhibitoire.

Il existe une autre façon de poser le problème.

Un terrain d'essai inattendu : un jeu de stratégie

Joan, un développeur de notre équipe, développe en side-project un jeu de stratégie multijoueur. Il y a intégré un game director piloté par une IA.

Le concept n'est pas neuf. En 2008, Valve introduisait dans Left 4 Dead un AI Director : un système qui observe l'état des joueurs et module en temps réel le rythme, la difficulté et l'apparition des menaces. Le jeu ne suit pas un script figé ; il s'adapte.

La nouveauté ici tient à l'interface. Le directeur de partie se pilote en langage naturel. Le joueur peut lui parler, négocier, lui demander de le ménager — et l'IA arbitre.

Amusant, mais anecdotique. L'intérêt réel est dans l'étape suivante.

De l'IA embarquée à l'IA branchée

L'objectif du projet n'est pas de fournir une IA aux joueurs. C'est de permettre à chaque joueur de brancher la sienne : son propre agent, avec le modèle de son choix, hébergé où il veut — y compris sur sa machine.

Le jeu ne devient pas intelligent. Il devient opérable par une intelligence. N'importe laquelle.

Techniquement, cela repose sur le Model Context Protocol, un standard ouvert qui permet à un système d'exposer ses capacités de façon interopérable :

• ses données deviennent des resources, accessibles en lecture ;
• ses actions deviennent des tools, que l'agent peut déclencher.

Tout agent conforme au protocole peut alors opérer le système, sans intégration sur mesure et sans connecteur propriétaire.

Prototyper dans le cloud, livrer en local

La feuille de route du projet illustre un chemin que nous recommandons régulièrement à nos clients, et qu'il est utile d'avoir parcouru soi-même.

Étape 1 — valider vite. Le premier prototype s'appuie sur une API cloud. C'est le moyen le plus rapide de vérifier qu'une boucle fonctionne, sans monter d'infrastructure.

Étape 2 — rapatrier. Une fois la mécanique validée, le modèle est ramené en local : Ollama pour exécuter des modèles ouverts, OpenWebUI pour l'orchestration auto-hébergée. Le comportement du système ne change pas ; sa dépendance externe disparaît.

Étape 3 — ouvrir. Le système expose ses capacités via MCP. Chaque utilisateur y branche son agent.

Prototyper dehors, livrer dedans. Sur un jeu, cette démarche ne fait courir aucun risque : aucune donnée client n'est en jeu. C'est précisément ce qui en fait un bon terrain d'apprentissage.

Ce que ça change pour un ERP ou un CRM

Le jeu n'est qu'un prétexte. L'architecture, elle, se transpose directement.

Exposez les capacités d'un ERP via MCP — ses données en resources, ses opérations métier en tools — et la relation s'inverse :

Les données ne sortent pas. L'agent du client interroge le système depuis l'environnement du client. Rien n'est transféré vers un fournisseur tiers.

Le modèle devient remplaçable. Changer de LLM ne demande plus de retoucher l'application. L'interface reste stable, l'agent derrière peut évoluer.

Le lock-in disparaît. L'intégration repose sur un protocole ouvert, pas sur un connecteur maison. Le client peut partir — et c'est justement ce qui le convainc de rester.

La conformité devient structurelle. Parce que la donnée ne change jamais de main, l'architecture s'aligne naturellement avec les exigences du RGPD et avec la logique du référentiel SecNumCloud porté par l'ANSSI, sans réécriture applicative.

Le protocole ne fait pas l'architecture

Il serait tentant de croire qu'il suffit d'ajouter une couche MCP pour rendre un logiciel « agent-ready ». C'est faux, et c'est là que se situe le vrai travail.

Exposer un système à des agents impose des décisions que personne ne prend à votre place : quelles données rendre lisibles, quelles actions un agent a le droit de déclencher, quelles opérations exigent une validation humaine, où placer les garde-fous et les limites de débit.

Un tool mal borné sur un CRM, c'est un agent qui envoie une campagne à toute la base. Un accès en écriture trop large sur un ERP, c'est une écriture comptable déclenchée sans contrôle. Le protocole fournit la prise ; l'architecture décide de ce qu'on y branche, et de ce qu'on refuse d'y brancher.

C'est un travail de conception, pas d'intégration. Il suppose de comprendre le métier avant de comprendre le protocole.