Un site qui se maintient tout seul : ce que j’ai construit sur le mien

L’automatisation qui vaut quelque chose n’est presque jamais celle qui impressionne. C’est celle qui supprime un geste qu’on aurait oublié.

Je le sais parce que je l’ai oublié.

Le geste que j’ai oublié

Mon site publie une page par jour depuis fin août. Au 21 septembre, 65 pages sont publiées ou programmées, tirées d’un plan de 420 pages et 702 145 mots.

Chaque nouvelle page a besoin de liens entrants depuis le reste du site le jour de sa sortie. Sans ça, elle est orpheline : elle existe, elle est dans le sitemap, et rien sur le site ne pointe vers elle. Google la trouvera, plus tard, avec moins d’empressement.

J’avais prévu ça. Un bloc de liens dans le pied de page, présent sur toutes les pages, mis à jour à chaque publication. Sauf que la mise à jour était un geste manuel, et qu’un geste manuel dans une routine quotidienne finit toujours par sauter.

Ce bloc est resté gelé trois semaines. Pendant trois semaines, il a servi une liste de liens qui ne correspondait plus à ce qui était en ligne, et les pages sorties dans l’intervalle n’ont reçu aucun lien entrant depuis le pied de page.

Le détail qui fait mal : l’automatisation censée l’éviter avait été écrite. Elle n’avait simplement jamais été activée.

Ce que j’ai construit à la place

Je suis parti d’un constat : un bloc présent sur toutes les pages qu’il faut mettre à jour à chaque publication est une charge permanente, et une charge permanente est une charge qu’on abandonne.

Alors j’ai déplacé le problème au lieu de le résoudre plus fort.

Le pied de page ne porte plus qu’un lien, fixe, vers la page « Plan du site ». Ce lien ne bougera jamais. C’est désormais la page plan qui porte tous les liens internes — et c’est elle qui se périme à chaque publication. La charge n’a pas disparu : elle s’est concentrée sur un seul objet, ce qui la rend automatisable.

Ensuite, un script :

• Il interroge l’API REST du site pour savoir ce qui est réellement publié : les pages et les articles, en statut publié, rien d’autre.
• Il régénère le contenu de la page plan à partir de cette liste.
• Il compare avec ce qui est déjà en ligne. Si les deux listes coïncident, il s’arrête sans rien écrire.
• Sinon, il pousse la nouvelle version, une fois, et se tait.

La partie qui compte est la première. La version précédente lisait mon calendrier de publication, un fichier local. Elle était donc aveugle à tout ce qui n’y figurait pas — un article de blog, une page légale, un cas client — et elle vieillissait dès que le calendrier bougeait. En lisant le site lui-même, elle ne peut plus se tromper : ce qui est publié apparaît, ce qui est programmé n’apparaît jamais avant l’heure, et aucun lien mort ne peut se glisser dans la page.

Ce que j’ai refusé d’ajouter au site

Il y avait une solution plus élégante : un traitement WordPress qui régénère la page au moment exact où une publication bascule en ligne. Zéro délai, pas de tâche planifiée, rien à activer.

Je ne l’ai pas retenue pour l’instant, et la raison est un principe que j’applique chez mes clients aussi : on n’ajoute rien au chargement des pages.

Chaque extension, chaque traitement branché sur l’affichage d’une page est une dette. Elle se paie en vitesse pour le visiteur, en surface de panne, et en incompatibilité le jour d’une mise à jour. Une page plus lente, ce sont des visiteurs qui partent avant de vous lire — c’est le genre de coût qui ne se voit dans aucun tableau de bord.

Le script que j’ai écrit s’exécute sur ma machine, pas sur le serveur. Le seul coût côté site est un appel d’API le jour où la liste change, c’est-à-dire une fois par publication. Le reste du temps, le site ne sait même pas que le script existe.

Quand j’écrirai la version branchée sur WordPress, elle ira dans un fichier séparé, jamais dans le thème — un thème modifié à la main perd ses modifications à la première mise à jour. C’est l’une des erreurs les plus fréquentes que je trouve en reprenant un site, et une des raisons pour lesquelles la maintenance d’un site WordPress coûte parfois plus cher que sa création.

Les deux limites, écrites noir sur blanc

Un : ça dépend de ma machine allumée. Une tâche planifiée sur un ordinateur portable n’est pas une infrastructure. Elle rattrape le retard au réveil de la machine, mais si je pars trois jours sans l’ouvrir, la page plan vieillit. C’est acceptable pour une page de plan, ça ne le serait pas pour un panier d’e-commerce. Je le dis parce que la différence entre « automatisé » et « fiable » est exactement là.

Deux : le script ne juge pas la qualité de ce qu’il écrit. Il vérifie que la structure est cohérente et refuse d’écrire si elle ne l’est pas. Mais un contrôle automatique vert ne prouve rien sur le rendu réel. Le seul juge est l’éditeur du site, ouvert à la main, où l’on compte les blocs cassés. Sur la dernière passe complète, le 21 septembre : zéro bloc invalide sur environ 4 600 blocs injectés. Ce chiffre n’a de valeur que parce qu’il a été vérifié dans l’éditeur, pas déduit d’un script.

Et une troisième chose, moins confortable : au moment où j’écris ces lignes, la tâche planifiée n’est pas encore en service. Il lui manque une clé d’accès à créer une fois, en trois minutes.

C’est exactement le défaut que je viens de décrire, une deuxième fois. Une automatisation écrite et non activée ne vaut pas mieux que pas d’automatisation du tout — elle vaut moins, parce qu’elle donne l’impression que le problème est réglé.

Ce que ça change pour vous, si vous n’avez pas 420 pages

Vous n’avez probablement pas de page plan à régénérer. Vous avez autre chose, et c’est le même problème.

• Un tableau de prix qui existe en trois endroits du site, et qu’on ne met à jour qu’à deux.
• Des horaires d’été modifiés sur la fiche Google et pas sur le site.
• Un formulaire dont les demandes arrivent dans une boîte mail que personne ne relève le vendredi.
• Une sauvegarde qu’on lance « quand on y pense ».
• Un certificat, un nom de domaine ou un abonnement qui se renouvelle tout seul jusqu’au jour où il ne se renouvelle plus.

Ces quatre-là ont un point commun : aucun ne provoque d’alerte. Rien ne clignote. Le site continue de s’afficher, le téléphone sonne un peu moins, et personne ne relie les deux avant des mois. C’est précisément ce qui les rend chers.

La bonne question n’est jamais « qu’est-ce que je pourrais automatiser ». C’est : quel geste, si je l’oublie une fois, me coûte de l’argent sans que je m’en aperçoive ? Ce geste-là mérite un script. Les autres n’en méritent pas.

Et la réponse est souvent plus petite qu’on ne l’imagine. Dans la plupart des cas que je traite en développement sur mesure, ce n’est pas une application qu’il faut, c’est une trentaine de lignes qui font une seule chose, à heure fixe, et qui ne font rien quand il n’y a rien à faire.

Le meilleur signe qu’une automatisation est réussie, d’ailleurs, c’est qu’on finit par oublier son existence : elle compare, ne trouve rien à faire, et se tait.

Mais la condition d’entrée reste la même pour vous comme pour moi. Une automatisation n’existe pas le jour où elle est écrite. Elle existe le jour où elle est branchée, et où l’on a vérifié au moins une fois qu’elle avait réellement fait le travail à votre place. Entre les deux, il n’y a rien — seulement l’impression rassurante d’avoir réglé le problème.

Je le note ici parce que c’est la deuxième fois que je me fais avoir par cette impression-là. Il n’y en aura pas de troisième.