Comment j'automatise notre production de blog de bout en bout

Je m'appelle Ming. En plus du design produit chez vm0, la gestion de notre contenu fait aussi partie de mon travail, et il s'est avéré qu'il y avait bien plus à faire que je ne l'imaginais : conception de workflow, illustrations, production d'images, travail sur le CMS, traductions. Voici comment j'ai peu à peu réussi à tout mettre en place.

Le contenu fait partie de ce que je fais ici

La majeure partie de mes journées chez vm0 se partage entre le design produit et notre base de code Next.js. Mais la gestion de notre contenu m'incombe également, et une fois que je m'y suis attelé, j'ai réalisé tout ce qu'exige réellement un blog performant. Il faut une production régulière, une vraie recherche de mots-clés, des visuels cohérents avec la marque, des méta-descriptions correctes, et des traductions dans les quatre langues que nous prenons en charge.

Quand j'ai commencé à m'y consacrer sérieusement, chaque article me prenait presque une journée entière. La rédaction n'en représentait au final qu'une petite partie. L'essentiel du temps passait dans le travail de production autour de l'écriture : trouver les bons mots-clés, créer l'illustration de couverture, renseigner correctement les champs du CMS, tout refaire pour chaque locale.

J'ai donc progressivement transféré le plus possible de ce pipeline à Lucas, un agent marketing IA que j'ai construit sur Zero autour de mon propre quotidien. Il est configuré comme « Marketing manager », et son périmètre couvre tout ce qui touche au marketing : la production de blog en est aujourd'hui la composante la plus aboutie, et il ne cesse de gagner en capacités à mesure que j'ajoute des skills et des connecteurs au fil du temps.

À l'heure actuelle, Lucas a accès à notre CMS headless Strapi, à notre compte Ahrefs, au Slack de notre équipe, à notre web chat, à un skill interne draw pour des illustrations cohérentes avec la marque, ainsi qu'au skill standard copywriting pour la mécanique de l'écriture.

Ci-dessous, je vais détailler comment cette automatisation de blog par IA fonctionne en pratique : comment Lucas prend un prompt vague, le décompose en sujet et mots-clés, rédige un article, dessine une couverture, fait passer le texte par une traduction naturelle, et dépose quatre brouillons localisés dans notre CMS headless. Ensuite, je raconterai comment j'en suis arrivé là, et ce que je laisse délibérément aux humains (encore essentiellement moi).

Comment j'utilise Lucas : application web et Slack

Plusieurs bulles de discussion convergeant vers un seul agent IA

Je travaille surtout avec Lucas via le web chat de vm0. C'est l'interface de travail en profondeur où je m'installe avec lui pour le plan, la rédaction, les itérations de couverture et les retouches. Des fils de discussion longs, du contexte étendu, le genre d'allers-retours qui seraient peu pratiques dans un canal de chat.

Lucas est aussi connecté au Slack de notre équipe, comme point d'entrée partagé. J'y dépose des prompts rapides depuis mon téléphone, et le reste de l'équipe peut aussi le solliciter. Quel que soit la personne en charge du blog ce jour-là, elle lance un article de la même manière. Même agent, même contexte sur les deux interfaces.

À quoi ressemble un prompt typique

Mes prompts adressés à Lucas sont généralement courts. Trois phrases maximum. Un exemple représentatif :

Lucas, rédige un tutoriel sur l'organisation de réunions hebdomadaires efficaces : aborde la structure de réunion, les pièges courants, et comment maintenir l'engagement des équipes à distance. Style tutoriel, optimisé SEO, termine par un CTA invitant à utiliser Zero. Lien vers le brouillon uniquement, ne publie pas.

C'est tout le brief. Un seul message. Pas de plan, pas de liste de mots-clés, pas de brief créatif, pas d'objectif de longueur. Lucas se charge du reste.

Il m'a fallu du temps pour aboutir à ce format. Au début, je rédigeais des briefs bien plus longs parce que je supposais que l'agent avait besoin que tout soit explicité, puis j'ai compris que l'essentiel du contexte appartient à ses instructions permanentes et à ses skills, pas à chaque prompt. Le prompt est un déclencheur ; c'est le reste de la configuration qui porte le poids du travail.

Comment Lucas analyse le sujet et les mots-clés

Un entonnoir se rétrécissant depuis de nombreuses étiquettes de mots-clés jusqu'à un seul mot-clé sélectionné

Le premier réflexe de Lucas est d'extraire une structure à partir d'un prompt vague. Pour une requête comme celle ci-dessus, ses notes de travail ressemblent à ceci :

Sujet : organiser des réunions hebdomadaires efficaces
Format : tutoriel → étapes numérotées, exemples concrets, formulations « faites ceci »
Audience implicite : chefs d'équipe, managers à distance, fondateurs
Sections requises : structure de réunion, pièges courants, engagement à distance
CTA : orienter les lecteurs vers Zero
Contrainte : URL de brouillon uniquement, non publié

Ensuite, il choisit le mot-clé. C'est la partie du marketing de contenu pour laquelle j'avais le moins d'intuition à mes débuts, alors j'ai donné à Lucas une procédure à suivre chaque fois que je le sollicite pour un travail sur les mots-clés. Ce n'est pas un skill qu'il exécute de façon autonome, juste une séquence que je lui confie en confiance :

Extraire des candidats depuis Ahrefs. Il appelle l'API Ahrefs sur la phrase du sujet, ce qui renvoie des variantes de longue traîne avec leur volume de recherche mensuel, leur difficulté de mot-clé (KD), leur sujet parent et l'intention SERP.
Filtrer par difficulté. Je lui ai donné une règle stricte : KD < 30. vm0 est un domaine relativement récent avec une autorité limitée, donc viser des mots-clés à KD élevé n'a pas encore de sens pour nous. La longue traîne l'emporte au début.
Recouper avec notre index Strapi. Il récupère tous les slugs publiés de notre CMS via l'API REST Strapi et écarte tout mot-clé que nous traitons déjà. Pas de cannibalisation.
Faire correspondre l'intention à l'adéquation produit. L'intention d'un mot-clé doit être compatible avec notre bibliothèque de cas d'usage. « Comment organiser des réunions hebdomadaires efficaces » → opérations / gestion d'équipe → adéquat. « Meilleurs ramen de Tokyo » → non, quel que soit le volume.
En choisir un. Dans la liste filtrée, il retient l'option au volume le plus élevé et en fait la colonne vertébrale de l'article. Par exemple, remote weekly meeting best practices.

Pour le SEO on-page, il applique une heuristique simple : le mot-clé cible dans le titre, dans au moins un H2, et dans les 100 premiers mots. Des synonymes et expressions associées tissés naturellement dans tout le texte. Des liens internes vers deux ou trois articles connexes là où ils s'intègrent. Au-delà : écrire naturellement, sans bourrage de mots-clés.

La structure de l'article (six ou sept H2, un encadré « Tip : » sous chaque étape, un CTA en clôture) provient d'un modèle de tutoriel que j'ai bâti par l'exemple au fil de plusieurs articles.

Comment la couverture est dessinée

La couverture est la partie de la production de blog à laquelle je tiens le plus, en partie parce que je suis designer et en partie parce que c'est ce que les lecteurs voient avant de lire le moindre mot. C'est aussi l'image Open Graph lorsque les articles sont partagés sur X ou LinkedIn, et c'est ce qui fait que notre index de blog ressemble à une publication plutôt qu'à un mur de photos de banque d'images.

Les photos de stock n'étaient pas envisageables pour le rendu que je voulais, et briefer les illustrations une par une aurait rendu le coût de production par article ingérable. J'ai donc construit un skill Zero appelé draw. C'est un script Python de 200 lignes qui fait cinq choses :

Prend deux entrées : une métaphore (quoi esquisser) et une couleur (un nom évocateur plus une ancre hexadécimale).
Les insère dans un modèle de prompt fixe qui verrouille le reste de la composition : fond gris chaud #eeeeee, tache aquarelle centrée dans le cadre dans la couleur choisie, esquisse à l'encre dessinée à la main par-dessus, logo vm0 en (25, 25) en haut à gauche.
Envoie le prompt composé au modèle nano-banana-pro de fal.ai en 16:9.
Télécharge le PNG. Normalise tout pixel proche du blanc pour le ramener exactement à #eeeeee afin que le fond ne dérive jamais. Met à l'échelle en 1600×900. Compose le logo vm0 transparent par-dessus en alpha.
Téléverse le résultat sur le CDN de vm0 et affiche l'URL.

Une invocation typique ressemble à ceci :

python draw.py \
  --metaphor "a tilted hourglass with sand draining into a small open notebook, a sparkle near the rim" \
  --color-name "dusty rose" \
  --color-hex "#e08b96" \
  --upload

Deux entrées, et le reste de la marque reste cohérent. Je choisis généralement une couleur qui convient au thème de l'article. Corail ou sauge pour les pièces de style tutoriel plus chaleureuses, bleu ou lavande pour les plus techniques, jaune moutarde pour les annonces. Quelques couleurs récurrentes transforment lentement l'index du blog en une palette reconnaissable.

Ce que j'ai compris à mes dépens, c'est que l'effet de levier ne réside pas dans le modèle. Il réside dans le modèle de prompt. Laisser le modèle choisir librement la composition, la palette et la mise en page faisait que chaque couverture ressemblait à une marque différente. Verrouiller ces éléments et ne le laisser choisir que la métaphore maintient un rendu cohérent d'un article à l'autre.

Il existe un skill jumeau appelé illustration pour les illustrations ponctuelles à l'intérieur des articles (les dessins plus petits que vous voyez entre les sections de cet article). Même principe : style fixe, seules la métaphore et la couleur varient. Simplement réglé pour des images carrées 1024×1024 plutôt que des couvertures 16:9.

Une petite note sur le SEO des images : la même image de couverture est configurée comme asset Open Graph et Twitter Card de l'article, si bien que les partages sociaux la récupèrent proprement. Strapi génère automatiquement quatre variantes pré-redimensionnées au téléversement (thumbnail, small, medium, large), même si je n'ai pas encore relié le corps de l'article pour les charger via srcset. C'est un petit TODO front-end. Les illustrations en ligne reçoivent un texte alternatif descriptif rédigé dans le markdown lorsque Lucas les intègre ; le alternativeText propre à la couverture dans Strapi est quelque chose que je veux encore compléter rétroactivement.

Comment l'article est rédigé

Un plan vertical à gauche s'élargissant vers la droite en blocs de paragraphes remplis avec une ampoule d'astuce

Une fois le sujet, le mot-clé et la couverture fixés, la rédaction est essentiellement mécanique. Lucas :

Établit d'abord un plan. Six ou sept H2, chacun avec un rôle clair : cadrage du problème, instructions étape par étape, encadrés « Tip : », récapitulatif, CTA.
Développe chaque H2 en prose à l'aide du skill copywriting. La voix (phrases courtes, exemples concrets, deuxième personne là où ça fonctionne, humour pince-sans-rire à l'occasion) provient de règles que je conserve dans les instructions permanentes de Lucas, et non du skill lui-même.
Ajoute des encadrés pratiques « Tip : » sous chaque étape. Utile pour les tutoriels car la plupart des lecteurs survolent, et les encadrés leur tracent un chemin à travers un contenu long.
Rédige le champ description de l'article. Strapi le limite à 80 caractères, il reste donc court et donne l'impression d'avoir été écrit par un humain. Il sert de sous-titre à l'article et de description pour les cartes OG/Twitter.
Conclut par un CTA qui nomme le produit et renvoie vers un espace de travail gratuit.

Un premier brouillon revient généralement deux ou trois minutes après le prompt. Je le lis, je demande des ajustements de ton là où la voix sonne faux, et Lucas itère jusqu'à ce que ce soit juste. Le premier brouillon est rarement prêt à être publié. Il est généralement presque bon mais un peu décalé, et c'est là que je passe l'essentiel de mon temps de relecture.

Comment le brouillon atterrit dans Strapi

Un colis de brouillon emballé déposé dans une boîte aux lettres CMS avec une icône de pause flottant au-dessus

Nous utilisons Strapi comme CMS headless. Le type de contenu articles comporte un cover (média), un author et une category (relations), une locale (chaîne de caractères), et une dynamic zone blocks où vit le corps de l'article.

Le flux de synchronisation CMS de Lucas :

POST du PNG de couverture vers /api/upload. Enregistrer le documentId renvoyé.
POST vers /api/articles?status=draft avec le titre, la description (≤ 80 caractères ; Strapi l'impose), le slug, la locale, les relations cover/author/category sous forme d'identifiants numériques, et un unique bloc shared.rich-text contenant le corps en markdown.
Élément crucial : omettre publishedAt. Strapi interprète null comme l'état brouillon.
Renvoyer une URL de prévisualisation selon le format de brouillon de vm0 : https://www.vm0.ai/{locale}/blog/posts/{slug}?status=draft.

Un avertissement concernant Strapi v5 : l'API REST publique peut écraser publishedAt sur certains types de contenu, ce qui signifie qu'un « brouillon » créé via l'API peut passer en ligne sans bruit. La solution est une petite migration de base de données qui supprime ce champ lors des écritures de brouillon.

La stratégie de slug compte aussi pour le SEO. Nous utilisons un seul slug canonique pour les quatre locales plutôt que de le traduire. Un lecteur sur /de/blog/posts/remote-weekly-meeting-best-practices voit la même structure d'URL qu'un lecteur sur /en, et notre profil de backlinks ne se fragmente pas entre des URL traduites. Émettre les balises de lien hreflang à partir de ces relations de locale est un petit TODO front-end. Nous ne les livrons pas encore.

Comment fonctionne la traduction i18n

Un document central se déployant en quatre copies plus petites étiquetées EN, DE, JA, ES

vm0 est disponible en quatre locales : anglais, allemand, japonais, espagnol. Nous ne faisons pas passer les articles par Google Translate. La voie économique détruit la voix ; la bonne voie adapte les idiomes.

Lucas crée d'abord le brouillon EN, capture le documentId renvoyé, puis émet trois appels de suivi PUT /api/articles/{documentId}?locale=de (ainsi que ?locale=ja et ?locale=es) avec des payloads traduits de manière naturelle. Strapi les considère comme des variantes localisées d'un même document canonique, ce qui maintient les quatre versions liées dans l'admin et dans le sélecteur de locale du front-end.

Les règles de traduction que je lui ai données, issues pour la plupart de mauvais résultats rencontrés puis corrigés :

Ne pas traduire les termes techniques qui sont déjà des emprunts à l'anglais dans la langue cible. « API », « CMS », « agent » et « prompt » restent en anglais en JA et en DE. Les traduire sonne faux dans les deux langues.
Adapter les idiomes de façon naturelle. Une traduction littérale de « kills your Friday » en allemand est du charabia ; une version native de la même métaphore fait mouche.
Réajuster les CTA selon la locale. Les impératifs paraissent plus insistants en DE, alors je les adoucis ; la version JA s'atténue généralement en une invitation polie.
Réajuster les titres selon la longueur. Les titres allemands tendent à être environ 30 % plus longs que leurs équivalents anglais. Les titres japonais tendent à être plus courts. Lucas maintient les titres sous la limite de troncature SERP de 60 caractères pour chaque locale.

La publication de contenu multilingue était la partie du workflow qui dévorait autrefois le plus de temps. Désormais, ce n'est que la dernière étape de la même exécution de l'agent.

Ce qui n'est pas automatisé

Une section courte mais importante. Tout dans ce workflow n'est pas automatisé, et c'est délibéré :

Le choix du sujet au niveau stratégique. Lucas choisit les mots-clés à l'intérieur d'un sujet, mais le sujet lui-même vient de moi, généralement des lancements de produit, des conversations clients ou des inflexions de la roadmap.
La relecture éditoriale finale. Je lis chaque brouillon avant sa publication. En particulier la version EN. Le ton, l'exactitude des affirmations techniques, les renvois au contexte produit interne nécessitent tous un œil humain.
La relecture par un locuteur natif pour les langues que je ne parle pas couramment. Je ne lis pas l'allemand couramment. Le brouillon DE passe par un relecteur natif pour une dernière passe avant publication.
La promotion. Publier sur X, envoyer aux abonnés, partager dans les communautés restent manuels pour l'instant.

Le but n'est pas de me retirer de la boucle. C'est de me retirer des parties de la boucle qui n'ont pas vraiment besoin de moi.

Comment je suis arrivé à ce workflow

Je ne me suis pas assis un week-end pour concevoir tout cela. Ça s'est accumulé, article après article, en remarquant quelles étapes dévoraient mon temps.

Ce que j'ai constaté : les parties qui valaient la peine d'être automatisées n'étaient pas les parties créatives. C'étaient les parties connectrices : les extractions de mots-clés, les rendus de couverture, les appels de téléversement, le déploiement vers les locales, le formatage de l'URL de prévisualisation. Quand j'en ai fait le compte honnêtement, je passais plus de temps sur la logistique que sur l'écriture proprement dite.

J'ai donc progressivement déplacé la logistique dans l'agent. Le modèle écrit ; l'agent s'occupe de déplacer les choses. Je reste celui qui décide de quoi écrire et de la façon dont cela doit sonner, simplement je ne suis plus celui qui assemble les morceaux.

Pour moi, l'automatisation de contenu en pratique ne s'est pas avérée être « l'IA écrit le blog ». Elle s'est avérée être « l'IA fait tout ce qui entoure l'écriture, pour que j'aie le temps de réellement me pencher sur l'écriture ».

Si vous voulez tenter quelque chose de similaire

Si vous êtes dans une situation comparable, portant plus de casquettes que vous ne le voudriez avec le contenu parmi elles, l'essentiel de tout ceci est reproductible :

Une plateforme d'agents qui vous permet de donner à l'agent un rôle et des skills persistants (nous utilisons Zero, où vit Lucas).
Des connecteurs vers vos outils existants : votre CMS, votre outil de recherche de mots-clés, votre générateur d'images, votre Slack.
Un petit ensemble de skills adaptés à votre marque (dans notre cas draw pour les couvertures et copywriting pour le ton).
Des instructions permanentes qui portent le contexte, afin que les prompts puissent rester courts.

Démarrez un espace de travail Zero gratuit →

Ou si vous préférez voir davantage de workflows d'agents avant de vous inscrire, notre bibliothèque de cas d'usage compte 19 automatisations prêtes à copier dans les domaines de l'ingénierie, du produit, du marketing et des opérations.

Si vous souhaitez cloner Lucas en particulier : créez un agent, donnez-lui le rôle Marketing manager, connectez Strapi (ou votre CMS) + Ahrefs + un outil de génération d'images, ajoutez un skill draw modelé sur le vôtre, et un skill copywriting qui capture la voix de votre marque. Il déduira le reste à partir de votre premier prompt.