2 800 téléchargements par semaine. C'est tout ce que pèse, à l'échelle mondiale, le principal outil libre capable de retirer les données personnelles d'une image — d'après l'index de paquets Snyk. Pas par mois. Par semaine. Mettez ce chiffre en face du nombre de contrats numérisés, de photocopies de cartes d'identité et de bulletins de salaire qui dorment dans les armoires d'un cabinet français, et vous ne constatez pas un retard technologique. Vous constatez qu'un marché a choisi son client, et que ce client n'est pas celui qui tient le document.
Le postulat d'extraction
Ouvrez la documentation de n'importe quel outil réputé et regardez le premier appel de fonction. Il attend une chaîne de caractères. Vous lui donnez du texte, il vous rend des positions — les caractères 40 à 51 sont un nom. L'interface est propre et honnête ; pour le travail auquel elle est destinée, c'est la bonne.
Mais regardez ce qu'elle présuppose. Elle présuppose que le texte existe déjà. Quelqu'un, quelque part, a déjà transformé la page en caractères. Appelons cela le postulat d'extraction : toute la catégorie démarre une étape après le plus difficile, sans jamais dire à voix haute qui est censé s'en charger.
Pour un développeur, aucun problème : le développeur est ce quelqu'un. Il a une colonne en base, un journal de conversation, un champ JSON. Le texte est déjà le terrain de son problème. Pour la personne qui tient un PDF numérisé, le présupposé est le problème tout entier — et on le lui a assigné en silence.
L'indice est dans la notice d'installation
Presidio — la référence du domaine, née chez Microsoft et désormais gouvernée par sa communauté — propose bien un module pour les images, et c'est du bon travail. Regardez comment on le met en route : installez le paquet Python, puis installez séparément Tesseract OCR pour votre système d'exploitation, dans une version récente — la documentation mentionne des tests avec la v5.2.0. La variante dédiée à l'imagerie médicale ajoute un avertissement : elle caviarde les pixels, mais ne nettoie pas les données personnelles qui subsistent éventuellement dans les métadonnées du fichier.
Chacune de ces phrases est utile à un ingénieur. Aucune n'est lisible pour une responsable RH qui a quarante contrats de travail numérisés sur les bras. Ce n'est pas un défaut de documentation. C'est une déclaration sur le destinataire du produit, et elle est honnête.
Les grands fournisseurs cloud font la même chose, avec davantage de chiffre d'affaires à la clé : ils vous vendront la reconnaissance de texte comme un service et la détection d'entités comme un autre, en vous laissant le câblage entre les deux. Deux produits, un projet d'intégration, une facture. Le travail d'assemblage — celui où les erreurs se produisent réellement — revient au client, par construction.
La réponse du leader : débrouillez-vous pour le plus dur
Adobe Acrobat est l'endroit où la plupart des gens s'y essaient vraiment, et sa réponse tient en deux temps : lancez d'abord la reconnaissance de texte sur le document numérisé, puis utilisez Rechercher et caviarder. Autrement dit : faites l'extraction vous-même, ensuite nous prenons le relais. Même présupposé, avec cette fois un humain posté dans la jointure.
Cette jointure, c'est là que vivent les fils d'assistance. La reconnaissance échoue discrètement sur un fax peu contrasté. La recherche trouve onze noms sur quatorze parce que le douzième a été lu avec une ligature cassée. À aucun moment rien ne signale une erreur. On vous demande d'être le contrôle qualité d'un procédé qu'on ne vous a jamais montré.
Nous avons fait le même présupposé. En pire.
J'aimerais écrire ceci en critique extérieur. Je ne peux pas : nous avons nous aussi expédié le postulat d'extraction, à trois endroits distincts, et nous ne l'avons découvert qu'en allant mesurer.
Notre chaîne de détection devait décider si une page méritait d'être lue comme une image, et elle posait la mauvaise question — « y a-t-il une grande image ici ? » — en prenant la surface pour un indice d'importance. Un nom de société dans un bandeau d'en-tête occupe environ un demi pour cent d'une page A4. Il passait au travers. La taille n'a jamais été la question. La question est de savoir si du texte est dessiné par-dessus l'image : du texte par-dessus signifie un filigrane ou un fond, et pas de texte par-dessus signifie que l'extracteur est aveugle à cet endroit, quelle que soit la taille.
Pire : la fonction chargée de vérifier si une page contenait des images appelait une méthode que notre bibliothèque PDF ne possédait pas. L'erreur était avalée au niveau debug. Elle répondait « aucune image ici » depuis aussi longtemps que cette dépendance était figée — y compris sur une page composée à 65 % d'image. Un faux silencieux est indiscernable d'une bonne réponse ; c'est exactement ainsi qu'il a survécu.
Et quand un utilisateur traçait à la main un rectangle de caviardage sur un en-tête numérisé, notre éditeur lisait la couche de texte de la page, ne trouvait rien à l'intérieur du rectangle, et ne capturait rien. L'utilisateur désignait précisément ce qu'il voulait faire disparaître, et nous ne le supprimions pas, en silence. Sur une page que nous venions précisément de lire — avant d'en jeter les mots.
Trois bugs, une seule cause racine, et c'est la même que celle du marché : nous avons tendu la main vers le texte en traitant l'image comme l'étape de quelqu'un d'autre.
Qui paie l'oubli silencieux
Un outil qui plante est agaçant. Un outil qui annonce « aucune donnée personnelle détectée » sur une page pleine de noms est autre chose : il n'échoue pas, il délivre un certificat de bonne santé, et transfère la responsabilité à quelqu'un qui n'a aucun moyen de l'auditer.
Demandez-vous qui détient réellement des documents numérisés. Pas l'équipe plateforme d'une grande banque : elle a des ingénieurs, et elle a déjà le texte. Ce sont le cabinet de deux avocats, le centre de santé qui numérise ses formulaires d'admission, le travailleur social avec une photocopie de carte d'identité, la gestionnaire RH et ses promesses d'embauche signées. Les documents en forme d'image sont, de façon disproportionnée, les plus sensibles — et ceux qui les détiennent sont tout aussi disproportionnément incapables d'écrire l'intégration que le marché de l'outillage suppose qu'ils écriront.
Ce sont aussi ceux qui encaissent le plus mal les conséquences. L'ingénieur qui câble mal une chaîne de caviardage ouvre un ticket. La personne dont la photocopie de pièce d'identité est partie en clair saisit la CNIL — et, sous le RGPD, la violation se notifie sous 72 heures.
Ce que change le fait de construire pour l'autre client
Cela change la matière première. L'unité de travail devient la page telle qu'elle existe, image comprise, et non une chaîne de caractères que quelqu'un d'autre était censé produire.
Concrètement : la reconnaissance de texte n'est pas une étape préalable que l'utilisateur déclenche, elle est à l'intérieur de la chaîne. Un rectangle tracé à la main qui n'attrape aucun mot va relire sa propre page, pour qu'une correction manuelle ne puisse jamais rester sans effet. Les noms détectés deviennent des rectangles peints sur les pixels, avec une couche de texte cherchable reconstruite dessous pour que le fichier reste exploitable. Si vous voulez la mécanique plutôt que l'argument, nous l'avons détaillée dans comment caviarder les PDF et images numérisés.
Rien de tout cela n'est plus malin que ce qu'ont bâti les auteurs de Presidio. Ce sont les mêmes composants, agencés pour quelqu'un qui n'allait jamais ouvrir un terminal. Et cela tourne sur la machine où le document se trouve déjà, ce qui, pour la photocopie d'un passeport, n'est pas une préférence.
Questions fréquentes
Pourquoi les outils de caviardage ratent-ils le texte contenu dans les images ?
Parce que la plupart ne regardent jamais l'image. Leur point d'entrée accepte du texte : une page numérisée arrive donc sans rien à chercher et repart avec « aucun résultat », silencieusement. Il faut traiter l'image comme la matière première, et non comme une étape que l'utilisateur exécute d'abord.
N'est-ce pas précisément le rôle du module d'images de Presidio ?
Si, et il fonctionne. C'est aussi un paquet Python qui attend de vous que vous installiez vous-même un moteur de reconnaissance de texte : demande raisonnable pour un développeur, impossible pour la plupart des gens qui détiennent des documents numérisés. Nous avons écrit où son moteur de texte convient et où il ne convient pas dans pourquoi nous avons écrit notre propre moteur plutôt que d'embarquer Presidio.
Pourquoi le traitement local compte-t-il davantage pour les documents numérisés ?
Parce que les numérisations penchent vers le sensible : pièces d'identité, dossiers médicaux, actes signés. Les envoyer à un service pour qu'il en retire les secrets suppose que les secrets arrivent d'abord chez ce service — c'est le risque que vous prenez quand le document lui-même est la chose sensible.
L'essentiel
Si caviarder un PDF plein d'images reste si difficile, ce n'est pas que le problème soit non résolu. Chaque brique existe depuis des années. C'est que les briques ont été conçues et tarifées pour des développeurs travaillant sur des flux de texte, et que l'assemblage — la partie coûteuse, celle qui casse — a été laissé à qui se trouvait tenir le fichier.
La plupart ne sont pas développeurs. C'est quelqu'un derrière un guichet, en train de photocopier un document qu'un inconnu vient de tendre parce qu'il avait besoin de quelque chose : un emploi, un soin, un logement. Cette personne n'a pas consenti à une chaîne de traitement. Elle a consenti à ce qu'un bureau, un après-midi, prenne soin d'une feuille de papier qui parle d'elle. Ce que nous construisons devrait rendre ce soin automatique, et non réservé à ceux qui sont assez techniques pour le mériter.
promptShield exécute la reconnaissance de texte, la détection et le caviardage des PDF et images numérisés sur votre propre machine — aucun paquet à installer, aucune étape de reconnaissance préalable, et rien qui parte en ligne. Essayez-le sur le document que votre outil actuel déclare propre.