Le jour où j'ai dépublié une page n°1 en voulant l'améliorer

En juillet, j'ai voulu mettre à jour une page en tchèque qui se classait dans le top 10 de Google, parfois en première position. Je l'ai passée en brouillon avant de la réécrire. Dans notre flux de publication, ce changement de statut l'a retirée du site.

Je suis Jim. Quatrième épisode de l'après-migration Eurofiscalis, sur une erreur de mise à jour dans le CMS. Dans l'article Sanity, puis Payload, j'expliquais pourquoi on avait choisi notre CMS. Ici, je décris les précautions ajoutées pendant son usage en production.

L'histoire

On réécrivait une page en tchèque. Une bonne page, bien positionnée, qui méritait simplement d'être mise à jour. Mon réflexe : la passer en brouillon, le temps de la retravailler tranquillement, puis la republier propre.

J'avais changé l'état du document publié, au lieu de préparer une version de travail à côté. Notre site ne diffusait que les documents publiés : la page n'était donc plus accessible.

Il faut distinguer cette action de l'enregistrement d'une version brouillon. Payload prévoit un mécanisme de versions et de drafts qui permet de garder un document publié pendant le travail sur une nouvelle version. Le comportement dépend de la configuration et de l'opération effectuée ; notre erreur ne décrit pas tous les CMS headless.

Nous avons repéré le problème rapidement et republié la page immédiatement. Cette remise en ligne corrigeait l'état de publication. Elle ne suffit pas, à elle seule, à mesurer un éventuel effet sur le classement.

Trois façons de retoucher utilisées dans notre flux

Depuis, la consigne de nos outils est claire : on ne passe jamais une page en ligne en brouillon. Pour la retoucher, il reste trois options.

Pour un nouvel article, en revanche, le brouillon reste le bon point de départ. Il n'y a rien à dépublier, et c'est justement ce qui permet de relire avant la mise en ligne.

Les autres pièges de la même famille

Nous avons également documenté les problèmes rencontrés dans les recherches et les mises à jour du contenu. Certains enregistrements pouvaient sembler réussis sans produire la modification attendue.

Les adresses traduites. Sur notre site, chaque langue a sa propre adresse : la page française sur la Slovaquie ne s'appelle pas du tout pareil en anglais ou en italien. Chercher « slovaquie » dans les adresses ne ramène donc que les pages françaises. Et tu en conclus, à tort, que les traductions n'existent pas. Nous vérifions les traductions à partir de la relation entre les versions du même contenu. Chercher un nom français dans leurs adresses ne suffit pas.

Les champs ignorés en silence. Le titre et la description SEO doivent être rangés à un endroit bien précis. Si tu les envoies à côté, le CMS ne râle pas : il ignore simplement. L'enregistrement réussit, et ta page n'a pas de description.

Ce que le CMS ne sait pas faire. Impossible, par exemple, de marquer un lien en « nofollow » directement dans l'éditeur. Pas grave, ça se gère à l'affichage, côté site, avec Max. Mais il faut le savoir avant d'en avoir besoin.

Le bug qui bloquait tout. Un jour, plus moyen de modifier le moindre article rattaché à un pays. Même changer un titre était refusé. La cause était un décalage dans la structure de la base de données, sur la table des pays. Max l'a réalignée, et on a gardé un test tout simple pour vérifier que ça ne revient pas.

Les garde-fous installés depuis

La leçon n'aurait servi à rien si elle était restée dans ma tête. Alors elle est passée dans les outils.

« Publié » écrit en toutes lettres. Chaque mise à jour d'une page en ligne précise explicitement qu'elle doit rester publiée. On ne compte plus sur l'état par défaut.

Les règles gravées dans les skills. Les outils IA qui publient et mettent à jour nos articles, ceux dont je parlais dans l'usine de skills, ont ces règles écrites noir sur blanc. Ces instructions interdisent de repasser une page en ligne en brouillon. Elles cadrent l’action de l’agent, mais ne remplacent pas la vérification du statut enregistré.

Vérifier après chaque écriture. Après chaque modification, on relit ce qui a vraiment été enregistré. Pas ce qu'on croit avoir envoyé. Ce qui est dans la base.

Ce que je retiens

Cette erreur venait de la différence entre une version de travail et l’état publié du document. La correction a consisté à conserver explicitement cet état dans les mises à jour et à relire ce qui avait été enregistré. Ces contrôles restent nécessaires, même avec les consignes écrites dans les skills.

La suite

Le dernier épisode examine un autre contrôle de publication : les valeurs de secours conservées à côté des données dynamiques. Le système est décrit dans l’article suivant : nos chiffres se mettent à jour tout seuls, sauf quand ils mentent.