Un système de support piloté par l'IA, que l'on pensait sécurisé au stade de la sortie du modèle, laissait fuiter des données clients par la « porte dérobée » qui injecte les enregistrements CRM dans le prompt. Le post-mortem du créateur montre que protéger uniquement le texte généré par le modèle ne suffit pas : la requête entrante, les données récupérées auprès des outils internes et l'émission finale nécessitent toutes des protections indépendantes, sous peine de voir une entreprise exposer des noms, des e-mails et des identifiants sans jamais constater de faille dans la sortie du modèle.

Pourquoi ces trois limites sont cruciales

La plupart des opérateurs supposent qu'une fuite se produit lorsque le modèle de langage répète un secret qu'il a vu. En pratique, l'exposition la plus importante survient avant même que le modèle ne voie les données. Un agent d'IA reçoit trois flux d'informations :

  • Ingress – la requête brute saisie par un client.
  • Return path – les informations que l'agent extrait de systèmes en aval, tels qu'un CRM.
  • Emission – le texte que le modèle renvoie à l'utilisateur.

Si l'un de ces flux contient des identifiants non protégés, l'agent peut involontairement les intégrer dans sa réponse, même si la couche de sortie est filtrée.

Du prototype à la production : des leçons durement acquises

Le passage d'un prototype à un centre d'assistance en direct a révélé des défaillances concrètes qu'une simple approche de type « masquer puis envoyer » n'avait pas détectées.

  • Tokeniser plutôt que masquer – Supprimer un nom ou un e-mail avant qu'il n'atteigne le modèle empêche le système de reconstruire une réponse correcte. Stockez la valeur originale dans un coffre-fort sécurisé, remplacez-la par un UUID aléatoire dans le prompt, puis réinjectez l'UUID une fois que le modèle a terminé. Cela permet de maintenir les données brutes hors du contexte du modèle tout en préservant ses fonctionnalités.

  • Valider les identifiants avec des sommes de contrôle (checksums) – Une expression régulière repère une chaîne qui ressemble à un numéro de compte ; une somme de contrôle confirme s'il s'agit d'un identifiant authentique. Un filtre de somme de contrôle empêche l'agent de traiter des nombres arbitraires comme des données sensibles, réduisant ainsi les faux positifs qui déclencheraient autrement des masquages inutiles.

  • Fusionner les segments (spans) qui se chevauchent – Les dossiers clients contiennent souvent un nom suivi d'une adresse e-mail qui partagent des caractères (ex : « John Doe john.doe@example.com »). Si vous ne tokenisez que le nom, le fragment d'e-mail reste en clair, ce qui peut entraîner son émission. Traitez toute la zone de chevauchement comme un seul jeton (token).

  • Tester la bonne limite – Un test qui réussit en ne vérifiant que la couche d'émission donne un faux sentiment de sécurité. Un test en échec qui détecte une fuite dans le chemin de retour impose une correction. Concevez des suites de tests qui valident explicitement chacune des trois limites.

  • Suivre la vérité terrain (ground truth) – Lorsqu'un humain modifie le brouillon généré par l'IA avant de l'envoyer, le modèle a déjà produit une réponse erronée. Comparer le brouillon de l'IA au message final approuvé par l'humain permet de révéler les écarts de confiance et d'empêcher le système d'apprendre à répéter ses erreurs.

Les enjeux pour les entreprises

Les agents d'IA de service client se situent à l'intersection de l'interaction publique et des bases de données internes.

Contre-argument : pourquoi certains privilégient encore le masquage

À retenir

Sécuriser un agent de service client piloté par l'IA n'est pas un problème à porte unique. Considérez la requête entrante, les données récupérées des systèmes internes et le texte sortant comme des murs distincts ; si l'un d'eux est franchi, c'est l'ensemble du service qui est compromis. La tokenisation des champs sensibles, la validation des identifiants, la fusion des segments qui se chevauchent, le test de la bonne limite et la comparaison continue des brouillons de l'IA avec les messages humains finaux sont les étapes concrètes qui transforment un « copilote » en un service agentique et fiable.