Votre site web a-t-il besoin d’une publication instantanée?

Avant de choisir comment un site web publie son contenu, posez une question pratique : une mise à jour doit-elle être publique en quelques secondes, ou peut-elle prendre quelques minutes? La réponse change l’architecture.

Une salle de rédaction peut avoir besoin qu’une correction soit visible immédiatement. Un magasin peut avoir besoin que les stocks et les prix fassent autorité à chaque requête. Un site de services, un portfolio ou un site d’entreprise relativement stable peut accepter un court délai lorsqu’une architecture qui sépare l’édition de la diffusion au moment de la compilation convient à ses besoins de fraîcheur et à son flux de travail. Le bon choix commence par le besoin de fraîcheur, pas par un outil préféré.

L’éditeur et le site public ont des fonctions différentes. L’éditeur offre au propriétaire un seul endroit pour modifier le contenu. Le site public diffuse les pages que les visiteurs lisent.

Sur yesid.dev, l’application actuelle lit des modules de contenu générés pour les pages publiques au lieu de demander le contenu au CMS lors de chacune des visites échantillonnées. Dans des traces de production récentes du 10 juillet 2026, la page d’accueil, Services, Blog, un article publié et la page du projet yesid.dev ont tous renvoyé un code 200. Chaque requête observée est restée sur yesid.dev, sans aucune requête vers Directus ou vers un hôte cms.*. Il s’agit d’une preuve tirée de cinq traces, pas d’une affirmation sur chaque route ou chaque visite future.

Cette dépendance plus limitée envers le CMS a une valeur pratique. Les pages déjà publiées sont conçues pour rester accessibles si l’éditeur est indisponible, car elles n’ont pas besoin d’une nouvelle réponse du CMS pour chaque lecteur. Cette attente découle de l’architecture; elle n’a pas été démontrée par un exercice de panne indépendant. Cela ne met pas non plus l’ensemble du site web à l’abri des pannes. D’autres dépendances liées à l’hébergement, au code, au réseau et aux ressources existent encore.

Pour le propriétaire, il y a toujours un seul éditeur. La séparation concerne la façon dont le contenu publié est construit et diffusé.

Voici le seul aparté technique : le chemin de production est Directus -> export à la compilation -> modules générés -> SvelteKit/Vercel. Le CMS fournit le contenu publié au processus de compilation, la compilation prépare les fichiers publics et seul un déploiement terminé remplace la version précédente.

Ce rafraîchissement du contenu en production est maintenant activé. Le 11 juillet 2026, une compilation de production a consigné mode=live, a lu https://cms.yesid.dev selon une politique qui bloque en cas d’échec, a exporté cinq articles publiés et cinq corps d’article, puis a produit les 22 modules de contenu générés.

Dans le chemin d’exportation en direct, le contenu actualisé ne devient pas public avant qu’un nouveau déploiement soit prêt. Au moment de ce relevé du 11 juillet, la compilation de production a commencé à 06:17:57.482 UTC et le déploiement s’est terminé à 06:19:26.603 UTC : 89.121 secondes entre le début de la compilation et la fin du déploiement.

Il s’agit d’une observation, pas d’un SLA ni d’une fourchette habituelle garantie. Elle prouve que cette modification précise du CMS a atteint le site public : une fois le déploiement terminé, les cinq nouvelles URL d’article prévues ont renvoyé un code 200, avaient chacune une URL canonique qui pointait vers elle-même et figuraient dans le plan du site; les trois URL d’article retirées ont renvoyé un code 404 et ont disparu du plan du site. Cet article était délibérément encore à l’état de brouillon pendant ce relevé, renvoyait lui aussi un code 404 et était absent du plan du site. Une compilation candidate antérieure a rejeté un lien vers cette page à l’état de brouillon et n’a pas été promue, de sorte que le déploiement précédent est resté en ligne jusqu’à la fin de la compilation corrigée.

Cette architecture convient mal lorsque les mises à jour doivent être publiques en quelques secondes. Cela comprend la publication au rythme d’une salle de rédaction, les stocks ou les prix qui doivent faire autorité au moment de la requête, les applications personnalisées, les tableaux de bord en direct et tout flux de travail qui ne peut pas tolérer une compilation avant la mise en ligne du contenu.

Elle peut convenir aux sites de services, aux portfolios, à la documentation et à d’autres pages relativement stables pour lesquelles quelques minutes sont acceptables. Même alors, la pertinence dépend des besoins d’aperçu, des approbations éditoriales, des intégrations et de la quantité de travail opérationnel que le propriétaire ou le développeur est prêt à prendre en charge. La livraison statique n’est pas une recommandation universelle.

Si ce compromis convient à votre site, voyez comment le service Sites web et commerce électronique aborde les projets web.

Voici le chapitre 6 d’une épopée en six chapitres. Chapitres 1 à 3 : qui je suis. Chapitres 4 à 6 : ce que je construis. Précédent : De 50 $ à 0 $ : une VM Oracle Always Free.