Qu’est-ce qu’une matrice de traçabilité ?18 min read

Dans un cahier des charges envoyé par un client à son fournisseur, le besoin est présenté en une somme d’exigences. Le fournisseur y répond à travers un document listant une somme de solutions. Théoriquement le fournisseur peut organiser sa réponse de différentes manières :

  • Il répond point à point à chaque élément du besoin :
    1 besoin = 1 solution
  • Il forge une solution qui couvre plusieurs besoins à la fois :
    plusieurs besoins = 1 solution
  • Il découpe sa réponse en une somme de solutions pour répondre à un besoin :
    1 besoin = plusieurs solutions

En pratique, c’est plutôt un mélange des 3 en même temps ! C’est là qu’intervient la matrice de traçabilité pour mettre un peu d’ordre dans tout ça.


Point sur le vocabulaire

Avant d’aller plus loin, voici les définitions de quelques termes utilisés dans cet article.

Exigence
Nous appellerons exigence la description détaillée d’un élément du projet relativement indépendant et élémentaire. Celui-ci peut être un besoin du client ou une solution du fournisseur. Une exigence, c’est un peu comme une pièce de lego, une ligne dans votre liste de course, quelque chose que l’on peut cocher et dont on peut dire « ok, ça c’est fait ».

Cahier des charges
C’est le document qui liste les exigences décrivant une besoin. Le cahier des charges est généralement fourni par le client.

Solution
C’est la description d’un choix technique qui répond à un ou plusieurs besoins (exigence) d’un cahier des charges. Généralement livrée par le fournisseur. On dit aussi spécification.


La traçabilité, ce plat de spaghetti

Noodles Spaghetti Knotted Connected
Myriams-Fotos / Pixabay

La taille d’un document est extrêmement variable suivant les domaines d’activité qu’il recoupe. Pour illustrer ça, je vais prendre un exemple que je connais bien. Imaginez un cahier des charges pour un calculateur d’avion… Ne partez pas tout de suite ! Vous allez voir ça va être très clair.

Alors dans un avion, il y a des dizaines de calculateurs. Les calculateurs sont des ordinateurs sans clavier, ni écran ni souris. Ils servent à gérer la climatisation, les freins, le réseau électrique, les portes, le train atterrissage… Suivant la complexité d’un calculateur, son cahier des charges atteint facilement la centaine de pages et peut contenir plusieurs centaines d’exigences. Plusieurs métiers différents participent à son écriture pour décrire leurs besoins spécifiques. Il y a par exemple :

  • Des électroniciens pour concevoir le circuit de ma carte électronique qu’il contient
  • Des mécaniciens pour définir le boîtier qui protégera la carte
  • Des développeurs pour coder le logiciel à l’intérieur de la carte

Puis le document est transmis à un fournisseur qui va l’étudier avec ses propres équipes pour construire sa réponse. Parfois, plusieurs exigences (besoins) du clients peuvent être résolus par une même solution :

Exigence client 1 : la carte électronique doit être protégée hermétiquement.
Exigence client 2 : le boîtier doit avoir les dimensions suivantes X x Y x Z

Solution fournisseur 1 : le boîtier utilisé sera de la marque M et de la référence R.

La solution du fournisseur fait d’une pierre deux coup car le boîtier choisi est à la fois hermétique et de dimension X x Y x Z. Ainsi il couvre deux exigences client.

Mais parfois c’est l’inverse ! Le besoin est complexe et nécessite plusieurs solution pour être entièrement couvert :

Exigence client 3 : la carte électronique doit pouvoir fonctionner alors que l’avion vole (c’est mieux).

Solution fournisseur 2 : les composants de la carte électronique seront de la gamme G car ceux-ci restent fonctionnels même pour des températures atteignant -50°C (en haute altitude, les parties de l’avion en dehors de l’habitacle peuvent approcher ces températures).

Solution fournisseur 3 : le boîtier aura un revêtement R pour protéger la carte électronique des perturbations électromagnétiques.

Solution fournisseur 4 : le boîtier sera monté sur un système d’amortissement pour protéger la carte des vibrations mécaniques.

On constate ainsi que le maillage entre les exigences du client et les solutions du fournisseur peut très rapidement devenir complexe ! Aussi emmêlé qu’un plat de spaghetti !

Il est donc nécessaire de dresser un tableau pour savoir exactement quelles solutions répondent à quelles exigences du client, s’assurer qu’on n’en a oublié aucune et donc avoir une idée précise du coût du projet ! C’est ce tableau qu’on appelle une matrice de traçabilité.

Et concrètement ?

La matrice de traçabilité est donc un tableau qui va dresser la liste exhaustive des liens entre 2 documents. Si on reprend notre exemple ci-dessus, voilà ce que cela pourrait donner :

Besoins client
(cahier des charges / appel d’offre)
Solutions fournisseur
(spécifications / réponse à l’appel d’offre)
Exigence client 1Solution fournisseur 1
Exigence client 2Solution fournisseur 1
Exigence client 3Solution fournisseur 2
Solution fournisseur 3
Solution fournisseur 4
Matrice de traçabilité descendante

A ma gauche, la liste des exigences du client dans l’ordre où elle apparaissent dans son document (cahier des charges, appel d’offre, …). On les représente par leur titre (et/ou leur numéro unique si possible) pour éviter de surcharger le tableau.
A ma droite, la liste des solutions fournisseur qui font face à chaque exigence client qu’elles contribuent à couvrir.

Il est crucial que dans la colonne “Besoins clients” il n’y ait pas de doublon, car on adopte le point de vue du client. On cherche donc à savoir quelles solutions du fournisseur répondent à chacun de nos besoins (je vais y revenir). A l’inverse, dans la colonne “Solutions fournisseur”, on observe que Solution fournisseur 1 apparaît 2 fois, ce qui est tout à fait normal car on a vu précédemment que cette solution répondait “d’une pierre deux coups” à deux besoins.

Donc cette matrice adopte le point de vue client ou plutôt du cahier des charges. Et elle “descend” vers la réponse à ce cahier des charges. On l’appelle généralement Matrice de traçabilité descendante ou encore Downstream Matrix en anglais. Une fois complétée, elle permet de vérifier que toutes les exigences clients ont au moins une solution en face ! On ne peut pas en oublier !

Attention ! Le diable se cache dans les détails et ici il se cache dans le “au moins une solution en face” !
Reconsidérons l’exigence client 3. On voit qu’il faut mettre en place 3 solutions pour couvrir cette exigence :

  • Solution fournisseur 2
  • Solution fournisseur 3
  • Solution fournisseur 4

Cependant si on avait omis de spécifier la solution fournisseur 4, par exemple, et bien l’exigence ne serait pas totalement couverte. Or la matrice indiquerait tout de même que l’exigence est couverte par 2 solutions.

Pour résumer, la matrice de traçabilité permet de s’assurer qu’on a couvert toutes les exigences client (quantitatif). Mais elle ne permet pas de savoir si tout est correctement couvert (qualitatif) !

Les différentes matrices de traçabilité

Ce principe de tableau est déclinable à toutes les sauces (spaghetti… sauces… 😉) suivant le point de vue qu’on veut favoriser pour lire la traçabilité du projet.

Matrice de traçabilité ascendante ou upstream matrix

On a vu l’angle du client / cahier des charges avec la matrice de traçabilité descendante. Et bien maintenant voyons celui du fournisseur / spécification avec la Matrice de Traçabilité Ascendante (qui remonte donc) or in english Upstream Matrix.

Solutions fournisseur
(spécifications / réponse à l’appel d’offre)
Besoins client
(cahier des charges / appel d’offre)
Solution fournisseur 1 Exigence client 1
Exigence client 2
Solution fournisseur 2 Exigence client 3
Solution fournisseur 3 Exigence client 3
Solution fournisseur 4 Exigence client 3
Matrice de traçabilité ascendante

A ma gauche, on liste les solutions fournisseur dans l’ordre dans lequel elles apparaissent dans son document (les spécifications / la réponse à l’appel d’offre), en évitant les doublons.
A ma droite, on liste, en face de chacune des solutions, les exigences client qu’elles contribuent à couvrir. Et ce n’est pas grave s’il y a des doublons, au contraire ! Cela signifie qu’une même solution répond à plusieurs besoins clients ! Ce qui témoigne de son efficacité et de sa pertinence.

Cette matrice permet de voir si toutes les solutions qu’a définies le fournisseur couvrent bien un besoin (on verra par la suite que ce n’est pas toujours le cas et que c’est souvent nécessaire).

Dans le planning du projet, on peut alors prioriser, lorsque c’est possible, celles qui couvrent le plus de besoin à la fois. Dans notre exemple, il est peut-être plus pertinent de mettre en place la solution fournisseur 1 d’abord, pour “abattre le gros du travail”. Ainsi on accède plus rapidement à une première version viable du livrable. Et on itérera sur cette version au fur et à mesure de la mise en place des solutions suivantes.

Matrice des solutions non couvrantes

Il arrive parfois que le fournisseur définisse des solutions qui ne répondent pas à une exigence du client. Étrange !

Pas forcément. Celles-ci peuvent témoigner de contraintes qui s’appliquent au fournisseur, indépendamment du besoin du client, mais qu’il souhaite mentionner dans les documents contractuels pour les porter à l’attention de son interlocuteur.

Par exemple, le fournisseur possède tel ou tel logiciel et mentionne dans sa réponse qu’il l’utilisera dans sa version V de ce logiciel pour réaliser la prestation.
Autre exemple, le fournisseur a un accord avec une marque d’équipement pour obtenir des produits à moindre coût. Il avertit alors son client à travers une solution non couvrante qu’il utilisera cette marque dans la prestation.
Dernier exemple, à la lecture du cahier des charges, le fournisseur a identifié une contrainte indirecte et non décrite dans le document client : en cas de coupure d’électricité dans l’avion, la carte électronique doit pouvoir continuer de fonctionner. Il rajoute une solution non couvrante qui résout cette contrainte : le boîtier doit contenir une batterie pour la carte électronique.

On pourrait faire figurer ces solutions non couvrantes dans la matrice ascendante. Simplement, en face des solutions fournisseur non couvrantes il n’y aurait pas d’exigence client, ce qui peut semer un doute : est-ce un oubli ou n’y a-t-il pas d’exigence ?

C’est pourquoi, le mieux est de créer un tableau supplémentaire dans lequel on aura juste une colonne qui listera ces solutions non couvrantes :

Solutions fournisseur non couvrantes
Solution fournisseur 5
Solution fournisseur 6
Solution fournisseur 7
Matrice des solutions non couvrantes

Suivi des évolutions

C’est quasi incontournable ! Que ce soit le cahier des charges du client ou la réponse du fournisseur, ces documents vont évoluer. Parce que le besoin se fait plus mature, parce que les discussions font émerger de nouvelles idées ou apportent des corrections…

Et donc dans la version 2 du document, certaines exigences ont été mises à jour. Mais pas toutes ! Alors quoi ? Il va falloir tout relire ? Les 200 pages ! Pour trouver 3 ou 4 modifs ! Et bien oui… SAUF si une matrice de suivi des évolutions a été mise en place !

Cette matrice ne fait plus le lien entre 2 documents différents, mais entre 2 versions d’un même document. Pour l’exemple, on imagine que c’est le cahier des charges qui a évolué :

Besoins client mis à jourCommentaire
Exigence client 2Supprimée
Exigence client 3.2Évolution
Exigence client 4Nouvelle exigence
Matrice du suivi des évolutions

Attention il y a de nouvelles subtilités !

On retrouve toujours la colonne avec les titres (ou les référence) des exigences. Ok. Mais on a rajouté une colonne commentaire. Oui, une mise à jour peut prendre plusieurs forme plus ou moins visible donc mieux vaut apporter un commentaire pour préciser le caractère de cette évolution.

Une suppression

Besoins client mis à jourCommentaire
Exigence client 2Supprimée
Matrice du suivi des évolutions (extrait)

Le client a tout bonnement supprimé une exigence car il s’est rendu compte que le besoin qu’elle décrivait n’était pas pertinent.
La suppression d’une exigence dans un document de 200 pages peut facilement passer inaperçue. Or elle impacte tout le projet car il faut aussi supprimer toutes les solutions qui la couvraient. Cela risque de modifier le budget, le planning …

Je conseille aussi de conserver l’exigence supprimée dans la matrice de traçabilité descendante, en remplaçant la solution fournisseur par la mention “supprimée”. Cela fait une redondance d’information mais au moins on s’assure de ne pas l’oublier.

Besoins client
(cahier des charges / appel d’offre)
Solutions fournisseur
(spécifications / réponse à l’appel d’offre)
Exigence client 1Solution fournisseur 1
Exigence client 2Supprimée
Exigence client 3Solution fournisseur 2
Solution fournisseur 3
Solution fournisseur 4
Matrice de traçabilité descendante avec une exigence supprimée

Une évolution

Besoins client mis à jourCommentaire
Exigence client 3.2Évolution
Matrice du suivi des évolutions (extrait)

Une exigence qui existait déjà dans la première version du document a été mise à jour. Il faut donc le signifier dans le suivi des évolution car elle va potentiellement impacter toutes les solutions qui la couvraient.

On peut lui attribuer un numéro de version “Exigence client 3.2” pour indiquer marquer son itération.

De manière générale, c’est une très bonne pratique de systématiquement attribuer un numéro de version à toutes les exigences : “Exigence client X.1”. Par défaut, on peut leur donner le numéro .1.

Besoins client
(cahier des charges / appel d’offre)
Solutions fournisseur
(spécifications / réponse à l’appel d’offre)
Exigence client 1.1Solution fournisseur 1.1
Exigence client 2.1Supprimée
Exigence client 3.2Solution fournisseur 2.2
Solution fournisseur 3.2
Solution fournisseur 4.2
Matrice de traçabilité descendante avec une exigence mise à jour

Une nouvelle exigence

Besoins client mis à jourCommentaire
Exigence client 4.1Nouvelle exigence
Matrice du suivi des évolutions (extrait)

Le client a ajouté une toute nouvelle exigence pour préciser un nouveau besoin. Tout comme une suppression, l’ajout d’une exigence est difficilement identifiable dans un document de 200 pages, si on ne la liste pas dans le suivi des évolutions. Et une nouvelle exigence implique de penser la solution à mettre en place, sinon la couverture globale du besoin client sera incomplète. Attention au “trou dans la raquette” dans la matrice de traçabilité descendante !

Besoins client
(cahier des charges / appel d’offre)
Solutions fournisseur
(spécifications / réponse à l’appel d’offre)
Exigence client 1.1Solution fournisseur 1.1
Exigence client 2.1Supprimée
Exigence client 3.2Solution fournisseur 2.2
Solution fournisseur 3.2
Solution fournisseur 4.2
Exigence client 4.1Solution fournisseur 5.1
Matrice de traçabilité descendante avec une nouvelle exigence avec sa couverture

Globalement, toute évolution décrite dans le suivi des évolutions doit être répercutée dans les autres matrices de traçabilité. Même si cela génère de la redondance, au moins toutes les matrices sont cohérentes entre elles ! Ce qui est primordiale pour connaître l’état d’avancement du projet.

Et comment ça se passe si on fait une troisième version du document ?

Alors, on parle toujours de la matrice de suivi des évolutions. Si on fait une v3 du document, la matrice doit présenter les évolutions entre la v2 et la v3.

Ce n’est pas obligatoire, mais il peut être utile de conserver toutes les matrices de suivi des évolutions au fur et à mesure des versions du document. Cela permet d’avoir l’historique complet des modifications et évite de devoir ré-ouvrir toutes les versions d’un document. Attention toutefois à la multiplications des matrices !

On va faire un tableau pour résumer tout ça (oui j’aime bien les tableaux) :

Les matricesDocument original (v1)v2v3vN
Descendante (Desc)Desc.v1 : cohérente avec Asc.v1 et NC.v1Desc.v2 : cohérente avec Asc.v2, NC.v2 et SDE.v1/v2 Desc.v3 : cohérente avec Asc.v3, NC.v3 et SDE.v2/v3 Desc.vN : cohérente avec Asc.vN, NC.vN et SDE.v(N-1)/vN
Ascendante (Asc)Asc.v1 : cohérente avec Desc.v1 et NC.v1 Asc.v2 : cohérente avec Desc.v2, NC.v2 et SDE.v1/v2 Asc.v3 : cohérente avec Desc.v3, NC.v3 et SDE.v2/v3Asc.vN : cohérente avec Desc.vN, NC.vN et SDE.v(N-1)/vN
Non couvrantes (NC)NC.v1 : cohérente avec Desc.v1 et Asc.v1 NC.v2 : cohérente avec Desc.v2, Asc.v2 et SDE.v1/v2 NC.v3 : cohérente avec Desc.v3, Asc.v3 et SDE.v2/v3NC.vN : cohérente avec Desc.vN, Asc.vN et SDE.v(N-1)/vN
Suivi des évolutions (SDE)Elle n’existe pas car il n’y a pas de version précédenteSDE.v1/v2 : évolutions entre v1 et v2SDE.v2/v3 : évolutions entre v2 et v3
+ SDE.v1/v2 (facultatif)
SDE.v(N-1)/vN : évolutions entre v(N-1) et vN
+ SDE.v(N-2)/v(N-3) (fac)
+ SDE.v(N-3)/v(N-4) (fac)
+ … (facultatif)
Tableau récapitulatif des matrices présentes dans chacune des versions d’un document

Conclusion

La matrice de traçabilité est un outil extrêmement puissant ! Elle permet d’avoir une vue globale de la couverture du besoin client afin de s’assurer qu’on n’oublie rien en chemin. Elle permet même d’être robuste aux évolutions du besoin client et de toutes les prendre en compte.

Mais si je vous disais qu’on n’en a explorer que la surface ?

Et oui, on a considéré cet outil qu’entre un cahier des charges client et la réponse d’un fournisseur ! Mais après la réponse à un cahier des charges, il peut venir d’autres documents ! Spécifications fonctionnelles, Conception, Plans de validation, … Le diagramme suivant en donne un exemple possible pour un projet informatique :

Exemple cycle en V documentaire complet, extrait de l’atelier que nous avons construit sur les bonnes pratiques de rédaction.

Dans cette article nous n’avons seulement appliqué la matrice de traçabilité sur le tout petit segment vert en haut à gauche du diagramme !

Bon je dramatise, je dramatise. Les concepts qu’on a vus s’appliquent à toutes les liaisons entre les documents. Certaines liaisons peuvent adopter des variantes de matrices qu’on a vue. Mais je vous propose d’en rester là pour cet article déjà très dense.

L’inconvénient est que plus le projet est conséquent et comporte de nombreux documents, plus la construction de matrices de traçabilité se complique et requiert de la rigueur pour ne rien oublier et maintenir le taux de couverture à 100%. C’est, entre autres, pour répondre à cette problématique et automatiser la construction de la matrice globale d’un projet que nous avons développé Naept.

Et vous ?

Connaissiez-vous les matrices de traçabilité ? Comment faîtes-vous pour calculer le taux de couverture du besoin client ?
Utilisez-vous d’autres variantes de matrices (matrices de conformité, de faisabilité, …) ?
Comment faîtes-vous pour suivre les évolutions de tous vos documents ?
Utilisez-vous des logiciels particuliers ?

Related Posts

Leave a Reply