Résumé

  • La page bêta d’Unicode annonce une revue close, un examen des changements finaux par UTC #188 et une publication finale prévue le 16 septembre 2026.
  • Une proposition, un numéro de registre, une consultation, une décision UTC, un artefact final et une adoption logicielle ne répondent pas à la même question.
  • Un reçu d’état de publication peut rendre ces passages vérifiables sans transformer une date prévue en engagement.

Une date ne constitue pas un artefact

La page Beta Review Status présente Unicode 18.0.0 comme la prochaine version et inscrit le 16 septembre 2026 dans sa ligne de publication finale. Elle qualifie ce calendrier de prévisionnel. La même page dit que la revue bêta est fermée et que les retours ainsi que les changements techniques finaux seront examinés à UTC #188.

Ces éléments ont chacun une portée propre. Une date aide une équipe à réserver du temps. La clôture d’une consultation décrit l’état d’une phase publique. Un examen annoncé par le comité signale qu’une étape institutionnelle reste dans la séquence. Aucun de ces faits ne fournit à lui seul un identifiant final, une empreinte de fichier, une heure de publication, ni la preuve qu’un système d’exploitation, une police, une bibliothèque ou un service a adopté la nouvelle donnée.

Le risque est concret. Une équipe produit peut annoncer un support avant l’artefact final. Un acheteur peut classer une version prévue comme exigence satisfaite. Un mainteneur peut conserver un fichier bêta dans une chaîne de construction sans distinguer ensuite cette expérience du support de la version finale. La revue précoce n’est pas le problème; l’erreur consiste à lui attribuer la force probante de l’étape suivante.

Ce que signifie réellement la bêta

Unicode distingue explicitement alpha et bêta. L’alpha porte sur le répertoire et les tableaux attendus; son périmètre est assez ferme mais peut encore évoluer. La bêta décrit un répertoire établi et stable, tandis que la revue porte surtout sur les propriétés de caractères et les changements algorithmiques susceptibles d’affecter les implémentations. La page mentionne aussi des fichiers UCD complets, des normes synchronisées, des tableaux préliminaires et des annexes mis à jour pour cette revue.

Le mot « stable » est donc délimité. Il ne rend pas tous les éléments définitifs. Il ne transforme pas une date en publication accomplie. Il n’autorise pas à présenter un téléchargement bêta comme preuve de compatibilité de production. Il indique aux relecteurs quels objets examiner et quel type de retour peut encore être utile.

Une équipe peut légitimement documenter un essai interne d’un artefact bêta identifié: version, empreinte, date et portée. Elle doit ensuite documenter séparément l’artefact final qu’elle accepte. Cette séparation protège deux réalités: l’essai précoce a eu lieu, mais le support final ne peut être affirmé qu’après la publication de sa preuve.

Un registre n’est pas une décision

Le registre documentaire UTC est une forme précieuse de garde publique. Il donne aux documents une place durable, et sa page Pipeline décrit des caractères et écritures approuvés qui peuvent encore être en revue ou en scrutin ISO et ne sont pas publiés dans une version d’Unicode. « Approuvé » et « publié » ne sont donc pas synonymes.

Les règles de soumission ajoutent une autre frontière: un document peut être préexaminé, révisé, différé, posté plus tard ou refusé pour le registre. Un numéro de document établit un parcours de traitement documenté; il ne prouve pas, à lui seul, une décision technique, une version finale ou un résultat déployé.

Les procédures des groupes techniques sont claires: les décisions techniques relèvent du comité technique, exigent un quorum au moment où elles sont prises et enregistrées, et doivent être consignées. Un groupe de travail formule des recommandations, non des décisions techniques. Les Public Review Issues ont un titre et une échéance, mais ni leur libellé ni les commentaires reçus ne lient les décisions du comité.

Un reçu d’état plutôt qu’une promesse

Le remède est un reçu d’état versionné: version et phase; fenêtre de revue et objet annoncé; liens de proposition, registre ou consultation; décision UTC applicable lorsqu’elle est publique; URL, libellés, empreintes et heure des artefacts finaux; puis preuve distincte d’adoption par une implémentation donnée.

Chaque champ répond à une seule question: soumission, revue, décision, publication ou adoption. Une inconnue reste inconnue. Le reçu ne déduit ni décision d’un numéro, ni fichier publié d’une date, ni déploiement d’une annonce.

Sources

  1. Unicode Beta Review Status
  2. Unicode Technical Group Procedures
  3. UTC Document Registry
  4. How to Submit Proposal Documents
  5. Unicode Technical Committee
  6. Heng Lu — The Registry Continuity Fallacy
  7. Heng Lu — The Multi-Stakeholder Mirage