Avant, publier un article sur mon site me prenait 3 heures de copier-coller HTML. Maintenant, j'écris un fichier markdown avec Claude Code, je lance une commande, l'article est en ligne. Voilà le pipeline complet.
Tu te dis peut-être que publier un article sur son site, c'est simple. En théorie, oui. En pratique, ça vire vite à la corvée : copier-coller le template HTML, remplacer 15 placeholders, vérifier que rien ne casse, mettre à jour le sitemap, ajouter le lien dans le parcours d'apprentissage...
Bref, 3 heures pour un article de 7 minutes de lecture. J'ai décidé de craquer là-dessus.
Tu perds plus de temps à déployer qu'à écrire ? C'est le signe qu'il te faut un pipeline. Quelques lignes de Node suffisent — pas besoin de monter une usine.
Le pipeline fait une chose simple : tu écris en markdown, il génère l'HTML. Comme un static site generator artisanal, mais pour mon site spécifiquement, avec mon template et ma charte.
Les 3 pièces :
drafts/ où je dépose mes articles en .mdarticles/_TEMPLATE.html) qui fixe la mise en pagepublish.js qui fait la conversionQuand je lance npm run publish mon-article, il lit le draft, injecte dans le template, écrit dans articles/mon-article.html, met à jour le sitemap.xml. Je relis le résultat, je commit, Vercel redéploie tout seul.
J'ouvre Claude Code, je lui dis "écris un article sur X en suivant AGENT_BRIEF.md". Il me sort un draft markdown complet avec frontmatter, structure, callouts. Je relis, j'édite les passages qui sonnent faux, je valide.
Temps passé à écrire : 45 minutes (vs 2h avant). Qualité : identique, parfois meilleure parce que Claude me propose des angles auxquels je n'aurais pas pensé.
Je lance npm run publish demo-pipeline-publish. Le script :
✓ articles/demo-pipeline-publish.html généré
✓ sitemap.xml — nouvelle entrée ajoutée
• parcours_etape non défini → apprendre.html non modifié
Je vérifie visuellement que tout est propre. J'ouvre le HTML en local, je scroll. Si c'est OK, je commit et je push.
Vercel est branché sur mon repo GitHub. Dès qu'un commit arrive sur main, il détecte les fichiers modifiés et redéploie le site. Temps moyen : 30-45 secondes.
Aucune config à gérer, aucune CI custom à maintenir. C'est la magie des sites statiques : on publie, ça marche.
Mon premier réflexe a été de supporter 100% de la syntaxe markdown + 50 composants custom. Résultat : 800 lignes de script pour une utilité marginale. Je suis revenu en arrière : marked + gray-matter + quelques regex suffisent pour 95% des cas. Le reste, j'injecte du HTML brut dans mon markdown.
Au début, je publiais sans mettre à jour sitemap.xml ni la carte apprendre.html. Google finit par indexer, mais ça traîne. Le script fait ces MAJ automatiquement maintenant — un piège de moins.
Une fois, j'ai commit un article avec un typo dans la meta description. Corrigé, pushé à nouveau, mais l'Open Graph continuait à montrer la vieille version sur LinkedIn. Leçon : Vercel met un temps à invalider les previews OG. Prévoir une relecture sérieuse avant le premier push.
(1) Le frontmatter est complet. (2) J'ai relu le MD à voix haute (test ton Leo). (3) Les liens internes pointent vers des articles qui existent. → Si OK aux 3, npm run publish.
Ce pipeline est la Phase 1 de mon plan agent IA. Ce qui arrive ensuite :
Si tu veux voir comment évolue cette stack, réponds à la newsletter — je publierai les retours d'XP dès qu'il y a quelque chose à raconter.
Une info obsolète, un chiffre qui a bougé, une source périmée ? Écris-moi à sagnier.jeremy@gmail.com · je corrige en 48h max et je note la date de MAJ en haut de l'article. Les retours terrain valent mille fois les articles — je lis tout, je réponds.
Chaque fois que je publie un nouveau tuto Claude Code / IA, je l'envoie dans ma newsletter AI Playbook. Si tu ne veux pas manquer le prochain, laisse-moi ton email sur la home.
Voir les newsletters →