# Syntaxe des exigences EARS expliquée, avec exemples Canonical: https://specscore.md/fr/articles/ears-requirements/ Dernière mise à jour : 2 novembre 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) est une notation d’exigences : un petit ensemble de patrons de phrase en anglais, aussi appelé syntaxe EARS, qui garde une condition, un déclencheur et une réponse du système dans un ordre fixe. Une exigence est une obligation testable qu’un système doit satisfaire. Le [développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/) (SDD, spec-driven development) consiste à écrire cette obligation dans une spécification avant le code, et à traiter la spécification comme la source de vérité. Un document d’exigences produit (PRD, product requirements document) est la prose qui énonce le problème et le périmètre avant de découper le travail en tâches. Dans [SpecScore](https://specscore.md/), une exigence (REQ) est une règle nommée dans une fonctionnalité, et un critère d’acceptation (AC, acceptance criterion) est une condition abstraite facultative qui pointe vers une ou plusieurs de ces règles. L’[intégration continue](https://specscore.md/fr/validators/) (CI, continuous integration) est un contrôle automatique à chaque changement proposé. Ce contrôle est une commande de l’[interface en ligne de commande](https://specscore.md/fr/cli/) (CLI, command-line interface) : `specscore spec lint`. [Kiro](https://kiro.dev/), un environnement de développement intégré (IDE, integrated development environment) agentique d’Amazon Web Services (AWS), écrit l’un de ces patrons. La notation a été publiée pour la première fois par Alistair Mavin et des collègues de Rolls-Royce lors d’une conférence d’ingénierie des exigences de l’Institute of Electrical and Electronics Engineers (IEEE) en 2009. ## D’où vient EARS Alistair Mavin, Philip Wilkinson, Adrian Harwood et Mark Novak, alors chez Rolls-Royce PLC, ont publié « Easy Approach to Requirements Syntax (EARS) » à la 17th IEEE International Requirements Engineering Conference en 2009. L’identifiant du document est [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9). Ils ont construit les règles en extrayant des exigences de commande moteur de la Certification Specification for Engines (CS-E), section CS-E 50, un règlement de navigabilité. Ce texte mêlait exigences, conseils de conception et notes. L’article nomme huit problèmes du langage naturel non contraint : ambiguïté, flou, complexité, omission, duplication, verbosité, implémentation inappropriée et intestabilité. Un petit jeu de règles devait permettre à chaque exigence d’utiliser l’un de cinq modèles. Les auteurs disent que la notation convient aux exigences de parties prenantes de haut niveau, et ils ne prétendent pas couvrir chaque niveau de décomposition d’un système. Le [guide de Mavin](https://alistairmavin.com/ears/) décrit EARS comme une façon de contraindre doucement les exigences textuelles. Les clauses restent dans un ordre, qu’il appelle logique temporelle : toute précondition, puis le déclencheur, puis le nom du système et la réponse. Son jeu de règles est zéro ou plusieurs préconditions, zéro ou un déclencheur, un nom de système, et une ou plusieurs réponses. L’article de 2009 spécialise cette forme en cinq modèles. Le même guide nomme aussi les exigences complexes, qui combinent les mots-clés. Dans l’étude de cas de l’article, l’extrait brut contenait 36 exigences et l’ensemble réécrit 47. La longueur moyenne est passée de 36,9 à 25,6 mots. Les auteurs rapportent que, dans cette étude, complexité, omission, duplication, implémentation inappropriée et intestabilité étaient absentes de l’ensemble réécrit, tandis que ambiguïté, flou et verbosité ont diminué sans disparaître. Ils listent aussi les limites : un petit échantillon, seulement des exigences de sûreté de haut niveau, et un jugement dans le classement du flou. Ces chiffres sont ceux de l’article, pour ce seul document. ## Les patrons de phrase EARS Les mots-clés sont ceux de l’article de 2009 et du guide de Mavin. L’article permet aussi *During* à la place de *While* pour un état, avec le même sens, quand cela se lit plus clairement. Les phrases d’exemple illustrent les modèles. Ce ne sont pas des citations de l’article. Kiro écrit le patron piloté par événement en capitales ; la notation d’origine utilise une capitale initiale. Les exemples restent en anglais parce que la syntaxe EARS est anglaise. ### Ubiquitaire `The shall ` Toujours actif. Il n’y a pas de mot-clé EARS, parce qu’il n’y a ni précondition ni déclencheur. L’illustration de l’article de 2009 est un système de commande qui doit empêcher la survitesse du moteur. **Exemple:** The checkout system shall keep the order total equal to the sum of its line items. ### Piloté par événement `When , the shall ` La réponse est exigée quand un déclencheur est détecté à la frontière du système, et seulement alors. Le mot-clé est *When*. **Exemple:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### Piloté par état `While , the shall ` La réponse est exigée tant que le système reste dans l’état nommé. Le mot-clé est *While*. **Exemple:** While the cart is empty, the checkout system shall keep the pay button disabled. ### Comportement indésirable `If , then the shall ` La réponse traite une panne, une perturbation, un écart ou un autre comportement indésirable. Les mots-clés sont *If* et *then*. L’article a donné à ce patron ses propres mots-clés pour que ces exigences restent visibles. Les auteurs notent que souhaité et indésirable est parfois une question de point de vue. **Exemple:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### Fonction facultative `Where , the shall ` La réponse ne s’applique que si le produit inclut la fonction nommée. Le mot-clé est *Where*. **Exemple:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### Complexe `While , when , the shall ` Plus d’un mot-clé. Le guide de Mavin garde le même ordre de clauses : *While* pour la précondition, puis *When* pour le déclencheur, puis la réponse du système. L’article de 2009 combine aussi *While* avec *If / then* pour un comportement indésirable dans un état. Une illustration de cette combinaison : While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **Exemple:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## Erreurs courantes ### Plusieurs obligations dans une phrase L’article traite une phrase composée comme le problème de complexité et la découpe. La [spécification d’exigence SpecScore](https://specscore.md/requirement-specification) dit la même chose dans ses termes : chaque `REQ` doit exprimer exactement une obligation testable. ### Cacher le comportement indésirable dans When *When* sert à un déclencheur attendu. *If / then* sert au comportement que l’on préférerait ne pas rencontrer. Un seul mot-clé pour les deux fait ressembler le cas indésirable au cas normal, ce qui est le problème d’omission que l’article signale. ### Écrire l’implémentation « The checkout system shall store the flag in Redis » nomme une conception. L’article appelle cela une implémentation inappropriée. La réponse doit dire ce que le système doit obtenir, pas quel composant le fait. ### Pas de nom de système « When the form is submitted, shall show an error » n’a pas de sujet. Le jeu de règles de Mavin exige un nom de système. ### Déclencheur après la réponse « The checkout system shall show an error when the form is submitted » place le déclencheur à la fin. L’ordre publié est précondition, puis déclencheur, puis réponse. ### Prendre la ligne de Kiro pour tout EARS La page de spécifications de fonctionnalité de Kiro publie un seul patron, `WHEN … THE SYSTEM SHALL …`. L’ubiquitaire, *While*, *If / then*, *Where* et les combinaisons complexes font partie de la notation dans l’article et dans le guide de Mavin. Ils ne sont pas sur cette page Kiro. ## Comment Kiro utilise EARS La [page des spécifications de fonctionnalité de Kiro](https://kiro.dev/docs/specs/feature-specs/), marquée mise à jour le 4 août 2026 et lue le 2 novembre 2026, dit que le fichier `requirements.md` utilise EARS. Le patron imprimé est `WHEN [condition/event]` suivi de `THE SYSTEM SHALL [expected behavior]`. L’exemple de la page : WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. La [page exigences d’abord](https://kiro.dev/docs/specs/feature-specs/requirements-first/) dit qu’un `requirements.md` généré inclut des user stories avec des critères d’acceptation et des comportements système dans la même forme WHEN … THE SYSTEM SHALL …. Son exemple d’inscription est trois phrases : des données d’inscription valides créent un compte, un e-mail déjà présent affiche « Email already registered », et un format d’e-mail invalide affiche une erreur de validation. Avant la conception, Analyze Requirements cherche des incohérences logiques, des ambiguïtés, des contraintes en conflit et des manques. La page des spécifications de fonctionnalité dit qu’on le choisit dans les options du chat ou le menu Continue de l’éditeur après la génération des exigences. `design.md` et `tasks.md` sont à côté des exigences. Quick Spec enchaîne exigences, conception et tâches sans arrêt d’approbation entre elles. Cette analyse est une étape dans Kiro. La page ne la décrit pas comme un linter de format à ajouter à sa propre CI. La façon dont les autres outils vérifient une spécification est dans le [guide des outils](https://specscore.md/fr/spec-driven-development/tools/). La comparaison des deux produits est [SpecScore vs Kiro](https://specscore.md/fr/vs/kiro/). ## La même exigence dans SpecScore SpecScore ne vérifie pas qu’une phrase correspond à un modèle EARS. `specscore spec lint`, du dépôt [specscore-cli](https://github.com/specscore/specscore-cli), vérifie la structure. Son aide nomme les fichiers README, les sections Open Questions, les niveaux de titre, les références de fonctionnalités, les liens internes et les entrées d’index. Une phrase EARS peut être la prose sous un titre `REQ`. Le linter ne note pas l’anglais. La [spécification d’exigence](https://specscore.md/requirement-specification) place chaque exigence sous un titre de sujet dans `## Behavior`, un niveau plus bas, en général `#### REQ: slug`. Le slug utilise des lettres minuscules, des chiffres et des traits d’union. L’identifiant est `{feature-path}#req:{slug}`. La spécification dit qu’une exigence devrait utiliser les mots-clés du RFC 2119 (Request for Comments 2119) : MUST, MUST NOT, SHOULD, SHOULD NOT et MAY. Dans la correspondance ci-dessous, le *shall* d’EARS s’écrit MUST. Un [critère d’acceptation](https://specscore.md/acceptance-criteria-specification) est facultatif. Quand on en utilise un, c’est `### AC: slug` dans `## Acceptance Criteria`, et la ligne suivante est `**Requirements:**` avec ces identifiants. La spécification des critères d’acceptation dit que l’AC énonce une condition abstraite et ne doit pas contenir d’étapes Given/When/Then, d’entrées concrètes ni de détail d’implémentation. Un flux concret est un [scénario](https://specscore.md/scenario-specification) dans le répertoire `_tests/` de la fonctionnalité. La [spécification de fonctionnalité](https://specscore.md/feature-specification) exige aussi un statut, un résumé, un problème, le comportement, des critères d’acceptation, des questions ouvertes et un pied d’adhérence. Les fichiers ci-dessous sont une fonctionnalité de paiement. `show-field-error` est l’exemple piloté par événement. `reject-invalid-email` est l’exemple de comportement indésirable. Le 2 novembre 2026, `specscore spec lint` a signalé 0 violations pour cet arbre avec specscore 0.55.1, la dernière version publiée le 30 octobre 2026, et avec specscore 0.39.1, la version épinglée dans [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Le [dépôt du format](https://github.com/specscore/specscore) est l’endroit de ce flux. ### spec/features/checkout/README.md ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### spec/features/README.md — la cellule de description est la phrase de résumé de la fonctionnalité. La règle feature-index-row-sync du linter a rejeté une description plus courte. ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### spec/README.md — retirer la section Open Questions a produit oq-section: Open Questions section not found. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org et project.repo sont les valeurs confrontées à la ligne studio-toolbar. Sans elles, le linter a signalé studio-toolbar: studio toolbar requires project host/org/repo. ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` Deux autres erreurs sont apparues en faisant passer cet exemple, et les deux sont corrigées dans les fichiers ci-dessus. Une fonctionnalité sans `**Source Ideas:**` a échoué sur `feature-source-ideas-required` ; `—` est la valeur vide. L’index des fonctionnalités avait aussi besoin du champ d’en-tête `format: https://specscore.md/features-index-specification`. Le succès du linter signifie que les fichiers respectent ces règles de structure. Il ne signifie pas que les phrases sont du bon EARS, ni que le produit de paiement existe. Le Given/When/Then de ce comportement serait un fichier de scénario sous `spec/features/checkout/_tests/`, pas un autre paragraphe dans l’AC. ## Questions ### Que signifie EARS ? Easy Approach to Requirements Syntax. C’est un ensemble de patrons de phrase pour les exigences, publié par Alistair Mavin, Philip Wilkinson, Adrian Harwood et Mark Novak de Rolls-Royce à la 17th IEEE International Requirements Engineering Conference en 2009, et décrit sur le site de Mavin. ### La notation de Kiro est-elle tout EARS ? La page de spécifications de fonctionnalité de Kiro fixe un patron : WHEN … THE SYSTEM SHALL …. L’article de 2009 et le guide de Mavin définissent aussi les exigences ubiquitaires, While piloté par état, If/then pour le comportement indésirable, Where pour une fonction facultative, et les combinaisons complexes de ces mots-clés. ### SpecScore valide-t-il la syntaxe EARS ? Non. `specscore spec lint` valide la structure des fichiers SpecScore. Une phrase EARS peut être la prose d’un `REQ`. Le linter ne note pas l’anglais. ### Où vont les exemples Given/When/Then ? Dans un scénario sous le répertoire `_tests/` de la fonctionnalité. Un critère d’acceptation reste une condition abstraite et, dans la spécification des critères d’acceptation, ne doit pas contenir d’étapes Given/When/Then. ## Sources Lu le 2 novembre 2026, sauf lorsqu’une page imprime sa propre date de mise à jour. La page de spécifications de fonctionnalité de Kiro indique une mise à jour le 4 août 2026. - [Mavin, Wilkinson, Harwood et Novak — Easy Approach to Requirements Syntax (EARS), 17th IEEE International Requirements Engineering Conference, 2009, DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Alistair Mavin — guide EARS](https://alistairmavin.com/ears/) - [Documentation Kiro — spécifications de fonctionnalité et EARS (page mise à jour le 4 août 2026)](https://kiro.dev/docs/specs/feature-specs/) - [Documentation Kiro — flux exigences d’abord](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — spécification d’exigence](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — spécification des critères d’acceptation](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — spécification de scénario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — spécification de fonctionnalité](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — flux CI dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) ## Liens - [Modèle de PRD en Markdown pour coder avec l’IA](https://specscore.md/fr/articles/feature-spec-template/) - [Linter des spécifications en CI avec un linter de spécifications](https://specscore.md/fr/articles/lint-specs-in-ci/) - [Comment écrire des critères d'acceptation qu'un agent d'IA peut vérifier](https://specscore.md/fr/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/fr/vs/kiro/) - [Outils de développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/tools/) - [Développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/) - [Spécification d’exigence](https://specscore.md/requirement-specification) - [Spécification des critères d’acceptation](https://specscore.md/acceptance-criteria-specification) - [Spécification de fonctionnalité](https://specscore.md/feature-specification) - [Validateurs et CI](https://specscore.md/fr/validators/)