Vous avez développé un agent Claude.
Il fonctionne.
Les tools sont correctement appelés, les permissions sont en place et les evals montrent que le comportement attendu est obtenu.
La tentation naturelle consiste alors à considérer le développement comme terminé.
Mais une question permet de savoir si vous avez réellement créé un asset réutilisable :
Une autre équipe peut-elle utiliser votre solution en la configurant, ou doit-elle modifier votre code pour l’adapter à son projet ?
Si elle doit fouiller dans le code pour remplacer des chemins, des prompts, des seuils ou des paramètres propres au client, vous n’avez pas encore réellement créé un accelerator.
Vous avez simplement créé un build qui fonctionne.
Voyons comment passer de l’un à l’autre.
Qu’est-ce qu’un accelerator ?
Dans ce contexte, un accelerator est une solution fonctionnelle packagée afin qu’un futur engagement puisse partir d’une base existante plutôt que d’un repository vide.
L’objectif est simple :
Projet 1
↓
BUILD
↓
PACKAGE
↓
ACCELERATOR
↓
├── Projet 2 → configure
├── Projet 3 → configure
└── Projet 4 → configure
Sans accelerator :
Projet 1 → Build from scratch
Projet 2 → Build from scratch
Projet 3 → Build from scratch
Le coût principal n’est pas nécessairement celui de l’infrastructure.
C’est le temps d’ingénierie passé à reconstruire plusieurs fois la même solution.
Le principe fondamental : séparer le reusable du customer-specific
Prenons un agent de revue de code.
La première version pourrait ressembler à ceci :
def build_review_agent():
return Agent(
model=MODEL_ID,
system_prompt=SYSTEM_PROMPT,
tools=[read_file, run_linter],
repo_path="/home/acme/checkout-service",
)
Le chemin :
/home/acme/checkout-service
appartient au client ACME.
Pour le premier projet, ce hardcoding n’empêche absolument pas le programme de fonctionner.
Mais lorsqu’une seconde équipe récupère le code, elle doit découvrir elle-même :
- où se trouve cette valeur ;
- pourquoi elle existe ;
- si elle peut être modifiée ;
- quelles autres valeurs sont spécifiques au client ;
- quelles valeurs ne doivent surtout pas être modifiées.
Le problème n’est donc pas fonctionnel.
C’est un problème de packaging.
Parameterize what changes
La solution consiste à sortir du code les valeurs qui changent selon l’engagement.
Par exemple :
def build_review_agent(repo_path):
return Agent(
model=MODEL_ID,
system_prompt=SYSTEM_PROMPT,
tools=[read_file, run_linter],
repo_path=repo_path,
)
Le chemin n’est plus une décision cachée à l’intérieur de l’agent.
Il devient une configuration explicite.
La nouvelle équipe peut appeler :
agent = build_review_agent(
repo_path="/projects/customer-b/service"
)
sans modifier la logique interne de l’agent.
C’est la différence fondamentale entre :
COPY
↓
EDIT
↓
DIVERGE
et :
INSTALL
↓
CONFIGURE
↓
REUSE
Pourquoi parameterize pendant que le build est encore frais ?
Il est possible de revenir six mois plus tard et de transformer un projet en accelerator.
Mais cela devient beaucoup plus difficile.
Pendant le développement, l’équipe sait encore immédiatement :
Cette valeur appartient au client.
Ce seuil est spécifique à cet environnement.
Cette partie du prompt est générique.
Cette autre partie vient du domaine métier du client.
Quelques mois plus tard, le code ne permet pas nécessairement de reconstruire cette intention.
Le principe du module est donc :
Package while the build is fresh.
Autrement dit : transformez le build en asset réutilisable pendant que les raisons ayant conduit aux décisions techniques sont encore connues.
Trois grands types d’assets réutilisables
Tous les éléments réutilisables ne se packagent pas de la même façon.
Le module distingue trois catégories principales :
Agent TemplateMCP Server PackageEval Suite
Chacune encapsule un type de travail différent.
1. Agent Template
Un Agent Template peut notamment regrouper :
- le
system prompt; - les tool schemas ;
- la structure de la boucle ;
- la logique générale de l’agent.
L’objectif n’est pas de créer un agent totalement générique.
L’objectif est de conserver ce qui est réutilisable tout en externalisant ce qui varie.
Par exemple :
def build_review_agent(
repo_path,
review_threshold,
domain_prompt,
):
return Agent(
model=MODEL_ID,
system_prompt=build_system_prompt(domain_prompt),
tools=[read_file, run_linter],
repo_path=repo_path,
review_threshold=review_threshold,
)
Une équipe peut désormais fournir ses propres paramètres sans réécrire la boucle.
Que faut-il parameterize dans un Agent Template ?
Le document cite notamment :
- prompts ;
- paths ;
- scopes ;
- credentials by reference ;
- thresholds.
La question pratique à se poser est :
Cette valeur change-t-elle selon le client ou l’environnement ?
Si oui, elle est probablement candidate à la configuration.
Attention aux credentials
Les credentials méritent une attention particulière.
Le principe n’est évidemment pas de transformer un secret en paramètre stocké directement dans le code ou dans un template partagé.
Le module parle de :
credentials by reference
L’asset doit donc savoir où obtenir le credential approprié plutôt que d’embarquer le secret lui-même.
Conceptuellement :
MAUVAIS
accelerator
│
└── API_KEY="secret..."
Préférer :
accelerator
│
└── credential_reference
↓
secret mechanism
Le mécanisme concret dépendra de l’environnement dans lequel l’asset est installé.
2. MCP Server Package
Un MCP Server Package pose un problème légèrement différent.
Le serveur expose des tools permettant à Claude d’accéder à des systèmes externes.
Le package doit notamment documenter :
- les tools exposés ;
- leurs inputs ;
- leurs scopes ;
- les limites d’accès ;
- les failure modes gérés.
L’équipe qui installe le serveur doit pouvoir définir son propre périmètre.
Exemple : éviter un scope codé pour un client
Imaginons un MCP server permettant de consulter des repositories.
Une mauvaise approche serait de coder directement :
ALLOWED_REPOSITORY = "acme/checkout-service"
Une approche réutilisable consiste à fournir cette information via configuration :
class MCPServerConfig:
def __init__(self, allowed_repositories):
self.allowed_repositories = allowed_repositories
L’équipe A peut alors autoriser :
acme/checkout-service
et l’équipe B :
company-b/payment-api
sans modifier le serveur.
Le scope est une partie essentielle de la configuration
Pour un MCP server, rendre les scopes configurables ne signifie pas supprimer les contrôles.
C’est exactement l’inverse.
L’asset doit permettre à l’équipe qui l’installe de définir explicitement ce que le serveur est autorisé à atteindre.
Conceptuellement :
MCP SERVER
│
├── Tool A
├── Tool B
└── Tool C
│
↓
CONFIGURED SCOPE
│
↓
CUSTOMER SYSTEM
Le package peut être réutilisable tout en restant strictement limité à l’environnement dans lequel il est installé.
3. Eval Suite
Une Eval Suite constitue le troisième grand type d’asset.
Elle regroupe principalement :
- le dataset d’évaluation ;
- le
judge rubric; - les critères ou seuils associés.
L’erreur serait de partager uniquement le dataset.
Sans rubric, la nouvelle équipe possède les questions mais pas nécessairement la définition de ce qu’est une bonne réponse.
Inversement, partager uniquement le grader sans les cas d’évaluation ne permet pas de reproduire l’évaluation.
Le principe est donc :
Ship the dataset and rubric together.
Pourquoi une Eval Suite est-elle un accelerator ?
Parce qu’elle évite à chaque équipe de reconstruire la méthodologie permettant de déterminer si le système fonctionne.
Une équipe peut récupérer :
EVAL SUITE
│
├── dataset
│
├── rubric
│
├── thresholds
└── baseline
puis l’exécuter dans son propre contexte.
Elle peut ainsi répondre à :
L’asset continue-t-il à fonctionner correctement dans notre environnement ?
L’eval peut également devenir une deployment gate
La même suite peut ensuite être utilisée lorsqu’une nouvelle version doit être déployée.
Par exemple :
Production
Model V1
Score baseline = X
↓
Candidate
Model V2
↓
Eval Suite
↓
Compare with baseline
Si la nouvelle version respecte les critères définis, elle peut continuer dans le processus de promotion.
Sinon, elle est bloquée.
Ainsi, l’eval n’est plus uniquement un outil de développement.
Elle devient une composante du processus de déploiement.
Les trois assets comparés
| Asset | Ce qu’il contient | Ce qu’il faut rendre configurable |
|---|---|---|
Agent Template | System prompt, tool schemas, loop structure | Prompts, paths, scopes, thresholds, credentials by reference |
MCP Server Package | Tools et accès aux systèmes | Scopes, credentials by reference, paths propres au client |
Eval Suite | Dataset + judge rubric | Thresholds et dataset paths selon l’environnement |
La règle commune reste :
Le prochain projet configure l’asset au lieu de le réécrire.
Parameterization ne suffit pas
Une erreur importante serait de penser :
J’ai sorti les variables du code, mon accelerator est terminé.
Non.
Un accelerator correctement packagé doit également être documenté.
Le code explique son comportement.
Il n’explique pas nécessairement les hypothèses qui ont conduit à ce comportement.
Document the assumptions
La documentation doit notamment préciser :
Environment assumptions
Dans quel environnement l’asset est-il supposé fonctionner ?
Expected inputs
Quels inputs les composants attendent-ils ?
Failure modes
Quels cas d’erreur sont déjà gérés ?
Configuration
Quelles valeurs doivent être configurées ?
Eval
Quelle évaluation permet de décider que l’asset fonctionne correctement ?
Exemple
Supposons qu’un agent accepte un repository comme entrée.
La signature :
build_review_agent(repo_path)
ne dit pas nécessairement :
- si le repository doit déjà être cloné ;
- quelles permissions sont nécessaires ;
- quels langages sont supportés ;
- ce qui se passe si le linter n’est pas disponible ;
- comment déterminer si la revue est satisfaisante.
Ces éléments doivent être documentés.
Le code ne remplace pas la documentation
Un futur développeur ne devrait pas avoir à lire tout le code pour reconstruire :
ASSUMPTIONS
+
CONFIGURATION RULES
+
FAILURE MODES
+
SUCCESS CRITERIA
Sans documentation, le risque est que l’équipe suivante considère l’asset comme une boîte noire.
Et lorsque quelque chose échoue, elle peut finir par le reconstruire au lieu de le réutiliser.
Bundle the audit log
Un accelerator destiné à un environnement professionnel, notamment réglementé, doit également être préparé pour les questions de sécurité et d’audit.
Un reviewer peut demander :
Quelles données cet agent touche-t-il ?
Sous quelle identité agit-il ?
À quelles ressources accède-t-il ?
Quelles opérations réalise-t-il ?
Quelle trace laisse-t-il ?
Un accelerator incapable de répondre à ces questions peut parfaitement réussir une démonstration tout en échouant au security review.
Le module recommande donc de traiter l’audit log comme une partie du package.
Trois informations fondamentales pour l’audit
Pour chaque asset, il faut notamment pouvoir déterminer :
Data
Quelles données sont touchées ?
Identity
Sous quelle identité l’asset agit-il ?
Log
Quelle trace de son activité est conservée ?
On peut résumer :
ACCELERATOR
│
├── CODE
├── CONFIGURATION
├── DOCUMENTATION
├── EVAL
└── AUDIT
├── data touched
├── identity
└── activity log
Packaging checklist : Agent Template
Pour un Agent Template, vérifiez au minimum :
Parameterize
- prompts spécifiques ;
- paths ;
- scopes ;
- credentials by reference ;
- thresholds.
Document
- environment assumptions ;
- expected inputs ;
- handled failure modes ;
- eval définissant le fonctionnement attendu.
Audit
- data touched ;
- identity utilisée ;
- actions réalisées et logs correspondants.
Packaging checklist : MCP Server
Pour un MCP Server Package :
Parameterize
- scopes ;
- credentials by reference ;
- paths propres au client.
Document
- inputs attendus pour chaque tool ;
- scope boundaries ;
- failure modes.
Audit
- données consultées ou modifiées ;
- identité utilisée ;
- accès effectués.
Packaging checklist : Eval Suite
Pour une Eval Suite :
Parameterize
- thresholds ;
- dataset paths variant selon l’environnement.
Document
- rubric logic ;
- signification des scores ;
- baseline utilisée.
Audit
Lorsque cela s’applique au contexte de l’asset :
- données utilisées ;
- identité sous laquelle l’évaluation est exécutée ;
- traces nécessaires.
Étude de cas : le template qui fonctionnait mais n’était pas réutilisable
Le module présente un scénario particulièrement instructif.
Une équipe doit livrer rapidement un agent.
Pour tenir le délai, plusieurs valeurs sont hardcodées :
- repository path ;
- model name ;
- review thresholds ;
- fragments de prompts propres au client.
L’agent fonctionne.
La livraison est réussie.
Le code est ensuite placé dans un repository partagé avec l’étiquette :
reusable
Quelques mois plus tard, une autre équipe tente de l’utiliser.
Le problème apparaît au deuxième projet
La seconde équipe découvre qu’il n’existe aucune configuration.
Les valeurs propres au premier client sont dispersées dans le code.
Personne n’a documenté :
- lesquelles peuvent être modifiées ;
- lesquelles sont spécifiques au domaine ;
- lesquelles sont essentielles au fonctionnement.
Pire encore : aucune eval suite n’est fournie.
Après avoir modifié certaines valeurs, l’équipe ne dispose donc d’aucun moyen fiable de vérifier que l’agent fonctionne toujours correctement.
Résultat :
elle réécrit la solution.
L’accelerator n’a donc rempli aucune de ses fonctions.
Pourquoi cette situation est dangereuse
Le premier projet ne révèle pas le problème.
C’est précisément ce qui rend cette erreur fréquente.
Le build fonctionne parfaitement.
PROJECT 1
Hardcoded values
↓
Agent runs
↓
Tests pass
↓
Delivery successful
Tout semble correct.
Le coût apparaît plus tard :
PROJECT 2
Reuse attempt
↓
Cannot configure
↓
Unknown assumptions
↓
No eval
↓
Rewrite
La dette de packaging est donc différée.
Les trois signaux d’un faux accelerator
Lorsqu’un asset est présenté comme réutilisable, recherchez immédiatement trois éléments.
1. Parameters
Les valeurs propres au client sont-elles configurables ?
2. Documentation
Les hypothèses et failure modes sont-ils explicitement documentés ?
3. Eval
Existe-t-il une évaluation permettant de vérifier que l’asset fonctionne toujours après configuration ?
Si ces trois éléments manquent, le simple fait que le code fonctionne ne prouve pas qu’il s’agit d’un accelerator.
Exemple de correction
Considérons ce template :
def build_review_agent():
return Agent(
model=MODEL_ID,
system_prompt=SYSTEM_PROMPT,
tools=[read_file, run_linter],
repo_path="/home/acme/checkout-service",
)
Le défaut évident est :
repo_path="/home/acme/checkout-service"
Cette valeur appartient au client.
La correction minimale consiste à la transformer en paramètre :
def build_review_agent(repo_path):
return Agent(
model=MODEL_ID,
system_prompt=SYSTEM_PROMPT,
tools=[read_file, run_linter],
repo_path=repo_path,
)
Le changement de code est minuscule.
Mais le changement architectural est important :
AVANT
code → customer configuration
APRÈS
code
+
configuration
Ne pas tout parameterize aveuglément
Le but n’est pas de transformer chaque constante du programme en option.
L’objectif est de séparer :
REUSABLE CORE
de :
ENGAGEMENT-SPECIFIC CONFIGURATION
Une configuration excessive peut elle-même rendre l’asset difficile à utiliser.
La bonne question n’est donc pas :
Puis-je rendre cette valeur configurable ?
mais plutôt :
Cette valeur doit-elle raisonnablement changer lorsqu’une autre équipe ou un autre client utilise l’asset ?
Le coût initial du packaging
Créer correctement un accelerator demande du travail supplémentaire.
Il faut :
- identifier les éléments généralisables ;
- extraire la configuration ;
- documenter les hypothèses ;
- préparer l’eval ;
- prévoir l’auditabilité.
Cela augmente le coût du premier build.
Mais ce coût est payé une fois.
Le bénéfice apparaît lorsque les projets suivants démarrent à partir d’un asset configurable.
Quand ne pas créer d’accelerator ?
Le module précise également qu’il existe des situations où le packaging n’est pas justifié.
Si le projet est réellement :
- one-off ;
- non réutilisable ;
- sans perspective de réemploi ;
le coût du packaging peut être inutile.
Dans ce cas :
ship the build and move on.
C’est une idée importante.
L’objectif n’est pas de transformer systématiquement chaque script en framework réutilisable.
L’architecture doit rester proportionnée au besoin.
Accelerator et principe de simplicité
On retrouve ici un principe général d’ingénierie :
One-off
↓
simple build
Repeated pattern
↓
package for reuse
Shared infrastructure
↓
stronger documentation
+ tests
+ auditability
Plus le rayon de réutilisation augmente, plus les exigences de packaging augmentent également.
Ce qu’il faut retenir pour l’examen
Pour la certification, plusieurs scénarios peuvent être ramenés à quelques réflexes simples.
Scénario 1
Une équipe souhaite réutiliser un agent, mais le repository du client est hardcodé.
Réflexe :
Parameterize the customer-specific value.
Scénario 2
Un template possède plusieurs valeurs propres au domaine dispersées dans le code.
Réflexe :
Separate the reusable core from engagement-specific configuration.
Scénario 3
L’asset fonctionne, mais la nouvelle équipe ne sait pas dans quel environnement il est supposé fonctionner.
Réflexe :
Document the assumptions.
Scénario 4
Une équipe adapte un agent mais ne sait pas si ses modifications ont provoqué une régression.
Réflexe :
Bundle the eval with the accelerator.
Scénario 5
Un security reviewer demande quelles données l’agent manipule et sous quelle identité il agit.
Réflexe :
Auditability is part of the package.
Scénario 6
Le projet est explicitement un prototype jetable sans perspective de réutilisation.
Réflexe :
Ne pas ajouter inutilement le coût du packaging.
Piège d’examen : « ça fonctionne donc c’est réutilisable »
C’est probablement le piège conceptuel le plus important de cette partie.
Ces deux affirmations sont différentes :
"The agent works."
et :
"The agent is reusable."
Un agent peut parfaitement fonctionner tout en étant impossible à réutiliser correctement.
La réutilisabilité demande :
WORKING BUILD
+
PARAMETERIZATION
+
DOCUMENTATION
+
EVAL
+
AUDITABILITY
↓
REUSABLE ACCELERATOR
Principe → Exemple → Erreur fréquente → Bonne pratique
Principe
Séparer la logique réutilisable des valeurs propres à l’engagement.
Exemple
Transformer :
repo_path="/home/acme/checkout-service"
en :
repo_path=repo_path
avec :
def build_review_agent(repo_path):
Erreur fréquente
Considérer le template comme réutilisable uniquement parce qu’il fonctionne pour le premier client.
Bonne pratique
Parameterize pendant que le build est frais, documenter les hypothèses, fournir l’eval et préparer l’auditabilité.
Fiche rapide
| Concept | À retenir | Exemple | Piège d’examen |
|---|---|---|---|
| Accelerator | Asset configuré plutôt que reconstruit | Agent template | Confondre « works » et « reusable » |
| Parameterization | Extraire les valeurs customer-specific | repo_path | Laisser les valeurs dans la boucle |
| Agent Template | Prompt + tools + loop | Code-review agent | Copier des scripts séparés |
| MCP Server Package | Tools + configurable scopes | Accès repository | Hardcoder le scope |
| Eval Suite | Dataset + rubric | Regression testing | Fournir uniquement le dataset |
| Documentation | Expliquer les assumptions | Environment requirements | Penser que le code suffit |
| Audit log | Data + identity + activity | Accès MCP | Ajouter l’audit seulement après le security review |
| One-off | Packaging pas toujours nécessaire | Prototype jetable | Sur-engineering |
À retenir en une phrase
Un accelerator n’est pas simplement un build qui fonctionne : c’est un build dont le reusable core est séparé de la configuration client, dont les assumptions sont documentées, dont le fonctionnement peut être vérifié par une eval et dont les actions peuvent être auditées.
C’est cette transformation qui permet au prochain engagement de commencer par :
« configurons l’asset »
plutôt que par :
« reconstruisons la solution ».
