Healthtech : la traçabilité logicielle ne se reconstruit pas la veille de l'audit

Un auditeur demande comment une exigence précise a été implémentée, puis vérifiée, puis validée avant mise en production. L’équipe sait que c’est fait : le produit tourne, les tests passent, personne ne doute du résultat. Mais prouver le chemin complet, exigence par exigence, prend trois jours de reconstitution à la main entre Jira, un tableur Excel et des comptes-rendus Word dispersés. Dans la santé, cette scène se répète à chaque audit, chaque levée de fonds, chaque revue qualité.

Un logiciel qui marche ne suffit pas

En dehors du secteur de la santé, un logiciel qui fonctionne est un logiciel qui a réussi. En healthtech et medtech, ça ne suffit jamais : il faut aussi démontrer comment il a été spécifié, développé, vérifié et validé. La différence paraît subtile, elle ne l’est pas. Un auditeur ne demande pas si la fonctionnalité marche, il demande à voir la chaîne de preuves : quelle exigence, quelles issues l’ont implémentée, quels tests l’ont vérifiée, quelle revue a validé le résultat avant release. Sans cette chaîne reconstituable, le logiciel le mieux conçu reste, du point de vue réglementaire, non conforme.

Trois outils, zéro lien entre eux

La plupart des jeunes équipes healthtech héritent d’une pile d’outils pensée pour la vitesse, pas pour la preuve : Jira ou Linear pour suivre le développement, un tableur Excel pour la matrice de traçabilité, des documents Word pour les comptes-rendus de validation. Chacun fait son travail isolément. Aucun des trois ne sait ce que font les deux autres. Le lien entre une exigence et l’issue qui l’implémente, entre cette issue et le test qui la vérifie, entre ce test et la décision qui a validé la release, n’existe dans aucun système : il existe uniquement dans la mémoire de l’équipe, et dans les heures passées à le reconstituer avant chaque audit.

Cette dette de traçabilité ne se voit pas au quotidien. Elle se paie d’un coup, au pire moment : pendant un audit ISO 13485, une revue de dossier technique MDR, ou une due diligence d’investisseur qui demande des preuves de rigueur avant de signer.

Les enjeux réglementaires auxquels les healthtech font face

Les startups healthtech et medtech ne choisissent pas d’ajouter de la rigueur, elles la subissent de l’extérieur, sous plusieurs formes qui s’empilent :

• IEC 62304 encadre le cycle de vie du logiciel médical : classification du risque, planification, exigences, architecture, implémentation, tests d’intégration, tests système. Chaque étape doit être documentée et reliée à la précédente.
• ISO 13485 impose un système de management de la qualité qui couvre tout le cycle de vie produit, pas seulement le développement : conception, production, surveillance post-marché, gestion des incidents.
• MDR (Medical Device Regulation) en Europe et les exigences équivalentes de la FDA aux États-Unis demandent un dossier technique démontrant la conformité, avec une traçabilité complète entre exigences utilisateurs, spécifications, vérification et validation.
• RGPD et hébergement des données s’ajoutent dès que le produit touche, même indirectement, des données de santé, avec des attentes de localisation et de chiffrement qui dépassent le cadre logiciel pur.

Aucune de ces normes n’impose un outil particulier. Toutes imposent la même chose en substance : pouvoir reconstituer, sans effort de mémoire collective, le chemin complet entre une exigence et sa mise en production vérifiée.

Ce que Sinra apporte à cette équation

Sinra ne certifie rien et ne remplace aucune démarche qualité : Sinra est un outil d’organisation du développement, pas une certification, et ne garantit pas à lui seul la conformité à une norme comme IEC 62304 ou ISO 13485. Ce qu’il fait : construire la traçabilité pendant que l’équipe développe, pour qu’elle n’ait plus jamais besoin d’être reconstruite après coup.

• Des exigences reliées au code et aux tests. Chaque spécification est liée aux issues qui l’implémentent et aux tests qui la vérifient. Le lien que Jira, Excel et Word ne pouvaient pas maintenir existe nativement, dans un seul système.
• Des validations formelles et historisées. Revues de phase avec critères d’évaluation explicites, verdict go / no-go / conditionnel, et historique complet de chaque décision : exactement ce qu’un auditeur demande à voir, déjà disponible plutôt qu’à reconstituer.
• Des incidents documentés. Postmortems structurés : chronologie, facteurs systémiques, actions correctives, temps de résolution. La gestion des incidents devient elle-même une preuve de maturité qualité, pas un angle mort.
• Un vocabulaire maîtrisé. Un glossaire métier partagé, réutilisé dans les spécifications, pour qu’une exigence signifie la même chose pour le développeur qui l’implémente et l’auditeur qui la relit un an plus tard.
• La rigueur du cycle en V, le rythme de l’agile. Les specs suivent leur propre flux de rédaction et de validation pendant que les développeurs avancent en cycles courts. Les tests et les revues de phase garantissent que rien ne part en production sans avoir été vérifié, sans sacrifier la vitesse d’itération qu’une startup ne peut pas se permettre de perdre.
• Hébergement en France, RGPD, données chiffrées. Sinra est conçu pour les données de développement, pas pour des données patients : comme dans un environnement de test, seules des données fictives ou anonymisées ont leur place dans les issues et pièces jointes.

Ce qu’il faut retenir

La traçabilité réglementaire en healthtech n’est pas un document qu’on rédige une fois, avant l’audit : c’est une discipline qui se construit issue après issue, test après test, revue après revue. Les équipes qui la reconstituent à la main entre trois outils déconnectés la paient en jours perdus et en stress à chaque échéance. En reliant exigences, développement, tests et validations dans un seul système dès le premier jour, Sinra transforme cette reconstitution d’urgence en un historique déjà prêt à être montré.