UUID v4 expliqué : pourquoi les ID aléatoires battent l'auto-incrément

Ce qu'est réellement un UUID v4, pourquoi le risque de collision est négligeable, et les situations concrètes où il l'emporte sur un simple ID entier auto-incrémenté.

Un UUID v4 est un identifiant de 128 bits généré presque entièrement à partir de bits aléatoires, formaté en 32 caractères hexadécimaux répartis en 5 groupes (ex. 3fa85f64-5717-4562-b3fc-2c963f66afa6). Le « 4 » indique la version, ce qui signifie que l'ID ne porte aucune information sur le quand, le où ou le comment de sa création — ce qui est précisément le but.

N'y a-t-il pas un risque que deux ID entrent en collision ?

Techniquement oui, en pratique non. Un UUID v4 possède 122 bits aléatoires (6 bits sont fixes pour marquer version et variante), ce qui donne environ 5,3 x 10^36 valeurs possibles. Il faudrait générer environ 2,71 trillions d'UUID avant d'avoir 50 % de chances d'une seule collision. Pour pratiquement toute application réelle, ce risque est plus faible que la probabilité qu'une panne matérielle corrompe les données de toute façon.

Pourquoi ne pas simplement utiliser 1, 2, 3… comme un auto-incrément de base de données ?

Un entier auto-incrémenté fonctionne bien dans une seule base de données, mais il fuite de l'information et casse dès que votre système grandit. Les ID séquentiels permettent à n'importe qui de deviner les enregistrements voisins en changeant simplement un chiffre dans une URL (/commandes/1042 → /commandes/1043), révèlent votre volume approximatif d'inscriptions ou de commandes à vos concurrents, et ne peuvent pas être générés de façon sûre par deux serveurs différents en même temps sans compteur partagé — qui devient un goulot d'étranglement dès que vous passez à l'échelle horizontale.

Quand un UUID est clairement le meilleur choix

Tout système avec plusieurs écrivains indépendants (microservices, applications mobiles offline-first, bases de données distribuées) en profite le plus, car chaque nœud peut générer un ID valide et unique sans aucune coordination ni compteur central. C'est aussi le bon choix chaque fois qu'un ID risque de devenir visible côté utilisateur — références de commande, ID de ressources API, noms de fichiers — où vous ne voulez pas qu'il soit devinable ni qu'il révèle un ordre.

Quand un entier reste le meilleur choix

Pour une petite application à écrivain unique où les ID ne quittent jamais la base de données et où vous avez besoin du plus petit espace de stockage possible et des recherches d'index les plus rapides, un simple entier auto-incrémenté (ou son cousin ordonné, l'UUID v7) reste plus simple et plus rapide. Le caractère aléatoire de l'UUID v4 est aussi son principal inconvénient pour l'indexation : les valeurs n'étant pas ordonnées, elles fragmentent un index B-tree bien plus qu'un ID séquentiel.

Notre générateur d'UUID produit des UUID v4 valides, conformes à la RFC 4122, instantanément et en masse, entièrement dans votre navigateur — utile pour des fixtures de test, des données simulées, ou simplement pour choisir un ID unique sûr sans monter une base de données.