Générateur UUID

Tout l'intérêt, c'est de ne pas demander la permission

Un générateur UUID te donne 128 bits d'identifiant que tu peux frapper sans appeler un serveur central pour réclamer le prochain numéro dans la file. Voilà, c'est toute l'astuce. Deux services peuvent créer un enregistrement à la même milliseconde exacte et personne ne se dispute un ID. Pratique pour les API, les logs d'événements, les jobs d'import, les brouillons côté client qui n'ont pas encore touché le serveur. Ça t'évite aussi de laisser fuiter de gentils petits numéros séquentiels dans des URLs publiques (ton concurrent qui compte tes numéros de commande, ce genre de chose), mais s'il te plaît ne confonds pas ça avec un vrai contrôle d'accès. Ça n'en est pas un.

Ce générateur fait les deux versions vers lesquelles tu vas vraiment tendre la main. v4 est purement aléatoire et supportée à peu près partout. v7 est triée dans le temps, ce que les bases de données et les systèmes de logs ont tendance à apprécier, parce que les valeurs fraîches se trient grosso modo selon le moment où tu les as créées. Au-delà de cracher des IDs, il valide ce que tu colles, avale les variantes URN, braces et no-hyphen, te montre les bits de version et de variant, exporte en texte ligne par ligne, en CSV ou en tableau JSON, et te parle des probabilités de collision sans le ton du manuel de maths.

UUID v4 ou UUID v7 ?

Prends v4 quand tu veux juste un bon ID aléatoire polyvalent et que ta stack le parle déjà. Passe en v7 dès que l'ordre de tri commence à compter pour toi : logs d'audit, enregistrements de file d'attente, tout ce où tu tires sans arrêt les lignes les plus récentes. Ni l'un ni l'autre n'est un secret, au passage, et je vais continuer à le répéter parce que les gens continuent à l'oublier. Que quelqu'un connaisse un UUID ne veut rien dire. Tes règles d'auth doivent toujours vérifier si la personne a le droit de lire ou de modifier cet enregistrement.

• UUID v4 est juste aléatoire. Génère-le correctement et une collision devient follement improbable.
• UUID v7 commence par un timestamp, puis remplit le reste avec de l'aléatoire, donc il se trie par date sans le moindre effort de ta part.
• Le format canonique est en minuscules avec des tirets, ces fameux groupes hex 8-4-4-4-12 que tout le monde reconnaît.
• La validation vérifie ici la syntaxe, la version et les bits de variant définis par la RFC.
• L'export par batch, c'est le truc ennuyeux mais utile : seed de tests, fixtures, scripts de migration, exemples d'API jetables.

Quelques points qui comptent vraiment pour le stockage

Sois cohérent. Si ta base propose un type UUID natif, utilise-le plutôt que de fourrer la chose dans une simple chaîne, tu te remercieras plus tard. Choisis une casse et tiens-t'y partout, dans les API comme dans les logs. Sur des très grosses tables, mesure le comportement de l'index avant de te mettre à échanger des clés primaires, parce que des clés aléatoires peuvent silencieusement saccager les performances d'écriture. Et si ce dont tu as réellement besoin c'est d'un secret (réinitialisations de mot de passe, liens d'invitation, bearer tokens), génère un vrai token aléatoire à forte entropie et stocke-le avec une expiration. Un UUID n'a jamais été conçu pour ça.

Questions fréquentes

Deux UUID peuvent-ils entrer en collision ?

Techniquement oui. En pratique, avec un hasard correct, les collisions v4 ne sont pas un truc qui va t'empêcher de dormir. Ce qui mord vraiment les gens, c'est le banal : un bug, une source d'aléatoire faible, un import qui a tourné deux fois. C'est de là que viennent réellement tes doublons.

UUID v7 est-il meilleur qu’UUID v4 ?

Ça dépend de ce que tu fais, honnêtement. v7 brille pour les insertions ordonnées et les données de logs. v4 reste le choix par défaut facile, qui marche partout. Je penche v7 ces derniers temps, mais je suis peut-être en train de me convaincre d'une mode.

Puis-je utiliser un UUID comme token secret ?

Non. C'est un nom pour quelque chose, point. Les règles de ton appli décident qui est autorisé, et les vrais tokens secrets se génèrent et se stockent comme des secrets, on ne va pas les emprunter à un champ d'ID.

Quelle est la différence entre UUID v4 et v7 ?

v4 est aléatoire de bout en bout. v7 met un timestamp en tête et l'aléatoire derrière, donc il s'aligne chronologiquement et a tendance à beaucoup mieux s'entendre avec les index de bases de données.

Devrais-je utiliser un UUID comme clé primaire de base de données ?

Tu peux. Ça a juste un coût. Les clés v4 aléatoires éparpillent ton index et plombent les performances d'écriture une fois que la table grossit. Prends plutôt v7, ou garde une clé primaire séquentielle classique et range l'UUID dans sa propre colonne.