Les coulisses de ce blog : de la copie au journal de l’école
Leçon du — corrigé le
Date du parcours pédagogique ; blog lancé début août 2026. Pourquoi ces dates ?
Texte initial : Claude · révision avec Codex · direction éditoriale : Matt · 5 min de lecture
Tu te souviens du journal de l’école ? On prépare l’article, on le met au propre, puis on le distribue dans les classes. Le blog suit un circuit du même genre : un article est un fichier Markdown, Git garde l’historique du projet, puis une chaîne fabrique et déploie le site.
Les anciens textes de cette série ont été préparés avec Claude. Aujourd’hui, je te raconte le fonctionnement configuré dans le dépôt : les articles sont écrits en amont, tandis que leur génération et leur distribution peuvent être automatisées. Ce sont deux étapes différentes.
1. La copie : un fichier Markdown
Un article commence dans un fichier texte au format Markdown. Quelques signes indiquent les titres, les listes et le texte en gras ; Astro s’occupe ensuite de l’habillage. C’est comme écrire le contenu d’une page du journal sans refaire à la main toute la maquette.
Les articles sont préparés avant leur date de publication. Le cahier de rédaction précise les sujets et leur statut éditorial ; le filtrage du site décide ensuite quelles dates sont éligibles au build. La date d’un article ne signifie donc pas qu’un modèle vient de l’écrire à cette heure-là.
2. Le classeur : Git et GitHub
Le projet est suivi avec Git. Quand on crée un commit, Git enregistre un instantané des fichiers sélectionnés et un message qui décrit les changements. Les modifications non suivies ou pas encore enregistrées ne sont pas dans cet historique : le classeur aide à retrouver des versions, mais il ne remplace pas une sauvegarde.
Les changements peuvent ensuite être envoyés sur GitHub. Une pull request permet de regarder les différences et de demander une relecture avant la fusion. Mais GitHub ne force pas forcément une personne à relire chaque changement : cela dépend des règles appliquées au dépôt. La règle éditoriale, elle, reste simple : l’agent aide à faire la copie, Matt en garde la responsabilité.
3. L’imprimerie : build puis déploiement
Le workflow GitHub Actions de ce dépôt peut démarrer après un push sur main, une pull request, une action manuelle ou son rendez-vous hebdomadaire. Le lundi, le déclencheur est fixé à 9 h 17, heure de Paris, après l’heure de publication prévue à 9 h. GitHub peut toutefois retarder un démarrage planifié lors des périodes chargées.
Le travail du lundi est précis : installer les dépendances avec npm ci, exécuter npm run build, puis envoyer le dossier dist/ généré à Azure Static Web Apps. Le build fabrique les pages et peut signaler les erreurs que le générateur détecte. Il ne rédige rien et n’appelle aucun modèle d’IA. Le filtre éditorial garde les brouillons et les articles datés plus tard hors des pages publiées à cette heure-là.
Il n’y a pas de suite de tests dédiée dans ce workflow : son contrôle principal est le build. Celui-ci ne vérifie pas à lui seul chaque lien, chaque affirmation ou le rendu de toutes les pages. C’est comme une imprimerie capable de signaler un bourrage papier, mais pas de relire le journal à la place du rédacteur.
4. La distribution : Azure Static Web Apps
Quand le build aboutit, l’action de déploiement téléverse les fichiers statiques produits dans dist/ vers Azure Static Web Apps. Le workflow utilise un secret GitHub pour autoriser ce déploiement ; sa valeur reste dans les paramètres secrets, pas dans le fichier source. La configuration visible ne permet pas de déduire le coût réel du service Azure ni le forfait associé au compte.
La chaîne ressemble donc à ceci : article préparé → changements enregistrés dans Git → pages générées par Astro → fichiers envoyés à l’hébergeur. Un déploiement réussi signifie que le workflow a terminé cette distribution ; pour confirmer qu’une page précise est bien visible en ligne, il faut encore consulter son URL.
À retenir : le blog automatise la fabrication et la distribution des pages, pas leur rédaction. Les contenus sont préparés à l’avance, puis le workflow applique les règles de date et de brouillon avant de construire et d’envoyer le site. Un build réussi est utile, mais il ne remplace ni la relecture ni la vérification des pages publiées.
Pourquoi te raconter tout ça ?
Parce que ça permet de savoir qui fait quoi. Claude a aidé à préparer les anciens articles ; Git conserve les changements ; Astro transforme les sources en pages ; GitHub Actions lance les étapes prévues ; Azure les héberge. Comme dans le journal de l’école, l’imprimerie fait gagner du temps, mais elle ne choisit pas le sujet et ne signe pas la copie.
La semaine prochaine, on change de casquette : maintenant que tu sais déléguer, il va falloir apprendre à bien corriger — superviser sans micro-manager, ou l’art de corriger la copie sans la réécrire.