Résumé

  • UUIDv7 place dans ses 48 premiers bits un nombre de millisecondes depuis l’époque Unix. Les autres bits utiles servent par défaut au hasard, ou facultativement à une fraction de temps et à un compteur. Ce dessin favorise le tri, non la preuve d’une histoire.
  • RFC 9562 autorise l’altération de l’horodatage et ne garantit pas sa proximité avec l’heure réelle. Les retours d’horloge, les lots, les compteurs et leur débordement restent des choix et des risques d’implémentation.
  • Pour soutenir une conclusion, un UUID doit être relié à la politique du générateur, à l’écriture durable, à l’autorité de l’acteur, à une attestation temporelle distincte si elle est requise, puis à l’effet observé.

Une amélioration d’index n’est pas une source d’autorité

RFC 9562 définit UUIDv7 comme un identifiant de 128 bits dont les 48 premiers contiennent un horodatage Unix en millisecondes, en ordre big-endian. Après les bits imposés de version et de variante, rand_a et rand_b offrent 74 bits utilisables. Ils reçoivent normalement de l’aléa; une implémentation peut y placer, dans un ordre déterminé, une fraction de milliseconde, un compteur initialisé avec soin et de l’aléa résiduel.

Cette disposition résout un problème concret. Une base peut comparer directement les octets, rapprocher les nouvelles insertions et limiter la dispersion qui accompagne des clés entièrement aléatoires. RFC 9562 présente explicitement UUIDv6 et UUIDv7 comme triables sous forme d’octets bruts et sous forme textuelle. C’est une propriété de représentation et de stockage. Ce n’est ni une signature de l’horloge, ni une position dans un consensus, ni une preuve que la ligne correspondante est devenue durable.

L’identifiant peut être créé avant que le système ait décidé d’accepter une demande. Il peut survivre au rejet d’une transaction. Il peut suivre un message dans une boîte d’envoi puis apparaître plusieurs fois lors d’une reprise. Il peut relier les journaux de plusieurs composants sans que ces composants aient observé l’action dans le même ordre. Dans chacun de ces cas, l’UUID garde une grande valeur de corrélation. Il ne gagne pas, par cette seule persistance, le pouvoir d’attester l’événement.

Le champ temporel n’est pas une horloge garantie

La section consacrée aux horodatages est plus prudente que beaucoup d’interfaces. Elle demande de tenir compte des changements de l’environnement ou du système d’exploitation lorsque ceux-ci peuvent faire reculer l’horloge, notamment après un ajustement manuel ou une correction de synchronisation. Puis elle laisse le traitement de ces cas aux exigences de l’implémentation.

La limite est encore plus nette : RFC 9562 indique qu’une implémentation peut modifier l’horodatage réel pour corriger une horloge imprécise, traiter les secondes intercalaires ou obtenir une valeur plus pratique, et ne fixe aucune exigence ni garantie sur la proximité entre la valeur incorporée et le temps réel. Un champ de millisecondes est donc un renseignement sur la politique du générateur, pas une expertise indépendante sur l’instant du monde.

Les valeurs produites pendant une même milliseconde montrent pourquoi. Un générateur peut accepter leur ordre aléatoire. S’il veut une monotonie additionnelle, il doit organiser un compteur ou exploiter une précision supplémentaire. Le choix d’un compteur implique un espace, une graine, un comportement au redémarrage et une règle de débordement. RFC 9562 demande que l’application gère le débordement afin d’éviter les erreurs de tri et recommande de détecter une valeur qui ne dépasse pas la précédente. Une liste propre n’est donc jamais une excuse pour oublier la politique qui l’a rendue propre.

Partager un format n’installe pas une mémoire commune

UUIDv7 évite un registre central parce que c’est souvent souhaitable. RFC 9562 observe néanmoins que la véritable unicité mondiale est impossible à garantir sans schéma de connaissance partagée. Une unicité locale peut être suffisante; le format n’exige pas de séquenceur global. Des nœuds indépendants peuvent donc émettre des clés compatibles tout en gardant des sources de temps, des états de compteur, des redémarrages et des chemins de persistance différents.

Il faut accepter les deux côtés de cette conception. Elle diminue la coordination nécessaire pour identifier une chose. Elle ne diminue pas la coordination nécessaire pour établir un ordre de responsabilité entre plusieurs choses. Un UUID lexicalement inférieur n’est pas nécessairement une opération arrivée avant une autre au destinataire, un engagement validé avant une autre demande, ou la cause de l’effet suivant. Le format donne une piste de comparaison; il ne fournit pas le procès-verbal partagé.

RFC 9562 conseille d’ailleurs de traiter les UUID comme opaques lorsque leur analyse n’est pas nécessaire. Le conseil protège contre une tendance fréquente : extraire une partie lisible d’un identifiant et lui attribuer davantage de sens que l’émetteur n’en a garanti.

Le dossier qu’un identifiant ne peut pas contenir seul

Une organisation qui doit expliquer une opération sensible peut garder l’UUIDv7 comme lien principal, mais doit conserver au moins cinq autres surfaces de preuve.

  1. Le dossier de génération : version du générateur, source de temps, précision, règle de compteur, reprise et erreurs.
  2. Le dossier de transition : validation, commit durable, échec, publication dans l’outbox, reprise et réconciliation.
  3. Le dossier d’autorité : acteur, service délégué, approbation, règle et périmètre de permission.
  4. Le dossier temporel externe, lorsque l’enjeu le justifie. RFC 3161 décrit un jeton signé par une autorité d’horodatage, portant sur l’empreinte d’une donnée et une politique identifiée. Le demandeur doit vérifier l’empreinte, la signature, le certificat, la fraîcheur ou le nonce, ainsi que l’acceptabilité de la politique. Ce mécanisme soutient une affirmation beaucoup plus étroite : une donnée existait avant un temps selon une politique. Il ne désigne ni auteur, ni détenteur de droit, ni résultat ultérieur.
  5. Le dossier d’effet : l’état effectivement reconnu par le système de réception, le règlement, la configuration appliquée, la décision d’accès ou la compensation.

L’application éditoriale de Heng Lu est simple : le code qui a réellement généré, validé, appliqué ou refusé une opération doit pouvoir contredire l’histoire décorative produite par une colonne triée. La règle commune doit rester mince; l’interprétation et le risque de décision doivent rester localisés et attribuables.

Sources