Léa est Product Owner dans une start-up MedTech.
Elle gère le backlog, priorise les évolutions, accompagne les devs et les tests… mais ce matin, face à ce message, elle sent une pression nouvelle.
La traçabilité ?
Elle sait bien que les informations sont là, quelque part : dans les tickets Jira, les pages Notion, les fichiers partagés sur Drive.
Mais comment les relier ? Les structurer ? Les justifier ?
Et surtout, comment s’assurer que cela répond aux exigences réglementaires, sans transformer le projet en tunnel ?
Ce flou, Léa n’est pas la seule à le ressentir.
Derrière le mot “traçabilité”, chacun entend quelque chose de différent.
Pour les développeurs, c’est une question de commits, de tickets, de tests.
Pour le réglementaire, c’est un graphe de relations, une matrice d’impact, un tableau à présenter à l’auditeur.
Et pour l’équipe projet… c’est souvent un mot un peu intimidant, qu’on sait important, mais qu’on a du mal à concrétiser.
Alors Léa s’interroge.
À quoi sert exactement cette traçabilité ?
Faut-il un outil dédié ? Ou peut-on s’en sortir avec ce qu’on a déjà ?
Comment faire simple, robuste, évolutif… et surtout, comment ne pas exploser la charge projet pour autant ?
Dans cet article, on va suivre les réflexions de Léa.
Pas à pas, elle va chercher à comprendre ce qu’est vraiment la traçabilité dans un projet de DMN, comment l’adapter à son contexte, et comment choisir ou configurer les bons outils pour que conformité et agilité avancent ensemble.
Elle ne le sait pas encore, mais elle commence peut-être à endosser un rôle hybride, à la croisée du produit et du réglementaire. Un rôle que certains appellent déjà… PO-QARA.
Chapitre 1 – De la demande floue à l’objectif concret
Léa relit encore le mail de son responsable QARA. Une “matrice de traçabilité complète” entre exigences, spécifications, tests, risques, code… Sur le papier, tout semble clair. Dans la réalité, tout est flou.
Son projet vit au quotidien dans Notion et Jira : les tickets avancent, les tâches se clôturent, les validations s’enchaînent. Mais une question la hante : est-ce que tout cela suffira pour convaincre un auditeur ? Est-ce qu’une simple liste de tickets ou un tableau de spécifications prouve réellement que le projet est maîtrisé de bout en bout ?
Très vite, Léa comprend que la réponse est non.
Dans l’univers des dispositifs médicaux numériques (DMN), la traçabilité n’est pas seulement une collection de documents ou de tâches validées. C’est un réseau vivant où tout doit être lié. Un auditeur ne lira pas 150 tickets un par un.
Or, dans son quotidien, Léa jongle déjà entre plusieurs outils. Les user stories et les tests fonctionnels sont suivis dans Jira. Les besoins métier, eux, sont documentés dans Notion. Les risques ont été identifiés dans un fichier Excel partagé sur le Drive. Chacun de ces éléments existe. Mais aucun n’est lié de manière formelle aux autres.
Pourtant, dans l’esprit des normes comme l’IEC 62304, c’est précisément cette relation entre les éléments qui est exigée. La réglementation suit la logique du cycle en V.
Cette architecture impose une traçabilité bidirectionnelle : descendante (exigence ➔ spécification ➔ code) et ascendante (test ➔ validation ➔ exigence).
Source : Qualitiso
Avoir des tickets ne suffit pas. Avoir des specs ne suffit pas. Il faut prouver que tout est lié.
Face à cette prise de conscience, Léa sait qu’elle va devoir faire l’inventaire de tout ce qui existe. Avant de penser à ajouter de nouveaux outils ou à modifier ses process, elle doit cartographier : quels objets ai-je ? Quels liens manquent ? Que peut-on reconstituer ?
Elle ouvre Notion, Jira et le Drive. Son chantier commence.
Chapitre 2 – Cartographier l’existant : ce que Léa peut utiliser
Léa commence à lister mentalement tout ce qu’elle a sous la main. Des exigences utilisateurs dans Notion. Des spécifications fonctionnelles dans Jira. Des tests disséminés dans les tickets. Un fichier de risques sur Drive. Chaque pièce existe. Mais sans structure, sans relations visibles entre elles.
Après une discussion rapide avec son responsable QARA, la demande devient plus précise : l’auditeur ne veut pas seulement vérifier que l’équipe a fait son travail. Il veut voir comment chaque besoin initial est traduit, spécifié, vérifié — et comment chaque risque est maîtrisé. Un peu perdue, Léa se replonge dans ses notes et tombe sur un article partagé quelquess plus tôt par Xavier, un collègue Tech expérimenté Cet article décrivait de manière très simple comment organiser la traçabilité autour du cycle de vie logiciel des dispositifs médicaux numériques. C’est exactement ce qu’il lui faut pour clarifier les attentes.
Léa s’inspire de ce modèle pour tracer un premier schéma sur son écran. Une carte vierge pour représenter la structure théorique idéale attendue par un auditeur : des besoins utilisateurs formalisés, des exigences précises, des spécifications détaillées, des éléments logiciels, du code, et pour chaque étape, des preuves de vérification par des tests adaptés.
En regardant ce schéma, Léa comprend mieux ce qu’elle doit reconstruire. Il ne s’agit pas seulement de rassembler des documents : il faut que tout soit lié.
Forte de cette vision, elle entame un audit méthodique de l’existant. Dans Notion, elle retrouve les besoins utilisateurs exprimés lors des premiers ateliers de cadrage : des thématiques fonctionnelles riches, mais peu d’exigences formalisées de manière rigoureuse. Dans Jira, elle navigue entre les user stories, les tâches techniques et les tests d’acceptation. Les spécifications sont relativement bien détaillées. Les tests fonctionnels sont présents, souvent associés aux tickets, même si leur lien direct avec les exigences initiales reste implicite. Sur le Drive, elle consulte les matrices de risques existantes. Le travail de recensement est plutôt solide, mais il manque souvent des liens clairs vers les mesures correctives développées dans les spécifications ou vers les résultats de tests validant leur traitement.
Du côté du code et des dépôts Git, elle constate une absence quasi-totale de documentation structurée du cycle de vie. Les commits sont nombreux, les branches vivantes, mais les traces d’une validation formelle par rapport aux exigences restent très limitées.
À ce stade, Léa réalise que les briques principales du projet sont bel et bien présentes. Mais sans liens explicites entre elles, la démonstration de la maîtrise projet restera fragile.
Pour avancer concrètement, elle reprend son schéma initial et l’enrichit à partir de ce qu’elle a trouvé : elle associe à chaque élément théorique l’outil ou l’espace où l’information est aujourd’hui disponible, même si les connexions restent encore à formaliser.
En procédant ainsi, Léa visualise immédiatement les points forts et les zones d’ombre de sa traçabilité actuelle. Certains chemins peuvent être recréés facilement par des liens croisés dans Notion ou Jira. D’autres nécessiteront une extraction manuelle et une reconstruction dans un tableau de correspondance. Quelques éléments devront être complétés pour que tout soit cohérent.
Un point en particulier attire son attention : si des tests fonctionnels existent bel et bien dans Jira, la couverture complète entre les exigences, les spécifications et les différents niveaux de tests reste incertaine. Léa note ce sujet à approfondir lors de la construction de la matrice de traçabilité. Cela fera partie des arbitrages à poser dans la prochaine étape.
Son plan devient limpide : d’abord reconstruire la traçabilité à partir des éléments existants, puis combler les manques, et enfin assembler une matrice robuste et exploitable pour l’audit.
La prochaine mission sera donc de choisir comment structurer cette matrice efficacement, en utilisant au mieux les outils disponibles… ou en adaptant ses méthodes si nécessaire.
Chapitre 3 – Construire la matrice : choisir et utiliser les bons outils
Léa a désormais une vision claire de l’existant. Les éléments sont identifiés, partiellement structurés, mais loin d’être intégrés. Il ne s’agit plus de comprendre ce qu’il manque : il faut maintenant décider comment transformer cette cartographie en une matrice de traçabilité solide, lisible et présentable.
Elle se fixe un cap : ne pas tout reconstruire, mais structurer intelligemment avec les moyens du bord. Pas question de lancer un chantier démesuré ou de bouleverser les habitudes de l’équipe. L’objectif reste clair : pouvoir répondre à l’auditeur, démontrer la maîtrise du cycle de vie du dispositif, et continuer à livrer du produit.
À partir du schéma enrichi qu’elle a formalisé, elle identifie les liens qu’il faut créer pour que la traçabilité prenne forme.
Premier constat : il manque un objet clé. Aucune exigence produit n’a été formalisée jusqu’ici. Léa a deux options : soit les créer dans Notion, en les liant directement aux besoins utilisateurs déjà rédigés ; soit les formaliser dans Jira, à mi-chemin entre les besoins et les spécifications techniques. Après quelques tests, elle choisit la seconde option : cela permet de relier directement les exigences aux user stories existantes, sans ajouter un outil de plus dans le quotidien de l’équipe.
Deuxième blocage : les éléments logiciels définis dans Jira ne sont pas connectés au code. Léa échange avec les développeurs, et découvre qu’il est possible d’ajouter les liens vers les commits Git directement dans les tickets. Elle met en place une règle simple : chaque spécification technique devra référencer un ou plusieurs commits via leur ID ou leur URL. Ce n’est pas parfait, mais cela crée une traçabilité descendante tangible entre spécifications, code et tests.
Reste le cas des tests unitaires. Léa ne les retrouve pas dans Jira, ni dans Drive. En échangeant avec l’équipe tech, elle apprend que les fichiers de tests sont bien présents dans le dépôt Git, mais sans documentation formelle. Elle décide de créer un tableau de correspondance, en parallèle de la matrice principale, qui associe chaque exigence critique à un répertoire de tests ou à un fichier nommé selon une convention (test_*.py, etc.). Ce lien est imparfait, mais il montre une volonté claire de maîtriser la vérification.
Au fil de l’exercice, la matrice prend forme : des onglets pour les exigences, les spécifications, les risques, les tests. Des colonnes pour les identifiants, les statuts, les sources (Notion, Jira, Drive). Des liens croisés, parfois manuels, parfois automatiques. Léa centralise le tout dans un tableau Notion, qu’elle versionne comme un livrable à part entière.
Mais une fois cette première version assemblée, une évidence s’impose : malgré tous ses efforts, des liens manquent encore. Des croisements qui n’existent pas, faute d’avoir une base de données unifiée. En réalité, c’est l’usage de trois outils différents — Notion, Jira, Drive — qui crée cette dispersion.
Et surtout : le temps presse. Une semaine s’est déjà écoulée depuis la demande initiale. La version logicielle n’est pas encore finalisée, les derniers tests doivent encore passer. L’équipe est concentrée sur la release. Léa le sait : elle ne peut pas ralentir la dynamique. Et l’audit est maintenant dans une semaine. Les choix qu’elle fera devront être soutenables immédiatement.
Elle liste alors quatre options.
a. Tout migrer dans un seul outil : par exemple, centraliser toute la traçabilité dans Jira ou dans Notion. Avantage : cohérence et liens internes facilités. Inconvénient : migration lourde, perte de confort sur certains usages, perte d’historique, reformation des équipes.
b. Utiliser un nouvel outil spécialisé : TraceX, Matrix Requirements, Tuleap… Ces outils sont pensés pour ça. Avantage : traçabilité native, structuration conforme, exports automatisés. Inconvénient : coût, courbe d’apprentissage, rupture avec les outils quotidiens, perte partielle d’historique, et surtout : impossible à mettre en place en une semaine.
c. Créer une supra-matrice indépendante : un tableau pivot qui centralise uniquement les liens (sans reproduire les contenus), entre tous les outils utilisés. Avantage : souple, léger, pas d’outil imposé. Inconvénient : effort de maintien manuel, risque d’erreur humaine.
d. Ajouter des liens croisés dans chaque outil : intégrer un champ “Référence associée” dans les pages Notion, des liens vers Drive dans Jira, et inversement. Avantage : pas de changement majeur. Inconvénient : risque d’incohérence, liens fragiles, sans système de validation formelle.
Léa évalue chaque option avec lucidité. Les solutions a et b seraient séduisantes dans un monde parfait, avec du temps devant elle. Mais elles sont inadaptées à son contexte actuel : la deadline approche, l’équipe est mobilisée sur la livraison, et l’historique projet reste essentiel pour l’audit.
Elle retient donc les options c et d.
Avant d’aller plus loin, elle décide de présenter ces deux solutions à son responsable QARA. Ensemble, ils pourront arbitrer sur ce qui sera jugé suffisant, soutenable, et conforme dans le contexte d’un audit imminent.
Chapitre 4 – La validation : Léa et le QARA finalisent ensemble la matrice
Léa est prête. Elle a structuré sa matrice : les exigences ont été formalisées, les spécifications reliées aux commits Git, les risques mis à jour, les tests cartographiés. Et surtout, elle a commencé à relier les éléments entre eux dans chaque outil. Ce n’est pas parfait, mais c’est cohérent. Et surtout : c’est explicable.
Elle a retenue les options c et d.
Son responsable QARA valide l’ensemble de la démarche. Il souligne que la stratégie proposée est bien alignée avec les attentes d’un audit réglementaire : il ne s’agit pas d’avoir une documentation parfaite, mais de démontrer la maîtrise du cycle de vie, l’existence de liens traçables, et la cohérence globale du dispositif.
Il revient cependant sur les implications de chaque option.
La supra-matrice permet une vision d’ensemble centralisée, lisible, transversale. Mais elle demande aussi un effort documentaire important : versionner chaque mise à jour, maintenir manuellement la cohérence des liens, assumer le risque d’erreur ou de désynchronisation. Une solution puissante, mais qui fait reposer une charge continue sur une seule personne.
À l’inverse, l’enrichissement des outils eux-mêmes permet de rester léger. Chaque champ de lien ajouté dans Notion, Jira ou Drive s’intègre dans le quotidien des équipes. C’est moins robuste sur le papier, mais plus réaliste à court terme. Et surtout, cela reste facilement présentable à l’audit sans générer de livrable supplémentaire.
Face à cette analyse, Léa et le QARA s’alignent. Ce sera l’option d. Léa poursuit donc le travail engagé : elle ajoute un champ “Référence associée” dans Notion, insère des liens vers Drive dans Jira, et complète les documents de risques pour assurer une navigation logique entre les sources. Pas de duplication. Pas de surcouche. Juste un fil conducteur assumé, visible, et défendable.
Quelques points de vigilance sont néanmoins posés : s’assurer que les champs sont bien systématiquement renseignés, que chaque exigence critique comporte une indication de couverture vérification, et que la démonstration de la matrice puisse être fluide le jour de l’audit, via les outils eux-mêmes.
Léa les intègre dans la foulée. Tout est géré dans les interfaces existantes. Pas de livrable en plus, pas de redondance. Elle verrouille sa matrice dans l’outil, renseigne les derniers liens, et s’autorise un vrai regard d’ensemble sur le travail accompli.
En refermant son tableau, elle mesure le chemin parcouru. Elle n’a pas simplement répondu à une demande qualité. Elle a structuré une réponse produit à une exigence réglementaire. Elle n’a pas cherché à devenir experte conformité, mais elle a posé les bonnes questions, identifié les zones critiques, proposé une stratégie et l’a fait valider par le bon interlocuteur. Une posture de PO-QARA qu’elle a incarnée sans l’anticiper — mais dont elle mesure, a posteriori, l’utilité.
Et si cette fois il s’agissait juste de réussir l’audit, la prochaine fois, peut-être qu’elle irait plus loin. Avec les bons outils, au bon moment.
Chapitre 5 – Quel outillage pour demain ?
L’audit est passé. Officiellement, aucun écart. L’auditeur a validé la cohérence du système de traçabilité, sa lisibilité, sa logique. Mais dans la dernière ligne du rapport, une phrase résonne :
« La traçabilité repose sur un ensemble de liens manuels. Il est recommandé de renforcer ce dispositif avec un système outillé plus intégré. »
Pas d’obligation. Mais une évidence : cette solution ne tiendra pas indéfiniment.
Rassurée mais lucide, Léa ouvre un nouveau fichier : “Choix d’un outil structurant”. Son objectif : sortir du système bricolé, passer à une solution pensée pour ça — ou au moins capable de s’adapter sans tout casser. Elle commence par recenser les outils qu’elle connaît ou a explorés. Notion et Jira d’un côté — parce qu’ils sont déjà utilisés dans l’équipe. Matrix Requirements, Tuleap et TraceX de l’autre — découverts via des démonstrations ou des retours d’expérience récents.
Notion
C’est l’outil qu’elle a utilisé dès le début du projet. Elle en connaît les forces : légèreté, souplesse, clarté. En combinant les bases de données relationnelles, il est possible de modéliser différents types d’objets (besoins, specs, exigences, tickets) et de les relier entre eux. Il existe des modèles publics qui vont encore plus loin : structuration par sprint, hiérarchie de spécifications, intégration des commits Git. Et surtout, Notion reste un excellent outil de documentation vivante, accessible à toutes les équipes. Mais la validation réglementaire n’est pas gérée nativement. Pas de versioning fort, pas de verrouillage documentaire, pas de logique de statut validé/revu. La traçabilité est faisable, mais elle dépend entièrement de la rigueur de celui qui le configure.
👉 Pour des équipes agiles très autonomes, c’est puissant.
🔗 https://www.notion.so
Jira
Léa le connaît côté dev. Elle y suit les sprints, les tickets, les stories. Mais elle découvre qu’en le configurant, Jira peut devenir bien plus. Grâce à des extensions comme Xray ou TestFLO, certaines équipes construisent une traçabilité complète entre exigences, specs, implémentation, tests et anomalies. Ces plugins permettent de générer des matrices de tests, de tracer automatiquement les exécutions, de structurer les plans de validation. Mais Jira n’est pas conçu à l’origine pour répondre aux exigences du MDR ou de l’ISO 13485. Tout doit être paramétré, formalisé, aligné. En contrepartie, l’intégration avec les outils dev est fluide, et l’outil reste très bien accepté côté tech.
👉 Pour une équipe déjà à l’aise avec Jira, bien accompagnée, cela peut devenir un socle. Mais ce socle demande de l’investissement.
🔗 https://www.atlassian.com/software/jira
Matrix Requirements
Lors d’une démonstration, elle découvre un outil pensé dès le départ pour les dispositifs médicaux numériques. Interface sobre, mais très complète : exigences, risques, tests, revues, anomalies, tout est modélisé, versionné, lié. Chaque modification est historisée. Le cycle en V n’est pas une vue de l’esprit, c’est la structure même du modèle. Les matrices sont générées automatiquement. Il est possible de créer différents types d’exigences, de les relier à des tests ou à des risques, et d’éditer des rapports conformes aux attentes d’un auditeur. Ce n’est pas l’outil le plus design, mais il est fonctionnel, carré, maîtrisé.
👉 Pour une équipe réglementée en recherche d’un outil qui coche toutes les cases documentaires sans complexifier la vie produit, c’est une valeur sûre.
🔗 https://www.matrixreq.com
Tuleap
Découvert via une autre équipe projet, Tuleap apparaît comme un couteau suisse modulaire. C’est une plateforme de gestion de projet dans laquelle on active des briques : exigences, risques, campagnes de test, documentation, backlog Agile. Chaque artefact est paramétrable, chaque relation personnalisable. On peut y intégrer Git, suivre des jalons, tracer les validations, configurer des workflows internes. C’est puissant, mais cela demande un temps de cadrage et un minimum d’accompagnement.
👉 Pour une structure qui veut industrialiser la conformité sans sacrifier sa méthode de développement, Tuleap constitue une base robuste et évolutive.
🔗 https://www.tuleap.org
TraceX
Lors d’une démonstration, Léa découvre un outil structuré comme une base de données projet. Chaque élément (exigence, risque, test, anomalie) possède ses champs, son statut, son identifiant. TraceX permet de créer des modèles sur mesure, de relier les objets entre eux, de filtrer les vues, de générer des exports automatiquement. Le système de navigation est hiérarchique, orienté documentation. L’outil est pensé pour faciliter la relecture, pour que chaque sous-ensemble d’objets soit consultable avec son propre filtre. Ce n’est pas une interface graphique “drag and drop”, mais un outil conçu pour produire une documentation de traçabilité claire, versionnée, exportable.
👉 Pour une équipe qui veut aller vite vers une traçabilité exploitable et générer des livrables d’audit fiables, TraceX est centré, efficace, adaptable.
🔗 https://www.tracex.io
En posant ces cinq options sur la table, Léa commence à distinguer deux familles. D’un côté, les outils qu’on adapte : Notion, Jira. De l’autre, ceux pensés pour la conformité : Matrix, Tuleap, TraceX. Elle commence à structurer ses critères : traçabilité bidirectionnelle, documentation, gestion des risques, UX, intégration Git, matrices exportables, vérification, validation, effort de mise en place, acceptabilité produit-tech, et évolutivité. Mais elle sent qu’il lui manque encore quelque chose.
Elle en parle à nouveau avec son responsable QARA. Et la discussion bascule. Car la question n’est plus seulement : « Quel est le meilleur outil pour gérer la traçabilité ? », mais bien : « Quel est l’outil qui peut devenir notre socle commun produit + qualité ? » Ils évoquent la gestion des risques, la documentation qualité, les anomalies, les rapports de test, les revues, les formulaires, le pilotage QMS. Et si finalement, la traçabilité n’était qu’un symptôme ? Et si le besoin réel, c’était un environnement unifié, clair, modulaire, pour piloter un produit réglementé dans sa globalité ?
Léa referme son fichier et renomme son document : “Choix d’un outil socle – produit & qualité”. Ce ne sera peut-être pas pour cette release. Mais ce sera leur prochain cap.
Avec son responsable QARA, elle prend le temps de structurer leur réflexion dans un tableau de synthèse. C’est leur manière de visualiser les options, de comparer objectivement les outils qu’ils ont identifiés, et de projeter une décision éclairée. Ils n’ont pas cherché à faire un benchmark exhaustif, mais à mettre à plat les critères qui comptent pour eux : la traçabilité bien sûr, mais aussi la documentation, les tests, l’UX, les intégrations, le coût, l’effort de mise en place, et le délai pour rattraper l’existant.
Voici ce tableau, tel qu’ils l’ont construit ensemble — une base de décision qu’ils partageront avec l’équipe lors de la prochaine roadmap.
Conclusion
Il y a quelques semaines encore, Léa pensait que la traçabilité n’était qu’un sujet parmi d’autres. Une étape obligatoire, un tableau à tenir à jour, un point de contrôle dans un processus qualité déjà bien dense. Ce qu’elle a traversé depuis lui a appris que la traçabilité n’était pas un livrable parmi d’autres, mais un révélateur. Elle oblige à regarder autrement le produit, à questionner ses fondations, à explorer les zones grises entre l’intention initiale, l’implémentation réelle et les preuves associées. Elle ne parle pas seulement de conformité, elle parle de maîtrise.
Ce travail a transformé la façon dont elle se positionne sur le projet. Sans devenir experte en réglementation, elle a adopté une posture nouvelle : celle d’une cheffe de produit qui sait naviguer entre les enjeux d’usage, de tech, et de conformité. Qui sait à quel moment faire appel à un expert, mais aussi quand structurer une réponse avec les moyens du bord. Une posture qu’elle ne lâchera plus : celle d’un PO-QARA.
Mais ce qu’elle retient surtout, c’est que la traçabilité n’est pas un sujet de contrôle. C’est un levier de clarté. C’est ce qui permet de relier les exigences, les décisions, les risques et les validations dans un langage commun. Ce qui permet à une équipe de ne pas seulement livrer vite, mais de livrer en confiance. Ce qui donne au produit une colonne vertébrale, visible, défendable, reproductible.
Et demain ? Demain, la question ne sera plus de savoir si elle a bien coché toutes les cases. La question sera : a-t-elle structuré son produit pour qu’il puisse évoluer, être audité, maintenu, et challengé sans peur ? Et si, finalement, c’était ça le vrai bénéfice de la traçabilité : donner à l’équipe les moyens d’accélérer, sans s’égarer.
.png)
