Faire fonctionner une application Claude n’est pas la fin du travail.
C’est même, dans de nombreux projets professionnels, le moment où commence une autre partie essentielle du travail d’ingénierie.
Un agent fonctionne.
Un MCP server communique correctement avec les systèmes externes.
Les evals montrent que le comportement attendu est obtenu.
Les permissions ont été configurées.
Les tests passent.
Le build fonctionne.
Mais plusieurs questions restent ouvertes :
- Une autre équipe peut-elle le réutiliser sans tout reconstruire ?
- Les paramètres propres au client sont-ils séparés de la logique générique ?
- Un maintainer externe peut-il comprendre et vérifier le code ?
- Le déploiement survivra-t-il à une mise à jour du modèle ?
- La plateforme choisie respecte-t-elle les contraintes de sécurité et de
data residencydu client ? - Les frontières de confiance restent-elles correctement contrôlées lorsque plusieurs composants sont connectés ?
C’est précisément le problème traité par Accelerators & IP Contribution.
L’idée centrale peut être résumée ainsi :
Un build qui fonctionne n’est pas encore nécessairement un build réutilisable, auditable et déployable.
Du build fonctionnel à l’asset réutilisable
Imaginons qu’une équipe développe un agent Claude de revue de code.
Il possède :
- un
system prompt; - plusieurs tools ;
- une boucle agentique ;
- un repository cible ;
- des seuils de validation ;
- un modèle Claude ;
- une suite d’
evals.
Pour le premier client, certaines valeurs sont directement intégrées au code.
Par exemple :
def build_review_agent():
return Agent(
model="...",
system_prompt=SYSTEM_PROMPT,
tools=[read_file, run_linter],
repo_path="/home/acme/checkout-service"
)
Le programme fonctionne parfaitement.
Mais le chemin :
/home/acme/checkout-service
appartient au contexte du client ACME.
Une seconde équipe souhaitant réutiliser cet agent devra modifier directement le code.
Le build est donc fonctionnel, mais il n’est pas correctement packagé pour la réutilisation.
1. Transformer le build en accelerator
Un accelerator est une solution fonctionnelle préparée de manière à ce qu’un futur projet puisse la configurer plutôt que la reconstruire.
Le principe consiste à distinguer :
BUILD EXISTANT
↓
┌──────────────────────────┐
│ logique réutilisable │
│ │
│ paramètres spécifiques │
│ au client │
└──────────────────────────┘
↓
SÉPARATION
↓
┌──────────────────────────┐
│ CORE RÉUTILISABLE │
└──────────────────────────┘
+
┌──────────────────────────┐
│ CONFIGURATION CLIENT │
└──────────────────────────┘
Les valeurs spécifiques au client deviennent des paramètres documentés.
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
)
La nouvelle équipe configure désormais l’asset au lieu de modifier sa logique interne.
Les trois grandes formes d’accelerators
Le module distingue principalement trois catégories.
Agent Template
Un Agent Template peut regrouper :
- le
system prompt; - les tool schemas ;
- la structure de la boucle agentique.
Les éléments propres au domaine ou au client doivent être externalisés sous forme de configuration.
MCP Server Package
Un package de MCP server contient notamment :
- les tools exposés ;
- leurs paramètres ;
- les limites de leur périmètre d’action.
L’équipe qui installe le serveur doit pouvoir définir son propre scope sans modifier son code.
Eval Suite
Une eval suite réutilisable contient :
- le dataset d’évaluation ;
- les critères de notation ;
- le
judge rubric; - les seuils appropriés.
Dataset et rubric doivent voyager ensemble.
L’équipe suivante peut ainsi vérifier que l’asset continue de fonctionner dans son propre contexte.
Les mêmes evals peuvent également devenir une deployment gate lorsqu’une nouvelle version du modèle ou du prompt doit être mise en production.
2. Documenter les hypothèses, pas uniquement le code
Le code explique ce que fait le programme.
Il n’explique pas forcément tout ce qu’un futur développeur doit savoir pour l’utiliser correctement.
La documentation d’un accelerator doit notamment préciser :
- les hypothèses sur l’environnement ;
- les inputs attendus ;
- les failure modes déjà gérés ;
- les paramètres configurables ;
- les limites de l’asset ;
- l’eval qui définit ce que signifie « fonctionner correctement ».
Sans ces informations, une nouvelle équipe risque de considérer l’asset comme une boîte noire.
Et lorsqu’une équipe ne comprend pas suffisamment un asset, elle finit souvent par le reconstruire.
3. L’auditabilité fait partie du package
Pour un environnement réglementé, la réutilisabilité ne suffit pas.
Un reviewer peut demander :
- Quelles données cet asset manipule-t-il ?
- Sous quelle identité agit-il ?
- À quelles ressources accède-t-il ?
- Quelles opérations réalise-t-il ?
- Quelles traces laisse-t-il ?
L’audit log ne doit donc pas être considéré comme un élément ajouté après coup.
Il fait partie du package.
Un accelerator destiné à un contexte sensible doit permettre de comprendre au minimum :
DATA
Quelles données sont touchées ?
IDENTITY
Sous quelle identité agit le composant ?
ACCESS
À quelles ressources peut-il accéder ?
ACTION
Quelles actions réalise-t-il ?
LOG
Quelle trace de ces actions est conservée ?
4. Passer de l’asset interne à une contribution partageable
Un accelerator correctement packagé possède déjà une grande partie de ce dont un maintainer a besoin.
Il est :
- paramétrable ;
- documenté ;
- testable ;
- accompagné de ses
evals.
Mais contribuer du code à une infrastructure partagée demande une étape supplémentaire.
Un maintainer doit pouvoir vérifier la contribution sans reconstruire mentalement tout le projet.
Quatre éléments sont particulièrement importants.
1. Un code focalisé
La contribution doit résoudre un problème clairement identifié.
Un énorme projet contenant plusieurs patterns est beaucoup plus difficile à examiner qu’un exemple ciblé.
2. Un exemple exécutable
Le reviewer doit pouvoir voir le comportement sans construire lui-même tout un environnement de démonstration.
3. Un test
Le test permet de vérifier objectivement que le comportement annoncé fonctionne.
4. Les hypothèses
Les contraintes et hypothèses d’environnement doivent être explicites.
5. Choisir le bon canal de contribution
Toutes les contributions ne vont pas au même endroit.
Un exemple focalisé montrant clairement un pattern peut correspondre à un repository de type Claude Cookbook.
Un tool ou un MCP server existant possède généralement son propre repository et ses propres conventions de contribution.
Un projet complet avec :
- interface utilisateur ;
- backend ;
- scripts de déploiement ;
- nombreux composants ;
n’est pas nécessairement adapté à un repository destiné à présenter un pattern focalisé.
Le principe est :
Adapter la forme de la contribution au canal qui doit la recevoir.
6. Vérifier les droits avant la qualité technique
Une contribution techniquement excellente peut être impossible à accepter si l’auteur n’a pas le droit de partager le code.
C’est particulièrement important lorsqu’un asset provient d’un engagement client.
Avant la revue technique, il faut donc vérifier :
- les droits de contribution ;
- les licences ;
- les éventuelles restrictions contractuelles ;
- l’attribution des travaux antérieurs.
Autrement dit :
Rights / licensing
↓
Technical review
↓
Merge éventuel
La question juridique précède la question de qualité du code.
7. Transformer le besoin métier en requirements
Avant de choisir où déployer Claude, il faut savoir ce que le système doit réellement accomplir.
Le module distingue notamment deux catégories.
Functional requirements
Ils décrivent ce que le système doit faire.
Par exemple :
Le système produit un résumé de l’appel client qui doit être approuvé par un humain avant d’être stocké.
Cette exigence peut être testée.
À l’inverse :
Le système doit être rapide et précis.
est trop vague pour constituer une spécification suffisamment exploitable.
Infrastructure requirements
Ils décrivent les contraintes non fonctionnelles du système.
Parmi les dimensions importantes :
latency;scale;data residency;identity;- auditabilité ;
- contraintes réglementaires.
Exemple :
Les transcripts doivent être traités dans l’Union européenne.
Cette exigence peut directement influencer la plateforme de déploiement.
8. Le systems lifecycle d’une application Claude
Une application Claude suit un véritable cycle d’ingénierie.
Le module le structure ainsi :
1. Requirements
↓
2. Design
↓
3. Build
↓
4. Test
↓
5. Deploy
↓
6. Operate
↓
7. Iterate
└──────────→ Requirements
Requirements
Définir les besoins fonctionnels et les contraintes d’infrastructure.
Design
Choisir :
- la plateforme ;
- le modèle ;
- l’architecture ;
- les
trust boundaries.
Build
Développer :
- agents ;
- prompts ;
- tools ;
- intégrations.
Test
Utiliser :
- unit tests ;
- integration tests ;
- end-to-end tests ;
evals.
Deploy
Contrôler précisément ce qui est mis en production et appliquer les gates de déploiement.
Operate
Observer notamment :
- coûts ;
- latence ;
- erreurs ;
- comportement ;
- sécurité.
Iterate
Les observations de production alimentent les nouvelles requirements.
9. Les gates entre les phases
Un système réglementé ne doit pas simplement avancer automatiquement d’une phase à la suivante.
Il existe des gates.
Par exemple :
DESIGN
↓
La plateforme respecte-t-elle
les contraintes de residency ?
↓ YES
BUILD
Ou :
NEW MODEL VERSION
↓
EVAL
↓
Score ≥ baseline ?
↙ ↘
YES NO
↓ ↓
DEPLOY BLOCK / FIX
Les evals deviennent ainsi une composante du processus de release.
10. Choisir où exécuter Claude
Une application Claude peut être déployée dans différents environnements.
Le support de cours étudie notamment :
- first-party Claude API ;
- Claude Platform on AWS ;
- Claude in Amazon Bedrock ;
- Claude on Amazon Bedrock (legacy) ;
- Google Vertex AI ;
- plateformes tierces.
Le choix n’est pas uniquement une question de préférence technique.
Dans une entreprise, il dépend souvent fortement de l’environnement que le client utilise déjà pour :
- son infrastructure cloud ;
- son IAM ;
- sa facturation ;
- sa conformité ;
- ses audits ;
- sa gouvernance des données.
11. Ne pas choisir une plateforme uniquement parce qu’on la connaît
Une équipe maîtrise parfaitement une plateforme.
Elle décide donc naturellement de l’utiliser.
Le développement se passe bien.
Puis le security review demande :
Où sont traitées les données ?
Et la plateforme choisie ne respecte pas l’exigence de data residency.
Le projet doit être redéployé ailleurs.
Le problème n’était pas la qualité de l’intégration.
Le mauvais critère avait simplement été utilisé pour prendre la décision.
MAUVAIS RAISONNEMENT
"Nous connaissons cette plateforme."
↓
Nous la choisissons.
MEILLEUR RAISONNEMENT
Requirements
↓
Compliance / residency
↓
Identity
↓
Latency
↓
Cost
↓
Plateforme adaptée
Pour certains clients réglementés, la conformité est une contrainte pass-or-fail.
Elle ne peut pas être compensée par une meilleure latence ou un prix inférieur.
12. Pin what ships
Une autre notion essentielle concerne le model versioning.
Utiliser un alias mouvant en production peut provoquer un changement de comportement sans modification du code de l’application.
Conceptuellement :
model = "opus"
peut représenter une référence susceptible d’évoluer.
Si cette référence change, l’application peut se retrouver avec un modèle différent alors que son propre code n’a pas changé.
Le principe de production est donc :
Pin what ships.
La version réellement déployée doit être explicitement contrôlée.
Il faut également versionner :
- le modèle ;
- le prompt ;
- l’asset ;
- le code.
13. Conserver la version précédente
Pinning seul ne suffit pas.
La version précédente doit rester disponible.
Le workflow devient :
VERSION N
baseline connue
↓
VERSION N+1
↓
EVAL SUITE
↓
Comparaison baseline
↙ ↘
OK REGRESSION
↓ ↓
PROMOTE ROLLBACK
Sans version précédente, une régression peut imposer un hotfix en urgence.
Avec une version précédente correctement conservée, elle peut devenir un rollback contrôlé.
14. Les evals deviennent une deployment gate
C’est une évolution importante dans la manière de penser les evals.
Au début d’un projet, elles permettent de répondre à :
Mon système fonctionne-t-il ?
En production, elles permettent également de répondre à :
Puis-je promouvoir cette nouvelle version ?
Une nouvelle version du :
- modèle ;
- prompt ;
- agent ;
- tool ;
- pipeline ;
doit être comparée à une baseline connue avant promotion.
L’eval devient donc une release gate.
15. Comparer les plateformes sur trois dimensions
Une décision de plateforme doit pouvoir être défendue devant les équipes :
- engineering ;
- security ;
- compliance ;
- procurement.
Le module insiste notamment sur trois dimensions.
Latency
Elle doit être mesurée depuis la région réelle du client et avec un workload représentatif.
Une mesure réalisée depuis le laptop du développeur n’est pas nécessairement représentative de la production.
Compliance
Il faut examiner :
data residency;- certifications ;
- audit controls ;
- exigences réglementaires.
Pour un environnement réglementé, ce critère peut être éliminatoire.
Cost
Le coût ne se limite pas au prix du token.
Il faut raisonner en total cost :
Total cost
=
token usage
+ egress
+ platform fees
+ integration cost
+ operational overhead
La plateforme affichant le prix par token le plus faible n’est donc pas nécessairement celle qui coûte le moins cher au système.
16. Les applications multi-composants créent des trust boundaries
Considérons maintenant :
Claude API
↓
Claude Code task
↓
MCP server
↓
Customer system
Chaque composant peut être sécurisé individuellement.
Mais cela ne signifie pas que les connexions entre les composants le sont automatiquement.
Chaque seam où transitent :
- données ;
- instructions ;
- credentials ;
- identités ;
constitue potentiellement une trust boundary.
17. Le contenu récupéré reste non fiable
Supposons qu’une tâche Claude Code récupère une page externe :
fetched = code_task.run(
fetch_url=customer_page
)
Puis que son contenu soit directement envoyé au composant suivant :
next_call(input=fetched)
Le fait que fetched provienne d’un composant interne ne rend pas son contenu fiable.
La source initiale reste externe.
Elle peut notamment contenir une indirect prompt injection.
Le composant suivant doit donc considérer ce contenu comme data, et non comme de nouvelles instructions autorisées.
Principe :
EXTERNAL CONTENT
↓
Component A
↓
TRUST BOUNDARY
↓
treat as DATA
not trusted instructions
↓
Component B
18. Least privilege à l’échelle du système
Le least privilege ne doit pas être appliqué uniquement tool par tool.
Il doit être appliqué à l’architecture entière.
Chaque composant reçoit seulement les permissions dont il a besoin.
Par exemple, un MCP server chargé de consulter certaines données client ne devrait pas disposer d’un accès général à tout le système simplement parce que cela facilite le développement.
L’application est aussi sûre que son seam le plus privilégié.
Un seul composant trop puissant peut devenir le point faible du système.
19. Le fil conducteur : le build n’est pas terminé quand il fonctionne
Toutes les notions de ce module convergent vers la même idée.
Pendant le développement
On demande :
Est-ce que ça fonctionne ?
Pour un accelerator
On demande :
Une autre équipe peut-elle le configurer sans le reconstruire ?
Pour une contribution
On demande :
Un maintainer peut-il le vérifier sans reconstruire mon raisonnement ?
Pour le deployment
On demande :
Peut-on savoir exactement quelle version fonctionne en production ?
Pour la compliance
On demande :
Peut-on démontrer pourquoi cette plateforme satisfait les requirements ?
Pour une architecture multi-composants
On demande :
Chaque trust boundary possède-t-elle un contrôle explicite ?
C’est ce passage du code fonctionnel au système maîtrisé qui constitue le cœur du module.
Les 5 idées essentielles à retenir
1. Package while the build is fresh
Transformez immédiatement les valeurs spécifiques au client en paramètres et documentez les hypothèses pendant que l’architecture est encore fraîche dans l’esprit de l’équipe.
2. A maintainer accepts what they can verify
Une contribution doit être focalisée, exécutable, testable et documentée.
Les droits de contribution doivent également être vérifiés.
3. Pin what ships
Une version de production doit être contrôlée explicitement.
Conservez également la version précédente pour permettre un rollback.
4. Measure the dimension that decides the placement
Comparez les plateformes sur :
- latency ;
- compliance ;
- cost.
Mais lorsqu’une contrainte réglementaire est obligatoire, elle peut déterminer la plateforme avant les autres critères.
5. Mark every seam as a boundary
Chaque passage de données entre composants doit être considéré comme une trust boundary.
Appliquez :
- validation ;
least privilege;- audit logging ;
- séparation entre data et instructions ;
- contrôles adaptés aux données non fiables.
À retenir pour la certification Claude Certified Developer – Foundations
Face à un scénario d’examen, recherchez les indices suivants :
| Situation | Réflexe |
|---|---|
| Valeur propre au client hardcodée | Parameterize |
| Asset réutilisable | Configuration + documentation + eval |
| Contribution impossible à vérifier | Example + test + assumptions |
| Code issu d’un engagement client | Vérifier rights/licensing |
| Besoin métier vague | Transformer en requirement vérifiable |
| Contrainte EU residency | Traiter comme infrastructure requirement |
| Choix de plateforme | Partir des requirements et de la compliance |
| Production avec référence mouvante | Pin la version |
| Nouvelle version | Eval avant promotion |
| Régression | Rollback vers version précédente |
| Comparaison de plateformes | Latency + compliance + total cost |
| Données récupérées par un composant | Untrusted data |
| Passage entre composants | Trust boundary |
| MCP avec accès très large | Réduire selon least privilege |
| Boundary impossible à sécuriser | Escalate to human owner |
Conclusion
Construire un agent Claude fonctionnel est une compétence d’ingénierie.
Construire un agent que d’autres équipes peuvent réutiliser, qu’un maintainer peut vérifier, qu’un client réglementé peut auditer et qu’une équipe peut faire évoluer sans casser silencieusement la production relève d’un niveau supplémentaire de maturité.
Le chemin complet devient :
BUILD
↓
PACKAGE
↓
DOCUMENT
↓
EVAL
↓
CONTRIBUTE / REUSE
↓
REQUIREMENTS
↓
CHOOSE PLATFORM
↓
PIN VERSION
↓
DEPLOY
↓
OBSERVE
↓
ITERATE
Et lorsqu’il existe plusieurs composants :
MAP THE SEAMS
↓
TRUST BOUNDARIES
↓
LEAST PRIVILEGE
↓
VALIDATION
↓
AUDIT LOGGING
L’objectif n’est donc plus simplement de pouvoir dire :
« Le code fonctionne. »
Mais :
« Le système est réutilisable, vérifiable, versionné, déployable, auditable et ses frontières de confiance sont explicitement contrôlées. »