Le problème de départ
Un blog professionnel ne vaut que par sa régularité. Deux articles par semaine tenus pendant six mois valent infiniment mieux que quinze publiés dans le même week-end. Or écrire ne se fait pas régulièrement : ça se fait par vagues, quand on a le temps et la tête à ça.
Le goulot n’est donc pas l’écriture, c’est la publication. Une tâche minuscule, deux minutes, mais qui doit tomber le bon jour, indéfiniment, y compris pendant les vacances et les semaines chargées. C’est exactement le profil de tâche que je cherche quand j’installe un système chez un client : courte, récurrente, sans jugement, et pénalisante quand elle saute.
Les cinq pièces
Le système complet tient en cinq pièces, et aucune n’est spectaculaire prise isolément.
Une source de vérité unique. Un seul fichier liste les articles, leur titre, leur date de publication. L’index du blog, le plan du site, le flux et les métadonnées lisent tous ce même endroit. Cette règle est la plus importante de toutes : quand une information existe à deux endroits, elle finit toujours par diverger, et c’est toujours au pire moment.
Un filtre sur la date. Un article dont la date n’est pas arrivée n’existe pas pour le site. Il est absent de l’index, du plan du site, du flux, et son adresse directe renvoie une page introuvable. C’est ce qui permet d’écrire un mois d’avance sans rien laisser fuiter.
Un déclencheur quotidien. Chaque matin, un automate lit les dates, les compare au jour en cours, et s’arrête net s’il n’y a rien à publier. Les jours où un article sort, il demande la reconstruction du site.
Ce détail mérite une explication, parce qu’il surprend toujours : ce site est statique, c’est-à-dire que ses pages sont fabriquées une fois pour toutes et servies telles quelles. C’est ce qui le rend rapide et robuste, mais ça implique que la liste des articles est figée au moment de la fabrication. Sans reconstruction, une date qui arrive ne change strictement rien. Toute la mécanique existe pour cette raison.
Une notification. Quand un article part, je reçois un message sur ma messagerie personnelle avec son titre et son lien. Pas un rapport, pas un tableau de bord à consulter : un message qui arrive. Un système silencieux est un système qu’on ne surveille pas, et un système qu’on ne surveille pas finit par tomber en panne sans que personne ne le remarque.
Une trace. Chaque article a une ligne dans une base éditoriale, qui passe automatiquement de « programmé » à « publié » avec son adresse. Cette base ne publie rien : elle garde la mémoire. C’est elle qui me prévient, chaque lundi, s’il reste moins de deux articles d’avance, parce que la panne la plus probable de ce système n’est pas technique : c’est que j’oublie d’écrire.
Vous vous demandez ce que ça donnerait chez vous ? Le diagnostic gratuit chiffre votre situation en 6 minutes.
Ce qui a cassé
Deux pannes pendant la construction, et elles sont plus instructives que le reste.
La première était bête et coûteuse en temps : dans un fichier de configuration, un simple deux-points au milieu d’une phrase rendait tout le fichier illisible pour la machine. Le message d’erreur disait seulement « problème avec le fichier », sans indiquer la ligne. Une demi-heure perdue sur un caractère de ponctuation. La leçon retenue est devenue une règle : valider le format d’un fichier de configuration avant de le mettre en service, jamais après.
La seconde était plus sérieuse. Le déclencheur devait au départ passer par une clé fournie par mon hébergeur. La clé dont je disposais n’avait pas les droits nécessaires, et aucun contournement propre n’existait. Plutôt que de bricoler, j’ai changé de mécanisme : le déclenchement passe désormais par l’outil qui héberge déjà le code, ce qui fait le même travail sans nécessiter le moindre secret à stocker.
Cette deuxième panne illustre une règle que j’applique partout : quand une pièce résiste, on ne force pas, on regarde si une autre pièce déjà présente peut faire le travail. Les installations qui tiennent dans le temps sont celles qui utilisent peu de morceaux, pas celles qui en empilent beaucoup.
Ce que ça coûte
À l’usage, rien. Aucun modèle d’IA n’intervient le jour de la publication : ce système-là n’a besoin d’aucune intelligence, seulement d’une comparaison de dates. Les outils utilisés tournent sur des services que j’utilise déjà.
Le coût réel a été celui de la conception : décider où vit la vérité, ce qui déclenche quoi, ce qui se passe quand ça rate, et qui est prévenu. Une demi-journée. Ce ratio est constant dans tous les projets que je livre, et c’est ce qui explique la structure de prix d’une installation : la dépense est en réflexion, presque jamais en technologie.
Cela dit quelque chose d’important sur le mot « automatisation ». Beaucoup de gens imaginent qu’il faut de l’IA partout. La vérité est plus prosaïque : une bonne installation réserve l’intelligence aux endroits qui demandent du jugement, et confie le reste à des règles bêtes, rapides et gratuites.
Le principe, transposable chez vous
Retirez le blog, gardez la structure. Vous obtenez un modèle qui marche pour la plupart des tâches récurrentes d’une entreprise : une source de vérité unique, un déclencheur qui vérifie une condition simple, une action, une notification à un humain, une trace.
Appliquez-le à une relance de factures impayées, à un rappel de renouvellement de contrat, à la préparation d’un reporting mensuel, à la mise en route d’un nouveau client. Vous retrouverez les cinq mêmes pièces. Ce qui change d’un cas à l’autre, c’est la condition à vérifier et la personne à prévenir.
Et si vous voulez vérifier plutôt que me croire sur parole : regardez la date de publication en haut de cette page. Elle était écrite dans le fichier plusieurs semaines avant d’arriver, et le jour où elle est arrivée, je n’ai rien fait.
