Une application Claude ne doit pas être pensée comme une simple succession de prompts et de calls API.
Elle suit un véritable systems lifecycle.
Ce cycle permet de replacer chaque activité au bon moment :
- définir les besoins ;
- concevoir l’architecture ;
- construire ;
- tester ;
- déployer ;
- exploiter ;
- améliorer.
Le module présente ce cycle sous la forme suivante :
Requirements
↓
Design
↓
Build
↓
Test
↓
Deploy
↓
Operate
↓
Iterate
└────────────→ Requirements
L’intérêt de ce modèle est simple :
Chaque décision appartient à une phase précise et certaines transitions doivent être protégées par des gates.
C’est particulièrement important dans les environnements réglementés.
Pourquoi parler de lifecycle pour une application Claude ?
Dans les modules précédents, les différents sujets sont souvent étudiés séparément :
- agents ;
- prompts ;
- tools ;
- MCP ;
- evals ;
- sécurité ;
- déploiement.
Le systems lifecycle permet de comprendre comment ces éléments s’enchaînent.
Par exemple :
Requirements
→ Que doit faire le système ?
Design
→ Quelle architecture et quelle plateforme ?
Build
→ Quels agents, tools et prompts ?
Test
→ Est-ce que cela fonctionne correctement ?
Deploy
→ Quelle version part en production ?
Operate
→ Que se passe-t-il réellement en production ?
Iterate
→ Que faut-il améliorer ?
Le lifecycle évite de traiter le déploiement, le versioning ou la sécurité comme des sujets ajoutés à la fin.
Phase 1 — Requirements
La première phase consiste à capturer :
- les
functional requirements; - les
infrastructure requirements.
Comme vu dans l’article précédent, cela inclut notamment :
- les comportements attendus ;
- la latency ;
- le scale ;
- la data residency ;
- l’identity.
Exemple :
Functional requirement:
A human approves the summary before storage.
Infrastructure requirement:
Transcript data must be processed in the EU.
Ces requirements deviennent la base des décisions suivantes.
Pourquoi Requirements vient avant Design
La plateforme et l’architecture doivent répondre aux contraintes.
Pas l’inverse.
Le mauvais ordre serait :
Choose platform
↓
Try to fit requirements
Le bon ordre :
Requirements
↓
Constraints
↓
Design
Phase 2 — Design
La phase Design répond notamment à trois grandes questions :
- quelle plateforme utiliser ?
- quel modèle utiliser ?
- quelles sont les
trust boundaries?
On conçoit ici l’architecture avant de commencer à coder.
Par exemple :
Requirements:
- EU residency
- existing AWS compliance posture
Design:
- choose an AWS-compatible deployment path
- define identity boundaries
- define component scopes
Le design transforme les contraintes en décisions d’architecture.
Le modèle fait également partie du Design
Le choix du modèle appartient à cette phase.
Il dépend notamment :
- de la qualité nécessaire ;
- du coût ;
- de la latency ;
- du type de workload.
Mais le lifecycle rappelle que ce choix doit s’inscrire dans une architecture globale.
Le modèle n’est pas choisi indépendamment de la plateforme ou des contraintes.
Les trust boundaries appartiennent au Design
Supposons l’architecture suivante :
API
↓
Claude Code task
↓
MCP server
↓
Customer system
Avant même d’écrire le code, il faut identifier :
- les données qui traversent chaque seam ;
- les identités utilisées ;
- les permissions ;
- les contenus non fiables.
Ces frontières sont des décisions de design.
Phase 3 — Build
La phase Build correspond à l’implémentation.
On y développe notamment :
- agents ;
- tools ;
- prompts ;
- MCP integrations ;
- loops ;
- application code.
Exemple :
DESIGN
Agent uses two tools
↓
BUILD
Implement:
- read_file
- run_linter
- agent loop
- prompt
C’est la phase où le système prend effectivement forme.
Build ne signifie pas encore que le système est prêt
Un code qui fonctionne localement n’est qu’une étape.
Il doit encore passer par :
Test
Deploy
Operate
C’est exactement le message général du module :
le moment où le code commence à fonctionner n’est pas le moment où le travail est terminé.
Phase 4 — Test
La phase Test regroupe plusieurs types de vérifications.
Le document cite :
evals;- unit tests ;
- integration tests ;
- end-to-end tests.
Chaque niveau répond à un problème différent.
Unit tests
Ils vérifient des composants isolés.
Par exemple :
result = normalize_input(data)
assert result == expected
Ils sont adaptés aux comportements déterministes du code.
Integration tests
Ils vérifient plusieurs composants ensemble.
Par exemple :
Agent
↓
Tool
↓
MCP server
L’objectif est de vérifier que l’intégration réelle fonctionne.
End-to-end tests
Ils vérifient le workflow complet.
Par exemple :
User input
↓
Agent
↓
Tool calls
↓
External system
↓
Final response
Evals
Les evals jouent un rôle particulier pour les comportements LLM.
Elles permettent d’évaluer :
- qualité ;
- conformité ;
- robustesse ;
- respect des instructions ;
- comportements métier.
Elles deviennent également essentielles au moment du déploiement.
Phase 5 — Deploy
La phase Deploy ne consiste pas seulement à pousser du code en production.
Le document met l’accent sur deux éléments :
- pinning de la version ;
- gating de promotion sur l’eval.
Autrement dit :
Candidate version
↓
Eval
↓
Pass?
↙ ↘
Yes No
↓ ↓
Deploy Block
Le déploiement devient un processus contrôlé.
Pinning : savoir exactement ce qui part en production
Un élément essentiel est de savoir quelle version exacte du modèle est utilisée.
Le principe :
Pin what ships.
Le modèle, le prompt et l’asset doivent être versionnés de manière explicite.
Le système ne doit pas dépendre d’un changement silencieux.
Garder la version précédente
La phase de déploiement doit aussi prévoir le rollback.
Conceptuellement :
Production:
Version N
Candidate:
Version N+1
↓
Eval
↓
Regression?
↓ YES
Rollback to Version N
Une version précédente conservée transforme un incident potentiel en rollback maîtrisé.
Phase 6 — Operate
Une fois en production, le système doit être observé.
Le document cite notamment :
- cost ;
- latency ;
- errors ;
- guardrails.
On entre ici dans la réalité du système.
Instrumenter le coût
Il faut savoir combien coûte réellement le workload.
Pas uniquement :
price per token
mais le coût du système dans son ensemble.
Les mesures peuvent notamment porter sur :
- tokens input ;
- tokens output ;
- coût par call ;
- coût par workflow ;
- coût par client.
Instrumenter la latency
La latency réelle doit être observée en production.
Une mesure effectuée depuis un environnement de développement peut être trompeuse.
L’exploitation permet de voir :
- les temps de réponse réels ;
- les différences selon les régions ;
- les pics ;
- les variations de charge.
Observer les erreurs
Il faut également suivre :
- API errors ;
- tool failures ;
- timeout ;
- rate limits ;
- parser failures ;
- erreurs d’intégration.
Un système qui ne logge pas correctement les erreurs est difficile à exploiter.
Guardrails
Les contrôles de sécurité doivent continuer à fonctionner en production.
Il ne suffit pas de les avoir testés une fois.
Le système doit continuer à appliquer :
- permissions ;
- validation ;
- least privilege ;
- human approval lorsque nécessaire.
Phase 7 — Iterate
La dernière phase consiste à utiliser les observations de production pour améliorer le système.
Cette phase referme la boucle.
Operate
↓
Findings
↓
Iterate
↓
New Requirements
C’est un point important.
Une application Claude n’est pas un artefact figé.
Les informations venant de la production alimentent de nouvelles décisions.
Exemple d’itération
Supposons qu’en production on observe :
Latency too high
Cette observation devient potentiellement un nouveau requirement :
Response must complete within target X
Puis :
Requirement
↓
Design change
↓
Build
↓
Test
↓
Deploy
Le cycle recommence.
Les gates entre les phases
Le module insiste particulièrement sur les gates.
Une gate est un point de décision empêchant le passage automatique d’une phase à la suivante.
Dans un environnement réglementé, ces gates sont essentielles.
Exemple de gate : Design → Build
Supposons qu’un requirement impose :
Les données doivent être traitées dans une région spécifique.
La phase Design propose une plateforme.
Avant de passer à Build, il faut vérifier :
Does platform satisfy residency requirement?
Si la réponse est non :
STOP
On ne commence pas le développement dans l’espoir de résoudre la conformité plus tard.
Exemple de gate : Test → Deploy
La même logique s’applique avant production.
New model version
↓
Eval
↓
Meets pinned baseline?
Si non :
Do not promote
Cette gate empêche une régression connue d’arriver en production.
Pourquoi les gates sont importantes
Sans gate :
Design
↓
Build
↓
Deploy
même lorsque des contraintes importantes ne sont pas satisfaites.
Avec gate :
Design
↓
CHECK
↓
Build
Chaque transition devient explicite.
Les gates ajoutent du coût
Le module ne prétend pas que les gates sont gratuites.
Elles ajoutent :
- reviews ;
- validations ;
- documentation ;
- temps ;
- coordination.
Une équipe sous pression peut être tentée de les supprimer.
Mais dans un contexte réglementé, ces étapes maintiennent le système sous contrôle.
Le piège de la deadline
Une équipe peut penser :
« Nous vérifierons la residency après le prototype. »
ou :
« Nous lancerons la nouvelle version et nous regarderons ensuite si la qualité baisse. »
Ces raccourcis déplacent le problème vers une phase beaucoup plus coûteuse.
Issue found in Requirements
→ cheap to change
Issue found in Design
→ manageable
Issue found after Deploy
→ expensive
Lifecycle et régulation
Le document précise qu’un prototype ponctuel peut éventuellement réduire certaines phases.
Mais un environnement réglementé ne peut pas simplement supprimer les gates.
Pourquoi ?
Parce que les reviewers doivent pouvoir reconstruire :
- ce qui a été décidé ;
- pourquoi ;
- ce qui a été testé ;
- ce qui a été approuvé.
Le lifecycle contribue donc à la reviewability du système.
Placer chaque activité dans la bonne phase
Le module propose plusieurs exemples très utiles.
Activité A — Pinning du model ID
Pinning the full model ID and keeping the prior version.
Cette activité appartient à :
Deploy
Pourquoi ?
Parce qu’elle concerne la version exacte qui est mise en production et la capacité de rollback.
Activité B — Gating promotion on eval result
Gating promotion on the eval result before a version goes to production.
Cela appartient également à :
Deploy
Le test a été exécuté, mais la décision de promotion est une décision de déploiement.
Activité C — Décider que les données doivent être traitées dans une région
Cela appartient à :
Requirements
C’est une contrainte à capturer avant de choisir la plateforme.
Activité D — Instrumenter cost et latency en production
Cela appartient à :
Operate
Parce qu’il s’agit d’observer le système réel en fonctionnement.
Activité E — Choisir Bedrock pour la compliance posture du client
Cela appartient à :
Design
Le requirement existe déjà.
Le choix de la plateforme est la décision d’architecture qui y répond.
Tableau synthétique
| Activité | Phase |
|---|---|
| Définir EU residency | Requirements |
| Choisir la plateforme | Design |
| Identifier trust boundaries | Design |
| Écrire l’agent | Build |
| Implémenter tools | Build |
| Exécuter unit tests | Test |
| Exécuter evals | Test |
| Pin le model ID | Deploy |
| Gate promotion sur eval | Deploy |
| Conserver prior version | Deploy |
| Mesurer token cost | Operate |
| Mesurer latency réelle | Operate |
| Observer production errors | Operate |
| Transformer les incidents en nouveaux besoins | Iterate |
Attention : Test et Deploy sont liés, mais différents
Un piège possible consiste à confondre :
Run eval
et :
Use eval as deployment gate
Le premier appartient principalement à :
Test
Le second appartient à :
Deploy
On peut donc avoir :
TEST
Run evaluation
↓
DEPLOY
Decide whether candidate can be promoted
Cette distinction est importante.
Attention : requirement et design ne sont pas la même chose
Autre confusion fréquente :
"Data must be processed in EU"
est un requirement.
Tandis que :
"Choose platform X because it satisfies EU residency"
est une décision de design.
Le requirement dit :
What constraint exists?
Le design répond :
How do we satisfy it?
Attention : production monitoring appartient à Operate
Une fois le système déployé, le travail n’est pas terminé.
L’observation continue appartient à Operate.
Cela inclut :
cost
latency
errors
guardrails
La production devient une source de données pour les décisions suivantes.
Le lifecycle comme boucle d’amélioration
Le modèle complet n’est pas linéaire.
Requirements
↓
Design
↓
Build
↓
Test
↓
Deploy
↓
Operate
↓
Iterate
└────────→ Requirements
Cette boucle est essentielle.
Elle signifie que les observations réelles peuvent modifier :
- le prompt ;
- le modèle ;
- les tools ;
- les requirements ;
- la plateforme ;
- les contrôles.
Exemple complet
Prenons une application de résumé d’appels pour une banque.
Requirements
- Human approval before storage
- EU processing requirement
Design
- Select compliant platform
- Define identity model
- Define trust boundaries
Build
- Implement summarization agent
- Implement review workflow
- Implement storage integration
Test
- Unit tests
- Integration tests
- Evals
Deploy
- Pin model version
- Retain previous version
- Gate promotion on eval
Operate
- Measure latency
- Measure cost
- Monitor failures
Iterate
- Feed production findings back
- Adjust requirements
Ce qu’il faut retenir pour l’examen
Pour un scénario, posez-vous cette question :
À quel moment du lifecycle cette décision doit-elle être prise ?
Réflexes de certification
| Signal dans la question | Phase |
|---|---|
| Besoin métier | Requirements |
| Residency constraint | Requirements |
| Scale requirement | Requirements |
| Choix de plateforme | Design |
| Trust boundary | Design |
| Choix du modèle | Design |
| Écriture du prompt | Build |
| Implémentation tool | Build |
| Unit test | Test |
| Eval execution | Test |
| Pinned version | Deploy |
| Rollback version | Deploy |
| Promotion gate | Deploy |
| Token cost production | Operate |
| Latency production | Operate |
| Production errors | Operate |
| Nouvelle exigence issue de production | Iterate |
Piège d’examen : choisir la plateforme pendant Requirements
Le requirement peut dire :
EU residency required
mais il ne doit pas nécessairement dire :
Use platform X
Le premier décrit la contrainte.
Le second est une solution.
La solution appartient au Design.
Piège d’examen : considérer l’eval uniquement comme un test
Les evals appartiennent bien à la phase Test.
Mais leur résultat peut aussi devenir une gate de déploiement.
Il faut donc savoir distinguer :
Evaluation activity
→ Test
Promotion decision based on evaluation
→ Deploy
Piège d’examen : oublier Operate
Une application en production doit être instrumentée.
Si un scénario parle de :
- cost ;
- latency ;
- errors ;
- monitoring ;
pensez immédiatement à :
Operate
Piège d’examen : supprimer les gates sous pression
Dans un système réglementé, une deadline ne justifie pas de passer directement :
Design → Build
sans vérifier les contraintes de compliance.
Ni :
Test → Production
sans gate.
La solution la plus sûre et la plus contrôlable reste celle qui respecte les transitions nécessaires.
Principe → Exemple → Erreur fréquente → Bonne pratique
Principe
Chaque activité appartient à une phase précise du systems lifecycle, et les transitions importantes sont protégées par des gates.
Exemple
Requirement:
EU residency
Gate:
Platform must satisfy residency before Build
Puis :
Candidate model
→ Eval
→ Deployment gate
→ Promote or rollback
Erreur fréquente
Commencer à coder avant de vérifier les contraintes de plateforme ou promouvoir une nouvelle version sans évaluation.
Bonne pratique
Utiliser :
Requirements
→ Design
→ Build
→ Test
→ Deploy
→ Operate
→ Iterate
avec des gates explicites sur les décisions critiques.
Fiche rapide
| Concept | À retenir | Exemple | Piège |
|---|---|---|---|
| Requirements | Définir besoins et contraintes | EU residency | Choisir déjà la solution |
| Design | Choisir architecture | Platform + trust boundaries | Confondre avec implementation |
| Build | Implémenter | Agent + tools | Considérer build = terminé |
| Test | Vérifier | Evals + unit tests | Tester seulement le happy path |
| Deploy | Contrôler ce qui part | Pin model | Alias mouvant |
| Operate | Observer production | Cost + latency | Ne pas instrumenter |
| Iterate | Réinjecter les findings | Nouveau requirement | Ne jamais revoir les besoins |
| Gate | Autoriser ou bloquer transition | Eval avant promote | Sauter la gate sous deadline |
À retenir en une phrase
Une application Claude suit un systems lifecycle complet : Requirements → Design → Build → Test → Deploy → Operate → Iterate, avec des gates explicites entre les phases critiques afin qu’aucune contrainte, régression ou décision de production ne soit laissée implicite.
Le prochain article abordera l’une des décisions centrales de la phase Design : où déployer Claude — first-party API, Claude Platform on AWS, Amazon Bedrock, Google Vertex AI ou third-party platform — et comment versionner ce qui part réellement en production.
