Enfermer une IA dans une API dédiée avec MCP

Brancher un assistant IA sur le système d'information, c'est la promesse la plus séduisante du moment : un agent qui lit vos commandes, interroge votre CRM, met à jour une fiche produit ou déclenche une action métier, en langage naturel.

C'est aussi la plus dangereuse si on la prend par le mauvais bout. Un modèle génératif est non déterministe : il décide seul quels outils appeler, dans quel ordre, avec quels arguments. Lui donner un accès direct à vos données revient à confier les clés du SI à un exécutant imprévisible, potentiellement manipulable par le texte qu'il lit. La question n'est donc pas « comment connecter l'IA », mais « comment la connecter sans lui ouvrir toutes les portes ».

J'ai expérimenté une réponse à ce problème, avec un pair : construire une API dédiée, taillée sur mesure, qui sert de sas entre l'IA et le SI. Chaque opération autorisée y devient un outil, la documentation OpenAPI sert de mode d'emploi au modèle, et le protocole MCP prend le relais pour la découverte et l'appel des outils. Cet article détaille cette approche — pourquoi elle est solide côté sécurité, comment API Platform la rend naturelle, et ce qu'elle ne règle pas.

Le vrai risque : un exécutant non déterministe branché sur le SI

Avant de parler de la solution, il faut nommer précisément le danger. Deux approches naïves circulent, et toutes deux ouvrent une brèche.

Donner au modèle un accès direct aux données

Laisser le modèle générer du SQL, ou lui exposer un accès en lecture/écriture à la base, est la pire option. Le modèle peut lire ce qu'il ne devrait jamais voir, écrire ce qu'il ne devrait jamais toucher, et une simple injection dans un document qu'il traite peut détourner son comportement. On retombe sur toutes les failles que l'on passe sa vie à éviter dans une application en production, aggravées par le fait que l'appelant, cette fois, improvise.

Exposer toute l'API métier existante

L'option qui paraît raisonnable — « je branche l'IA sur notre API interne, elle est déjà là » — l'est moins qu'elle en a l'air. Une API métier expose des dizaines, parfois des centaines d'opérations, pensées pour des développeurs de confiance, pas pour un agent autonome. On offre alors au modèle une surface immense, on l'expose à des opérations destructrices qui n'avaient aucune raison de lui être accessibles, et on sature son contexte de dizaines d'outils qu'il choisit mal. La surface d'attaque n'est pas réduite : elle est maximale.

Le problème n'est pas de connecter l'IA au SI. C'est de décider, opération par opération, ce qu'elle a le droit de faire — et rien d'autre.

L'idée : une API dédiée comme sas entre l'IA et le SI

Plutôt que d'exposer le SI, on construit une API distincte, dont la seule raison d'être est de servir l'IA. Elle n'expose que les opérations qu'on a explicitement décidé d'autoriser, dans une forme sûre, validée et tracée. L'agent devient un client comme un autre — sans aucune confiance particulière — et ne peut agir qu'à travers ce sas.

Le principe tient en une phrase : l'IA ne parle jamais au SI. Elle parle au sas — l'assistant appelle l'API dédiée, qui seule accède à l'ERP, au CRM ou à la base métier. Et c'est le sas qui décide, à chaque appel, ce qui passe et ce qui est refusé : validation, autorisations, quotas, journalisation.

C'est un motif d'architecture éprouvé sous un nouveau nom : une couche anti-corruption, doublée d'un principe de moindre privilège. L'API dédiée découple l'IA du modèle métier réel — on peut refondre le SI sans toucher au contrat offert à l'agent — et elle réduit la surface à une porte étroite, versionnée et auditée.

Pourquoi API Platform rend ce sas naturel

On peut bâtir cette API dédiée avec n'importe quel framework. Mais API Platform, sur une base PHP/Symfony moderne, aligne exactement les bonnes propriétés pour ce cas d'usage.

• déclaratif — on expose des ressources et des opérations par des attributs. Le périmètre offert à l'IA se lit d'un coup d'œil : ce qui n'est pas déclaré n'existe pas pour elle
• OpenAPI de première classe — la documentation de l'API est générée automatiquement, au format standard, et se pilote finement (descriptions, exemples, schémas, contraintes)
• sécurité intégrée — autorisations par opération, voters, validation des entrées, groupes de sérialisation pour maîtriser les champs renvoyés, limitation de débit : tout est natif
• ouvert sur MCP — les versions récentes savent exposer les opérations comme outils MCP ; à défaut, un pont OpenAPI → MCP fait le travail à partir de cette même documentation

Autrement dit, les garde-fous ne sont pas un ajout : ce sont les mécanismes standard d'une API REST bien conçue, qu'on met simplement au service d'un client d'un genre nouveau.

Chaque opération devient un outil MCP

MCP (Model Context Protocol) est le standard qui permet à un assistant de découvrir des outils et de les appeler. Un outil MCP, c'est un nom, une description en langage naturel et un schéma d'entrée typé. Or c'est précisément ce que décrit une opération OpenAPI. La correspondance est directe.

La correspondance est terme à terme : le nom de l'opération devient le nom de l'outil, sa description devient le texte que le modèle lit pour décider de l'appeler, le schéma de ses paramètres devient le schéma d'entrée typé (JSON Schema), les énumérations en restreignent les valeurs possibles, et les réponses d'erreur documentées apprennent au modèle à gérer les échecs.

Concrètement, sur une ressource API Platform, l'opération et sa description se déclarent en quelques lignes :

#[ApiResource(operations: [
    new GetCollection(
        uriTemplate: '/produits/recherche',
        security: "is_granted('ROLE_AGENT_IA')",       // l'agent est un client authentifié, sans privilège implicite
        openapi: new Operation(
            summary: 'Rechercher un produit du catalogue par mots-clés',
            // cette description est le contexte que le modèle lit pour choisir cet outil
            description: "À n'utiliser que pour un article du catalogue. Jamais pour un contrat ni une facture.",
        ),
    ),
])]
final class ProduitRecherche { /* … */ }

Deux choses se jouent ici. La description n'est pas un commentaire pour développeurs : c'est le texte que le modèle lit pour décider s'il appelle cet outil — d'où l'importance d'y écrire quand l'utiliser et quand s'en abstenir. Et l'attribut security rappelle que l'agent est un client authentifié comme un autre, sans droit implicite sur le reste.

Reste la tuyauterie : comment cette opération devient un outil que l'assistant peut réellement appeler. Deux architectures d'exécution coexistent.

• un serveur MCP autonome placé devant l'API — il lit le document OpenAPI du sas, en génère dynamiquement les outils et les expose à l'assistant sur un transport standard (stdio en local, HTTP pour le distant)
• une exposition MCP portée par l'API elle-même — à côté de son endpoint REST ; l'écosystème autour d'API Platform évolue vite sur ce terrain

Dans les deux cas, la source de vérité est unique : le contrat OpenAPI du sas. C'est lui qu'on soigne, pas un prompt dispersé et fragile.

On n'expose pas toutes les opérations : on en sélectionne un sous-ensemble restreint, pensé pour l'agent. Rechercher un client, lire l'état d'une commande, créer un brouillon de fiche — oui. Supprimer, facturer, modifier en masse — non, ou seulement derrière une validation humaine. Le choix des outils exposés est la politique de sécurité.

De la phrase à l'appel d'outils : trois exemples

L'intérêt se voit mieux sur des demandes réelles. Voici trois requêtes en langage naturel, de la plus anodine à la plus engageante, et ce que le sas en fait techniquement.

« Donne-moi les dernières commandes Magento pas encore validées »

L'assistant n'a besoin que d'un outil de lecture. Il appelle une opération de collection filtrée : les commandes du canal Magento, au statut « à valider », triées par date décroissante et paginées. Rien n'est écrit, et le sas ne renvoie que les champs prévus pour cet outil.

« Exporte les utilisateurs qui ne se sont pas connectés depuis plus de trois semaines »

Le modèle traduit « trois semaines » en une date, appelle l'opération de collection filtrée sur la dernière connexion, parcourt les pages et remet le résultat au format demandé. Toujours de la lecture seule : les groupes de sérialisation garantissent que l'export ne contient aucun champ sensible (mot de passe, jeton…), même si on le lui demandait.

« Corrige tous les produits de la gamme X pour préciser qu'ils sont vendus uniquement dans l'UE »

Là, on écrit — et en masse. C'est précisément le cas où l'on ne lâche pas un agent non déterministe sans filet. Le sas le contraint en plusieurs temps : une lecture pour lister les produits de la gamme, puis, produit par produit, une écriture étroite qui ne touche qu'un seul champ — la description. Chaque écriture est validée, idempotente (une clé d'idempotence absorbe un éventuel retry) et tracée. Et sur une action de cette ampleur, on interpose une prévisualisation : l'agent propose la liste des changements, un humain valide, le sas applique.

« les dernières commandes Magento pas encore validées »   → lecture seule
GET   /commandes?canal=magento&statut=a_valider&tri=-date

« les utilisateurs inactifs depuis plus de 3 semaines »    → lecture seule
GET   /utilisateurs?derniere_connexion_avant=2026-06-18

« préciser “UE uniquement” sur toute la gamme X »          → écriture en masse, sous garde-fous
GET   /produits?gamme=X
PATCH /produits/{id}   {"description": "… Commercialisé uniquement dans l'Union européenne."}
      chaque PATCH : validé · idempotent · tracé · après prévisualisation + validation humaine

Les mêmes trois phrases, lâchées sur une base de données ou sur l'API métier complète, seraient au mieux imprévisibles, au pire destructrices. À travers le sas, elles deviennent une poignée d'appels bornés, validés et tracés — et la seule qui écrit passe par une validation humaine. C'est toute la différence entre « donner l'accès à l'IA » et « lui donner des outils ».

La documentation OpenAPI est le contexte du modèle

Voici le point le plus contre-intuitif, et le plus important. La qualité avec laquelle l'IA utilise vos outils ne dépend pas d'un prompt magique : elle dépend de la qualité de votre documentation OpenAPI. C'est elle qu'on donne au modèle comme contexte. Une description soignée, c'est du prompt engineering qui ne dit pas son nom.

Un modèle choisit le bon outil et remplit correctement ses arguments quand chaque opération porte une description sans ambiguïté, des exemples représentatifs, des énumérations pour les valeurs possibles et des schémas d'erreur explicites. À l'inverse, une API techniquement correcte mais peu documentée produit un agent qui hésite, se trompe d'outil ou invente des paramètres.

La documentation n'est plus un livrable annexe pour les développeurs. C'est l'interface même par laquelle le modèle comprend ce qu'il a le droit de faire.

C'est une bonne nouvelle d'ingénierie : l'effort se porte là où il est vérifiable et durable — dans un contrat d'API versionné et testable —, pas dans un prompt fragile qu'on ajuste à l'aveugle.

Ce que le sas apporte, concrètement

Ramener l'accès de l'IA à une API dédiée transforme un risque diffus en surface maîtrisée. C'est aussi là qu'on arrête ce que le modèle n'aurait jamais dû envoyer — payloads malformés, valeurs hors bornes, appels trop lourds — avant qu'ils n'atteignent le SI. Chacun de ces mécanismes est standard ; leur cumul est ce qui « enferme » l'IA sans la brider.

• moindre privilège — l'IA ne peut appeler que les opérations explicitement exposées ; le reste n'existe pas pour elle
• surface réduite — une porte étroite, versionnée et auditée, au lieu de l'ensemble du SI
• validation à la frontière — schéma d'entrée strict : chaque payload est validé, typé et borné en taille avant que le SI ne soit touché ; les groupes de sérialisation limitent les champs renvoyés
• authentification et quotas — l'agent s'authentifie, chaque appel est soumis à une limitation de débit et à des quotas
• journalisation complète — chaque action de l'IA est tracée et rejouable, indispensable pour l'audit et la conformité
• découplage du SI — couche anti-corruption : on refond le SI derrière sans changer le contrat vu par l'agent

Ce que cette approche ne règle pas

Le sas contient le risque, il ne le supprime pas. Le présenter comme une garantie absolue serait sur-promettre — ce n'est pas ma façon de travailler. Trois limites doivent rester en tête.

• l'injection de prompt subsiste — un document malveillant peut toujours tenter de détourner l'agent. Mais justement, le sas circonscrit les dégâts : l'IA détournée ne peut exécuter que les actions exposées par le sas — validées et tracées. La frontière limite le rayon d'explosion
• l'IA peut mésuser d'une opération permise — si on expose une suppression, elle peut la déclencher au mauvais moment. D'où le principe : concevoir des opérations sûres par construction, privilégier la lecture et les écritures étroites, idempotentes et réversibles, garder l'humain dans la boucle sur les actions sensibles
• le modèle reste non déterministe — on ne contrôle ni la séquence de ses appels, ni ses reprises : en cas de doute ou de délai dépassé, un agent relance volontiers la même action. Les écritures du sas doivent donc être idempotentes — typiquement via une clé d'idempotence (un UUID rattaché à l'action voulue) qui fait qu'un second appel identique ne crée pas de doublon métier, mais renvoie le résultat du premier

Cette exigence de fiabilisation — garde-fous, validation humaine, traçabilité — n'est pas un détail : c'est un poste de coût à part entière, comme je le détaille dans combien coûte réellement une fonctionnalité IA.

Quand cette approche est pertinente

Bâtir une API dédiée est un investissement d'ingénierie ; il ne se justifie pas pour un simple assistant conversationnel sans accès aux données. Il devient rationnel dès que l'agent doit toucher au réel : lire des données métier sensibles, déclencher des actions, s'intégrer au SI.

C'est exactement le terrain où se rejoignent deux savoir-faire : la connexion au système d'information existant et l'exigence de sécurité héritée d'environnements réglementés. Dans les contextes santé, secteur public ou données sensibles, le sas n'est pas une élégance d'architecte : c'est la condition pour qu'un projet IA soit déployable sans exposer l'entreprise.

Conclusion

Connecter une IA à son système d'information est puissant et risqué. Le risque ne vient pas de l'IA en elle-même, mais du fait qu'on lui donne trop souvent un accès trop large à un SI qui n'a jamais été pensé pour un client non déterministe et manipulable.

Une API dédiée, construite avec API Platform et exposée en MCP, renverse le rapport de force : l'IA n'obtient plus les clés du SI, mais l'usage d'un sas étroit, validé, authentifié et tracé. Chaque opération autorisée devient un outil ; la documentation OpenAPI, soignée, devient le contexte qui guide le modèle. On ne bride pas l'IA — on l'enferme dans un périmètre sûr, ce qui est précisément la condition pour la laisser agir.