Un après-midi de septembre, j'ai pris Claude Code, je lui ai branché un skill OSINT disponible publiquement ↗, et je lui ai demandé ce qu'un œil extérieur verrait de moi en consultant uniquement des sources ouvertes. Pas de base policière, pas d'accès privilégié, rien que ce que n'importe qui peut lire. En vingt minutes, un rapport structuré, chiffré, hiérarchisé. En le relisant, j'y ai trouvé quatre choses sur lesquelles il se trompe franchement, trois surprises que je n'avais pas vu venir, et le nom de Drazik, mon chien, qui me manque toujours.
Je raconte parce que je pense qu'on va de plus en plus souvent faire ça — brancher un modèle de langage sur une tâche OSINT. On sait déjà que ça marche, et plutôt bien. La vraie question est ailleurs : où est-ce que ça casse, qu'est-ce qu'on doit systématiquement revérifier à la main, et comment on apprend à ne pas se laisser rassurer par un rapport bien mis en page.
La séance, en vrac
Le format du rapport ressemble à ce qu'on obtient d'un stagiaire appliqué : un résumé exécutif de cinq points, un tableau de findings notés en sévérité, une partie « empreinte publique », une partie « fuites de données », une partie « pseudos et comptes », un plan d'action classé en trois priorités. Pour quelqu'un qui en a lu quelques-uns dans sa vie, la mise en forme est une évidence immédiate — et c'est précisément ce qui doit mettre en garde. Un rapport propre inspire une confiance qui n'a rien à voir avec sa fiabilité.
La méthode suivie, pour l'essentiel : interrogation de bases publiques de fuites, croisement avec des moteurs de recherche d'exposition de services sur Internet, pivot sur les pseudonymes retrouvés dans mes propres pages, remontée de l'archive de 2006 à aujourd'hui, lecture des registres belges d'entreprises, recoupement avec les plates-formes grand public où des adresses mail sont inscrites. Rien que je n'aie déjà vu décrit, rien que des outils d'OSINT consomment depuis des années. Ce qui change, c'est la vitesse de synthèse : un croisement qui prenait une après-midi tient en une passe.
Un détail de dispositif, qui compte beaucoup dans ce qui suit : je ne laisse pas tourner un seul agent de bout en bout. J'en lance plusieurs en parallèle sur des branches distinctes de l'enquête — un pour les fuites de données, un pour les archives, un pour les pseudos, un pour les enregistrements publics — et par-dessus, un agent de contrôle dont la seule tâche est de rouvrir chaque assertion produite par les autres et de dire si elle tient à la seconde lecture. C'est le même principe que l'interlocuteur qui relit : il ne cherche pas ce qui marche, il cherche ce qui ne marche pas. Sans ce dispositif, plusieurs des erreurs qui suivent seraient probablement passées inaperçues — pas parce qu'elles sont difficiles à voir, mais parce qu'un rapport bien mis en page désarme la vigilance qui les repérerait.
Ce qu'il trouve bien
Il reconstruit sans difficulté le fil qui relie plusieurs décennies de mon activité en ligne : les sites que j'ai tenus, les pseudos que j'ai portés, les projets que j'ai assumés publiquement. Il repère la petite dizaine de fuites de données étalées sur quinze ans où mon adresse mail apparaît, en distinguant celles qui comportent un mot de passe de celles qui ne font que lister un nom et une adresse. Il croise correctement les sources, il hiérarchise correctement les risques, et quand il annonce « votre domaine n'a pas de politique DMARC publiée », il a raison et c'est utile.
Et un geste qui mérite d'être souligné, parce qu'il n'est pas acquis : à un endroit du rapport, le modèle tombe sur une personne qui porte mon nom et n'est pas moi. Il le signale explicitement, nomme l'ambiguïté, refuse de la fusionner avec mon profil. C'est exactement la prudence qu'on attend d'un outil d'OSINT, et il la fait très bien. Qu'il la fasse à cet endroit-là est important, non pas comme performance isolée, mais parce que ça change la lecture de l'erreur dont je parle plus bas.
Deux pivots d'identité, surtout, qui ne sont pas une surprise mais que j'avais sous-estimés dans leur efficacité :
replicatorbe— mon handle sur plusieurs plates-formes de code et de création, en évidence sur ce site.smuug— mon handle sur un vieil annuaire personnel.
Ces deux chaînes de caractères, prises séparément, suffisent à remonter à mon identité réelle en un seul saut. Je le savais, dans l'absolu. Lire un rapport qui le pose en deux lignes, c'est autre chose. Un pseudo n'est pas une couverture, c'est un alias publié.
Ce qu'il hallucine, et pourquoi
C'est la partie que je trouve la plus intéressante, parce qu'elle dit quelque chose sur le genre d'erreurs qu'on va voir arriver dans ce type de rapport. Quatre cas, du plus net au plus fin.
1. La donnée sourcée qui ne l'est pas
Il m'attribue, dans la version archivée de mon site de 2007, un numéro de téléphone fixe précis, en citant la page qui serait censée le contenir. À la revérification manuelle de cette page, le numéro n'y est pas. Peut-être un numéro que j'avais posé moi-même à l'époque et dont je n'ai plus souvenir, peut-être une invention pure du modèle — je ne tranche pas, parce qu'il n'y a aucune façon de le savoir aujourd'hui. Ce qui tient, c'est le motif : la citation de la source donne un rapport l'apparence de la vérifiabilité, alors que la source ne confirme pas la donnée qu'elle est censée porter. C'est l'une des hallucinations les plus dangereuses, parce qu'elle est présentée exactement comme un fait vérifié.
2. Le chaînage opportuniste
Il m'invente, dans son plan d'action, un lien avec « un audit M365/Entra en cours que vous avez signalé précédemment ». Je n'ai jamais signalé ça. Il n'y a pas d'audit en cours. Mais il a croisé le fait que mon adresse mail s'authentifie contre Office 365 (vrai, et banal) avec un vocabulaire d'audit qui lui semblait cohérent avec le reste du rapport, et il a inventé la pièce qui manquait pour que la section se boucle. Ce type d'erreur est insidieux parce qu'il ajoute un fait, au lieu d'en tordre un. Un lecteur pressé le prend pour un rappel.
3. La confusion d'homonyme non signalée
Il m'attribue une entrée sur un site de généalogie où ne figure que mon nom. Je ne me suis jamais inscrit sur ce service, et la fiche est manifestement celle d'un homonyme — mon nom de famille n'est pas unique en Belgique. L'erreur serait moins grave si le rapport l'avait signalée comme ambiguë. Il ne l'a pas fait.
Et c'est précisément ce qui rend ce cas pénible, parce qu'ailleurs dans le même rapport, il sait le faire — j'en ai parlé plus haut, il a correctement nommé un autre homonyme et refusé de le fusionner avec moi. Il ne manque donc pas de la capacité ; il manque de la systématicité. C'est le pire des deux mondes : on ne peut plus se fier au silence (si rien n'est signalé, c'est peut-être que c'est bien moi, peut-être pas), ni compter sur l'alerte comme garantie que le reste a été vérifié. Un bon outil d'OSINT doit publier l'incertitude autant que la donnée, et il doit le faire pour chaque donnée. Celui-là publie la donnée, et avale l'incertitude de façon inégale.
4. Le fait obsolète présenté comme actuel
Il mentionne mon affiliation à un hackerspace de Charleroi. C'est vrai — mais ça ne l'est plus depuis des années. Si je garde la mention en évidence sur mon site, c'est pour continuer d'offrir un peu de visibilité à ce lieu que j'apprécie, pas pour laisser croire que j'en suis encore membre actif. Le modèle, lui, ne lit pas l'intention derrière une donnée : il lit la donnée. Pour lui, une page qui dit X en 2015 et une page qui redit X en 2026 ne se contredisent pas forcément, et surtout il n'a pas la notion native de « ça a été vrai, ça ne l'est plus ». Il faut lui apprendre à distinguer la mention assumée d'un fait actuel — et, quand il ne peut pas trancher, à poser la question plutôt que de conclure.
Ce que je n'avais pas vu venir
Deux choses, surtout.
Archive.org garde ce que mon site actuel a oublié. Dans une capture de 2007, l'ancienne version de mon site affichait l'adresse postale et le téléphone de l'époque, dans une page « contact » que personne n'a mise à jour depuis presque vingt ans. Mon site vivant ne les affiche plus. L'archive, elle, les sert à qui le demande. J'avais écrit sur les huit endroits où une date se cache dans un site ; j'ajoute aujourd'hui qu'il faut compter l'archive comme un neuvième tuyau par lequel les anciennes versions de vous-même continuent de parler.
Et c'est précisément là qu'un LLM apporte quelque chose qui n'existait pas vraiment à l'échelle d'une personne. Parcourir à la main toutes les captures d'un site de vingt ans — plusieurs centaines, dans mon cas — pour y chercher les traces d'une adresse, d'un numéro, d'une mention qui aurait dû disparaître, c'est un travail de fourmi qu'on ne fait presque jamais parce qu'il coûte des jours. Un modèle, lui, traverse l'archive, remonte ce qui dépasse encore, et le pose dans un rapport en une passe. La vitesse ne compresse pas seulement le temps : elle rend praticable ce qu'on renonçait à faire. Et quand on comprend ce que ça rend praticable pour quelqu'un qui s'intéresse à nous, on remet un peu d'ordre dans ses propres restes.
Drazik. Dans une page de 2010, j'avais mentionné mon chien. Il s'appelait Drazik, il est mort il y a dix ans, et je l'aimais. Le LLM a repéré la mention et me l'a remise sous les yeux comme une donnée personnelle, parfaitement neutre, parmi d'autres. Elle est neutre, et elle n'est pas. C'est exactement la mécanique du doxxing contextualisé : il n'y a aucun fait sensible dans « cette personne avait un chien qui s'appelait Drazik », et pourtant le simple fait de me le ressortir dans un rapport m'a serré quelque chose. Un outil ne jauge pas ça. Un enquêteur, oui.
Ce qui ne change pas depuis l'OSINT à l'ancienne
Les mêmes règles que celles posées pour reconnaître quelqu'un qui revient sur un chat, appliquées à soi-même :
- Un indice n'est pas une preuve. Un seul rapport, aussi bien structuré soit-il, ne tient lieu de rien. Chaque ligne doit être re-vérifiée à la source primaire — et c'est précisément ce que je viens de faire ci-dessus pour quatre d'entre elles.
- Deux indices qui disent la même chose ne comptent pas double. Trois sources qui dérivent toutes du même registre d'entreprises ne font pas trois corroborations : elles font le même fait, vu trois fois.
- La constellation prime sur l'indice isolé. Un pseudo tout seul ne vaut rien. Un pseudo plus une adresse mail plus un fuseau horaire plus un graphe social : il n'y a plus beaucoup de monde dans la case.
- La vérification à la main reste la dépense de temps réelle. La synthèse est gratuite. La preuve ne l'est pas.
La frontière
Je l'ai fait sur moi, et c'est le seul cadre dans lequel ce billet existe. Faire le même exercice sur un tiers change de nature et de régime : il engage une base légale, une finalité, une durée de conservation, et selon qui le fait, une autorité. Ce cadre existe, il est écrit, et il bouge avec les réformes en cours. Ce que je m'autorise sur moi-même ne dit rien de ce que je m'autoriserais sur quelqu'un d'autre. La confusion des deux est, comme je l'écrivais ailleurs, la façon la plus sûre de transformer un travail légitime en problème.
Ce que j'ai fait, après
La vraie leçon n'est pas dans la méthode, elle est dans ce qu'elle a mis en évidence et que j'ai corrigé le soir même :
- Revue de confirmation sur les comptes correspondant aux adresses fuitées — mon stock est déjà unique par service et dans un gestionnaire depuis longtemps, mais le passage en revue a confirmé qu'aucun mot de passe de ces époques ne traînait quelque part. Les combolists recirculent chaque année ; le risque n'est pas la fuite, c'est la réutilisation.
- MFA actif sur les comptes pivots. Pas de SMS — mon numéro a fuité une fois, il peut re-fuiter.
- Un service d'administration remis derrière une liste d'adresses autorisées, au lieu d'être joignable depuis Internet entier.
Rien de spectaculaire. Juste la boucle que je n'avais pas fermée.
Et deux gestes qui restent sur ma liste :
- Publier une politique DMARC sur mon domaine (en mode observation d'abord, puis resserré par étapes) et aligner le SPF en conséquence. Ce n'est pas une case à cocher dans la DNS : ça demande d'abord de passer en revue le routage mail existant pour ne pas rejeter du courrier légitime au moment où on bascule.
- Demander à archive.org l'exclusion des vieilles pages qui exposent encore des coordonnées de 2007 que le site vivant a cessé d'afficher depuis longtemps. Les archives acceptent ce type de demande sous conditions ; il me reste à voir lesquelles s'appliquent à une capture de cette ancienneté.
J'écrirai quand ce sera fait, ou pour expliquer pourquoi ça ne l'a pas été.
Ce que je retiens
- Un rapport propre inspire une confiance disproportionnée. Ce qui est bien mis en forme n'est pas pour autant vérifié.
- Les hallucinations d'un LLM OSINT ne sont pas aléatoires. Elles comblent des trous — un numéro qu'il faut bien écrire, un chaînage qu'il faut bien boucler, une incertitude qu'il préfère avaler que publier.
- Un outil ne jauge pas la charge émotionnelle d'une donnée. Pour lui, le nom d'un chien qu'on a aimé vaut un code postal.
- La vitesse qu'il apporte ne remplace pas le pas de vérification. Elle le rend plus visible, parce qu'elle le compresse.
- Sur soi, c'est un exercice d'hygiène. Sur un tiers, c'est un autre métier, avec d'autres règles — et surtout d'autres bases légales.
Vingt minutes avec une IA ont fait apparaître la moitié d'une après-midi de travail à l'ancienne. Ce qu'il m'a fallu derrière pour trier le vrai du faux et le pertinent du bruit : à peu près la même après-midi. L'économie n'est pas là où on l'attend ; elle est dans la couverture, pas dans le temps. On ne va pas plus vite, on regarde plus large — à condition de garder la main sur ce qu'on garde.