Caviardage des données personnelles : guide RGPD et IA 2026

Chaque bulletin de paie, contrat, transcription d'entretien de départ et email client que votre cabinet traite contient des données personnelles qui doivent être retirées avant que le document soit partagé, archivé ou transmis à un modèle d'intelligence artificielle. Le caviardage de documents — la suppression délibérée des informations personnelles identifiables (PII) — n'est plus une tâche de conformité de niche. C'est le verrou opérationnel qui détermine si votre cabinet peut utiliser l'IA générative en toute sécurité, partager des fichiers avec des tiers sans enfreindre le RGPD, et survivre à une enquête de la CNIL sans produire les journaux que vous regretteriez d'avoir écrits. L'anonymisation de documents et le masquage de données sont les deux mécanismes pratiques dont nous parlerons ; nous tenons cette terminologie dans toute la guide.

Ce guide est la référence long-form que nous aurions voulu trouver quand nous avons construit Redactic. Il couvre ce qu'est réellement le caviardage et ce qu'il n'est pas, comment le RGPD l'encadre (pseudonymisation à l'article 4(5) versus anonymisation au Considérant 26), les deux modes opérationnels que vous utiliserez en pratique, les catégories de PII qui doivent absolument être masquées avant tout usage IA, un workflow en cinq étapes qui passe à l'échelle d'un seul PDF à un tableur de paie multi-feuilles, le risque RGPD réel du shadow AI dans les cabinets professionnels, une checklist en huit points pour choisir un outil de caviardage, et une FAQ avec les questions que les clients nous posent chaque semaine.

Vous pouvez lire l'article du début à la fin — il est écrit pour être survolé — ou sauter à la section qui correspond à votre problème immédiat. Si votre cabinet a déjà eu la conversation "qu'est-ce qu'on fait de ChatGPT" et l'a perdue, commencez par la section shadow AI. Si votre préoccupation est l'inspection CNIL, commencez par le cadre RGPD.

1. Qu'est-ce que le caviardage — et ce qu'il n'est pas

Le caviardage de documents est le processus qui consiste à identifier les informations personnelles ou sensibles dans un document et à les retirer de la version qui sera partagée, traitée ou archivée en aval. Le terme vient de la pratique judiciaire consistant à noircir les passages des dossiers de tribunal publiés ; dans les workflows numériques il couvre un ensemble bien plus large d'opérations, du remplacement d'un nom par un jeton-place-tenant à la destruction permanente d'une zone d'image par un noircissement pixel-perfect.

On utilise souvent "caviardage", "anonymisation", "pseudonymisation", "masquage", "chiffrement" et "suppression" comme synonymes. Ils ne le sont pas, et la différence compte au regard du RGPD. Nous reviendrons sur les nuances juridiques en section 2 ; pour l'instant gardez en tête les distinctions suivantes.

• Le caviardage est l'opération-parapluie : transformer un document contenant des PII en une version qui n'en contient plus (ou plus d'une manière récupérable par un attaquant ou un lecteur non autorisé).
• Le masquage (ou masquage de données) est une technique : remplacer chaque span PII détecté par un place-tenant tel que [PERSONNE_1] ou ⟦NOM⟧. Le place-tenant est signifiant pour le processus en aval (par exemple un LLM) mais ne contient en lui-même aucun identifiant.
• La pseudonymisation est le masquage plus une cartographie de retour conservée séparément. Le RGPD la reconnaît explicitement à l'article 4(5) et la récompense dans tout le texte, mais elle ne transforme pas les données en données "anonymes".
• L'anonymisation est irréversible, à sens unique. Après anonymisation, personne — y compris vous — ne devrait pouvoir ré-identifier la personne concernée. Le RGPD place la barre au Considérant 26 et les données anonymes sortent entièrement du champ du règlement.
• Le chiffrement est réversible par toute personne disposant de la clé. Les PII chiffrées restent des données personnelles au sens du RGPD ; le chiffrement est un contrôle de sécurité, pas une technique de caviardage.
• La suppression retire le document ; le caviardage retire les PII d'un document que l'on conserve.

L'implication pratique pour toute équipe adoptant un outil de caviardage ou un outil de masquage est la suivante : si vous voulez partager une seule version propre avec un tiers et ne jamais regarder l'original, l'anonymisation (un noircissement permanent) est l'outil juste. Si vous voulez confier le document à un modèle IA pour analyse puis lire la réponse avec les vrais noms restaurés, vous voulez la pseudonymisation — c'est-à-dire le masquage réversible. La plupart des workflows professionnels ont besoin des deux, souvent dans le même document. Un bon outil supporte nativement les deux modes au lieu de vous forcer à choisir un seul chemin pour toute la pipeline.

L'autre anti-pattern que nous voyons constamment est de traiter le caviardage comme une étape ponctuelle de pré-partage. Dans un cabinet multi-utilisateurs avec drives partagés, usage hebdomadaire de LLM et sous-traitants externes, le caviardage doit vivre dans le workflow — à l'upload, au moment de la requête IA, à l'export — pas comme une révision mensuelle manuelle d'un assistant avec un surligneur noir.

2. Le cadre RGPD : article 4(5) pseudonymisation vs Considérant 26 anonymisation

Trois références RGPD structurent toute conversation sérieuse sur le caviardage en UE.

L'article 4 RGPD, paragraphe 5, définit la pseudonymisation comme "le traitement de données à caractère personnel de telle façon que celles-ci ne puissent plus être attribuées à une personne concernée précise sans avoir recours à des informations supplémentaires". Ces informations supplémentaires doivent être "conservées séparément et soumises à des mesures techniques et organisationnelles afin de garantir que les données à caractère personnel ne sont pas attribuées à une personne physique identifiée ou identifiable". Les données pseudonymisées restent des données personnelles : le RGPD s'applique encore, il faut toujours une base légale, et la personne concernée conserve ses droits d'accès et d'effacement. C'est ce qu'on appelle la pseudonymisation RGPD au sens strict.

Le Considérant 26 RGPD trace la ligne pour l'anonymisation : "il convient donc que les principes de la protection des données ne s'appliquent pas aux informations anonymes, à savoir les informations ne concernant pas une personne physique identifiée ou identifiable, ni aux données à caractère personnel rendues anonymes de telle manière que la personne concernée ne soit pas ou plus identifiable". Les données anonymes sont hors champ. La barre est haute et se comprend mieux à travers les trois critères de l'Opinion 05/2014 WP29 : singling out (isolement), linkability (corrélation), inference (déduction). Si un document caviardé permet encore d'isoler un individu, de lier des enregistrements entre datasets, ou d'inférer des attributs sur une personne spécifique, vous avez pseudonymisé — pas anonymisé. L'anonymisation RGPD à proprement parler est plus rare que ce que les vendeurs laissent entendre.

L'article 25 RGPD (Protection des données dès la conception et par défaut) et l'article 32 RGPD (Sécurité du traitement) poussent ensemble la pseudonymisation comme mesure technique prudente pour les traitements risqués. L'article 32(1)(a) la nomme expressément. C'est pourquoi un programme de conformité ayant investi dans une pseudonymisation correcte est récompensé par les autorités de contrôle : c'est un contrôle que le règlement lui-même prescrit nominativement.

L'AI Act de l'UE, en vigueur depuis 2024 avec des dispositions haut-risque qui s'échelonnent en 2026 et 2027, ajoute une couche supplémentaire. Les systèmes IA utilisés pour les RH (recrutement, évaluation de la performance, décisions de promotion) sont classés haut-risque à l'annexe III. Ils exigent gestion des risques, gouvernance des données, documentation technique, transparence, supervision humaine, contrôles d'exactitude/robustesse/cybersécurité, et une analyse d'impact sur les droits fondamentaux. L'RGPD IA n'est pas deux réglementations empilées l'une sur l'autre ; c'est un modèle opérationnel unique. L'intelligence artificielle RGPD, la conformité IA et le caviardage RGPD passent en pratique par le même processus de pseudonymisation préventive, car il satisfait à la minimisation (art. 5 RGPD) et à la gouvernance des données AI Act (art. 10) au même moment. La CNIL IA, dans ses recommandations publiées en 2024-2025, va dans le même sens : pseudonymiser avant l'usage IA, surtout pour les données RH.

Un mythe à tuer : beaucoup de vendeurs commercialisent leur outil comme "anonymisation RGPD" alors qu'il s'agit en fait de pseudonymisation. Si la carte du place-tenant à la valeur originale existe quelque part — sur votre filesystem, dans le navigateur de l'utilisateur, dans un service que nous opérons — les données sont pseudonymisées, pas anonymes. La pseudonymisation est une garantie précieuse, et il n'y a rien de mal à la proposer ; l'appeler anonymisation est trompeur et expose le client à un piège de conformité. Le certificat de Redactic distingue explicitement les deux et étiquette chaque job réversible comme pseudonymisation au sens de l'article 4(5).

La jurisprudence a encore resserré la ligne. Dans Breyer c. Allemagne (C-582/14, 2016) la CJUE a jugé qu'une adresse IP détenue par un opérateur de site web est une donnée personnelle si l'opérateur a des moyens légaux raisonnables d'obtenir les informations identifiantes supplémentaires auprès d'un tiers. Le test des "moyens raisonnables" est plus large que ce que beaucoup d'ingénieurs supposent : des données que votre service seul ne peut pas identifier peuvent rester personnelles si une décision de justice ou un accord contractuel peut fournir les pièces manquantes. Pour le caviardage, cela signifie qu'un split place-tenant-plus-carte entre deux organisations n'est pas automatiquement de l'anonymisation — si l'une des parties peut légalement contraindre l'autre à divulguer la carte, les données sont pseudonymisées pour les deux. L'arrêt 2023 SRB c. EDPS (T-557/20) a renforcé la nature contextuelle du test en distinguant les données pseudonymisées entre les mains d'un destinataire qui ne peut pas ré-identifier et les mêmes données entre les mains du responsable du traitement qui peut.

L'Opinion 05/2014 WP29 (désormais reprise par l'EDPB) opérationnalise le Considérant 26 avec trois modèles d'attaque concrets. Singling out : un attaquant peut-il isoler un enregistrement correspondant à un individu ? Linkability : deux enregistrements du même dataset, ou de datasets différents, peuvent-ils être liés au même individu ? Inference : la valeur d'un attribut peut-elle être déduite de la combinaison des autres ? Si la réponse à l'une est oui, le document est pseudonymisé, pas anonymisé. La conclusion pratique est que masquer le nom sur un tableur de paie ne l'anonymise pas — la ligne isole encore un seul employé — et que le cas véritablement anonyme est plus rare que ce que la documentation marketing laisse entendre.

3. Les deux modes : réversible (carte de place-tenants) et irréversible (noircissement)

En production vous utiliserez constamment deux modes. Comprendre la différence est la différence entre un workflow qui survit à une inspection et un workflow qui fuit des noms parce que vous avez utilisé le mauvais outil pour la tâche.

Le caviardage réversible (pseudonymisation) remplace chaque entité détectée par un place-tenant stable et stocke une carte séparée du place-tenant vers la valeur originale. La carte est ce qui rend l'opération réversible : vous passez le texte masqué à un LLM, vous récupérez la réponse référençant les place-tenants, et vous substituez les valeurs originales dans la sortie rendue. L'utilisateur voit les vrais noms ; le modèle ne les a jamais vus. C'est le seul mode qui permet de masquer PDF, anonymiser PDF ou caviarder PDF et utiliser l'IA de manière utile. Le compromis est qu'il faut protéger la carte. Si la carte fuit, la pseudonymisation est défaite pour chaque enregistrement qu'elle couvrait.

La réversibilité a deux architectures. Cartes côté client : elles vivent dans le navigateur de l'utilisateur et n'atteignent jamais le serveur — le mode le plus paranoïaque, utile quand on ne peut pas faire confiance à un état côté service. Cartes côté serveur : elles vivent dans un store éphémère (Redis avec TTL court est le motif courant) pour permettre à l'utilisateur de reprendre le job depuis un autre appareil. Redactic utilise des cartes éphémères côté serveur chiffrées Fernet avec TTL 120 secondes sur l'input et 300 secondes sur l'output, plus un mode explicite de restauration locale dans le navigateur pour les workflows les plus sensibles. Les deux modes acheminent la requête IA via du texte pseudonymisé, donc le fournisseur LLM ne voit jamais les PII originales.

Le caviardage irréversible (noircissement de type anonymisation) détruit définitivement la zone du document où vivaient les PII. Noircir un PDF dans ce sens strict est ce que la plupart des régulateurs ont en tête quand ils disent "anonymisation". Sur un PDF numérique l'outil retire le contenu textuel et superpose un rectangle noir ; sur un PDF scanné ou une image, l'outil exécute l'OCR pour trouver les PII puis peint sur les pixels. Il n'y a pas de carte. La sortie est le document que votre cabinet livre à la partie adverse ; pas de retour possible. C'est le seul mode à utiliser quand l'objectif est "ce fichier quitte le cabinet et nous n'aurons plus besoin de l'original". Le noircissement irréversible est ce qu'il y a de plus proche de l'anonymisation au sens du Considérant 26 au niveau document, mais soyez honnête sur les limites : si le document permet encore le singling-out (une petite organisation, un rôle unique, une date spécifique), le statut juridique reste "pseudonymisé en pratique" même sans carte.

L'erreur que nous voyons le plus souvent est l'inverse : un cabinet exécute une passe d'"anonymisation" qui est en réalité un masquage réversible, partage le fichier à l'extérieur, et conserve la carte sur un drive partagé auquel le destinataire finit par avoir accès. Résultat : un enregistrement ré-identifiable sur le serveur d'un tiers. Choisissez le mode en fonction de la destination, pas par habitude.

Redactic expose les deux modes depuis le même upload : un commutateur de réversibilité sur l'écran de chargement et un bouton de confirmation sur le chemin irréversible exigeant une reconnaissance explicite. Le mode réversible supporte les formats text-first end-to-end (TXT, DOCX run-preserving, XLSX cell-preserving, Markdown, JSON, CSV, HTML, XML) ; pour le PDF le chemin réversible format-preserving passe par un intermédiaire en texte brut, choix honnête qui marche pour les workflows d'analyse mais n'est pas un vrai PDF réversible. Pour caviarder PDF ou supprimer données personnelles PDF de manière véritable, Redactic est blackout-only sur PDF, et nous le disons aux clients.

4. Catégories de PII à caviarder avant tout usage IA

Toutes les données personnelles n'ont pas le même poids réglementaire. Le RGPD distingue les "données personnelles" (art. 4(1)) — tout ce qui identifie ou peut identifier une personne physique — des "catégories particulières" (art. 9) telles que données de santé, identifiants biométriques, origine raciale ou ethnique, opinions politiques, convictions religieuses, appartenance syndicale, orientation sexuelle et données génétiques. Pour les catégories particulières la barre de traitement est nettement plus élevée (consentement explicite, intérêts vitaux, intérêt public en santé, etc.) et le risque d'une divulgation involontaire côté LLM est proportionnellement plus grand. La protection des données personnelles sur ces catégories est non négociable.

Le tableau ci-dessous est la shortlist opérationnelle que nous utilisons. Avant qu'un document n'aille à ChatGPT, Claude, Gemini, Mistral ou tout autre fournisseur LLM, chaque ligne ci-dessous doit être soit masquée avec un place-tenant soit noircie, selon que le workflow exige la réversibilité.

Catégorie	Exemples	Pourquoi cela compte
Identifiants directs	Nom complet, email, téléphone, adresse postale	L'ensemble PII minimal ; identification triviale.
Identifiants nationaux	NIR/INSEE français, Codice Fiscale italien, Steuer-ID allemand, DNI/NIE espagnols, numéros de passeport UE	Souvent ratés par les modèles entraînés sur l'anglais. Redactic utilise GLiNER multilingue + regex nationales.
Financiers	IBAN, SWIFT, numéros de carte, compte bancaire, identifiant fiscal/TVA	Déclenchent un risque PCI-DSS adjacent et un risque de fraude direct.
Emploi	ID salarié, ligne de paie, date d'embauche, rémunération, note de performance	Ré-identifiantes dans une petite organisation même sans nom.
Santé (art. 9)	Diagnostics, médicaments, motifs d'arrêt maladie, notes du médecin du travail	Catégorie particulière, consentement explicite ou autre base art. 9 requis.
Biométriques / pièces d'identité	Numéros de carte d'identité, permis, passeport, photographies de visages	Catégorie particulière si utilisés pour identification univoque.
Quasi-identifiants	Date de naissance + code postal + genre, rôle+département exact, titre rare	Utilisés dans les attaques de linkage. Règle de Sweeney à 87 % : CP+DOB+genre ré-identifie la majorité des adultes US.
Divulgations en texte libre	Transcriptions d'entretien de départ, plaintes clients, tickets de support	La catégorie la plus difficile. Échappe souvent aux redactors pattern-based et nécessite un NER ML.

La détection automatique de PII sur les documents en texte libre est le problème dur — la part de la rédaction de documents RGPD qui sépare un vrai produit d'un wrapper de regex. Les regex attrapent IBAN, identifiants fiscaux, emails et téléphones de manière fiable ; elles n'attrapent pas les noms de personnes que vous n'avez jamais entendus en trois langues sur un PDF scanné. C'est là que le choix du modèle compte. Redactic utilise urchade/gliner_multi_pii-v1, un GLiNER multilingue fine-tuné sur les catégories PII qui tourne sur CPU sans bascule de modèle par langue. Les documents sont découpés en fenêtres de 180 mots avec recouvrement pour contourner la troncation GLiNER à 384 sub-tokens — détail subtil mais critique : sans découpage un PDF long perd toute entité au-delà de la page 2.

Pour les PDF scannés et les images, la pipeline exécute d'abord Tesseract OCR avec le pack linguistique eng+ita+fra+deu+spa pour extraire le texte, puis la détection, puis peint le caviardage sur les pixels originaux. C'est ainsi que anonymiser PDF ou noircir PDF fonctionne sur les scans — pas en espérant que le fichier était numérique depuis le début. La qualité sur les scans pivotés ou penchés varie ; Redactic saute les pages fortement pivotées et les remonte pour revue manuelle plutôt que de produire une sortie "confidently-wrong". L'outil anonymisation PDF idéal est celui qui assume cette boucle de revue plutôt que de la cacher.

5. Le workflow en cinq étapes qui passe à l'échelle

La principale raison pour laquelle les programmes de caviardage échouent dans les cabinets professionnels est qu'ils vivent entièrement dans la tête d'un assistant : un rituel ad-hoc Word-et-surligneur qui ne survit pas à la semaine de congés de l'assistant. Le workflow ci-dessous est celui que nous recommandons comme baseline ; c'est le workflow que Redactic implémente end-to-end et celui que nous avons audité contre le principe d'accountability du RGPD.

1. Upload. Dépôt du fichier source (PDF, DOCX, XLSX, image, texte, CSV, HTML, XML, Markdown). Pour les workflows multi-documents, groupez l'upload mais gardez l'audit trail de chaque document séparé. L'upload doit atterrir dans un store chiffré éphémère, pas sur un disque qui survit à la requête. Redactic stocke les inputs en Redis avec chiffrement Fernet et TTL 120 secondes.
2. Détection. Exécutez la cascade : dictionnaire exact-match (pour les rosters connus comme votre liste de clients), regex nationales (NIR français, CF italien, Steuer-ID allemand, DNI/NIE espagnols, IBAN, email), NER multilingue (GLiNER multilingue sur les noms résiduels, organisations, lieux), et fallback OCR pour scans et images. Affichez les spans détectés groupés par catégorie avec scores de confiance.
3. Revue. Montrez à l'utilisateur chaque span avec un toggle conserver/caviarder. La détection recall-biased sur-caviarde volontairement — les faux positifs sont peu coûteux à corriger, les faux négatifs fuient. Laissez l'utilisateur décocher les spans qui ne sont pas réellement des PII (un nom de marque détecté comme personne, un nombre qui ressemble à un identifiant fiscal mais est un code produit) et relancez côté serveur avec keep_values. Cette étape est non négociable pour les workflows juridiques.
4. Application. Choisissez le mode : réversible (carte de place-tenants côté client ou en store serveur éphémère) ou irréversible (noircissement). Pour la réversible, stockez la carte séparément, chiffrée, avec TTL court. Pour l'irréversible, retirez aussi les métadonnées du document (/Info PDF + XMP, core-properties DOCX, properties XLSX) — beaucoup d'échecs de caviardage laissent fuir le nom de l'auteur depuis les propriétés du document alors même que le corps est propre.
5. Partage ou restauration. Téléchargez le fichier masqué, envoyez-le à un LLM, partagez-le avec un tiers. Pour les workflows réversibles, quand la réponse revient, restaurez les valeurs originales à l'intérieur du navigateur de l'utilisateur pour que les vrais noms ne fassent jamais de round-trip à travers le modèle. Pour l'audit, générez un certificat de caviardage SHA-256 listant l'empreinte d'input, l'empreinte d'output, les comptes de caviardage par catégorie, le mode et l'horodatage — mais jamais les valeurs originales. Le certificat est le document que vous produisez si l'autorité demande comment une sortie donnée a été générée.

Le point du certificat mérite l'emphase. Un certificat de caviardage est l'artefact qui transforme "nous avons utilisé un outil de caviardage" en "voici l'enregistrement cryptographique de ce job spécifique". C'est aussi l'artefact qui prouve que vous n'avez pas stocké le document ni ses PII, puisqu'il ne contient que des empreintes et des comptes par catégorie, pas de contenu. Redactic en génère un pour chaque job, téléchargeable en PDF, signé avec la clé applicative.

Un exemple concret : caviarder un tableur de paie. Supposons qu'un cabinet de gestion de paie uploade un XLSX à 12 feuilles avec 80 salariés, des colonnes pour nom, NIR, IBAN, salaire brut, déductions et notes. Un find-and-replace générique corromprait les formules de salaire ; l'édition manuelle au surligneur dans Excel prendrait une demi-journée. Le bon workflow traite les cellules chaîne de chaque feuille via une bibliothèque structurée (openpyxl dans notre stack), laisse intactes les cellules numériques et les formules, et exécute la cascade — lookup dictionnaire sur le roster salariés que le cabinet uploade, regex NIR sur la colonne NIR, regex IBAN sur la colonne bancaire, GLiNER sur la colonne notes pour les noms libres. L'écran de revue affiche 240 spans détectés groupés par colonne ; le reviewer accepte les cartes canoniques et rejette trois faux positifs (un code produit matché comme IBAN, deux noms d'organisation classés comme personnes). L'export est un XLSX avec place-tenants sur les cellules chaîne, formules et cellules numériques intactes, propriétés du document débarrassées du nom du producteur. Le certificat accompagnant logge le SHA-256 de l'input et de l'output, le compte par catégorie (80 noms, 80 NIR, 80 IBAN, 14 noms libres des notes), le mode (réversible) et l'horodatage. Temps total : moins de 60 secondes pour la détection, moins de trois minutes incluant la revue manuelle. La carte est tenue en Redis pour le round-trip LLM et détruite automatiquement à l'expiration du TTL.

6. Shadow AI : pourquoi l'usage aveugle de ChatGPT enfreint le RGPD

La conversation que nous avons le plus souvent avec les clients commence ainsi : "Nous avons interdit ChatGPT pour les données sensibles. Puis nous avons découvert que tout le monde y colle quand même des choses, depuis des comptes personnels, sur leur téléphone, après les heures de bureau." C'est le shadow AI : l'usage d'endpoints LLM publics avec données sensibles, hors de la visibilité IT, typiquement avec les meilleures intentions. C'est le risque IA dominant dans les cabinets professionnels en 2026.

Le shadow AI enfreint le RGPD de trois manières spécifiques. Premièrement, le fournisseur LLM devient un sous-traitant sans Data Processing Agreement. L'article 28 exige un DPA — l'article 28(3) liste les huit clauses minimales — avant tout traitement pour le compte du responsable. Un utilisateur qui colle des noms de clients dans un compte ChatGPT personnel crée un traitement sans DPA, sans registre des activités de traitement (art. 30), sans vetting article 28, sans chaîne de sous-traitants documentée. Le couple ChatGPT RGPD ne tient qu'à condition de basculer sur le tier enterprise avec contrat signé. Deuxièmement, selon les défauts du tier consumer du fournisseur, l'input peut être utilisé pour entraîner le prochain modèle, créant une divulgation irréversible que l'effacement (art. 17) ne peut pas annuler. Troisièmement, les transferts de données franchissent la frontière UE vers un data center US sans que le responsable ait réalisé une transfer impact assessment après Schrems II.

La réponse honnête n'est pas "interdis plus fort". Les utilisateurs contourneront l'interdiction chaque fois que l'outil officiel est plus lent ou pire que le consumer. La réponse est de faire du chemin officiel le chemin de moindre résistance — un chat IA sécurisé qui masque les PII avant que le message ne quitte le navigateur, envoie le texte pseudonymisé à un LLM EU-hosted sous DPA signé, et restaure les valeurs réelles dans la réponse localement. C'est ce que fait Redactic Secure Chat : les PII sont masquées dans le navigateur via la même pipeline de détection que le workflow document, la requête va à OpenAI, Anthropic, Google ou Mistral sur leurs endpoints UE (zero retention, no-train sur l'input), et la restauration se fait côté client de sorte que les valeurs originales ne se posent jamais dans un log serveur où que ce soit.

Ce n'est pas une préoccupation théorique. Samsung a interdit ChatGPT et d'autres outils d'IA générative en mai 2023 après que des collaborateurs auraient saisi dans le chatbot des informations de l'entreprise, dont du code source. La Garante italienne a temporairement suspendu ChatGPT le 30 mars 2023 sur l'art. 6 (base légale), l'art. 13 (notice d'information) et l'absence de vérification d'âge ; le service a été rétabli le 28 avril 2023 seulement après qu'OpenAI a implémenté un âge-gate, un opt-out et une notice d'information explicite. La Garante a ensuite rendu une décision finale le 20 décembre 2024 avec une amende de 15 millions d'euros. En parallèle, l'AEPD espagnole a ouvert une enquête en avril 2023, et l'EDPB a formé une task force dédiée à ChatGPT en avril 2023 qui a publié ses constatations préliminaires en mai 2024. La CNIL IA, dans ses recommandations 2024 sur l'usage des IA génératives en RH, est arrivée à des conclusions très similaires : pseudonymisation préventive, sous-traitance documentée, base légale solide. L'étude Cyberhaven 2023 a trouvé que 11 % des prompts ChatGPT en entreprise contenaient des données sensibles — fiches de paie, code source, informations clients — uploadées depuis l'intérieur des firewalls. L'AI Act UE ajoute des obligations sur les GPAI à partir d'août 2025 qui contraignent davantage l'usage des endpoints LLM consumer dans les contextes régulés. Construire une histoire de privacy IA pour votre cabinet n'est plus optionnel ; c'est la pré-condition opérationnelle à l'adoption IA.

Le motif est cohérent dans chaque incident : la brèche technique est rarement sophistiquée, la réponse de policy est toujours réactive, et le coût est payé par le cabinet dont l'assistant a collé le contrat dans un chatbot gratuit à 23 h. La conformité IA d'entreprise n'est pas un problème top-down de policy ; c'est un problème bottom-up d'expérience utilisateur. Si le chemin sûr est plus lent, le chemin non sûr l'emporte. Redactic Secure Chat est plus rapide que ChatGPT sur le round-trip "masquage-puis-chat" parce que le masquage se fait côté client en millisecondes, le modèle répond en latence normale, et la restauration est locale. L'utilisateur ne perçoit pas une taxe de conformité ; il perçoit un flux plus fluide que l'alternative consumer parce que les réponses arrivent avec les vrais noms déjà restaurés, sans cleanup de copier-coller.

Pour évaluer le risque de shadow AI dans votre propre cabinet, mieux vaut manier avec prudence les statistiques qui circulent : notre audit des statistiques sur le shadow AI les plus répétées remonte chaque chiffre à sa source d'origine et en montre plusieurs qui ne mesurent pas ce pour quoi on les cite d'ordinaire.

7. Choisir un outil de caviardage : checklist 8 points

Si vous achetez un outil ou évaluez une build interne versus un produit sur étagère, la checklist ci-dessous est celle que nous utilisons avec les prospects. Notez chaque item 0-2 (non / partiel / oui) et pondérez les items de posture privacy double. Si vous finissez sous 18 sur 32 possibles, vous avez un risque de conformité ; sous 12, vous avez aussi un risque de productivité.

1. Architecture no-trace. Le service traite-t-il le document en mémoire et le détruit-il immédiatement ? Les inputs sont-ils chiffrés at-rest dans le store éphémère, avec TTL court, et jamais écrits dans un log persistant ? Pourquoi cela compte : une copie stockée reste donnée personnelle — le processus de caviardage lui-même devient une activité de traitement distincte si l'input survit à la requête.
2. Détection PII multilingue. Le modèle gère-t-il NIR français, Codice Fiscale italien, Steuer-ID allemand, DNI/NIE espagnols, PESEL polonais, etc., ou seulement les noms anglais et SSN américains ? Pourquoi cela compte : les détecteurs anglo-centriques manquent 30-50 % des identifiants nationaux sur les documents UE.
3. OCR pour scans. L'outil peut-il caviarder un PDF scanné ou une image de carte d'identité avec un noircissement pixel-perfect ? Pourquoi cela compte : les cas qui effraient le plus votre DPO — vieux contrats, documents photographiés — sont exactement ceux qu'un redactor text-only ne traite pas.
4. Support des deux modes. L'outil peut-il produire des sorties à la fois réversibles (place-tenant) et irréversibles (noircissement) depuis le même upload ? Pourquoi cela compte : les outils mono-mode obligent à maintenir deux pipelines.
5. Revue manuelle. L'UI permet-elle à un humain d'accepter ou de rejeter chaque span détecté avant d'appliquer le caviardage ? Pourquoi cela compte : la détection recall-biased est le bon défaut mais produit des faux positifs qui ont besoin d'un chemin de revue rapide.
6. Strip des métadonnées. L'outil retire-t-il aussi les propriétés du document (auteur, last-modified-by, XMP, EXIF) ? Pourquoi cela compte : la fuite la plus courante en production est un corps propre avec un nom d'auteur dans les propriétés PDF.
7. Certificat d'audit. L'outil génère-t-il un enregistrement cryptographique par job de ce qui a été traité, avec empreintes et comptes par catégorie mais sans contenu ? Pourquoi cela compte : le certificat est ce que vous montrez à l'autorité de contrôle, à l'assureur, au client.
8. Posture conformité. Résidence des données UE, DPA inclus au signup, registre des sous-traitants, consentement click-wrap avec snapshot cryptographique, séparation des rôles (votre outil agit comme sous-traitant, pas comme responsable). Pourquoi cela compte : ce sont les items qui déterminent si l'outil s'insère dans votre programme RGPD existant ou crée de nouvelles activités de traitement qu'il faut désormais gouverner.

Les outils livrés comme extension Chrome peuvent être élégants mais scorent mal sur (1) et (8) — il y a rarement un vrai DPA derrière une extension gratuite. Les bibliothèques open source comme Presidio ou Piiranha scorent bien sur (2) mais vous héritez de l'empreinte opérationnelle (no-trace, OCR, audit, certificat) qui est l'essentiel du travail. Les outils commerciaux hébergés varient ; la question à poser n'est pas "avez-vous une fonctionnalité appelée caviardage ?" mais "montrez-moi le certificat d'un job exemple et la liste des sous-traitants".

Build vs buy. L'argument du construire-en-interne vient en général de CTO qui notent que GLiNER, Tesseract et la couche regex nationales sont tous open source. L'argument a raison sur les composants et tort sur le coût total. Le vrai travail n'est pas le moteur de détection — c'est un prototype d'un week-end — mais la couche opérationnelle : un store éphémère chiffré avec discipline TTL qui survit aux crashs, une UI de revue manuelle qui gère des milliers de spans sans achever le navigateur, un générateur de certificat de caviardage qui signe avec une clé stable, un stripper de métadonnées qui gère les idiosyncrasies de chaque producteur PDF, un workflow DPA avec capture du consentement click-wrap, un flux de notification de changement de sous-traitant, et la maintenance continue pour suivre les nouveaux identifiants nationaux, les nouvelles langues OCR, les nouveaux endpoints LLM. La valeur du vendeur est rarement le modèle ; c'est la discipline autour du modèle.

Redactic a été conçu contre cette checklist dès le jour un : no-trace by design (Redis chiffré Fernet avec TTL 120s/300s, pas de modèles DB, pas de logs de contenu), GLiNER multilingue avec fallback regex nationales, Tesseract OCR avec pack linguistique cinq langues, modes réversible et irréversible, console de revue manuelle, stripper de métadonnées sur PDF/DOCX/XLSX, certificat SHA-256 d'audit avec PDF téléchargeable, résidence UE sur Hetzner Helsinki et Cloudflare R2 juridiction UE, DPA signé au signup avec snapshot consentement click-wrap, et rôle explicite de sous-traitant dans les pages trust. Le DPA et la liste des sous-traitants sont publics ; l'architecture est documentée ; le certificat de caviardage est téléchargeable depuis le tableau de bord pour chaque job.

Caveats honnêtes : le caviardage réversible pour PDF dans Redactic passe par un intermédiaire en texte brut (le vrai PDF est blackout-only) ; le chemin OCR blackout n'a été testé end-to-end dans le navigateur qu'au déploiement de production de juin 2026 ; dans les cas de nom multi-forme ("Marie Dupont" et le partiel "Marie" plus loin dans le document), la règle côté serveur de maintien comme forme canonique peut laisser un masque partiel que l'UI client montre comme conservé. Nous le disons aux prospects à la première conversation, pas après le contrat.

8. Questions fréquentes

Quelle est la différence entre caviardage et anonymisation ?

Le caviardage est l'opération ; l'anonymisation est l'un des résultats possibles. Le caviardage peut produire une sortie pseudonymisée (réversible, RGPD art. 4(5)) ou anonymisée (irréversible, Considérant 26). L'anonymisation retire les données du champ RGPD entièrement ; la pseudonymisation les garde dedans mais réduit le risque.

La pseudonymisation est-elle la même chose que le chiffrement ?

Non. Le chiffrement est réversible par quiconque a la clé et est un contrôle de sécurité ; la pseudonymisation remplace les valeurs identifiantes par des place-tenants et garde la carte de retour sous contrôle d'accès plus strict. Le RGPD reconnaît expressément la pseudonymisation à l'art. 4(5) et à l'art. 32(1)(a) ; des données personnelles chiffrées restent des données personnelles.

Puis-je utiliser ChatGPT avec des documents caviardés en sécurité sous RGPD ?

Oui, à deux conditions. Premièrement, le caviardage doit se faire avant que le document quitte votre environnement — masquer après l'upload vers ChatGPT n'aide pas. Deuxièmement, l'endpoint LLM devrait idéalement être le tier UE/enterprise avec DPA signé et défauts no-train. Un chat IA sécurisé qui masque les PII dans le navigateur avant la requête et restaure les valeurs réelles dans la réponse localement est le motif le plus propre.

La détection PII automatique fonctionne-t-elle sur les PDF scannés ?

Seulement si l'outil exécute l'OCR d'abord. Un redactor qui ne gère que le texte numérique produira silencieusement un scan "caviardé" avec toutes les PII intactes. Tesseract avec le bon pack linguistique est le chemin open-source standard ; l'OCR commercial cloud existe mais introduit un sous-traitant qui a besoin de son propre DPA. Redactic exécute Tesseract sur le worker avec le pack eng+ita+fra+deu+spa. Si vous cherchiez "anonymiser PDF" ou "caviarder PDF" en espérant une solution un-clic, la réponse honnête est que les scans ont besoin d'OCR avant tout masquage — et la qualité OCR borne la qualité du caviardage.

Combien de temps la carte de place-tenants doit-elle être conservée ?

Le temps strictement nécessaire au workflow. Pour un round-trip LLM la carte n'est nécessaire qu'entre la requête et la réponse — minutes, pas jours. Redactic utilise 120 secondes sur le store input et 300 secondes sur le store output. Pour un dossier multi-documents la carte peut devoir vivre pour la durée du dossier, auquel cas elle doit être chiffrée at-rest, access-logguée, et explicitement listée dans votre registre des activités de traitement.

Qu'est-ce que le shadow AI et pourquoi est-ce un problème RGPD ?

Le shadow AI est l'usage d'endpoints LLM publics avec des données sensibles, hors de la visibilité IT, typiquement via des comptes personnels. Il crée du traitement sans DPA (art. 28), des transferts internationaux non documentés (Schrems II), et une exposition possible à l'entraînement de l'input. La mitigation n'est pas une interdiction plus stricte — les interdictions sont contournées — mais un chemin officiel plus rapide et plus sûr que le shadow.

L'AI Act change-t-il quelque chose au caviardage ?

Oui. Les systèmes IA haut-risque sous l'annexe III (RH, recrutement, évaluation de la performance) doivent respecter les obligations de gouvernance des données (art. 10), gestion des risques (art. 9), supervision humaine (art. 14). Pseudonymiser les données d'input avant de les donner à un tel système est le moyen le plus propre de satisfaire en même temps la minimisation sous art. 5 RGPD et l'art. 10 AI Act. L'AI Act n'exige pas explicitement le caviardage mais le récompense opérationnellement.

Qu'est-ce qu'un certificat de caviardage et pourquoi en ai-je besoin ?

Un enregistrement cryptographique d'un job de caviardage : empreinte d'input, empreinte d'output, mode, comptes de caviardage par catégorie, horodatage, signature applicative. Il ne contient pas de contenu ni de PII, donc est sûr à stocker et à partager. Vous en avez besoin pour démontrer l'accountability de l'art. 5(2) — que vous pouvez montrer comment une sortie donnée a été générée des mois plus tard, sans conserver le document.

Puis-je caviarder une feuille Excel avec des données salariés sans casser les formules ?

Oui si l'outil comprend la différence entre une cellule chaîne et une cellule nombre/formule. Le find-and-replace générique casse les formules. Redactic traite les cellules chaîne par feuille via openpyxl en laissant intacts les nombres, les formules et le formatage — c'est le workflow que nous utilisons pour les fichiers de paie multi-salariés et celui que le travail récent multi-feuilles sur le caviardage par colonne raffine.

Où Redactic stocke-t-il mes données ?

Nulle part de manière persistante. Les documents vivent en Redis avec chiffrement Fernet et TTL court pendant le job, et sont détruits par le bloc finally du worker quel que soit le résultat. L'application n'a pas de modèle DB pour le contenu du document. Le certificat de caviardage ne stocke qu'empreintes et comptes. Compute et stockage de métadonnées sont UE (Hetzner Helsinki + Cloudflare R2 juridiction UE). La liste des sous-traitants et le DPA sont publics sur les pages trust.

Si vous ne lisez qu'une chose de ce guide, lisez la section 6 sur le shadow AI. Le seul risque le plus grand dans votre cabinet en 2026 n'est pas un caviardage manuel raté ; c'est l'effet cumulé de mille petits copier-coller ChatGPT depuis des comptes personnels. La réponse n'est pas des règles plus strictes — elles seront contournées — mais un chemin officiel plus rapide avec un caviardage correct et un DPA signé. Construisez le chemin avant que le régulateur ne le construise à votre place.

Si vous voulez voir comment cela fonctionne en pratique, la landing Redactic guide à travers les quatre modes d'usage (Caviarder, Anonymiser, Utiliser avec IA, Chatbot sécurisé) avec une démo live sur un contrat exemple. Le plan Solo couvre un professionnel seul à 19 €/mois ; le plan Firm ajoute le chat IA sécurisé et jusqu'à cinquante sièges à 49 €/mois ; Enterprise est sur mesure. Le DPA est signé au signup et le certificat de caviardage est téléchargeable depuis chaque job complété.