Formation Claude IA pour les équipes Pédagogiques

Formation

Claude appliqué à la conception : objectifs, supports, quiz et exercices bâtis sur votre documentation produit

Durée

Deux jours, 14 heures au total, chaque module se concluant sur la révision d'un de vos contenus

Formats

Jusqu'à 12 concepteurs et formateurs en intra, ou un parcours individuel ; dans vos murs ou en classe virtuelle

Tarif

À partir de 1 980 € HT pour chaque journée, quel que soit l'effectif du groupe ; préparation sur mesure en plus, au devis

Financement

Certification Qualiopi de Masteria ; demande à adresser à l'OPCO de votre branche, montée ensemble

Prérequis

Pratique de la conception de formations ; un compte Claude payant, Team de préférence pour partager compétences et projets

La documentation complète entre dans la conversation, sous deux réserves

La fenêtre de contexte, c'est le volume de texte que Claude embrasse d'un seul regard au cours d'un échange. Sur une offre payante, elle atteint un million de tokens, ces morceaux de mots qui servent d'unité de lecture, avec Fable 5.1, Sonnet 5.5 ou Opus 5.5. D'après Anthropic, 500 pages de texte font environ 200 000 tokens : un guide utilisateur de 400 pages, ses notes de version et l'ancien module y logent ensemble, et vous pouvez joindre jusqu'à vingt fichiers à une même conversation.

Première réserve : un PDF long de plus de 100 pages ne livre que son texte. Les captures d'écran, qui portent souvent l'essentiel d'une formation logicielle, sortent alors de l'analyse ; découpez le guide en parties de 100 pages au plus dès que le module s'appuie sur l'interface. Seconde réserve : dans un projet, Claude bascule vers une recherche d'extraits quand les documents de connaissance approchent la limite du contexte. Cette méthode, appelée RAG, va chercher les seuls extraits qui répondent à la question, sans parcourir chaque fichier. Un contrôle exhaustif, comme le recensement de toutes les nouveautés d'une version, exige donc de joindre les fichiers à la conversation elle-même plutôt qu'aux connaissances du projet.

Une conversation qui s'allonge finit enfin par condenser ses premiers échanges pour libérer de la place. Ouvrez une conversation par module plutôt qu'une seule pour toute la version, et reprenez à chaque fois les fichiers dont le module a besoin.

Un objectif s'écrit avec l'épreuve qui le vérifiera

Le rapport d'Anthropic sur les usages des enseignants, publié le 27 août 2025 et signé Drew Bent et Kunal Handa, a passé au crible environ 74 000 conversations de personnels de l'enseignement supérieur sur Claude.ai, entre le 22 mai et le 2 juin 2025 (utilisateurs des offres Free et Pro ; le rapport ne précise pas le modèle). La conception de cours et de supports y occupait 57 % des échanges, loin devant la recherche (13 %) et l'évaluation des étudiants (7 %). Les auteurs observent aussi des enseignants qui bâtissent leurs propres exercices interactifs dans les artefacts.

Pour un module produit, un objectif décrit un geste dans le logiciel, sa condition et son critère : « planifier une intervention récurrente dans le module Planning de la version 5, sans aide, en moins de trois minutes ». Demandez à Claude d'écrire chaque objectif suivi de l'épreuve qui le vérifie, question de quiz ou tâche à réaliser dans l'environnement de démonstration. Un verbe comme « découvrir » ou « connaître » ne résiste pas à cette discipline : il ne désigne aucun geste qu'un formateur puisse observer.

Le même rapport signale un point d'attention. Lorsque les enseignants confiaient une évaluation à Claude, 48,9 % de ces échanges relevaient de l'automatisation, l'IA accomplissant elle-même la tâche. Pour un module produit, la correction d'un quiz fermé par une machine ne pose pas de difficulté ; le jugement sur les acquis d'un apprenant, lui, revient au formateur.

La charte de l'académie devient une compétence que chaque concepteur applique

Une compétence, ou skill, prend la forme d'un dossier organisé autour d'un fichier SKILL.md. Ce fichier commence par un nom, limité à 64 caractères, et par une description qui n'en dépasse pas 200 ; viennent ensuite les instructions, avec au besoin des fichiers d'appui tels qu'un modèle de déroulé ou un glossaire. Claude lit la description pour décider d'appliquer la compétence ; elle doit donc nommer les demandes qui la déclenchent, par exemple « conception ou révision d'un module de l'académie client ». Les compétences ne fonctionnent qu'avec l'exécution de code activée.

Un projet remplit une autre fonction : il conserve les fichiers et les consignes d'un module donné, rechargés à chaque conversation de ce projet. La compétence porte la méthode et vaut pour tous les modules ; le projet porte la matière d'un seul.

Vous créez une compétence en déposant un fichier ZIP dans la liste de vos compétences, ou en demandant à Claude de la rédiger d'après une conversation réussie. Sur Team et Enterprise, vous la partagez à des collègues, qui s'en servent sans pouvoir la modifier, ou vous la versez au catalogue commun de l'organisation, après relecture par un Owner, l'un des administrateurs de l'organisation, si votre politique le demande. Une charte pédagogique enregistrée de cette façon contient au moins quatre éléments.

• →la structure d'un module : accroche, démonstration, mise en pratique, vérification ;
• →les règles de quiz : une seule bonne réponse, des distracteurs tirés d'erreurs constatées chez les apprenants, aucune tournure négative ;
• →le glossaire des noms officiels des écrans et des menus, tenu version par version ;
• →les formats de sortie : déroulé Word, présentation PowerPoint, banque de questions au format attendu par votre plateforme.

Un artefact transforme une procédure en exercice, testé avant la session

Un artefact est un contenu autonome que Claude construit à côté de la conversation : document, schéma, petite application. Pour une formation logicielle, il donne une simulation de l'écran de paramétrage qui réagit à chaque clic, un quiz commenté réponse par réponse, ou un scénario dans lequel l'apprenant choisit l'étape suivante. Un artefact peut aussi appeler Claude : l'apprenant pose ses questions et reçoit une réponse adaptée, chaque utilisateur se connectant avec son propre compte Claude, sur lequel son usage est décompté.

Les artefacts gardent leurs données entre deux utilisations, en stockage personnel ou partagé, dans la limite de 20 Mo de texte par artefact. En stockage partagé, chaque utilisateur voit les données des autres : un tableau des scores visible de tous convient à un jeu, alors que les résultats nominatifs d'une évaluation n'ont rien à y faire.

Claude Design, en bêta sur les offres payantes, produit fiches mémo, maquettes d'écran et pages de présentation avec votre système de design importé : couleurs, polices, composants. Il fonctionne d'emblée sur Team et attend l'activation d'un Owner sur Enterprise. Une maquette s'exporte en PDF, en PowerPoint ou en HTML autonome ; l'outil n'a pas encore d'historique des versions, d'où l'intérêt d'exporter avant toute refonte. Pour vos clients, l'exercice se prototype dans Claude, puis il rejoint votre plateforme de formation.

Cas pratique : réviser le module « Prise en main » avant la sortie de la version 5

L'académie client d'un éditeur de logiciel de gestion des interventions prépare la sortie de la version 5, attendue dans trois semaines. Le module « Prise en main », 45 minutes et un quiz de 12 questions, décrit encore la version 4. La responsable des contenus dispose des notes de version (80 pages), du guide utilisateur (410 pages) et du module en vigueur ; elle doit remettre la version révisée aux formateurs vendredi.

1. Créez un projet « Prise en main v5 » ; notez dans ses consignes le public, techniciens et planificateurs chez les clients, ainsi que la durée du module, et activez la compétence de charte de l'académie.
2. Découpez le guide utilisateur en cinq fichiers de 100 pages au plus, pour que Claude analyse aussi les captures d'écran.
3. Joignez à une conversation du projet les notes de version, les cinq parties du guide, le déroulé actuel et le quiz, puis soumettez la demande qui suit.
4. Rejouez chaque question du nouveau quiz dans l'environnement de démonstration de la version 5.
5. Faites construire l'exercice de planification sous forme d'artefact, confiez-le à deux formateurs pour un essai, puis ajoutez à la compétence ce que cet essai vous a appris.

Je dois réviser le module « Prise en main » de notre académie client pour la version 5 de notre logiciel de gestion des interventions. Durée : 45 minutes. Public : techniciens et planificateurs chez nos clients, qui utilisent la version 4 au quotidien.

Fichiers joints : les notes de version 5, le guide utilisateur v5 en cinq parties, le déroulé actuel du module et son quiz de 12 questions.

Procède en quatre temps.
1. Liste les nouveautés de la version 5 qui changent le travail quotidien d'un technicien ou d'un planificateur. Pour chacune, cite la page des notes de version et la page du guide qui la décrit. Laisse de côté ce qui ne concerne que l'administrateur.
2. Relève dans le déroulé et dans le quiz tout ce que la version 5 rend faux : nom de menu, ordre des étapes, écran décrit. Donne l'ancien passage, la correction et la page qui la justifie.
3. Propose quatre objectifs au plus. Chacun décrit un geste observable dans le logiciel, avec sa condition et son critère de réussite, suivi de la question ou de la tâche pratique qui le vérifiera.
4. Écris le nouveau quiz de 12 questions : quatre propositions, une seule bonne réponse, des distracteurs tirés des habitudes de la version 4, et sous chaque question la page du guide qui justifie la bonne réponse.

Quand la documentation se contredit ou ne permet pas de trancher, écris « à vérifier dans le logiciel » au lieu de choisir.

Ce que vous obtenez. Vous disposez de la liste des nouveautés utiles avec leurs pages, des corrections à reporter dans le support, de quatre objectifs reliés à leur épreuve et d'un quiz dont chaque bonne réponse renvoie au guide. Avant de remettre le module, ouvrez la version 5 et contrôlez chaque libellé à l'écran : la documentation décrit parfois un intitulé que l'équipe de développement a modifié ensuite. Les mentions « à vérifier dans le logiciel » restent dans le module jusqu'à la réponse de l'équipe produit.

Les pièges à connaître

Confiez-nous un module à réviser et sa documentation : le programme se construit sur eux.