Fuite de 153 Millions de Documents : Ce Qui Change Pour Qui Demande une Photo d'Identité
Salut HaWkers, le 1er septembre 2026 le journaliste Brian Krebs a publié qu'un nouveau service du dark web, appelé Nexus, vendait des images numérisées de plus de 153 millions de permis de conduire des États-Unis et du Canada. S'y ajoutaient plus de 10 millions de cartes d'identité, plus de 3 millions de documents de voyage et environ 579 000 cartes d'assurance santé. Krebs lui-même a retrouvé son propre permis, émis par l'État de Virginie, proposé comme échantillon gratuit.
Vous êtes-vous déjà demandé combien de buckets stockent, en ce moment, la photo de votre pièce d'identité parce que vous avez loué une voiture, séjourné dans un hôtel ou ouvert un compte ? Dans cet article je montre ce que l'on sait de l'affaire, pourquoi l'architecture la plus courante de vérification d'identité accumule ce risque, et ce que vous pouvez changer dans votre code dès cette semaine pour ne pas devenir le prochain gros titre.
Ce Qui S'est Passé : 153 Millions de Documents et un Fournisseur au Milieu
La piste mène à une seule entreprise. Sur la base d'entretiens avec des personnes dont les permis étaient en vente, l'origine probable des images est IDScan.net, une société de vérification d'identité basée à La Nouvelle-Orléans, en Louisiane, qui valide des documents pour des clients comme Hertz, FedEx, Caesars Entertainment et une longue liste de dispensaires de cannabis aux États-Unis.
Deux détails techniques resserrent l'étau. Les enregistrements ne contenaient pas seulement la photo du recto et du verso : ils contenaient aussi les balayages en infrarouge et en ultraviolet que les lecteurs professionnels effectuent pour contrôler les éléments de sécurité du plastique. Et ils portaient des horodatages qui coïncident avec le moment où ces personnes ont loué une voiture ou voyagé. Aucune fuite de base de données laissée à l'abandon sur internet ne produit un tel ensemble : c'est ce qui sort d'un équipement de capture, au point d'accueil, en route vers le cloud.
Le vendeur affirmait exfiltrer des données en continu depuis plus d'un an, avec un stock mis à jour en permanence, et il est allé jusqu'à annoncer près de 400 000 nouveaux permis ajoutés en 24 heures. Pour donner une dimension publique à la collection, le permis du secrétaire à la Défense des États-Unis, Pete Hegseth, émis au Minnesota, était listé à 100 dollars.
Le bureau du FBI à La Nouvelle-Orléans a ouvert une enquête officielle sur l'origine des images, et Krebs a raconté avoir été mis en communication avec une demi-douzaine d'agents, y compris des responsables de la division cyber. Gillian Cossman, directrice des opérations d'IDScan.net, a confirmé que l'entreprise enquêtait sur l'incident. Le site Nexus a disparu peu après l'article, ce qui ne rend rien : qui a acheté, a acheté.
Pourquoi le Fournisseur de Vérification Est la Cible Parfaite
L'économie de la vérification d'identité s'est organisée comme presque toute notre stack : au lieu que chaque entreprise construise sa propre lecture de documents, toutes se branchent sur la même poignée de fournisseurs. C'est la bonne décision en matière de qualité de détection de fraude, et c'est la décision qui concentre tout le risque en un seul point.
Pensez à ce que cela représente en volume. Un loueur de voitures seul stocke peut-être quelques millions de documents. Un fournisseur qui sert un loueur, un hôtel, une salle de concert, un dispensaire et une banque stocke l'intersection de tous ces acteurs — c'est-à-dire, à la limite, la population adulte de deux pays. L'attaquant n'a plus besoin de choisir une cible : il choisit le fournisseur.
Le deuxième problème est le temps. Un mot de passe qui fuit, vous le changez en 30 secondes. Un numéro de carte, la banque le réémet en trois jours. Un permis de conduire avec photo, numéro, date de naissance, adresse et signature reste valable pour les cinq ou dix prochaines années, et la seule façon d'en "changer" est de déménager. C'est la raison pour laquelle l'image d'un document est une catégorie de données différente de toutes les autres que vous stockez : elle n'expire pas et elle n'a pas de révocation.
Et il existe un troisième problème, plus inconfortable : presque personne ne sait où vivent les images. Quand vous téléversez votre pièce d'identité dans une application, vous avez une relation avec cette marque. L'image, en pratique, est partie chez son sous-traitant, qui utilise peut-être un stockage tiers, qui réplique dans une autre région. C'est exactement cette chaîne que l'affaire Nexus a exposée — les victimes n'avaient jamais entendu parler d'IDScan.net.
L'Erreur d'Architecture : Garder l'Image Après la Vérification
Voici le point qui intéresse celui qui écrit du code. Dans l'écrasante majorité des produits, la photo du document est l'intrant d'une décision binaire : cette personne a plus de 18 ans, ce nom correspond à celui de la carte, ce document est authentique. La décision est ce dont le métier a besoin. L'image est le résidu.
Sauf que le flux standard fait l'inverse : il envoie l'image dans un bucket, lance la vérification, écrit le résultat dans une colonne et laisse l'image là, "par sécurité", "pour l'audit", "parce que la conformité pourrait la demander". Des années plus tard, plus personne ne se souvient que ce bucket existe, et il contient désormais 40 millions d'objets.
Le schéma sain consiste à inverser : l'image est éphémère, le verdict est persistant. En TypeScript, dans un handler de téléversement, c'est moins de travail qu'il n'y paraît.
// Vérification en mémoire : l'image n'atteint jamais un bucket.
import { randomUUID, createHash } from 'node:crypto';
type Verdict = {
id: string;
utilisateurId: string;
majeur: boolean;
nomCorrespond: boolean;
documentAuthentique: boolean;
regionEmettrice: string; // attribut dérivé, pas le document
fournisseur: string;
verifieLe: string;
// Empreinte pour dédupliquer les tentatives sans garder l'image.
empreinteImage: string;
};
export async function verifierDocument(
utilisateurId: string,
image: Buffer,
nomAttendu: string
): Promise<Verdict> {
// 1. Envoie au fournisseur et ne reçoit que des attributs.
const analyse = await fournisseurKyc.analyser(image);
// 2. Extrait ce dont le métier a réellement besoin.
const verdict: Verdict = {
id: randomUUID(),
utilisateurId,
majeur: analyse.age >= 18,
nomCorrespond: normaliser(analyse.nom) === normaliser(nomAttendu),
documentAuthentique: analyse.scoreAuthenticite > 0.9,
regionEmettrice: analyse.region,
fournisseur: 'fournisseur-x',
verifieLe: new Date().toISOString(),
empreinteImage: createHash('sha256').update(image).digest('hex'),
};
// 3. Détruit l'image avant de répondre. Pas de bucket, pas de file, pas de log.
image.fill(0);
return verdict;
}Regardez ce qui reste : aucune date de naissance, aucun numéro de document, aucune photo. Si cette base fuit demain, l'attaquant repart avec des booléens. Et l'empreinteImage permet encore de répondre à "ce même document a-t-il déjà été utilisé sur un autre compte ?" sans conserver le document.
Si Vous Devez Conserver, Conservez Avec une Date de Péremption
Il existe des cas légitimes de rétention. Les institutions financières ont des obligations de conservation, et les litiges de rétrofacturation exigent des preuves. La réponse n'est pas "ne conservez jamais", c'est "conservez avec un délai, avec une clé par enregistrement et avec une suppression automatique".
La clé par enregistrement compte parce qu'elle change l'économie de la fuite. Avec une clé unique pour tout le bucket, celui qui obtient la clé obtient tout. Avec le chiffrement par enveloppe, chaque document a sa propre clé de données, chiffrée par la clé maîtresse du KMS. L'attaquant qui copie le bucket repart avec des octets aléatoires.
// Chiffrement par enveloppe + expiration : l'enregistrement se détruit tout seul.
import { KMSClient, GenerateDataKeyCommand } from '@aws-sdk/client-kms';
import { createCipheriv, randomBytes } from 'node:crypto';
const kms = new KMSClient({});
const RETENTION_JOURS = 90;
export async function stockerAvecDelai(image: Buffer, enregistrementId: string) {
// Une nouvelle clé de données pour chaque document.
const { Plaintext, CiphertextBlob } = await kms.send(
new GenerateDataKeyCommand({ KeyId: 'alias/documents', KeySpec: 'AES_256' })
);
const iv = randomBytes(12);
const cipher = createCipheriv('aes-256-gcm', Plaintext!, iv);
const chiffre = Buffer.concat([cipher.update(image), cipher.final()]);
await s3.putObject({
Bucket: 'documents-kyc',
Key: `${enregistrementId}.bin`,
Body: Buffer.concat([iv, cipher.getAuthTag(), chiffre]),
// L'expiration vit dans l'objet, pas dans un tableur de processus.
Expires: new Date(Date.now() + RETENTION_JOURS * 864e5),
Metadata: { cle: CiphertextBlob!.toString('base64') },
});
// Efface la clé en clair de la mémoire dès que l'usage est terminé.
Plaintext!.fill(0);
}Complétez avec une règle de cycle de vie sur le bucket qui supprime réellement les objets après le délai. Une politique déclarée dans l'infrastructure survit au changement d'équipe ; une routine de nettoyage écrite à la main meurt au premier déploiement que personne n'a relu.
La Métadonnée Que Personne Ne Regarde
L'affaire Nexus contient une leçon facile à appliquer et facile à oublier : les enregistrements en vente contenaient un horodatage et les balayages en infrarouge et en ultraviolet. Autrement dit, avec l'identité a fuité le contexte — où et quand cette personne se trouvait.
La même chose se produit dans votre téléversement. Une photo prise par un téléphone arrive avec ses données EXIF : modèle de l'appareil, date, heure et, fréquemment, coordonnées GPS. Si vous stockez le fichier tel que vous l'avez reçu, vous n'avez pas gardé un document, vous avez gardé un document plus la localisation de celui qui l'a envoyé.
// Normalise l'image et supprime toute métadonnée avant la moindre persistance.
import sharp from 'sharp';
export async function assainir(entree: Buffer): Promise<Buffer> {
return sharp(entree)
.rotate() // applique l'orientation puis jette l'EXIF
.resize({ width: 1600, withoutEnlargement: true })
.jpeg({ quality: 82, mozjpeg: true })
.withMetadata({ exif: {} }) // sans GPS, sans appareil, sans horodatage
.toBuffer();
}La même discipline vaut pour les logs. Un console.log(req.body) dans un handler de téléversement envoie l'image entière, en base64, vers l'agrégateur de logs — qui a d'habitude une rétention plus longue et un contrôle d'accès plus lâche que la base de données. Là, la fuite n'a même pas besoin d'un attaquant sophistiqué.
Vérification de l'Âge Sans Demander le Document
La question la plus honnête vient avant tout cela : avez-vous vraiment besoin de l'image ? Pour une grande partie des cas — vérifier la majorité, confirmer la résidence dans un pays, prouver qu'une personne a un permis valide — la réponse en 2026 est non.
La Digital Credentials API du W3C est arrivée dans Chrome 141 et Safari 26 en septembre 2025, et Firefox embarque déjà une implémentation de base. Elle dialogue avec le portefeuille du système d'exploitation et utilise le format mdoc, de la norme ISO/IEC 18013-5, la même qui soutient les permis de conduire numériques déployés un peu partout dans le monde. La deuxième édition de la norme est en cours de vote, avec une publication prévue pour le troisième trimestre 2026.
Ce qui change pour votre code, c'est la divulgation sélective : vous demandez un attribut, pas un document.
// Demande seulement "a plus de 18 ans", jamais le numéro ni l'adresse.
const reponse = await navigator.credentials.get({
digital: {
requests: [
{
protocol: 'openid4vp',
data: {
response_type: 'vp_token',
nonce: nonceDuServeur, // généré côté backend, usage unique
dcql_query: {
credentials: [
{
id: 'permis',
format: 'mso_mdoc',
meta: { doctype_value: 'org.iso.18013.5.1.mDL' },
// La demande entière tient dans un champ booléen.
claims: [{ path: ['org.iso.18013.5.1', 'age_over_18'] }],
},
],
},
},
},
],
},
});
// Arrive une preuve signée de "true". N'arrivent ni photo, ni numéro, ni date.
await fetch('/api/age', { method: 'POST', body: JSON.stringify(reponse.data) });Le justificatif reste chiffré sur l'appareil, et ce qui circule est une preuve signée de l'attribut. Il n'existe aucune image à faire fuiter parce qu'il n'existe aucune image. C'est le même débat qui est apparu autour de la loi californienne AB 1856 sur la vérification de l'âge : la régulation pousse les plateformes à vérifier, et la manière dont elles vérifient décide si le résultat est une protection ou un passif de 153 millions d'enregistrements.
Ce Qu'il Faut Demander Avant de Brancher un Fournisseur
Si la vérification part chez un tiers, et c'est presque toujours le cas, le contrat fait partie de l'architecture. Quatre questions règlent l'essentiel :
- Conservez-vous l'image après le verdict ? Pendant combien de temps, et comment puis-je forcer la suppression ? Si la réponse est vague, la réponse est "pour toujours".
- Qui sont les sous-traitants et dans quelles régions les données résident-elles ? La liste doit être écrite et versionnée, pas énoncée dans une conversation commerciale.
- Le chiffrement est-il par enregistrement ou par bucket ? Cela décide si un accès indu coûte un document ou tous les documents.
- Existe-t-il une API de suppression à la demande, et efface-t-elle les sauvegardes ? Sous le RGPD et les lois équivalentes, c'est vous le responsable de traitement. L'obligation de répondre à la personne concernée est la vôtre, même si la donnée se trouve chez le fournisseur.
Ajoutez à cela l'hygiène de base : identifiants d'API du fournisseur avec rotation, portée minimale et alerte de volume. Le vendeur de Nexus disait exfiltrer depuis plus d'un an, avec 400 000 enregistrements en 24 heures. Un graphique de lectures par identifiant aurait hurlé bien plus tôt.
Ce Qu'il Faut Faire de Notre Côté
Comme utilisateur, ce que l'on peut faire est limité, mais ce n'est pas rien. Demandez pourquoi un établissement a besoin de copier votre pièce d'identité et ce qui arrive à la copie. Préférez le justificatif numérique ou la lecture sur place plutôt que d'envoyer la photo par e-mail ou par messagerie. Activez l'alerte de crédit auprès des organismes concernés. Et méfiez-vous des approches qui citent des données correctes de votre document : avec une collection pareille, l'arnaque par ingénierie sociale devient convaincante par défaut.
Le point plus large est le même que celui abordé dans le billet sur le procès de WhatsApp autour du chiffrement de bout en bout : une donnée qui existe est une donnée qui peut être réclamée, volée ou vendue. La seule protection qui ne dépend pas de la compétence d'un tiers, c'est la donnée qui n'a jamais été collectée.
Ce Que Cela Laisse Pour 2026
Trois lectures pratiques.
La première, c'est que l'ère du "téléversez la photo de votre document" touche à sa fin, et pas par bonté : elle devient coûteuse. Les régulateurs européens traitent déjà la rétention d'images de documents comme disproportionnée dès qu'une alternative technique existe, et il existe désormais une alternative technique dans un navigateur stable.
La deuxième, c'est que la vérification d'identité est devenue une dépendance critique, du même niveau qu'un prestataire de paiement. Elle mérite un plan de continuité, une révision de contrat et une surveillance des volumes — pas une intégration faite en un sprint et plus jamais touchée.
La troisième est la plus directe. Ouvrez aujourd'hui l'inventaire des endroits où votre produit stocke des images de documents. Mesurez combien d'objets existent, depuis quand, et combien seraient encore nécessaires si vous supprimiez tout ce qui a dépassé le délai. Dans la plupart des équipes ce calcul fait peur, et c'est justement pour cela qu'il vaut la peine de le faire avant que quelqu'un d'extérieur ne le fasse à votre place.
Allez, on y va! 🦅
📚 Vous Voulez Suivre Ce Qui Arrive?
Cet article a couvert la fuite de 153 millions de documents et ce qu'elle change dans la vérification d'identité, mais l'écosystème change chaque semaine et tout ne devient pas un article ici.
Sur X je partage ce que je teste, les coulisses des projets et les nouveautés qui apparaissent avant de devenir un post.
Suivez-Moi Là-Bas
💡 Du contenu quotidien sur le développement, la carrière et les outils que j'utilise vraiment

