Les écarts que les praticiens rapportent le plus souvent

Aucune statistique publique et indépendante des non-conformités relevées en audit ISO/IEC 42001 n’existe. C’est un fait, et non une précaution de langage : la norme est jeune, les organismes ne publient pas leurs constats, et l’enquête annuelle de l’ISO ne couvre pas encore ce référentiel.

Toute page qui vous annoncerait « les 5 non-conformités les plus fréquentes » avec des pourcentages fabriquerait ces chiffres.

Ce qui suit est autre chose, et plus modeste : neuf écarts que plusieurs sources de terrain décrivent de façon convergente. La convergence n’est pas une mesure, mais elle vaut mieux qu’une intuition — et chacun de ces écarts s’explique par un mécanisme identifiable.

1. L’évaluation d’impact sans dimension sociétale

Le plus régulièrement rapporté, et le plus spécifique à cette norme. L’évaluation existe, elle examine les conséquences pour la personne concernée, et s’arrête là.

Pourquoi cela revient : une organisation qui aborde le sujet depuis sa pratique de protection des données examine naturellement l’individu, puisque c’est l’objet du droit applicable. Le contrôle A.5.5 porte précisément sur ce qui dépasse l’individu.

2. L’appréciation du risque calquée sur la sécurité de l’information

Le registre est solide sur la confidentialité, l’intégrité et la disponibilité, et muet sur la discrimination, l’iniquité et les effets sociétaux.

Pourquoi cela revient : c’est l’écart type de l’organisation déjà certifiée ISO/IEC 27001. Elle réutilise une méthode qui fonctionne sans changer l’objet du risque. Les clauses 6.1.2 et 6.1.4 regardent deux objets différents.

3. L’absence de revue d’efficacité des actions correctives

Les actions sont ouvertes, mises en œuvre, closes — et personne n’a vérifié qu’elles avaient produit un effet.

Pourquoi cela revient : l’examen d’efficacité est le quatrième temps de la clause 10.2, et le seul qui demande d’attendre. Un registre où chaque action est ouverte et close à la même date le signale immédiatement.

4. L’inventaire des systèmes d’IA incomplet

Il manque toujours les mêmes : l’assistant utilisé par une équipe métier, l’API appelée par un composant du produit, l’outil essayé puis conservé.

Pourquoi cela revient : l’inventaire se construit depuis les projets connus, alors que l’usage de l’IA n’entre pas par les projets. C’est ce que l’on nomme l’IA de l’ombre, et elle est rarement malveillante — simplement invisible.

5. Les services d’IA tiers absents de l’appréciation du risque

L’organisation appelle un modèle en production, et ce modèle n’apparaît ni dans le registre des risques ni dans la gestion des fournisseurs.

Pourquoi cela revient : le raisonnement « nous ne développons pas d’IA » est en partie juste et conduit à une conclusion fausse. Le dernier alinéa de la clause 8.1 impose la maîtrise des processus fournis par l’extérieur, et le domaine A.10 la décline.

6. La déclaration d’applicabilité sans justification substantielle

Les 38 contrôles sont déclarés applicables, ou écartés avec des motifs interchangeables qui ne renvoient à aucun risque du registre.

Pourquoi cela revient : déclarer tout applicable évite d’avoir à justifier. Mais le sens de lecture se voit — la clause 6.1.3 f) demande de partir des risques, pas du catalogue.

7. La supervision humaine nominale

Une personne est désignée pour valider, sans autorité réelle d’arrêter, sans temps alloué, et sans trace de la moindre décision contraire.

Pourquoi cela revient : la supervision est facile à écrire et coûteuse à exercer. L’auditeur demande combien de fois la personne a interrompu quelque chose.

8. Les responsabilités non clarifiées

Trois fonctions se croient concernées par le même sujet, et aucune n’en répond.

Pourquoi cela revient : la gouvernance de l’IA touche la technique, la conformité et le métier. Sans attribution explicite, chacun suppose que l’autre s’en occupe. Le test utile : qui peut arrêter une mise en production ?

9. La documentation qui décrit l’intention

Le système est écrit, cohérent, complet — et il n’a pas encore tourné. Les procédures emploient le futur.

Pourquoi cela revient : c’est le scénario de l’organisation qui a bien préparé son stade 1. Elle passe la revue documentaire sans difficulté et échoue au stade 2, qui vérifie l’exécution.

Ce qu’il faut retenir

Sept de ces neuf écarts ont la même origine : avoir transposé un système de management existant sans changer l’objet de ce qu’on gère. L’IA introduit un second objet de risque — les conséquences pour des personnes qui ne sont pas vos clients — et c’est cette bascule que la plupart des dossiers manquent.

Et une précision sur le statut de cette page : elle rapporte des constats de praticiens, datés de leur publication. Si une statistique indépendante paraît un jour, elle remplacera cette liste.