Skip to content
AISO Learn AISO Learn - Home
Une marque du AISO Group Faire le Scorecard
Ressources / Règlement IA

Article 4 du Règlement IA de l'UE - ce que la "littératie IA" exige réellement de votre équipe.

Un guide pratique de l'Article 4 du Règlement IA de l'UE : à qui il s'applique, ce que la littératie IA signifie en pratique, quelle documentation soutient la préparation à l'Article 4 de l'AI Act, et comment bâtir un programme qui tient face à un contrôle.

Lead

Le 2 février 2025, l’Article 4 du Règlement IA de l’UE est entré en application. Les règles de supervision et de sanction s’appliquent à compter d’août 2026. Il est court. Il est vague. Il s’applique à presque tout le monde. Et il a posé une obligation silencieuse sur le bureau de chaque employeur européen qui laisse ses collaborateurs utiliser un outil d’IA au travail.

La clause dit que les fournisseurs et déployeurs de systèmes d’IA doivent prendre des mesures pour garantir un niveau suffisant de littératie IA de leur personnel et des autres personnes impliquées dans l’exploitation et l’utilisation de systèmes d’IA en leur nom. C’est toute la phrase. Elle ne définit pas “suffisant”. Elle ne précise pas d’heures de formation. Elle ne liste pas de programmes agréés. Ce qu’elle crée, c’est un standard par lequel un régulateur, un CSE ou un avocat de la partie adverse pourra vous mesurer après qu’un problème soit survenu.

Cet article est le guide pratique que nous aurions voulu avoir quand des clients ont commencé à nous interroger sur l’Article 4 fin 2024. Il couvre ce que la clause exige réellement - pas ce que des intervenants de conférence disent qu’elle exige - et la documentation que les organisations doivent pouvoir produire comme preuves prêtes. Il est tranché là où la loi est vague : nous disons comment nous la lisons et pourquoi. Là où la loi est claire, nous le disons sans détour.

Si vous êtes responsable de la littératie IA dans votre organisation et qu’il vous faut un programme défendable avant qu’un incident ne force la question, c’est pour vous.

Ce que dit réellement l’Article 4, en langage clair

  • Le texte de la clause, dépaqueté expression par expression
  • “Fournisseurs” vs “déployeurs” - lequel êtes-vous
  • “Personnel et autres personnes impliquées dans l’exploitation” - le périmètre est plus large qu’on croit
  • Ce que “suffisant” doit vouloir dire, au regard de la législation UE adjacente

La clause tient en une phrase. Lisez-la lentement :

Les fournisseurs et les déployeurs de systèmes d’IA prennent des mesures pour garantir, dans toute la mesure du possible, un niveau suffisant de littératie en matière d’IA pour leur personnel et les autres personnes impliquées dans l’exploitation et l’utilisation des systèmes d’IA en leur nom, en tenant compte de leurs connaissances techniques, de leur expérience, de leur éducation et de leur formation, ainsi que du contexte d’utilisation des systèmes d’IA et des personnes ou groupes de personnes sur lesquels les systèmes d’IA seront utilisés.

Trois expressions portent l’essentiel.

“Fournisseurs et déployeurs.” Un fournisseur est l’organisation qui construit, marque ou modifie substantiellement un système d’IA et le met sur le marché. Un déployeur est toute entité qui utilise un système d’IA dans un cadre professionnel - la case dans laquelle se range presque chaque employeur européen dès qu’un collaborateur ouvre ChatGPT, Copilot, Gemini, Claude ou n’importe quelle fonctionnalité d’IA intégrée à un outil SaaS pour faire son travail. Si votre équipe utilise l’IA au travail, vous êtes déployeur. Si vous construisez ou rebadgez aussi des fonctionnalités d’IA, vous êtes les deux.

“Personnel et autres personnes impliquées dans l’exploitation et l’utilisation … en leur nom.” Le périmètre dépasse les salariés permanents. Il atteint les contractants, le personnel d’agence, les freelances et les partenaires qui exploitent le système en votre nom. Le critère n’est pas le contrat. Le critère est de savoir si la personne utilise l’IA pour produire du travail pour vous.

“Niveau suffisant.” C’est la partie qui inquiète, et à raison. Le Règlement ne définit pas “suffisant”. Il n’y a pas de seuil d’heures de formation. Il n’y a pas de cursus agréé. Le standard est calibré sur le rôle, le risque, le contexte d’usage et les personnes affectées par le résultat. Ce qui veut dire que “suffisant” pour un marketeur junior qui utilise l’IA pour rédiger des publications sociales n’est pas “suffisant” pour un spécialiste RH qui filtre des CV avec l’IA, et aucun des deux n’équivaut au “suffisant” pour un ingénieur qui entraîne un modèle sur des données clients.

Les points de référence les plus proches dans la législation UE adjacente sont les garanties “appropriées” du RGPD et le repos “adéquat” de la directive Temps de travail. Dans les deux cas, les régulateurs lisent le standard à l’aune de ce qu’une organisation compétente du secteur devrait raisonnablement faire. L’Article 4 sera lu de la même manière. “Suffisant” veut dire défendable face à une attente raisonnable : ni parfait, ni un dossier d’achèvement, mais documenté, calibré au rôle et rafraîchi.

À qui l’Article 4 s’applique

  • Tout employeur dont le personnel utilise un outil d’IA tiers
  • Toute organisation qui construit ou intègre une fonctionnalité d’IA dans son propre produit
  • Contractants, freelances, personnel d’agence - pourquoi ils sont dans le périmètre
  • La question du petit employeur - existe-t-il une exemption (non, mais lisez la nuance)

Si votre organisation fait l’une des choses suivantes, l’Article 4 vous concerne :

Votre personnel utilise un outil d’IA tiers au travail. C’est le cas le plus large et le plus fréquent. Dès qu’un collaborateur utilise ChatGPT, Copilot, Gemini, Claude, Perplexity, un résumeur IA dans Notion ou Slack, une fonctionnalité IA dans votre CRM, ou toute autre fonction propulsée par l’IA pour produire un livrable, vous êtes déployeur au sens de l’Article 4. Version gratuite, payante, validée ou parallèle : peu importe. L’usage crée l’obligation.

Vous construisez ou intégrez une fonctionnalité d’IA dans votre propre produit. Si votre produit appelle une API de modèle, fait du fine-tuning sur un modèle, ou enveloppe une IA tierce dans votre interface, vous êtes fournisseur pour cette fonctionnalité. Les obligations de fournisseur s’ajoutent à celles de déployeur, vous portez donc les deux.

Vous faites appel à des contractants, freelances ou personnel d’agence qui manipulent l’IA en votre nom. Lacune classique. L’Article 4 s’étend explicitement aux “autres personnes impliquées dans l’exploitation et l’utilisation de systèmes d’IA en leur nom”. Si une designer freelance utilise Midjourney pour produire des visuels que vous diffusez, si une agence rédige vos campagnes avec ChatGPT, ou si un analyste sous contrat prépare vos rapports avec un outil d’IA, l’obligation les atteint à travers vous. Leur littératie, c’est à vous d’en apporter la preuve.

Vous êtes petit. Pas d’exemption à l’effectif. Le Règlement s’applique au plus petit cabinet en nom propre comme à la plus grande multinationale. Ce qui change avec la taille, c’est la forme concrète de “suffisant” : on n’attend pas d’une équipe de 6 personnes le même programme qu’une entreprise de 6 000. Mais l’obligation, elle, est identique. Les organisations plus petites s’orientent souvent vers une preuve plus légère et pragmatique : une politique écrite, une intégration courte, un calendrier de rafraîchissement, et un journal simple de qui a complété quoi. C’est suffisant, quand c’est réel.

À retenir : si quelqu’un lié à votre travail utilise l’IA pour produire un livrable, planifiez l’Article 4 comme s’il s’appliquait à vous, parce qu’il s’applique.

Le calendrier - ce qui est applicable quand

  • 2 février 2025 - Article 4 et clauses de pratiques interdites en application
  • 2 août 2025 - règles sur les modèles d’IA à usage général en application
  • 2 août 2026 - obligations systèmes haut risque et cadre de supervision et sanctions s’appliquent
  • Ce que l’échelonnement signifie pour la planification de votre programme de formation

Le Règlement IA est entré en vigueur le 1er août 2024 et s’active par étapes. Les dates qui comptent pour la planification de la littératie IA :

2 février 2025 - l’Article 4 est entré en application. Avec les clauses de pratiques interdites, c’est la première vague d’obligations à se fixer. La clause est en application maintenant. Ce qui n’est pas encore en vigueur, c’est le régime formel de supervision et de sanctions qui l’entoure : il arrive en 2026.

2 août 2025 - règles sur les modèles d’IA à usage général en application. Concerne surtout les fournisseurs de modèles de frontière et de modèles de fondation, ainsi que les organisations qui les fine-tunent ou les modifient substantiellement. La plupart des déployeurs ne sont pas directement touchés à cette date, mais l’outillage en amont qu’utilise votre équipe va évoluer en réponse - une raison de plus pour qu’un cycle de rafraîchissement importe.

2 août 2026 - obligations systèmes haut risque et cadre de supervision et sanctions s’appliquent. C’est la date sur laquelle beaucoup d’équipes s’ancrent mentalement, parce qu’elle apporte l’architecture d’application : autorités de surveillance du marché, évaluation de conformité pour les systèmes haut risque, et les sanctions financières associées aux manquements. À partir d’août 2026, l’obligation Article 4, en application depuis février 2025, s’inscrit dans un cadre de supervision actif.

2 août 2027 - certaines dispositions pour les systèmes haut risque déjà sur le marché continuent leur entrée échelonnée. Surtout pertinent pour les fournisseurs, pas pour la plupart des déployeurs.

Ce que ce calendrier échelonné signifie pour votre programme de formation : l’obligation est vive maintenant. La machinerie de sanctions s’active à partir d’août 2026. La fenêtre entre les deux est le temps pour bâtir un programme réel, calibré au rôle, rafraîchi et documenté, pour que, lorsque le régime de supervision arrivera, vous ne partiez pas de zéro. Les organisations qui souffriront en 2026 sont celles qui auront traité 2025 comme un report.

Ce que la “littératie IA” exige réellement - les quatre compétences

  1. Comprendre ce que fait le système d’IA, au niveau requis par le rôle
  2. Reconnaître les risques et limitations qui s’appliquent à votre cas d’usage
  3. Savoir quand le jugement humain est requis et comment l’exercer
  4. Pouvoir documenter et expliquer les décisions assistées par IA a posteriori

Voici à quoi ressemblent les quatre compétences en pratique, rôle par rôle. L’objectif n’est pas l’exhaustivité : il est de montrer comment “suffisant” se déplace avec le travail.

Juridique et conformité. La compréhension porte sur la manière dont le modèle traite la confidentialité, la conservation et l’attribution des sources. La conscience des risques inclut les citations hallucinées, la dérive de juridiction dans le raisonnement juridique et les fuites de confidentialité par les prompts. Le jugement humain est au cœur du métier : chaque livrable assisté par IA est revu contre les sources primaires et contre l’analyse propre du juriste avant de sortir du cabinet. Documentation : quels dossiers ont été assistés par IA, avec quels modèles, quelle revue a été faite, et ce que le juriste a modifié.

RH et gestion des personnes. La compréhension inclut la manière dont les outils de recrutement, de tri et de performance notent et classent les personnes, les features qu’ils utilisent et par où entrent les biais. La conscience des risques couvre les proxys de caractéristiques protégées, la dérive de scoring dans le temps, et la frontière entre automatisation d’appui et décision qui doit légalement être prise par un humain. Jugement humain : chaque shortlist, alerte de performance ou recommandation revue avant action. Documentation : registres de formation de l’équipe, journaux d’utilisation des outils d’IA pour les décisions d’embauche, et trace claire de l’endroit où se situe la décision humaine.

Marketing et contenu. La compréhension porte sur la manière dont les outils génératifs produisent du texte et des images, sur quelles données ils ont été entraînés, et sur les limites de la fiabilité factuelle. La conscience des risques couvre la dérive de la voix de marque, le risque de plagiat, les statistiques fabriquées et les obligations d’information du public. Le jugement humain est éditorial : chaque livrable rédigé par IA est revu pour exactitude, voix, allégations et droits. Documentation : quels livrables ont été assistés par IA, quelle revue a été faite, ce que le marketeur a modifié.

Ingénierie et produit. La compréhension inclut le fonctionnement des modèles de génération de code, les données sur lesquelles ils ont été entraînés, les risques du code suggéré, et la distinction entre autocomplétion et génération autonome. La conscience des risques couvre la contamination de licences, les vulnérabilités de sécurité dans le code suggéré, les secrets fuités dans les prompts, et la dépendance excessive. Jugement humain : revue de chaque suggestion acceptée, et pratique délibérée d’écrire le test avant d’accepter l’implémentation. Documentation : quelles fonctionnalités ont utilisé l’assistance IA, quels modèles ont été fine-tunés sur du code interne, et la trace de revue.

Support client et ventes. La compréhension couvre la manière dont les résumés IA, les réponses en brouillon et les outils de recommandation produisent leur sortie et où ils échouent. La conscience des risques couvre les énoncés erronés de politique, les engagements inventés, les fonctionnalités produit hallucinées et les décalages de ton avec la marque. Jugement humain : l’agent revoit chaque réponse générée par IA avant envoi, en particulier quand le client est dans une situation vulnérable, en litige ou dans un contexte régulé. Documentation : quelles interactions ont utilisé l’assistance IA, les chemins d’escalade, et les retouches de l’agent.

La forme se répète : les quatre compétences sont constantes. Le contenu et la profondeur évoluent avec le risque du rôle et la conséquence d’une erreur.

Quelle documentation les organisations doivent pouvoir présenter comme preuves prêtes

  • Une politique écrite de littératie IA - quelles sections elle doit contenir
  • Des registres de formation - qui a été formé, à quoi, par qui, avec quels supports
  • Des preuves d’évaluation - comment vous savez que la formation a fonctionné
  • Des registres d’incidents - quand l’usage IA a mal tourné et ce qui en a été appris
  • Un calendrier de conservation - combien de temps garder ce qui précède, et sous quel format

Il n’y a pas de format de fichier officiel pour l’Article 4. Il n’y a pas de portail de soumission. La Commission européenne a confirmé qu’aucun dossier d’achèvement délivré par un tiers n’est requis. Ce qui est requis, ce sont des registres internes qui, pris ensemble, montrent qu’une organisation compétente a pris des mesures adaptées au rôle et au risque. En pratique, quand un responsable conformité, un régulateur, un client, un CSE ou un conseil d’administration demande “montrez-nous vos preuves prêtes Article 4”, il cherche ces éléments :

Une politique écrite de littératie IA. Courte suffit, réelle est essentielle. Elle doit nommer qui elle couvre (y compris contractants et personnel d’agence), quels outils sont validés, ce qui est interdit, où poser ses questions, quelle formation est exigée pour quels rôles, et à quelle fréquence la politique elle-même est revue. Une à trois pages, avec un responsable nommé, datée, sous gestion de versions.

Des registres de formation. Qui a été formé, à quoi, par qui, avec quels supports, et à quelle date. Le registre doit être accessible par personne et par rôle. Les supports doivent être archivés dans la forme où ils ont été délivrés : si vous avez animé un atelier, conservez le deck et la liste de présence ; si vous avez utilisé un module e-learning, conservez la version et le journal de complétion. La formation fournie par l’éditeur convient comme une pièce du programme, pas comme l’ensemble.

Des preuves d’évaluation. Comment vous savez que la formation a fonctionné. Cela ne doit pas obligatoirement être un QCM. La preuve la plus forte, c’est la revue de production réelle : la première pièce assistée par IA d’un marketeur revue par un senior ; la première pull request assistée par IA d’un ingénieur revue contre les critères de littératie ; la première shortlist d’un spécialiste RH dont la revue est documentée. Le principe : l’évaluation intégrée au travail, pas plaquée par-dessus.

Des registres d’incidents. Quand l’usage IA a mal tourné, ce qui s’est passé, ce qui a été appris, ce qui a changé. “Mal” est large : une fuite de confidentialité, un fait halluciné parvenu à un client, un quasi-incident rattrapé en revue, une violation de politique. Le registre montre que l’organisation répond, apprend et met à jour son programme - ce qui est le cœur de “mesures suffisantes, tenant compte de l’expérience”.

Un calendrier de conservation. Combien de temps les registres sont gardés et sous quelle forme. Cinq ans pour les registres de formation est une valeur par défaut raisonnable dans la plupart des contextes UE ; alignez-vous sur votre politique de conservation plus large. Gardez ensemble la politique elle-même, les supports de formation, les registres de complétion, les preuves d’évaluation et le journal d’incidents pour qu’un évaluateur puisse lire l’histoire de bout en bout.

Voilà à quoi ressemble un dossier de preuves prêtes. Rien de tout cela n’exige un dossier d’achèvement délivré par un tiers. Tout cela est productible par une organisation compétente qui prend l’obligation au sérieux.

Erreurs courantes des employeurs

  • Traiter l’Article 4 comme un problème informatique
  • Se reposer sur la formation fournie par l’éditeur comme programme entier
  • Former une fois et ne jamais rafraîchir
  • Laisser contractants et personnel d’agence hors périmètre
  • Ne pas documenter - le plus dur à rattraper après coup

Les cinq motifs que nous voyons le plus souvent quand des employeurs nous arrivent en cours de programme :

Traiter l’Article 4 comme un problème informatique. Il ne l’est pas. C’est une obligation organisationnelle qui touche à la politique, aux personnes, à la formation et aux registres. La DSI peut valider des outils et verrouiller des secrets. Elle ne peut pas, à elle seule, prouver que le personnel comprend ce que les outils font, où ils échouent, et quand un jugement humain est requis. L’Article 4 a besoin que RH, juridique, management de proximité et DSI rament ensemble. Quand il reste cantonné à une initiative DSI, les couches politique et formation sont presque toujours absentes.

Se reposer sur la formation fournie par l’éditeur comme programme entier. La formation Copilot de Microsoft est bonne. Le module ChatGPT for Work d’OpenAI est correct. Ni l’un ni l’autre n’est un programme. La formation éditeur enseigne un outil. L’Article 4 demande une compétence spécifique au rôle, autour de l’usage de l’IA dans votre contexte, avec vos données, face à vos risques. Le matériel éditeur peut être une pièce. Il ne peut pas être la réponse.

Former une fois et ne jamais rafraîchir. Le texte de la clause dit que les mesures doivent tenir compte de l‘“expérience” - et les outils changent chaque trimestre. Un programme sans cadence de rafraîchissement vieillit vite. Fixez un intervalle de rafraîchissement aligné sur la vitesse à laquelle votre outillage change ; pour la plupart des équipes, c’est six à douze mois, pas une fois par an.

Laisser contractants et personnel d’agence hors périmètre. L’Article 4 atteint explicitement les “autres personnes impliquées dans l’exploitation et l’utilisation de systèmes d’IA en leur nom”. Si votre agence rédige vos campagnes avec l’IA et que vous n’avez pas étendu votre politique de littératie à cette agence, c’est une lacune. Le remède est contractuel : exigence de formation, attestation de politique et trace conservée de votre côté.

Ne pas documenter. L’erreur la plus difficile à rattraper après coup, parce que les événements que vous deviez documenter ont déjà eu lieu. Le motif est familier : une équipe mène une formation solide, construit une vraie capacité, et ne produit aucun registre. Dix-huit mois plus tard, un client demande une preuve et l’organisation ne peut pas la sortir. La documentation n’a pas besoin d’être lourde. Elle a besoin d’être habituelle, et elle doit commencer maintenant, pas quand la question est posée.

Si vous reconnaissez plus d’un de ces motifs chez vous, vous n’êtes pas en retard : vous êtes dans la norme. Le travail consiste à fermer les écarts avant que quelqu’un d’extérieur ne vous le demande.

Bâtir un programme qui tient face à un contrôle

  1. Cartographier où l’IA est utilisée dans les rôles (la plupart des employeurs sous-estiment d’un facteur 3 à 5)
  2. Écrire la politique de littératie IA avant de concevoir la formation
  3. Étager la formation selon le risque-rôle, pas selon l’ancienneté
  4. Intégrer l’évaluation - non comme un test, mais comme une revue de production réelle
  5. Fixer une cadence de rafraîchissement alignée sur la vitesse d’évolution des outils
  6. Tenir des registres dans un format que votre responsable conformité puisse relire et qu’un régulateur puisse comprendre

C’est le schéma Cartographier -> Former -> Prouver que nous utilisons avec chaque client. Il est tranché. Il fonctionne.

1. Cartographier où l’IA est utilisée dans les rôles. La plupart des employeurs sous-estiment cela d’un facteur trois à cinq. Menez une découverte structurée : chaque équipe, chaque outil, chaque workflow qui touche à l’IA - validé, non validé, intégré dans un SaaS, ou utilisé discrètement sur des comptes personnels. Le livrable, c’est une carte d’usage par rôle, avec des notations de risque face aux quatre compétences. La carte est la fondation. Manquez-la et le reste du programme formera les mauvaises personnes sur les mauvaises choses.

2. Écrire la politique de littératie IA avant de concevoir la formation. La politique est la constitution ; la formation est le cursus. Écrivez d’abord la politique, pour que la formation soit construite afin de la livrer, et non l’inverse. La politique est courte, sensible au rôle, signée par un responsable nommé. C’est aussi le document qui rend “suffisant” défendable : il énonce ce que l’organisation a décidé d’appropriée, vu le rôle et le risque.

3. Étager la formation selon le risque-rôle, pas selon l’ancienneté. L’associé senior qui utilise l’IA pour un résumé hebdomadaire a besoin de moins de profondeur que le collaborateur junior qui s’en sert quotidiennement sur des dossiers clients. Étager par ancienneté est une habitude. Étager par risque-rôle est une discipline. Construisez un palier de base pour tous, un palier plus profond pour les rôles intensifs en IA, et un palier spécialisé pour les rôles où l’IA touche à des décisions régulées.

4. Intégrer l’évaluation, non comme un test, mais comme une revue de production réelle. La preuve la plus forte que la formation a fonctionné, c’est la première pièce de travail assistée par IA que chacun produit, revue par un senior contre les critères de littératie. C’est plus crédible qu’une note de quiz, et cela fait office de coaching sur le terrain. Consignez la revue dans le registre.

5. Fixer une cadence de rafraîchissement alignée sur la vitesse d’évolution des outils. Le rafraîchissement annuel est trop lent pour la plupart des équipes. Six à neuf mois, c’est plus juste. Déclenchez un rafraîchissement hors cycle quand un outil majeur change, qu’un nouveau modèle est déployé, ou qu’un incident révèle une lacune. Le rafraîchissement est court : ce n’est pas refaire, c’est mettre à jour.

6. Tenir des registres dans un format que votre responsable conformité puisse relire et qu’un régulateur puisse comprendre. Langue claire. Datés. Sous gestion de versions. Un dossier, une structure, un responsable. Le test : quelqu’un qui ne connaît pas le programme peut-il lire les registres de bout en bout et comprendre ce qui a été enseigné, à qui, quand, et quelles preuves montrent que cela a tenu. Si oui, vous avez un dossier de preuves prêtes. Si non, vous avez une pile de fichiers.

Un programme bâti ainsi - cartographié, ancré dans une politique, étagé par risque-rôle, évalué dans le travail, rafraîchi en cadence, et documenté dans une forme lisible - c’est ce que “mesures suffisantes” veut dire en pratique. Ce n’est pas un dossier d’achèvement. Ce n’est pas une garantie. C’est une position défendable, qui est le standard que la clause demande réellement.

Comment AISO Learn aide sur l’Article 4

  • Team Engagement avec le pack littératie Article 4
  • Ce qui est inclus (formation + politique + registres)
  • Ce qui n’est pas inclus (validation juridique - votre conseil garde la politique)
  • L’appel de découverte comme prochaine étape

Si vous êtes responsable de la préparation à l’Article 4 de l’AI Act dans votre organisation et voulez un programme défendable avant qu’un incident, une revue client, un CSE ou une enquête du régulateur ne force la question, un appel de découverte est la prochaine étape.

Ou, si vous voulez d’abord voir où en est votre équipe, le Scorecard de maturité IA inclut une bande de compétence Article 4 et vous indique le chemin le plus court pour combler l’écart.


AISO Learn fournit de la formation à la littératie IA et de la documentation pour soutenir les organisations dans leur préparation à l’Article 4 de l’AI Act. Nous ne sommes pas un cabinet d’avocats ni un organisme de certification et ne fournissons pas de conseil juridique, de certification formelle de conformité, d’évaluation de conformité ni de garantie de conformité réglementaire.