Une norme IA ne rend pas un usage sérieux

Les normes arrivent avec un vocabulaire rassurant. Gestion des risques. Gouvernance des données. Traçabilité. Supervision humaine. Qualité. Conformité. Chaque mot semble promettre que l’usage de l’IA deviendra, par la force d’un cadre bien rangé, plus sérieux qu’il ne l’était hier.

L’Europe avance sur ce terrain. La Commission indique que CEN et CENELEC travaillent sur des normes harmonisées dans dix domaines liés aux systèmes d’IA à haut risque. Une première proposition, prEN 18286, est entrée en enquête publique fin 2025 pour traiter le système de management de la qualité visé par l’article 17 de l’AI Act. Les projets de lignes directrices sur la qualification du haut risque restent, eux, en consultation jusqu’au 23 juillet 2026.

Ce mouvement est nécessaire. Il ne faut pas le confondre avec une réponse complète.

Une norme n’améliore pas un usage parce qu’elle existe. Elle n’empêche pas une mauvaise décision parce qu’elle a été achetée, citée dans une présentation ou ajoutée à une politique interne. Elle devient utile lorsqu’elle oblige une organisation à répondre à des questions que le travail réel peut contredire : quel système fait quoi, sur quelles données, pour quelle décision, avec quelle personne responsable et quelle preuve après coup ?

Avant cela, la norme est souvent un meuble de plus dans le couloir de la gouvernance.

La norme n’est pas le système

Le premier malentendu consiste à traiter la normalisation comme une propriété attachée à l’IA elle-même. Il suffirait d’avoir un outil sérieux, un fournisseur réputé ou un référentiel correct pour que l’usage devienne conforme par contagion.

Ce n’est pas le raisonnement du règlement. L’AI Act organise des obligations selon les risques et les rôles : fournisseur, déployeur, importateur, distributeur, personne affectée. La Commission rappelle que les systèmes à haut risque doivent être identifiés à partir de cas d’usage précis, notamment quand ils peuvent affecter la santé, la sécurité ou les droits fondamentaux. Ses lignes directrices donnent des exemples ; elles ne remplacent pas le travail de qualification.

Un même outil peut donc prendre des visages très différents. Un assistant qui reformule une note publique n’a pas le même poids qu’un système qui classe des candidatures, évalue l’accès à une formation, priorise des dossiers ou produit une recommandation reprise dans une décision. Les mots “IA générative” ou “agent” ne suffisent pas à les mettre dans la même boîte.

Pour une PME, c’est une bonne nouvelle, à condition de ne pas la gaspiller. Elle n’a pas besoin de faire semblant d’exploiter une usine de modèles pour chaque assistant de bureautique. Elle doit en revanche savoir distinguer les usages banals des usages qui deviennent sensibles par la matière qu’ils traitent ou la décision qu’ils influencent.

La simplicité n’est pas l’absence de règles. C’est une règle qui colle au geste réel.

Ce que les standards promettent vraiment

Les normes harmonisées ont une fonction précise. Lorsqu’elles sont publiées et référencées au Journal officiel de l’Union européenne, leur application peut donner une présomption de conformité pour les exigences couvertes. La Commission le dit aussi clairement : leur application demeure volontaire. Une entreprise peut choisir un autre moyen de démontrer qu’elle respecte ses obligations.

Cette nuance compte. Une norme n’est ni un talisman ni une dispense de jugement. Elle est une voie de preuve reconnue.

La promesse est substantielle. Un standard bien conçu peut éviter que chaque organisation invente seule son vocabulaire de risque, sa méthode de journalisation ou sa manière de décrire un changement de modèle. Il peut rendre les attentes plus lisibles pour un fournisseur, un client, un auditeur ou une autorité. Il peut surtout empêcher que la conformité dépende uniquement de la personne la plus méthodique dans la pièce.

Le contrepoint est que la présomption ne crée pas les faits qu’elle est censée organiser. Si personne ne sait expliquer pourquoi un modèle a été mis dans un flux, quelles données l’alimentent, quand une sortie doit être rejetée et comment un incident remonte, le système de management devient un cahier très propre posé sur une table instable.

Le problème n’est pas la documentation. C’est la documentation qui arrive avant la pratique qu’elle prétend décrire.

Le risque de normaliser le vide

Dans beaucoup d’organisations, l’IA arrive d’abord comme une série de possibilités vagues. Un outil de rédaction, un assistant de réunion, une recherche augmentée, une fonction de tri, une promesse de copilote. La direction demande alors une charte, une formation, un référentiel, parfois une certification. Cela donne rapidement l’impression d’agir.

Mais une question plus simple demeure souvent sans réponse : quel problème précis essaie-t-on de résoudre ?

Sans cette réponse, les mots de la conformité gonflent. On écrit “supervision humaine” sans nommer la personne qui relit. On écrit “qualité des données” sans savoir quelles données entrent réellement. On écrit “traçabilité” alors que les décisions sont reprises dans des courriels, des tableurs et des appels où personne ne conserve la chaîne de raisonnement. On écrit “gestion du risque” sans avoir défini l’erreur qui ferait arrêter le cas d’usage.

Ce sont des formules honorables. Elles deviennent fragiles dès qu’un client demande pourquoi une recommandation a été suivie, qu’un salarié conteste une décision ou qu’une sortie fausse se propage dans un dossier.

La normalisation ne doit pas servir à faire monter une organisation sur l’échelle des mots. Elle doit la faire descendre dans le détail de son travail.

Une fiche d’usage avant un grand programme

La méthode la plus praticable n’est pas de commencer par un catalogue de standards. C’est de prendre un usage existant et de le mettre à plat.

Une fiche tient sur une page. Elle demande six choses :

Question	Ce qu’il faut pouvoir répondre
Quel travail ?	La tâche précise, pas le nom vague de l’outil.
Quelle entrée ?	Les données, documents ou signaux transmis.
Quelle sortie ?	Brouillon, classement, recommandation, décision ou automatisation.
Qui valide ?	La personne qui peut corriger, accepter ou refuser.
Quelle erreur compte ?	L’erreur qui ferait du tort, ferait perdre du temps ou créerait une obligation.
Quelle trace reste ?	L’endroit où l’on peut reconstituer le contexte après coup.

Cette fiche n’est pas une norme miniature. Elle est le matériau à partir duquel une règle sérieuse peut exister.

Prenons une fonction de résumé de réunion. Si elle ne reçoit que des notes internes peu sensibles et produit un brouillon relu par l’organisateur, le risque peut rester modéré. La trace utile est alors le compte rendu final et la personne qui l’a validé. Ajouter un registre de vingt pages ne rendra pas ce résumé plus exact.

Prenons maintenant un outil qui extrait des critères de candidatures ou hiérarchise des dossiers de formation. La même logique de résumé peut se rapprocher d’une décision qui affecte des personnes. Les entrées, les critères, les erreurs, le contrôle humain et la conservation des éléments changent de nature. C’est ici que les lignes directrices et les outils de normalisation deviennent une aide concrète plutôt qu’un décor institutionnel.

La différence ne tient pas dans le modèle. Elle tient dans la conséquence.

Le temps gagné ne suffit pas comme preuve

Les PME ont une tentation légitime : si un assistant fait gagner du temps, elles veulent l’utiliser vite. Le temps est rare, les équipes sont petites et les démonstrations sont souvent convaincantes. Il ne faut pas mépriser cet argument.

Mais le temps gagné au premier geste ne dit pas tout du coût total. Une synthèse peut être produite en trente secondes et demander vingt minutes de vérification. Un classement peut accélérer la première lecture et multiplier les contestations. Un texte peut sembler utilisable jusqu’au moment où il faut expliquer son origine, son exactitude ou son effet sur une décision.

La preuve utile ne consiste donc pas seulement à montrer que l’outil fonctionne. Elle consiste à montrer que l’organisation sait où il peut se tromper et qui porte encore la responsabilité de la sortie.

Les standards ont une valeur lorsqu’ils aident à produire cette preuve de manière répétable. Ils deviennent coûteux lorsqu’ils demandent à une petite équipe de simuler une maturité qu’elle n’a pas encore construite.

Il est parfaitement raisonnable de ne pas engager une grande démarche de conformité pour un usage qui n’existe encore que dans une présentation. Il est tout aussi imprudent de déployer un système qui affecte des personnes en espérant que les normes futures répareront le manque de préparation.

La maturité n’est pas un certificat

La publication de prEN 18286 en enquête publique est un signe important : l’écosystème européen prépare des outils plus structurés pour les obligations à venir. La Commission lie d’ailleurs le calendrier des règles à haut risque à la disponibilité de ces outils d’appui, avec des échéances désormais prévues en décembre 2027 pour certains systèmes autonomes et en août 2028 pour ceux intégrés à des produits réglementés.

Il serait toutefois dommage d’en tirer la mauvaise leçon. Attendre la norme finale ne dispense pas de comprendre ses usages. La télécharger ne dispense pas de les améliorer. Un audit ne remplace pas un responsable qui sait arrêter une sortie absurde avant qu’elle devienne une décision.

La maturité se voit moins dans la présence d’un badge que dans quelques réponses ordinaires. Peut-on dire pourquoi cet outil existe ? Peut-on identifier les données qu’il ne doit jamais recevoir ? Peut-on retrouver la personne qui a validé une sortie importante ? Peut-on nommer l’erreur qui justifierait de suspendre l’usage ?

Si ces réponses manquent, il n’y a pas encore de système à normaliser. Il y a un projet à regarder plus lentement.

Ce que Jachère retient

L’Europe a raison de préparer des normes pour les usages d’IA où l’erreur peut devenir un problème de droits, de sécurité ou de responsabilité. Les entreprises ont raison de chercher des repères communs plutôt que de réinventer seules la conformité.

Mais le bon ordre compte. D’abord le travail, ensuite la preuve, puis le cadre qui la rend comparable. Inverser cet ordre produit des politiques propres et des usages opaques.

Une norme ne rend pas un usage sérieux. Elle aide une organisation déjà décidée à regarder sérieusement ce qu’elle fait. C’est moins spectaculaire qu’un programme de transformation. C’est aussi le seul point de départ qui ne demande pas à la conformité de jouer le rôle d’une compétence absente.