Le texte, c'est la partie facile : le pipeline qui illustre les articles rédigés par IA

Vous êtes développeur avec un objectif de contenu : des dizaines d'articles par mois, parfois des centaines. Le modèle de rédaction gère le brouillon, le plan, la meta description, les liens internes. Puis le pipeline arrive à la seule étape qui n'a pas de modèle propre — les images — et s'arrête. Pas parce que les images sont difficiles à obtenir, mais parce que rien dans la chaîne ne sait laquelle choisir, d'où, avec quelle licence, décrite comment.

Cet article est cette étape manquante, câblée de bout en bout : quel type de visuel produire pour quel type de section, le prompt qui transforme un brouillon terminé en briefs de recherche, l'appel API qui renvoie les photos, le second modèle qui dessine ce qu'une photographie ne peut pas dire, et l'assembleur qui émet un balisage que Google peut réellement lire. Deux workflows complets à la fin, prêts à être repris.

Le texte est résolu. L'illustration est là où ça bloque.

Faites l'audit honnête d'un pipeline d'articles automatisé. Plan : résolu. Brouillon : résolu. Titre, meta description, schéma, liens internes, traduction : résolu, tout par le même modèle, tout en texte. Ensuite :

Faites glisser le tableau pour voir toutes les colonnes →

L'échec n'est pas esthétique, il est structurel : l'article sort avec un placeholder générique, ou avec la même photo que les douze précédents, ou avec une image générée dont la main à six doigts est la première chose que voit un lecteur. Et l'image n'est pas de la décoration — la documentation de Google sur les images le dit clairement : le texte alt « est l'attribut le plus important pour fournir des métadonnées sur une image », et la recommandation est d'utiliser de vrais éléments <img> avec un alt descriptif plutôt que des arrière-plans CSS, pour que l'image puisse être trouvée et comprise.1

Quatre types de visuel, quatre types de modèle

La plus grande erreur de conception consiste à traiter « l'image » comme un seul problème avec un seul fournisseur. Ce sont en réalité quatre problèmes, et le routeur entre eux est une ligne de prompt, pas un service :

Faites glisser le tableau pour voir toutes les colonnes →

Le pipeline, de bout en bout

Cinq étapes. Seule l'étape 3 touche une API d'images, et seule l'étape 4 est optionnelle :

┌─ 1. WRITE ────────────────────────────────────────────────────┐
   topic ──▶ LLM ──▶ draft.md  (h2 sections, front-matter)
└───────────────────────────────┬───────────────────────────────┘
┌─ 2. BRIEF ────────────────────┴───────────────────────────────┐
   draft.md ──▶ LLM ──▶ { hero: {...}, sections: [ {...} ] }
                     un seul objet JSON : par emplacement, un kind +
                     soit un brief caméra, soit une spec de données/schéma
└──────────┬──────────────────────────────────┬─────────────────┘
           │ kind = "photo"                │ kind = "chart" | "diagram"
           ▼                               ▼
┌─ 3. SEARCH ───────────────┐   ┌─ 4. DRAW (optional) ─────────┐
   GET /search/photos          LLM ──▶ mermaid | plotting code
   ← credited photo +           ──▶ sandbox ──▶ .svg / .png
     w/h, blur_hash, alt,       (rendu déterministe, aucun
     licence, source URL         chiffre inventé)
└──────────┬────────────────┘   └──────────────┬───────────────┘
           └───────────────┬──────────────────┘
┌─ 5. ASSEMBLE ─────────────┴───────────────────────────────────┐
   <img> avec width/height + fetchpriority | loading
   alt écrit pour un humain · crédit visible · ImageObject JSON-LD
   photo_id stocké pour qu'aucune page ne partage un hero
└───────────────────────────────────────────────────────────────┘

Deux propriétés comptent plus que le schéma. L'étape 2 est un routeur : elle décide, par emplacement, quel producteur intervient, si bien que vous ne demandez jamais à une banque de photos un graphique en barres. Et l'étape 5 est là où se joue le SEO — tout ce que Google documente sur les images (alt descriptif, métadonnées de licence, un hero sûr pour le LCP) est émis ici, à partir de champs que la réponse de recherche portait déjà.

Étape 2 : transformer le brouillon en briefs visuels

Un seul appel de modèle sur le brouillon terminé, et ce qu'il retourne est un plan plutôt qu'une requête. Comment rédiger un brief photo unique — pourquoi le titre de l'article est la pire entrée possible, à quoi ressemble un brief caméra de 12 à 25 mots, et ses modes d'échec — est exposé en détail dans le guide sur l'illustration d'un article, et n'est pas repris ici. Ce qu'un pipeline ajoute, c'est le routage : le même appel doit décider, emplacement par emplacement, quel producteur s'exécute — et une entrée de type graphique porte des données là où une entrée photo porte une scène.

# prompt système — exécuté une fois par brouillon terminé
Vous êtes le directeur artistique d'une publication technique. Lisez l'article et
renvoyez le plan visuel : une entrée pour le hero, une par section H2.

Pour chaque entrée, choisissez exactement un kind :
  "photo"    une scène réelle : quelqu'un fait quelque chose quelque part, un lieu,
              un objet, un geste. Le choix par défaut pour les heroes.
  "chart"    la section énonce des chiffres qui figurent DANS l'article. N'inventez
              jamais de valeurs : copiez-les dans data, mot pour mot.
  "diagram"  la section décrit une structure, un flux ou une séquence.
  "none"     la section est courte, ou porte déjà un bloc de code.

Règles pour les entrées "photo" — le champ est query :
   Rédigez un descriptif de prise de vue : une scène qu'une caméra aurait pu
   capturer, de 12 à 25 mots, en anglais, correspondant à l'ambiance de la
   section. Nommez ce qui figure dans le cadre, jamais le sujet. Pas de texte,
   de logos, de marques ni de personnes célèbres ; pas de métaphores invisibles.
   (Règles complètes, avec exemples et cas d'échec :
   pexafy.com/blog/illustrate-blog-articles-at-scale/)

N'écrivez PAS le texte alt d'une entrée photo : l'image que vous recevrez est la
correspondance la plus proche du brief, pas la scène que vous avez décrite, donc son alt
doit être rédigé à partir de la photo choisie. Les entrées chart et diagram portent
bien un alt — là, vous contrôlez exactement ce qui est rendu.

Renvoyez uniquement du JSON :
{
  "hero": { "kind": "photo", "query": "…", "orientation": "landscape" },
  "sections": [
    { "h2": "…", "kind": "photo",   "query": "…" },
    { "h2": "…", "kind": "chart",   "title": "…", "unit": "ms",
      "data": [ {"label": "…", "value": 0} ], "alt": "…" },
    { "h2": "…", "kind": "diagram", "spec": "flowchart LR; …", "alt": "…" }
  ]
}

La ligne kind fait l'essentiel du travail, et l'instruction data fait le reste : une entrée de type graphique ne peut porter que des nombres déjà présents dans le brouillon, si bien que le modèle transcrit plutôt qu'il n'invente. Voici le routeur appliqué à trois sections réelles d'un article destiné aux développeurs :

Faites glisser le tableau pour voir toutes les colonnes →

Étape 3 : les photos reviennent créditées

Chaque entrée kind: "photo" correspond à une requête. Le brief hero ci-dessus, exécuté contre l'API publique, renvoie ceci en 147 ms :

GET /search/photos — brief hero · « un développeur qui travaille tard à un bureau avec deux écrans… » · 147 ms

Hero choisiUnsplash Unsplash Pexels

Le brief de la dernière section, une scène complètement différente, en 144 ms :

GET /search/photos — brief de section · « deux ingénieurs debout devant un tableau blanc couvert de schémas… » · 144 ms

Meilleur résultat · 0.91Pexels Unsplash Unsplash

Ce qui revient par photo est ce qui rend l'étape 5 possible — pas seulement un fichier :

{
  "photo_id":  "019e1c7f-0063-759e-b498-33ce1714e6c9",   // à stocker : pas de répétition
  "urls": { "small": "…?w=400", "regular": "…?w=1080",
             "large": "…?w=1920" },
  "width": 3000, "height": 1688,          // → pas de décalage de mise en page
  "blur_hash": "LJ8gjv9rVq-6OFxanNNFI7xco$Na",   // → vrai placeholder
  "alt_description": "Person types on keyboard in front of dual monitors…",
  "photographer_full_name": "Jakub Żerdzicki",   // → ImageObject.creator
  "source": "Unsplash", "license_type": "free",
  "source_image_url": "https://unsplash.com/photos/…",
  "attribution": { "html": "<span…>Photo by …</span>",
                    "plain": "Photo by Jakub Żerdzicki on Unsplash (…)" }
}

Étape 4 : ce qu'une photographie ne peut pas dire

Deux emplacements du plan ne sont pas recherchables, et c'est précisément là qu'un second modèle trouve sa place — pas pour dessiner une image, mais pour écrire le code qui la dessine. La distinction compte : le code est révisable, déterministe et ne peut pas halluciner la hauteur d'une barre.

Schémas : du texte en entrée, du SVG en sortie

Mermaid rend des schémas à partir d'une définition en texte brut,3 ce qui en fait la cible la plus sûre pour un modèle : la sortie est inspectable, comparable dans git, et se rend de la même manière à chaque fois. Le routeur a déjà renvoyé la spec.

# le champ "spec" d'une entrée diagram, écrit dans build/graph.mmd
cat build/graph.mmd
flowchart LR
  install["install deps · 480s"] --> compile["compile · 1080s"]
  compile --> test["test suite · 720s"]
  compile --> upload["upload artifacts · 120s"]

npx -y @mermaid-js/mermaid-cli -i build/graph.mmd -o static/img/graph.svg
# → un SVG que vous pouvez relire dans la PR, pas une image à croire sur parole

Graphiques : uniquement des chiffres que l'article contient déjà

Même principe, un garde-fou supplémentaire. Le routeur a copié les valeurs depuis le brouillon ; le modèle écrit le code de tracé ; le code s'exécute dans un sandbox ; l'assembleur revérifie les valeurs rendues contre les chiffres source avant que le graphique ne soit autorisé à approcher une page.

import re, matplotlib
matplotlib.use("Agg")                # sans interface : pas d'affichage en CI
import matplotlib.pyplot as plt

def assert_in_draft(value, draft: str) -> None:
    """Un chiffre tracé doit apparaître dans l'article EN TANT QUE NOMBRE."""
    # Le piège ici, c'est la correspondance de sous-chaîne : "120" est dans "1200",
    # et dans "?w=1200" — un `str(v) in draft` naïf passe sur n'importe quoi.
    # On matche sur des frontières de mot, et on accepte 1 234 / 1,234 / 1234.
    body = re.sub(r"(?<=\d)[  ,](?=\d{3}\b)", "", draft)   # retire les séparateurs
    if not re.search(rf"(?<![\d.]){re.escape(str(value))}(?![\d.])", body):
        raise ValueError(f"{value} is not stated in the article — refusing to plot")

def render_chart(entry: dict, draft: str, out: str) -> str:
    labels = [d["label"] for d in entry["data"]]
    values = [d["value"] for d in entry["data"]]
    for v in values:
        assert_in_draft(v, draft)       # valeur hallucinée → pas de graphique

    fig, ax = plt.subplots(figsize=(8, 4.5), dpi=160)
    ax.barh(labels, values)
    ax.set_xlabel(entry["unit"])
    ax.set_title(entry["title"])
    fig.tight_layout()
    fig.savefig(out)                    # artefact déterministe, révisable
    return out

Le garde-fou est court, mais écrivez-le soigneusement : une vérification par sous-chaîne ne fonctionne pas. "120" in draft est vrai pour un article qui contient 1200 ou ?w=1200, si bien que la version naïve passe sur tout et ne protège rien. Ancrez sur des frontières de chiffres, normalisez les séparateurs de milliers, et la classe d'erreur qui fait démonter un article technique dans les commentaires — un graphique contredisant son propre paragraphe — ne peut plus atteindre la production. Les captures d'écran suivent le même principe : un page.screenshot() scripté contre votre vrai build est la seule source de vérité pour votre propre interface, et elle reste vraie au fil des évolutions de l'interface.

Étape 5 : c'est dans l'assemblage que se joue le SEO

Tout ce qui précède a produit des fichiers et des champs. Cette étape les transforme en balisage — et il vaut mieux être précis ici, car trois comportements documentés se décident dans ces quelques lignes.

<!-- Les octets viennent d'une autre origine : payez la poignée de main tôt -->
<link rel="preconnect" href="https://images.unsplash.com" crossorigin>

<!-- Élément LCP : jamais lazy, toujours priorité haute -->
<figure>
  <img src="{urls.regular}"
       width="{width}" height="{height}"        <!-- élimine le décalage de mise en page -->
       alt="{alt}"                                <!-- écrit APRÈS le choix -->
       fetchpriority="high" decoding="async"
       style="background:{color_hex}">   <!-- couleur dominante, 1 champ -->
  <figcaption>{attribution.html}</figcaption>
</figure>

<!-- Images de section, sous la ligne de flottaison : les réglages inverses -->
<img src="{urls.regular}" width="{width}" height="{height}"
     alt="{alt}" loading="lazy" decoding="async">

1. Ne jamais mettre le hero en lazy-load. web.dev est sans ambiguïté : « Ne mettez jamais votre image LCP en lazy-load, cela entraînera toujours un délai de chargement de ressource inutile et aura un impact négatif sur le LCP », et il recommande fetchpriority="high" sur l'élément susceptible d'être le LCP — utilisé avec parcimonie, sur une seule image. 4 Un pipeline qui applique loading="lazy" sur toutes les images, hero compris, est la blessure Core Web Vitals auto-infligée la plus courante en publication automatisée.
2. Émettez toujours width et height — ils reviennent dans la réponse, donc aucune excuse ; cette seule paire d'attributs est ce qui permet au navigateur de réserver l'espace et empêche la mise en page de sauter. Utilisez blur_hash comme placeholder pendant le chargement du fichier.
3. Écrivez l'alt après le choix, jamais avant. C'est le point subtil. Le champ alt du plan décrit la scène demandée ; la photo obtenue est la correspondance la plus proche, pas cette scène. Livrer le texte du brief comme alt est exactement l'échec d'accessibilité que ce pipeline est censé éviter — une description d'une image qui n'est pas sur la page. Construisez l'alt à partir de l'alt_description de la photo choisie, affiné en fonction du paragraphe dans lequel elle s'insère. La recommandation de Google est de « se concentrer sur la création de contenu utile et riche en informations, qui utilise les mots-clés de manière appropriée et dans le contexte du contenu de la page », et elle prévient que bourrer les attributs alt de mots-clés « entraîne une mauvaise expérience utilisateur et peut faire percevoir votre site comme du spam ».1

La partie que presque personne n'automatise : les métadonnées de licence

Google prend en charge les données structurées ImageObject pour la licence des images. Cela requiert contentUrl plus au moins un des champs creator, creditText, copyrightNotice ou license, recommande acquireLicensePage, et les images avec des informations de licence deviennent éligibles au badge Licensable dans Google Images.5 Chacun de ces champs est déjà présent dans la réponse de recherche — l'émettre relève donc d'un template, pas d'un projet :

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "{urls.large}",                 // requis
  "creator": { "@type": "Person",
                "name": "{photographer_full_name}" },
  "creditText": "{photographer_full_name} on {source}",
  "license": "{LICENSE_URL[source]}",           // la propre page de la banque
  "acquireLicensePage": "{source_image_url}"     // la page de la photo
}
</script>

# LICENSE_URL fait correspondre le champ `source` à la licence qui régit
# réellement la photo — unsplash.com/license, pexels.com/license, pixabay.com/…

Un détail qui vaut la peine d'être bien fait : license doit pointer vers la licence qui régit cette photo — la propre page de licence de la banque source — pas une page récapitulative sur votre domaine. Google la lit pour décider de l'éligibilité au badge, et une URL auto-référencée est à la fois un signal plus faible et difficile à défendre autrement que comme un lien vers vous-même. Conservez votre propre résumé de licence comme page interne pour les lecteurs ; placez l'URL canonique dans le balisage.

Et tant que vous êtes dans l'assembleur : donnez au fichier un nom court et descriptif plutôt que IMG_0042.jpg, et ajoutez l'image à un sitemap — le format de sitemap d'images de Google accepte jusqu'à 1 000 images par URL de page.6 Les deux tiennent chacun en une ligne dans un pipeline et aucun des deux n'est jamais fait à la main.

Deux pipelines à reprendre

Mêmes cinq étapes, deux formes très différentes — l'une pour les articles que vous rédigez, l'autre pour la documentation qui doit correspondre à un produit en fonctionnement. Choisissez celui dont vous reconnaissez le mode d'échec.

1 · Le blog de développeurs en CI — Markdown dans le dépôt

Les articles vivent en Markdown, les images sont commitées à côté, et tout tourne au push. Déterministe, révisable dans la PR, aucune dépendance à l'exécution envers une quelconque API :

on: { pull_request: { paths: ["content/**.md"] } }

jobs:
  illustrate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: python plan_to_pr.py $(git diff --name-only origin/main -- 'content/*.md')
        env:
          PEXAFY_API_KEY: ${{ secrets.PEXAFY_API_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
      - uses: peter-evans/create-pull-request@v6   # les images arrivent dans la PR
        with: { commit-message: "chore(content): illustrate" }

Un humain approuve toujours la PR, et c'est là tout l'intérêt : le pipeline propose, le relecteur dispose, et le front-matter qu'il a écrit est comparable ligne à ligne.

La partie recherche tient en un seul GET — la requête, son score_threshold et les champs qu'elle retourne sont détaillés ligne par ligne dans le guide sur l'article unique, ils sont donc importés ici plutôt que réimprimés. Ce que ce fichier ajoute, c'est tout ce dont un plan a besoin et qu'une seule photo n'a pas : la nouvelle tentative sur un brief qui n'a rien retourné, la réservation d'un photo_id pour qu'aucune page ne partage une image avec une autre, et le texte alternatif rédigé à partir de la photo obtenue.

import frontmatter
from photo_search import search   # un seul GET /search/photos ; ignore les ids présents dans `used`

def find_photo(entry: dict, used: set) -> dict | None:
    """Cherche ; si le brief était trop spécifique, l'élargit une fois, puis abandonne."""
    orientation = entry.get("orientation", "landscape")
    for query in (entry["query"], widen(entry["query"])):
        photo = search(query, orientation, used)
        if photo:
            used.add(photo["photo_id"])   # réservée : pas de répétition sur le site
            return photo
    return None                        # l'appelant décide : ignorer l'emplacement, ou échouer

def widen(query: str) -> str:
    """Retire la dernière clause — généralement la trop spécifique."""
    return query.rsplit(" in ", 1)[0] if " in " in query else query

def illustrate(path: str, plan: dict, used: set) -> None:
    post = frontmatter.load(path)
    hero = find_photo(plan["hero"], used)
    if hero is None:                    # pas de hero vaut mieux qu'un mauvais
        raise SystemExit(f"{path}: no photo above threshold — rewrite the brief")

    post["hero"] = {                    # tout ce dont le template a besoin
        "src": hero["urls"]["regular"], "w": hero["width"], "h": hero["height"],
        # L'alt décrit la photo REÇUE, jamais la scène demandée.
        "alt": alt_for(hero, section=post.get("title", "")),
        "bg": hero["color_hex"], "credit": hero["attribution"]["html"],
        "creator": hero["photographer_full_name"], "id": hero["photo_id"],
        "source": hero["source"],
        "source_url": hero["source_image_url"],   # → acquireLicensePage
    }
    open(path, "w").write(frontmatter.dumps(post))

def alt_for(photo: dict, section: str) -> str:
    """alt_description comme base, réduit à ~125 caractères pour les lecteurs d'écran.
    Repassez-le par le modèle avec le paragraphe si vous voulez mieux."""
    base = photo.get("alt_description") or photo.get("description", "")
    return base[:125].rstrip(" ,;")

2 · Docs & changelog — captures d'écran d'abord, photos en dernier

Inversez les valeurs par défaut du routeur. Dans la documentation produit, le visuel honnête est presque toujours votre propre interface : un script Playwright qui ouvre le vrai build, fixe un viewport précis et capture exactement l'état que décrit le paragraphe. Les schémas couvrent les pages d'architecture, et les photographies n'apparaissent que sur les pages conceptuelles et de landing — là où une capture d'écran ne dirait rien.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page(viewport={"width": 1440, "height": 900},
                            device_scale_factor=2)   # net comme du retina
    page.goto("http://localhost:3000/dashboard")
    page.get_by_role("button", name="New API key").click()
    page.screenshot(path="static/img/docs/new-api-key.png")
    browser.close()
# Tourne dans le même job CI que le build de la doc → la capture d'écran ne peut
# jamais décrire une version de l'interface qui n'existe plus.

Deux variantes qui méritent d'être nommées mais pas leur propre recette. Le SEO programmatique inverse la boucle : avec des centaines de pages générées depuis une base de données, vous ne cherchez pas par page — une requête renvoie jusqu'à 100 photos, donc vous cherchez par groupe thématique et assignez depuis un pool, avec une contrainte d'unicité qui gère la déduplication (cette architecture, en détail). Et les newsletters et cartes sociales ont besoin de la même photo en quatre recadrages : conservez le photo_id, demandez la taille dont vous avez besoin dans urls, et ne recherchez à nouveau que quand un recadrage échoue réellement.

Le même pipeline, comme un seul agent

Si un modèle rédige déjà le brouillon, le chemin le plus court consiste à lui donner directement l'outil de recherche plutôt que de faire circuler du JSON entre processus. Pexafy exploite un serveur Model Context Protocol hébergé à l'adresse mcp.pexafy.com/mcp. La configuration du connecteur et les outils qu'il expose sont traités ailleurs — la configuration bureau et éditeur dans le guide sur un article unique, la variante headless pour un runner CI dans l'article sur le contenu à grande échelle, et à quoi ressemble le marché plus large des connecteurs — qui propose un serveur d'images MCP, à quelles conditions — dans l'étude de l'infrastructure de recherche d'images pour les agents IA. Ce qui mérite d'être montré ici, c'est ce qui arrive à ce pipeline une fois que l'agent dispose des outils : il ne s'agit plus de cinq étapes mais d'une seule instruction.

Vous  Voici le brouillon. Construis le plan visuel, illustre-le, et ouvre une PR.
     Les graphiques uniquement à partir de chiffres déjà présents dans le texte.

Agent  → plan : hero=photo · §2=chart · §3=diagram · §4=photo
      → search_photos(q="a developer working late at a desk with two
         monitors and a mechanical keyboard in a dark room…")
      ← 16 photos · 147 ms · sélectionnée #1, 3000×1688, créditée
      → mermaid-cli build/graph.mmd → static/img/graph.svg
      → chart.py §2 → 4 valeurs vérifiées contre le brouillon ✓
      → search_photos(q="two engineers standing at a whiteboard…")
      ← 16 photos · 144 ms · sélectionnée #1

      ✓ 4 emplacements remplis · 2 appels API · alt + crédit + ImageObject écrits
      ⚠ §5 n'a rien renvoyé au-dessus de 0.5 — brief trop abstrait, réécrit en
        "a person at a kitchen table checking figures on a laptop"

Cette dernière ligne explique pourquoi un agent vaut la peine dans cette boucle plutôt qu'un simple script : le mode d'échec de l'illustration automatisée est un mauvais brief, et réécrire un mauvais brief est exactement ce à quoi sert un modèle de langage. Gardez les parties déterministes — l'assignation, la déduplication, le garde-fou numérique — dans le code.

Ce que coûte un article illustré

Trois emplacements photo par article signifient trois requêtes de recherche, si bien que le plan gratuit (5,000 requêtes/mois) couvre 1,666 articles par mois avant même que la question de payer se pose — et si vous mutualisez les recherches par groupe thématique plutôt que par article, ce plafond gagne encore un ordre de grandeur. La ventilation plan par plan, et l'architecture de mutualisation qui la rend accessoire, se trouvent dans l'article compagnon sur l'illustration de contenu à grande échelle.

Les deux appels modèle par article — un pour le brouillon, un pour le plan visuel — représentent quelques milliers de tokens et seront la ligne la moins chère du pipeline ; les rendus Mermaid et matplotlib ne coûtent rien à part des secondes de CI. Le chiffre qui surprend les gens, c'est la ligne qui n'est pas bon marché : générer quatre images par article, quatre cents images par mois, plus les tentatives qui n'ont pas été retenues — et le résultat ne porte toujours aucun photographe, aucune date et aucune URL source.

Ce que ce pipeline ne règle pas

Une section honnête, car l'échec qu'elle prévient est coûteux. Un article bien illustré reste un article : une vraie photographie, des graphiques exacts et un balisage correct améliorent une page qui mérite d'exister. Ils ne font pas se positionner un contenu léger produit en masse. Les politiques anti-spam de Google nomment l'abus de contenu à grande échelle — générer de nombreuses pages principalement pour manipuler le classement et offrant peu de valeur aux utilisateurs, que l'automatisation soit impliquée ou non — et la qualité des illustrations n'entre pas dans ce jugement.7

Le cadre qui tient donc la route : ce pipeline est un plancher de qualité que vous contrôlez, appliqué à des pages qui ont déjà une raison d'être publiées. Là où il paie démonstrablement :

• Une provenance qu'un lecteur peut vérifier. Une mention de crédit avec un vrai photographe et une URL source est une affirmation vérifiable — et ces mêmes champs alimentent le balisage ImageObject que Google lit.
• Accessibilité et Core Web Vitals. Un vrai texte alt, des dimensions sur chaque image, un hero jamais en lazy-load. Multipliez par chaque article publié et c'est ça qui fait la qualité d'image du site.
• Une exactitude vérifiable. Un graphique dont les chiffres sont vérifiés contre l'article, une capture d'écran générée depuis le build en cours d'exécution, un schéma révisable comme du texte dans la PR — trois visuels qui ne peuvent pas dériver de la vérité sans qu'un test échoue.

Sur l'attribution, le point propre à ce pipeline est étroit : l'argument en faveur de l'affichage systématique du crédit est développé ailleurs, et ce qu'un assembleur automatisé ajoute, c'est que la même chaîne attribution qu'il affiche est le creditText dont les données structurées ont besoin. Un seul champ, deux emplacements, émis dans la même passe de template — ce qui fait qu'un pipeline a encore moins d'excuse qu'un humain de l'omettre.

Par où commencer

1. Ajoutez le prompt routeur à ce qui rédige déjà vos brouillons, et affichez le JSON sans agir dessus. Lisez dix plans. Si les briefs nomment des sujets plutôt que des scènes, corrigez le prompt avant d'écrire la moindre intégration.
2. Câblez uniquement les emplacements photo. Un GET /search/photos par brief, et stockez photo_id dès le premier jour — une déduplication rétrofittée sur 3 000 pages en production est une migration, pas une colonne.
3. Émettez width, height et alt dans le même commit. C'est le travail Core Web Vitals le moins cher que vous ferez jamais.
4. Ajoutez ensuite l'étape 4, les schémas avant les graphiques — Mermaid est du texte, donc c'est celui qui n'a aucun mode d'échec au-delà d'une erreur de syntaxe.
5. Ajoutez le garde-fou numérique avant que le premier graphique n'atteigne un lecteur, pas après.

Références & notes de bas de page