Chaque article JSON doit avoir un identifiant stable, un slug unique, une date de publication et une date de modification. Le fichier doit aussi annoncer sa version de schéma et sa propre date de mise à jour.
La réponse utile dépend de l’objectif de la page, des personnes autorisées à la modifier et du coût d’une erreur. Un workflow fiable sépare la décision éditoriale, la diffusion technique et la vérification finale au lieu de cacher ces trois étapes dans une seule automatisation.
La décision à prendre en premier
Versionnez les données et leur structure. Ajouter un champ optionnel est simple ; renommer ou supprimer un champ exige une migration explicite, un contrôle des lecteurs et un historique vérifiable.
Une méthode concrète
- Attribuer un identifiant immuable indépendant du titre.
- Conserver les slugs publiés ou préparer une redirection.
- Trier les clés de façon cohérente pour obtenir des différences lisibles.
- Contrôler doublons, types et dates avant chaque commit.
- Étiqueter dans Git les lots éditoriaux importants.
Contrôles avant publication
- La source de vérité est explicite et peut être restaurée.
- Les URL, les dates et les affirmations visibles correspondent à la page diffusée.
- Un relecteur humain peut reproduire le contrôle sans service caché.
Le principal piège
Réutiliser un identifiant ou régénérer tous les slugs crée collisions, liens cassés et perte de traçabilité. L’identité d’un article ne doit pas dépendre d’un champ éditable.
Prochaine étape recommandée
Écrivez un contrôle CLI qui compte les articles, repère les slugs en double et valide les champs requis dans chaque langue.
Atelier de vérification : une preuve avant la décision
Exercice proposé sur un périmètre choisi, avec des données fictives si nécessaire. Consignez le résultat observé ; ce scénario ne décrit pas un test déjà réalisé sur votre site.
- Manipulation à essayer
Sur une copie de travail, corrigez une phrase d’un article JSON en conservant son identifiant. Comparez les données avant et après, puis régénérez la page.
- Trace à conserver
Gardez le diff, le résultat du parseur JSON et la page rendue. Vérifiez que titre, URL, relations et contenus voisins n’ont pas changé involontairement.
- Ce que la preuve ne démontre pas
Un JSON valide peut contenir une erreur factuelle. Un identifiant stable ne garantit pas à lui seul une publication ou un retour arrière corrects.
Exemple de changement à versionner
Une équipe corrige le délai de réponse annoncé dans douze articles stockés en JSON. Elle modifie d’abord la donnée de référence, relève les douze identifiants touchés, puis vérifie que les titres, dates et liens n’ont pas changé accidentellement. Une comparaison des fichiers avant publication montre précisément les réponses retouchées.
Gardez un identifiant stable pour chaque article et validez le JSON avant de déployer. Si une correction ne concerne qu’une phrase, elle ne doit pas provoquer une nouvelle URL ni effacer l’historique. Notez la raison du changement et la personne qui l’a validé.