L'Exigence Air-Gapped
Les entrepreneurs de défense, les agences de renseignement gouvernementales et les opérateurs d'infrastructures critiques gèrent des réseaux où la connectivité Internet externe est physiquement impossible, et non simplement interdite par la politique. Un SCIF (Sensitive Compartmented Information Facility) est une pièce ou un établissement conçu pour prévenir l'écoute électronique et la collecte de renseignements par signaux — il est en cage de Faraday, sans signaux sans fil entrant ou sortant. Un réseau gouvernemental classifié sous le contrôle de l'ITAR (International Traffic in Arms Regulations) ne peut pas transmettre des données techniques couvertes à des parties non approuvées — une catégorie qui inclut les fournisseurs de services cloud non autorisés sous l'ITAR.
Pour les organisations dans ces environnements, "SaaS cloud" n'est pas un risque à gérer — c'est une impossibilité technique. Tout outil d'anonymisation nécessitant une connexion réseau active ne peut pas être déployé. Tout outil qui se connecte pour vérifier la licence est un non-démarreur. Tout outil dont les modèles de détection nécessitent des appels API cloud pour l'inférence ne peut pas fonctionner.
La communauté Ollama cite spécifiquement le déploiement air-gapped comme la principale justification pour les outils d'IA locaux : "Toutes les données restent sur votre appareil avec Ollama, sans information envoyée à des serveurs externes — particulièrement important pour des travaux sensibles comme les médecins traitant des notes de patients ou les avocats examinant des dossiers de cas." La même logique s'applique au niveau organisationnel pour les environnements classifiés et contrôlés par l'ITAR.
Le Cas d'Utilisation ITAR
Un data scientist chez un entrepreneur de défense traitant des dossiers de personnel sous les exigences de l'ITAR doit dé-identifier des fichiers avant de les partager avec un journaliste demandant des informations en vertu de la FOIA. Le réseau de l'entrepreneur est air-gapped. Le traitement doit avoir lieu sur la machine air-gapped et doit produire des résultats adaptés à une publication publique.
Ce cas d'utilisation n'a pas de solution cloud. Le seul chemin est un outil qui fonctionne entièrement sur la machine locale, applique des modèles de détection stockés localement et produit des résultats anonymisés sans aucune communication externe. L'application de bureau basée sur Tauri 2.0 fonctionne exactement dans cette configuration : après téléchargement et installation, aucun appel réseau n'est effectué pendant le traitement des documents. Les modèles NER de spaCy, les motifs regex et l'inférence des transformateurs s'exécutent localement. La sortie de traitement ne quitte jamais la machine à moins d'être explicitement exportée par l'utilisateur.
Pseudonymisation Réversible pour les Opérations Classifiées
Une exigence connexe dans les contextes classifiés et gouvernementaux : la pseudonymisation réversible qui maintient l'utilité analytique tout en protégeant les vraies identités. L'Article 4(5) du RGPD reconnaît formellement la pseudonymisation comme une mesure de protection des données qui réduit le risque de conformité — les données pseudonymisées sont soumises à des obligations réduites par rapport aux données entièrement identifiables, à condition que les clés de pseudonymisation soient conservées séparément de l'ensemble de données pseudonymisées.
La recherche de l'IAPP (2024) a révélé que seulement 23 % des outils d'anonymisation offrent une véritable réversibilité — la capacité de déchiffrer des données pseudonymisées en valeurs originales à l'aide d'une clé conservée séparément de la sortie. La majorité des outils mettent en œuvre un remplacement permanent (les données originales sont écrasées et ne peuvent pas être récupérées) ou un masquage (affichage partiel de la valeur originale).
Pour les opérations gouvernementales où les ensembles de données pseudonymisées doivent être partageables entre compartiments — une équipe reçoit l'ensemble de données pseudonymisées pour un travail analytique, une autre équipe détient la clé de déchiffrement pour la ré-identification lorsque cela est légalement requis — le chiffrement réversible avec séparation des clés est la seule architecture conforme.
L'approche de connaissance nulle étend cela encore plus loin : la clé de chiffrement est générée côté client et n'est jamais transmise. Même si le fournisseur de l'outil d'anonymisation était assigné à comparaître, il ne peut pas produire la clé de déchiffrement car il ne l'a jamais reçue. Pour les environnements classifiés où la chaîne de custody pour les clés de chiffrement est elle-même une exigence de sécurité, cette architecture fournit l'assurance requise.
Conformité aux Directives de l'EDPB
Les Directives 05/2022 de l'EDPB sur la pseudonymisation exigent la séparation des clés : la clé de pseudonymisation doit être détenue par une partie différente de celle recevant l'ensemble de données pseudonymisées, ou stockée avec des contrôles techniques qui empêchent la partie recevant les données d'accéder à la fois aux données et à la clé simultanément.
La combinaison de la génération de clés côté client (la clé ne quitte jamais l'appareil de l'utilisateur), du traitement local (les données ne quittent jamais l'environnement air-gapped), et de l'exportation séparée des sorties pseudonymisées et des clés de déchiffrement satisfait l'exigence de séparation des clés de l'EDPB tout en respectant la contrainte opérationnelle air-gapped.
Sources :