Sécurité, données clients et RGPD

Un agent est un programme qui détient vos clés, lit vos données clients et peut agir dans vos outils. Traitez-le comme une nouvelle recrue qui aurait accès à la production dès le premier jour : il reçoit le strict nécessaire, il ne voit jamais un secret en clair, et tout ce qui ne peut pas être annulé attend un humain. L’essentiel du travail de sécurité, c’est de la plomberie ennuyeuse faite une fois. Le reste tient en une courte liste d’actions dont vous décidez, par écrit, que l’agent ne les prendra jamais seul.

Rien de ce qui suit n’est un conseil juridique. Je décris comment je m’organise et ce que je vérifie ; c’est votre conseil qui décide de ce que votre entreprise a le droit de faire de ses données.

Gardez les secrets hors du contexte de l’agent

Un secret collé dans un prompt finit dans un historique de conversation, peut-être dans la rétention d’un fournisseur, et parfois dans un fichier que l’agent réécrit sur le disque. Ma règle : le modèle ne lit jamais une clé. Il appelle un outil, et c’est l’outil qui lit la clé dans l’environnement.

Où vont les secrets	Où ils ne vont jamais
Variables d’environnement ou gestionnaire de secrets lu par l’outil	Le fichier d’instructions ou un prompt
Un fichier .env listé dans .gitignore	Les fichiers de configuration d’exemple versionnés
Des clés restreintes, une par agent ou par routine	Une clé admin partagée réutilisée partout

Les clés restreintes paient le jour où quelque chose déraille : vous révoquez une clé et un seul agent s’arrête, au lieu de tout couper.

Ce qui m’a convaincu n’est pas une fuite. Pendant un temps, toute l’organisation d’agents qui fait tourner le marketing de Derrick (que j’ai cofondé) existait en un seul exemplaire, sur un seul ordinateur portable. Depuis novembre 2026, elle vit dans un dépôt privé, données clients exclues, avec un contrôle qui bloque le push si un secret apparaît. Une version minimale, sous forme de hook Git pre-push :

#!/bin/sh
# .git/hooks/pre-push : refuse le push si un fichier suivi semble contenir un secret
PATTERN='(sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----)'
if git grep -nIE "$PATTERN" -- . ':!*.lock'; then
  echo "Possible secret found. Push blocked."
  exit 1
fi

Un scanner de secrets dédié reconnaît bien plus de motifs. L’intérêt est ailleurs : le contrôle tourne à chaque fois, sans que personne ait à y penser.

N’envoyez au modèle que les données dont la tâche a besoin

La plupart des tâches d’un agent n’ont besoin d’aucune donnée personnelle, et celles qui en ont besoin en utilisent rarement la totalité. Avant qu’un agent lise un export CSV, un dump de CRM ou un log, un script en produit un condensé : les colonnes utiles à la tâche, agrégées quand c’est possible, avec e-mails, numéros de téléphone et jetons remplacés. L’agent travaille sur le condensé. Il consomme moins de contexte, et un modèle ne peut pas répéter ce qu’il n’a jamais vu.

import re

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
PHONE = re.compile(r"\+?\d[\d .-]{7,}\d")

def redact(text: str) -> str:
    text = EMAIL.sub("[email]", text)
    return PHONE.sub("[phone]", text)

Le masquage par expressions régulières n’attrape que l’évident : les noms et les notes libres passent au travers. Le meilleur réglage se fait donc en amont, en choisissant les colonnes qui sortent de la base. Ce que l’agent doit lire et où vit chaque fait sont traités dans le chapitre sur la mémoire et le contexte.

Quand des données personnelles doivent atteindre le modèle, comme en prospection, vérifiez trois points avec votre fournisseur et votre conseil : si les entrées servent à l’entraînement, combien de temps elles sont conservées, et où elles sont traitées. Ces réponses ont leur place dans votre registre des traitements, à côté de la base légale sur laquelle vous vous appuyez.

Donnez à chaque outil la plus petite permission qui suffit

Un agent peut faire tout ce que ses outils lui permettent. Le modèle de permissions vit donc dans les outils, pas dans le prompt. « Ne supprime rien » dans un fichier d’instructions est un souhait ; un outil sans point de suppression est une garantie. J’écris la politique de chaque agent dans un fichier qu’un relecteur peut lire :

agent: outbound_assistant
tools:
  crm:
    allow: [search_contacts, read_contact, create_note]
    deny: [delete_contact, merge_contacts, update_owner]
  sending_tool:
    allow: [read_campaigns, read_audience, add_lead_draft]
    deny: [launch_campaign, send_message]
  files:
    allow_read: [data/digests/]
    allow_write: [out/]
human_approval_required:
  - any action on more than 50 records
  - anything that sends, publishes, deletes or spends money

Si vous construisez votre propre connecteur, c’est là que la conception compte le plus : exposez des outils étroits avec des arguments explicites plutôt qu’un point d’entrée générique « exécuter une requête ». Construire son propre serveur MCP détaille comment dessiner ces outils.

Traitez tout ce que l’agent lit de l’extérieur comme une donnée, jamais comme une instruction. Une page web, un e-mail entrant ou une note CRM peuvent contenir un texte écrit pour piloter un modèle. La parade est structurelle : l’étape qui lit du contenu non fiable n’a aucun outil d’écriture, et sa sortie est un champ structuré que l’étape suivante valide.

Les actions qu’un agent ne prend jamais seul

Voici ma liste. Elle est courte exprès, pour être réellement appliquée.

Action	Pourquoi elle attend un humain	Ce que fait l’agent à la place
Envoyer un message à un prospect ou un client	Votre nom, la réputation de votre domaine, votre exposition juridique	Il rédige, un humain envoie
Publier un contenu	Un fait faux reste indexé et cité	Il ouvre un brouillon ou une pull request
Supprimer ou écraser des enregistrements	Souvent irréversible	Il liste ce qu’il changerait
Dépenser de l’argent ou des crédits au-delà d’un plafond	Une boucle qui s’emballe démarre vite	Il s’arrête et donne l’estimation
Modifier des permissions, des clés ou des intégrations	Cela élargit ce que tous les autres agents peuvent faire	Il rédige la demande

Les routines planifiées suivent la même règle : une routine propose, elle ne publie ni n’envoie sans exception écrite pour cette routine. L’un des vrais contrôles de notre flux de prospection est là : avant de pousser des leads vers l’outil d’envoi, l’agent vérifie qu’il n’écrase pas un lead déjà présent dans une campagne active. Faire tourner l’agent seul montre comment les routines vérifient leurs outils avant de démarrer.

RGPD et AI Act : les questions à poser pour chaque agent

Les agents ne changent pas les règles sur les données personnelles. Ils permettent d’en traiter davantage, plus vite, ce qui fait mordre les règles existantes plus tôt. Les questions que je pose pour chaque agent qui touche des données personnelles :

Question	Où se trouve la réponse
Quelles données personnelles l’agent lit, et pourquoi chaque champ lui est nécessaire	La spécification et le fichier de politique de l’agent
Quelle base légale couvre ce traitement	Votre registre des traitements, validé par votre conseil
Quels fournisseurs reçoivent les données, à quelles conditions	Les accords de sous-traitance
Comment une personne peut s’opposer ou demander l’effacement, et comment l’agent le respecte	Une liste d’opposition que l’agent lit avant chaque passage
Combien de temps les sorties sont conservées	Une règle de conservation sur le dossier ou la table de sortie

En France, les ressources de la CNIL sur l’IA et sa page sur la prospection commerciale par courrier électronique sont les points de départ ; la page de la Commission européenne sur la protection des données couvre le RGPD lui-même. L’Union a aussi un règlement sur l’IA dont les obligations dépendent de l’usage et du niveau de risque ; la page de la Commission sur l’AI Act en présente le cadre. Je ne suis pas qualifié pour vous dire où se situe votre usage, et votre agent non plus. Si votre TAM est concerné, la logique d’opposition et de fraîcheur de maintenir le TAM à jour s’applique telle quelle.

Une revue d’une page avant le premier passage

Avant qu’un agent touche des données réelles, je remplis ce tableau et je le garde à côté du fichier d’instructions.

Contrôle	Validé quand
Secrets	Aucune clé dans les prompts ni dans le dépôt ; push bloqué sur un motif de secret
Clés	Une clé restreinte par agent ; vous savez comment la révoquer
Données en entrée	Liste des champs lus par l’agent, chacun justifié
Masquage	Les condensés retirent coordonnées et jetons avant que le modèle les voie
Outils	Listes d’autorisation et d’interdiction écrites ; aucun point d’écriture générique
Contenu non fiable	Les étapes qui le lisent n’ont aucun outil d’écriture
Validations humaines	Le tableau des actions ci-dessus, seuils chiffrés compris
Journal	Chaque passage enregistre ce qu’il a lu, ce qu’il a modifié et qui a validé
Juridique	Votre conseil a vu la liste des données et des fournisseurs

Votre prochaine étape : prenez l’agent que vous construisez, écrivez son fichier de politique avec ses listes d’autorisation et d’interdiction, et retirez-lui une permission dont il dispose aujourd’hui sans en avoir strictement besoin.