Connecter un assistant IA à un système de production supposait jusqu’ici une intégration sur mesure par assistant et par système. Cela a changé, et il vaut mieux comprendre ce changement avant d’entamer la conversation sur la sécurité, parce que l’essentiel de l’inquiétude dans cette conversation porte sur l’architecture plutôt que sur les modèles.
Ce que MCP a changé
Le Model Context Protocol a été publié par Anthropic en novembre 2024 et a depuis été adopté bien au-delà. Il s’attaque à un problème combinatoire : chaque assistant multiplié par chaque système dont il pourrait lire les données est une intégration distincte.
MCP définit une interface commune. Un système expose ses capacités une fois, des ressources lisibles, des outils appelables, des prompts réutilisables, et n’importe quel client parlant le protocole peut s’en servir. Le client est l’assistant ; le serveur se tient du côté du système exposé.
Pour une exploitation qui fait tourner un ERP, la conséquence pratique est banale et considérable : poser une question aux données de production cesse d’exiger qu’un rapport soit construit d’abord. Quelles quantités de cette pièce sont réservées, quels appareils de cet arrivage attendent encore le tri, quel a été le taux de retour sur ce modèle : cela devient des questions plutôt que des tickets.
Les permissions se décident côté serveur, pas dans le prompt
Le point d’architecture le plus important est l’endroit où l’accès est décidé. Ce que l’assistant peut voir et ce qu’il peut modifier sont fixés par le système qui les expose, et non par des consignes données au modèle.
C’est la seule configuration où la réponse à la question de savoir à quoi cette chose peut toucher ne dépend pas du bon comportement du modèle. Une permission exprimée comme une consigne dans un prompt est une demande ; une permission appliquée par le serveur est une frontière. La distinction compte davantage à mesure que les assistants suivent mieux les consignes, et non l’inverse, parce qu’un système dont la sécurité repose sur le respect des consignes n’a pas de plancher.
En pratique, cela veut dire que l’accès est calqué sur les profils que l’ERP a déjà. Un utilisateur qui ne voit pas les prix fournisseurs ne les obtient pas en passant par un assistant, et l’assistant hérite des droits de l’appelant au lieu d’en avoir en propre.
Lire et écrire sont deux décisions distinctes
Lire des données de production et agir dessus sont des risques différents et méritent des réponses différentes. L’essentiel de la valeur arrive avec le seul accès en lecture : des questions auxquelles on répond, des exports produits, des analyses qui exigeaient auparavant que quelqu’un construise un rapport.
L’accès en écriture est l’endroit où une erreur devient un événement d’exploitation et non une mauvaise réponse. Le schéma défendable consiste à faire passer les actions d’écriture par une validation humaine, l’assistant prépare la modification et une personne la confirme, puis à enregistrer l’action dans la piste d’audit comme n’importe quelle autre modification, avec le fait qu’elle vient d’un assistant visible dans l’enregistrement.
Autant le décider délibérément plutôt que d’en hériter. Une intégration en lecture seule par conception est une conversation beaucoup plus courte avec une équipe sécurité qu’une intégration en lecture-écriture entourée de conventions.
L’ancrage, et pourquoi une réponse a besoin de ses sources
Se connecter à un système est une moitié du sujet. L’autre est l’endroit d’où viennent les réponses sur les procédures. La génération augmentée par la recherche répond à une question en retrouvant d’abord les passages pertinents dans vos propres documents, puis en générant à partir de ces passages plutôt que de la mémoire du modèle.
La qualité se joue sur la recherche bien plus que sur le modèle. Si le bon passage n’est pas retrouvé, aucun modèle ne peut produire une réponse correcte à partir de ce qu’on lui a donné. Et si le corpus contient trois versions d’une procédure, le système répondra fidèlement à partir de la mauvaise, ce qui fait de la gestion documentaire une partie du système et non un prérequis dont quelqu’un d’autre s’occupe.
Le test honnête en atelier est de savoir si une réponse porte sa source. Un technicien a besoin de savoir quelle procédure, quelle révision, et si elle s’applique au modèle qu’il a devant lui. Une réponse sans source n’est pas utilisable à un poste, aussi fluide soit-elle.
Quatre questions à trancher avant de connecter quoi que ce soit
Où les données sont-elles traitées, et sous quelles conditions ? Cloud, hébergement chez vous ou exécution locale sont des réponses différentes, et celle qui convient dépend des exigences contractuelles de vos clients plus que de votre préférence. Un donneur d’ordre reste responsable des données personnelles qu’il vous confie et a ses propres engagements à tenir sur leur traitement : en pratique, ce sont souvent ses exigences qui tranchent avant les vôtres.
Vos données servent-elles à entraîner un modèle ? C’est une question contractuelle qui appelle une réponse par oui ou par non, et elle doit être écrite plutôt que déduite.
Que peut modifier l’assistant, et un humain le confirme-t-il ? Si la réponse est qu’il peut tout modifier et que personne ne confirme, l’intégration n’est pas prête, quelles que soient ses performances.
L’activité de l’assistant figure-t-elle dans la piste d’audit ? Une action passée par un assistant reste une action. Si elle n’est pas enregistrée avec la même complétude qu’une action passée par l’interface, la piste a un trou exactement là où des questions finiront par être posées.