Sécurité et confidentialité des données quand on met de l'IA dans ses process

Précision utile avant de commencer : cet article décrit une pratique d'ingénierie, pas un avis juridique. Sur les points réglementaires sensibles, la référence reste la documentation de la CNIL et, le cas échéant, votre conseil.

Le vrai risque n'est pas le modèle, c'est le trajet des données

La crainte la plus répandue est qu'un modèle « apprenne » vos données et les restitue à un concurrent. C'est une préoccupation légitime, mais ce n'est pas le risque principal au quotidien. Le risque le plus fréquent est bien plus banal : des données qui sortent du périmètre de l'entreprise sans que personne n'ait décidé qu'elles devaient en sortir.

Un exemple typique : une automatisation qui résume les e-mails entrants envoie, pour faire son travail, l'intégralité du message au modèle. Or ce message contient parfois un RIB, un document d'identité, un dossier médical ou une information contractuelle confidentielle. Personne ne l'a voulu ; c'est simplement la conséquence de n'avoir pas décidé quoi envoyer.

Étape 1 : Cartographier ce qui sort

Avant toute considération technique, il faut un inventaire écrit. Pour chaque automatisation qui appelle un modèle, notez quatre choses : quelles données entrent dans le prompt, quel fournisseur les reçoit, dans quelle zone géographique elles sont traitées, et combien de temps elles sont conservées.

Cet exercice réserve presque toujours des surprises. On découvre qu'un flux transmet un fichier entier là où trois champs suffisaient, ou qu'un service tiers ajouté « pour tester » est resté en production. La cartographie n'est pas de la paperasse : c'est ce qui rend le reste possible.

Étape 2 : Minimiser, vraiment

La minimisation est le principe le plus efficace, et le plus négligé. La question à se poser pour chaque appel est : de quoi le modèle a-t-il strictement besoin pour produire le résultat attendu ?

• Extraire avant d'envoyer : si l'objectif est de déterminer l'urgence d'une demande, envoyez le corps du message sans les pièces jointes, sans la signature et sans l'historique de la conversation.
• Pseudonymiser ce qui n'est pas nécessaire : remplacer un nom par un identifiant avant l'appel, puis rétablir la correspondance après, est souvent simple à mettre en place et change radicalement le niveau d'exposition.
• Filtrer les motifs sensibles en amont : détecter et masquer par règle déterministe les IBAN, numéros de sécurité sociale et numéros de carte avant tout appel au modèle. Cette étape ne doit pas être confiée à une IA. Un filtre de sécurité doit être prévisible.
• Segmenter les documents : traiter la section pertinente d'un contrat plutôt que le contrat entier réduit à la fois l'exposition et le coût.

Étape 3 : Choisir où le traitement a lieu

Il existe trois grandes options, et le choix se fait selon la sensibilité des données, pas selon la mode du moment.

1. API d'un fournisseur de modèles : la voie la plus simple et la plus performante. Elle suppose de vérifier les engagements contractuels du fournisseur ainsi que la zone de traitement. Vérifiez notamment que vos données ne servent pas à l'entraînement : cette garantie dépend de l'offre souscrite.
2. Modèle hébergé dans votre environnement cloud : un compromis courant, où le modèle s'exécute dans une région et un compte que vous contrôlez. Cela répond à beaucoup d'exigences de localisation sans imposer d'exploiter du matériel.
3. Modèle exécuté localement : cette option permet de garder le traitement dans votre infrastructure, à condition de contrôler aussi les appels externes, la télémétrie et les outils utilisés. Elle demande du matériel et des compétences. Évaluez le modèle sur vos tâches réelles avant de conclure qu’il répond au besoin.

Le même raisonnement s'applique à la plateforme d'automatisation elle-même : un outil auto-hébergé garde les données dans votre périmètre, un outil en ligne les fait transiter par un tiers. C'est précisément ce qui rend ce critère structurant dans le choix d'outil.

Étape 4 : Traiter le fournisseur comme un sous-traitant

Dès lors qu'un service tiers traite des données personnelles pour votre compte, il entre dans la catégorie des sous-traitants au sens du RGPD. Cela emporte des conséquences concrètes et vérifiables.

• Le service doit figurer dans votre registre des traitements, avec sa finalité et la nature des données concernées.
• Un accord de traitement doit exister. La plupart des fournisseurs sérieux en publient un, encore faut-il l'avoir lu et accepté explicitement.
• Votre politique de confidentialité doit mentionner ces destinataires. C'est le point le plus souvent oublié : ajouter un outil dans un flux sans mettre à jour la politique crée une incohérence facile à constater de l'extérieur.
• Les transferts hors Union européenne doivent reposer sur un mécanisme valide, et les personnes concernées doivent pouvoir exercer leurs droits, y compris la suppression, ce qui suppose de savoir où leurs données ont été copiées.

Étape 5 : Sécuriser l'exécution

Trois sujets techniques déterminent le niveau réel de sécurité d'une automatisation, bien avant le choix du modèle.

Les secrets

Clés d'API, jetons d'accès et mots de passe ne doivent jamais figurer en clair dans un flux, un dépôt de code ou une variable d'environnement partagée. Ils doivent être stockés dans un gestionnaire dédié, avoir la portée la plus étroite possible, et pouvoir être révoqués sans casser le reste. Une clé qui donne accès à tout parce que c'était plus simple à configurer est un risque évitable.

Les permissions

Une automatisation qui lit des e-mails n'a pas besoin de pouvoir en supprimer. Un agent qui consulte un CRM n'a pas besoin d'y écrire. Chaque droit accordé au-delà du nécessaire est un dégât potentiel en cas d'erreur ou de compromission. C'est particulièrement vrai pour un agent, dont le comportement n'est pas entièrement prévisible : ses permissions doivent être restreintes par construction, pas par confiance.

La journalisation

Il faut pouvoir répondre à la question « que s'est-il passé le 12 à 14 h ? ». Une trace horodatée des exécutions, des erreurs et des décisions prises est indispensable. Avec une nuance importante : ces journaux contiennent souvent des données personnelles, parfois plus que le traitement lui-même. Ils doivent donc être protégés, avoir une durée de conservation définie et être purgés automatiquement. Un journal éternel est une base de données non déclarée.

L'injection de prompt : un risque propre aux agents

Quand un agent lit un contenu venu de l'extérieur, comme un e-mail, une page web ou un document envoyé par un tiers, ce contenu peut contenir des instructions destinées au modèle plutôt qu'à l'humain. Un e-mail peut ainsi tenter de faire exécuter à l'agent une action non prévue.

Aucune formulation de consigne ne protège totalement contre cela. La seule défense robuste est architecturale : ne jamais donner à un agent qui lit du contenu externe le pouvoir d'effectuer une action irréversible. Séparer la lecture de l'action, valider les sorties par des règles déterministes et exiger une confirmation humaine pour tout ce qui engage l'entreprise. C'est le même principe que celui qui régit la frontière entre agent et automatisation classique, appliqué à la sécurité.

Quand il faut renoncer

• Quand les données relèvent d'une catégorie particulière (santé, opinions, données judiciaires) et qu'aucune option de traitement local n'est envisageable. Le gain d'efficacité ne justifie pas ce niveau d'exposition.
• Quand un engagement contractuel de confidentialité interdit la communication à un tiers. Un client qui a exigé que ses documents ne quittent pas votre système a exprimé une contrainte, pas une préférence.
• Quand personne ne pourra assurer le suivi. Une automatisation qui manipule des données sensibles sans propriétaire identifié devient un risque dormant.
• Quand vous ne savez pas dire, précisément, quelles données partent. L'incertitude elle-même est le signal d'arrêt : on cartographie d'abord, on automatise ensuite.

En pratique

La démarche tient en une phrase : savoir ce qui sort, n'envoyer que le nécessaire, choisir un traitement compatible avec la sensibilité des données, déclarer ce que l'on utilise, et empêcher par construction ce qui ne doit jamais arriver. Aucun de ces points ne demande une expertise inaccessible à une PME. Ils demandent surtout d'être traités avant la mise en production plutôt qu'après un incident.