L’autonomie croissante des agents IA transforme un sujet technique en question de gouvernance. Lorsqu’un système agit sur des données, du code ou des applications métier, l’entreprise doit savoir qui autorise l’action, qui la surveille et qui répond de ses conséquences.
L’incident de sécurité devient un sujet de responsabilité
Aux États-Unis, une ONG a engagé une action contre OpenAI à la suite du piratage de la plateforme Hugging Face. Cette procédure porte devant la justice la responsabilité associée aux incidents de sécurité impliquant des agents IA. Elle ouvre un débat sur le partage des obligations entre les concepteurs de modèles, les fournisseurs de services, les intégrateurs et les entreprises utilisatrices, sans constituer à ce stade une décision établissant une faute.
Pour une PME, l’enjeu ne se limite donc plus à la qualité des réponses produites. Il concerne toute la chaîne d’exécution. L’éditeur fournit une technologie, un intégrateur la relie au système d’information et l’entreprise décide des données et fonctions auxquelles l’agent peut accéder. Une gouvernance imprécise à l’un de ces niveaux peut affecter les opérations, la confidentialité des informations et la relation client.
Cette distinction devient essentielle dans les équipes commerciales. Un assistant qui prépare la synthèse d’un rendez-vous n’a pas le même pouvoir qu’un agent autorisé à modifier une opportunité, envoyer une proposition ou consulter des documents contractuels. Le premier aide à décider. Le second agit dans les outils de l’entreprise et peut déclencher des conséquences difficiles à annuler.
La responsabilité opérationnelle commence donc par une question simple : que l’agent peut-il réellement faire ? Le nom du modèle ou les performances présentées lors d’une démonstration ne répondent pas à cette question. Il faut examiner ses connexions, ses permissions, les données consultées et les étapes pouvant être exécutées sans validation humaine.
Le contrat fournisseur ne suffit pas à protéger la PME
Les engagements de l’éditeur restent importants, mais ils ne remplacent pas les contrôles internes. Les conditions d’utilisation, les garanties de sécurité, le recours à des sous-traitants, la localisation des données et les modalités de signalement d’un incident doivent être rapprochés des usages autorisés dans l’entreprise.
Le cadre présenté par la CNIL sur l’intelligence artificielle invite notamment les organisations à définir leurs finalités, à maîtriser les données personnelles traitées et à clarifier les responsabilités. Le cadre réglementaire européen de l’intelligence artificielle conduit également les entreprises à qualifier leurs usages et leur rôle dans la chaîne de valeur. La conformité commence ainsi par un inventaire concret des systèmes employés, et non par une clause générale ajoutée à un contrat.
Dans un CRM, le principe du moindre privilège offre une base utile. Un agent chargé de résumer des échanges n’a pas besoin de supprimer des contacts. Un outil de préparation commerciale n’a pas à exporter toute la base clients. Un assistant de support ne doit pas pouvoir modifier seul les conditions accordées à un compte. Chaque permission supplémentaire élargit la portée d’une erreur, d’une instruction malveillante ou d’un détournement de compte.
La traçabilité compte tout autant. L’entreprise doit pouvoir retrouver la demande reçue par l’agent, les données consultées, l’action exécutée et l’identité de la personne ayant validé l’opération lorsque cette validation est requise. Sans ces éléments, l’analyse d’un incident devient plus lente et le partage des responsabilités plus difficile.
Tester les actions plutôt que la démonstration
Une démonstration réussie ne valide pas un agent en situation réelle. Le test opérationnel doit couvrir les permissions accordées, les actions interdites, les données sensibles, la résistance aux instructions détournées et la procédure de reprise. Cette logique rejoint notre analyse du vrai test opérationnel de Gemini Argon pour les PME : la valeur métier se mesure dans un environnement contrôlé, avec des critères d’acceptation définis avant la mise en production.
Le même principe s’applique au développement logiciel et à la cybersécurité. Un agent capable de lire un dépôt, de proposer une correction ou d’exécuter une commande demande un cloisonnement plus strict qu’un outil de génération isolé. Notre article consacré à Gemini, au code et à la cybersécurité en PME détaille cette différence. L’accès minimal, la validation humaine et la journalisation limitent l’impact d’une action erronée ou détournée.
L’affaire américaine rappelle finalement qu’un agent IA doit être traité comme un composant technique disposant de pouvoirs définis, et non comme une simple interface de conversation. Cette approche aide aussi à prioriser les projets : une assistance sans accès sensible ne réclame pas les mêmes contrôles qu’un système autorisé à engager l’entreprise auprès d’un client.
L’action interne à mener consiste à réunir direction, métiers, informatique et protection des données pour recenser les agents déjà utilisés, leurs accès et leurs responsables. Pour chaque usage, l’entreprise peut ensuite formaliser les actions autorisées, les validations humaines obligatoires, les traces à conserver et la procédure de suspension en cas d’incident.
