Agent IA et données clients : sécuriser le traitement de bout en bout

Un agent qui traite des données clients ne se contente pas de les lire : il les transmet, les reformule, les envoie à des modèles, parfois à des services tiers, et les stocke dans ses traces. Chacune de ces étapes est un point où les données peuvent fuir, être mal utilisées, ou être conservées plus longtemps que nécessaire. Sécuriser un agent, ce n’est pas ajouter un cadenas à la fin, c’est contrôler la donnée à chaque maillon de la chaîne.

La difficulté vient de ce que l’agent lui-même ne comprend pas toujours ce qu’il manipule. Un modèle de langage ne fait pas de différence entre une donnée personnelle et un texte banal, et il peut reproduire une adresse ou un numéro dans une réponse sans que personne ne l’ait prévu. La protection doit donc être structurelle, appliquée en amont, plutôt que confiée au comportement du modèle.

Cet article passe en revue les mesures concrètes pour sécuriser un agent de bout en bout, du moment où la donnée entre jusqu’au moment où elle sort. L’objectif est de vous donner une liste de contrôles à mettre en place avant de confier des données clients à un agent.

Minimiser ce qui entre dans la chaîne

La première mesure, et la plus efficace, est de ne pas faire entrer dans la chaîne ce qui n’a pas besoin d’y être. Si l’agent doit répondre à une question sur une commande, il n’a pas besoin du numéro de carte bancaire, de l’historique complet, ni des coordonnées de tous les contacts. Il a besoin du strict nécessaire pour répondre.

Cette minimisation se fait à la source, au moment où l’on prépare les données envoyées au modèle. On filtre les champs, on ne retient que ce qui est utile à la tâche, et l’on écarte le reste. C’est la mesure la plus simple à mettre en place et celle qui réduit le plus le risque, car une donnée qui n’entre pas ne peut pas fuir.

La difficulté est de définir ce strict nécessaire pour chaque tâche, et de s’y tenir. Cela demande de réfléchir à ce que l’agent fait réellement, et de documenter ce choix. C’est un travail de cadrage qui prend du temps au départ, et qui évite des incidents coûteux ensuite.

L’anonymisation avant l’envoi au modèle

Quand certaines données doivent entrer mais n’ont pas besoin d’être identifiantes, on les anonymise avant l’envoi. Un nom devient un identifiant neutre, une adresse devient un code, un numéro de téléphone devient une référence. Le modèle traite les faits sans jamais voir les identités.

Cette opération, appelée pseudonymisation, se fait par une couche dédiée, avant l’appel au modèle. Elle remplace les données identifiantes par des substituts, et les restaure à la sortie si nécessaire. Le modèle, lui, ne voit que les substituts, ce qui réduit considérablement la surface d’exposition. Pour détecter les noms, e-mails et numéros dans un texte libre, une bibliothèque open source comme Microsoft Presidio fournit une bonne base, à compléter par des règles propres à vos données.

Le point d’attention est la cohérence : les mêmes substituts doivent être utilisés pour les mêmes personnes à travers toute la chaîne, sinon l’agent perd le fil de la conversation. C’est une contrainte technique, mais elle est bien maîtrisée et largement appliquée dans les systèmes sérieux.

Le choix des modèles et de l’hébergement

Le choix de l’endroit où s’exécute le modèle détermine une grande partie du risque. Envoyer les données à une API externe, c’est les confier à un tiers dont il faut vérifier qu’il ne les conserve pas et ne les réutilise pas pour entraîner ses modèles. Faire tourner le modèle sur ses propres serveurs, c’est garder la donnée chez soi, au prix d’une infrastructure plus lourde. Entre les deux, Azure OpenAI ou Amazon Bedrock donnent accès aux grands LLM avec un hébergement en région européenne et un engagement contractuel de non-réutilisation des données.

Pour les données clients sensibles, la question de l’hébergement est centrale. Il faut vérifier le contrat de traitement, s’assurer que les données ne servent pas à l’entraînement, et comprendre où elles transitent géographiquement. Ces points ne sont pas des détails juridiques, ils déterminent le niveau réel de protection.

Le bon réflexe est de séparer les usages : les données peu sensibles peuvent passer par des API si le contrat le permet, les données sensibles doivent rester dans un environnement maîtrisé, idéalement sur vos propres serveurs ou chez un hébergeur qui s’engage contractuellement. Les options concrètes (modèles open source comme Llama ou Mistral, Le Chat en entreprise, hébergement dans l’Union européenne) sont détaillées sur notre page IA souveraine et RGPD.

Le chiffrement et le contrôle d’accès

Deux mesures techniques complètent la chaîne : le chiffrement des données au repos et en transit, et un contrôle d’accès strict sur qui peut consulter quoi. Ces mesures sont classiques, mais elles prennent une importance particulière avec les agents, parce que les traces d’exécution contiennent souvent les données elles-mêmes.

Les traces, indispensables pour comprendre ce que fait un agent quand il échoue, sont aussi un risque : elles conservent les entrées et sorties de chaque étape, donc potentiellement des données clients. Il faut donc chiffrer ces traces, limiter leur durée de conservation, et restreindre qui peut y accéder, pour que l’observabilité ne devienne pas une fuite. Un outil comme Langfuse, qui peut être auto-hébergé, garde ces traces dans votre infrastructure plutôt que chez un éditeur tiers.

Le contrôle d’accès doit suivre le principe du moindre privilège : chaque personne et chaque service n’accède qu’à ce qui lui est nécessaire. C’est une discipline d’exploitation qui se met en place avec les outils habituels, mais qui doit être pensée dès la conception de l’agent, pas ajoutée après coup. Si l’agent accède à votre CRM ou à SharePoint via MCP, chaque serveur MCP n’expose que les outils et les champs utiles à la tâche. Elle va de pair avec la protection contre les injections de prompt, qui sont l’autre grande voie par laquelle un agent peut divulguer ce qu’il ne devrait pas.

Les traces, la conservation et le droit à l’effacement

Un agent qui traite des données clients doit respecter les droits des personnes concernées, en particulier le droit d’accès et le droit à l’effacement. Cela signifie qu’il faut savoir quelles données l’agent a traitées, où elles sont stockées, et pouvoir les supprimer sur demande.

Cette exigence entre en tension avec la conservation des traces dont on parlait. La résolution est une politique de conservation claire : les traces utiles au débogage sont conservées le temps nécessaire puis purgées, et les données personnelles qu’elles contiennent sont soit anonymisées, soit supprimées selon des règles définies.

Mettre en place cette politique demande une réflexion sur le cycle de vie de la donnée : où elle entre, où elle est copiée, combien de temps elle vit, comment elle meurt. C’est un travail de fond, mais il est la condition pour utiliser un agent sur des données clients sans accumuler un passif réglementaire.

Au-delà des données clients, les risques plus larges d’un usage de l’IA en entreprise sont recensés dans l’emploi de l’IA nécessite des précautions.

Par où commencer

Avant de brancher un agent sur vos données clients, dressez la carte de la chaîne : quels champs entrent, où ils sont pseudonymisés, quel modèle les reçoit et où il tourne, ce que les traces conservent et pendant combien de temps. Si l’une de ces questions reste sans réponse claire, c’est là que se trouve votre risque principal, et c’est par là qu’il faut commencer.

C’est ce travail de cartographie qu’on mène en premier quand on construit un agent IA qui touche à des données personnelles : la protection est intégrée à l’architecture dès le cadrage, et vous savez précisément où vont vos données, combien de temps elles y restent et comment elles en sortent.