Confidentialité : ce qu'on a le droit de mettre dans un prompt

« Est-ce que je peux coller ce document ? » C'est la première question posée dans presque toutes les formations que j'anime, et elle est posée après que la personne l'a déjà fait.

Répondre « ça dépend des conditions contractuelles » est exact et inutilisable : personne ne va lire les conditions avant chaque saisie. Il faut une règle qui tienne en une phrase et qui se retienne.

Parce qu'elle transpose une situation que chacun sait déjà arbitrer. Personne n'a besoin qu'on lui explique qu'on n'envoie pas un contrat client à un inconnu.

Elle a aussi le mérite d'être conservatrice sans être bloquante : elle autorise la reformulation d'une note interne, l'aide à la rédaction, le brouillon d'un compte rendu. Elle exclut les données personnelles identifiantes, les pièces contractuelles et tout ce qui relève d'un secret.

La règle ci-dessus ne protège que si les gens utilisent l'outil que vous avez choisi. Or dans toutes les organisations où je suis intervenu, une partie des équipes utilisait déjà un assistant grand public, sur leur propre compte, sans que personne ne le sache.

Interdire ne règle rien : cela déplace simplement l'usage hors de vue. Fournir un accès encadré, avec la règle ci-dessus et une formation courte, ramène l'usage dans le périmètre, et c'est aussi ce qu'exige la littératie IA du règlement européen depuis février 2025.

J'écris cette règle sur une page, avec trois exemples autorisés et trois exemples interdits tirés du métier de l'organisation. Elle est affichée à côté de l'outil, pas rangée dans un classeur.

Une règle qu'on ne peut pas citer de mémoire n'est pas une règle.

Un document peut rester identifiant après retrait de tous les noms, et la règle simple ne le voit pas. C'est la limite à poser explicitement.

Un compte rendu décrivant une pathologie rare, une date d'intervention et un établissement identifie une personne sans qu'aucun nom n'apparaisse. Un dossier mentionnant un poste unique dans une petite structure fait de même.

Pour ces corpus, la règle générale ne suffit pas et le traitement doit rester interne. La chaîne technique correspondante est décrite dans anonymiser avant d'envoyer, avec ses conditions de validité.

Un modèle qui tourne sur le poste de travail ne pose aucune question de transfert, parce qu'aucune donnée ne part. Cette option n'existait pas quand la règle a été formulée ; elle change la conversation.

Pour l'extraction, la classification, l'anonymisation et le résumé court, un modèle local suffit désormais. Ces tâches couvrent l'essentiel des besoins portant sur des données sensibles.

La configuration qui en découle est mixte : traitement local pour ce qui est protégé, service externe pour l'analyse complexe sur ce qui peut sortir. Elle est détaillée dans petits modèles sur poste, et elle rend la règle beaucoup plus facile à tenir au quotidien.

Une note d'une page par système, indiquant quelles données lui sont fournies et quels droits d'accès s'appliquent, suffit à répondre à l'essentiel des questions posées lors d'un contrôle. Elle manque presque toujours.

Le contenu utile tient en quatre lignes : quelles catégories de données entrent dans le système, d'où elles viennent, à quel moment de la chaîne les droits d'accès sont appliqués, et où va le traitement.

La troisième ligne est celle qui distingue une protection d'une apparence de protection. Filtrer les droits après la recherche laisse le modèle lire ce que l'utilisateur n'a pas le droit de voir, avant qu'un filtre ne masque la source, la réponse, elle, est déjà formée.

Le format complet de cette note figure dans écrire la fiche d'un système d'IA. Elle prend une heure et sert bien au-delà de la conformité : elle oblige à nommer ce que le système reçoit réellement, ce que personne ne sait dire spontanément.