Mettre un contrôle qualité avant toute publication

Tout texte écrit par un agent doit franchir deux portes avant que quiconque à l’extérieur ne le voie : un contrôle mécanique exécuté par un script, et un jugement rendu par un second modèle qui n’a jamais vu comment le texte a été produit. Un agent ne note jamais son propre travail. Ajoutez un jeu de cas de test figés, relancé à chaque modification des instructions, et vous attrapez l’essentiel des erreurs avant qu’elles ne vous coûtent quelque chose.

C’est ainsi que fonctionnent les agents qui font tourner le marketing de Derrick (j’ai cofondé Derrick, lisez la suite en gardant ce biais en tête). Chaque post, chaque page, chaque message outbound qu’ils écrivent passe par ces deux portes, et chaque domaine de travail a un pilote, un agent ou une skill dont le seul rôle est de contrôler la production avant sa sortie.

Pourquoi l’auteur ne peut pas se relire lui-même

Un modèle qui a écrit un texte garde les mêmes angles morts quand il le relit. Il sait ce qu’il voulait dire, donc il lit ce qu’il voulait dire. Demandez-lui « est-ce que c’est bon ? » dans la même conversation : il répondra le plus souvent oui, puis polira la formulation autour du vrai problème.

Répartissez donc les contrôles selon le type d’erreur qu’ils attrapent.

Erreur	Exemple	Qui l’attrape
Forme interdite	Tiret cadratin, expression bannie, nom d’un concurrent	Un script, à chaque fois
Fait faux	Un prix qui a changé, une fonctionnalité qui n’existe pas	Un script, contre votre fichier de faits
Contenu faible ou hors sujet	Accroche générique, mauvais angle, aucune preuve	Un juge indépendant
Une promesse que le produit ne tient pas	Le post décrit un geste que l’outil ne fait pas	Une vérification dans le produit lui-même
Régression après une modification	Les nouvelles instructions cassent un ancien cas	Des cas de test figés

Les deux premières lignes sont bon marché et certaines. Traitez-les en code, jamais dans un prompt : un modèle à qui l’on demande « évite les tirets cadratins » en produira quand même un de temps en temps, alors qu’une expression régulière n’en rate aucun.

Première porte : un lint mécanique

Le lint est un court script qui lit le brouillon et sort en erreur dès qu’un motif correspond. Voici la forme du mien, simplifiée.

import re, sys

text = open(sys.argv[1], encoding="utf-8").read()
errors = []

PATTERNS = {
    "dash used as punctuation": r"[\u2013\u2014]",
    "banned phrase": r"(?i)\b(best-in-class|cutting-edge|in a world where)\b",
    "competitor name": r"(?i)\b(acme|globex)\b",  # charger la vraie liste depuis un fichier
}
ALLOWED_PRICES = {"20", "47.50", "175", "320"}  # lu depuis votre fichier de faits produit

for label, pattern in PATTERNS.items():
    for m in re.finditer(pattern, text):
        errors.append(f"{label}: {m.group(0)!r}")

for m in re.finditer(r"€\s?(\d+(?:[.,]\d+)?)|(\d+(?:[.,]\d+)?)\s?€", text):
    price = (m.group(1) or m.group(2)).replace(",", ".")
    if price not in ALLOWED_PRICES:
        errors.append(f"price not in facts file: {m.group(0)}")

print("\n".join(errors) or "OK")
sys.exit(1 if errors else 0)

Deux détails comptent plus que les motifs eux-mêmes. Les listes vivent dans des fichiers que le reste du système lit aussi, si bien que le prix dans le lint et le prix dans les faits produit ne peuvent jamais diverger ; le chapitre sur la mémoire explique où chaque fait doit vivre. Et c’est l’agent qui lance le lint, lit les erreurs et les corrige : vous ne voyez que des brouillons qui passent déjà.

Chez moi, un script vérifie aussi que chaque fonctionnalité citée dans un texte existe bel et bien avant que le texte puisse la mentionner, et les comptes sont calculés, jamais tapés à la main. Un nombre écrit dans un prompt est périmé le jour où le produit change.

Deuxième porte : un juge dans un contexte vierge

Le juge est un appel séparé, avec une conversation vide. Il reçoit le brief, le brouillon et une grille, rien d’autre : ni les instructions de l’auteur, ni les versions précédentes, ni son raisonnement. C’est ce qui le rend indépendant.

You review a draft written by someone else. You did not write it.

BRIEF: {{brief}}
DRAFT: {{draft}}

Score each criterion from 1 to 5 and quote the passage that justifies the score.
1. Answers the brief: the main point is in the first two sentences.
2. Proof: every claim is backed by a fact, an example or a number from the brief.
3. Voice: reads like the reference samples, no stock AI phrasing.
4. Reader value: the reader can do something after reading.

Return JSON only:
{"scores": {"brief": n, "proof": n, "voice": n, "value": n},
 "blocking_issues": ["..."], "verdict": "pass|revise|reject"}
Verdict is "pass" only if every score is 4 or more and there is no blocking issue.

Exiger une citation derrière chaque note empêche le juge de distribuer des 4 par défaut. Écrire la règle de validation dans le prompt fait du verdict une règle appliquée aux notes, pas une humeur. Quand le verdict est « revise », les problèmes bloquants repartent tels quels chez l’auteur, et le nouveau brouillon repasse les deux portes.

Pour la grille, partez des règles du fichier d’instructions de l’agent. Le juge doit vérifier ce qu’on a demandé à l’auteur, plus ce qu’on ne remarque qu’en tant que lecteur.

Vérifier la promesse dans le produit

Certaines erreurs franchissent les deux portes, parce que le texte est bien écrit et plausible. En novembre 2026, un post LinkedIn pour Derrick disait « filtrer, puis enrichir ». En confrontant cette affirmation au code, on a vu que le bouton lecture dans l’en-tête de colonne enrichissait aussi les lignes masquées, et les facturait. Le texte avait raison sur la méthode et tort sur ce que le produit en faisait, ce qu’aucun lint ni aucun juge ne pouvait voir. Le produit a été corrigé.

La règle que j’en ai tirée : quand un texte dit au lecteur de faire quelque chose dans un produit, quelqu’un vérifie ce geste dans le produit avant publication. Un agent qui a accès au code ou à un compte de test peut faire cette vérification, mais ce doit être une étape explicite de la routine, avec un résultat écrit.

Figer des cas de test et les relancer après chaque modification

Les instructions dérivent. Vous ajoutez une règle pour corriger une mauvaise sortie, trois bonnes se dégradent, et vous ne le découvrez que des semaines plus tard. La parade : un jeu de briefs figés, souvent appelés golden evals, des entrées réelles conservées pour toujours, chacune avec ce qu’une bonne sortie doit et ne doit pas contenir.

id: linkedin-tuesday-03
skill: linkedin-writer
brief: "Tuesday data post. Fact: the free plan gives 100 credits a month."
must:
  - mentions "100 credits"
  - opens on the fact, not on a question
must_not:
  - any price other than the plan table
  - a rhetorical question as the first line
judge_min_scores: { brief: 4, proof: 4, voice: 4, value: 3 }

Après toute modification des instructions d’un rédacteur, chaque cas figé repasse par le lint et le juge, et la modification n’est livrée que si aucun ne régresse. Dix à vingt cas par rédacteur suffisent pour commencer. Ajoutez-en un chaque fois qu’un vrai brouillon échoue d’une manière que les cas existants ne couvraient pas : le jeu grandit à partir de vos vraies erreurs.

Ce qui se passe après un échec

Un brouillon refusé ne livre que la moitié de l’information. L’autre moitié, c’est la raison de l’échec, et la probabilité qu’il se reproduise.

Résultat	Ce que fait le pilote	Ce qui est consigné
Le lint échoue	L’auteur corrige et relance, sans humain	Rien, sauf si la même erreur revient
Le juge dit « revise »	L’auteur reçoit les problèmes bloquants et réécrit	Le problème, s’il est nouveau
Le juge dit « reject »	Brouillon abandonné, brief revu par un humain	Le brief et la raison de l’échec
La vérification produit échoue	Texte bloqué, produit ou texte corrigé	Une entrée dans le registre des leçons
Même problème trois fois	La règle entre dans les instructions de l’auteur	Un nouveau cas de test figé

C’est la dernière ligne qu’on saute le plus souvent. Une leçon notée dans un journal ne fait rien toute seule. Dans mon système, une leçon durable est écrite directement dans les instructions de l’expert, parce qu’un rappel n’est pas une action. Pour voir la boucle complète tourner sur une cadence hebdomadaire, le chapitre sur l’agent LinkedIn la montre de bout en bout.

Votre prochaine étape : prenez les dix derniers textes produits par votre agent, notez chaque correction faite à la main et classez-les dans les cinq lignes du premier tableau. Les lignes « forme interdite » et « fait faux » deviennent votre lint cette semaine ; le reste devient la grille du juge et vos premiers cas figés.