Refondre 938 pages depuis un corpus JSON

#Refondre 938 pages depuis un corpus JSON

nehos-groupe.com est un produit du groupe, pas une mission client. Ses 938 pages ne vivent pas dans une base de données : elles tiennent dans des fichiers JSON versionnés, lus au build par un pipeline qui les rend en HTML statique. Mesure du 8 septembre 2026, production mobile : score performance Lighthouse 95, LCP 2,8 s, CLS 0,001.

#Le problème n'était pas d'écrire les pages, c'était de pouvoir les corriger

Un site de 938 URL change d'échelle. À dix pages, vous corrigez à la main. À cent, vous cherchez et remplacez. À neuf cents, une affirmation écrite en juin est reformulée de quinze façons en août, et vous n'avez plus de moyen fiable de savoir où elle se cache.

Nous avons rencontré ce mur sur notre propre site. La première version partait d'une architecture orthodoxe : Next.js 16, Payload CMS 3, PostgreSQL, Docker. Le contenu était rédigé en JSON, importé en base par un script, puis servi depuis cette base. Cela fonctionnait. Deux défauts nous ont fait changer d'avis.

Le premier : une fois importée, une page n'existait plus qu'en base. Plus lisible dans un diff, plus trouvable en une commande, plus relisible par qui n'ouvrait pas l'administration. Indifférent sur un site vitrine de vingt pages ; angle mort sur un corpus de neuf cents pages qui engage la parole du groupe.

Le second, plus brutal : la base et les fichiers ont divergé. Le formulaire de devis de la page d'audit avait été ajouté directement en base. Le jour où le pipeline Payload a été abandonné, il a disparu de la page — pendant que 1 062 boutons du site, dont celui de l'en-tête, continuaient de pointer vers son ancre. Un appel à l'action qui ne mène nulle part, sur le point d'entrée commercial du site.

Nous avons pris la décision inverse de l'usage : supprimer la base, faire des fichiers la source de vérité unique.

#Ce que nous avons construit

Le site n'a plus ni base de données ni serveur Node en production. next.config.ts déclare output: 'export' : le build produit un dossier de fichiers, et rien d'autre. Ce dossier part sur Netlify. C'est l'approche Jamstack dans sa forme la plus stricte, et la stack que nous livrons en développement Next.js et React sur les projets clients.

Entre le corpus et le HTML, un module de 410 lignes parcourt le dossier de contenu, écarte les trois fragments d'interface partagés — en-tête, pied de page, bandeau — et construit un index en mémoire clé par chemin public. Il reste 938 pages : exactement le nombre d'URL du sitemap publié, et d'entrées du manifeste de soumission aux moteurs.

Chaque page traverse trois passes.

La normalisation ramène les champs hétérogènes à une forme unique. Le corpus a été rédigé sur plusieurs mois : le champ faq y est tantôt un objet, tantôt un tableau ; un comparatif tantôt décrit par critères et solutions, tantôt par en-têtes et lignes. Tant que le CMS servait les pages, ces variantes n'atteignaient jamais les gabarits ; en lecture directe, elles font tomber le rendu.

La construction des blocs dérive du JSON une liste de blocs typés : hero, essentiel, fil d'Ariane, statistiques, FAQ, appel à l'action, cartes, formulaire, outil interactif. Nous avons repris la logique de l'ancien script d'import à l'identique : l'objectif n'était pas un rendu équivalent après le changement de source, mais le même rendu, pour que la refonte ne se paie pas en régressions invisibles réparties sur neuf cents pages.

Le nettoyage retire les champs de pilotage éditorial. Next sérialise l'objet de page entier dans le HTML : grilles d'auto-évaluation E-E-A-T, notes anti-duplication et arbitrages internes se retrouvaient lisibles dans le code source. La première version ne traitait que la racine et laissait passer les champs imbriqués — 76 pages exposaient encore leur mécanique de rédaction. Il est désormais récursif.

Les blocs partent enfin dans un routeur qui mappe 18 types vers autant de composants React, tandis que le champ template choisit l'un des 7 gabarits : article, cas client, comparatif, glossaire, pilier, service, cas d'usage.

#Les choix techniques, et pourquoi

Statique plutôt que rendu à la demande. Un site éditorial dont le contenu change par commits n'a aucun besoin d'un serveur. Le statique supprime une classe entière d'incidents d'exécution et rend le coût d'hébergement indépendant du trafic. Le prix à payer est réel : l'optimiseur d'images de Next ne fonctionne plus, les fichiers sont servis tels quels — une photo de 520 Ko affichée dans une vignette de 144 px partait entière. Nous traitons donc les images au build : plafond à 1200 px de large, recompression, conversion en WebP. Quarante-six fichiers, de 7,0 Mo à 3,0 Mo.

Générer les visuels depuis le corpus plutôt que les produire un par un. Toutes les pages émettaient la même image de partage : sur LinkedIn, un article de blog et une fiche service s'affichaient à l'identique. Un script de build compose désormais une vignette 1200 × 630 par page éditoriale — fond de marque, surtitre de section, titre réel de la page en serif à une taille qui s'adapte à sa longueur, nom de domaine. 551 vignettes générées quand le corpus en comptait 915 ; il en compte 938 aujourd'hui. Trente-huit kilo-octets en moyenne, en aplats plutôt qu'en dégradé : le bruit d'un dégradé triplait le poids du JPEG pour une différence invisible à taille d'aperçu. Si le fichier manque, la page retombe sur la vignette générique — aucune page ne peut se retrouver sans aperçu.

Chercher la cause, pas le symptôme. Pendant six semaines, Lighthouse a renvoyé « NO_LCP » sur la page d'accueil, donc aucun score de performance du tout, alors que les pages internes mesuraient 91 et 93. Six hypothèses ont été éliminées par la mesure, pas par intuition : cache du CDN, outillage, canvas décoratif, animation du titre, hero pleine hauteur, HTML pourtant identique octet pour octet. La cause tenait dans une classe CSS. Le carrousel de cas d'usage portait un scroll-snap obligatoire, et la trace brute raconte tout : la piste émet six événements de scroll entre 1325 et 1414 ms, le First Contentful Paint tombe à 1399 ms, les candidats LCP sont invalidés à 1541 puis à 2210 ms. Chrome abandonne la mesure du Largest Contentful Paint dès qu'un défilement lui est notifié — et le scroll-snap recale la piste à chaque changement de mise en page, donc à chaque police qui arrive et à chaque image décodée. Le snap ne s'applique plus qu'après chargement.

Deux autres corrections ont suivi la même logique. Le H1 apparaissait en fondu depuis une opacité nulle : Chrome n'enregistre aucun candidat tant que son plus grand texte est invisible, si bien que l'animation masquait l'élément même qu'il fallait mesurer. Le titre glisse désormais sans fondu. Et trois familles de polices étaient préchargées en parallèle, dont une monospace qui disputait la bande passante à la serif du H1 — celle qui conditionne réellement le LCP. Les préchargements sont passés de cinq à deux.

Mesures en production mobile, prises deux fois après déploiement : 94 puis 95, LCP 3,0 s puis 2,8 s, TBT 20 ms puis 10 ms. Plus tôt, différer les animations décoratives jusqu'au chargement complet avait fait passer le Speed Index de 6,4 s à 1,9 s, avec un FCP à 1,2 s et un CLS à 0,001. Aucun de ces quatre chantiers ne se serait vu sans mesure avant et après — l'exigence que la Méthode Nehos ROI-First IA impose aux projets clients, appliquée ici à nous-mêmes. Notre fiche Core Web Vitals déplie ces métriques.

#Ce qu'un corpus impose en discipline

Un corpus structuré n'est pas gratuit : il déplace le risque. Plus de schéma de base pour refuser une donnée mal formée, donc il faut un garde-fou explicite et exécuté.

Le nôtre est un script de validation lancé avant le build. Il vérifie cinq choses : que chaque JSON se parse — un seul fichier invalide casse le build entier —, qu'aucun artefact de corruption ne traîne, que chaque lien interne pointe vers une page existante, qu'aucune page n'est orpheline ni trop maigre. La deuxième n'a rien de théorique : un remplacement de masse mal calibré avait laissé des grilles tarifaires incohérentes — sur une page, la formule la plus complète s'affichait moins chère que le palier inférieur. Deux autres scripts complètent le dispositif : l'un réaligne les liens dont la cible a changé de chemin, l'autre supprime ceux dont la cible n'a jamais été écrite.

S'y ajoutent 189 tests unitaires sur la mécanique elle-même : unicité des chemins publics, nettoyage récursif des champs internes, URL canoniques, grappes hreflang, résolution des vignettes, validation des formulaires.

#Ce que ça prouve, si vous avez le même besoin

Une refonte n'oblige pas à réécrire le contenu. Le passage du CMS au rendu direct n'a pas touché une ligne de rédaction : le contenu était déjà séparé de son rendu, changer de moteur revenait à changer de lecteur. C'est exactement ce que l'on cherche quand on migre un site WordPress vers Next.js — sortir le contenu du gabarit avant de changer de gabarit. Les refontes qui coûtent cher sont celles où cette séparation n'a jamais été faite.

Une décision éditoriale devient applicable en une passe. Quand nous avons acté que Netlify est notre plateforme de livraison — et pas telle alternative que le corpus mentionnait par habitude —, il a fallu reclasser 802 occurrences : le contenu pédagogique garde ses faits, glossaire et comparatifs compris ; les offres qui présentaient une autre plateforme comme la nôtre ont basculé. Résultat : 45 pages modifiées, 119 lignes remplacées, une passe de vérification derrière. Même mécanique quand une revue interne a établi que six études de cas présentées comme des clients réels sous NDA n'existaient pas : chaque bloc a été requalifié en « scénario type », dépouillé de ses indicateurs inventés et repointé vers la page de service concernée. Sur un site où le contenu vit en base, ces chantiers se traitent page par page, et personne ne relit la correction dans un diff.

La performance se corrige à la racine, pas page par page. Parce que les 938 pages passent par les mêmes gabarits, un correctif de LCP profite à toutes d'un coup. C'est l'autre face de la contrainte : la discipline du corpus rend l'échelle utile plutôt que subie.

Une réserve. Cette architecture suppose une équipe à l'aise avec Git : un corpus JSON versionné n'est pas une interface d'administration, et nous ne la recommandons pas là où rédaction et publication reposent sur des profils non techniques sans accompagnement. Le bon arbitrage est alors souvent un CMS headless posé au-dessus d'un rendu statique : même séparation entre contenu et rendu, ergonomie différente.

Si votre site présente les mêmes symptômes — trop de pages pour être corrigé à la main, un CMS qui rend le contenu invisible à la relecture, des scores de performance qui ne bougent pas —, l'audit gratuit est le point d'entrée : nous regardons votre corpus et votre chaîne de publication, pas seulement votre page d'accueil.