Générer des UUID

Pour une clé primaire de base de données, la v7. S'il doit être impossible à deviner — un lien de réinitialisation de mot de passe, un code d'invitation, un identifiant de session — la v4. C'est tout le choix, et la plupart des gens ignorent même qu'il existe, car presque tous les générateurs ne proposent que la v4.

Parce qu'elle est entièrement aléatoire, alors qu'un index de base de données est trié. Les nouvelles clés aléatoires atterrissent n'importe où dans l'index : chaque insertion touche une page différente, le cache ne sert plus à rien, et l'index se fragmente et grossit. Sur une grande table très sollicitée, c'est un ralentissement mesurable qui s'aggrave avec le temps. Ce n'est pas un souci théorique — c'est la raison pour laquelle les documentations de Postgres et de MySQL en parlent désormais toutes les deux.

Un UUID dont les 48 premiers bits sont un horodatage à la milliseconde, suivis d'aléatoire. Il reste unique au niveau mondial et fait toujours 128 bits, mais comme la date vient en premier, les UUID v7 se trient dans leur ordre de création. Les nouvelles clés s'ajoutent à la fin de l'index au lieu de s'y disperser, exactement comme un entier auto-incrémenté — avec l'unicité d'un UUID. Il a été normalisé par la RFC 9562 en 2024, et c'est la recommandation actuelle pour les nouvelles tables.

Oui, y compris au sein d'une même milliseconde, ce que la plupart des implémentations ratent. Un horodatage n'a qu'une résolution à la milliseconde : générer mille identifiants dans une boucle se termine en une seule — et avec des bits de poids faible purement aléatoires, ces mille-là ne se trient PAS dans leur ordre de création. Ce générateur utilise le compteur monotone décrit dans la RFC 9562 : un lot est donc strictement croissant, à chaque fois. Générez-en mille et triez-les : ils reviennent dans l'ordre où ils ont été créés.

Oui, en gardant une chose à l'esprit : par conception, il révèle sa date de création, à la milliseconde près. Pour une clé de base de données, c'est généralement sans conséquence, voire utile. Mais si la date de création est elle-même sensible, ou si l'identifiant doit être impossible à deviner, utilisez la v4 — la v7 compte tout de même 74 bits aléatoires, ce qui est beaucoup, mais son horodatage est lisible en clair par quiconque possède l'identifiant.

Oui. L'aléatoire provient de `crypto.getRandomValues`, le générateur cryptographiquement sûr du navigateur, jamais de `Math.random`. Cette distinction a causé de vraies vulnérabilités : `Math.random` est rapide mais prévisible, et des jetons de session construits dessus ont été devinés en pratique. Un UUID v4 compte 122 bits aléatoires, ce qui suffit pour que les collisions ne soient pas un souci en pratique.

Oui, entièrement, et pour des identifiants, cela compte. Un UUID récupéré sur le serveur de quelqu'un d'autre est un UUID que quelqu'un d'autre a vu — ce qui va à l'encontre du but si vous générez un secret. Ceux-ci ne quittent jamais votre navigateur. Une fois la page chargée, coupez votre Wi-Fi : elle fonctionne exactement de la même façon. C'est le moyen le plus simple de vérifier vous-même la promesse de confidentialité, plutôt que de nous croire sur parole.

Que des zéros : 00000000-0000-0000-0000-000000000000. C'est un UUID valide et réservé, utilisé pour signifier « aucun » ou « non défini » là où un null n'est pas possible. Son opposé, l'UUID max composé uniquement de f, sert parfois de sentinelle de tri. Les deux sont proposés ici, car on en a parfois besoin et ils sont pénibles à taper correctement.