IA et vie privée : quelles données ne pas partager et comment réduire les risques

Vous souhaitez améliorer votre curriculum vitæ et vous le collez en entier dans un assistant d’intelligence artificielle. La démarche semble anodine, mais le document comprend votre adresse, votre numéro de téléphone, votre courriel personnel et peut-être des références contenant des données d’autres personnes. Aucun de ces détails n’était nécessaire pour obtenir de l’aide sur la rédaction.

C’est là le problème quotidien de l’IA et de la vie privée : une requête utile peut se transformer, sans intention délibérée, en une transmission excessive d’informations. La solution ne consiste ni à se méfier de tout outil ni à supposer que le moindre réglage offre une protection absolue. Elle consiste à mieux déterminer quelles données sont nécessaires, lesquelles doivent être retirées de la requête et dans quel environnement la tâche peut être accomplie.

Idée clé : La meilleure protection commence avant d’appuyer sur « envoyer » : si une donnée n’est pas nécessaire pour obtenir une réponse utile, retirez-la.

D’abord, classer l’information

Toutes les données n’engendrent pas le même préjudice si elles sont exposées. Avant de les saisir dans un outil d’IA, il convient d’identifier à quelle catégorie elles appartiennent :

• Publiques : elles ont déjà été publiées de manière légitime et leur réutilisation ne crée pas de risque significatif. Pour autant, public ne signifie pas dépourvu de contexte ou de responsabilité.
• Personnelles : elles permettent d’identifier directement ou indirectement une personne, comme le nom, l’adresse, le téléphone, le courriel, la localisation ou un numéro d’identification.
• Particulièrement sensibles : elles décrivent la santé, la biométrie, la vie sexuelle, les opinions politiques, les croyances ou d’autres aspects susceptibles de causer un préjudice important en cas de divulgation. Les catégories juridiques exactes varient selon les juridictions.
• Confidentielles ou secrètes : mots de passe, clés d’accès, informations financières, contrats non publics, secrets d’affaires ou documents soumis à des obligations professionnelles.
• De tiers : toute donnée relative à une autre personne, même si elle vous semble ordinaire.

Cette classification n’est pas un exercice théorique. Elle sert à guider la décision. Un texte public peut être utilisé avec prudence ; un document comportant des données personnelles exige une minimisation ; un mot de passe ou un secret d’affaires ne devrait pas être introduit dans une requête ordinaire.

Le Règlement général sur la protection des données de l’Union européenne définit comme donnée à caractère personnel toute information se rapportant à une personne identifiée ou identifiable, et reconnaît des catégories particulières. Il constitue une référence utile pour comprendre ces notions, et non une règle juridique universelle : les droits et obligations concrets dépendent du pays et du contexte.

L’arbre de décision : omettre, minimiser ou utiliser un environnement approuvé

Une fois l’information classée, appliquez ces questions dans l’ordre :

1. La tâche peut-elle être résolue sans cette donnée ? Si la réponse est oui, supprimez-la. Pour corriger le style d’un courriel, le nom réel du client, son numéro de téléphone ou le numéro de contrat ne sont pas nécessaires.
2. Pouvez-vous la remplacer par une information fictive ou plus générale ? Remplacez les noms, dates, chiffres et lieux par des variables génériques ou des fourchettes lorsque ces détails n’influent pas sur le résultat.
3. Le contexte restant permet-il encore d’identifier quelqu’un ? Une profession rare, une petite localité et une date précise peuvent révéler une identité même si vous avez retiré le nom.
4. L’information est-elle confidentielle ou soumise aux règles d’une organisation ? Utilisez uniquement un environnement autorisé pour ce type de données ou n’effectuez pas la requête.
5. Avez-vous vérifié les conditions réelles du service ? Examinez le produit, l’offre, le compte et les paramètres ; ne vous fiez pas à une impression générale sur la marque.

Ce critère répond au principe de minimisation des données : n’utiliser que des informations adéquates, pertinentes et nécessaires. Réduire les identifiants diminue l’exposition, mais ne garantit pas l’anonymat.

Retirer le nom ne garantit pas toujours l’anonymisation

Remplacer « María Pérez » par « Patient A » peut être utile, mais il s’agit généralement d’une forme de pseudonymisation, et non d’anonymisation. Si vous conservez une table permettant de retrouver l’identité, ou si les détails du cas suffisent à reconnaître la personne, le lien subsiste.

La Commission européenne explique que différents éléments d’information peuvent se combiner pour identifier une personne. Le NIST avertit également que l’efficacité des techniques de dé-identification varie et qu’il existe un risque de réidentification.

C’est pourquoi effacer le nom ne suffit pas. Il peut aussi être nécessaire de généraliser les âges et les dates, de supprimer les localisations, de résumer les antécédents ou de créer un cas synthétique qui préserve la problématique sans reproduire l’histoire réelle.

Idée clé : Anonymiser ne consiste pas à masquer un identifiant visible ; cela consiste à empêcher raisonnablement que l’information puisse de nouveau être associée à une personne.

Quels paramètres vérifier avant d’utiliser un outil

Les pratiques des services d’IA ne sont pas uniformes. Il ne suffit pas non plus de lire un slogan promotionnel. Le guide de l’Australian Signals Directorate et de ses partenaires internationaux recommande d’évaluer quelles données sont saisies et de vérifier des aspects tels que le stockage, le réentraînement, les conditions d’utilisation et les paramètres de contrôle.

Avant de travailler avec des informations qui ne sont pas publiques, vérifiez :

• si les données saisies sont conservées et pendant combien de temps ;
• si elles peuvent être utilisées pour améliorer ou entraîner des systèmes ;
• quelle option permet de limiter cet usage et si elle est activée ;
• qui y a accès au sein d’un compte ou d’un espace partagé ;
• quelles intégrations, extensions ou autorisations sont connectées ;
• où les données sont traitées ou stockées, lorsque cela est pertinent ;
• comment demander la suppression et quelle est la portée de cette procédure ;
• quelle politique, quel contrat ou quelle règle interne s’applique à votre cas.

Rétention, entraînement et suppression sont des questions distinctes. Effacer une conversation depuis l’interface ne prouve pas, à lui seul, que toute copie a disparu de chaque système. Il convient de consulter la documentation en vigueur du produit, de l’offre et de la configuration spécifique.

Une politique favorable ne compense pas non plus un compte mal configuré. De la même manière, un bon réglage de la part de l’utilisateur ne remplace pas les contrôles techniques, contractuels et organisationnels qui incombent au fournisseur ou à l’institution.

Trois cas pour appliquer ce critère

Un curriculum vitæ avec des coordonnées

Objectif : améliorer la valorisation des réalisations et la clarté. Il n’est pas nécessaire de partager une adresse, un numéro de téléphone, un courriel, une pièce d’identité ni le nom de personnes de référence. Conservez les postes, les compétences et les résultats ; remplacez les noms des entreprises si leur divulgation n’est pas indispensable. Intégrez ensuite les corrections au document original en dehors de l’outil.

Une question sur la santé d’un tiers

Objectif : comprendre des questions générales en vue d’un prochain rendez-vous. Ne collez pas le rapport médical et ne décrivez pas une combinaison d’âge, de localité, de diagnostic rare et de date permettant d’identifier le patient. Formulez une question générale ou utilisez un cas fictif. De plus, une réponse fournie par une IA ne remplace pas l’évaluation d’un professionnel de santé.

Un document de travail

Objectif : résumer un contrat ou préparer une communication. Si le fichier contient des noms, des identifiants, des clauses confidentielles ou des éléments de stratégie interne, ne l’envoyez pas à un outil public. Utilisez le canal approuvé par l’organisation, s’il existe et qu’il est autorisé pour ce type d’informations. S’il n’existe pas, travaillez à partir d’une trame dépourvue de données réelles.

Dans ces trois cas, la question décisive est la même : puis-je préserver l’utilité de la tâche tout en réduisant les informations exposées ?

Si vous avez déjà envoyé des informations par erreur

Agissez avec calme et évitez d’aggraver la situation :

1. Ne réutilisez pas et ne recollez pas ce contenu dans d’autres requêtes.
2. Supprimez la conversation à l’aide des paramètres disponibles, sans présumer que cela clôt la procédure.
3. Consultez la documentation relative à la rétention, à l’utilisation des données et aux demandes de suppression.
4. Modifiez immédiatement tout mot de passe, jeton ou identifiant exposé.
5. S’il s’agissait de données relatives à des tiers ou à une organisation, signalez-le via le canal interne approprié et suivez sa procédure de gestion des incidents.
6. Consignez ce qui a été envoyé, à quel moment, vers quel service et depuis quel type de compte. Ces informations aident à évaluer le risque et à réagir de manière proportionnée.

La responsabilité ne repose pas uniquement sur l’utilisateur : les fournisseurs conçoivent le service et les organisations doivent établir des règles, des accès et des réponses claires. Néanmoins, chaque personne conserve un pouvoir de décision important sur ce qu’elle transmet. Cette capacité de choisir fait partie intégrante de la vie privée et de l’autonomie individuelle.

Idée clé : Aucun paramètre ne rend prudente une requête contenant des secrets, des identifiants ou des données de tiers non nécessaires.

La règle finale est simple : partagez moins et vérifiez davantage. Définissez la tâche, supprimez les données qui ne modifient pas la réponse, adaptez l’exemple lorsque c’est possible et réservez les informations délicates à un environnement expressément autorisé. L’IA peut être utile sans exiger que vous renonciez au contrôle de vos informations ni à celui des données d’autrui.