Scénario illustratif. L’équipe qui construit ton agent de support client demande, très logiquement, « un échantillon de tickets réels pour l’affiner ». Ils exportent deux mille conversations du CRM, les posent dans un dossier partagé, et l’agent progresse. Personne n’a rien décidé : c’est arrivé. Et ce dossier contient désormais des noms, des adresses et des incidents de gens qui ne se doutaient pas que leurs messages serviraient à tester un logiciel.
La thèse en une ligne : tester un agent sur des données réelles n’est pas un raccourci technique, c’est un traitement de données personnelles avec son risque et son responsable, et on peut presque toujours l’éviter ou le restreindre, au prix d’une perte de qualité qu’il vaut mieux mesurer qu’ignorer.
Données de test pour agents IA : pourquoi « tester sur du réel » est déjà un traitement de données
L’autorité espagnole de protection des données (l’AEPD) le dit sans détour dans son billet sur les environnements de développement et de préproduction (avril 2022) : les tests logiciels avec des données personnelles « sont, ou font partie de, traitements de données personnelles », avec toutes les obligations du RGPD, et il faut éviter autant que possible d’utiliser des données personnelles en développement, en préproduction ou dans tout autre environnement de test. Elle ajoute un point gênant : le risque dans ces environnements peut être égal ou supérieur à celui de la production, car il y a plus de prestataires, plus de copies et moins de contrôles.
Avec un agent, l’exposition est plus difficile à voir qu’avec une application classique. Les données de test ne restent pas dans une base : elles voyagent dans des prompts vers un modèle tiers, se retrouvent dans des traces d’observabilité et finissent dans des jeux d’évaluation versionnés et partagés. Chaque copie est un endroit de plus où les données de tes clients existent sans que personne les ait comptées ; c’est le problème décrit dans ce qui sort de ton périmètre à chaque appel. La règle de fond est européenne ; l’application concrète peut varier d’une autorité nationale à l’autre.
Quelles alternatives aux données réelles, et que perd-on avec chacune ?
Aucune option n’est gratuite. Chaque alternative protège quelque chose et coûte quelque chose ; bien choisir, c’est savoir quel test on perd avec chacune.
| Alternative | Ce qu’elle fait | Ce qu’on perd | Quand elle convient |
|---|---|---|---|
| Anonymiser pour de vrai | Retire ou transforme les données jusqu’à ce que personne ne puisse identifier la personne, même avec des informations supplémentaires | Les détails qui rendaient le cas réel : l’historique, le fil qui relie un message au suivant. Bien le faire est difficile, et si c’est réversible, ce n’est pas de l’anonymisation | Données courtes et structurées ; presque jamais du texte libre long |
| Pseudonymiser | Remplace les identifiants par des codes et garde la clé à part | Presque aucun réalisme. Mais ce sont toujours des données personnelles : les lignes directrices 01/2025 du Comité européen de la protection des données rappellent que des données pseudonymisées restent personnelles si des informations supplémentaires permettent de réidentifier | Quand il faut de la continuité entre les cas et que tu contrôles qui détient la clé |
| Données synthétiques | Génère des données de même forme que les vraies, sans correspondre à personne | Les bizarreries que personne n’a pensé à simuler : la faute de frappe, le client qui mélange deux langues, le champ vide sauf le mardi | Tester le flux, le format, les droits et les intégrations |
| Cas construits à la main | Écrits par quelqu’un qui connaît le processus, à partir de schémas réels | Le volume et la surprise : on ne trouve que ce qu’on savait chercher | Cas limites et tests qui doivent être reproductibles |
| Données réelles restreintes | Un sous-ensemble minimal, avec décision documentée, accès restreint et date de suppression | Aucun réalisme perdu, mais tout le risque, réduit | Seulement quand le reste ne suffit pas et qu’il y a une raison concrète |
L’AEPD reprend cette hiérarchie : les données synthétiques évitent dans bien des cas de traiter des données personnelles lors des tests, et les données de test dérivées de données réelles doivent conserver la structure sans contenir de vraies données personnelles. Si cela ne suffit pas, elle demande une décision documentée qui limite au maximum les données réelles utilisées.
Que ne peut-on pas tester avec de fausses données ?
Ce qui casse en production est rarement ce qu’on avait imaginé. Un agent testé seulement sur des données propres réussit des examens que la production ne pose pas : messages de trois lignes sans contexte, pièces jointes scannées de travers, client qui répond à autre chose. C’est le mécanisme de la démo qui utilisait tes meilleurs cas, appliqué aux tests.
La réponse n’est donc pas « jamais de données réelles », mais séparer ce qu’on teste et où. La logique, les formats, les intégrations et les droits se testent avec des données synthétiques et des cas faits main. La qualité face à la variété réelle se mesure ensuite, dans une exécution en parallèle où l’agent lit des entrées réelles mais écrit vers de fausses destinations, comme l’explique le guide pour tester des changements sans casser l’automatisation. Attention : cette copie lit des données réelles, c’est donc encore un traitement, qui demande sa propre justification et ses propres limites.
Quelle règle pratique évite le problème dès le départ ?
- Commence en synthétique et monte seulement si nécessaire. Chaque cran vers le réel demande une raison écrite : quel test précis tu ne peux pas faire sans.
- Donne à l’environnement de test des droits d’environnement de test. Identifiants propres, aucun accès à la production ni aux envois réels, comme développé dans quels droits donner à un agent IA.
- Suis le trajet des données. Prompts, traces, jeux d’évaluation et copies du prestataire comptent. Si ton prestataire conserve tes entrées de test, l’environnement de test n’est plus seulement à toi.
- Mets une date de suppression au jeu de test. Un jeu d’évaluation de données réelles que personne ne relit est une archive de données personnelles sans responsable.
- Qu’une personne nommée décide. Qui approuve l’usage de données réelles, et qui vérifie régulièrement qu’il est toujours nécessaire.
Que faire quand c’est le prestataire qui demande un échantillon réel ?
Ça arrive plus qu’on ne croit : le prestataire doit « voir vos cas » pour configurer l’agent. Avant d’envoyer quoi que ce soit, quatre questions, par écrit :
- Pour quoi exactement ? Un échantillon pour comprendre le format n’est pas un échantillon pour entraîner ni pour évaluer.
- Qu’en fait le prestataire ? S’il sert à améliorer ses propres modèles ou à autre chose que ton projet, la discussion change.
- Où est-il stocké et qui y accède ? Pays, sous-traitants, durée de conservation. C’est la question de fond de ce que ton prestataire ne dit pas sur l’IA et le RGPD.
- Des données synthétiques suffisent-elles ? Le plus souvent, dix cas écrits à la main et un schéma de champs suffisent pour configurer ; l’échantillon réel vient plus tard, restreint, et seulement si besoin.
Quand les données réelles se justifient-elles ?
Quand mesurer la qualité réelle est l’objectif et que le synthétique ne la représente pas. Une évaluation continue sur un petit échantillon restreint, à accès limité, est défendable, et c’est le type de mesure que nous détaillons dans évaluer la qualité de tes agents IA et dans evals : sans mesure, tu ne sais pas si ça marche. Ce qui n’est pas défendable, c’est de le faire par habitude.
Dans ce cas, l’AEPD demande une analyse de nécessité et de proportionnalité et des mesures de sécurité conformes à l’article 32 du RGPD. En pratique, ça tient sur une page : pourquoi, combien de données, qui y accède et jusqu’à quand. Et s’il faut déboguer une panne sur des données réelles faute d’alternative, la même AEPD indique ce qui s’applique : autorisation du responsable, trace et audit de cette autorisation et des actions menées, données minimales et accès réservé à ceux qui en ont besoin.
La phrase à retenir : ne demande pas si ton agent a passé ses tests, demande avec les données de qui il les a passés. Si la réponse est « les vraies » et que personne ne l’a décidé, tu n’as pas testé un agent : tu as ouvert une archive.
Sources (consultées le 20 octobre 2026) : AEPD, « Brechas de datos personales: entornos de desarrollo y preproducción » (18 avril 2022, en espagnol) ; Règlement (UE) 2016/679, art. 4(5) et 32 ; et un résumé des lignes directrices 01/2025 du CEPD sur la pseudonymisation (adoptées le 16 janvier 2025). Information générale, pas un conseil juridique.