Publication · Le Labo du Yeti

L'idée clé. Tant qu'aucun build n'est lancé, vos modifications restent invisibles pour vos visiteurs. Le build transforme votre travail en pages HTML statiques publiées immédiatement.

Le principe : brouillon puis publication

Le Labo du Yeti fonctionne en deux temps. D'un côté il y a l'espace de travail (l'interface où vous créez vos pages, articles et cocons SEO). De l'autre il y a le site public (ce que voient vos visiteurs). Entre les deux, une étape de publication appelée build.

Cette séparation est volontaire. Elle vous permet de préparer plusieurs modifications, de les relire tranquillement, puis de tout publier d'un seul coup quand vous êtes satisfait. Aucune crainte qu'un brouillon non terminé se retrouve en ligne par erreur.

Le workflow complet

Voici le cheminement d'une modification depuis sa création jusqu'à sa mise en ligne effective.

Vous éditez du contenu. Vous créez ou modifiez une page, écrivez un article, générez un cocon SEO. À ce stade, le contenu est enregistré dans la base de données du CMS mais reste invisible pour le public.
Vous lancez un build. Dans la sidebar, vous cliquez sur l'entrée Build du site (généralement placée dans la section CONFIGURATION). Vous arrivez sur le tableau de bord du build et cliquez sur le bouton orange Lancer un build.
Le CMS génère le site statique. Toutes les pages, tous les articles, toutes les pages de cocon sont compilés en fichiers HTML dans le dossier /public/. Le sitemap, le robots.txt et la page 404 sont également régénérés.
Le site public est immédiatement à jour. Dès la fin du build, vos visiteurs voient la nouvelle version. Aucune attente, aucune mise en cache à purger.

Bon à savoir. Un build typique de site moyen (50 à 200 pages) dure de quelques secondes à une minute. Vous pouvez continuer à travailler dans l'interface pendant qu'il tourne.

Lancer un build manuellement

Le build manuel est l'opération de publication la plus courante. Vous l'utilisez chaque fois que vous voulez rendre vos modifications visibles en ligne.

Connectez-vous au CMS avec un compte ayant le rôle Administrateur, Chef projet ou Webmaster. Le rôle Client ne peut pas déclencher de build.
Dans la sidebar à gauche, ouvrez la section CONFIGURATION et cliquez sur Build du site.
Sur la page qui s'affiche, vous voyez la date du dernier build et le nombre de pages actuellement publiées.
Cliquez sur le bouton orange Lancer un build en haut à droite.
Une barre de progression apparaît. Attendez que le statut passe à Build terminé avec succès.
Cliquez sur Voir le site dans la topbar pour vérifier le rendu public.

Quand faut-il lancer un build ?

Tous les changements ne nécessitent pas un build immédiat. Voici les cas typiques où il devient nécessaire.

Modification effectuée	Build requis ?	Pourquoi
Création ou édition d'une page	Oui	La page reste en brouillon tant que le build n'est pas exécuté.
Publication d'un article de blog	Oui	L'article est invisible publiquement avant le build.
Génération d'un cocon SEO	Oui	Toutes les pages générées doivent être compilées en HTML statique.
Modification du Header ou du Footer	Oui	Le header et le footer sont injectés à la compilation : il faut rebuilder pour propager les changements partout.
Changement de Layout global	Oui	Le squelette HTML utilisé par toutes les pages a changé, il faut tout regénérer.
Installation d'une extension impactant le rendu	Oui	Certaines extensions transforment le HTML à la génération (ex : conversion WebP).
Modification d'un réglage interne sans impact visuel	Non	Pas besoin de toucher au site public.
Ajout d'un utilisateur ou modification de droits	Non	Concerne uniquement l'interface CMS, pas le site public.

Ce que produit un build

Concrètement, à chaque exécution, le CMS crée ou met à jour les fichiers suivants dans le dossier /public/.

Une page HTML pour chaque page créée dans le CMS, à l'URL définie par son slug. Par exemple, une page Contact avec le slug contact devient /public/contact.html.
Une page HTML pour chaque article de blog publié. Les articles brouillons et programmés ne sont pas inclus.
Une page de listing /public/blog.html qui liste tous les articles avec pagination.
Une page par catégorie dans /public/blog/categorie/, listant les articles de cette catégorie.
Toutes les pages de cocon SEO avec leurs URLs composites (par exemple /parent/enfant.html pour une page enfant rattachée à un parent).
Une page d'erreur 404 personnalisée /public/404.html servie automatiquement quand un visiteur arrive sur une URL inexistante.
Le fichier sitemap.xml à la racine de /public/, listant toutes les URLs publiques pour faciliter l'indexation par Google et Bing.
Le fichier robots.txt à la racine de /public/, indiquant aux moteurs de recherche les zones à explorer et l'emplacement du sitemap.

Performance maximale. Comme tout est servi en HTML statique, votre site se charge en quelques dizaines de millisecondes. Aucune base de données n'est sollicitée côté public, ce qui supporte des pics de trafic importants sans ralentissement.

Le build automatique des articles programmés

Vous pouvez écrire un article aujourd'hui et choisir qu'il soit publié plus tard. Cette fonction s'appelle la programmation.

Quand vous créez un article et lui donnez le statut Programmé avec une date de publication future, le CMS surveille cette échéance. Au moment voulu, un mécanisme automatique appelé scheduler fait deux choses :

Il fait passer l'article du statut Programmé au statut Publié.
Il déclenche immédiatement un build complet du site.

Résultat : votre article apparaît en ligne automatiquement, sans intervention manuelle. Vous pouvez préparer une semaine de publications à l'avance et partir en vacances l'esprit tranquille.

Attention au fuseau horaire. La date de publication d'un article programmé est interprétée selon le fuseau horaire du serveur. Si vous publiez depuis une autre zone, vérifiez bien l'heure avant de valider.

Le sitemap : votre allié SEO

Le sitemap est un fichier XML qui liste toutes les pages de votre site avec leur date de dernière modification. Les moteurs de recherche le consultent pour découvrir et indexer vos contenus plus rapidement.

Bonne nouvelle : vous n'avez rien à faire. Le sitemap est régénéré automatiquement à chaque build. Il inclut :

Toutes les pages statiques publiées
Tous les articles de blog publiés
Toutes les pages de cocon SEO
La page de listing du blog et les pages de catégorie

Il est accessible publiquement à l'adresse https://votre-domaine.com/sitemap.xml et il est automatiquement référencé dans le fichier robots.txt. C'est le standard attendu par Google et par tous les outils SEO du marché.

Le fichier robots.txt

Le fichier robots.txt donne des consignes aux robots des moteurs de recherche : que peuvent-ils explorer, que doivent-ils ignorer, où trouver le sitemap.

Le CMS génère un robots.txt par défaut qui autorise l'exploration de l'ensemble du site et qui pointe vers le sitemap. Si vous avez besoin de personnaliser ce fichier (par exemple pour bloquer certaines URLs), parlez-en à votre équipe technique : voir la documentation technique du build.

Les réglages du build

Dans Réglages → Build, vous trouvez quelques options qui influencent le comportement de la génération.

Quota de génération cocon. Ce toggle global active ou désactive la limite anti-spam sur les pages cocon (5 pages par groupe et par semaine glissante par défaut). Très utile pour éviter qu'un client ne génère 500 pages de mauvaise qualité d'un coup et nuise au référencement.
Notifications email. Les rôles Chef projet et Webmaster reçoivent un email automatique cinq minutes après chaque libération de quota cocon.

Bonnes pratiques de publication

Quelques conseils pratiques pour bien vivre avec le système de build.

Groupez vos modifications

Plutôt que de lancer un build après chaque petite modification, accumulez plusieurs changements puis publiez d'un seul coup. C'est plus efficace et cela évite de surcharger le serveur.

Vérifiez avant de publier

Utilisez systématiquement la prévisualisation disponible sur chaque page, chaque article et chaque page de cocon avant de lancer le build. Une fois publié, le contenu est immédiatement visible par tout le monde.

Anticipez les gros builds

Si vous venez de générer 100 pages de cocon SEO, le prochain build sera plus long que d'habitude. Évitez de le lancer juste avant une démo client.

Surveillez l'état du dernier build

Sur la page Build du site, vous voyez toujours la date du dernier build réussi. Si un build a échoué (cas rare), un message d'erreur s'affiche et vous oriente vers les logs.

Piège à éviter. Modifier le Header ou le Footer sans relancer de build : les nouvelles versions ne se propageront pas sur les pages déjà compilées. Pensez toujours à rebuilder après une modification globale.

Pourquoi un site statique ?

Vous vous demandez peut-être pourquoi le CMS impose cette étape de build plutôt que de servir les pages dynamiquement comme WordPress. La réponse tient en trois mots : vitesse, sécurité, robustesse.

Vitesse. Un fichier HTML statique se sert en quelques millisecondes, sans calcul ni requête base. Vos visiteurs voient les pages instantanément, ce qui améliore l'expérience et le référencement Google (Core Web Vitals).
Sécurité. Aucun code dynamique n'est exposé publiquement. Les pirates ne peuvent pas exploiter une faille PHP ou injecter du SQL puisqu'il n'y en a pas côté visiteur.
Robustesse. Si la base de données est temporairement indisponible, votre site public continue de fonctionner. Seule l'interface d'administration est affectée.

Checklist avant publication

Avant de cliquer sur Lancer un build, prenez trente secondes pour vérifier ces points.

Toutes les pages éditées ont été prévisualisées
Les images ajoutées sont correctement affichées
Les liens internes pointent vers les bonnes pages
Le Header et le Footer sont à jour si vous les avez modifiés
Les articles programmés ont la bonne date de publication
Aucun contenu confidentiel ne traîne en page brouillon que vous comptiez supprimer

Vous êtes prêt. Le système de publication du Labo du Yeti est conçu pour être simple : vous éditez, vous prévisualisez, vous buildez, c'est en ligne. Pas de FTP, pas de cache à vider, pas de cron à configurer.

Pour aller plus loin

Vous voulez comprendre les coulisses techniques du build, les hooks d'extension qui s'y greffent ou la structure exacte des fichiers générés ? Consultez la documentation technique du build. Vous y trouverez le détail des étapes internes, les options de personnalisation avancées et les conseils de dépannage en cas de souci.