Résumé

  • RFC 9553 sélectionne un PatchObject par étiquette de langue, copie la Card sans localizations, applique la totalité du correctif puis utilise cette copie comme variante localisée.
  • Le rejet atomique interdit une localisation partiellement appliquée ; il ne certifie ni l’auteur du texte, ni le caractère officiel d’un alias, ni l’actualité des coordonnées.
  • La preuve exploitable relie l’empreinte de la base, la langue choisie, le correctif exact, son autorisation, l’empreinte de sortie et l’usage aval.

Une vue complète peut rester dérivée

L’interface ne montre pas un diff. Elle montre une fiche entière. Le lecteur voit un nom, une fonction, une adresse et peut-être une photographie ; le résultat paraît autonome. C’est précisément à cet endroit que l’apparence dépasse facilement le modèle.

RFC 9553 donne à une Card une langue principale et, facultativement, une table localizations. Les clés sont des étiquettes RFC 5646 ; les valeurs sont des PatchObjects. Pour produire une variante, l’implémentation détermine la langue, récupère le correctif correspondant, crée une copie sans recopier localizations, applique le correctif et peut changer la propriété language de la copie.

Le mot décisif est « copie ». Le RFC ne crée pas un autre uid, une autre histoire de révision ou un autre responsable des faits. La variante hérite de presque tout son contenu de la Card choisie au moment de l’opération. Elle dépend aussi du correctif et de la règle qui a choisi la langue.

Si une plateforme enregistre seulement le HTML final, elle perd ces dépendances. Un intitulé erroné ne peut plus être attribué à la base, au correctif, au choix de langue ou à une ancienne version. La localisation devient alors une duplication opaque plutôt qu’une projection reproductible.

L’atomicité protège la forme

Le PatchObject de RFC 9553 utilise un sous-ensemble de JSON Pointer. Le slash initial est implicite. Les segments précédant le dernier doivent déjà exister. Une case de tableau peut être remplacée, mais l’indice ne peut servir à insérer ou supprimer. Deux chemins ne peuvent se recouvrir par préfixe. La nouvelle valeur doit respecter le type et les contraintes de la propriété ; null ne peut retirer qu’une propriété optionnelle.

Une seule erreur invalide tout le PatchObject. L’implémentation doit refuser l’ensemble et ne peut pas conserver les modifications qui auraient réussi. Cette règle évite une adresse à moitié adaptée ou un nom dont seuls certains composants auraient changé.

Elle ne résout cependant pas la question éditoriale. « Tout le correctif est valide » signifie que la transformation respecte le modèle contre cette base. Cela ne signifie pas que la formulation française est naturelle, que le titre professionnel est encore vrai ou que la personne a approuvé l’orthographe affichée.

Une chaîne de production doit donc conserver plusieurs verdicts : validation de structure, authentification de la source, autorisation sur le champ, validation d’identité et résultat d’usage. Les fusionner dans le statut « localisé » revient à attribuer au parseur un pouvoir qu’il n’a jamais exercé.

Le chemin appartient à une version précise

Le RFC montre un remplacement complet de name, puis un correctif étroit sur titles/t1/name. Le deuxième conserve les autres membres de l’objet t1. Il est élégant parce qu’il modifie seulement la chaîne traduite.

Mais il suppose que titles, t1 et name désignent encore ce que l’éditeur avait examiné. Les clés de type Id doivent être préservées entre les versions d’un même objet JSContact, notamment pour rendre ces corrections stables. Elles restent des coordonnées locales : le même identifiant dans deux tables ou deux Cards ne crée aucune relation sémantique.

La conséquence opérationnelle est simple. Un correctif accepté pour l’empreinte A ne devrait pas être appliqué sans trace à l’empreinte B. Si t1 a changé de sens, le chemin peut rester valide et produire une traduction devenue fausse. Si t1 disparaît, le correctif doit échouer. Si seule une donnée sans rapport change, le correctif peut rester valable, mais cette décision demande une règle de révision.

L’horodatage updated ne reconstruit pas cette histoire. Il indique la dernière modification des données de la Card, pas le champ modifié, l’auteur, la source, la valeur précédente ou les localisations revues. prodId nomme un produit, pas un signataire. version nomme le modèle JSContact, pas la révision métier.

Une étiquette de langue n’est pas une attestation de nom

RFC 5646 permet de décrire langue, écriture et région. Le format JSContact s’en sert pour indexer les alternatives. Avant l’application, quelqu’un ou quelque chose doit « déterminer » l’étiquette. Le RFC ne définit pas toute la politique de négociation d’une application : correspondance exacte, repli, préférence de script et arbitrage régional restent des décisions de produit.

Une étiquette correcte ne prouve pas non plus la nature du texte. Le nom localisé d’une institution peut être son nom officiel, une traduction consacrée, une translittération, une commodité éditoriale ou une invention. Pour une personne, changer d’écriture peut conserver fidèlement le nom ou en fabriquer un autre.

Le rôle du PatchObject est de transporter une alternative, pas de décider laquelle de ces catégories s’applique. Lorsqu’un nom de personne ou d’organisation est concerné, la preuve devrait citer une source multilingue officielle, un alias validé par le sujet ou une règle de translittération revue. À défaut, le système sait seulement afficher une variante.

Cette distinction protège aussi les autres données. Une adresse localisée peut réordonner des composants sans changer le lieu ; elle peut également introduire une région incorrecte. Une fonction traduite peut être fidèle au poste ou lui donner un rang différent. Le contrôle doit porter sur le sens, pas seulement sur la langue.

La menace est plus crédible lorsqu’elle est bien écrite

Les considérations de sécurité de RFC 9553 qualifient les coordonnées de très sensibles : elles peuvent révéler identité, localisation, informations d’identification, emploi, intérêts et réseau social. Le texte cite écoute, rejeu, insertion, suppression, modification et attaque sur le chemin.

Il décrit surtout un scénario directement lié à l’autorité : un acteur malveillant peut reprendre le nom d’une autre personne et insérer ses propres moyens de contact. Une version localisée naturelle peut renforcer cette usurpation. Le lecteur reconnaît son écriture, un titre plausible et une formule locale ; il est alors moins susceptible de vérifier le courriel ou le numéro.

Le RFC demande aux systèmes ayant des conséquences réelles d’authentifier les données reçues et de s’assurer que le changement vient d’une entité autorisée. Puis il limite clairement son propre rôle : il spécifie le format, non l’API, le stockage ou le transport.

Un canal authentifié peut donc prouver quel service a livré la Card. Il ne prouve pas nécessairement que ce service pouvait modifier le nom, la relation et le téléphone. Une signature peut attribuer le correctif sans donner le consentement du sujet. La conformité JSON peut rejeter un pointeur invalide sans reconnaître un mensonge parfaitement typé.

Le registre coordonne le vocabulaire

RFC 9553 inscrit la version 1.0 et crée des registres IANA pour versions, propriétés, types et valeurs énumérées. Les bornes Since Version et Until Version permettent de savoir dans quel modèle un élément est défini. C’est un mécanisme d’interopérabilité essentiel.

Il ne certifie pas les faits contenus dans une instance. « Propriété enregistrée » ne veut pas dire « valeur vérifiée ». « Card valide » ne veut pas dire « contact vérifié ». Le premier jugement appartient au modèle ; le second demanderait une preuve d’origine, de pouvoir et d’observation.

Le tableau de bord devrait exposer le modèle et l’instantané du registre utilisés. Une implémentation qui accepte une extension inconnue ou obsolète doit aussi le signaler. Mais cette transparence ne remplace toujours pas la provenance des valeurs.

Conserver une lignée légère

Il suffit d’un reçu compact pour éviter que la projection se transforme en autorité autonome. Il contient l’uid, la version du modèle, l’empreinte et la révision de la Card de base ; la règle ayant choisi la langue ; l’empreinte du PatchObject et son auteur ; la portée de l’autorisation ; le résultat atomique ; l’empreinte de la sortie et l’usage aval.

Pour un nom protégé, le reçu ajoute la décision qui autorise l’alias ou la translittération. Pour une coordonnée utilisée par une automatisation, il ajoute l’action : appel lancé, message remis, accès accordé ou paiement redirigé. L’effet ne doit pas être déduit du simple rendu.

Cette lignée permet de traiter les mises à jour. Un changement de base peut invalider seulement une localisation, toutes les localisations ou aucune. Le système peut demander la bonne révision plutôt que recopier aveuglément des vues devenues indépendantes.

La localisation garde alors sa fonction réelle : rendre une même Card lisible dans plusieurs contextes humains tout en laissant visible la chaîne de responsabilité qui lui donne son sens.

Sources