Comment une fuite de données arrive par l'IA

En bref. Lors d’un audit de sécurité réalisé chez un fabricant de pièces automobiles, une fuite de données a été détectée après qu’un assistant IA a été branché sur un fichier Excel contenant les références de commandes clients. Quatre chemins réels ont été identifiés : l’exposition via des prompts mal formulés, l’usage de services tiers non maîtrisés, la fuite par fine‑tuning sur des données internes, et l’exploitation de chaînes d’automatisation (n8n, Make) qui ré‑exportent les résultats. Pour chacun, un garde‑fou simple existe : limiter le contexte fourni au modèle, vérifier les contrats de traitement des prestataires, geler le fine‑tuning dans un environnement isolé, et auditer les workflows d’automatisation avant mise en production.

1. Prompts qui révèlent trop de contexte

Dans de nombreuses PME, les équipes marketing ou commerciales testent des assistants de rédaction basés sur GPT‑4o ou Mistral pour générer des e‑mails personnalisés. Elles collent parfois directement un extrait du CRM contenant le nom, l’adresse e‑mail et le historique d’achat du client dans le champ de prompt, pensant que le modèle ne « voit » que la demande. En réalité, le modèle intègre ce texte dans son contexte de génération et peut le reproduire partiellement dans la réponse, surtout lorsque la température est élevée ou que le prompt est ambigu. Un cas observé chez un distributeur de matériel médical a montré qu’une réponse générée contenait le numéro de sécurité sociale d’un patient, simplement parce que le fichier CSV joint au prompt comprenait cette colonne.

Le garde‑fou consiste à ne jamais transmettre de données identifiantes dans le prompt. Une pratique efficace est de remplacer les informations sensibles par des jetons ou des identifiants aléatoires avant d’appeler l’API, puis de faire la substitution en post‑traitement. Si l’utilisation d’un modèle externe est incontournable, il faut limiter la taille du contexte envoyé (par exemple, moins de 500 caractères) et désactiver l’option de logging des prompts auprès du fournisseur.

2. Services d’IA externes sans contrôle de traitement

Beaucoup de dirigeants décident d’accélérer leurs projets en souscrivant à des offres « IA as a service » proposées par des start‑ups ou des plateformes cloud généralistes. Ils supposent que le contrat de service couvre implicitement la protection des données. Or, plusieurs fournisseurs n’offrent pas de Data Processing Agreement (DPA) signé, ou leurs conditions générales stipulent qu’ils peuvent réutiliser les entrées pour améliorer leurs modèles. Un exemple récent : une ETI du secteur du luxe a utilisé un service de transcription basé sur Whisper hébergé chez un fournisseur asiatique pour convertir des enregistrements de réunions internes en texte. Trois mois plus tard, des extraits de ces transcriptions sont apparus dans un jeu de données public destiné à l’entraînement de modèles de langue, révélant des détails sur des stratégies de prix.

Dans ce cas, la réponse est claire : ne le faites pas si le prestataire qui ne garanties de traitement des données (DPA) et ne vous permet pas d’auditer l’usage de vos entrées. Préférez des solutions déployées sur votre propre infrastructure (par exemple, un serveur GPU exécutant Mistral en mode privé) ou choisissez exclusivement des fournisseurs qui offrent un DPA conforme au RGPD et qui s’engagent à ne pas réutiliser vos données pour l’entraînement.

3. Fine‑tuning non supervisé sur des jeux de données internes

Le fine‑tuning permet d’adapter un modèle de langue à un vocabulaire métier spécifique. Certaines PME lancent ces opérations sur des notebooks Jupyter partagés, en utilisant les historiques de tickets du service support ou les fiches clients extraites du ERP. Sans isolation, le processus d’entraînement peut écrire des points de contrôle (checkpoints) sur des répertoires accessibles depuis le réseau interne, et ces checkpoints contiennent une représentation compressée des données d’origine. Un incident chez un éditeur de logiciels a révélé qu’un checkpoint laissé sur un partage réseau a été indexé par un moteur de recherche interne, permettant à un employé curieux de reconstruire partiellement des adresses e‑mail et des numéros de téléphone à partir des poids du modèle.

Le garde‑fou consiste à réaliser le fine‑tuning exclusivement dans un environnement sandbox, dépourvu de droits d’écriture sur les partages de fichiers et coupé du réseau extérieur. Utilisez des volumes Docker chiffrés ou des instances de cloud avec des politiques d’accès strictes (IAM). Après l’entraînement, exportez uniquement le fichier de poids final dans un coffre fort chiffré et détruisez immédiatement les intermédiaires. Enfin, documentez chaque étape dans un registre de traitement des données afin de démontrer la conformité au RGPD.

4. Chaînes d’automatisation qui ré‑exportent les données sensibles

Les outils d’automatisation comme n8n ou Make sont fréquemment employés pour connecter un CRM, une feuille Excel et un modèle IA afin de générer automatiquement des réponses aux demandes clients. Dans un flux typique, une ligne du CRM est lue, envoyée au modèle via une requête HTTP, puis la réponse est écrite dans un champ du CRM ou enregistrée dans un fichier de suivi. Si la configuration n’est pas rigoureuse, le nœud qui appelle le modèle peut également transmettre l’enregistrement complet du CRM (y compris les historiques d’achat, les notes internes ou les données de paiement) comme partie du corps de la requête, simplement parce que le champ « payload » n’est pas filtré. Un cas observé chez une PME de la logistique a montré qu’une automatisation n8n a exporté, sans le savoir, l’ensemble de la base de contacts vers un endpoint de test exposé publiquement pendant une phase de débogage.

Le garde‑fou consiste à mettre en place une étape de transformation explicite qui ne conserve que les champs strictement nécessaires au modèle (par exemple, uniquement le texte de la demande). Dans n8n, utilisez le nœud « Function » pour construire un nouvel objet contenant uniquement ces champs ; dans Make, ajoutez un module « Mapper » qui supprime les attributs superflus avant l’appel au modèle. Ensuite, journalisez les entrées et sorties de chaque automatisation dans un système de logs centralisé avec rétention limitée, et réalisez une revue trimestrielle des workflows pour vérifier que aucun nœud ne ré‑exporte des données sensibles.

Après avoir examiné ces quatre scénarios, la prochaine action concrète consiste à cartographier tous les points de contact entre vos données métier et les outils d’IA (prompts, appels API, fine‑tuning, automatisations) et à appliquer le garde‑fou correspondant à chaque point avant toute mise en production.

Questions fréquentes

Comment savoir si un prestataire d’IA signe bien un DPA conforme au RGPD ?

Vérifiez la section « Confidentialité » ou « Données personnelles » du contrat proposé ; un DPA valide précise les catégories de données traitées, la finalité exclusive du service, les mesures de sécurité techniques et organisationnelles, ainsi que le droit d’audit. En l’absence de ce document ou si celui‑ci se limite à une clause de confidentialité générique, considérez le prestataire comme non conforme.

Est‑ce que l’utilisation d’un modèle open‑source comme Mistral sur mon serveur élimine totalement le risque de fuite ?

Non. Même en hébergement propre, le risque demeure si le modèle reçoit en entrée des données sensibles ou si les points de contrôle d’entraînement sont stockés sans chiffrement. Il faut donc appliquer les mêmes garde‑fous : limiter le contexte transmis, isoler l’environnement d’entraînement, et chiffrer les artefacts intermédiaires.

Puis‑je continuer à utiliser Excel comme intermédiaire entre mon CRM et l’IA sans danger ?

Excel peut être utilisé tant que les feuilles contenant des données personnelles ne sont jamais partagées avec des services externes ni laissées ouvertes sur des postes non sécurisés. Préférez exporter uniquement les champs nécessaires vers un fichier CSV chiffré avant d’appeler le modèle, et supprimez immédiatement le fichier après l’opération.

À quelle fréquence devrais‑je réviser les workflows d’automatisation (n8n, Make) pour éviter les fuites ?

Une revue au moins trimestrielle est recommandée, accompagnée d’un test d’intrusion simulé sur chaque nœud qui effectue un appel à un modèle externe. Lors de chaque modification majeure du workflow, refaites une analyse d’impact sur la protection des données (AIPD) afin de valider que aucun nouveau champ sensible n’est introduit dans la chaîne.