Aller au contenu principal
  • Cours pratique
  • Informatique

Formation Spécifier pour les agents IA : la notation EARS

Rédiger des exigences qu'un agent de code ne peut pas mal interpréter

Voir les sessionsDemander un devis
Une formatrice accompagne deux participants penchés sur leurs notes, en salle de formation
Durée
2 jours
Niveau
Fondamental
Modalités
Distanciel

Description de la formation notation EARS

Les agents de code produisent aujourd'hui du logiciel plus vite que les organisations ne savent décrire ce qu'elles attendent. Le goulot d'étranglement s'est déplacé : la question n'est plus « l'agent sait-il coder ? » mais « l'agent sait-il quoi construire ? ». Le symptôme porte un nom, la dérive : du code livré vite, cohérent en apparence, qui résout confortablement le mauvais problème. Dans une démarche de Spec-Driven Development (SDD), la spécification devient l'artefact le plus rentable qu'un humain puisse produire : elle est versionnée dans le dépôt au même titre que le code, et c'est elle qui pilote l'implémentation. Les métiers de la maîtrise d'ouvrage y retrouvent une position centrale, à condition d'écrire autrement. Une exigence rédigée en prose libre laisse à l'agent le soin de combler les vides ; il les comble toujours, et rarement comme prévu. Cette formation enseigne la notation EARS (Easy Approach to Requirements Syntax), issue de l'ingénierie des exigences en contexte critique et devenue la référence des démarches pilotées par la spécification. Cinq gabarits de phrase, des mots-clés en position fixe : la contrainte de forme oblige à trouver l'information manquante au moment de l'écriture plutôt que six semaines plus tard, et rend chaque exigence traçable vers un test. Aucune ligne de code n'est écrite pendant ces deux jours, et aucun outil d'intelligence artificielle n'est manipulé. C'est une formation de rédaction rigoureuse.

Atelier en salle : une participante présente des notes au tableau

Objectifs pédagogiques

À l'issue de cette formation Spécifier pour les agents IA : la notation EARS, vous aurez acquis les connaissances nécessaires pour :

  • Situer le rôle de la spécification dans une démarche de Spec-Driven Development
  • Rédiger des exigences selon les cinq patterns de la notation EARS
  • Détecter et corriger les formulations ambiguës, incomplètes ou non testables d'une exigence existante
  • Arbitrer entre notation EARS et scénarios Gherkin selon la nature de ce qui est exprimé
  • Formuler les exigences non fonctionnelles, les contraintes et le périmètre exclu comme bornes du travail de l'agent
  • Établir et vérifier la traçabilité entre exigence, critère d'acceptation et test
  • Organiser le cycle de vie d'une spécification versionnée aux côtés du code

Objectifs opérationnels

Savoir rédiger et structurer des exigences en notation EARS, exploitables par une équipe de développement comme par un agent de code, et en maintenir la traçabilité vers les tests.

Programme

Contenu du cours

Jour 1 — Écrire une exigence qu'une machine ne peut pas mal interpréter

Introduction : Ce que l'IA change dans le travail de spécification

Le nouveau goulot d'étranglement du développement logiciel
Que lit un agent IA et qu'est-ce qu'il invente 
La dérive : comment du code conforme à la lettre d'une exigence peut être faux
Pourquoi la maîtrise d'ouvrage redevient centrale, A quelle condition

Anatomie d'une spécification exploitable

Les composants attendus : contexte métier, glossaire du domaine, exigences fonctionnelles, exigences non fonctionnelles, périmètre exclu
Le rôle des user stories : point de départ de la conversation, pas support de la spécification
Critères d'acceptation : ce qui distingue un critère d'une intention

La notation EARS

Origine et raison d'être : l'ingénierie des exigences en contexte critique
Les différents patterns ubiquitaire, événementiel, d'état, comportement indésirable, ..
Les exigences complexes : combinaison de pattern
Les confusions les plus fréquentes 

Atelier : Convertir un dossier existant en EARSObjectif : Savoir appliquer les cinq patterns EARS sur du matériau réel et constater que la contrainte de forme révèle les informations manquantes.Descriptif : Les participants reçoivent une vingtaine d'exigences du dossier fil rouge, rédigées en prose. Ils doivent les convertir en EARS, en identifiant pour chacune le pattern approprié. 

Traquer l'ambiguïté

Le vocabulaire ambigu
Les pièges de structure 
Les exigences non testables 

Atelier  : Chasse à l'ambiguïté Objectif : Savoir repérer mécaniquement les formulations qu'un agent interprétera librement, et les réécrire sans attendre d'arbitrage extérieur quand c'est possible.Descriptif: Chaque binôme reçoit un extrait de dossier différent et applique une grille de relecture construite collectivement en séance.Jour 2 — Structurer, borner, faire vivre

EARS ou Gherkin : choisir la notation

Règle générale contre l'exemple concret
Coût caché d'un scénario Gherkin
Grille de décision applicable à un lot d'énoncés hétérogène
Articulation entre les deux dans un même dossier de spécifications

Atelier : Répartir un lot d'énoncés entre EARS et GherkinObjectif : Savoir choisir la notation en fonction de la nature de ce qui est exprimé, et cesser de traiter une notation unique comme le format universel de la spécification.Descriptif : Les participants reçoivent un lot mixte d'une trentaine d'énoncés issus du fil rouge, ils répartissent chaque énoncé entre EARS, Gherkin, ou aucun des deux.

Borner le travail de l'agent

Exigences non fonctionnelles : performance, sécurité, accessibilité, observabilité — les formuler en EARS
Contraintes techniques et organisationnelles imposées au projet
Le périmètre exclu comme exigence de plein droit : ce que le système ne doit pas faire
Les décisions structurantes et leur justification : pourquoi une décision non écrite est une décision perdue

Traçabilité et couverture

La chaîne exigence → critère d'acceptation → test
Identifier et référencer une exigence de manière stable
Vérifier la couverture : quelles exigences ne sont vérifiées par rien
Gérer l'évolution : amender une exigence sans casser la traçabilité

La revue de spécification assistée par IA

Faire critiquer sa propre spécification : ambiguïtés, contradictions, cas non traités
La technique la plus utile : demander à l'assistant de poser les questions plutôt que d'y répondre
Faire produire des contre-exemples et des cas limites
Les limites de l'exercice : ce que l'assistant ne verra jamais faute de connaître le métier

Atelier 4 : Faire relire sa spécification par un assistant IAObjectif :  Savoir utiliser un assistant IA comme relecteur exigeant sans lui déléguer la décision métier, et mesurer ce qu'il détecte réellement.Descriptif :  Chaque binôme soumet la section du dossier qu'il a réécrite au cours des ateliers précédents à un assistant conversationnel, avec trois consignes successives : lister les ambiguïtés restantes, poser les questions auxquelles la spécification ne répond pas, puis produire des cas limites non couverts.

Faire vivre une spécification versionnée

Pourquoi la spécification rejoint le dépôt de code : historique, revue, proximité avec l'implémentation
Organisation des fichiers et granularité utile
Qui est propriétaire de la spécification, qui la met à jour, à quel moment
Le point de vigilance permanent : la spécification qui ne suit plus le code redevient une documentation morte

Synthèse et suites

Où se situe cette pratique dans une démarche de Spec-Driven Development
Ce qui se joue côté équipe technique, et comment dialoguer avec elle

Travaux pratiques

Fil rouge unique sur les deux jours : la refonte du module de réservation d'un service interne, fourni sous la forme d'un dossier de spécifications rédigé en prose libre, réaliste et volontairement imparfait.

Programme mis à jour le 19/08/2026

Formations liées