Clause 10 : amélioration continue et actions correctives
La clause 10 est courte et fait l'objet d'une erreur de citation tenace : elle ne comporte que deux sous-clauses. Il n'existe ni 10.3, ni 10.4.
La clause 10 comporte deux sous-clauses : l’amélioration continue en 10.1, la non-conformité et l’action corrective en 10.2. C’est tout.
Cette précision n’est pas pédante. On rencontre couramment des références à une « clause 10.3 » ou à une « clause 10.4 incidents » qui n’existent pas. Aucune des clauses 4 à 10 n’est d’ailleurs consacrée aux incidents liés à l’IA : s’il est retenu, le contrôle A.8.4 demande un plan documenté pour en informer les utilisateurs, et la norme donne des repères sur la réponse elle-même à propos de l’exploitation des systèmes (A.6.2.6 et ses lignes directrices B.6.2.6). Un incident ne relève de la clause 10.2 que s’il révèle une exigence non satisfaite : il se traite alors comme toute non-conformité. Préparer un dossier sur une numérotation inexistante fait perdre du temps et de la crédibilité.
10.1 — L’amélioration continue
Une seule phrase, et une exigence réelle. Ce que l’auditeur cherche est une trajectoire : des actions d’amélioration issues des revues de direction, des audits internes ou des incidents, avec un état d’avancement.
Le moment de relâchement est connu : l’année qui suit l’obtention du certificat. L’audit de surveillance intervient précisément dans cette fenêtre, et l’absence de toute action d’amélioration depuis la certification est un constat facile à établir.
10.2 — Non-conformité et action corrective
La norme n’impose pas d’ordre entre ces étapes, mais l’une d’elles est souvent oubliée. L’examen de l’efficacité de l’action corrective est une exigence explicite, et c’est une étape qu’on a tendance à escamoter une fois l’action lancée. Une action marquée « clôturée » sans mesure de son effet ne démontre rien : ni que la cause a disparu, ni que l’écart ne se reproduira pas.
La distinction entre correction et action corrective mérite d’être tenue. Corriger, c’est réparer le symptôme — désactiver la fonction fautive, reprendre les dossiers mal traités. L’action corrective s’attaque à la cause — pourquoi ce système est-il entré en production sans revue. La norme fait corriger selon le cas, et fait toujours rechercher les causes pour décider s’il faut agir sur elles. Cette décision peut conclure qu’aucune action n’est nécessaire ; en pratique, noter les causes retenues et, quand on n’agit pas, pourquoi, rend la décision lisible en audit. Faire tourner cette démarche sans alourdir les équipes : c’est l’objet du guide sur le traitement des non-conformités.
Ce que la clause 10 ne demande pas
Ni méthode d’analyse de cause imposée — les cinq pourquoi, l’arbre des causes ou toute autre approche conviennent —, ni délai de clôture, ni outil de gestion des non-conformités.
Elle ne fixe pas non plus de délai de notification d’incident : ces délais viennent de la réglementation applicable et des contrats. Le règlement européen sur l’IA comporte ses propres obligations de signalement, indépendantes d’ISO/IEC 42001. La norme conduit en revanche à les recenser : si les contrôles A.8.4 et A.8.5 sont retenus, l’organisme documente son plan d’information des utilisateurs en cas d’incident et ses obligations d’information envers les parties intéressées, et l’Annexe B lui recommande de connaître ses obligations de notification, délais compris.