JSON et Unicode : préserver les identifiants et textes du catalogue voyage

Définir les types avant de convertir

Le format JSON possède notamment chaînes, nombres, booléens, tableaux, objets et null. Il ne donne pas à lui seul le sens métier d’un champ. Dans le contrat d’échange, précisez ce qui est identifiant, quantité, montant ou date. Une référence contenant seulement des chiffres peut rester une chaîne pour conserver ses zéros et sa forme exacte. Un montant exige devise et unité ; la présence d’un nombre dans le message ne démontre pas que la valeur soit en euros ou en unités majeures.

Préparez un jeu de test dont chaque valeur répond à une question : référence avec zéro initial, quantité nulle, champ absent et texte vide. Comparez le message, la transformation, l’enregistrement et l’export. Si l’outil convertit automatiquement une référence, corrigez le mapping plutôt que le nom affiché. Le support doit pouvoir rapprocher la référence source et celle de l’application, sans reconstruire une valeur supposée à partir de son apparence.

Garder les valeurs inconnues distinctes

Un champ absent, une valeur null, une chaîne vide et zéro ne sont pas interchangeables. Le contrat métier doit définir lesquels sont autorisés et leur conséquence. Pour un équipement hôtelier, absence de donnée ne signifie pas équipement absent ; pour un coût, inconnu ne signifie pas gratuit. Décrivez le comportement attendu dans les recherches et affichages : masquer la promesse, demander confirmation ou conserver un statut explicite selon le besoin.

Faites rejouer un import partiel et une mise à jour. Certains échanges modifient uniquement les champs envoyés, d’autres remplacent un objet ; cette sémantique doit être documentée par l’interface concernée. N’attribuez pas une règle unique à tous les messages JSON. Retrouvez la valeur avant et après ainsi que l’origine de la modification. Le critère de réussite est la conservation du sens convenu, y compris lorsqu’une information est retirée ou encore indéterminée.

Vérifier les textes dans les langues utiles

RFC 8259 impose UTF-8 aux échanges JSON entre systèmes hors écosystème fermé. Cette exigence concerne le transport ; elle ne garantit ni qualité de traduction ni correspondance des noms. Préparez des textes autorisés avec accents, apostrophes, caractères non latins et signe monétaire. Comparez les chaînes reçues et exportées, puis leur rendu dans les fiches et documents. Ne réduisez pas le test à une seule langue parce que l’équipe de recette travaille en français.

Séparez libellé d’affichage et clé de rapprochement. Une recherche peut normaliser accents et ponctuation pour aider l’utilisateur, tandis que le dossier conserve le nom ou la référence source. Toute translittération destinée à un fournisseur doit suivre son contrat et rester traçable. Contrôlez également les sauts de ligne et caractères échappés : le résultat doit afficher le texte voulu, sans laisser une séquence technique visible ni interpréter une description comme du code.

Refuser une ambiguïté silencieuse

RFC 8259 recommande des noms de membres uniques dans un objet ; le comportement des lecteurs peut différer si une clé apparaît plusieurs fois. Ajoutez un contrôle des clés répétées au point d’entrée plutôt que d’accepter une valeur arbitraire. Le même standard avertit des limites d’interopérabilité des nombres selon les implémentations. Une grande référence numérique doit donc être traitée selon le type convenu avec l’émetteur, sans la convertir par commodité.

Créez un essai pédagogique avec deux valeurs incompatibles pour le même champ et relevez la réaction du système. Le dossier doit être rejeté ou suivi selon une règle explicite, avec un motif exploitable et la source à corriger. Ne faites pas rejouer un flux ambigu sur des réservations réelles. Lorsque l’erreur touche plusieurs enregistrements, identifiez la population concernée avant d’appliquer une correction ; un import qui termine sans erreur ne prouve pas que toutes les valeurs ont été conservées.

Comparer un aller-retour complet

Le test le plus utile commence avec un message de référence, passe par l’import et se termine par un export relisible. Comparez les objets métier et les champs qui comptent, plutôt que l’ordre de toutes les clés ou la présentation du fichier. Conservez le résultat attendu pour chaque cas et la transformation autorisée. Une représentation différente peut être acceptable si le sens et les références sont conservés ; une chaîne devenue nombre peut être un échec même si l’écran paraît identique.

Transmettez version de contrat, cas anonymisés, écarts et corrections au propriétaire de l’intégration. Distinguez erreur de syntaxe, type invalide et incohérence métier pour orienter la reprise. Après correction, rejouez le cas concerné et un cas voisin qui devait rester inchangé. Le suivi mesure les enregistrements rejetés, repris et encore indéterminés sur une période définie. Il ne transforme pas le nombre de messages reçus en preuve de qualité du catalogue.

Sources et périmètre des faits documentés

La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.

• RFC 8259 : format JSON — Types du format, UTF-8, unicité recommandée des membres et limites d’interopérabilité ; les règles métier restent à définir. (consultée le 08/10/2026)