Génération d'identifiants uniques avec l'API Web Crypto

Tout développeur frontend est confronté tôt ou tard à ce problème : vous avez besoin d’un identifiant unique pour des données côté client, mais il n’y a pas encore d’ID généré par le serveur. Peut-être construisez-vous une liste de tâches, gérez des champs de formulaire ou suivez des éléments avant leur persistance. Vous avez besoin de quelque chose de fiable, et vous en avez besoin maintenant.

La bonne nouvelle ? Les navigateurs modernes intègrent une solution native. L’API Web Crypto fournit crypto.randomUUID()—une méthode simple et sécurisée pour générer des identifiants uniques dans le navigateur sans installer de bibliothèques.

Pourquoi crypto.randomUUID() devrait être votre choix par défaut

La méthode crypto.randomUUID() produit des UUID version 4 conformes à la RFC 9562 (anciennement RFC 4122) en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé. Le résultat ressemble à ceci :

550e8400-e29b-41d4-a716-446655440000

Il s’agit d’une chaîne de 36 caractères avec 122 bits d’aléa. La probabilité de collision est astronomiquement faible—il faudrait générer un milliard d’UUID par seconde pendant environ 85 ans pour atteindre 50 % de chance d’une seule collision.

Voici à quel point c’est simple :

function generateId() {
  return crypto.randomUUID()
}

const newItem = { id: generateId(), label: 'My item' }

Cette méthode fonctionne dans tous les navigateurs modernes (Chrome 92+, Firefox 95+, Safari 15.4+), s’exécute dans les Web Workers et ne nécessite aucune dépendance.

L’exigence de contexte sécurisé

Un détail crucial : crypto.randomUUID() ne fonctionne que dans des contextes sécurisés. Cela signifie HTTPS en production ou localhost pendant le développement. Si vous testez en HTTP simple sur un domaine autre que localhost, la méthode ne sera pas disponible.

Cette exigence existe car l’API Web Crypto fournit des primitives cryptographiques qui ne devraient pas être exposées dans des environnements non sécurisés.

Pourquoi les anciennes approches sont insuffisantes

Avant que crypto.randomUUID() ne devienne largement disponible, les développeurs se tournaient souvent vers des alternatives qui semblent raisonnables mais présentent de vrais problèmes.

Math.random() n’est pas cryptographiquement sécurisé. Sa sortie peut être prévisible, et les collisions sont beaucoup plus probables qu’on ne le penserait dans des applications en production.

Les horodatages (comme Date.now()) échouent lorsque plusieurs identifiants sont générés dans la même milliseconde—un scénario courant dans les boucles ou les opérations par lots.

Les générateurs ad hoc combinant horodatages et nombres aléatoires sont meilleurs, mais ils réinventent un problème déjà résolu avec moins de rigueur que ce que la plateforme fournit nativement.

Pour la génération sécurisée d’identifiants côté client, crypto.randomUUID() est le choix évident.

Considérations pratiques pour le frontend

Générer une fois, stocker immédiatement

L’erreur la plus courante est de générer des identifiants pendant les cycles de rendu. Au lieu de cela, créez l’identifiant lors de la création de l’objet et stockez-le :

// ✓ Correct : ID généré au moment de la création
function addItem(label) {
  return { id: crypto.randomUUID(), label }
}

// ✗ Incorrect : ID généré pendant le rendu
items.map(item => <li key={crypto.randomUUID()}>{item.label}</li>)

Générer un nouvel UUID à chaque rendu va à l’encontre du but des clés stables. React, par exemple, utilise les clés pour suivre les éléments à travers les rendus successifs. Une nouvelle clé à chaque fois force une destruction et une recréation inutiles du DOM.

SSR et environnements navigateur

Si vous utilisez le rendu côté serveur, crypto.randomUUID() est disponible dans Node.js 19+ et les versions récentes d’autres runtimes. Pour les versions plus anciennes de Node ou les cas particuliers, vérifiez la disponibilité avant d’appeler :

const id = typeof crypto !== 'undefined' && typeof crypto.randomUUID === 'function'
  ? crypto.randomUUID()
  : fallbackGenerator()

Une stratégie de repli légère

Pour les environnements où crypto.randomUUID() n’est pas disponible, crypto.getRandomValues() bénéficie d’un support plus large (y compris Node.js 16+) et peut générer des UUID sans bibliothèques :

function fallbackUUID() {
  const bytes = crypto.getRandomValues(new Uint8Array(16))
  bytes[6] = (bytes[6] & 0x0f) | 0x40 // Version 4
  bytes[8] = (bytes[8] & 0x3f) | 0x80 // Variant 10
  
  const hex = [...bytes].map(b => b.toString(16).padStart(2, '0')).join('')
  return `${hex.slice(0, 8)}-${hex.slice(8, 12)}-${hex.slice(12, 16)}-${hex.slice(16, 20)}-${hex.slice(20)}`
}

Cela définit manuellement les bits de version et de variante pour produire un UUID v4 valide, en utilisant la même source aléatoire cryptographiquement sécurisée sous le capot.

Quand les bibliothèques ont encore du sens

Bien que crypto.randomUUID() couvre la plupart des cas, vous pourriez vous tourner vers une bibliothèque comme uuid ou nanoid lorsque vous avez besoin de :

• Versions d’UUID autres que v4 (v1, v5, v7)
• Identifiants plus courts pour les URL ou les affichages destinés aux utilisateurs
• Compatibilité garantie entre environnements avec des runtimes plus anciens

Mais pour la génération standard d’identifiants sécurisés côté client, l’API native devrait être votre point de départ.

Conclusion

crypto.randomUUID() vous offre des UUID conformes à la RFC et cryptographiquement sécurisés sans aucune dépendance. Générez les identifiants au moment de la création de l’objet, pas pendant les rendus. Utilisez HTTPS en production. Pour les cas particuliers, repliez-vous sur crypto.getRandomValues(). Le navigateur a déjà ce dont vous avez besoin—utilisez-le.

FAQ

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.