AI Act : maîtrise de l’IA et obligation de former le personnel (article 4)

L’article 4 du règlement (UE) 2024/1689, le règlement européen sur l’intelligence artificielle (IA) dit AI Act, oblige les fournisseurs et les déployeurs de systèmes d’IA à faire monter en compétence les personnes qui les font fonctionner. Applicable depuis le 2 février 2025, il a été réécrit par le règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026, et il est devenu une obligation de moyens. Cette page détaille ce que le texte exige, ce qu’il n’exige pas, et comment construire un programme proportionné qui laisse une trace défendable.

→ Lire l’explication complète de la marmotte

Article 4 de l’AI Act, texte d’origine et texte en vigueur

La version publiée au Journal officiel (JO) du 12 juillet 2024 imposait de « garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA ». La formule mélangeait déjà deux logiques : « garantir » tire vers le résultat, « dans toute la mesure du possible » tire vers les moyens. Personne ne savait mesurer un « niveau suffisant », ce qui laissait toute la place aux certificats vendus pour le combler.

Le règlement (UE) 2026/1744 (omnibus numérique sur l’IA, publié au JO du 24 juillet 2026) remplace l’article par trois paragraphes (article 1er, point 5). Le premier impose de « prendre des mesures pour favoriser le développement de la maîtrise de l’IA » et précise que l’obligation « ne contraint pas » à garantir un niveau spécifique chez un individu. Les deux autres paragraphes ne visent pas les organisations, mais la Commission, les États membres et le Comité IA (le Comité européen de l’intelligence artificielle).

Le schéma montre qui doit quoi dans chaque version : les flèches qui atteignent les fournisseurs et déployeurs sont celles qui créent une obligation.

Le considérant 8 du règlement 2026/1744 dit les choses franchement : une obligation stricte de garantir un niveau suffisant n’était pas adaptée à tous les fournisseurs et déployeurs et créait une charge de mise en conformité supplémentaire, surtout pour les petites entreprises, alors que la maîtrise de l’IA reste une priorité stratégique. Il cite le DigComp (Digital Competence Framework for Citizens, le cadre européen des compétences numériques) comme exemple de cadre dont la Commission et les États membres peuvent tenir compte. L’obligation est allégée, elle n’est pas supprimée. Lire l’omnibus comme un enterrement de l’article 4 est une erreur de la même famille que l’achat d’un badge « AI Act ready », qui ne figure dans aucun article du règlement. Les dates d’application et la portée globale de l’omnibus sont détaillées sur la page calendrier de l’AI Act.

La définition de l’article 3, point 56, n’a pas bougé : la maîtrise de l’IA désigne les compétences, connaissances et la compréhension permettant de déployer des systèmes d’IA « en toute connaissance de cause » et de prendre conscience des possibilités, des risques et des préjudices potentiels. Le considérant 20 précise que le contenu varie selon le contexte : appliquer correctement les éléments techniques au développement, appliquer les bonnes mesures pendant l’utilisation, interpréter les sorties.

Qui est visé par l’obligation de maîtrise de l’IA

L’article 4 s’applique à tout fournisseur et à tout déployeur, quel que soit le niveau de risque du système. Un assistant conversationnel généraliste, un outil de tri de tickets, un modèle de scoring : tous déclenchent l’obligation dès qu’une organisation les met en service sous sa responsabilité. Comme les interdits de l’article 5 et la transparence de l’article 50, elle ne dépend pas de la classification haut risque.

Le déployeur est la personne qui utilise un système d’IA sous sa propre autorité, sauf dans le cadre d’une activité personnelle non professionnelle. Un particulier qui interroge un chatbot pour sa liste de courses n’est pas déployeur ; s’il l’utilise pour rédiger les devis de son entreprise, c’est l’entreprise (ou l’entrepreneur individuel lui-même) qui l’est. La frontière entre fournisseur et déployeur (et le cas où un déployeur devient fournisseur en modifiant un système) est traitée sur la page rôles de fournisseur et de déployeur ; le cas fréquent de l’intégration d’un modèle tiers par API (Application Programming Interface) est détaillé dans AI Act et modèle d’IA à usage général appelé par API.

Le périmètre humain est plus large que la masse salariale : « leur personnel et les autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte ». Entrent donc dans le champ :

les salariés, quel que soit leur service ;
les intérimaires et stagiaires qui manipulent l’outil ;
les prestataires et sous-traitants qui exploitent, supervisent ou paramètrent le système pour le compte de l’organisation.

Le cas des prestataires est celui qui se perd le plus souvent. Le contrat de prestation est le bon levier : une clause qui impose au prestataire de former ses intervenants sur les systèmes concernés et d’en fournir la preuve sur demande. Sans cette clause, l’organisation se retrouve à devoir former directement des personnes qu’elle ne gère pas.

Obligation de moyens, ce que « favoriser la maîtrise de l’IA » exige en pratique

Une obligation de moyens se juge sur la démarche, pas sur le résultat individuel. Concrètement, une démarche défendable réunit trois éléments : un programme proportionné au rôle de chaque population et au risque des systèmes utilisés, une mise en œuvre effective de ce programme, et une trace de ce qui a été fait. Le texte n’exige ni certification, ni diplôme, ni nombre d’heures minimal. Tout fournisseur de formation qui affirme le contraire vend un produit, pas une lecture du règlement.

Le compromis central se situe entre deux approches :

le socle générique pour tous : un module unique, déployé en masse, peu coûteux à produire et à tracer. Il coche une case, mais il ne traite ni le contexte d’utilisation ni les personnes concernées, deux critères que l’article 4 cite explicitement. Une opératrice qui supervise un outil de présélection de candidatures et un développeur qui branche un modèle sur une base clients n’ont aucun risque en commun au-delà des généralités ;
la formation ciblée par rôle : elle oblige à savoir qui utilise quoi, donc à tenir un inventaire des usages, et à maintenir plusieurs modules. Elle coûte plus cher au démarrage et en entretien, mais c’est la seule qui correspond à la lettre du texte (« en prenant en considération leurs connaissances techniques, leur expérience […] ainsi que le contexte »).

La recommandation est nette : un socle commun court, plus des modules par rôle rattachés à l’inventaire des systèmes. Le socle seul ne tient que dans une structure où un seul outil généraliste est utilisé de façon homogène et sans décision sur des personnes. Dès qu’un système touche des clients, des candidats ou du code mis en production, le module par rôle devient la partie qui compte. Un webinaire de quarante minutes suivi d’un quiz réussi à 100 % prouve surtout que le quiz était facile.

L’absence d’obligation de niveau individuel ne dispense pas de mesurer. Elle déplace la mesure : on vérifie l’efficacité du programme (taux de complétion par rôle, erreurs récurrentes constatées en exploitation, incidents liés à un mauvais usage) plutôt que de noter chaque personne.

Matrice rôles et contenus de formation à l’IA

La matrice ci-dessous associe chaque population à ce qu’elle doit savoir faire. Elle se lit ligne par ligne : la condition entre crochets indique quand le module devient nécessaire.

Deux points méritent d’être soulignés. Les équipes achats et juridique sont presque toujours oubliées, alors que ce sont elles qui signent les contrats fixant la rétention des données par le fournisseur et l’éventuel droit d’entraîner un modèle sur ces données. Ensuite, les pratiques interdites de l’article 5 ont leur place dans le module achats : c’est au moment de l’achat qu’un outil de reconnaissance des émotions sur le lieu de travail doit être arrêté, pas six mois après son déploiement.

Contenus de sécurité, ce que le modèle ne garantit pas

La partie sécurité est celle que les catalogues de formation traitent le plus mal, alors qu’elle correspond directement à la surface d’attaque créée par les utilisateurs. Le contenu minimal, pour toute population qui saisit des données dans un outil d’IA générative :

Exactitude : un modèle de langage produit du texte plausible, pas du texte vérifié. Les hallucinations (références inventées, articles de loi inexistants, noms de bibliothèques logicielles qui n’existent pas) se présentent avec la même assurance que les réponses justes. La règle à enseigner : toute sortie réutilisée hors de la conversation est relue par quelqu’un qui saurait la produire.
Confidentialité des données saisies : ce qui est tapé dans un prompt quitte le périmètre de l’organisation, sauf déploiement local. Selon le contrat, le fournisseur peut le conserver dans ses journaux, le faire relire par des humains pour modération, ou l’utiliser pour l’entraînement. Un secret collé dans une conversation doit être considéré comme exposé et renouvelé.
Injection de prompt : un document, une page web ou un courriel traité par l’assistant peut contenir des instructions qui détournent son comportement. L’utilisateur doit savoir qu’un assistant connecté à sa messagerie peut obéir à l’expéditeur d’un courriel plutôt qu’à lui.
Fuite par les fonctions annexes : partage public de conversations, extensions de navigateur, historique synchronisé sur un compte personnel.
Ingénierie sociale assistée : voix clonées, courriels rédigés sans faute, fausses demandes urgentes de la direction.

Le programme lui-même est une cible. Les campagnes d’hameçonnage déguisées en « formation AI Act obligatoire » exploitent précisément l’annonce d’une obligation réglementaire. La contre-mesure est organisationnelle : un canal unique et annoncé à l’avance pour la diffusion des modules, et une consigne explicite indiquant qu’aucune formation ne demande d’identifiants par courriel.

Ces contenus ne valent que s’ils s’appuient sur une règle écrite. La formation explique pourquoi ; la politique d’usage de l’IA générative dit ce qui est permis.

Sanctions et articulation avec l’article 26

L’article 4 ne figure pas dans les amendes harmonisées de l’article 99, paragraphes 3 à 5, qui visent l’article 5 puis les articles 16, 22, 23, 24, 26, 31, 33, 34 et 50. Seul l’article 99, paragraphe 1, peut s’y appliquer : il renvoie aux régimes nationaux de sanctions et aux autres mesures d’exécution, avertissements compris. Le règlement ne fixe aucun montant pour un manquement à l’article 4.

Le défaut de compétence pèse pourtant ailleurs, et plus lourdement :

l’article 26, paragraphe 2, oblige le déployeur d’un système à haut risque à confier le contrôle humain à des personnes qui disposent des compétences, de la formation et de l’autorité nécessaires. Ce manquement est passible d’une amende au titre de l’article 99, paragraphe 4, point e), dès l’application du régime du haut risque ;
en cas d’incident, l’absence de toute démarche de formation pèse dans l’appréciation de la diligence de l’organisation, devant une autorité de surveillance comme dans un autre cadre juridique.

Savoir si une organisation donnée est en règle ou ce qu’elle risque relève d’un avocat ; les textes de référence sont le règlement (UE) 2024/1689 sur EUR-Lex et le règlement (UE) 2026/1744, qui le modifie.

Ce que la maîtrise de l’IA ne garantit pas

Un personnel formé ne rend pas un système conforme. La classification de risque, la documentation technique, la transparence de l’article 50 et les obligations du haut risque restent entièrement à traiter. La formation n’en est qu’une pièce.

Un personnel formé ne rend pas non plus un système sûr. Si l’assistant interne peut lire tous les documents de l’organisation sans contrôle d’accès, un utilisateur parfaitement sensibilisé obtiendra quand même des réponses construites sur des données qu’il n’aurait pas dû voir. Les contrôles techniques (filtrage des sorties, validation des appels d’outils, cloisonnement des corpus, journalisation) relèvent de l’architecture, pas de la vigilance individuelle. Former à « ne pas croire le modèle » sans limiter ce que le modèle peut faire revient à transférer à l’utilisateur un risque de conception.

Enfin, la formation ne couvre que les outils connus. Un assistant public utilisé sans déclaration échappe à l’inventaire et donc au programme. La détection de ces usages fait l’objet de la page Shadow AI, détecter les assistants IA publics non déclarés.

Exemple de cycle inventaire, formation, preuve, révision

Le programme fonctionne comme une boucle, pas comme un événement annuel. Le schéma montre l’ordre des étapes et les déclencheurs qui relancent un tour de boucle.

Le point de lecture principal est la dernière flèche : la boucle repart sur un événement, pas sur une date. Un fournisseur qui ajoute la connexion à la messagerie dans son assistant change la surface d’attaque du jour au lendemain ; le module correspondant doit suivre sans attendre la campagne annuelle. Le format des micro-formations de sensibilisation régulières se prête mieux à ce rythme qu’une session annuelle.

La version du module dans le registre n’est pas un détail. Sans elle, il est impossible de savoir qui a été formé avant ou après l’ajout du chapitre sur l’injection de prompt, et la preuve perd la moitié de sa valeur.

Prérequis et conditions d’exploitation du programme

Avant de produire le moindre contenu, trois éléments doivent exister :

un inventaire des systèmes d’IA en usage, outils achetés, fonctions d’IA activées dans des logiciels existants et intégrations développées en interne compris. Les fonctions d’IA ajoutées discrètement à un logiciel de bureautique par une mise à jour sont les plus souvent oubliées ;
une politique d’usage écrite, sans laquelle la formation enseigne des principes que rien ne rend opposables ;
un responsable désigné pour le programme, avec l’autorité de bloquer la mise à disposition d’un outil tant que le module correspondant n’existe pas.

En exploitation, les conditions de durée sont les suivantes :

mise à jour à chaque nouvel outil ou changement de capacité d’un outil existant, déclenchée par le processus d’achat ou de demande d’accès plutôt que par la mémoire de quelqu’un ;
preuves conservées dans un registre minimal. Ce registre contient des données personnelles : le RGPD (règlement général sur la protection des données) s’applique, avec une durée de conservation définie et aucun résultat individuel détaillé si le programme n’en a pas besoin ;
prestataires couverts par une clause contractuelle et une attestation fournie à chaque renouvellement ;
supervision par les signaux d’exploitation : refus de filtrage, alertes de fuite de données vers des domaines d’assistants publics, incidents d’usage. Ces signaux disent quel module ne fonctionne pas, mieux que n’importe quel taux de complétion.

🐝 Ce qui arrive si on s’en passe

Sans programme rattaché à l’inventaire, chaque nouvel outil arrive chez des utilisateurs qui ignorent où partent leurs saisies. Les secrets et données clients collés dans les prompts finissent dans les journaux du fournisseur, hors de toute capacité d’effacement. Les opérateurs d’un système à haut risque valident les sorties par habitude, ce qui vide le contrôle humain de l’article 26 de sa substance et ouvre la voie à une amende harmonisée. Un assistant connecté à la messagerie exécute des instructions cachées dans un courriel sans que personne ne reconnaisse le symptôme. Et sans registre versionné, après un incident, rien ne permet de démontrer qu’une démarche existait, ni de savoir quelles populations n’avaient jamais été informées du risque.

🦫 Explication de la marmotte 🍫

Depuis février 2025, une loi européenne sur l’intelligence artificielle demande aux entreprises qui fabriquent ou utilisent ces outils de former les personnes qui s’en servent pour elles : salariés, stagiaires, intérimaires et prestataires extérieurs. Cette règle vaut pour tous les outils, même les plus banals. Un particulier qui utilise un chatbot pour lui-même n’est pas concerné.

En juillet 2026, la loi a été modifiée. Avant, l’entreprise devait garantir un niveau suffisant. Maintenant, elle doit faire des efforts réels, sans promettre que chaque personne atteindra un niveau précis. Aucun diplôme ni nombre d’heures n’est imposé.

En pratique, l’entreprise commence par lister les outils utilisés et qui s’en sert. Ensuite, elle prépare une formation de base pour tous, puis des formations spécifiques selon le métier : celui qui surveille un outil qui trie des candidats n’apprend pas la même chose que le développeur qui le programme. Les points essentiels : l’outil peut inventer des réponses fausses, ce qu’on y tape peut être conservé par l’entreprise qui le fournit, et un document lu par l’outil peut contenir des ordres cachés. Enfin, l’entreprise note qui a suivi quelle formation, et recommence à chaque nouvel outil.

Former les gens ne suffit pas à rendre un outil sûr ou légal : les protections techniques et les autres règles restent nécessaires. Si rien n’est fait, des données partent sans contrôle, et en cas de problème l’entreprise ne peut pas prouver qu’elle avait agi.

Pages voisines

La citent

AI Act : maîtrise de l'IA et obligation de former le personnel (article 4)

Elle cite