Comment contrôler le dossier technique avant la décision de certification ?

Réponse courte : quand un dossier technique est-il prêt pour la décision ?

Un dossier est prêt pour la décision lorsque le produit et sa révision sont clairement identifiés, que chaque exigence applicable est reliée à une preuve à jour, que les non-conformités sont soldées et que l’examen indépendant de l’évaluation est achevé.

L’objectif du contrôle n’est pas de compter le nombre de documents dans le dossier, mais de permettre au décideur de reconstituer une chaîne de preuves ininterrompue pour un seul périmètre produit. Si un document manque, si sa validité dans le temps est incertaine ou s’il appartient à une autre révision, le système doit rester du côté de la sécurité et suspendre la décision.

Quelles sept portes doivent être contrôlées avant la décision ?

Réponse courte : identité, périmètre, exigences applicables, preuves, non-conformités, examen indépendant et éléments de décision — tant que ces éléments ne sont pas tous validés ensemble, le dossier n’est pas réputé complet.

1. Identité du produit : le modèle, le type, la variante, le périmètre série/lot et la révision technique correspondent-ils tous entre eux ?
2. Programme et périmètre : la demande, le contrat, le programme de certification et le périmètre du certificat demandé décrivent-ils bien le même produit ?
3. Exigences applicables : les versions en vigueur de la réglementation, des normes, des règles du programme et des exigences du client ont-elles été déterminées ?
4. Suffisance des preuves : chaque exigence est-elle adossée à une preuve vérifiable, telle qu’un plan, un registre des risques, un calcul ou un rapport d’inspection ou d’essai ?
5. Solde des constats : existe-t-il une non-conformité ouverte, une évaluation complémentaire en attente ou une correction non vérifiée ?
6. Examen indépendant : une personne habilitée n’ayant pas participé à l’évaluation a-t-elle attesté la complétude des informations et de la procédure ?
7. Dossier de décision : le décideur peut-il voir en une seule vue le périmètre, le résultat de l’examen, les exceptions et les risques ouverts ?

Comment construire la matrice exigences-preuves ?

Chaque ligne doit présenter une seule exigence applicable et l’enregistrement à jour qui la démontre. Au lieu d’une simple case « disponible », on consigne l’identifiant de la preuve, sa révision, son résultat et son statut d’examen.

La décision n° 768/2008/CE prévoit que, dans les modules de la législation d’harmonisation de l’UE, la documentation technique permette l’évaluation de la conformité et couvre, en tant que de besoin, la description du produit, les informations de conception et de fabrication, l’évaluation des risques, les normes, les calculs et les rapports d’essai. Plutôt que de copier cette liste telle quelle pour chaque produit, mettez-la en correspondance avec la réglementation et le programme applicables.

Comment tester la cohérence interne du dossier ?

Réponse courte : comparez le même identifiant critique d’un document à l’autre et traitez toute contradiction non comme un simple avertissement, mais comme un obstacle à la décision.

• Comparez les désignations modèle/type figurant dans la demande, sur l’étiquette du produit, sur les plans et dans le rapport d’essai.
• Consignez que l’échantillon soumis aux essais est représentatif de la famille de produits visée par la décision.
• Recroisez les mesures de maîtrise des risques avec les sorties de conception, les informations d’utilisation et les résultats d’essai.
• Indiquez quels articles d’une norme partiellement appliquée ont été utilisés et comment les exigences restantes sont satisfaites.
• Après une modification technique, soumettez à l’évaluation d’une personne habilitée la question de savoir si les anciens résultats d’essai ou d’examen restent valables.
• Distinguez la révision d’une traduction ou d’un PDF exporté de celle de l’enregistrement source ; ne présentez pas un document dérivé comme l’enregistrement original.

Le Blue Guide 2022 de la Commission européenne explique également que le chemin d’évaluation de la conformité dépend du produit et de la réglementation applicable. C’est pourquoi un rapport d’essai, un marquage CE ou un certificat antérieur ne constituent pas, à eux seuls, une preuve décisionnelle suffisante pour tous les programmes.

Pourquoi séparer l’examen technique de la décision ?

Le guide actuel d’ISO/IEC sur l’évaluation de la conformité précise que les résultats de l’évaluation doivent être documentés avant l’examen, que celui-ci doit être réalisé par une personne n’ayant pas participé à l’évaluation et que la décision est prise après l’achèvement de l’examen. Même si une même personne peut assumer l’examen et la décision, la distinction du non-participation à l’activité d’évaluation reste maintenue.

Dans le flux de travail numérique, au moins trois états doivent être maintenus distincts : évaluation achevée, examen technique conforme et décision prise. L’achèvement d’un état ne doit pas engendrer automatiquement un autre ; la personne, le périmètre d’habilitation, la date, la version des données d’entrée et la justification doivent être consignés dans une piste d’audit infalsifiable.

Comment gérer les versions des normes et du programme ?

La liste de contrôle doit être gérée en version avec le dossier. Selon l’inventaire officiel de l’ISO, l’ISO/IEC 17065:2012 et l’ISO/IEC 17067:2013 demeurent les versions publiées ; les révisions 2026 sont au stade FDIS. Un texte à l’état de projet ne doit pas être appliqué automatiquement comme une exigence publiée.

Chaque dossier doit conserver le nom/la version du programme, l’édition applicable des normes, la règle de transition et la liste de contrôle utilisée à la date de décision. Lorsqu’une règle est mise à jour, les décisions passées ne sont pas silencieusement réécrites ; une évaluation d’impact ouvre un nouvel examen ou une mission de surveillance.

Comment concevoir une porte de décision fail-closed dans le logiciel ?

Ne liez pas le bouton de décision à la seule habilitation du rôle, mais à un état vérifiable du dossier. Il ne suffit pas que les champs obligatoires paraissent remplis ; il faut aussi vérifier que la preuve associée est accessible, à la bonne révision et dans un statut valide.

1. Générez les lignes d’exigences obligatoires à partir de la version du programme.
2. Reliez chaque ligne à la révision du produit et à l’identifiant de la preuve.
3. Présentez comme blocages un constat ouvert, une preuve manquante, une identité contradictoire ou une évaluation en attente.
4. Vérifiez si l’examineur fait partie de l’équipe d’évaluation et son périmètre d’habilitation.
5. figez, sous forme de paquet infalsifiable, la matrice et ses annexes telles qu’utilisées au moment de la décision.
6. Gérez les modifications ultérieures par une nouvelle révision et un enregistrement d’impact, sans écraser l’ancien dossier de décision.

le flux de bout en bout du logiciel de certification de produits décrit le modèle de données plus large entre la demande et le certificat. le guide sur la révision et l’historique d’approbation des documents détaille quant à lui la manière de préserver la piste des modifications.

Quels scénarios tester dans le pilote de Vizyon Cert ?

Vizyon Cert lors de l’évaluation, choisissez une seule famille de produits et un dossier réel mais anonymisé. Établissez d’abord les liens corrects entre produit, programme, exigences et preuves ; testez ensuite si le système bloque réellement la décision dans les scénarios défavorables.

• Téléchargez un rapport d’essai appartenant à une mauvaise révision du produit.
• Laissez une exigence obligatoire sans preuve.
• Tentez d’ouvrir une décision avec une non-conformité non soldée.
• Désignez comme examinateur l’utilisateur qui a réalisé l’évaluation.
• Après le dossier de décision, modifiez le plan et vérifiez que le dossier historique n’a pas changé.

Le critère de succès ne se réduit pas à l’étiquette « dossier complet ». Le système doit indiquer pour quelle exigence porte le manquement, conserver la piste du nouvel examen après correction et ne présenter au décideur que la version valide.