Avant de brancher un moteur éditorial sur un site, une question paraît secondaire : où le moteur a-t-il le droit d'écrire ?
La mauvaise réponse est tentante. Le script ouvre le fichier principal du blog, cherche le tableau des articles, injecte un bloc au bon endroit, puis espère que la structure n'aura pas changé. Cela fonctionne une fois. Ensuite, chaque refonte devient un risque.
Le fichier principal n'est pas une API
Un fichier lu par des humains n'est pas forcément un point d'entrée pour une machine. S'il contient les articles historiques, les types, les fonctions de tri et la logique de publication, le modifier automatiquement revient à confondre une page de travail avec une interface stable.
La règle est simple : le moteur écrit dans un fichier dédié. Le site lit ce fichier et le combine avec les articles existants.
Ce que cette séparation évite
Elle évite les modifications fragiles. Elle évite les insertions au mauvais endroit. Elle évite surtout qu'un outil de publication ait le pouvoir de casser la logique historique du blog.
Le code principal reste un code de lecture. Le fichier généré devient le seul point d'écriture. La frontière est visible dans le dépôt et vérifiable en revue.
La maintenance comme preuve de sérieux
Ce détail ne se voit pas dans l'article publié. Il se voit six semaines plus tard, quand il faut changer la page blog sans relire un script d'injection.
Une automatisation fiable commence souvent par ce genre de décision étroite : donner à la machine un couloir précis, puis lui interdire le reste.
Le bon système n'est pas celui qui peut écrire partout. C'est celui qui sait exactement où il a le droit d'écrire.