Un DHF ne se fige pas. Ce qu’on gèle à un dépôt, c’est une configuration.

Au moment de préparer un dépôt MDR ou une revue d’organisme notifié, un réflexe revient sans cesse : « on fige le DHF ». On imagine qu’il faut créer un nouveau Design History File, mettre l’ancien de côté, et repartir. Ce réflexe paraît prudent. Il repose sur une confusion — entre deux objets qui n’ont rien à voir.

Deux documents, un seul souvent confondu

Le DHF, ou dossier de conception, est le journal de bord du logiciel. Il enregistre tout ce qui s’y passe : les exigences, les choix de conception, les analyses de risque, les tests, les écarts. Par nature, il est cumulatif et vivant. Il n’est pas censé s’arrêter à une date : il continue de raconter ce que devient le produit.

La configuration, elle, est tout autre chose. C’est l’état daté du produit à un jalon donné — la version qui a été déposée, évaluée, marquée. Elle ne « contient » pas la conception : elle pointe vers un ensemble d’éléments précis du logiciel, à une date précise. Le DHF référence le tout ; la configuration pioche dedans.

Confondre les deux, c’est s’imposer des manipulations inutiles : un DHF qui se dédouble, un ancien qu’on met « de côté », des versions qu’on ressort parfois, qu’on fusionne parfois, jusqu’à un versioning chaotique où plus personne ne sait ce qui est réellement documenté.

Pourquoi on gèle la configuration — et jamais le DHF

Quand un dossier part en dépôt, l’auditeur doit pouvoir reconstituer l’état exact du produit qui a été évalué. C’est une obligation légitime, et c’est là que la configuration intervient : on date, on verrouille, on identifie précisément la combinaison d’éléments concernée. Ce verrou est une référence, pas une séparation du reste de la documentation.

Le DHF, lui, n’a aucune raison de s’arrêter. Au contraire : s’il est bien tenu, il continue de montrer comment le produit évolue, ce qui a changé et pourquoi. L’auditeur qui a besoin de la version déposée à telle date la retrouve dans la configuration correspondante — sans qu’on ait eu à figer, dupliquer ou ressortir le dossier de conception.

Ce que cela change concrètement

Côté startup et PME. Le piège du « nouveau DHF à chaque dépôt » est ravageur pour une petite équipe : elle se retrouve avec une documentation en double, des versions parallèles, et une perte de confiance dans son propre dossier. Garder un DHF unique et vivant, adossé à des configurations datées, coûte bien moins cher à l’usage.

Côté ETI. C’est la cohérence entre lignes de produits qui se joue. Une règle simple — un DHF vivant, des configurations indépendantes et datées — évite que chaque projet réinvente sa propre mécanique de gel et de fusion, source d’écarts incomparables.

Côté grand groupe. La question devient la reproductibilité de cette discipline à grande échelle. Séparer proprement le dossier de conception de la configuration est ce qui permet de capitaliser, sans hériter à chaque dépôt d’une pile de documents manipulés à la main.

L’idée à retenir

Le DHF doit rester vivant, en permanence — y compris celui qui a servi à un dépôt. Ce qu’on fige, c’est la configuration, et c’est précisément parce qu’on la fige que le DHF peut continuer de vivre sans se perdre dans des versions parallèles.

Vous préparez un dépôt et la question du gel de votre documentation vous embarrasse ? Échangeons sur la bonne frontière entre dossier de conception et configuration. → bonjour@numedikal.com