Générateur UUID

Un UUID est un identifiant de 128 bits conçu pour être généré indépendamment par n'importe quel nombre de systèmes séparés, à tout moment, sans autorité centrale coordinatrice délivrant le prochain nombre disponible, tout en ayant une garantie statistique écrasante que deux valeurs générées n'entreront jamais en collision. C'est fondamentalement différent d'un ID entier auto-incrémenté, qui nécessite une seule base de données pour suivre et délivrer le prochain nombre en séquence — un UUID peut être généré sur un mobile hors ligne, dans une fonction serverless, ou à travers mille instances de microservice parallèles simultanément, sans avoir besoin d'aucune coordination entre elles, la simple taille de l'espace de nombres rendant une collision accidentelle astronomiquement improbable quel que soit le nombre généré indépendamment.

UUID version 4 remplit essentiellement les 128 bits complets de données cryptographiquement aléatoires, rendant chaque valeur générée complètement imprévisible et ne donnant aucun indice sur quand elle a été créée ni son ordre relatif à tout autre UUID v4 — exactement la propriété désirée pour quelque chose comme un jeton de sécurité, où la prévisibilité elle-même serait une vulnérabilité. UUID version 7, standardisé bien plus récemment dans la RFC 9562 (2024), sacrifie délibérément une partie de cette opacité : il place un horodatage de précision milliseconde dans les bits de tête, donc un UUID v7 généré plus tard se trie toujours après un généré avant, tandis que les bits restants demeurent aléatoires et tout aussi impossibles à deviner que ceux de v4. Les deux ne sont pas des designs concurrents où l'un est simplement « meilleur » — ils échangent le même aléatoire sous-jacent contre une propriété différente selon si le tri ou l'imprévisibilité uniforme est ce qui compte réellement pour un cas d'usage donné.

Un index de base de données soutenant une clé primaire est généralement stocké comme un B-tree, une structure qui fonctionne le mieux quand les nouvelles valeurs sont insérées à ou près de la fin de l'ordre trié existant — ce qui est exactement comment se comporte une clé entière auto-incrémentée traditionnelle. Une clé primaire UUID v4, étant uniformément aléatoire, s'insère à une position effectivement aléatoire dans cette structure triée à chaque fois, forçant la base de données à diviser et rééquilibrer répétitivement des pages d'index dispersées dans tout l'arbre plutôt que de simplement ajouter à la fin. À petite échelle ce surcoût est invisible ; à grande échelle, avec des millions de lignes, cela devient une source réelle et mesurable de fragmentation d'index et d'écritures plus lentes — exactement le problème que l'horodatage de tête d'UUID v7 a été standardisé spécifiquement pour résoudre, permettant à un UUID de maintenir des ID uniques et impossibles à deviner tout en s'insérant dans un ordre approximativement séquentiel.