Comment construire la matrice de compétence des auditeurs avec les codes NACE et EA ?

Réponse courte : quelle décision la matrice doit-elle produire ?

La matrice de compétence des auditeurs doit montrer si une personne remplit simultanément, et non le seul code EA : le programme de certification, le domaine technique, le rôle, la date de mission et les preuves de qualification à jour.

Le NACE classifie l'activité du client ; le domaine EA/IAF aide à regrouper le périmètre d'accréditation. Aucun des deux ne constitue à lui seul une qualification d'auditeur. L'affectation ne doit être ouverte que lorsque les critères définis par l'organisation et les preuves vérifiées sont simultanément satisfaits.

Quelle est la différence entre le code NACE et le code EA ?

Le NACE classe l'activité économique en détail ; le domaine EA/IAF aide à exprimer le périmètre d'accréditation QMS et EMS dans des domaines techniques plus larges.

Eurostat publie la classification la plus récente sous le nom de NACE Rev. 2.1 et décrit son introduction progressive dans les statistiques européennes à partir de 2025. En revanche, le tableau des domaines QMS et EMS de l'IAF ID 1:2020 repose sur la NACE Rev. 2. C'est pourquoi votre matrice doit conserver, avec chaque code, le nom et la version de la classification également.

Plutôt que d'écraser manuellement la conversion des codes, utilisez une table de correspondance versionnée. Si une activité Rev. 2.1 se divise en plusieurs anciennes classes ou présente un cas limite, ne produisez pas de « conforme » automatique ; orientez la revue de périmètre vers le rôle habilité.

Comment concevoir les lignes et colonnes de la matrice de compétence ?

Construisez les lignes non pas sur le nom des personnes, mais sur l'unité de compétence sur laquelle porte la décision ; et les colonnes sur des critères démontrables.

La clé de ligne recommandée program + teknik alan + rol + görev türü est cette combinaison. La personne est rattachée à cette ligne ; mais les critères de la ligne et les preuves de la personne sont maintenus séparément. Ainsi, lorsqu'un critère change, on peut voir quelles personnes doivent être réévaluées.

1. Programme : La norme de système de management concernée et le jeu de documents normatifs utilisés.
2. Domaine technique : Le domaine EA/IAF, les activités NACE de soutien et la sous-découpe propre de l'organisation en risques/complexité.
3. Rôle : Revue de demande, audit, leadership d'équipe, expertise technique, revue de rapport ou décision de certification.
4. Critère : Les connaissances et compétences requises relatives au programme, au secteur, aux processus, à la réglementation et à la pratique d'audit.
5. Preuve : Un enregistrement comportant la source, la date, l'évaluateur, le périmètre, le résultat et, le cas échéant, la date de validité/revue.
6. Décision d'habilitation : La décision datée et motivée donnée par le rôle habilité ; restrictions, conditions et date de suivi ultérieur.

L'ISO/IEC 17021-1 établit le cadre général de compétence. Pour les QMS, des parties propres au programme comme l'ISO/IEC 17021-3 apportent des critères supplémentaires. TÜRKAK indique également que, dans les demandes de certification de système de management, les documents ISO, IAF, EA et TÜRKAK pertinents s'appliquent conjointement. C'est pourquoi un modèle à cellule unique du type « EA 17 validé » perd la distinction de programme et de rôle.

Quelles preuves doivent remplir une cellule ?

Une attestation de participation n'est pas à elle seule une décision de compétence ; il faut une chaîne de preuves montrant que les connaissances et compétences ont été évaluées par des méthodes appropriées.

Définissez à l'avance la méthode d'évaluation acceptée pour chaque critère. Un dossier de formation peut montrer l'acquisition de connaissances ; l'expérience sectorielle appuie le contexte ; un examen, un entretien, une revue de dossier ou une observation fournit la preuve d'évaluation qu'un critère donné est satisfait. La décision finale doit être enregistrée avec l'évaluateur habilité et la date.

• Le périmètre du programme, du domaine technique et du rôle couverts par la preuve est-il explicite ?
• La méthode d'évaluation mesure-t-elle réellement la connaissance ou la compétence visée ?
• Le résultat, l'évaluateur et la justification de la décision sont-ils consignés ?
• La date de la preuve est-elle compatible avec la date d'audit planifiée ?
• Le dossier de suivi, de témoignage ou de performance est-il à jour ?
• Y a-t-il une suspension, une restriction, un conflit d'intérêts ou un empêchement de disponibilité ?

La matrice ne doit pas être un tableau « présent/absent ». Utilisez des états explicables tels que conforme, non conforme, preuve manquante, périmètre/revue dépassés, restreint. Un enregistrement ambigu ou incomplet ne doit pas se transformer en résultat conforme.

Comment fonctionne le contrôle d'affectation fail-closed ?

Le périmètre de la mission est d'abord configuré ; l'habilitation du candidat est ensuite comparée au même périmètre et à la même date de mission. Tant que chaque contrôle obligatoire n'est pas franchi, l'affectation n'est pas enregistrée.

1. Lors de la revue de demande, les activités et les sites du client sont déterminés ; on ne se contente pas du code principal du registre de commerce.
2. Le code NACE et sa version sont enregistrés ; le domaine EA/IAF pertinent est déterminé avec la version de correspondance utilisée et la justification de la revue de périmètre.
3. Le programme de certification, le type d'audit, le rôle, la date planifiée et les compétences techniques requises sont extraits.
4. La décision d'habilitation complète du candidat, la preuve de suivi à jour, le rôle approprié et les contrôles de conflit d'intérêts sont appelés.
5. La personne et l'équipe dans leur ensemble sont évaluées séparément. L'IAF MD 11:2023 exige que, lors d'audits combinés, l'équipe soit suffisante pour chaque norme couverte et chaque domaine technique concerné.
6. S'il manque un contrôle, l'affectation s'arrête et la preuve requise est explicitement indiquée. En cas d'exception, son périmètre, sa durée, sa justification et son approbation indépendante sont consignés ; aucun passage silencieux n'est admis.

Le recours à un expert technique ne transfère pas automatiquement l'ensemble des responsabilités de l'auditeur. La composition de l'équipe et la répartition des missions doivent être déterminées selon les procédures en vigueur de l'organisation et les règles du programme ; le logiciel ne doit qu'appliquer des règles vérifiées.

Que deviennent les affectations en cours lorsqu'un code ou une compétence change ?

N'écrasez pas l'ancienne décision ; ouvrez une nouvelle version et placez les interventions planifiées concernées dans la file de réévaluation.

La transition de la NACE Rev. 2 à la Rev. 2.1, une modification du périmètre d'accréditation, une révision du document de programme, une restriction d'habilitation du personnel ou un changement du résultat de suivi peuvent affecter les plans existants. La version de la matrice, le jeu de règles, la table de correspondance et la décision d'affectation doivent être historisés sous des identités distinctes.

Une réévaluation ne signifie pas une annulation automatique. Le système liste les interventions concernées ; la personne habilitée compare les nouvelles et anciennes conditions. Mais tant que la revue n'est pas achevée, aucune nouvelle affectation ni plan d'audit ne doit être considéré comme « conforme ».

Pour gérer la durée d'audit au sein du même plan, vous pouvez utiliser le guide IAF MD 5 sur la durée des auditset, pour l'ensemble du flux de la demande à la décision, le guide du logiciel de certification de système .

Quels scénarios tester lors du pilote logiciel ?

Menez le pilote non seulement avec des affectations réussies, mais aussi avec des scénarios où des données erronées ou ambiguës sont bloquées en toute sécurité.

• Lorsque le bon programme et le mauvais domaine technique sont sélectionnés, l'affectation est-elle refusée ?
• Une activité dont la version NACE est inconnue ou qui correspond à plusieurs classes Rev. 2.1 remonte-t-elle en revue ?
• Si l'auditeur est adéquat mais qu'il manque un programme/domaine technique dans l'équipe globale, le plan s'arrête-t-il ?
• Si la décision d'habilitation existe mais que la preuve de suivi à jour manque, le système affiche-t-il la justification ?
• Si la date d'audit est postérieure à la date de revue d'habilitation, un nouveau contrôle est-il demandé ?
• Lorsqu'une version de règle ou de périmètre change, les dossiers ouverts entrent-ils dans la liste des éléments concernés ?
• La personne ayant fait l'affectation, la version de matrice utilisée et tous les résultats de contrôle sont-ils conservés dans la piste d'audit ?

Vizyon Alia lors de l'évaluation, exécutez ces scénarios négatifs avec les enregistrements réels mais anonymisés de demandes, périmètres et auditeurs de votre organisation. Le produit ne prend aucune décision d'accréditation ni de compétence ; il applique les critères approuvés par l'organisation dans un flux visible, versionné et fail-closed.