# Matrice de traçabilité des exigences : quelles colonnes, quels contrôles, quel modèle

Source : https://consignestudio.fr/guides/matrice-de-tracabilite-des-exigences/ · publié le 2026-10-27 · Antoine Despres, Consigne

Une matrice de traçabilité des exigences relie chaque exigence à son origine, à ses exigences filles et aux vérifications qui prouvent qu'elle est satisfaite. Elle tient en quelques colonnes : identifiant, niveau, énoncé, source, parents, méthode de vérification, vérifications liées, résultat et preuve. Sa valeur vient des contrôles qu'on en tire : rien d'oublié en descendant, rien d'ajouté sans raison en remontant.

## À quoi sert une matrice de traçabilité

Quel que soit le référentiel (un cahier des charges industriel, une spécification technique de besoin, DO-178C, EN 50128 ou IEC 61508), la personne qui relit votre matrice cherche à répondre à cinq questions :

| Question | Ce qui est attendu |
|---|---|
| D'où vient chaque exigence ? | Un paragraphe du document client, ou une exigence de niveau supérieur. Sinon, elle est dérivée et cette décision est justifiée. |
| Chaque besoin est-il pris en compte ? | Chaque exigence d'un niveau non terminal est déclinée en exigences filles, ou porte une justification. |
| Chaque exigence est-elle vérifiée ? | Une méthode est choisie, au moins une vérification est liée et son résultat est connu. |
| Où est la preuve ? | Chaque résultat conforme renvoie à une pièce identifiable, avec sa version. |
| Que se passe-t-il quand ça change ? | On sait quelles exigences filles et quels essais une modification remet en cause. |

Une matrice qui ne permet pas de répondre à l'une de ces questions en quelques secondes n'est pas encore prête pour une revue.

## Les colonnes indispensables

Le plus simple et le plus robuste : **une exigence par ligne** dans un registre, et **une vérification par ligne** dans un second onglet. La matrice croisée exigences × vérifications se déduit de ces deux listes ; on ne la saisit pas à la main.

### Le registre des exigences

| Colonne | Contenu |
|---|---|
| ID | Identifiant unique et stable, jamais réutilisé, même après suppression |
| Niveau | Besoin client, système, sous-système, logiciel, matériel… |
| Titre et énoncé | Le titre sert à la lecture ; l'énoncé est l'exigence elle-même |
| Type | Fonctionnelle, performance, interface, sécurité… ou Information |
| Source | Document et paragraphe d'origine, indispensable au niveau le plus haut |
| Parents | Identifiants des exigences de niveau supérieur, séparés par un point-virgule |
| Dérivée, justification | Oui si l'exigence naît d'un choix de conception, avec sa justification |
| Méthode | Inspection, analyse, démonstration ou test |
| Statut, révision | Pour savoir ce qui a changé et quand |

### Le registre des vérifications

| Colonne | Contenu |
|---|---|
| ID de la vérification | Essai, analyse, inspection ou démonstration |
| Exigences couvertes | Les identifiants vérifiés, séparés par un point-virgule |
| Méthode et niveau d'essai | Unitaire, intégration, système, recette usine, recette site, qualification |
| Résultat | Non exécutée, conforme, partielle, non conforme |
| Référence de preuve | Procès-verbal ou rapport, avec son indice |
| Date et configuration testée | Sur quelle version du produit l'essai a été joué |

> Ne supprimez jamais une ligne d'exigence : passez-la au statut « supprimée ». Une exigence fille dont le parent a disparu ou a été renuméroté est l'un des constats les plus fréquents en revue.

Les informations qui ne sont pas des exigences (définitions, contexte, hypothèses) peuvent rester dans le registre avec le type Information : elles gardent leur identifiant et leur source, mais sortent du calcul de couverture.

## Les deux sens de la traçabilité

La **traçabilité descendante** part du besoin client et vérifie qu'il est décliné jusqu'à la conception, puis vérifié : rien n'a été oublié. La **traçabilité ascendante** part d'un élément de conception, d'une ligne de code ou d'un essai et remonte à son origine : rien n'a été ajouté sans raison.

Un auditeur teste souvent les deux sens en tirant une exigence au hasard en haut de la pyramide et une autre en bas. Il suffit pourtant d'une seule information saisie pour les deux sens : la colonne **Parents** de chaque exigence. Les exigences filles d'une exigence se comptent en cherchant son identifiant dans les parents des autres lignes.

Une exigence sans parent n'a que trois statuts possibles :

1. elle est au niveau le plus haut, c'est normal ;
2. elle est **dérivée**, marquée comme telle et justifiée ;
3. elle est **orpheline** : c'est un défaut à corriger.

Les exigences dérivées sont légitimes, mais personne au-dessus d'elles ne les a demandées. En aéronautique, DO-178C impose de les transmettre au processus d'évaluation de la sécurité système ; notre guide sur [la liste des documents DO-178C](https://consignestudio.fr/guides/do-178c-liste-des-documents/) détaille ce cadre.

## Calculer la couverture

La couverture se calcule exigence par exigence, puis se résume par niveau.

**Couverture de déclinaison.** Pour chaque exigence d'un niveau non terminal : déclinée (au moins une fille active), justifiée (aucune fille mais une justification écrite) ou non déclinée.

**État de vérification.** Pour chaque exigence, à partir des vérifications qui la citent :

| État | Règle |
|---|---|
| Non conforme | au moins une vérification liée est non conforme |
| Non vérifiée | aucune vérification n'est liée |
| En cours | des vérifications sont liées, aucune n'est encore jouée |
| Partielle | une partie seulement des vérifications est conforme |
| Vérifiée | toutes les vérifications liées sont conformes |

Le taux de couverture d'un niveau est alors la part des exigences actives (hors Information et hors supprimées) déclinées, et la part vérifiée. Présentez-le **par niveau** : un taux global de 92 % peut cacher un niveau système couvert à 60 %.

> Une vérification « conforme » sans référence de procès-verbal ne compte pas aux yeux d'un auditeur. Contrôlez la colonne preuve avant de calculer quoi que ce soit.

## Les contrôles à faire avant une revue

Une matrice fait main échoue rarement sur des questions techniques. Elle échoue sur des trous qu'un filtre aurait montrés :

* exigences de haut niveau sans aucune fille ;
* exigences filles dont le parent est introuvable ;
* exigences sans méthode de vérification ;
* exigences sans aucune vérification liée ;
* essais conformes sans référence de preuve, ou sans date ;
* essais joués **avant** la dernière modification de l'exigence, donc à rejouer ;
* termes vagues dans les énoncés : rapide, convivial, si possible, environ, ou une valeur laissée en suspens ;
* énoncés sans verbe prescriptif (doit, doivent) ;
* identifiants en double ;
* remarques de revue acceptées mais jamais intégrées.

Envoyez l'état de ces contrôles au client **avant** la revue. Un écart que vous avez déjà expliqué devient une action ; un écart qu'il découvre en séance devient un constat.

## Écrire des exigences qui se laissent tracer

Une exigence mal écrite ne se décline pas et ne se vérifie pas. La norme ISO/IEC/IEEE 29148:2018 décrit les caractéristiques d'une bonne exigence (§5.2.5), d'un bon ensemble d'exigences (§5.2.6) et les termes à éviter (§5.2.7). En pratique :

* **une seule exigence par ligne** : un « et » cache souvent deux exigences ;
* **un critère mesurable** : « afficher une piste au plus 1,5 s après réception de la trame » plutôt que « affichage rapide » ;
* **une méthode choisie en l'écrivant** : si vous ne savez pas comment vous la vérifierez, l'exigence n'est probablement pas vérifiable.

La méthode EARS propose cinq gabarits de phrase qui rendent le déclencheur et la réponse explicites, par exemple « Quand une piste entre dans une zone d'exclusion, le système doit lever une alarme en moins de 1 s ».

## Gérer les modifications

Quand une exigence change, deux choses deviennent douteuses : ses **exigences filles**, qu'il faut relire, et ses **vérifications déjà jouées**, qui l'ont été sur l'ancienne version. Notez la date de révision de chaque exigence et la date d'exécution de chaque essai : la comparaison des deux dates suffit à repérer les essais à rejouer. Avant même de modifier, listez tout ce qui dépend de l'exigence en suivant les parents vers le bas et les vérifications liées : c'est l'analyse d'impact que le client vous demandera.

## Tableur ou outil dédié ?

Un tableur bien structuré suffit pour quelques dizaines à un millier d'exigences tenues par une petite équipe. Au-delà de quelques milliers d'exigences, avec plusieurs rédacteurs simultanés, des lignes de base et des variantes, un outil de gestion d'exigences devient préférable. Pensez dès le départ au format d'échange ReqIF pour ne pas tout ressaisir le jour du changement.

## Un modèle prêt à remplir

La [Matrice de traçabilité](https://consignestudio.fr/matrice-tracabilite-exigences/) est un classeur sans macro, conçu pour LibreOffice Calc (où il a été testé), Excel 2010 ou plus récent et Google Sheets. Vous saisissez les exigences et les vérifications ; il calcule la déclinaison, l'état de vérification, la matrice, un tableau de bord et 21 contrôles, dont ceux de la liste ci-dessus. L'édition complète ajoute l'analyse d'impact, les remarques de revue, l'historique, l'export CSV et ReqIF 1.2, des préréglages DO-178C et EN 50128 et un guide de mise en œuvre. Une édition gratuite de 60 lignes existe. Limites à connaître : Excel n'a pas été testé dans l'édition 1.0, et le classeur est un outil de support non qualifié qui n'atteste aucune conformité ; ses résultats se confirment par revue.

## Sources

- ISO/IEC/IEEE 29148:2018, Systems and software engineering · Life cycle processes · Requirements engineering, §5.2.5 à §5.2.7 (cités par numéro, texte non reproduit)
- Mavin et al., Easy Approach to Requirements Syntax (EARS), conférence IEEE Requirements Engineering, 2009
- Guide de mise en œuvre de la Matrice de traçabilité des exigences 1.0, Consigne, 2026