Maintenance d'une bibliothèque de prompts Claude Code pour équipes

Un bon prompt ne doit pas rester dans l’historique

Une équipe commence souvent Claude Code avec quelques prompts efficaces dispersés : Slack, commentaire de pull request, note personnelle, page Notion. Pendant une semaine, cela suffit. Ensuite cinq variantes circulent, personne ne sait laquelle est approuvée, et chaque review repart de zéro.

Une bibliothèque de prompts n’est pas un tiroir à phrases. C’est un actif d’exploitation. Elle a besoin de versioning, d’un owner, de review gates, de règles de dépréciation et de métriques. La Claude Code Prompt library officielle donne des modèles utiles, mais votre équipe doit ajouter son contexte : dépôt, pages produit, prix, CTA, formation et support. Les pages officielles sur CLAUDE.md et memory, Skills, Subagents et Hooks complètent ce cadre.

Cet article prolonge la checklist de review Claude Code et la checklist des 30 premières minutes. Il vise les équipes qui veulent relier prompts réutilisables, produits payants, formation et consulting.

Commencez par un registre

Le versioning permet de suivre l’évolution d’un prompt. L’owner est la personne ou fonction responsable. Le review gate est le passage obligé avant usage officiel. La dépréciation retire une ancienne version avec une route de remplacement. Les métriques disent si le prompt réduit le risque, améliore la conversion ou économise du temps.

Enregistrez cet exemple sous prompt-library.json.

[
  {
    "id": "review-risk-finder",
    "version": "1.2.0",
    "owner": "platform",
    "status": "active",
    "useWhen": "A pull request changes behavior, data flow, pricing, or CTA routing.",
    "inputs": ["goal", "diff", "riskAreas", "expectedTests"],
    "output": "Findings ordered by severity with evidence and smallest fix.",
    "reviewGate": "Owner approval plus one successful run on a known risky diff.",
    "deprecates": ["review-risk-finder@1.1.0"],
    "metrics": ["reuse_count", "accepted_findings", "false_positive_rate"],
    "officialDocs": [
      "https://code.claude.com/docs/en/prompt-library",
      "https://code.claude.com/docs/en/memory"
    ]
  }
]

Ce registre ne rend pas le prompt parfait. Il le rend gouvernable. Quand la sortie devient bruyante, l’owner corrige. Quand une page produit change, l’équipe décide si le prompt de review CTA doit passer en version mineure. Quand un atelier est livré, le formateur sait exactement quelle version enseigner.

Un modèle, un résultat

L’erreur coûteuse consiste à demander review, tests, documentation, refactor et amélioration de CTA dans une seule instruction. Cela semble efficace, mais mélange les responsabilités et rend l’échec illisible. Dans une bibliothèque d’équipe, un prompt produit un artefact précis.

# review-risk-finder

You are reviewing a production change for business and user risk.

Context:
- Goal: {{goal}}
- Diff or changed files: {{diff}}
- Risk areas: {{riskAreas}}
- Expected tests: {{expectedTests}}

Return findings first. For each finding include:
1. Severity
2. Evidence from the diff
3. User or revenue impact
4. Smallest safe fix
5. Verification command

If there are no findings, list what you checked and what remains unverified.

Ce format explique à Claude Code ce qui compte comme risque et quelle preuve fournir. L’ingénierie vérifie la commande, le produit juge l’impact revenu, et la personne chargée de la formation peut transformer le même modèle en exercice.

Use case : trois flux liés au revenu

Use case 1 : review de pull request. Au lieu de “regarde s’il y a un problème”, passez l’objectif, le diff, les tests attendus et les zones de risque : paiement, authentification, permissions, suppression de données, routing de CTA. La sortie devient une liste d’actions, pas un commentaire vague.

Use case 2 : maintenance des pages produit. Même si la locale française renvoie vers products, le prompt doit contrôler promesse, lecteur cible, résultat après achat, langage de prix, preuve et liens. L’owner est souvent produit ou marketing, pas seulement l’ingénierie.

Use case 3 : training et consultation. Pour training, le prompt doit faire apparaître la douleur de l’équipe, la maturité du workflow actuel, les risques d’adoption Claude Code et les livrables après atelier. La métrique n’est pas seulement le trafic, mais les demandes qualifiées.

Use case 4 : mise à jour éditoriale. Les articles publiés vieillissent avec les docs officielles, les commandes, les liens internes et les exemples. Un prompt de refresh vérifie official links, updatedDate, code exécutable, visuels et retour d’expérience.

Des gates avant le statut active

Trois statuts suffisent : draft, active, deprecated. Draft se teste. Active peut entrer dans docs, produits et formation. Deprecated reste visible avec une migration.

Utilisez le versioning sémantique simplement. Un changement cassant de format de sortie augmente major. Un nouvel input augmente minor. Une correction d’exemple ou de texte augmente patch. Le but est d’éviter qu’une personne utilise un ancien comportement en pensant être sur la version actuelle.

flowchart LR
  Draft["draft prompt"] --> Owner["owner review"]
  Owner --> Gate["known-risk gate"]
  Gate --> Active["active library"]
  Active --> Metrics["monthly metrics"]
  Metrics --> Deprecate["deprecate or improve"]

Le known-risk gate est le test que beaucoup d’équipes oublient. Gardez un échec réel : diff risqué manqué, bouton d’achat cassé, première erreur cachée dans un log, article avec ancienne URL officielle. Si le prompt ne le détecte pas, il n’est pas prêt.

Limitez le rôle des agents

Un agent est utile quand la tâche est étroite et que le résultat se résume clairement. Les subagents officiels travaillent dans leur propre contexte, ce qui impose une délégation précise. Pour une bibliothèque, séparez trois rôles : librarian pour les métadonnées, reviewer pour tester les sorties, owner pour approuver.

Exemple pour .claude/agents/prompt-librarian.md :

---
name: prompt-librarian
description: Maintains prompt library metadata, ownership, versions, metrics, and deprecation notes.
tools: Read, Grep
---

You audit prompt library entries. Do not rewrite product copy.
Check that each prompt has id, version, owner, status, useWhen, inputs, output,
reviewGate, deprecation note, and metrics. Report missing fields first.

Cet agent doit surtout lire et auditer. Ne lui laissez pas réécrire silencieusement une page de vente. Si une règle doit bloquer une action, placez-la dans Hooks, permissions ou CI. Le prompt guide le jugement ; le gate applique la règle.

Pitfall : les points de dégradation

Pitfall 1 : noms vagues. good-review, debug-helper, marketing-check deviennent introuvables. Préférez checkout-cta-risk-review, build-log-first-failure ou training-page-objection-check.

Pitfall 2 : ne garder que les réussites. Cela masque les limites. Conservez au moins une entrée ratée et une note concrète : “lien prix obsolète manqué”, “n’a lu que les noms de tests”.

Pitfall 3 : tout mettre dans CLAUDE.md. Ce contexte est utile, mais ce n’est pas un moteur de politique. Pour bloquer, utilisez Hooks, permissions ou CI.

Pitfall 4 : ajouter le CTA à la fin. Une vente collée après coup ressemble à une publicité. Concevez le parcours dès le départ : article gratuit, produit pour les modèles prêts à l’emploi, training pour la gouvernance d’équipe.

Script d’audit minimal

Quand la bibliothèque dépasse dix entrées, automatisez le contrôle de base.

import fs from "node:fs";

const file = process.argv[2] ?? "prompt-library.json";
const entries = JSON.parse(fs.readFileSync(file, "utf8"));
const required = [
  "id",
  "version",
  "owner",
  "status",
  "useWhen",
  "inputs",
  "output",
  "reviewGate",
  "metrics"
];

let failed = false;
for (const entry of entries) {
  const missing = required.filter((key) => !entry[key]);
  if (!/^\\d+\\.\\d+\\.\\d+$/.test(entry.version ?? "")) {
    missing.push("version must be semver");
  }
  if (!["draft", "active", "deprecated"].includes(entry.status)) {
    missing.push("status must be draft, active, or deprecated");
  }
  if (missing.length > 0) {
    failed = true;
    console.error(`${entry.id ?? "(missing id)"}: ${missing.join(", ")}`);
  }
}

if (failed) process.exit(1);
console.log(`OK: ${entries.length} prompt entries checked`);

Le script ne juge pas le style. Il bloque les prompts sans owner, version ou reviewGate avant qu’ils n’entrent dans du matériel payant.

Mesurez peu, mais utile

Métrique	Pourquoi	Action
reuse_count	Le prompt est-il trouvable ?	Renommer ou déplacer
accepted_findings	Produit-il des corrections réelles ?	Resserrer la sortie
false_positive_rate	Fait-il perdre du temps ?	Préciser les riskAreas
time_to_fix_minutes	Réduit-il le temps de correction ?	Exiger smallest safe fix
cta_click_rate	Améliore-t-il produit ou training ?	Revoir contexte et position

Un contrôle mensuel suffit. Si un prompt n’est pas utilisé, pas cru, ou pas lié à une décision, dépréciez-le.

Relier produits et formation

Une bibliothèque maintenue crée une échelle commerciale lisible. Les articles gratuits expliquent le raisonnement. ClaudeCodeLab products donne des templates aux personnes qui veulent avancer seules. Claude Code training and consultation aide les équipes à adapter owner, gates, hooks, métriques et rollout à leur dépôt réel.

Masa a d’abord essayé de garder plus de trente prompts. Le résultat était moins bon : trop de choix et peu de responsabilité. En réduisant à review, debug, product page et training page, avec trois prompts actifs par catégorie, l’équipe choisissait plus vite. Les cas d’échec conservés ont ensuite guidé les versions suivantes.