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 residency du 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. »