Création de formations, Pédagogie R, Claude AI, Formation data science, Notebooks Quarto, Méthode pédagogique
Les meilleures idées naissent loin de l’écran. Voici comment je les transforme en formations concrètes.
Mes meilleures idées naissent sur les sentiers
Quand je cours ou que je pédale, mon esprit vagabonde. C’est dans ces moments-là, loin de l’écran, que les structures de formation prennent forme. Une analogie pour expliquer la validation croisée. Un exercice progressif pour introduire la vision par ordinateur. Une manière plus claire d’organiser le chapitre sur l’optimisation des hyperparamètres.
Je fais beaucoup de sport (course à pied, vélo, natation) et j’ai donc beaucoup de temps libre pour penser. Ces heures d’entraînement sont mes sessions de brainstorming les plus productives. Mais entre cette vision et un support de formation complet, il y a du travail.
Je ne pars pas d’un grand plan structuré. Je pars de plein de petites idées qui émergent au fil du temps :
Pendant des semaines (parfois des mois), je collecte ces petites briques. Je les note, je les teste autour de moi, je les affine. Certaines viennent de mon expérience de recherche, d’autres d’explications à des collègues, d’autres encore de mes propres galères d’apprentissage.
Ensuite seulement, j’assemble. Je regarde toutes ces briques et je cherche l’ordre logique : qu’est-ce qui doit venir en premier ? Quel exercice prépare le terrain pour le suivant ? Quelle analogie aide à comprendre quel concept ?
C’est comme un puzzle : les pièces existent déjà, il faut juste trouver comment elles s’emboîtent pour former un chemin d’apprentissage cohérent. Une fois cette structure posée, place à la création concrète.
Je ne commence pas par rédiger la théorie. Je commence par concevoir les exercices.
Une fois que j’ai mes briques conceptuelles, je cherche des datasets qui fonctionnent pour les illustrer. Je commence par chercher des données réelles avec un sujet intéressant (j’utilise beaucoup l’UCI Machine Learning Repository). Si nécessaire, j’adapte : je simplifie, je nettoie, je sélectionne les variables pertinentes. En dernier recours, je crée des données synthétiques.
L’objectif : des données ni trop faciles ni trop difficiles, avec un sujet qui parle. On apprend mieux quand on comprend ce qu’on manipule.
Pour chaque dataset, je conçois des exercices progressifs (du guidé vers l’autonome) avec des solutions commentées qui expliquent le raisonnement, pas juste le code. Et surtout, je teste : l’exercice fonctionne-t-il bien avec ces données ? Est-il faisable en formation dans le temps imparti ?
Une fois la structure posée et les exercices conçus, il faut écrire. Et écrire une formation de 4 jours, c’est long. C’est là qu’intervient Claude.
Clarifions tout de suite : Claude ne crée pas ma formation. Je pilote, il rédige.
Je lui donne l’architecture, les concepts à expliquer, le ton souhaité, les analogies que je veux. Il génère le contenu. Je teste chaque ligne de code, je corrige, je reformule, je restructure. On itère jusqu’à ce que ce soit juste.
Le gain de temps ? Énorme. Ce qui prendrait des semaines se réduit à quelques jours d’itérations intensives. Mais sans ma supervision, le contenu serait générique et potentiellement faux.
On se corrige mutuellement : Claude fait des erreurs de code que je détecte en testant, je fais des erreurs qu’il repère. Ni l’un ni l’autre n’est infaillible seul.
Je compile tout en HTML avec Quarto. Le résultat : un site web complet pour la formation.
Pour chaque jour :
Pages transversales :
Tout est accessible dans le navigateur, consultable pendant et après la formation. Les apprenants peuvent réviser, approfondir, chercher un concept dans le glossaire.
Exemple de notebook interactif : notes de cours, code exécutable et visualisations dans une même page.
Mes formations utilisent Posit Cloud Instructor. Les apprenants n’installent rien : tout fonctionne dans le navigateur, environnement identique pour tous, accès en 30 secondes.
Je prépare un projet R complet qu’ils chargent dans leur espace Posit Cloud :
renv.Le jour J : zéro problème technique, on se concentre sur l’apprentissage.
Une formation n’est jamais parfaite dès la première version.
Avant la première session, je fais relire les supports par des collègues pour repérer les erreurs et les incohérences. Puis je teste la formation en conditions réelles avec une ou quelques personnes test.
Je vérifie que :
Cette phase révèle toujours des problèmes : section trop longue, concept introduit trop tôt, exercice ambigu. Je corrige, j’ajuste, je re-teste.
Pendant mes cours en M2, j’avais pris l’habitude de noter systématiquement les points d’amélioration. Je fais pareil avec mes formations.
Après chaque session, je note : quels exercices ont généré des déclics ? Quelles explications ont posé problème ? Où les apprenants ont-ils décroché ? Quelles questions n’avais-je pas anticipées ?
Je modifie alors les supports. J’intègre aussi les nouvelles versions de packages, les retours des apprenants, les nouvelles bonnes pratiques. Mes formations évoluent constamment.
Mon objectif n’est jamais que l’apprenant “sache faire tourner le code”. C’est qu’il comprenne ce qu’il fait, qu’il puisse adapter à ses propres données, qu’il soit autonome après la formation.
C’est pour ça que je privilégie les explications détaillées, j’intègre les LLM dans la pédagogie, je propose un suivi post-formation, et je garde de petits groupes (6 max).
P.S. : Cet article a été rédigé avec l’aide de Claude. J’ai conçu la structure, rédigé les grandes lignes, et nous avons itéré ensemble pour trouver les bonnes formulations. Exactement comme pour mes formations.
Envie d’en savoir plus ?