Cette fiche résume les notions essentielles du module Accelerators & IP Contribution.

Le fil conducteur est simple :

Un build Claude n’est pas terminé lorsqu’il fonctionne. Il doit encore être reusable, reviewable, testable, deployable, auditable et sécurisé.

1. Accelerator

Concept

Un accelerator est un asset réutilisable qui permet à une autre équipe de configurer une solution plutôt que de la reconstruire.

Les trois grandes formes du module sont :

Agent Template
MCP Server Package
Eval Suite

À retenir

Un accelerator doit séparer :

REUSABLE LOGIC
      +
CUSTOMER-SPECIFIC CONFIGURATION

Le but est :

configure, not rewrite

Exemple

Mauvais :

repo_path="/home/acme/checkout"

Meilleur :

def build_agent(repo_path):
    ...

Piège d’examen

Un asset qui fonctionne pour un client n’est pas automatiquement reusable.

2. Que faut-il parameterize ?

Chercher notamment :

prompts
paths
scopes
credentials by reference
thresholds
dataset paths
environment-specific values

Credentials by reference

Ne pas embarquer les secrets dans l’accelerator.

Mauvais :

API_KEY = "..."

Meilleur principe :

accelerator
   ↓
references credential
   ↓
deployment environment supplies it

3. Documentation minimale d’un accelerator

Le package doit documenter au minimum :

environment assumptions
expected inputs
handled failure modes
eval definition

L’équipe suivante doit pouvoir comprendre :

dans quel environnement l’asset fonctionne ;
quelles entrées il attend ;
quels échecs sont prévus ;
comment déterminer s’il fonctionne correctement.

4. Auditability

Un asset production-ready doit permettre de retracer :

what data was touched
which identity acted
what was logged

Dans un système réglementé, ce point devient particulièrement important.

5. Agent Template

Un Agent Template peut inclure :

system prompt
tool schemas
agent loop structure
defaults
configuration parameters

Les valeurs spécifiques au client doivent être configurables.

6. MCP Server Package

Un package MCP doit documenter :

tools
inputs
scope
required permissions
configuration

Le scope doit pouvoir être défini par l’équipe qui installe le server.

Exemple :

allowed_repositories:
- repo-a
- repo-b

plutôt que :

all repositories

7. Eval Suite

Une Eval Suite reusable contient notamment :

dataset
judge rubric
baseline
thresholds

Les paths et thresholds peuvent être configurables.

La baseline permet de savoir si une nouvelle version représente une amélioration ou une régression.

8. Quand ne pas créer d’accelerator ?

Si le travail est réellement :

one-off
non-reusable
customer-specific

le coût du packaging peut dépasser sa valeur.

Principe :

Ne pas ajouter de complexité de réutilisation lorsqu’aucune réutilisation n’est prévue.

9. Contribution readiness

Partager du code ne signifie pas simplement ouvrir une pull request.

Un maintainer doit pouvoir vérifier ce qui est proposé.

Principe :

A maintainer accepts what they can verify.

Ce qu’un maintainer veut

Généralement :

focused code
runnable example
test
documented assumptions

Exemple vs test

Un runnable example montre :

comment utiliser le code.

Un test montre :

que le comportement attendu est effectivement vérifié.

Les deux sont utiles, mais ils n’ont pas le même rôle.

10. Choisir le bon contribution channel

Le canal doit correspondre à l’asset.

Focused reference implementation

Peut correspondre à un repository de type Cookbook lorsque le projet accepte ce type de contribution.

Tool ou MCP server

Préférer :

le repository du tool ou du MCP server concerné, avec ses conventions propres.

Full customer application

Mauvais candidat à une contribution de type Cookbook.

Il faut généralement :

customer application
       ↓
extract reusable pattern
       ↓
reduce scope
       ↓
focused contribution

One-line fix

Si la correction concerne directement un exemple existant :

contribuer dans le repository correspondant, après vérification des droits.

11. Licensing, attribution et rights

Avant la review technique, vérifier :

license
attribution
ownership
right to contribute

Particulièrement lorsqu’un asset provient d’un customer engagement.

Piège d’examen

Le code peut être techniquement excellent et néanmoins ne pas être publiable.

12. Business problem ≠ requirement

Exemple :

« Nous voulons aider le support à répondre plus vite. »

C’est un objectif métier.

Pas encore un requirement testable.

13. Functional requirement

Question :

What must the system do?

Exemples :

Generate a summary.
Require human approval before storage.
Classify the ticket.

14. Infrastructure requirement

Question :

Under what constraints must the system run?

Le module met particulièrement en avant :

latency
scale
residency
identity

Exemple certification

Banque européenne réglementée.

Functional requirement :

Human approves the summary
before it is stored.

Infrastructure requirement :

Transcript data is processed in the EU.

Piège : solution ≠ requirement

"Use Bedrock"

est typiquement une décision de design.

Alors que :

"Data must be processed in the EU"

est un requirement.

15. Requirements avant architecture

Le bon ordre :

BUSINESS PROBLEM
      ↓
FUNCTIONAL REQUIREMENTS
      ↓
INFRASTRUCTURE REQUIREMENTS
      ↓
DESIGN

Pas :

Favorite platform
      ↓
Force requirements to fit

16. Systems lifecycle

À mémoriser :

Requirements
    ↓
Design
    ↓
Build
    ↓
Test
    ↓
Deploy
    ↓
Operate
    ↓
Iterate

17. Que se passe-t-il dans chaque phase ?

Phase	Activités
Requirements	functional + infrastructure requirements
Design	plateforme, modèle, architecture, trust boundaries
Build	prompts, agents, tools, MCP integrations
Test	unit, integration, end-to-end, evals
Deploy	pinning, promotion gate, rollback
Operate	cost, latency, errors, guardrails
Iterate	production findings → nouveaux changements

18. Gates

Une gate bloque une transition si une condition obligatoire n’est pas satisfaite.

Exemple Design → Build

EU residency required
      ↓
Does design satisfy it?
      ↓
NO
      ↓
STOP

Exemple Test → Deploy

candidate
   ↓
eval
   ↓
pass?
 ↙   ↘
yes   no
 ↓     ↓
ship  block

19. Activités à savoir classer

Pin full model ID

Deploy

Keep prior version

Deploy

Gate promotion on eval

Deploy

Run eval

Test

Decide data must remain in a specific region

Requirements

Choose platform based on requirements

Design

Measure production latency and token cost

Operate

20. Deployment platform

Le module compare plusieurs voies pour utiliser Claude.

Le principe à mémoriser est plus important que les noms précis :

Le choix de plateforme dépend des infrastructure requirements.

Dimensions importantes

identity
billing
residency
compliance
latency
feature availability
cost

21. Compliance peut être PASS/FAIL

Exemple :

Platform	Cost	Latency	Compliance
A	excellent	excellent	FAIL
B	moyen	bon	PASS

Si compliance est obligatoire :

A est éliminée.

Modèle mental

HARD CONSTRAINTS
      ↓
FILTER
      ↓
OPTIMIZE REMAINING OPTIONS

22. Latency

Ne pas choisir sur un benchmark générique.

Mesurer avec :

customer region
+
representative payload
+
target model

23. Cost

Ne pas considérer uniquement :

token price

Le module demande de penser au coût global :

tokens
+
egress
+
platform fees
+
integration effort

Objectif :

total cost per call

24. Data residency

Ne pas supposer :

application region
=
inference residency

Il faut comprendre le routage réel de la plateforme.

25. Pin what ships

Principe majeur :

Pin what ships.

Une production doit permettre d’identifier précisément la version utilisée.

26. Pourquoi le pinning ?

Pour :

reproducibility
debugging
eval comparison
audit
rollback

27. Ne pas versionner uniquement le modèle

Le comportement dépend de :

model
+
prompt
+
tool schemas
+
agent logic
+
configuration
+
code

Il faut donc penser en termes de release.

Exemple

Release 5.3
│
├── model ID
├── prompt v18
├── tool schemas v7
├── agent code
├── configuration
└── eval suite v4

28. Upgrade d’un modèle

Mauvais réflexe :

new model
→ production

Bon réflexe :

new model
→ candidate
→ eval
→ compare baseline
→ gate
→ deploy

29. Garder la prior version

Même si les evals passent :

retain previous release

afin de permettre :

rollback

30. Evals + monitoring + rollback

À mémoriser :

BEFORE DEPLOY
→ EVAL

AFTER DEPLOY
→ MONITOR

IF REGRESSION
→ ROLLBACK

31. Trust boundary

Une trust boundary apparaît lorsqu’une donnée, une instruction, une identité ou une action traverse d’un composant à un autre.

Exemple :

API
 ↓
Claude
 ↓
MCP server
 ↓
Customer system

Chaque seam doit être examiné.

32. Mark every seam as a boundary

Principe du module :

Mark every seam as a boundary.

Pour chaque seam :

What crosses?
Where does it go?
Under which identity?
Is it trusted?
What can the receiver do?

33. Fetched content remains untrusted

Si l’application récupère :

une page web ;
un document ;
un email ;
une issue ;
un tool result ;

le contenu reste potentiellement non fiable.

Mauvais modèle

untrusted source
      ↓
trusted fetcher
      ↓
trusted data

Faux.

Bon modèle

untrusted source
      ↓
trusted fetcher
      ↓
still untrusted data

34. Indirect prompt injection

Exemple :

External document
contains malicious instruction
      ↓
application retrieves it
      ↓
Claude reads it
      ↓
instruction influences tool use

C’est une indirect prompt injection.

35. Data ≠ instructions

Le contenu externe doit rester traité comme :

DATA

et non comme :

CONTROL INSTRUCTIONS

36. Prompt-only security est insuffisante

Dire :

« Ignore malicious instructions »

n’est pas suffisant.

Il faut des contrôles applicatifs.

37. Claude demande, l’application autorise

Modèle mental essentiel pour tool use :

Claude
   ↓
tool_use
   ↓
APPLICATION
validate
authorize
decide
   ↓
tool executes

Claude propose l’action.

L’application décide si elle est autorisée.

38. Validation ≠ authorization

VALIDATION
→ Is the argument well formed?

AUTHORIZATION
→ Is this action allowed?

Les deux sont nécessaires.

Exemple

{
  "account_id": "999"
}

peut être syntaxiquement valide.

Mais l’utilisateur peut ne pas avoir accès au compte 999.

39. Least privilege

Chaque composant reçoit uniquement les permissions nécessaires.

Mauvais :

MCP server
→ organization admin

alors qu’il a seulement besoin de :

read repo A

40. Le seam le plus privilégié est critique

Une application peut être bien sécurisée presque partout mais contenir :

one highly privileged MCP server

Ce composant peut devenir le point d’impact maximal.

41. Human approval

Pour une action sensible ou irréversible :

Claude proposes
      ↓
application validates
      ↓
human approves
      ↓
execute

La validation humaine doit se produire avant l’action.

42. Audit

Pouvoir reconstruire notamment :

data touched
identity used
tool requested
arguments
authorization decision
tool result
human approval

Mais ne pas logger inutilement :

secrets
credentials
sensitive data

43. Cas cumulatif du module

Le code problématique contient :

def build_agent():
    return Agent(
        model="opus",
        repo_path="/home/acme/checkout",
    )

fetched = code_task.run(
    fetch_url=customer_page
)

next_call(input=fetched)

Trois défauts doivent être détectés immédiatement.

Défaut A

repo_path="/home/acme/checkout"

Problème :

customer-specific configuration hardcodée.

Correction :

parameterize.

Défaut B

model="opus"

Dans le scénario du module :

moving alias.

Correction :

pin full model version
+
eval
+
retain prior version

Défaut C

next_call(input=fetched)

Problème :

untrusted fetched data traverse directement une trust boundary.

Correction :

treat as untrusted data
+
boundary controls
+
least privilege downstream

44. Les cinq takeaways du module

1. Package while the build is fresh

C’est juste après le build que l’équipe sait le mieux :

what is reusable
vs
what is customer-specific

2. A maintainer accepts what they can verify

Une contribution doit être :

focused
runnable
tested
documented

3. Pin what ships

Aucun changement upstream ne devrait devenir silencieusement une modification de production.

4. Measure the dimension that decides placement

Comparer les plateformes selon le requirement qui décide réellement :

compliance
residency
latency
cost

5. Mark every seam as a boundary

Toute transition entre composants mérite une analyse de confiance et de privilèges.

45. Tableau de révision express

Concept	À retenir	Exemple	Piège d’examen
Accelerator	Configure, not rewrite	Agent Template	Copier puis modifier
Parameterization	Sortir les valeurs customer-specific	`repo_path`	Hardcode
MCP package	Tools + inputs + scope	Read-only repo	Scope global
Eval Suite	Dataset + rubric + baseline	Deployment gate	Eval sans threshold
Contribution readiness	Maintainer doit vérifier	Test + runnable example	Envoyer full app
Rights	Vérifier avant contribution	Customer code	Ignorer ownership
Functional requirement	Comportement	Human approval	Formulation vague
Infrastructure requirement	Contrainte	EU processing	Confondre avec plateforme
Lifecycle	Req → Design → Build → Test → Deploy → Operate → Iterate	—	Sauter phases
Gate	Bloque une transition	Eval before promote	Tester après prod
Platform choice	Suit requirements	compliance first	Choix par familiarité
Latency	Mesurer workload réel	customer region	Benchmark générique
Cost	Total cost	fees + egress	Seulement token price
Pinning	Identifier ce qui ship	pinned model	Moving alias
Rollback	Garder prior release	N+1 → N	Supprimer N
Trust boundary	Chaque seam	Claude → MCP	Ne regarder que Claude
Untrusted data	Reste non fiable	fetched page	Faire confiance après fetch
Tool authorization	Application décide	allowlist	Claude autorise
Least privilege	Minimum nécessaire	read-only	Admin credentials
Human approval	Avant action sensible	Delete approval	Validation après action

46. Questions réflexes pour l’examen

Face à un scénario, demandez-vous dans cet ordre :

1. What is the actual requirement?

2. Is it functional or infrastructure?

3. Is someone choosing a solution too early?

4. Which lifecycle phase are we in?

5. Is there a gate before the next phase?

6. Is anything customer-specific hardcoded?

7. Is the deployed release explicitly versioned?

8. Has the candidate passed the relevant eval?

9. Can the system rollback?

10. Where are the trust boundaries?

11. Is any external content being treated as trusted?

12. Who actually authorizes tool execution?

13. Does every component follow least privilege?

14. Is human approval needed before the action?

15. Can the system be audited afterwards?

47. Raisonnement type certification

Lorsque plusieurs réponses paraissent possibles, privilégiez généralement celle qui est :

safer
+
simpler
+
testable
+
explicit
+
least privileged
+
aligned with requirements

48. Formules à mémoriser

Accelerator

REUSABLE
=
PARAMETERIZED
+
DOCUMENTED
+
TESTED

Deployment

PIN
→ EVAL
→ GATE
→ DEPLOY
→ MONITOR
→ ROLLBACK

Platform choice

REQUIREMENTS
→ HARD CONSTRAINTS
→ FILTER
→ MEASURE
→ CHOOSE

Tool security

CLAUDE REQUESTS
APPLICATION AUTHORIZES
TOOL EXECUTES

Trust boundaries

EXTERNAL CONTENT
=
UNTRUSTED DATA

Permissions

MINIMUM SUFFICIENT PRIVILEGE

49. Les pièges les plus probables

À éviter :

considérer « ça fonctionne » comme critère suffisant ;
hardcoder une valeur spécifique au client ;
contribuer une application client complète comme exemple générique ;
ignorer licensing et ownership ;
confondre requirement et design choice ;
choisir une plateforme avant de connaître les constraints ;
optimiser cost avant compliance ;
utiliser un benchmark de latency non représentatif ;
changer de modèle sans eval ;
ne pas conserver de prior version ;
croire qu’un tool_result est forcément trusted ;
croire que MCP fournit automatiquement la sécurité ;
confondre JSON Schema validation et authorization ;
donner des credentials trop larges ;
utiliser uniquement un prompt comme mécanisme de sécurité ;
effectuer l’action avant human approval.

50. Résumé final

Le module peut être résumé par cette chaîne :

WORKING BUILD
      ↓
PACKAGE
      ↓
PARAMETERIZE
      ↓
DOCUMENT
      ↓
TEST
      ↓
CONTRIBUTE IF APPROPRIATE
      ↓
DEFINE REQUIREMENTS
      ↓
DESIGN PLATFORM
      ↓
PIN RELEASE
      ↓
EVAL
      ↓
DEPLOY
      ↓
PROTECT TRUST BOUNDARIES
      ↓
OPERATE
      ↓
ITERATE

Le message central est qu’une application Claude production-ready est un système, pas seulement un prompt ou un appel de modèle.

À retenir en une phrase

Un build Claude devient un accelerator production-ready lorsqu’il est parameterized, documented, testable et auditable, qu’il est déployé à partir de requirements explicites avec une release pinée et une eval gate, et que chaque trust boundary applique validation, authorization, least privilege et human approval lorsque nécessaire.

Explorer le phare info

📌 Contexte

📊 Les stratégies de greenwashing

1. Techniques utilisées par les multinationales

2. Exemples concrets de greenwashing

3. Les conséquences pour les consommateurs et l’environnement

⚠️ Décryptage des biais

🚀 Quelles solutions pour lutter contre le greenwashing ?

📝 Conclusion

Fiche de révision certification — Accelerators & IP Contribution

1. Accelerator

Concept

À retenir

Exemple

Piège d’examen

2. Que faut-il parameterize ?

Credentials by reference

3. Documentation minimale d’un accelerator

4. Auditability

5. Agent Template

6. MCP Server Package

7. Eval Suite

8. Quand ne pas créer d’accelerator ?

9. Contribution readiness

Ce qu’un maintainer veut

Exemple vs test

10. Choisir le bon contribution channel

Focused reference implementation

Tool ou MCP server

Full customer application

One-line fix

11. Licensing, attribution et rights

Piège d’examen

12. Business problem ≠ requirement

13. Functional requirement

14. Infrastructure requirement

Exemple certification

Piège : solution ≠ requirement

15. Requirements avant architecture

16. Systems lifecycle

17. Que se passe-t-il dans chaque phase ?

18. Gates

Exemple Design → Build

Exemple Test → Deploy

19. Activités à savoir classer

Pin full model ID

Keep prior version

Gate promotion on eval

Run eval

Decide data must remain in a specific region

Choose platform based on requirements

Measure production latency and token cost

20. Deployment platform

Dimensions importantes

21. Compliance peut être PASS/FAIL

Modèle mental

22. Latency

23. Cost

24. Data residency

25. Pin what ships

26. Pourquoi le pinning ?

27. Ne pas versionner uniquement le modèle

Exemple

28. Upgrade d’un modèle

29. Garder la prior version

30. Evals + monitoring + rollback

31. Trust boundary

32. Mark every seam as a boundary

33. Fetched content remains untrusted

Mauvais modèle

Bon modèle

34. Indirect prompt injection

35. Data ≠ instructions

36. Prompt-only security est insuffisante

37. Claude demande, l’application autorise

38. Validation ≠ authorization

Exemple

39. Least privilege

40. Le seam le plus privilégié est critique

41. Human approval