Ce que le scan détecte — et ce qu’il ne voit pas

Quand l’analyse a lieu

Par défaut, elle n’a pas lieu. Le contenu part en ligne tel quel, ce qui rend la publication immédiate — c’est le comportement depuis le 28 août 2026. L’analyse se demande explicitement : pii_mode à la création ou à la mise à jour via l’API, la case « Analyser le contenu » dans l’interface, scan:true depuis un agent. Une organisation peut l’imposer à toutes les publications de son espace, et ce réglage-là ne peut pas être desserré par un appel.

Le rapport distingue les deux situations : skipped dit qu’aucune analyse n’a eu lieu, et ne se confond pas avec clean, qui dit qu’on a cherché sans rien trouver. Sur une mise à jour partielle, seuls les fichiers poussés sont analysés ; le rapport le déclare par sa portée.

Ce qui reste appliqué à toute publication, analyse ou non : le refus des chemins sensibles — .env, id_rsa, *.pem, .git/ — dès la déclaration, avant qu’un seul octet ne soit transféré. Ce contrôle porte sur les noms de fichiers, jamais sur leur contenu.

Moment du contrôle, quand il est demandé

Les fichiers sont d’abord envoyés directement vers l’Object Storage au moyen d’URLs pré-signées. Lors de la finalisation, le service ouvre chaque fichier pris en charge et exécute les détecteurs. Les détecteurs bloquants balayent le fichier entier en flux, sans plafond de taille : le contenu défile par fenêtres successives, il n’est pas chargé en mémoire d’un bloc. Le scan est synchrone : le budget commenté de 500 ms par Mio ne déclenche pas encore de bascule asynchrone.

Un contenu bloqué reste en quarantaine et ne reçoit pas de slug publiable. Dans l’implémentation actuelle, cette quarantaine n’obtient pas automatiquement une date de purge : le publieur doit supprimer explicitement la publication bloquée avec son identifiant. Ce point reste à durcir pour éviter un stockage orphelin.

Le rapport indique le statut, le mode appliqué, le nombre de fichiers et d’octets effectivement scannés, la durée, les catégories détectées et au plus 20 positions par catégorie. La valeur trouvée n’est jamais enregistrée dans le rapport ; une empreinte temporaire en mémoire sert uniquement à dédupliquer les occurrences.

Détecteurs actifs

Modes warn et block

Warn est le mode par défaut : NIR valides et secrets techniques bloquent toujours ; IBAN, cartes, emails et téléphones sont signalés sans empêcher la publication.

Block, disponible selon l’offre et la policy du workspace, transforme aussi ces avertissements en refus de publication. Les informations de niveau info ne changent jamais le verdict.

Formats effectivement analysés

Le scanner prend en charge les formats texte usuels : HTML/XHTML, texte et Markdown, CSV/TSV, JSON, XML, YAML, TOML, JavaScript/TypeScript, CSS, SVG, SQL, logs et fichiers de configuration, ainsi que certains fichiers sans extension comme .env, Dockerfile, .npmrc et .netrc.

• HTML et SVG : le code brut et le texte débarrassé des balises sont analysés.
• PDF : seules les chaînes textuelles littérales non compressées sont extraites, et l’extraction reste plafonnée — le parseur a besoin du document entier, il ne peut pas travailler en flux. Un PDF traité partiellement est nommé dans le rapport.
• Fichier UTF-8 invalide ou binaire : il est ignoré pour éviter des faux positifs sur des octets aléatoires.
• Image, audio et vidéo : aucun OCR ni transcription n’est exécuté.
• Archive ZIP, gzip ou format similaire : son contenu n’est pas décompressé ni parcouru.
• Code minifié : il est analysé comme texte brut, sur toute sa longueur.

Presidio

Le registre décrit Microsoft Presidio comme composant prévu mais non déployé. En son absence, la détection de noms de personnes est suspendue et le champ presidio_used du rapport reste faux. Les détecteurs bloquants et d’avertissement ci-dessus sont implémentés dans le binaire Go et continuent de fonctionner sans ce composant. Lorsque le sidecar répond, la détection de noms reste plafonnée : elle passe par un appel HTTP portant un extrait du texte, pas par le balayage en flux. C’est le second cas de couverture partielle, signalé fichier par fichier dans le rapport.

Limites de taille et de lecture

Deux plafonds bornent le volume analysé, et ils ne disent pas la même chose. Celui de l’offre porte sur le TOTAL du compte, tous sites confondus : 50 Mo en Gratuit, 500 Mo en Plus, 1 Go en Business. Celui du fichier dépend de son TYPE et reste identique sur toutes les offres : 10 Mo pour une image, 50 Mo pour un document analysé (HTML, PDF, bureautique, texte, données), 200 Mo pour une vidéo, un son ou une archive — que le scanner ne lit pas. Les détecteurs bloquants n’ont plus de limite de lecture propre : ils couvrent le fichier entier, quelle que soit sa taille dans ces quotas. Deux traitements restent partiels — l’extraction des PDF et la détection de noms par Presidio — et le rapport nomme les fichiers concernés dans files_truncated plutôt que de laisser croire à une couverture intégrale.

Faux positifs et faux négatifs

Les contrôles NIR, IBAN et carte combinent recherche large et validation de clé pour réduire les faux positifs. Un candidat numérique qui n’est qu’un morceau d’un nombre plus long — typiquement la mantisse d’un flottant dans un fichier JavaScript minifié — est écarté avant validation. Le SIREN et le SIRET ne sont pas recherchés : ce sont des données publiques. Les secrets utilisent des formes connues plutôt qu’une mesure d’entropie : un secret exotique, obfusqué, chiffré ou fragmenté peut ne pas être détecté, où qu’il se trouve dans le fichier.

Un PDF compressé ou scanné comme image, une archive, un format non pris en charge et un contenu chargé après publication depuis un service externe peuvent échapper au scan. À l’inverse, une chaîne de test qui ressemble exactement à un secret pris en charge peut être bloquée.