Littératie IA en entreprise : prouver les compétences utiles

La littératie IA en entreprise ne se résume pas à imposer la même formation à toute l’équipe. L’article 4 de l’AI Act demande aux fournisseurs et aux déployeurs de systèmes d’intelligence artificielle de soutenir le développement des compétences des personnes qui les utilisent ou les exploitent pour leur compte. Les mesures doivent tenir compte des connaissances, de l’expérience, du contexte d’usage et des personnes affectées.

Pour agir utilement, partez donc des usages réels. Une personne qui reformule un e-mail, une équipe RH qui prépare un recrutement et un opérateur qui valide une décision produite par un système à haut risque n’ont ni les mêmes connaissances à acquérir, ni les mêmes erreurs à prévenir.

La méthode de cet article relie usage, rôle, risque, compétence, consigne et preuve. Elle aide à construire un dispositif vérifiable sans prétendre qu’une attestation, une charte ou une demi-journée standard suffit à elle seule.

Que demande l’article 4 de l’AI Act ?

L’article 4 présenté par le service officiel de l’AI Act vise les fournisseurs et déployeurs de systèmes d’IA. Ils doivent prendre des mesures pour soutenir un niveau de littératie adapté chez leur personnel et chez les autres personnes qui utilisent ou exploitent ces systèmes pour leur compte.

La foire aux questions de la Commission européenne, mise à jour après l’AI Omnibus de juillet 2026, apporte plusieurs nuances importantes :

• aucun niveau unique de compétence n’est imposé à chaque personne ;
• aucune formation, durée, certification ou structure de gouvernance particulière n’est obligatoire par principe ;
• le dispositif doit varier selon les outils, les rôles, les connaissances et les risques ;
• un registre interne peut documenter les formations et autres actions de sensibilisation ;
• demander simplement de lire la notice d’un outil peut être inefficace ;
• les exigences propres à la supervision humaine des systèmes à haut risque restent distinctes.

L’obligation s’applique depuis le 2 février 2025. Les règles de supervision et d’application ont commencé à produire leurs effets les 2 et 3 août 2026 selon les autorités concernées. La Commission a confirmé le début de l’application de plusieurs règles de l’AI Act le 2 août, mais cette date ne transforme pas chaque usage en urgence identique ni chaque erreur en sanction automatique.

Le premier travail consiste à identifier ce qui est réellement utilisé, par qui et pour affecter quelle décision.

Une formation IA est-elle obligatoire pour chaque salarié ?

L’article 4 n’impose pas une formation standard à toute l’entreprise. Il impose une démarche adaptée au contexte. Une formation peut être pertinente, mais aussi une consigne ciblée, un exercice, une restriction d’accès, un guide par rôle, une revue de cas ou un accompagnement au poste.

La confusion vient souvent d’une traduction trop rapide entre littératie et formation. Former décrit un moyen. La littératie décrit la capacité attendue : comprendre assez bien l’outil, ses limites et ses effets pour l’utiliser ou le superviser dans une situation donnée.

Trois collaborateurs peuvent donc recevoir des mesures différentes :

1. une personne qui prépare des textes avec un assistant généraliste apprend à protéger les données, vérifier les faits et assumer la version finale ;
2. une personne qui paramètre un outil métier comprend ses données, ses seuils, ses journaux et sa procédure de retour arrière ;
3. une personne qui valide une décision sensible connaît les critères de supervision, les informations disponibles et les cas où elle doit refuser la sortie.

Une attestation de présence montre qu’une session a eu lieu. Elle ne montre pas nécessairement que la bonne personne sait reconnaître l’erreur qui compte dans son travail.

La matrice usage, rôle, risque, compétence, consigne et preuve

La matrice suivante transforme une obligation générale en décisions opérationnelles. Elle ne constitue ni une certification, ni une conclusion juridique. Elle aide à repérer les mesures manquantes avant qu’un outil devienne invisible dans les habitudes de travail.

Usage observé	Rôle concerné	Risque concret	Compétence attendue	Consigne ou contrôle	Preuve utile
reformuler un e-mail ou traduire un texte	utilisateur métier	divulgation, erreur factuelle, ton inadapté	reconnaître les données interdites et vérifier la sortie	liste des informations à ne pas saisir, relecture avant envoi	exercice corrigé et version approuvée
produire un contenu public	rédacteur, relecteur, responsable éditorial	information fausse, source inventée, défaut de transparence	vérifier les sources, distinguer assistance et responsabilité	chaîne de revue et règle de publication	sources retenues, modifications et approbation
résumer un dossier client	utilisateur métier, DPO ou sécurité selon le cas	donnée personnelle ou confidentielle exposée	choisir l’outil autorisé et minimiser l’entrée	accès limité, environnement approuvé, règle de conservation	test avec données fictives et journal d’accès
classer ou recommander une action	opérateur, responsable métier	biais, mauvaise règle, confiance excessive	comprendre le critère, la limite et le recours	seuil d’escalade, échantillon de contrôle, droit de corriger	décisions acceptées, refusées et rectifiées
agir dans plusieurs outils	opérateur et propriétaire du processus	action irréversible, permission excessive, doublon	lire le plan d’action et reprendre la main	validation avant effet externe et procédure d’arrêt	scénario d’erreur, journal et retour arrière
exploiter ou maintenir le système	équipe technique, produit, prestataire	dérive, incident, version non maîtrisée	diagnostiquer les dépendances et les limites du système	surveillance, versionnement, alerte et repli	exercice d’incident et compte rendu

Le niveau de détail doit suivre le coût de l’erreur. Expliquer les hallucinations ne suffit pas lorsqu’une sortie déclenche un paiement, refuse un dossier ou publie une information. À l’inverse, imposer un cursus technique complet à une personne qui utilise un outil autorisé pour un brouillon occasionnel peut créer du bruit sans réduire le risque.

La meilleure unité de travail n’est donc pas le département. C’est l’usage réel dans une décision identifiable.

Commencer par l’inventaire des usages, pas par le catalogue de formations

Un inventaire utile ne demande pas seulement « utilisez-vous ChatGPT ? ». L’IA peut être intégrée à un logiciel de bureautique, un CRM, un outil de recrutement, une fonction de recherche, une plateforme marketing ou un processus automatisé sans être nommée dans le quotidien.

Pour chaque usage, relevez :

• l’outil, l’offre et le compte utilisés ;
• la tâche confiée et la sortie attendue ;
• les données saisies, recherchées ou produites ;
• la personne qui utilise, paramètre et valide ;
• les personnes affectées par la sortie ;
• l’effet possible : brouillon, recommandation, décision ou action ;
• les erreurs déjà observées ou raisonnablement prévisibles ;
• la procédure lorsque l’outil est indisponible ou contesté.

Si l’usage traverse plusieurs outils ou reproduit une habitude mal définie, commencez par observer le processus avant de l’automatiser. La compétence attendue dépend du flux que l’entreprise choisit de conserver, simplifier ou déléguer.

Cet inventaire protège aussi contre le shadow AI, c’est-à-dire l’usage d’outils non identifiés par l’organisation. Une interdiction générale ne garantit pas que ces outils disparaissent. Elle peut seulement les rendre plus difficiles à observer. Un dispositif crédible doit donner une voie autorisée pour les usages acceptables et une explication compréhensible pour les usages refusés.

La CNIL recommande de familiariser les utilisateurs avec le fonctionnement, les limites, les transferts de données et les usages autorisés ou interdits. Elle rappelle aussi de ne saisir dans un service grand public aucune information confidentielle ou personnelle que l’utilisateur n’est pas autorisé à partager.

L’objectif n’est pas de tout consigner. Il est de rendre visibles les usages qui peuvent modifier une décision, exposer une donnée ou engager une personne extérieure.

Construire des parcours de compétence par rôle

Une sensibilisation générale peut donner un vocabulaire commun : ce qu’est un système d’IA, comment une sortie est produite, pourquoi elle peut être inexacte et quelles données ne doivent pas être partagées. Elle devient utile seulement si elle se prolonge dans le travail réel.

Construisez ensuite un petit parcours par rôle :

Utilisateur métier

Il doit savoir quand l’outil est autorisé, quelles informations peuvent être saisies, comment vérifier une sortie et qui solliciter en cas de doute. Son exercice doit reprendre un document ou une décision proche de son activité, avec des données fictives.

Validateur humain

Il doit disposer des informations nécessaires pour juger la sortie. « Un humain valide » ne suffit pas si la personne ne connaît ni la source, ni la règle, ni les limites du système. La compétence attendue inclut le droit de refuser et la capacité à expliquer ce refus.

Responsable produit ou métier

Il attribue les propriétaires, décide des usages autorisés, suit les incidents et réexamine le dispositif après un changement d’outil, de données ou de public. Il ne doit pas confondre le taux d’adoption avec la qualité de la décision.

Équipe technique ou prestataire

Elle maîtrise les accès, versions, intégrations, journaux, évaluations et mécanismes de repli. Une qualification technique ne dispense pas de connaître le contexte métier, les personnes affectées et les conséquences d’une sortie erronée.

La Commission précise que les personnes travaillant pour un prestataire au nom du déployeur doivent elles aussi posséder les compétences adaptées à la tâche. Le contrat peut attribuer des responsabilités, mais il ne remplace pas la preuve que le système est correctement utilisé dans le parcours réel.

Six scénarios pour vérifier que le dispositif fonctionne

La présence d’un support de formation n’est pas une validation suffisante. Testez des situations où la personne doit reconnaître une limite, appliquer une consigne ou reprendre le contrôle.

1. Hallucination plausible. L’outil produit une réponse fluide contenant une source inexistante. La personne doit la détecter, la vérifier et empêcher sa diffusion.
2. Donnée confidentielle. Une demande semble nécessiter un contrat, un dossier client ou une clé d’accès. La personne doit refuser l’envoi dans l’outil non autorisé et utiliser le canal prévu.
3. Décision sensible. Une sortie propose d’écarter une candidature, un client ou une demande. La personne doit identifier la règle applicable, les informations manquantes et la voie d’escalade.
4. Contenu public. Un texte assisté par IA doit être sourcé, relu et publié sous une responsabilité éditoriale explicite. Le guide sur la transparence des chatbots et contenus IA traite séparément les signaux visibles et le marquage technique.
5. Action automatisée. Un agent propose d’envoyer, modifier ou supprimer une information. La personne doit comprendre ses permissions et arrêter l’effet avant qu’il devienne irréversible. Le cadrage d’un agent IA reste propriétaire de cette décision produit.
6. Prestataire externe. Le fournisseur change une fonction, un modèle ou une règle de conservation. L’équipe doit savoir qui réévalue l’usage, actualise la consigne et informe les personnes concernées.

Pour chaque scénario, conservez l’entrée fictive, la réponse attendue, l’action réellement effectuée, l’écart observé et la correction décidée. Il ne s’agit pas de noter chaque salarié. La Commission indique que l’article 4 n’impose pas de mesurer individuellement leurs connaissances. Le scénario vérifie le dispositif : est-ce que la bonne information, le bon contrôle et la bonne voie d’aide existent au moment utile ?

Quel dossier conserver sans créer une bureaucratie IA ?

La Commission n’impose ni certificat, ni « AI officer », ni comité de gouvernance particulier pour satisfaire l’article 4. Elle indique qu’un registre interne des formations et autres actions de guidance peut être conservé. Le dossier doit donc rester proportionné à l’usage et servir à reprendre le travail.

Un dossier minimal peut contenir six objets :

1. Inventaire daté : outil, version, fournisseur, usage, données, personnes affectées et propriétaire.
2. Matrice des rôles : utilisateur, validateur, responsable métier, technique et prestataire.
3. Mesures choisies : sensibilisation, guide, restriction, exercice, accompagnement ou contrôle.
4. Consignes opératoires : données autorisées, vérifications, seuils d’escalade, arrêt et repli.
5. Preuves de scénario : cas testé, résultat, écart, correction et date.
6. Règle de révision : changement d’outil, de modèle, de données, de public, d’effet ou incident.

Le répertoire européen des pratiques de littératie IA rassemble plus de quarante exemples d’organisations. Il peut aider à choisir des formats, mais la Commission précise que recopier une pratique ne crée pas automatiquement une présomption de conformité. Une bibliothèque d’exemples est un point de départ, pas un modèle universel.

Évitez deux excès. Le premier consiste à stocker des attestations sans savoir à quel usage elles répondent. Le second consiste à surveiller chaque interaction des salariés avec l’IA. La preuve nécessaire porte sur les mesures et les contrôles ; elle ne justifie pas une collecte illimitée de données sur le travail.

Quand faut-il réviser les compétences et les consignes ?

Une date annuelle peut servir de rappel, mais elle ne suffit pas. Le dispositif doit surtout être réexaminé lorsqu’un changement modifie ce que l’outil sait, voit, produit ou déclenche.

Prévoyez une revue lorsque :

• un nouvel outil ou une nouvelle fonction IA entre dans le processus ;
• le fournisseur change de modèle, de conditions, de conservation ou de sous-traitants ;
• une intégration donne accès à de nouvelles données ou permet une action externe ;
• la sortie passe du brouillon à la recommandation, puis de la recommandation à l’exécution ;
• un nouveau métier, prestataire ou public utilise le système ;
• une erreur, une plainte ou un contournement révèle une consigne incomprise ;
• une recommandation européenne ou nationale précise le cadre applicable.

La revue ne conduit pas toujours à une nouvelle formation. Elle peut conclure qu’il faut retirer un accès, réécrire une consigne, améliorer l’interface, ajouter une source visible, déplacer une validation ou réduire l’autonomie du système. C’est un point important : demander à une personne de « faire plus attention » ne corrige pas un produit qui masque l’incertitude ou autorise une action trop large.

Conservez la date, le déclencheur, les rôles concernés, la décision et la prochaine condition de revue. Cette trace courte montre que le dispositif suit le produit au lieu de figer les compétences autour d’une version devenue ancienne.

Exemple fictif : un assistant qui prépare des réponses commerciales

Imaginons une PME fictive qui autorise un assistant IA à résumer les demandes entrantes et à préparer une réponse commerciale. Le système n’envoie rien. Une personne relit le résumé, vérifie les informations dans le CRM et décide de la réponse finale.

L’entreprise ne commence pas par acheter une formation générale. Elle observe le parcours et identifie trois risques : un document client confidentiel copié dans un service inadapté, une promesse inventée par le modèle et une information erronée enregistrée dans le CRM.

Elle construit alors un dispositif limité :

• un outil et des comptes autorisés ;
• une règle claire sur les données saisissables ;
• un exercice montrant une promesse plausible mais fausse ;
• une vérification obligatoire dans la source de vérité ;
• un statut « à confirmer » avant toute modification du CRM ;
• une voie manuelle si l’assistant est indisponible ;
• une révision après tout changement de modèle ou d’intégration.

L’équipe conserve la consigne, le scénario testé, les corrections et la date de révision. Cet exemple ne prouve aucune conformité et ne décrit aucun client Zence. Il montre comment la littératie devient une propriété du processus, pas une case séparée du produit.

Quelle première action prendre cette semaine ?

Choisissez un seul usage IA déjà présent dans l’entreprise. Prenez une sortie réelle après avoir retiré ou remplacé toute donnée sensible. Demandez à l’utilisateur de montrer ce qu’il vérifie, ce qu’il refuse de saisir, ce qu’il ferait en cas de doute et qui assume la décision finale.

Vous découvrirez rapidement si le problème principal est une connaissance, une consigne, un accès, une interface ou une responsabilité mal attribuée. Traitez ce manque, puis rejouez un scénario d’erreur. La plus petite mesure utile est celle qui permet à une personne de reconnaître la limite et de terminer correctement son action.

Le canvas de la plus petite preuve produit peut formaliser la personne, l’action importante, l’hypothèse, les erreurs et le signal de réussite avant d’élargir le dispositif à toute l’organisation.

Zence conçoit des logiciels métier et intégrations sur mesure en reliant usages, données, permissions, contrôles et exploitation. La littératie IA ne remplace pas ce cadrage. Elle garantit que les personnes comprennent assez bien le système pour utiliser les contrôles prévus, reconnaître leurs limites et reprendre la main lorsque la situation sort du cas nominal.

Sources principales

• Commission européenne — Questions-réponses sur la littératie IA, mise à jour en juillet 2026
• Commission européenne — Début de l’application des règles de l’AI Act, 31 juillet 2026
• AI Act Service Desk — Article 4 sur la littératie IA
• AI Act Service Desk — Répertoire des pratiques de littératie IA, 27 juillet 2026
• CNIL — Questions-réponses sur l’utilisation d’un système d’IA générative
• CNIL, France Num et CPME — Fiches pratiques pour utiliser l’IA générative dans les TPE-PME