Beaucoup d’applications commencent avec un compteur de base de données. Le premier enregistrement reçoit 1, le suivant 2, et une autorité centrale garantit l’absence de doublon. Ce modèle fonctionne jusqu’à ce que plusieurs services, régions ou clients hors ligne doivent créer des objets en même temps. UUID adopte une autre stratégie: générer un identifiant dans un espace si vaste qu’une collision pratique devient extrêmement improbable sans demander l’avis d’un compteur central.

Un UUID est une valeur de 128 bits

La forme texte, comme 550e8400-e29b-41d4-a716-446655440000, est une représentation lisible. Les tirets séparent des groupes standard et certains bits indiquent version et variante. L’unicité vient du mode de génération et de l’immense espace de valeurs, pas d’un registre mondial.

Avec un UUID v4 correctement généré, la plupart des bits sont aléatoires. Même à grande échelle, le risque de collision reste négligeable pour des applications ordinaires. Une contrainte unique en base reste toutefois nécessaire pour protéger l’intégrité.

L’indépendance change l’architecture

Un client peut créer un ID avant de synchroniser. Deux bases peuvent produire des lignes puis les fusionner. Un événement peut référencer une entité avant qu’un service central l’ait vue. Ces propriétés simplifient les workflows hors ligne, les imports et les systèmes distribués.

Un UUID public évite aussi de révéler un simple compteur. Il ne remplace pas l’autorisation. Un identifiant difficile à deviner reste un identifiant, pas un droit d’accès.

Les versions ont des propriétés différentes

La version 4 est aléatoire. La version 1 combine temps et information de nœud, ce qui peut révéler des détails. Des versions ordonnées par temps, comme v7, améliorent la localité des index. Les versions basées sur un nom produisent toujours le même UUID à partir du même namespace et nom.

Le choix dépend de confidentialité, ordre, déterminisme, performance et compatibilité. Une chaîne valide n’est pas automatiquement la bonne version pour le domaine.

Le stockage doit être réfléchi

Stocker un UUID en texte est pratique, mais plus volumineux. Un type UUID natif ou une représentation binaire peut réduire la taille des index. Les UUID aléatoires peuvent fragmenter les index ordonnés, surtout dans des workloads d’écriture intensifs.

Il faut mesurer avec des données proches de la production. Certaines applications utilisent UUID comme clé primaire, d’autres gardent une clé interne séquentielle et exposent un UUID public.

La forme canonique évite les doublons logiques

Les APIs devraient émettre une forme stable, souvent lowercase avec tirets. Accepter trop de variantes en entrée peut compliquer caches, logs et comparaisons. Une validation par bibliothèque est préférable à une regex improvisée.

Il faut distinguer syntaxe valide et politique autorisée. Un service peut accepter plusieurs versions anciennes tout en générant seulement une version moderne.

Les outils humains ont besoin de contexte

Un UUID est difficile à mémoriser et à dicter. Les panneaux internes doivent permettre copie exacte, recherche, et affichage d’un contexte lisible comme nom, statut ou date. Raccourcir l’UUID dans les endroits opérationnels peut provoquer des confusions.

Pour les utilisateurs finaux, un numéro métier ou un libellé peut coexister avec l’UUID technique. Les deux identités doivent avoir des rôles clairs.

Le lifecycle de l’identifiant doit être écrit

La facilité de génération ne signifie pas que chaque couche peut remplacer l’UUID. Il faut savoir qui le crée, quand il devient permanent, s’il peut être fourni par un client et s’il peut changer après publication. Sans règle, un service peut traiter l’ID comme mutable alors qu’un autre l’a déjà envoyé dans des événements.

Les retries doivent réutiliser le même identifiant logique. Sinon une action répétée après timeout crée plusieurs objets distincts, tous techniquement uniques mais métier incorrects.

Cette règle doit apparaître dans les contrats d’événements et les API de création. Un consumer ne devrait pas deviner si l’UUID est provisoire, définitif ou remplaçable après synchronisation.

Les logs ne doivent pas devenir la seule interface

Un UUID isolé dans un log ne suffit pas. Ajoutez request ID, type de ressource et environnement pour diagnostiquer rapidement. Cela évite de copier des identifiants entre outils sans savoir s’ils appartiennent au même tenant ou au même système.

Les outils de support devraient aussi accepter le collage d’un UUID complet et retourner un résultat unique ou aucun. Une recherche approximative sur des préfixes trop courts peut mener un opérateur vers la mauvaise ressource.

Les migrations doivent préserver l’identité

Lors d’un import legacy, générez les UUID une seule fois et gardez le mapping avec les anciennes clés. Régénérer à chaque passage casse les liens et l’idempotence. Un UUID déterministe peut aider si la source est stable et non sensible.

Les tests doivent couvrir rollback et réexécution. L’identité doit survivre aux pannes de migration.

UUID résout l’allocation, pas tout le système

Il supprime une coordination centrale pour créer des IDs. Il ne décide pas du stockage, de l’index, de l’autorisation, des migrations ou de la sérialisation. Ces responsabilités restent dans l’architecture.

Utilisé avec un générateur fiable, une version choisie, une contrainte unique et une politique claire, UUID est un outil puissant pour les systèmes distribués.