Qu'est-ce qu'un audit d'exigences ? Couverture et dérive

Un audit d'exigences compare les exigences qu'une équipe a validées, figées à la signature en ligne de base, avec le travail qui existe réellement. Pour chaque exigence, il rapporte la couverture : y a-t-il du travail en face, et est-il terminé ? Il rapporte aussi la dérive : les exigences dont la formulation a changé, ou qui ont été supprimées, après validation. Il ne lit pas le code source.

Voilà toute l'idée en un paragraphe. La suite explique pourquoi les équipes en ont besoin, déroule un exemple concret d'un PRD qui s'éloigne de ce qui a été livré, montre en quoi il diffère d'un scan de code, et finit par la façon d'en mener un, à la main ou avec un outil.

Pourquoi « qu'avons-nous convenu de construire ? » est une question difficile

Toute équipe peut dire combien de tâches sont ouvertes. Très peu peuvent dire, exigence par exigence, si ces tâches ouvertes correspondent à ce qui a été promis. Les deux informations vivent à des endroits différents. Les exigences sont dans un PRD, une proposition, un contrat ou une page Notion écrite il y a des mois. Le travail est dans un outil de suivi, découpé en issues nommées par celui qui les a prises. Personne ne relie les deux, et l'écart entre eux reste invisible jusqu'à ce qu'un client, un lancement ou une nouvelle recrue le découvre.

L'écart se creuse de trois manières :

Omission. Une exigence a été validée et n'est jamais devenue du travail. Elle n'est pas dans le backlog, donc aucun tableau ne la montre en retard.
Reformulation discrète. Une exigence a été modifiée après validation, en général pour coller à ce qui était plus facile à construire. Le document vivant dit désormais que la livraison « passe », et la formulation d'origine a disparu.
Suppression silencieuse. Une exigence a été effacée. Le document est plus court, et personne n'a décidé qu'il devait l'être.

Un audit d'exigences rend les trois visibles. L'entrée du glossaire en donne la définition formelle ; on parle aussi d'audit de traçabilité des exigences ou de couverture des exigences.

Les trois parties : ligne de base, couverture, dérive

Ligne de base. Une ligne de base d'exigences est une copie figée et numérotée des exigences au moment de leur validation : identifiant, formulation, priorité et critères d'acceptation pour chacune. Le document vivant continue de changer ; la ligne de base, non. L'entrée sur la ligne de base détaille la pratique. Sans ligne de base, il n'y a rien à auditer, parce que la seule version des exigences est celle qui a déjà dérivé.

Couverture. Pour chaque exigence de la ligne de base, quel est l'état du travail derrière elle ? Un audit utile distingue au moins ces états :

État	Signification	Ce que cela signale en général
Aucun travail	Rien dans l'outil de suivi ne pointe vers cette exigence	Validée puis oubliée
En cours	Du travail lié existe et n'est pas terminé	Sur les rails, ou bloqué ; vérifier les dates
Travail terminé	Toutes les tâches liées sont closes	Prêt à vérifier contre les critères d'acceptation
Abandonnée depuis	L'exigence a été retirée du document vivant après la ligne de base	Une décision de périmètre, consignée ou non
Enregistrement disparu	L'enregistrement de l'exigence a été supprimé	Quelqu'un a fait le ménage ; était-ce convenu ?

Une exigence dont les seules tâches ont toutes été annulées n'a aucun travail, même après trois tentatives, et un audit honnête dit les deux choses.

Dérive. La dérive compare la formulation de la ligne de base à celle d'aujourd'hui. Si le texte d'une exigence a changé après le gel, l'audit le signale et montre les deux versions. Rapporter la couverture contre la nouvelle formulation tout en prétendant évaluer la ligne de base serait trompeur ; un bon audit mesure toujours contre le texte figé et affiche le texte vivant à côté.

Un exemple concret : le PRD disait une chose, la livraison en a fait une autre

Un cas petit et réaliste. Une équipe de quatre personnes valide un PRD pour un portail client avec quatorze exigences et le fige en ligne de base 1 le 2 septembre. Le lancement est le 30 octobre. Deux semaines avant, quelqu'un lance l'audit.

Onze exigences sont en cours ou terminées. Trois ne le sont pas :

REQ-006, « Les clients peuvent exporter leurs factures en CSV et en PDF. » Couverture : travail terminé. Dérive : signalée. La formulation vivante dit désormais « Les clients peuvent exporter leurs factures en CSV ». La moitié PDF a été abandonnée quand le développeur a trouvé la bibliothèque PDF pénible, et l'exigence a été modifiée pour coller. Personne n'a prévenu le client qui avait demandé le PDF.
REQ-009, « Les administrateurs reçoivent un e-mail quand un client conteste une facture. » Couverture : aucun travail. Validée, personne n'a créé d'issue, et le backlog n'a aucune ligne pour elle. Tous les tableaux étaient au vert parce qu'un tableau ne connaît que les issues qui existent.
REQ-013, « Le portail est disponible en deux langues au lancement. » Couverture : abandonnée depuis. Retirée du PRD vivant la troisième semaine lors d'une discussion de périmètre tenue dans le chat. La décision était peut-être la bonne ; sa trace est un message que personne ne retrouve.

Rien de tout cela n'apparaîtrait dans une revue de sprint. REQ-006 a été démontrée et semblait finie. REQ-009 n'a jamais existé en tant que tâche. REQ-013 avait discrètement cessé d'être une exigence. L'audit a transformé trois écarts invisibles en trois décisions : créer le travail pour REQ-009, rétablir ou renégocier formellement REQ-006, et consigner la décision sur REQ-013 pour que la ligne de base 2 la porte.

C'est aussi pourquoi l'audit doit se calculer à partir d'enregistrements, pas de la lecture du projet par un modèle. Un modèle de langage à qui l'on demande « REQ-009 est-elle couverte ? » cherchera quelque chose qui ressemble à des notifications par e-mail et pourra trouver une issue liée aux reçus. Une couverture calculée à partir de liens explicites entre exigences et issues donne un simple « aucun travail », qui est la réponse dont l'équipe avait besoin.

Audit d'exigences, scan de code et revue de code

Les gens entendent « audit » et pensent à un scanner qui lit du code source. C'est une activité différente, avec une question différente.

	Audit d'exigences	Scan de code (analyse statique)	Revue de code
Question	Avons-nous construit ce qui était convenu ?	Le code est-il sain ?	Ce changement est-il bon ?
Entrée	Exigences de la ligne de base et éléments de travail liés	Code source	Une pull request
Lit le code	Non	Oui	Oui
Trouve	Omissions, reformulations, retraits de périmètre silencieux	Bugs, vulnérabilités, mauvais motifs	Erreurs locales, problèmes de conception et de style
Rate	Si le travail terminé respecte vraiment les critères	Les promesses absentes du code	Les problèmes répartis sur de nombreux changements
Livrable	Couverture et dérive par exigence	Constats par fichier ou par ligne	Approbation ou changements demandés

Les trois ne se remplacent pas. Une base de code peut passer tous les scans et manquer la fonctionnalité qu'un client a payée. Un audit d'exigences peut montrer toutes les exigences couvertes et laisser passer une faille de sécurité. Les équipes qui tiennent aux deux font les deux.

Deux précautions gardent un audit d'exigences honnête. D'abord, « travail terminé » n'est pas « exigence satisfaite ». Une issue close prouve que quelqu'un a fini une tâche, pas que le résultat respecte les critères d'acceptation ; une personne doit encore vérifier. Ensuite, l'audit vaut ce que valent les liens. Si les issues ne sont pas rattachées aux exigences, chaque exigence affiche « aucun travail », ce qui ne sert à rien. Relier est le coût initial, et c'est le même coût qui rend l'audit possible.

Comment mener un audit d'exigences à la main

Pas besoin d'outil. Il faut de la discipline et un tableur.

Figez la ligne de base. Copiez les exigences validées dans une feuille avec un identifiant stable par ligne (REQ-001, REQ-002), la formulation exacte, la priorité et les critères d'acceptation. Datez-la et notez qui l'a validée. Ne modifiez plus cette feuille.
Reliez le travail aux exigences. Dans votre outil de suivi, donnez à chaque issue un champ ou une étiquette nommant l'exigence qu'elle sert. Un nouveau travail sans identifiant d'exigence est un bug, une corvée ou du périmètre ajouté ; décidez lequel.
Calculez la couverture. Pour chaque ligne REQ, listez ses issues et leurs statuts. Attribuez un état d'après le tableau ci-dessus. Comptez d'abord les lignes sans travail ; cette liste est le principal constat de l'audit.
Vérifiez la dérive. Placez le document vivant des exigences à côté de la feuille figée. Marquez chaque ligne dont la formulation diffère et chaque ligne absente de la version vivante.
Écrivez les décisions. Pour chaque écart : créer du travail, renégocier, ou abandonner formellement. Consignez les abandons avec un motif, puis figez la ligne de base 2.
Recommencez aux jalons. Avant une revue client, un lancement, une facture ou une passation. Une fois par mois suffit pour la plupart des petites équipes.

La version manuelle fonctionne. Sa faiblesse est l'étape 2 : les liens se dégradent dès que les gens sont occupés, et une feuille que personne ne met à jour produit un audit auquel personne ne fait confiance.

Comment les outils s'y prennent, et ce que fait Atrix

Plusieurs outils de gestion des exigences destinés aux industries réglementées font de la traçabilité depuis des décennies, en général sous forme de matrice d'exigences contre tests et tâches. Ils sont conçus pour l'aéronautique, le médical et l'automobile, et tarifés en conséquence.

Pour les petites équipes produit, la version pratique est un outil de suivi qui garde exigences et issues au même endroit et entretient les liens pour vous. C'est ce que nous avons intégré à Atrix pour nos propres projets, et il vaut la peine d'être précis sur ce qu'il fait. Le run Develop de l'agent rédige les exigences à partir d'un brief ; vous les modifiez et les validez, et le mode Audit fige une ligne de base. Dès lors, l'audit rapporte les cinq états ci-dessus pour chaque exigence de la ligne de base, avec un indicateur de dérive et la formulation vivante quand elle a changé. Chaque état est calculé à partir de lignes, pas du jugement d'un modèle, donc l'audit ne consomme aucun run d'IA et donne deux fois la même réponse. Les projets GitHub et Vercel liés ajoutent à côté des signaux de dépôt et de déploiement.

Ce qu'il ne fait pas compte tout autant. Atrix ne scanne pas le code, ne fait pas d'analyse statique et ne trouve pas de vulnérabilités, et la page de la fonctionnalité le dit. S'il vous faut un audit de code, c'est un autre service, et chez nous ce sont les auditeurs humains de l'agence, pas le produit. S'il vous faut savoir si la livraison correspond à l'accord, c'est le travail du produit.

FAQ

Quelle différence entre un audit d'exigences et un audit de code ?

Un audit d'exigences compare les exigences convenues au travail qui existe et rapporte couverture et dérive. Un audit de code examine le code source par rapport à un référentiel pour les bugs, la sécurité et la qualité. Le premier répond à « avons-nous construit ce qui était convenu ? » ; le second à « le code est-il sain ? ». Aucun ne remplace l'autre.

Qu'est-ce que la traçabilité des exigences ?

La traçabilité est l'ensemble des liens de chaque exigence vers le travail, les tests ou le code qui la mettent en œuvre, et retour. Un audit d'exigences en dépend : sans liens des issues vers les exigences, la couverture ne peut pas être calculée.

Qu'est-ce que la dérive de périmètre ?

La dérive de périmètre, ou dérive des exigences, est le changement progressif de ce qu'un projet doit livrer sans décision explicite : exigences reformulées pour coller à la livraison, abandonnées discrètement, ou ajoutées sans validation. Un audit la détecte en comparant une ligne de base figée aux exigences vivantes.

À quelle fréquence auditer les exigences ?

Aux jalons plutôt qu'à date fixe : avant une revue client, un lancement, une passation ou une facture importante. Les équipes qui tiennent leurs liens à jour peuvent auditer à la demande en quelques minutes ; celles qui le font à la main y arrivent en général une fois par mois.

Une tâche terminée signifie-t-elle que l'exigence est satisfaite ?

Non. Une tâche close montre que quelqu'un a fini un travail, pas que le résultat respecte les critères d'acceptation. Un bon audit étiquette cet état « travail terminé » et laisse la vérification contre les critères à une personne.

L'IA peut-elle mener un audit d'exigences ?

L'IA peut rédiger et affiner des exigences, et aider à y relier du travail. L'audit lui-même doit être calculé à partir d'enregistrements, parce que l'avis d'un modèle sur ce qui est « couvert » varie d'une exécution à l'autre et ne peut pas être défendu devant un client. Atrix utilise l'agent pour écrire les exigences et des données brutes pour calculer l'audit.

Prochaine étape

Commencez par la définition et les états dans l'entrée du glossaire sur l'audit d'exigences, puis figez votre première ligne de base. Si vous voulez que les liens et l'audit soient entretenus pour vous, l'audit d'exigences dans Atrix le fait à partir de vos propres issues.

Qu'est-ce qu'un audit d'exigences ? Couverture, dérive et exemple concret