Comment fonctionne un logiciel de certification de produits ? Du dossier technique au certificat

Que fait un logiciel de certification de produits ?

Un logiciel de certification de produits gère, dans un dossier unique et traçable, la candidature, la famille de produits et ses variantes, le programme applicable, le dossier technique, les tâches d'essai, d'inspection et d'audit, les constats, la revue et la décision, le périmètre du certificat, la surveillance et les modifications du produit.

L'objectif n'est pas de produire plus rapidement un PDF de certificat. Le véritable objectif est de pouvoir montrer quel produit a été évalué selon quelles exigences techniques, avec quels échantillons et quelles preuves, sur quelle version du dossier repose la décision, et si une modification ultérieure affecte ou non le périmètre du certificat. Le logiciel organise cette chaîne de preuves ; il n'assume ni la compétence de l'organisme d'évaluation de la conformité, ni les règles du propriétaire du programme, ni les obligations du fabricant, ni la décision de l'autorité.

Que déterminent l'ISO/IEC 17065 et l'ISO/IEC 17067 ?

L'ISO/IEC 17065 fixe les exigences des organismes réalisant la certification de produits, de processus et de services ; l'ISO/IEC 17067 fournit quant à elle le guide fondamental pour comprendre, élaborer et exploiter les programmes de certification de produits.

Selon la page de statut ISO en date du 11 juillet 2026, l'ISO/IEC 17065:2012 demeure la version publiée ; elle a été réexaminée et confirmée en 2024 et devrait être remplacée dans les prochains mois par l'ISO/IEC FDIS 17065. L'ISO/IEC 17067:2013 est également toujours la version publiée ; l'ISO/IEC FDIS 17067 est en cours d'élaboration pour la deuxième édition. Cette perspective de transition montre que le logiciel doit gérer la norme non seulement par son nom, mais par son édition, la version du programme et sa date d'entrée en vigueur. [1] [2]

TÜRKAK traite l'accréditation des organismes de certification de produits dans le cadre de la TS EN ISO/IEC 17065, des documents et guides obligatoires EA/IAF applicables. Selon l'activité requise par le produit ou le programme, les exigences applicables de l'ISO/IEC 17025 pour les essais, de l'ISO/IEC 17020 pour l'inspection et de l'ISO/IEC 17021-1 pour l'audit de système de management peuvent également entrer en jeu. Un logiciel de certification de produits n'est donc pas un simple module documentaire ; c'est une couche d'orchestration qui relie différentes sources d'évaluation au sein d'un même dossier de décision. [3]

De quelles étapes se compose le flux numérique du dossier technique au certificat ?

Le flux se compose de la candidature et du choix du programme, de l'identification du produit, du dossier technique, des tâches d'évaluation, de la clôture des non-conformités, de la revue, de la décision, du certificat et du suivi surveillance/modifications.

Dans une candidature, définit-on d'abord le produit ou le programme ?

L'identité du produit et l'usage prévu sont d'abord clarifiés ; ensuite la réglementation technique applicable, le document normatif et le programme de certification sont rapprochés par un examen habilité.

Des appellations larges comme « appareil électrique », « machine » ou « produit de construction » ne suffisent pas en elles-mêmes. Le nom commercial, le modèle, la variante, les spécifications techniques, l'usage prévu, le groupe d'utilisateurs, le lieu de fabrication, le marché cible et, le cas échéant, les certificats/rapports existants doivent être conservés dans des champs structurés. Un même produit avec une tension, un matériau, une version logicielle ou une option de composant critique différent peut nécessiter une évaluation distincte.

Le choix du programme ne doit pas être fait au hasard dans une liste déroulante. Le propriétaire du programme, le document normatif, le schéma de certification, les activités d'évaluation requises, l'approche de surveillance, l'usage des marques et le périmètre d'autorisation de l'organisme doivent être examinés ensemble. L'ISO/IEC 17067 fournit un cadre pour comprendre et exploiter les programmes ; elle ne détermine toutefois pas à elle seule quelle législation ou quel module s'applique à un produit donné. [2]

Comment le classeur du dossier technique devient-il un modèle de données traçable ?

Chaque document doit être relié au produit/modèle, à l'exigence, à la version, à l'émetteur, à la date, à l'état d'évaluation et à l'enregistrement d'essai/inspection/décision correspondant.

Le contenu susceptible de figurer dans le dossier technique varie selon le produit et la règle applicable. La description du produit, les plans de conception/fabrication, la liste des pièces ou matériaux critiques, l'analyse des risques, les normes appliquées, les rapports d'essai, les enregistrements d'inspection, le mode d'emploi, la conception des étiquettes/marques et les informations de contrôle de la production en sont des exemples fréquents. Le logiciel ne doit pas présenter cette liste comme une liste de contrôle réglementaire universelle et immuable ; il doit la versionner selon le programme choisi et la réglementation technique.

La Décision 768/2008/CE de l'Union européenne contient le cadre commun prévoyant que le fabricant établit la documentation technique requise et met en œuvre ou fait mettre en œuvre la procédure d'évaluation de la conformité applicable, et que la documentation technique est suffisamment détaillée pour permettre l'évaluation de la conformité du produit aux exigences pertinentes. Des éléments tels que les plans, les descriptions, les normes appliquées et l'évaluation des risques sont donnés en exemple dans les textes des modules. Cette source ne dit pas que le même dossier technique suffit pour chaque produit ; la législation sectorielle et le module sont déterminants. [4]

Comment rattacher les enregistrements d'échantillons, d'essais et d'inspections ?

Chaque résultat d'évaluation doit être rattaché à l'identité correcte du produit et de l'échantillon, à la méthode utilisée, au laboratoire ou à l'organisme d'inspection et à la version immuable du rapport.

À la réception de l'échantillon, le numéro de série/lot, le modèle, la variante, la quantité, les photos, les informations de scellage ou de livraison et les conditions de conservation doivent être suivis. Si l'essai ou l'inspection est confié à un prestataire externe, la commande, le périmètre, le rapport, la révision et l'évaluation de l'organisme doivent rester dans le même dossier. Le fait qu'un rapport soit chargé dans le système ne signifie pas qu'il est automatiquement accepté ; il doit être examiné quant à l'identité du produit, la méthode, le périmètre, le résultat et l'autorisation.

Si le programme d'évaluation comporte un audit du lieu de fabrication, le plan, l'équipe, le site, les processus, les preuves et les constats sont rattachés au dossier produit. L'audit de système de management, l'essai du produit et l'inspection du produit sont des activités distinctes ; le logiciel ne doit pas toutes les fusionner sous l'appellation « rapport d'audit » au prix de la perte de la distinction de méthode et de compétence. La déclaration TÜRKAK sur la certification de produits montre à cet égard que, selon le programme, les exigences applicables de l'ISO/IEC 17025, de l'ISO/IEC 17020 ou de l'ISO/IEC 17021-1 peuvent entrer en jeu. [3]

Le certificat peut-il être publié automatiquement dès la clôture de la non-conformité ?

Non. Le traitement de la non-conformité, l'achèvement du dossier d'évaluation et l'étape habilitée de revue/décision doivent être séparés ; le logiciel ne doit soutenir que le flux de contrôle et de preuves.

Un enregistrement de non-conformité doit faire apparaître l'exigence concernée, la preuve, le périmètre, le responsable, la correction, l'exigence d'action corrective/analyse de cause racine, le document fourni et le résultat de vérification. Le dépôt d'un nouveau fichier par le demandeur ne doit pas clore l'enregistrement de lui-même. L'évaluateur consigne la suffisance de la preuve ; si le dossier comporte un point ouvert ou conditionnel, la personne habilitée à décider en est informée avec l'état exact.

L'écran de décision peut résumer les résultats, signaler les contradictions et bloquer les champs obligatoires manquants. Toutefois, les décisions telles que la délivrance du certificat, la réduction du périmètre, la demande d'une évaluation complémentaire, la suspension ou le retrait doivent être consignées avec leur justification par des personnes habilitées, conformément au programme et à la procédure de l'organisme. Si un rapport d'essai change ultérieurement, l'ancienne décision ne doit pas être silencieusement rattachée au nouveau rapport ; une étude d'incidence doit être ouverte.

Comment contrôler le périmètre du certificat et l'usage des marques ?

Le certificat doit correspondre exactement au produit, au modèle, au document normatif, au programme, au lieu de fabrication et aux conditions approuvés dans la décision ; l'usage des marques ne doit être géré que selon l'autorisation réelle.

Des champs tels que le numéro de certificat, la première émission, la validité, la révision, la description du produit, les modèles, la version norme/programme, le fabricant et le lieu de fabrication doivent être générés à partir de l'enregistrement structuré. Une correction après approbation doit ouvrir une nouvelle version du certificat ; le PDF précédent et l'enregistrement de vérification doivent être conservés. Tandis que le portail client met en avant le seul document à jour, l'utilisateur interne doit pouvoir consulter l'historique des modifications.

Le logiciel ne doit pas transformer la bibliothèque de logos ou de marques de conformité en une zone de libre création. Le marquage CE, la marque d'accréditation, la marque du programme et le logo de l'organisme de certification obéissent à des règles juridiques et contractuelles différentes. Aucune marque ne doit être apposée sur un document sans vérification de l'autorisation, du périmètre, des règles graphiques et de l'approbation d'usage. L'expression « le système a produit le certificat » ne prouve pas à elle seule la conformité réglementaire du produit ni l'autorisation accréditée de l'organisme.

La certification de produits, le CE et la réglementation technique sont-ils un seul et même processus ?

Non. La réglementation technique applicable détermine le chemin d'évaluation de la conformité à suivre ; certains chemins impliquent un tiers, d'autres peuvent reposer sur des modules relevant de la seule responsabilité du fabricant.

Le Livre bleu 2022 de la Commission européenne est un guide complet expliquant l'application des règles de l'Union relatives aux produits ; le guide n'est pas lui-même un texte législatif contraignant et la force juridique réside dans la législation d'harmonisation de l'Union concernée. Il traite ensemble des rôles des opérateurs économiques, de la documentation technique, des organismes d'évaluation de la conformité, de l'accréditation, de la surveillance du marché et des limites relatives au marquage CE. C'est pourquoi, dans le logiciel, l'enregistrement du marché cible du produit et de la législation applicable est un point de départ plus juste qu'un générique « certification CE ». [5]

En Turquie, dans le cadre de la loi n° 7223 sur la sécurité des produits et les réglementations techniques, les produits doivent être conformes à la réglementation technique applicable ; la page officielle de la FAQ du ministère du Commerce indique qu'un produit ne peut être mis sur le marché, maintenu sur le marché ou mis en service sans que la non-conformité ait été levée. Le Règlement sur les méthodes d'évaluation de la conformité explique quant à lui que le ou les modules à suivre pour un produit sont précisés dans la réglementation technique concernée. Le logiciel peut offrir une bibliothèque de règles aidant à sélectionner la législation ; le choix final doit être déterminé par le texte officiel à jour et l'évaluation habilitée. [6] [7]

Pourquoi suivre la modification du produit et la surveillance dans le même dossier ?

Parce qu'un changement de matériau, de composant, de lieu de fabrication, de conception ou de logiciel peut affecter la validité des preuves antérieures et du périmètre du certificat.

Lorsque le demandeur signale un changement, le système doit comparer l'ancienne et la nouvelle structure du produit et marquer les plans, risques, essais, inspections, enregistrements de production et de certificat concernés. Un changement ne peut pas être clos automatiquement par l'option « mineur ». La personne habilitée doit déterminer, avec un enregistrement de décision, si un nouvel essai, des documents complémentaires, un examen du lieu de fabrication ou une révision du certificat sont nécessaires.

Si un programme de surveillance existe, les enregistrements de dates, d'activités, d'échantillons, de marché ou de lieu de fabrication sont planifiés selon la règle du programme. Les retards, résultats ou non-conformités sont rattachés à l'état du certificat. Les réclamations et les appels sont également gérés dans un flux distinct d'autorisation et de confidentialité ; ils ne doivent pas se perdre en simples notes du service client. Lorsque le programme change, la version selon laquelle les dossiers ouverts seront achevés doit être déterminée conformément à une règle de transition écrite.

Quels enregistrements un modèle de données robuste de certification de produits distingue-t-il ?

Le produit, le modèle, la variante, l'exigence technique, la preuve, l'échantillon, l'évaluation, le constat, la décision et le certificat doivent être des objets distincts ; leurs relations doivent être établies avec les informations de version et de date.

• Famille de produits : Relation entre modèle principal, variante et composant critique.
• Matrice d'exigences : Réglementation technique, article de norme/programme et état des preuves.
• Version du document : Émetteur du dossier, date, périmètre produit et lien avec la version précédente.
• Chaîne des échantillons : Réception, identité, conservation, expédition, essai/inspection et enregistrement de retour/destruction.
• Évaluation externe : Organisme chargé de la mission, périmètre, rapport et résultat de l'examen technique.
• Lien de décision : Évaluations et versions de dossiers utilisées par la décision.
• Cycle du certificat : Émission, révision, suspension, retrait, validité et état de vérification.
• Incidence du changement : Élément modifié, preuves affectées, activité requise et décision.

Cette séparation permet d'interroger pour quelles variantes un même rapport d'essai est utilisé, ou quels certificats doivent être revus lorsqu'un composant change. Dans un système fondé sur la seule arborescence de dossiers, ces relations sont laissées aux noms de fichiers et à la mémoire des utilisateurs.

Comment planifier la migration vers un logiciel de certification de produits ?

On modélise d'abord le flux réel de dossier technique et de décision d'un programme ; le pilote est ensuite validé avec les scénarios de famille de produits, d'évaluation externe, de certificat et de modification.

1. Établissez l'inventaire des programmes et des documents

Rassemblez le formulaire de candidature, la liste des exigences, le formulaire d'échantillon, les enregistrements d'essai/inspection, le rapport d'audit, les constats, la décision, le certificat, la règle d'usage des marques et le plan de surveillance. Déterminez la source de chaque document et le rôle qui l'approuve.

2. Construisez l'arbre de preuves avec une seule famille de produits

Choisissez un modèle principal et au moins deux variantes. Séparez les documents techniques communs et les preuves propres au modèle. Suivez lors du pilote quels rapports sont affectés par un changement d'un composant critique.

3. Testez le flux externe laboratoire/inspection

Testez la commande, l'expédition des échantillons, l'acceptation des rapports, la révision et les étapes d'examen technique avec des scénarios d'erreur réels. Un rapport se rapportant à un mauvais modèle ou un périmètre incomplet doit être rendu visible par le système.

4. Validez la décision et la révision du certificat

Testez ensemble le rôle habilité de décision, le blocage en cas de dossier incomplet, la sélection du périmètre, la version du certificat et l'état de vérification de l'ancien document. La production d'un PDF ne doit pas faire présumer que le contrôle de la décision est achevé.

Quelles sont les erreurs les plus fréquentes avec un logiciel de certification de produits ?

Les plus grandes erreurs sont : considérer CE et certificat comme synonymes, dissoudre les variantes sous un seul produit et accepter automatiquement une preuve dès qu'un fichier est chargé.

• Figer le programme : Utiliser la même liste d'exigences pour tous les produits et marchés.
• Se fier au nom de fichier : Laisser le lien produit/version/exigence au seul nom de fichier.
• Perdre la trace de l'échantillon : Ne pas rattacher le résultat d'essai au bon numéro de série/lot et à la bonne variante.
• Approuver automatiquement un rapport externe : Ne pas soumettre la concordance périmètre/méthode/produit à l'examen technique.
• Subordonner la décision à la production du PDF : Utiliser la génération du document à la place de la décision habilitée.
• Utiliser librement les marques : Apposer le CE ou la marque d'accréditation/du programme sans vérifier les autorisations et les règles graphiques.
• Traiter le changement comme une simple note : Ne pas évaluer l'incidence d'une révision du produit sur les preuves et le certificat.

Comment Vizyon Cert soutient-il le processus de certification de produits ?

Vizyon Cert peut réunir, dans un dossier opérationnel unique conforme à la structure de programmes et d'autorisations de l'organisme, les enregistrements de candidature, de famille de produits, de dossier technique, de tâches d'évaluation, de constats, de décision, de certificat et de surveillance.

Sur la page de la solution Vizyon Cert, vous pouvez découvrir la structure modulaire de l'opération de certification. Le service de logiciel de certification, dans ce cadre, analyse les programmes, formulaires, décisions et intégrations existants afin de concevoir le modèle de données approprié. L'installation du logiciel ne signifie pas que l'organisme devient automatiquement conforme à l'ISO/IEC 17065 ou accrédité ; le processus et l'application doivent être validés par des évaluations habilitées.

Pour une démonstration, préparer une famille de produits anonyme, deux variantes, un rapport d'essai, une non-conformité, un changement de composant et une révision de certificat donne le résultat le plus réaliste. Analyse de processus avec VizyonTech : une démarche de bout en bout, du dossier technique à la décision, peut être menée sur ces exemples.

Foire aux questions