# D3 · Inputs, Outputs and Contracts
Traiter chaque étape d’un workflow comme un contrat avec des entrées nommées, des champs requis, un schéma ou gabarit de sortie, des critères d’acceptation et un comportement défini en cas d’entrée manquante.
import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components';
Ce domaine pèse **16 %** de l’examen blanc — environ **8 items sur 50**. Il teste si vous savez rendre un workflow *prévisible* en définissant, pour chaque étape, exactement ce qui entre et exactement ce qui sort. La décomposition ([Domaine 2](/fr/openai/applied-ai/domains/d2-decomposing-work-into-steps/)) vous donne des étapes ; ce domaine donne à chaque étape un **contrat** afin que les étapes s’emboîtent de façon fiable et qu’un collègue qui exécute le workflow obtienne le même résultat que vous.
## Ce qu’il faut savoir
Le contrat d’une étape spécifie cinq choses : les **entrées nommées** qu’elle consomme, lesquelles sont **requises** par opposition à optionnelles, la **forme de sortie** qu’elle doit produire (un schéma, un gabarit ou des champs fixes), les **critères d’acceptation** qui définissent une bonne sortie, et le **comportement en cas d’entrée manquante ou malformée**. Les contrats transforment « ça marche en général » en « ça marche de façon prévisible » parce que chaque étape sait ce sur quoi elle peut compter en réception et ce qu’elle est tenue de renvoyer. La source unique la plus fréquente d’instabilité d’un workflow est une forme de sortie indéfinie qui alimente l’étape suivante, ou une entrée manquante non gérée que le modèle devine silencieusement.
## Objectifs d’apprentissage
À la fin de cette page, vous devriez être capable de :
1. **Spécifier** les entrées nommées d’une étape et marquer chacune comme requise ou optionnelle.
2. **Définir** une sortie comme un schéma, un gabarit ou un ensemble de champs fixes sur lequel les étapes en aval peuvent compter.
3. **Écrire** des critères d’acceptation qui rendent « bonne sortie » vérifiable plutôt que subjectif.
4. **Décider** ce qu’une étape fait quand une entrée requise est manquante ou malformée — demander, appliquer un défaut, ou échouer.
5. **Concevoir** le passage de relais entre deux étapes de sorte que la sortie du producteur corresponde exactement à l’entrée attendue par le consommateur.
---
## 3.1 Les cinq parties du contrat d’étape
```text
CONTRAT de l’étape « Catégoriser la facture »
ENTRÉES invoice_text (requis), known_categories (requis),
prior_vendor_map (optionnel)
SORTIE { vendor, amount, currency, category, confidence } (JSON)
ACCEPTATION category ∈ known_categories ; amount est un nombre ;
confidence dans [0,1] ; chaque champ présent
SI MANQUANT si invoice_text absent → ÉCHOUER avec « aucune facture fournie »
si known_categories absent → ÉCHOUER (impossible de catégoriser sûrement)
```
| Partie | Ce qu’elle fixe | Défaillance qu’elle prévient |
| --- | --- | --- |
| Entrées nommées | Ce que l’étape consomme, par nom | L’ambiguïté sur ce qu’il faut lui fournir |
| Requis vs optionnel | Ce qui doit être présent pour s’exécuter | La devinette silencieuse quand quelque chose manque |
| Forme de sortie | La structure exacte renvoyée | Les étapes en aval qui cassent sur un format inattendu |
| Critères d’acceptation | Ce que « correct » signifie, de façon vérifiable | « Ça a l’air bien » qui passe alors que non |
| Si entrée manquante | Le comportement de repli défini | Le modèle qui invente des données pour combler un manque |
:::tip[Signal d’évaluation]
Quand un énoncé dit que le workflow « renvoie parfois un format différent », « casse quand un champ est vide », ou « un collègue a obtenu un résultat différent », c’est un problème de contrat. Le remède est de fixer la forme de sortie et de définir le comportement en cas d’entrée manquante, pas de reformuler le prompt.
:::
## 3.2 Entrées nommées et champs requis
Chaque étape devrait déclarer ses entrées par nom et marquer chacune comme **requise** ou **optionnelle**. Cela compte le plus aux passages de relais : si l’étape 2 requiert un champ `total`, le contrat de l’étape 1 doit promettre de le produire.
| Style d’entrée | Quand l’utiliser | Exemple |
| --- | --- | --- |
| Requis | L’étape ne peut pas s’exécuter correctement sans | Le document à résumer |
| Optionnel avec défaut | Agréable à avoir ; un défaut sensé existe | Ton = « neutre » si non spécifié |
| Optionnel, change le comportement | La présence bascule un mode | Un glossaire → imposer la terminologie |
Un bug fréquent : un champ qui est *réellement* requis est traité comme optionnel, de sorte que lorsqu’il manque, le modèle fabrique une valeur plausible. Le déclarer requis avec une règle explicite d’entrée manquante arrête cela.
## 3.3 La sortie comme schéma, gabarit ou champs fixes
La forme de sortie est la colonne vertébrale du contrat, car c’est ce dont dépend l’étape suivante. Choisissez la forme la plus stricte dont le consommateur a besoin.
Pour des données structurées qu’un système ou une étape en aval analyse.
```json
{
"vendor": "string",
"amount": 0.0,
"currency": "USD",
"category": "one of the supplied categories",
"confidence": 0.0
}
```
Spécifiez les noms de champs, les types et les valeurs autorisées. Demandez *uniquement* le JSON, sans prose autour, pour que l’analyse soit fiable.
Pour un document qu’une personne lit, fixez les sections et l’ordre.
```text
## Synthèse hebdomadaire — {week}
### Points forts (5 puces max)
### Risques (chacun : risque — responsable — atténuation)
### Décisions nécessaires
```
Un gabarit rend la complétude vérifiable : une section manquante est visible.
Quand un JSON complet est excessif mais qu’il faut tout de même de la cohérence.
```text
Renvoyer exactement ces trois lignes :
CATEGORY:
AMOUNT:
NEEDS_REVIEW:
```
Bon marché, lisible par un humain, tout de même analysable.
La règle : **faire correspondre la forme de sortie au consommateur.** Un lecteur humain veut un gabarit ; un analyseur veut un schéma ; un tri humain rapide veut des champs fixes.
## 3.4 Critères d’acceptation — rendre « bon » vérifiable
Les critères d’acceptation transforment un « est-ce bon ? » subjectif en une check-list qu’une personne ou une étape ultérieure peut appliquer. De bons critères sont **observables**.
| Faible (non observable) | Fort (observable) |
| --- | --- |
| « Le résumé est de haute qualité » | « ≤ 200 mots ; couvre les cinq points de l’ordre du jour ; aucune affirmation absente de la source » |
| « La réponse est conforme à la marque » | « Deuxième personne ; aucun jargon de la liste interdite ; se termine par une prochaine étape » |
| « Le tableau est correct » | « La somme des lignes correspond au total indiqué ; chaque catégorie provient de l’ensemble autorisé » |
Les critères d’acceptation sont aussi ce que vérifient l’étape **brouillon puis critique** et le **point de revue humaine** — donc les écrire ici est payant au [Domaine 5](/fr/openai/applied-ai/domains/d5-review-points-and-human-oversight/).
:::tip[Signal d’évaluation]
« Comment savez-vous que la sortie est assez bonne ? » demande des critères d’acceptation. La meilleure réponse nomme des conditions observables et vérifiables — pas « ça se lit bien » ni « le modèle est capable ».
:::
## 3.5 Comportement en cas d’entrée manquante ou malformée
Le défaut le plus dangereux dans tout workflow est la *devinette silencieuse*. Quand une entrée requise est absente, une étape doit faire l’une de trois choses définies — jamais inventer des données.
```text
Entrée requise manquante ?
│
├─ Un humain peut-il la fournir rapidement ? ─► DEMANDER (renvoyer / signaler pour saisie)
│
├─ Existe-t-il un défaut sûr et explicite ? ─► DÉFAUT (et le marquer comme appliqué par défaut)
│
└─ Sinon ─► ÉCHOUER BRUYAMMENT (arrêter, renvoyer une raison claire ; ne pas fabriquer)
```
| Stratégie | À utiliser quand | Danger en cas de mauvais usage |
| --- | --- | --- |
| **Demander** | Une personne est dans la boucle et peut la fournir à faible coût | Interrompt l’automatisation à fort volume |
| **Défaut** | Un défaut sûr et documenté existe | Un défaut silencieux cache l’absence de données |
| **Échouer** | Aucun défaut sûr ; la justesse en dépend | Échouer à l’excès bloque le workflow sur des broutilles |
La mauvaise réponse est une quatrième option que personne n’écrit : **deviner**. Un modèle à qui l’on demande de catégoriser une facture sans liste de catégories inventera volontiers des catégories — plausibles, fausses, et indétectables en aval.
## 3.6 Concevoir le passage de relais entre étapes
Un workflow est une chaîne de contrats, et il ne tient que si le **contrat de sortie** de chaque producteur correspond au **contrat d’entrée** du consommateur suivant.
```text
Étape 1 SORTIE : { scope[], dates[], constraints[] }
│ doit correspondre ▼
Étape 2 ENTRÉE (requise) : scope[], dates[] ← consommée
ENTRÉE (optionnelle) : constraints[] ← utilisée si présente
SORTIE : { timeline, pricing_table }
│ doit correspondre ▼
Étape 3 ENTRÉE (requise) : timeline, pricing_table
```
Quand vous ajoutez ou modifiez une étape, revérifiez les deux bords : reçoit-elle ce dont elle a besoin, et produit-elle ce que l’étape suivante requiert ? La plupart des bugs « le workflow a cassé après que j’ai modifié l’étape 2 » sont un décalage de contrat à l’un de ces bords.
## 3.7 Les contrats comme documentation vivante
Un contrat écrit est aussi ce qui permet à un **collègue d’exécuter votre workflow**. Le contrat *est* l’interface : « donnez-lui ces entrées nommées, attendez cette forme de sortie, c’est terminé quand ces critères tiennent ». C’est pourquoi ce domaine alimente directement la répétabilité ([Domaine 6](/fr/openai/applied-ai/domains/d6-repeatability-and-improvement/)) — une étape non documentée ne vit que dans votre tête et ne peut être transmise, versionnée ni améliorée.
---
## Cadre de décision
**La fiche CONTRACT** — avant de construire une étape, remplissez une fiche. Si une ligne est vide, l’étape n’est pas prête.
| Ligne | Question | Exemple de réponse |
| --- | --- | --- |
| **In** | Quelles entrées nommées consomme-t-elle ? | `ticket_text`, `issue_types` |
| **Req** | Lesquelles sont requises vs optionnelles ? | les deux requises ; `customer_tier` optionnel |
| **Out** | Quelle forme exacte renvoie-t-elle ? | champs fixes : `DRAFT`, `NEEDS_REVIEW` |
| **Accept** | Quelles conditions observables définissent une bonne sortie ? | répond à chaque question posée ; aucune affirmation non vérifiée sur le compte |
| **Missing** | Que se passe-t-il si une entrée requise est absente ? | `issue_types` manquant → ÉCHOUER ; `ticket_text` manquant → ÉCHOUER |
| **Handoff** | La sortie correspond-elle à l’entrée requise de l’étape suivante ? | oui — l’étape suivante consomme `DRAFT` |
La discipline de la fiche est que **Missing** et **Handoff** sont des lignes obligatoires. La plupart des workflows instables ont ces deux-là vides.
## Erreurs fréquentes
| Erreur | Pourquoi elle se produit | Que faire à la place |
| --- | --- | --- |
| Laisser la forme de sortie non spécifiée | Le premier résultat avait l’air bien | Fixer un schéma/gabarit/champs fixes sur lequel le consommateur peut compter |
| Traiter une entrée requise comme optionnelle | Elle était présente dans chaque test | La marquer requise et définir le comportement d’entrée manquante |
| Laisser le modèle deviner quand l’entrée manque | Deviner ressemble à de la résilience | Demander, défaut (marqué), ou échouer bruyamment — jamais fabriquer |
| Écrire des critères d’acceptation subjectifs | « Haute qualité » semble suffisant | Utiliser des conditions observables et vérifiables |
| Passage de relais décalé après modification d’une étape | Seule l’étape modifiée a été testée | Revérifier les deux bords : reçoit-elle et donne-t-elle ce dont les voisines ont besoin |
| Emballer la sortie JSON dans de la prose | Le modèle est bavard par défaut | Demander uniquement le JSON pour que l’analyse soit fiable |
| Défauts silencieux qui cachent des données manquantes | Un défaut fait avancer le workflow | Marquer tout champ appliqué par défaut pour que la revue voie qu’il manquait |
| Aucun contrat écrit | Le workflow vit dans la tête de l’auteur | Écrire la fiche de contrat pour qu’un collègue puisse l’exécuter |
## Mise en situation
**Situation.** Lena a automatisé une étape qui lit les e-mails de feedback client et produit un enregistrement structuré pour le CRM : sentiment, domaine produit et un résumé d’une ligne. Cela a marché des semaines. Puis deux problèmes sont apparus. D’abord, un collègue qui a repris le workflow a obtenu une sortie *d’apparence différente* — parfois un paragraphe, parfois des puces, parfois une valeur de sentiment comme « plutôt positif » au lieu du `positive/neutral/negative` attendu. Ensuite, quand un e-mail arrive sans mention claire de produit, l’étape produit tout de même un domaine produit avec assurance — et ces valeurs devinées polluent le CRM. L’instinct de Lena est de réécrire le prompt pour qu’il soit « plus clair ».
**Trace de raisonnement expert.**
1. **Diagnostiquer le problème un comme une défaillance de forme de sortie.** La sortie n’a pas de schéma fixe, donc le modèle varie le format et invente même de nouvelles valeurs de sentiment. Un prompt en prose plus clair ne corrigera pas cela de façon fiable — le contrat n’a pas de forme de sortie fixée. Le remède est de spécifier un schéma : `sentiment ∈ {positive, neutral, negative}`, `product_area ∈ `, `summary` en une ligne, et d’exiger *uniquement* le JSON.
2. **Diagnostiquer le problème deux comme une défaillance d’entrée manquante.** L’étape traite `product_area` comme toujours dérivable, donc quand l’e-mail manque de produit clair, elle *devine* — la quatrième option interdite. Le contrat doit définir le comportement d’entrée manquante : si aucun produit ne peut être identifié avec confiance, produire `product_area: "unknown"` et `needs_review: yes` (un défaut marqué plus un drapeau), jamais un domaine fabriqué.
3. **Rejeter le réflexe du « prompt plus clair ».** Le problème n’est pas la persuasion ; c’est un contrat sous-spécifié. Reformuler pourrait réduire brièvement la dérive de format mais ne contraindra pas l’ensemble de valeurs ni ne gérera le produit manquant, et le collègue subira encore la dérive parce que la *forme* n’est pas fixée.
4. **Corriger le passage de relais.** Le CRM (le consommateur) requiert un sentiment énuméré et un domaine produit valide ou explicitement inconnu. Le contrat de sortie du producteur doit promettre exactement cet énuméré et cette gestion de l’inconnu, afin que le CRM ne reçoive plus jamais un sentiment en texte libre.
5. **Ajouter des critères d’acceptation pour la revue.** « Chaque enregistrement a tous les champs ; le sentiment est une des trois valeurs ; product_area provient de la liste ou est ‘unknown’ ; les domaines devinés sont signalés. » Désormais un contrôle par échantillonnage ([Domaine 5](/fr/openai/applied-ai/domains/d5-review-points-and-human-oversight/)) peut détecter les violations, et le contrat est une documentation que le collègue peut suivre pour obtenir une sortie identique.
**La décision :** remplacer le prompt vague par un **schéma de sortie défini (valeurs énumérées, JSON uniquement)** et une **règle explicite d’entrée manquante (unknown + needs_review, jamais deviner)**, correspondant à l’entrée requise du CRM, plus des critères d’acceptation observables — pas un prompt en prose « plus clair ». Les deux symptômes — dérive de format entre utilisateurs et domaines produits pollués — remontent aux deux lignes de contrat que l’on laisse le plus souvent vides : forme de sortie et comportement d’entrée manquante.
## Pièges de l’évaluation
| Piège | Pourquoi c’est tentant | Le discriminant |
| --- | --- | --- |
| « Reformuler le prompt pour qu’il soit plus clair » | Le prompting est le levier familier | La dérive de format et la devinette sont des lacunes de contrat ; fixer la forme de sortie et la règle d’entrée manquante |
| « Laisser l’étape deviner une valeur quand l’entrée manque » | Deviner paraît robuste | Deviner fabrique des données indétectables ; demander, défaut-et-marquer, ou échouer |
| « ‘Haute qualité’ est un bon critère d’acceptation » | Cela ressemble à une norme | Les critères doivent être observables/vérifiables, pas subjectifs |
| « La sortie a l’air bien, donc la forme est définie » | Un bon échantillon fait office de preuve | Une forme non fixée varie selon les entrées et les utilisateurs ; la spécifier explicitement |
| « Emballer le JSON dans une explication conviviale » | Le modèle est bavard | La prose autour du JSON casse les analyseurs ; renvoyer uniquement le JSON |
| « Un défaut silencieux garde les choses fluides » | Moins d’interruptions | Les défauts non marqués cachent les données manquantes à la revue ; toujours signaler un défaut |
## Questions d’entraînement
Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler.
A. Le modèle est trop petit
B. La forme de sortie n’est pas fixée dans le contrat de l’étape
C. La température est trop élevée
D. Le collègue a utilisé le mauvais compte
**Réponse : B.** Un format incohérent selon les entrées et les utilisateurs signifie que le contrat n’a jamais spécifié de forme de sortie ; fixer un schéma/gabarit le corrige. La taille du modèle (A) et la température (C) ne définissent pas la structure. Le compte (D) est sans rapport avec le format.
A. Modèle, température, max tokens, séquence d’arrêt
B. Entrées nommées, requis vs optionnel, forme de sortie, critères d’acceptation, comportement d’entrée manquante
C. Prompt, réponse, coût, latence
D. Déclencheur, responsable, échéance, budget
**Réponse : B.** Un contrat d’étape fixe ce qui entre, ce qui doit être présent, ce qui sort, ce que « bon » signifie, et ce qui se passe en cas d’entrée manquante. L’option A liste des réglages de modèle. L’option C liste des métriques d’observabilité. L’option D liste des champs de gestion de projet, pas un contrat.
A. Inventer des catégories plausibles pour continuer
B. Échouer bruyamment avec une raison claire, car elle ne peut pas catégoriser sûrement sans la liste
C. Renvoyer une chaîne vide silencieusement
D. Choisir la première catégorie par ordre alphabétique
**Réponse : B.** Sans défaut sûr et la justesse dépendant de la liste, l’étape doit échouer bruyamment plutôt que deviner. Inventer des catégories (A) fabrique des données indétectables. Une chaîne vide silencieuse (C) cache la défaillance. Un choix arbitraire (D) est une devinette déguisée.
A. « La synthèse est de haute qualité »
B. « La synthèse se lit de façon professionnelle »
C. « ≤ 200 mots, couvre les cinq points de l’ordre du jour, aucune affirmation absente de la source »
D. « La synthèse est exhaustive »
**Réponse : C.** Les critères d’acceptation doivent être des conditions vérifiables qu’une personne ou une étape peut contrôler. « Haute qualité » (A), « se lit de façon professionnelle » (B) et « exhaustive » (D) sont subjectifs et invérifiables.
A. Une explication conviviale suivie des données
B. Uniquement le JSON, avec des noms de champs, des types et des valeurs autorisées spécifiés, et aucune prose autour
C. Un paragraphe narratif
D. Le format que le modèle préfère
**Réponse : B.** La consommation par machine nécessite un schéma strict et uniquement le JSON pour que l’analyse soit fiable. La prose autour des données (A) et une narration (C) cassent les analyseurs. Laisser le modèle choisir (D) réintroduit la dérive.
A. L’étape 3 a besoin d’un modèle plus gros maintenant
B. La sortie de l’étape 2 ne correspond plus à l’entrée requise de l’étape 3 — un décalage de relais/contrat
C. La température a dérivé
D. L’étape 1 est cassée
**Réponse : B.** Modifier une étape change couramment sa forme de sortie, cassant le consommateur qui comptait sur l’ancien contrat ; revérifier les deux bords. La taille du modèle (A) et la température (C) ne sont pas impliquées. L’étape 1 (D) n’a pas été touchée.
A. Quand la justesse dépend entièrement de la valeur manquante
B. Quand un défaut sûr et documenté existe et que vous signalez que la valeur a été appliquée par défaut
C. Chaque fois que vous voulez éviter les interruptions
D. Jamais — toujours échouer
**Réponse : B.** Un défaut est approprié seulement quand il est sûr et documenté, et il doit être marqué pour que la revue voie que la valeur manquait. Si la justesse en dépend (A), échouer plutôt. Éviter les interruptions à tout prix (C) mène à la devinette silencieuse. « Toujours échouer » (D) est trop rigide quand un défaut sûr existe.
A. Forme de sortie / comportement en cas d’entrée manquante
B. La date de sortie du modèle
C. La correspondance du relais avec l’entrée requise de l’étape suivante
D. Le nombre de mots du prompt
E. La couleur de la sortie
**Réponse : A et C.** Une forme de sortie non fixée (avec un comportement d’entrée manquante indéfini) et des passages de relais non vérifiés sont les lacunes classiques qui rendent les workflows instables. La date de sortie (B), le nombre de mots (D) et la couleur de mise en forme (E) ne sont pas des lignes de contrat.
A. Demander au modèle d’être plus prudent
B. Contraindre la sortie à un ensemble énuméré `{positive, neutral, negative}` dans le schéma et ne renvoyer que cette structure
C. Augmenter max tokens
D. Ajouter plus d’exemples de bons e-mails
**Réponse : B.** Un ensemble de valeurs énuméré dans le schéma est ce qui force une des valeurs autorisées ; le texte libre signifie que l’ensemble de valeurs n’a jamais été contraint. « Être prudent » (A) n’est pas un contrat. Max tokens (C) est sans rapport. Plus d’exemples d’e-mails (D) ne contraignent pas l’énuméré de sortie.
A. Cela raccourcit le prompt
B. Le contrat est l’interface : il indique à un collègue exactement quelles entrées donner, quelle sortie attendre, et quand l’étape est terminée
C. Cela permet de sauter les critères d’acceptation
D. Cela supprime le besoin de revue
**Réponse : B.** Un contrat écrit est l’interface exécutable qu’un collègue suit pour obtenir le même résultat ; une étape non documentée ne vit que dans la tête de l’auteur. Il ne raccourcit pas les prompts (A), ne saute pas les critères (C), ni ne supprime la revue (D).
A. Définir une règle d’entrée manquante : si aucun produit n’est identifiable, produire `unknown` et signaler `needs_review`
B. Laisser le modèle continuer à deviner mais le journaliser
C. Contraindre product_area à la liste autorisée, avec `unknown` comme seul repli
D. Augmenter la température pour la variété
E. Supprimer entièrement le champ product_area
**Réponse : A et C.** Le remède est une règle explicite d’entrée manquante (unknown + drapeau de revue, jamais deviner) plus la contrainte du champ à la liste autorisée avec un seul repli sûr. Deviner-et-journaliser (B) pollue encore avec des valeurs fabriquées. La température (D) aggrave la variance. Supprimer le champ (E) abandonne une sortie requise.
A. Analyser la chaîne en aval et espérer que le format ne change jamais
B. Changer le contrat de sortie du producteur pour renvoyer `total` comme un nombre, correspondant à l’entrée requise du consommateur
C. Ajouter un modèle plus gros au consommateur
D. Demander au producteur d’être plus cohérent
**Réponse : B.** Le remède propre est d’aligner le contrat de sortie du producteur sur le type requis du consommateur — un nombre — plutôt qu’une analyse fragile en aval. Analyser-et-espérer (A) est fragile aux changements de format. Un modèle plus gros (C) ne corrige pas un décalage de type. « Être plus cohérent » (D) n’est pas un changement de contrat.
## À retenir
- Chaque étape est un **contrat** : entrées nommées, requis vs optionnel, forme de sortie, critères d’acceptation et comportement d’entrée manquante.
- **Fixer la forme de sortie** au consommateur — schéma pour les machines, gabarit pour les lecteurs, champs fixes pour le tri rapide — et renvoyer *uniquement* cette forme pour les sorties analysables.
- Les **critères d’acceptation doivent être observables** et vérifiables, pas « haute qualité » ; ils sont ce que les étapes de critique et les points humains vérifient.
- En cas d’entrée requise manquante, **demander, défaut-et-marquer, ou échouer bruyamment** — ne jamais laisser le modèle **deviner**.
- Un workflow est une chaîne de contrats : après avoir modifié une étape, **revérifier les deux bords du relais**.
- Le contrat écrit est l’**interface** qui permet à un collègue d’exécuter, versionner et améliorer le workflow — le pont vers les Domaines 5 et 6.
- Les deux lignes le plus souvent laissées vides — **forme de sortie** et **comportement d’entrée manquante** — sont la cause habituelle des workflows instables.