Avant de choisir un modèle, une plateforme ou une architecture, il faut répondre à une question plus fondamentale :
Qu’est-ce que le système doit réellement faire, et sous quelles contraintes doit-il fonctionner ?
C’est une étape que les équipes techniques ont parfois tendance à écourter.
Un besoin métier arrive sous une forme générale :
« Nous voulons aider les agents support à répondre plus vite. »
ou :
« Nous voulons résumer automatiquement les appels clients. »
Mais ces formulations ne suffisent pas pour concevoir une application Claude.
Elles ne disent pas :
- ce que le système doit produire exactement ;
- quelles actions sont autorisées ;
- quelles actions nécessitent une validation humaine ;
- où les données doivent être traitées ;
- quelle latence est acceptable ;
- quelle identité doit être utilisée ;
- quelles contraintes réglementaires s’appliquent.
Le travail d’ingénierie consiste donc à transformer le business problem en requirements vérifiables.
Un business problem n’est pas encore un requirement
Prenons ce besoin :
« Aider les agents support à répondre plus rapidement. »
C’est un objectif métier.
Mais il est trop vague pour être testé.
Comment savoir objectivement si le système le satisfait ?
Faut-il :
- classer les tickets ?
- rédiger une réponse ?
- retrouver une procédure ?
- envoyer automatiquement le message ?
- citer les sources ?
- demander une validation humaine ?
Le besoin doit être décomposé en comportements précis.
Functional requirements : ce que le système doit faire
Un functional requirement décrit un comportement attendu du système.
Il doit être formulé de manière suffisamment précise pour pouvoir être vérifié.
Par exemple :
Le système classe chaque ticket dans l’une des quatre catégories définies.
ou :
Le système génère un brouillon de réponse contenant une référence à la politique applicable.
ou encore :
Le système ne doit jamais envoyer automatiquement une réponse sans validation humaine.
Ces formulations sont testables.
Exemple : du besoin vague au comportement vérifiable
Besoin initial :
"Help support agents answer faster."
Transformation possible :
1. Classify each ticket into one of four queues.
2. Retrieve the relevant policy.
3. Draft a response citing that policy.
4. Require human approval before sending.
On est passé d’un objectif général à plusieurs comportements contrôlables.
Pourquoi un requirement doit être testable
Si une exigence est trop vague, elle ne peut pas devenir :
- un test ;
- une eval ;
- une gate ;
- un critère de review.
Par exemple :
« Le système doit être performant. »
ne précise rien.
Une meilleure formulation serait :
« Le système doit produire un résumé utilisable par l’agent support dans le délai attendu par le workflow métier. »
Et si le projet exige davantage de précision, cette exigence peut encore être raffinée avec une mesure concrète.
Exemple de mauvais functional requirement
Considérons :
« L’agent doit être rapide et précis. »
Cette phrase mélange deux qualités souhaitables, mais elle ne définit pas un comportement suffisamment vérifiable.
On ne sait pas :
- ce que signifie « rapide » ;
- ce que signifie « précis » ;
- comment mesurer l’une ou l’autre.
Elle constitue donc davantage un objectif qu’un requirement exploitable.
Exemple de bon functional requirement
Dans le scénario du module :
Une banque européenne réglementée souhaite un agent qui résume des transcripts d’appels clients.
Un requirement valide serait :
The agent produces a summary that a human approves before it is stored.
Ce comportement est clair.
Il peut être testé.
Le workflow est explicite :
TRANSCRIPT
↓
CLAUDE
↓
SUMMARY
↓
HUMAN REVIEW
↓
STORAGE
La présence d’un human approval avant stockage fait partie du comportement fonctionnel du système.
Infrastructure requirements : sous quelles contraintes le système doit fonctionner
Les infrastructure requirements décrivent les contraintes non fonctionnelles que le déploiement doit respecter.
Le document met particulièrement en avant quatre dimensions :
latency;scale;residency;identity.
Ces contraintes peuvent déterminer directement la plateforme et l’architecture.
1. Latency
La question est :
À quelle vitesse le système doit-il répondre ?
Il ne suffit pas de dire :
« Il doit être rapide. »
Il faut comprendre le workflow réel.
Une application utilisée pendant une interaction avec un client n’a pas les mêmes contraintes qu’un batch exécuté pendant la nuit.
Par exemple :
Real-time support
→ low latency is important
Nightly batch processing
→ higher latency may be acceptable
La contrainte vient donc du besoin métier.
2. Scale
Il faut également comprendre la charge.
Par exemple :
- combien de requêtes par jour ?
- combien de requêtes simultanées ?
- quels sont les pics ?
- quelle taille ont les inputs ?
- quelle quantité de tokens est consommée ?
Un prototype utilisé par cinq personnes ne pose pas les mêmes contraintes qu’un système utilisé par plusieurs milliers d’agents.
3. Data residency
Dans un contexte réglementé, la localisation du traitement des données peut devenir une contrainte déterminante.
Par exemple :
Transcript data is processed in the EU.
Ce requirement n’explique pas ce que fait fonctionnellement l’agent.
Il impose une contrainte sur l’endroit où le workload peut être exécuté.
Il s’agit donc d’un infrastructure requirement.
Pourquoi la residency doit être capturée tôt
Supposons qu’une équipe développe toute l’application sur une plateforme familière.
Le projet fonctionne.
Les tests passent.
Puis le security review demande :
Où sont traitées les données ?
Si la plateforme choisie ne respecte pas l’exigence de residency, toute l’intégration peut devoir être reconstruite.
Le requirement existait depuis le début.
Il n’avait simplement pas été capturé.
4. Identity
La question de l’identité est tout aussi importante.
Il faut savoir :
- sous quelle identité le système agit ;
- quelles ressources cette identité peut atteindre ;
- comment les credentials sont gérés ;
- quelles actions sont auditées.
Dans une architecture composée de plusieurs services, différentes identités peuvent être utilisées.
Par exemple :
User
↓
Application identity
↓
MCP server identity
↓
Customer system
Chaque niveau doit être compris et documenté.
Les infrastructure requirements ne sont pas toujours explicitement donnés
C’est un point important.
Le client peut dire :
« Nous voulons résumer les appels clients. »
Il ne dira pas nécessairement spontanément :
« Nous avons besoin d’un endpoint régional respectant telle politique de residency et intégré à notre IAM existant. »
Ces contraintes doivent être dérivées.
Le développeur ou l’architecte doit poser les questions que le besoin implique.
Les questions à poser
Avant de choisir la plateforme, il faut notamment comprendre :
Latency
À quel moment le résultat est-il utilisé ?
Un utilisateur attend-il devant l’écran ?
Scale
Combien d’appels sont prévus ?
Quel est le pic de charge ?
Residency
Existe-t-il une obligation de traitement dans une région précise ?
Identity
Qui appelle le système ?
Sous quels credentials ?
Quels accès doivent être audités ?
Business problem → requirements
On peut représenter le processus ainsi :
BUSINESS PROBLEM
↓
What must the system do?
↓
FUNCTIONAL REQUIREMENTS
↓
Under what constraints?
↓
INFRASTRUCTURE REQUIREMENTS
Ces requirements deviennent ensuite l’entrée des décisions d’architecture.
Exemple complet : banque européenne
Le scénario du module est le suivant :
Une banque européenne réglementée souhaite un agent qui résume les transcripts des appels clients pour l’équipe support.
À partir de ce besoin, on peut distinguer différents types de requirements.
Functional requirement
The agent produces a summary that a human approves before it is stored.
Pourquoi est-ce fonctionnel ?
Parce que cette phrase décrit le comportement du workflow.
Generate summary
↓
Human approval
↓
Store
Infrastructure requirement
Transcript data is processed in the EU.
Pourquoi est-ce infrastructure ?
Parce que cela contraint l’environnement d’exécution.
Workload
↓
Must execute within
approved EU processing boundary
Cette règle peut éliminer certaines options de plateforme.
Attention aux réponses qui semblent techniques
Dans les QCM, certaines propositions peuvent sembler « très techniques » sans être des infrastructure requirements.
Par exemple :
« The agent summarizes transcripts using a pre-approved prompt template. »
Cela concerne la manière dont la fonctionnalité est implémentée.
Ce n’est pas la même chose qu’une contrainte comme :
- region ;
- identity ;
- latency ;
- scale.
Functional vs infrastructure : tableau de distinction
| Requirement | Type |
|---|---|
| Le système classe chaque ticket dans une queue | Functional |
| Le système génère un résumé | Functional |
| Un humain approuve avant stockage | Functional |
| Les données sont traitées dans l’UE | Infrastructure |
| Le système utilise l’IAM du cloud client | Infrastructure |
| Le service doit supporter le volume de pointe | Infrastructure |
| La réponse doit arriver dans le délai imposé par l’usage | Infrastructure |
Pourquoi cette distinction est importante
Parce que les deux types de requirements orientent des décisions différentes.
Les functional requirements orientent notamment :
- prompts ;
- workflows ;
- tools ;
human-in-the-loop;- evals.
Les infrastructure requirements orientent notamment :
- plateforme de déploiement ;
- région ;
- IAM ;
- capacité ;
- architecture réseau ;
- observabilité.
Les requirements deviennent des critères de design
Supposons que le requirement dise :
« Les données doivent être traitées dans une région spécifique. »
Alors la phase de design doit choisir une plateforme qui permet de satisfaire cette contrainte.
On obtient :
REQUIREMENT
EU processing required
↓
DESIGN DECISION
Choose a deployment option
that satisfies EU residency
La plateforme n’est donc pas choisie parce que l’équipe l’aime ou la connaît.
Elle est choisie parce qu’elle satisfait les requirements.
Les requirements deviennent aussi des critères de test
Un requirement fonctionnel comme :
« Un humain doit approuver avant stockage »
peut être vérifié en testant qu’aucun chemin d’exécution ne contourne cette étape.
Conceptuellement :
summary_generated = True
human_approved = False
store(summary)
devrait être interdit.
Le requirement devient donc un testable invariant.
Requirements et evals
Une bonne eval suite doit refléter les comportements réellement attendus.
Si un requirement est :
Le système doit citer la politique applicable.
L’eval peut vérifier que la réponse :
- contient une citation ;
- cite la bonne source ;
- ne fabrique pas une politique inexistante.
Ainsi :
REQUIREMENT
↓
EVAL CASE
↓
PASS / FAIL
Un requirement suffisamment précis peut donc devenir directement un critère d’évaluation.
Requirements et human-in-the-loop
Certains requirements portent explicitement sur les actions qui doivent rester sous contrôle humain.
Dans l’exemple :
Human approves before storage.
Cela signifie que l’architecture ne doit pas permettre :
Claude
↓
Automatic permanent storage
mais plutôt :
Claude
↓
Draft / Summary
↓
Human review
↓
Approved?
↙ ↘
Yes No
↓ ↓
Store Reject/Edit
La présence du contrôle humain n’est pas un détail d’interface.
Elle fait partie de la spécification.
Documenter les requirements pour pouvoir défendre le choix
Le module insiste sur un autre objectif :
les requirements doivent être écrits afin que les personnes qui n’ont pas participé aux discussions initiales puissent comprendre les décisions.
C’est particulièrement important lors de :
- security review ;
- procurement review ;
- architecture review ;
- compliance review.
Exemple
Une équipe choisit Amazon Bedrock.
Sans requirements documentés, la justification peut ressembler à :
« C’est la plateforme qu’on utilise généralement. »
Avec un requirements record :
Requirement:
EU processing boundary required
Requirement:
AWS IAM must be reused
Requirement:
Existing compliance controls are on AWS
Decision:
Use the deployment option satisfying
those requirements
La décision est désormais défendable.
Le requirements record
Le document recommande un enregistrement court couvrant :
- les comportements fonctionnels ;
- les contraintes d’infrastructure ;
- la réglementation ou la raison derrière ces contraintes.
Il n’est pas nécessairement gigantesque.
L’objectif est que la décision puisse être reconstruite.
Exemple de format
Functional Requirements
-----------------------
FR-01: Generate a call summary.
FR-02: Human approval required before storage.
Infrastructure Requirements
---------------------------
IR-01: Process transcript data in the EU.
IR-02: Use approved enterprise identity controls.
IR-03: Support expected peak workload.
Source / Rationale
------------------
IR-01: Regulatory residency requirement.
IR-02: Customer security policy.
Ce type de document fournit une trace claire.
Pourquoi ne pas choisir la plateforme avant les requirements ?
Parce que cela inverse le raisonnement.
Mauvaise approche :
"We know AWS."
↓
Choose AWS
↓
Try to make requirements fit
Bonne approche :
Business need
↓
Requirements
↓
Constraints
↓
Evaluate platforms
↓
Choose platform
La plateforme devient une conséquence du problème, pas un point de départ.
Le piège de la familiarity
Une équipe peut être très expérimentée sur une plateforme.
C’est un avantage opérationnel.
Mais ce n’est pas automatiquement une justification suffisante.
Si la plateforme échoue sur un requirement obligatoire, la familiarité ne compense pas cet échec.
Dans un projet réglementé :
Compliance requirement
↓
PASS or FAIL
Un meilleur coût ou une meilleure productivité de développement ne transforme pas un FAIL réglementaire en PASS.
Le piège du prototype devenu production
Autre scénario fréquent :
Une équipe démarre un prototype.
Elle choisit l’environnement le plus rapide.
Aucun problème.
Puis le prototype devient progressivement un système réel.
Mais les requirements d’infrastructure n’ont jamais été formalisés.
Lorsque le système arrive en production, apparaissent :
- residency ;
- identity ;
- audit ;
- scale ;
- latency.
La migration devient alors plus coûteuse.
Une exception : le throwaway prototype
Le document précise néanmoins qu’un prototype réellement jetable peut fonctionner avec des notes plus légères.
Si le projet :
- n’est pas destiné à la production ;
- ne manipule pas de données réglementées ;
- n’est soumis à aucun review ;
il n’est pas nécessaire d’appliquer la même lourdeur documentaire.
Le principe reste celui de l’architecture proportionnée au contexte.
Principe → Exemple → Erreur fréquente → Bonne pratique
Principe
Transformer le business problem en comportements testables et en contraintes d’infrastructure avant de choisir la plateforme.
Exemple
Besoin :
Résumer les appels d’une banque européenne.
Functional requirement :
Un humain approuve le résumé avant stockage.
Infrastructure requirement :
Les transcripts sont traités dans l’UE.
Erreur fréquente
Choisir d’abord la plateforme parce que l’équipe la maîtrise, puis découvrir les contraintes de residency pendant le security review.
Bonne pratique
Capturer functional requirements, latency, scale, residency et identity pendant le scoping.
Checkpoint : identifier le bon type de requirement
Reprenons le scénario :
Une banque européenne réglementée souhaite un agent qui résume les transcripts d’appels clients.
Question
Laquelle correspond à un valid functional requirement ?
A. L’agent doit être rapide et précis.
B. L’agent produit un résumé qu’un humain approuve avant stockage.
C. Le système doit être construit avec un cloud provider approuvé.
D. Les transcripts ne doivent pas quitter l’UE.
La réponse attendue est :
B
Pourquoi ?
Parce qu’elle décrit précisément un comportement du système.
Deuxième question
Laquelle correspond à un valid infrastructure requirement ?
A. Le système produit les résumés suffisamment rapidement pour le support.
B. L’agent utilise un prompt pré-approuvé.
C. Les transcripts sont traités dans l’UE.
D. Un humain examine chaque résumé.
La réponse la plus nette dans ce scénario est :
C
Il s’agit d’une contrainte directe sur l’environnement d’exécution.
Ce qu’il faut retenir pour la certification
Les questions d’examen peuvent présenter plusieurs formulations qui semblent toutes raisonnables.
Utilisez cette règle :
Functional
Demandez :
What must the system do?
Infrastructure
Demandez :
Under what technical or operational constraints must it run?
Réflexes de scénario
| Signal | Réflexe |
|---|---|
| « Le système doit générer… » | Functional |
| « Un humain doit approuver… » | Functional |
| « Les données doivent rester dans… » | Infrastructure |
| « Le workload doit utiliser l’IAM… » | Infrastructure |
| « Il doit supporter X requêtes… » | Infrastructure |
| « L’équipe connaît déjà cette plateforme » | Pas un requirement |
| Requirement vague | Le rendre checkable |
| Compliance obligatoire | Capturer avant le platform choice |
Fiche rapide
| Concept | À retenir | Exemple | Piège d’examen |
|---|---|---|---|
| Business problem | Objectif métier initial | Répondre plus vite | Le traiter comme une spec |
| Functional requirement | Comportement testable | Human approval avant stockage | Formulation vague |
| Infrastructure requirement | Contrainte de fonctionnement | EU residency | Confondre avec implémentation |
| Latency | Temps nécessaire au workflow | Support temps réel | Mesure abstraite |
| Scale | Charge attendue | Peak requests | Ignorer les pics |
| Residency | Région de traitement | EU-only | La découvrir après le build |
| Identity | Qui agit et avec quels accès | AWS IAM role | Utiliser des credentials génériques |
| Requirements record | Justifie les décisions | Contraintes + origine | Garder les décisions uniquement oralement |
À retenir en une phrase
Avant de choisir une architecture Claude, transformez le besoin métier en functional requirements vérifiables et en infrastructure requirements explicites — notamment latency, scale, residency et identity — afin que le design soit une conséquence des contraintes réelles plutôt qu’un choix basé sur la familiarité.
Cette étape prépare directement la suivante : le systems lifecycle, dans lequel ces requirements deviennent la première phase d’un processus complet allant jusqu’au déploiement, à l’exploitation et à l’itération.
