Sécurité des systèmes agentiques : ce qu'il faut exiger d'un éditeur

Ce qui change quand un système agit dans vos outils

Avec un logiciel classique, la question de sécurité tient en une phrase : qui peut voir quoi. Les données entrent, elles sont stockées, elles sont consultées. Le risque se raisonne en confidentialité et en disponibilité.

Un système agentique déplace la question. Il lit vos données, mais il agit aussi : il crée une fiche dans le CRM, envoie un message, met à jour un champ, dépose un document. La question devient donc qui peut faire quoi, et sous quel contrôle. Une action mal déclenchée ne se corrige pas en révoquant un droit de lecture — elle a déjà eu un effet, parfois visible par un tiers. C'est pourquoi les exigences qui suivent portent autant sur le périmètre des actions et leur traçabilité que sur l'hébergement des données.

Où vivent les données

Demandez la juridiction d'hébergement, pas seulement le nom du fournisseur cloud. Un même fournisseur opère des régions dans plusieurs pays, et la région retenue détermine le droit applicable aux données qui s'y trouvent. Demandez ensuite la liste des sous-traitants qui traitent effectivement ces données : hébergeur, fournisseurs de modèles, outils d'observabilité, prestataires de support. Cette liste doit être écrite, datée, et l'éditeur doit s'engager à vous prévenir avant d'y ajouter un acteur.

Deux points méritent une réponse précise : la localisation de l'hébergement principal et celle des sauvegardes, qui ne sont pas toujours dans la même région ; et l'existence d'un accord de sous-traitance en bonne et due forme, couvrant les obligations habituelles de sécurité, de notification d'incident et d'assistance en cas de demande d'une personne concernée. Une réponse approximative en avant-vente annonce une réponse approximative le jour d'un incident.

Le cloisonnement entre clients

Une entreprise ne doit jamais pouvoir atteindre les données d'une autre, ni par erreur ni par une requête bien formulée. La question à poser n'est pas « les données sont-elles cloisonnées » — la réponse sera toujours oui — mais comment l'isolation est obtenue et comment elle est testée.

• Le cloisonnement est-il logique, dans une base partagée avec un identifiant de client, ou physique, avec des ressources dédiées par client ? Les deux sont défendables ; ils n'ont pas le même coût ni le même profil de risque.
• Comment ce cloisonnement s'applique-t-il aux secrets de connexion, aux journaux, aux sauvegardes et aux index de recherche — c'est-à-dire aux endroits où les fuites entre clients se produisent en pratique.
• Comment est-il vérifié : tests automatisés à chaque déploiement, revue de code sur les accès aux données, test d'intrusion par un tiers ? Demandez la date du dernier test et la nature des conclusions.

Le périmètre des accès

Le principe du moindre privilège est simple : le système ne demande que les autorisations dont il a besoin pour faire ce que vous lui avez demandé, et vous devez pouvoir les lire en clair, outil par outil. Exigez un tableau des connexions avec, pour chacune, les autorisations demandées, l'usage qui les justifie, et la distinction entre lecture et écriture.

Un accès total à une messagerie professionnelle ou à un espace de fichiers d'équipe mérite une discussion avant d'être accordé : il porte bien au-delà du cas d'usage, et il devient difficile de démontrer après coup ce qui a été lu. Quand la plateforme connectée propose une granularité plus fine — une boîte dédiée, un dossier précis, un périmètre en lecture seule, un compte de service aux droits restreints — c'est cette option qu'il faut demander. Vérifiez enfin comment se révoque un accès et ce que devient le travail en cours quand il l'est.

La journalisation des actions

Toute action exécutée par le système dans un de vos outils doit être reconstituable après coup, sans avoir à solliciter le support de l'éditeur. Une trace exploitable répond à quatre questions :

1. Quoi : la nature de l'action et l'objet concerné, identifié précisément.
2. Quand : un horodatage fiable, avec le fuseau.
3. Déclenchée par quoi : le signal, la règle ou la demande à l'origine de l'action.
4. Validée par qui : l'identité de la personne ayant approuvé, quand une supervision humaine était requise.

Demandez la durée de conservation de ces journaux, la possibilité de les exporter, et le délai dans lequel l'éditeur s'engage à vous notifier un incident de sécurité. Sur le rôle de la validation dans la chaîne d'exécution, voir notre guide sur la validation humaine dans un système agentique.

L'entraînement des modèles

Exigez un engagement écrit indiquant que vos données ne servent pas à entraîner des modèles, ni chez l'éditeur, ni chez les fournisseurs de modèles qu'il appelle. Ces deux niveaux sont distincts et doivent être couverts séparément : un éditeur peut n'entraîner aucun modèle lui-même tout en transmettant vos contenus à un fournisseur tiers dont le contrat autorise cet usage.

Demandez donc la liste des modèles tiers appelés, le nom de leur fournisseur, la région où s'exécutent les appels et la durée de rétention côté fournisseur. Un même fournisseur propose souvent plusieurs régimes selon l'offre souscrite ; ce qui vous intéresse est celui qui s'applique au contrat de l'éditeur. Un changement de fournisseur de modèles doit faire l'objet d'une information préalable.

La réversibilité et la fin de contrat

La sortie se négocie à l'entrée. Trois points doivent figurer noir sur blanc :

• La récupération : quelles données vous sont restituées, dans quel format exploitable, par quel moyen, et si cette restitution est facturée.
• La suppression : ce qui est supprimé, y compris dans les sauvegardes et chez les sous-traitants, et sous quelle forme l'éditeur atteste de cette suppression.
• Les délais : sous combien de jours après la fin du contrat l'export est disponible, et sous combien de jours la suppression est effective. Un délai résiduel sur les sauvegardes est normal ; il doit être annoncé, pas découvert.

Lire les certifications correctement

C'est le point sur lequel les acheteurs se font le plus souvent avoir, sans mauvaise foi de part et d'autre. Une certification affichée par un éditeur de logiciel porte presque toujours sur l'infrastructure d'hébergement qu'il utilise, et non sur l'éditeur lui-même. Les deux formulations ne disent pas la même chose :

Un éditeur honnête sur ce point le formule spontanément et vous dit ce qui est audité et ce qui ne l'est pas encore. Un fournisseur qui entretient la confusion mérite une question de plus — non parce que l'absence de certification propre serait rédhibitoire pour une jeune société, mais parce que la manière dont il en parle vous renseigne sur la façon dont il répondra le jour d'un incident.

La check-list à faire figurer par écrit

Ces neuf points se demandent dans un questionnaire de sécurité et se reprennent dans le contrat ou son annexe technique. Un fournisseur sérieux répond aux neuf sans négociation.

1. La juridiction d'hébergement des données de production et des sauvegardes.
2. La liste datée des sous-traitants, avec engagement d'information préalable en cas d'ajout.
3. La description du mécanisme de cloisonnement entre clients et la manière dont il est testé.
4. Le tableau des autorisations demandées sur chaque outil connecté, avec la justification de chacune.
5. La procédure de révocation d'un accès et son effet sur le travail en cours.
6. Le contenu, la durée de conservation et le mode d'export des journaux d'actions.
7. L'engagement de non-entraînement, couvrant l'éditeur et les fournisseurs de modèles tiers.
8. Le format, le délai et le coût de restitution des données en fin de contrat.
9. Le délai de suppression, sauvegardes comprises, et la forme de l'attestation fournie.

Questions fréquentes

Quelles questions de sécurité poser avant de connecter un système agentique à nos outils ?

Six questions couvrent l'essentiel : où sont hébergées les données et qui sont les sous-traitants, comment les données d'un client sont isolées de celles des autres, quelles autorisations exactes le système demande sur chaque outil connecté, quelle trace il conserve de chaque action exécutée, si les données servent à entraîner des modèles, et comment on récupère puis supprime tout en fin de contrat. Les réponses doivent figurer dans le contrat ou dans une annexe technique, pas dans un échange commercial.

Un éditeur peut-il être certifié SOC 2 ou ISO 27001 ?

Une entreprise peut l'être, mais dans le cas des logiciels agentiques la certification affichée porte le plus souvent sur l'infrastructure d'hébergement, pas sur l'éditeur lui-même. La formulation honnête est donc « infrastructure certifiée SOC 2 Type II » ou « hébergement certifié ISO 27001 ». Si un fournisseur écrit simplement « certifié », demandez-lui le rapport ou le certificat, avec le nom de l'entité auditée et la date. Un refus, ou une réponse évasive, est en soi une information.

Faut-il donner à un système agentique un accès complet à la messagerie de l'équipe ?

Non, et une demande d'accès total à une boîte mail ou à un espace de fichiers mérite d'être discutée avant d'être accordée. Le principe à appliquer est celui du moindre privilège : le système ne demande que les autorisations nécessaires à ce qu'il doit faire, et vous devez pouvoir les lire en clair, outil par outil. Quand la plateforme connectée propose des accès restreints — une boîte dédiée, un dossier, un périmètre en lecture seule — c'est cette option qu'il faut exiger.

Comment vérifier que les données ne servent pas à entraîner des modèles ?

Par un engagement écrit, contractuel, portant à la fois sur l'éditeur et sur les modèles tiers qu'il appelle. Demandez la liste de ces fournisseurs, leur localisation, et la configuration retenue chez chacun, car un même fournisseur propose souvent plusieurs régimes selon le contrat souscrit. Une déclaration sur une page marketing n'a pas la même valeur qu'une clause.

Qu'est-ce que la journalisation doit permettre de reconstituer ?

Pour chaque action exécutée dans un outil métier : ce qui a été fait, à quel moment, sur quel objet, ce qui l'a déclenchée, et qui l'a validée quand une supervision humaine était requise. Cette trace doit être consultable par vos équipes sans passer par le support de l'éditeur, exportable, et conservée pendant une durée annoncée. Sans elle, aucune analyse d'incident n'est possible.

Pour aller plus loin

Le pendant opérationnel de ce guide est la question de la supervision humaine : quelles actions un système peut exécuter seul, lesquelles doivent être soumises, et comment cette frontière se paramètre. Elle est traitée dans le guide sur la validation humaine. Nos propres réponses à la check-list ci-dessus sont détaillées sur la page sécurité.