Un atelier IA utile ne commence pas par un catalogue d’outils. Il choisit une tâche réelle, un résultat observable et les erreurs que les participants doivent savoir détecter. Le programme alterne compréhension courte, pratique sur des cas autorisés, vérification et reprise autonome. À la fin, chaque participant doit pouvoir exécuter la tâche, juger la sortie et savoir quand arrêter ou demander de l’aide.
Méthode et sources vérifiées le 8 septembre 2026. Le programme doit être adapté aux outils, aux risques, aux métiers et aux règles de chaque entreprise ; il ne constitue ni une certification ni une preuve automatique de conformité.
Le livrable d’un atelier IA n’est pas une liste de prompts
Une liste de prompts devient vite obsolète et ne prouve aucune compétence. Le vrai livrable d’un atelier IA est une manière de travailler reproductible : choisir les bonnes informations, formuler le résultat attendu, contrôler la réponse, corriger la demande et reconnaître une situation où l’outil ne doit pas être utilisé.
« Découvrir les possibilités de l’IA » est trop large pour être évalué. « Préparer un compte rendu à partir de notes autorisées, vérifier cinq informations et signaler les inconnues avant partage » décrit une capacité observable, donc un exercice et une règle de réussite.
Si l’entreprise ne sait pas encore quelle tâche travailler, commencez par sélectionner un cas d’usage. Notre matrice pour choisir un premier usage IA aide à écarter une tâche sans données utilisables, sans évaluateur métier ou dont l’erreur aurait un effet trop coûteux.
Que faut-il décider avant de construire le programme ?
Le cadrage d’un atelier IA tient sur une page, à condition d’expliciter six décisions. Sinon, les participants ne savent pas transposer la démonstration à leur travail.
| Décision | Question à trancher | Preuve à préparer |
|---|---|---|
| Public | Qui participe, avec quel niveau et quel rôle ? | Un autodiagnostic court et deux tâches décrites par métier |
| Résultat | Que saura faire la personne après la session ? | Une action observable, avec un livrable attendu |
| Cas pratique | Quelle situation revient réellement dans le travail ? | Deux exemples représentatifs et un contre-exemple |
| Données | Quelles informations peuvent entrer dans l’outil choisi ? | Des documents fictifs, anonymisés ou explicitement autorisés |
| Contrôle | Quelles erreurs faut-il savoir repérer avant utilisation ? | Une grille de vérification et un cas volontairement ambigu |
| Suite | Où la compétence sera-t-elle réutilisée ? | Un responsable, une période d’essai et un point de retour |
Un groupe peut partager un socle commun tout en travaillant des tâches différentes. Si les écarts de niveau sont importants, gardez une introduction commune puis séparez les exercices ou les critères de réussite.
Quel programme type utiliser pour une demi-journée ?
Voici un programme illustratif de 3 h 30, hors pause. Un usage impliquant plusieurs outils, des données sensibles ou une décision métier demande davantage de préparation et de suivi.
| Séquence | Durée indicative | Production attendue |
|---|---|---|
| Situation de départ | 20 min | Une tâche, son résultat actuel et la difficulté observée |
| Fonctionnement, limites et règles | 25 min | Ce que l’outil peut recevoir, produire et ne doit pas décider |
| Démonstration commentée | 35 min | Une méthode visible, y compris les contrôles et les échecs |
| Pratique guidée | 55 min | Un premier livrable produit à partir d’un cas autorisé |
| Contre-exemple et vérification | 45 min | Les erreurs détectées, corrigées ou escaladées |
| Reprise sans procédure détaillée | 20 min | Le même type de tâche réalisé de façon plus autonome |
| Transfert au travail | 10 min | Une fiche d’usage, un prochain essai et un responsable |
La théorie doit surtout permettre d’agir avec discernement. La CNIL rappelle qu’une IA générative peut produire un résultat inexact mais plausible. Cette limite doit apparaître dans les exercices, pas seulement sur une diapositive.
Comment construire un exercice à partir du travail réel ?
Un bon exercice contient une entrée, un résultat attendu, une contrainte, un piège et une règle de décision. Le piège rend la vérification observable ; sans lui, une réponse fluide peut donner une fausse impression de maîtrise.
| Métier fictif | Entrée autorisée | Résultat demandé | Piège à détecter | Contrôle final |
|---|---|---|---|---|
| Commerce B2B | Fiche produit publique et courriel fictif | Brouillon de réponse structuré | Délai absent de la fiche | Ne pas inventer ; demander l’information |
| Opérations | Notes anonymisées d’une intervention | Compte rendu selon un modèle | Référence d’équipement ambiguë | Rapprocher la référence ou signaler le doute |
| Support | Base d’aide validée et ticket fictif | Proposition de réponse avec source | Procédure obsolète dans un document | Utiliser la version datée et faire valider l’écart |
L’exercice évalue une sortie conforme aux faits et aux règles, pas le texte le plus élégant. Rejeter la réponse de l’IA lorsque des informations manquent fait partie de la compétence.
Exemple rempli : un atelier pour une équipe de maintenance B2B
Prenons une PME fictive de maintenance industrielle. Six coordinateurs transforment les notes des techniciens en comptes rendus destinés aux clients. Les notes varient en forme, certaines références d’équipement sont abrégées et aucune recommandation technique ne peut être ajoutée sans validation d’un responsable.
Trois options sont envisagées : présenter plusieurs assistants, distribuer un prompt de résumé ou travailler le cycle complet. Ce cycle consiste à préparer une entrée autorisée, demander un compte rendu, le comparer aux notes, marquer les inconnues et faire valider les recommandations.
L’entreprise choisit le cycle complet. Elle remplace les noms, coordonnées et numéros de série par des valeurs fictives, puis prépare deux dossiers ordinaires et un dossier où une référence se contredit. Le formateur dispose du compte rendu attendu et des contrôles.
Le participant doit retrouver chaque fait dans l’entrée, conserver les unités, signaler la contradiction et ne pas inventer la cause de la panne. Demander une clarification plutôt que produire une recommandation incertaine est une réussite.
Après l’atelier, l’équipe teste la méthode sur une série limitée de dossiers autorisés. Elle relève le temps complet, les omissions, les corrections humaines et les abandons pour décider de conserver, ajuster, intégrer ou arrêter l’usage. L’exemple ne promet aucun gain.
Quelles règles de données faire pratiquer ?
Les règles doivent précéder la connexion à l’outil. La CNIL recommande aux organisations de définir les usages autorisés et interdits, de vérifier les conditions du fournisseur et de ne soumettre que des informations que l’utilisateur est autorisé à partager. Le mode d’hébergement, la réutilisation éventuelle des données et les réglages du compte changent la décision.
Chaque exercice devrait donc indiquer :
- l’outil et le compte autorisés ;
- les catégories de données admises, à anonymiser ou interdites ;
- la personne responsable du contrôle ;
- les sorties qui peuvent rester internes et celles qui exigent une validation ;
- la manière de conserver ou de supprimer l’entrée, la sortie et l’historique.
Une charte générale ne suffit pas si personne ne sait l’appliquer. Faites classer quelques exemples, d’une fiche publique à un contrat ou un CV fictif. La décision varie selon l’outil et les règles ; l’équipe doit savoir qui tranche avant l’usage.
Comment mesurer l’autonomie après l’atelier ?
La satisfaction à chaud ne mesure pas la capacité à travailler. Demandez au participant de traiter un nouveau cas sans recopier la procédure, puis observez les données choisies, la demande, la vérification, la correction et la décision.
La grille suivante adapte la logique des niveaux d’autonomie de DigComp 3.0 à un exercice interne. Ce n’est ni une certification officielle ni une échelle juridique.
| Niveau observé | Comportement sur la tâche | Prochaine étape |
|---|---|---|
| À guider | Suit une procédure, mais oublie un contrôle ou utilise une donnée incertaine | Refaire un cas avec accompagnement |
| Autonome sur cas défini | Exécute la tâche connue, vérifie la sortie et respecte les règles | Tester plusieurs exemples représentatifs |
| Capable d’adapter | Ajuste la méthode, explique ses limites et arrête un cas inadapté | Documenter les variantes autorisées |
| Capable de transmettre | Aide un collègue et améliore la fiche sans retirer les contrôles | Contribuer au suivi de l’usage |
Définissez avant la session le niveau attendu pour chaque public. Tout le monde n’a pas besoin de savoir concevoir une automatisation. Un utilisateur occasionnel peut devoir seulement reconnaître l’outil autorisé, exécuter une tâche délimitée, vérifier la sortie et demander de l’aide au bon moment.
L’AI Act impose-t-il un format de formation précis ?
Au 8 septembre 2026, la Commission européenne explique que l’article 4 de l’AI Act maintient pour les fournisseurs et déployeurs de systèmes d’IA une obligation de soutenir le développement de la culture IA des personnes concernées. Aucun niveau individuel précis ni formation obligatoire au format unique n’est imposé par cet article. Le contexte, les connaissances, les usages et les risques doivent guider les mesures choisies.
Un atelier peut contribuer à cette démarche, mais sa seule tenue ne prouve pas la conformité de l’organisation. Il faut aussi connaître les systèmes utilisés, les personnes concernées, les risques, les règles internes et les actions de suivi. Pour un cas sensible ou un système à haut risque, faites examiner les obligations applicables par les responsables compétents plutôt que de transformer un programme générique en avis juridique.
Quand faut-il reporter l’atelier ?
Reportez la pratique si les comptes autorisés, les données utilisables ou le responsable du contrôle ne sont pas définis. Commencez par un cadrage sans données métier. Si personne ne peut juger la sortie, clarifiez d’abord le processus et ses critères.
Un atelier n’est pas non plus le bon remède à une intégration défaillante, à des documents introuvables ou à une décision que personne n’assume. La formation transmet une méthode ; elle ne remplace ni la gouvernance, ni la qualité des données, ni le développement nécessaire pour sécuriser un usage récurrent.
Klaapp propose des ateliers de formation IA adaptés aux tâches réelles. Un premier échange peut servir à choisir le public, la tâche, les données d’exercice et le niveau d’autonomie attendu. Si ces éléments ne sont pas prêts, la prochaine étape peut être un cadrage plutôt qu’une formation complète.
Questions fréquentes
Faut-il organiser une journée complète ?
Pas systématiquement. Une demi-journée peut suffire pour un public homogène et une tâche délimitée. Plusieurs groupes, des niveaux très différents, des outils à configurer ou des cas sensibles demandent davantage de préparation, de pratique ou un second rendez-vous.
Peut-on former débutants et utilisateurs avancés ensemble ?
Oui pour le socle commun sur le fonctionnement, les risques et les règles. Pour la pratique, prévoyez des variantes ou des groupes de niveau. Le critère de réussite d’un débutant peut être l’exécution sûre d’un cas défini ; celui d’un utilisateur avancé, l’adaptation et la transmission.
Peut-on utiliser des documents réels pendant l’atelier ?
Seulement si leur utilisation dans l’outil choisi est autorisée et maîtrisée. Par défaut, préparez des documents fictifs ou anonymisés qui conservent les difficultés du métier. Un exemple réaliste n’a pas besoin d’exposer un contrat, un CV, une donnée client ou un secret de l’entreprise.
Un QCM suffit-il pour évaluer une formation IA ?
Un QCM peut vérifier des connaissances, mais pas l’exécution d’une tâche. Ajoutez une mise en situation où la personne choisit les données, produit une sortie, détecte un piège et décide de valider, corriger ou arrêter. C’est cette production qui rend l’autonomie observable.
Sources
- Commission européenne — AI Literacy, questions et réponses
- CNIL — Questions-réponses sur l’utilisation d’un système d’IA générative
- Commission européenne, Joint Research Centre — DigComp 3.0
Thomas R. est cofondateur de Klaapp. Il porte les choix techniques et l’intégration de l’IA, accompagne leurs usages et forme les équipes. Découvrir le studio Klaapp.