Audit de désensibilisation des informations personnelles (privacy-audit)

Utilisation

Effectue un audit de conformité et de désensibilisation des informations personnelles sur des packages de compétences locales, des bases de code ou des répertoires de données, produisant une liste de problèmes classés et un rapport d'audit standardisé. Basé sur le droit chinois : Loi sur la protection des informations personnelles (Décret présidentiel n° 91), Loi sur la sécurité des données, Loi sur la cybersécurité (révision 2025), GB/T 35273-2020, GB/T 45574-2025 (en vigueur à compter du 2025-11-01), GB/T 43697-2024, Règles de gestion de l'audit de conformité de la protection des informations personnelles (en vigueur à compter du 2025-05-01), etc. L'audit est strict : tout traitement sans justification claire est considéré comme interdit.

Scénarios d'application : vérification de sécurité avant la publication d'une compétence IA / code / document, vérification de désensibilisation avant le partage d'un jeu de données, inspection des fuites de journaux et de configuration, production de rapports d'audit de conformité. Distinction de positionnement : Ce skill est un « outil d'audit / inspection » (détection + classification + recommandations + index des références), PAS un « exécuteur de désensibilisation ». Pour les scénarios nécessitant un masquage/remplacement direct des données, utilisez un skill de désensibilisation ; ce skill est responsable de déterminer au préalable « si l'on doit publier, où se situe la violation, et sur quelle réglementation se baser ». Positionnement commercial (v1.2.0) : Destiné au scénario « auto-vérification de conformité avant la publication d'une compétence / application IA », compatible avec les plateformes de dialogue comme Coze (l'utilisateur peut télécharger une pièce jointe ou coller du texte pour une analyse sans répertoire local), et peut être publié en tant que skill payant.

Mots déclencheurs

Audit de désensibilisation / Audit de vie privée / Vérification de conformité de la vie privée / Audit de conformité / Audit de protection de la vie privée / privacy audit / desensitization audit
Scan d'informations sensibles / Scan PII / PII scan / Détection de champs sensibles / Scan d'informations personnelles / Inspection des fuites de données
Scanne ce répertoire pour voir s'il contient des informations personnelles / Scanne ce skill pour voir s'il contient des informations personnelles
Scan de numéro de carte d'identité / Vérifier si le code contient des numéros de téléphone / Vérifier si le code contient des numéros de carte d'identité / Vérification des fuites de numéros de carte bancaire
Y a-t-il des clés en dur dans le dépôt ? / Y a-t-il des mots de passe en clair dans les journaux ? / Le fichier téléchargé contient-il des informations sensibles ?
Ce skill fuit-il la vie privée ? / Ce skill peut-il être publié ? / Faut-il désensibiliser avant le partage ? / Vérification de désensibilisation du jeu de données
Suggestion de rectification de désensibilisation / Générer un rapport d'audit de conformité / Vérification de sécurité avant publication / Examen de conformité avant mise en ligne

Préparation de l'environnement

# Dépendances : Python 3.8+, bibliothèque standard uniquement, aucune dépendance tierce
export SKILL_DIR=~/.workbuddy/skills/privacy-audit   # Chemin d'installation du skill
export TARGET_DIR=/path/to/待审查目录                  # Répertoire à auditer (code / skill / données)
export REPORT_DIR=/path/to/报告输出目录                # De préférence en dehors du répertoire scanné pour éviter l'auto-détection

Processus d'exécution

Étape 1 : Scan automatique L1 (d'abord la machine, puis l'humain)

# Scan d'un seul répertoire + rapport JSON
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json"

# v1.1.0 Scan par lots de plusieurs répertoires (audit combiné) + rapport HTML visuel
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR_A" "$TARGET_DIR_B" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json" \
  --html "$REPORT_DIR/audit_result.html"

Scanne 17 types de champs sensibles : Numéro de carte d'identité / Numéro de téléphone / Numéro de carte bancaire / Email / IP / Adresse exacte / Coordonnées de localisation précises / Nom du médecin / Nom de l'établissement hospitalier / Mot de passe en clair / Informations médicales et de santé / Informations sur les mineurs / Numéro de plaque d'immatriculation / Numéro de passeport / ID WeChat / Numéro QQ / Code d'identification sociale unifié (nouveau en v1.1.0)
Détecte 5 types de credentials en dur : Clé SkillHub / Token GitHub / Clé OpenAI / SecretId Tencent Cloud / Identifiant temporaire COS
Codes de sortie (intégration CI) : 0 = Réussi ; 1 = Détection haute criticité (publication interdite) ; 2 = Détection criticité moyenne (validation humaine requise)
--json : Rapport structuré (contient scanned_roots / summary / verdict / findings, consommable par CI) ; --html : Rapport visuel autonome (carte de synthèse + graphique de distribution par niveau + liste des détections groupées par fichier, consultable hors ligne)
--strict : Les détections de niveau moyen sont également considérées comme un échec ; --quiet : N'affiche que la ligne de résultat

Scan en mode dialogue (nouveau en v1.2.0, adapté aux scénarios de dialogue comme Coze, sans répertoire local) :

# Scan d'un seul fichier (pièce jointe téléchargée par l'utilisateur, ex. .py / .md / .json / .txt, etc.)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --file /path/to/uploaded.py \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json" \
  --json "$REPORT_DIR/audit_result.json"

# Scan d'un contenu textuel (code / fragment de texte collé par l'utilisateur)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --text "Texte à auditer" \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json"

# Scan via l'entrée standard (pipe)
echo "Texte à auditer" | python3 "$SKILL_DIR/scripts/privacy_audit.py" --stdin \
  --rules "$SKILL_DIR/scripts/字段检测正则库.json"

Étape 2 : Audit complet L2 (vérification humaine sur six dimensions)

Basé sur references/个人信息脱敏审查规范.md, vérifier dimension par dimension :

Identification et classification : La liste des champs est-elle complète ? Marquage du niveau de sensibilité ? Risque de réidentification combinatoire ? Marquage spécial pour les mineurs ?
Méthode et scénario de désensibilisation : Le choix entre désidentification / anonymisation est-il adapté au niveau de sensibilité ? (irréversible prioritaire ; réversible nécessite un contrôle strict des clés)
Désensibilisation au niveau du champ : Vérification champ par champ pour les quatre étapes (stockage / affichage / transmission / partage) (points clés : carte d'identité / carte bancaire doivent être stockées cryptées ; interface masquée par défaut ; les journaux ne doivent pas contenir de données en clair)
Processus et liste de vérification : Cochez les 33 éléments un par un (A Identification préalable 5 / B Stockage 6 / C Affichage 6 / D Journaux 4 / E Partage 5 / F Tests 2 / G Garanties techniques 6)
Inspection des scénarios de violation : Vérifiez les 15 scénarios de violation courants un par un (stockage en clair, interface non masquée, collecte excessive, consentement coché automatiquement, reconnaissance faciale obligatoire, journaux en clair, fuite non notifiée, divulgation et vente, transferts transfrontaliers non évalués, etc.)
Vérification des références de conformité : Suivez la partie 6 de la norme pour les noms des réglementations / numéros de documents / dates et les numéros des normes nationales, sans modification.

Étape 3 : Correction et validation

Risque élevé (P0) : Correction obligatoire → Supprimer les credentials en dur (variables d'environnement / gestion de clés) ; données sensibles en clair → cryptage du stockage + masquage de l'affichage
Après la correction, relancez le scan L1 pour confirmer que le code de sortie est tombé à 0 (ou qu'il ne reste que des risques faibles)
Risque moyen (P1) : Recommandé pour la prochaine itération ; Risque faible (P2) : Enregistré pour une optimisation ultérieure

Étape 4 : Génération du rapport standardisé

Basé sur references/审查报告模板.md pour la structure du rapport : Objet de l'audit et profil des données → Synthèse des résultats → Liste des problèmes classés (P0/P1/P2) → Vérification des éléments de conformité → Priorité de correction → Tableau comparatif des listes de vérification → Conclusion et clause de non-responsabilité.

Liste des dépendances

Python 3.8+ (bibliothèque standard : argparse / json / os / re / sys)
Aucune dépendance tierce ; optionnellement, --json produit un rapport structuré pour consommation par CI

Limites et sécurité (lignes rouges)

Ne constitue pas un avis juridique : Les conclusions du rapport doivent être interprétées en fonction du contexte métier spécifique ; pour les scénarios à haute sensibilité, une relecture humaine et la consultation d'un avocat spécialisé en conformité sont recommandées.
Rapport généré en dehors du répertoire scanné : Évite que le rapport d'audit ne soit lui-même détecté, et évite qu'il ne se retrouve dans les artefacts à publier.
Entièrement local : N'utilise aucune API cloud, ne transmet aucun contenu audité.
Fichiers binaires ignorés : .zip / .png / .pdf / .docx / .xlsx / .pyc, etc. ne sont pas analysés (extraction ou conversion en texte nécessaire au préalable).
Interdiction de supprimer : Ce skill ne fait que signaler, il ne supprime ni ne modifie aucun fichier audité.

Pièges intégrés (leçons apprises, ne pas répéter)

Piège	Cause racine	Solution (intégrée dans le script)
Constantes de coordonnées / chaînes numériques longues aléatoires faussement détectées comme carte d'identité / carte bancaire	La regex pure ne correspond qu'à la « forme » sans vérifier la « validité »	Validation de la somme de contrôle des cartes d'identité (MOD 11-2), vérification Luhn pour les cartes bancaires ; si échoué, saut du faux positif
Les chiffres internes d'une carte d'identité sont détectés secondairement par la regex du téléphone / carte bancaire	Conflit de priorité des regex	Déduplication d'intervalle : si l'intervalle de détection est entièrement contenu dans une détection de priorité supérieure, saute (ex. les 6 premiers chiffres 110101 ne sont pas faussement détectés comme un téléphone)
Chaîne numérique longue (ex : constante de coordonnée 0.00669342162296594323) dont une sous-chaîne détectée comme téléphone	Regex du téléphone sans limites	Ajout de limites avant/après `(?<![0-9])…(?![0-9])` à la regex du téléphone
Le rapport d'audit écrit dans le répertoire scanné est lui-même détecté	Le rapport contient des « exemples de détections »	Sortie du rapport en dehors du répertoire scanné (--json pointe vers un répertoire externe)
Encodage des fichiers chinois sous Windows problématique	Les fichiers peuvent être en GBK plutôt qu'UTF-8	`read_text` essaie d'abord UTF-8, puis décode en fonction du ratio de caractères imprimables
Gros répertoires (node_modules / .git) ralentissent le scan	Aucun filtre, tout est scanné	SKIP_DIRS intégré (.git / pycache / node_modules / .venv / dist / build, etc.)
Comportement du script incohérent après ajout de nouveaux champs dans le fichier JSON de règles	Désynchronisation entre le fichier de règles et le script	Le fichier JSON de règles est la seule source de vérité, le script le charge dynamiquement ; pour ajouter un nouveau type de champ, modifiez d'abord le JSON puis exécutez le script
Le texte de définition du motif dans le fichier JSON de règles est lui-même détecté (ex. le mot « 人民医院 » apparaît dans la regex du nom de l'hôpital)	La définition de la règle est elle-même un échantillon de mot sensible	C'est un phénomène normal ; lors de l'auto-audit, si cette détection apparaît, confirmez manuellement qu'il s'agit de la définition du motif et ignorez-la (orientation conservatrice : mieux vaut une REVUE qu'un oubli)
« 北京市A12345 » (nom de lieu + chiffres) faussement détecté comme plaque d'immatriculation	Regex de plaque sans limites, la sous-chaîne « 京A12345 » est détectée	Ajout de limites de caractères avant/après `(?<!…)(?<![\u4e00-\u9fa5])…(?![…])` à la regex de plaque, double vérification par validateurs structurels (province + lettre + longueur 7/8)
Chaîne numérique aléatoire de 18 chiffres a environ 1/31 de chance de passer la validation GB 32100 du code d'identification sociale unifié (USCC)	La somme de contrôle modulo 31 a une probabilité naturelle de passer pour une chaîne aléatoire	USCC est classé comme « criticité moyenne » (REVUE nécessite confirmation humaine) plutôt que haute criticité, précisément pour cette raison ; les tests négatifs utilisent de vrais faux derniers chiffres
Auto-détection des étiquettes d'exemples de test (ex : « pseudo ID WeChat : xxx » détecté par la regex d'ID WeChat)	L'étiquette elle-même contient le préfixe déclencheur + un format valide	C'est un comportement correct (dans un scénario réel, « ID WeChat : xxx » doit être détecté) ; lors de la conception des exemples de test, évitez de reproduire le préfixe déclencheur dans l'étiquette
Les cas de test dans `evals/` contiennent des échantillons fictifs sensibles, ce qui fait que `preflight --strict` signale des alertes phone/email	Les cas de test doivent avoir une forme réelle pour tester la capacité de détection, mais la sonde de sensibilité de la passerelle de publication ne fait pas la distinction entre vrai et faux	Lors de l'auto-vérification de la publication, utilisez `--waive phone --waive email --reason "Les cas de test evals contiennent des échantillons fictifs, pas de véritables informations personnelles"` pour exonérer et laisser une trace ; supprimez `.preflight-waiver.json` avant la publication ; la première ligne des fichiers d'échantillons doit être marquée uniformément « Données de test fictives »
Chaîne numérique aléatoire de 18 chiffres (ex : horodatage + numéro de séquence) a environ 1/11 de chance de passer la validation MOD 11-2 de la carte d'identité et d'être faussement détectée	La somme de contrôle ne garantit que la validité, pas l'authenticité ; une chaîne aléatoire a une probabilité naturelle de passer	Il s'agit d'une limitation connue : après confirmation manuelle qu'il s'agit d'un numéro de séquence / horodatage / numéro de série, ignorez-la ; ne relâchez pas la regex (mieux vaut une REVUE qu'un oubli)

Exemples d'utilisation (simulation de dialogue)

Utilisateur : Vérifie pour moi le répertoire ~/projects/skill-demo, est-ce qu'il peut être publié ?
Agent :
  1. Exécute le scan L1 :
     python3 ~/.workbuddy/skills/privacy-audit/scripts/privacy_audit.py ~/projects/skill-demo \
       --rules ~/.workbuddy/skills/privacy-audit/scripts/字段检测正则库.json --json ~/reports/demo_audit.json
  2. Code de sortie 1 → 2 détections haute criticité (token GitHub en dur + carte d'identité en clair) → Publication interdite
  3. Vérification L2 sur six dimensions selon les « Règles d'audit » : stockage non crypté, affichage non masqué, journaux contenant du texte en clair…
  4. Génération de la liste des problèmes classés (H-1 token en dur / H-2 stockage de carte d'identité en clair / M-1 journaux en clair…)
  5. Recommandations de correction + rapport standardisé → Utilisateur corrige puis relance L1 → Code de sortie 0 → Publication autorisée

Documents de référence

references/个人信息脱敏审查规范.md : Spécification complète sur six dimensions (couches L1/L2, liste de 33 éléments, 15 scénarios de violation, index de 18 réglementations + 6 normes nationales, annexe sur les outils) — Seule source de vérité pour l'exécution de l'audit
references/个人信息脱敏审查要点.md : Points clés des six dimensions (contexte réglementaire et explications détaillées des dimensions de jugement ; la source est officielle = lois, réglementations et normes nationales, consensus communautaire = cas publics d'application de la loi / de jurisprudence et pratiques sectorielles)
references/审查报告模板.md : Modèle de structure de rapport standard L2
references/Changelog.md : Seule source de vérité pour l'historique des versions (journal complet des modifications de la version 1.0.0 à la version actuelle et explications des plages de versions)
evals/ : Ensemble de tests de régression (10 cas de test exécutables + jeu d'intentions des mots déclencheurs trigger_eval.json), exécutez-le après toute modification de ce skill pour vérifier que les capacités existantes ne sont pas altérées ; voir evals/README.md pour la méthode d'exécution

Version et sources de vérité

Le numéro de version actuel est celui du version dans le frontmatter du SKILL.md ; les tags de publication, le résumé de version dans le README et l'entrée de version actuelle dans references/Changelog.md doivent tous être alignés.
Les modifications historiques sont uniquement basées sur references/Changelog.md comme source de vérité. Les journaux de modifications dans SKILL.md et README ne sont que des résumés des deux dernières versions + un lien vers ce fichier ; n'enregistrez pas un historique complet à plusieurs endroits — une redondance sur trois emplacements entraînera inévitablement une divergence.
Les mentions « nouveau en v1.1.0 » / « nouveau en v1.2.0 » dans le texte sont des annotations d'appartenance de fonctionnalité : elles indiquent la version dans laquelle la fonctionnalité est apparue pour la première fois, il s'agit d'un enregistrement historique et ne doit pas être modifié en fonction du numéro de version actuel (la version actuelle est la 1.3.0, l'annotation reste inchangée).
Le "version": "1.1.0" dans scripts/字段检测正则库.json est la version de la bibliothèque de règles : indépendante de la version du skill, elle n'est incrémentée que lorsque les types de champs / regex / validateurs changent réellement. La version 1.2.0 n'a modifié que les points d'entrée de scan (--file / --text / --stdin), pas les règles, donc la bibliothèque de règles reste en 1.1.0 — c'est l'état correct, pas une erreur de frappe ; ne « réalignez pas » par souci de cohérence.

Journal des modifications

Voir references/Changelog.md pour l'historique complet des versions (seule source de vérité). Le tableau ci-dessous présente un résumé des deux dernières versions.

Date	Version	Type de modification	Contenu de la modification	Source
2026-09-06	1.3.1	Optimisation	Ajout de balises internes (protection de la vie privée / désensibilisation / PII / protection des informations personnelles, etc., 6 au total), aucune modification fonctionnelle	Optimisation SkillHub
2026-08-29	1.3.0	Optimisation	Couverture des mots déclencheurs de 58 % à 100 % (ajout de 16 intentions dans `evals/trigger_eval.json` + extension du cluster de mots déclencheurs à 30 entrées) ; description réduite de 444 à 238 caractères, les détails sont descendus dans le texte principal ; ajout de 10 cas de test exécutables dans `evals/` (score moyen 1.00 avec `--run --aggregate`) ; ajout de `references/Changelog.md` ; établissement du périmètre des deux sources de vérité (version et historique des versions)	Correction suite au rapport de santé
2026-08-19	1.2.0	Nouveauté	Ajout des points d'entrée de scan `--text / --stdin / --file` pour fichier unique / texte (adaptés à une saisie dialoguée comme Coze, sans répertoire local) ; recentrage du positionnement sur « passerelle de conformité avant publication » ; ajout d'une description du positionnement commercial	Adaptation pour la publication sur Coze

(Pour les entrées de la version 1.1.0 et antérieures, voir references/Changelog.md)

Clause de non-responsabilité

Ce skill est généré avec l'aide de l'IA et est fourni à titre indicatif uniquement. Il ne constitue pas un avis juridique formel et ne remplace pas un avocat qualifié. Le jugement de conformité spécifique doit être effectué en fonction du contexte métier et en consultant des professionnels du droit, en se basant sur les lois et réglementations en vigueur les plus récentes.

johnsmithCA-sta/privacy-audit

Qu'est-ce que privacy-audit ?

Demander à votre IA préférée

Documentation