Il n’y a pas beaucoup de choses dans lesquelles je me considère vraiment très bon. Je ne suis pas un génie. Je ne suis même pas un excellent programmeur. Mais enseigner, expliquer quelque chose à quelqu’un est définitivement un de mes points forts. La bonne nouvelle, c’est qu’il existe quelques règles simples, qui, si vous les suivez, vous permettront vous aussi de développer vos capacités à faire passer des connaissances.
(par contre je vous préviens, c’est un méchant bloc, prévoyez la lecture à la pause de midi :-p)
1 – Il n’y a rien d’évident
Quand on est bon dans quelque chose, on a tendance à considérer certaines connaissances comme la base. Tout le monde doit savoir ça. Il n’est pas rare dans notre profession, très intellectuelle, de voir même certains afficher du mépris envers ceux qui montrent leur ignorance dans ces domaines (salut cortex :-)).
La règle numéro 1, la seule à retenir si vous ne voulez pas lire le reste: il n’existe AUCUNE connaissance que tout le monde possède.
Anecdote amusante: même si il existait une chose que tout le monde savait une fois atteint l’âge adulte (ce qui n’est pas le cas), par le simple truchement des statistiques, il y aurait 10000 personnes par jour aux USA qui découvriraient ce fait. Donc qui l’ignoraient hier.
Le corollaire, c’est que donc la valeur d’une personne ne peut pas être jugée en fonction de ce qu’elle sait, ou ce qu’elle ne sait pas. Max a appris ce qu’était la signature d’une fonction le mois dernier. Il a 15 ans de métier.
Par respect donc, et par souci d’efficacité, il va falloir faire une liste des prérequis nécessaires à la compréhension de ce que vous essayez d’expliquer. Et il va falloir se demander: puis-je glisser une explication simple pour ces prérequis ? Puis-je glisser un rappel ? Au moins faire un lien vers une autre ressource qui fait ce rappel ? Quel en sera le prix (taille de l’article, temps de la conférence, complexité, énergie dépensée, etc) ? Si le prix est raisonnable, précisez cette notion, et votre article / cours / présentation touchera soudainement plus de monde.
L’exemple de la réussite de cette pratique est l’article sur les décorateurs Python. Il n’existe aucun autre bon article français sur Internet expliquant les décorateurs, parce que la plupart partent du principe que vous savez ce qu’implique qu’une fonction est un objet en Python. Ici, la moitié de l’article s’acharne à expliquer cette notion. L’autre moitié à expliquer ce qu’on peut faire avec les décorateurs. Seule une toute petite partie de l’article est vraiment une explication sur les décorateurs. La notion clé n’est pas forcément ce qui prend le plus de temps à expliquer: les choses sont simples quand on connaît le contexte.
L’exemple de l’échec de cette pratique, c’est l’article sur les vues en Python. Je suis parti du principe que les lecteurs savaient ce qu’était une structure de données et un proxy, des notions qui à mes yeux étaient des notions de base. J’ai été heureusement rapidement rappelé à l’ordre par deux lecteurs sympathiques. Si ils ne l’avaient pas fait, je serais resté dans l’illusion que mon article était bon. Car c’est tout le problème avec une mauvaise explication: personne n’a envie d’admettre que l’on n’a pas compris quelque chose. Et on crée un sentiment de rejet envers le sujet et l’auteur.
Il y a un fort attachement émotionnel qui se créé pour le lecteur si on fait bien son travail: il reçoit votre message, et dedans il se rend compte qu’il comprend, et voit l’effort que vous avez fait pour qu’il comprenne, alors que d’autres sources ne l’ont pas fait. Il se créé un sentiment de satisfaction pour lui d’avoir compris, et de reconnaissance pour vous de lui avoir expliqué.
C’est exactement ce qui s’est passé avec le site du zéro. Le mec était tellement bon que quand il a eu besoin d’un nouveau serveur (au tout début du site), il a lancé une collecte et reçu 2000 euros des lecteurs heureux. Sa boîte, Simple IT, est construite sur le lien émotionnel qu’il a créé avec ses lecteurs en ne les prenant pas pour des cons. Inutile de préciser que j’adore ce mec.
2 – Limitez le bruit
Quand vous parlez d’un sujet, limitez au maximum toute notion dont vous n’avez pas besoin dans le sujet. Si vous faites un article sur comment débuter dans le domaine x, ne mettez JAMAIS les bonnes pratiques du domaine x.
Trop de profs expliquent (ce qu’ils croient être) les bonnes pratiques à des gens qui ne connaissent pas la base. On dépense déjà beaucoup d’énergie à comprendre la base. Il y a zéro chance qu’on comprenne en plus les bonnes pratiques, et leurs implications. Et même si on y arrive, le jour où on à vraiment besoin d’appliquer ces bonnes pratiques est très loin, et on aura oublié tout cela (l’exception à cet exemple étant la formation / présentation professionnelle sur quelques jours).
Si les bonnes pratiques sont essentielles à votre cours, comme par exemple un cours sur le xHTML qui doit être valide, donnez uniquement des exemples valides. Introduisez les règles de validité sans emphase par rapport au reste. Mais ne martelez pas la philosophie de la raison de rendre le code valide. C’est un autre sujet. Traitez le ailleurs. Les gens sont ici pour apprendre à faire du code valide, pas pour entendre un sermon. Laissez les produire du code non valide. C’est une erreur comme les autres. Ça se corrige avec la pratique, comme toutes les autres erreurs.
Un autre exemple: évitez d’introduire une notion connexe comme le fait ce slideshow qui vente les mérites d’apprendre le HTML5, mais dont les exemples sont écrit avec HAML.
Si vous parlez d’un algo de parcours, évitez de parler en détail de complexité algorithmique. Juste savoir qu’il est efficace pour tel usage ou non suffit. A moins d’être dans un cours d’algo, bien sûr. Si vous parlez d’une nouvelle lib Python, ce n’est pas le moment de parler de comment installer une lib avec pip. Tous les gens qui savent déjà ça vont être gavés. Les autres vont être perdus. Installer une lib avec pip, c’est un exercice à part. Je hais de tout mon être les livres sur Django qui commencent par expliquer des notions de Python: le résultat, c’est qu’aucun des deux sujets n’est bien traité.
Montrez une seule manière de faire les choses, et de préférence la plus simple à moins qu’elle soit vraiment nulle ou que le titre de votre article soit “x façons de faire z”.
En Python, on peut par exemple faire:
sorted(truc, key=operator.itemgetter(1)) |
ou
sorted(truc, key=lambda x: x[1]) |
Lequel des deux utiliser n’est pas important pour votre sujet en cours. Choisissez-en un, ne mentionnez même pas l’existence de l’autre. On s’en branle.
Si un petit malin vient faire une réflexion en comment, mettez lui un tampon dans la tronche.
J’ai toujours fait ça par instinct, sachant que c’était plus efficace, mais sans vraiment savoir pourquoi. Jusqu’à ce que je sorte avec une neuropsy qui m’a un jour expliqué le principe des tests dans son métier: toute la difficulté est de créer un exercice qui teste une aptitude mentale, et n’implique aucune autre. Par exemple si on veut tester la mémoire, le jeu du memory est un mauvais test car il demande aussi une capacité d’observation. Vous pourriez diagnostiquer une personne comme ayant Alzheimer alors qu’elle est juste pas observatrice.
C’est pareil en pédagogie: une personne risque de ne pas comprendre un sujet car vous avez introduit une notion supplémentaire, donc un risque supplémentaire d’incompréhension. Le problème avec l’incompréhension, c’est que ça s’accumule: si on ne pige pas le premier paragraphe, le cerveau est confus, et aura plus de mal à comprendre le second paragraphe qu’il aurait compris tout de suite si il n’avait pas lu le premier. Et je vous passe bien sûr les conséquences de la frustration de l’échec dans un monde où Youtube est à un clic de votre article tout pourri.
Cette règle est très difficile à appliquer car elle contredit deux autres règles:
- La règle numéro 1. Quand vous avez besoin d’expliquer un prérequis, il faut rajouter du bruit. Néanmoins, il faudra toujours choisir de sacrifier une part du public pour respecter la règle 2. Par exemple, si vous faites un article sur une notion de Python avancée, vous pouvez sacrifier les grands débutants.
- La règle numéro 3. Quand vous voulez intéresser le lecteur, il faut dériver un peu.
C’est une question de dosage, et ça vient avec l’expérience. Mais il faut toujours travailler à améliorer ce dosage.
3 – Rendez ça fun
Notre capacité de concentration est limitée. Pour maintenir l’intérêt, introduisez des détails qui font marcher une autre partie du cerveau: un truc qui choque, qui fait réfléchir, ou rire.
Il faut faire ça de la manière la moins intrusive possible pour ne pas dégommer instantanément la règle 2. Si vous faites un trait d’humour, faites le court. Mieux encore, gardez tout l’article sérieux, mais mettez la blague dans le nom d’une variable du code d’exemple, dans un lien sortant de l’article, dans une référence cinématographique sans vous attarder, dans une photo d’illustration, dans un title qu’on lit au survol, dans le ton général de l’article.
Ce n’est pas grave si tout le monde ne comprend pas. Nous n’avons pas tous le même humour. L’idée est de ne pas déconcentrer l’audience, mais que ceux qui tiltent aient un sourire au coin de la bouche.
Si vous commencez vraiment à vous toucher, vous pouvez utiliser des citations, des blagues complètes, des petites histoires et autres moyens plus imposants. Mais c’est advanced. Garder un rythme avec ça, c’est plus difficile.
Dans tous les cas n’en abusez pas. Voir règle 2.
4 – D’où on vient, où on va
L’être humain est biologiquement câblé pour détester l’inconnu. Et quand il n’aime pas, il fuit. Sur Internet ça se traduit par la fermeture de l’onglet, dans une conf par la consultation de Facebook sur son mobile, etc.
En gros, quand vous commencez un article, votre accroche doit toujours indiquer de quoi on va parler et pourquoi. Avec si possible une forme qui donne envie de lire la suite.
Rapidement, il va falloir aussi respecter la règle 1, sinon les gens vont se demander ce qu’ils foutent là. Si vous ne respectez pas la règle 1 dans le but de respecter la règle 2 ou parce que vous n’avez pas les ressources pour le faire (vous écrivez un article de blog, pas un livre…), alors glissez une explication de ce que l’on a besoin de savoir pour comprendre la notion. Comme ça les gens savent pourquoi ils ne comprennent pas, et peuvent choisir de se documenter au lieu de juste se barrer. Ils peuvent aussi se dire “ok, je comprends pas ça, mais ça ne m’empêche pas de retenir, comme ça quand je saurai l’autre truc plus tard, tout ça deviendra utile”.
Et annoncez la couleur: si c’est un article que vous avez fait long et pompeux, ben dites le. Au moins ils sont prévenus. Si vous allez taper un coup de gueule, introduisez avec le bon ton. Les personnes qui ne sont pas d’humeur sauront que l’article n’est pas pour elles, du moins pas aujourd’hui.
Enfin, de manière générale, respectez l’adage de notre bon Pikachu. Heu, Picasso, pardon:
Pour apprendre quelque chose aux gens il faut mélanger ce qu’ils connaissent avec ce qu’ils ignorent
Ne communiquez pas en zorglang, partez d’une base commune. On se sent en sécurité, et on peut commencer à chercher à comprendre le reste.
5 – Une bon dessin vaut mieux…
Des schémas et des exemples. C’est votre priorité.
Les schémas servent à avoir une vision globale: utilisez les partout où vous avez des relations complexes à expliquer telles que des imbrications, des flux non linéaires (car pour les flux linéaires une liste suffit), des dépendances sous forme de graphe, etc.
Mettez des exemples de mises en œuvre et d’usages. La mise en œuvre permet de savoir comment ça marche. L’usage permet de savoir à quoi ça sert. Les deux sont importants à la compréhension. Dans notre métier, les exemples sont généralement du code. La mise en œuvre, c’est le code qui montre “comment écrire un décorateur”, l’usage c’est le code qui montre “pour quoi utiliser un décorateur”.
Et si vous écrivez beaucoup de texte: une liste vaut mieux qu’un paragraphe. Deux parties titrées valent mieux qu’une grosse partie. Deux petits paragraphes valent mieux qu’un gros. Divisez. Mettez du gras sur les notions clés. Faites des phrases courtes. Rendez la lecture en diagonale facile.
Les gens ne vont JAMAIS lire votre article de bas en haut. Il vont cherchez les images et schémas et sauter sur eux. Si il n’y en a pas, ou si ils s’aperçoivent qu’ils ne comprennent pas uniquement avec le schéma (et en supposant qu’ils aient encore la patience pour lire la suite), ils vont scanner rapidement la page pour cherche des exemples. Pour nous des bouts de code. Si il n’y en a pas, ou si les exemples ne suffisent pas pour comprendre la notion (vous avez déjà perdu la moitié de votre auditoire ici, dans une conf, tout le monde check ses mails à ce stade), ils iront lire le texte.
Même ceux qui croient lire de haut en bas ne le font pas. Inconsciemment, nos yeux scannent les pages, et notre cerveau évalue le coût de la lecture, avec un ratio “intérêt pour le sujet” / “effort demandé”. On a de la chance, en info, généralement le dividende est plus conséquent que dans d’autres domaines comme la finance ou les jeux vidéos. C’est aussi pour cette raison qu’il faut utiliser des phrases simples, pas alambiquées, dans une mise en page claire, car sinon on augmente ce qu’on appelle en ergonomie la “charge cérébrale”. En gros la consommation CPU de la tête du lecteur. C’est très sérieux, il y a même des outils pour calculer la lisibilité d’un texte.
Exemple ironique: cette page qui parle de complexité de texte, et qui est une corvée à lire.
Cette règle est applicable à tout système qui doit être compris: blague, machine outil et surtout… UI. Google et Apple respectent ces règles sur leurs sites et téléphones.
La seule exception à la règle 5 est l’article dit “d’essai”, comme celui que vous êtes en train de lire. Mais sachez que ce genre de texte demande beaucoup de travail, et sera lu par une minorité.
6 – Laissez les gens se planter
C’est dur. C’est très dur.
Mais le mécanisme de base de l’apprentissage c’est de se vautrer comme une grosse loutre bourrée à la bière. De s’en apercevoir. Et de recommencer en essayant de ne pas se planter cette fois.
Et de se planter à nouveau. for… in et try/catch.
Donc, si vous êtes dans un cours, ou avec un collègue en train d’expliquer un truc, résistez à l’envie de lui donner la réponse. Résistez à l’envie de corriger son code tout merdique qu’il va mettre en prod (l’enculé !).
Si vous émettez une critique, ce sera une seule. Même si il y a 20 choses à redire. On est limité dans le nombre de critiques qu’on peut assimiler. Après on se braque.
Et évidement, ça va sans dire, ne soyez pas méprisant dans votre critique. Vous faites de la merde vous aussi. Et elle sent pas la rose.
Mais inutile d’envelopper ça dans un sandwich de compliments comme on vous l’apprend en cours de com’, et surtout, surtout, évitez ces tournures à la con de la soi-disant “communication non violente” du genre “tu penses pas que ce serait mieux si…”. Dites clairement et simplement ce que vous pensez. Il y a rien qui crie plus “je te regarde de haut” qu’un mec qui essaye maladroitement de ne pas te blesser. Laissez ça aux gonzesses, elles elles savent le faire correctement, nous on sonne encore plus désagréable et faux-cul.
Très instructif !
Ça me fait penser un un truc tout récent.
Hier j’ai ouvert un ticket sur github pour faire part d’un problème dans la doc d’installation d’un module django mais il a été fermé aussitôt parce que l’auteur m’a montré que je n’avais pas compris l’explication, seulement, dans sa doc, il “perd” le “débutant” en fournissant des exemples qui ne fonctionnent pas. conséquence j’ai désinstallé le module. Ça reflète bien tout ce que tu décris.
Et il a mal réagit : quand on voit que quelqu’un n’a pas compris quelque chose qu’on a écrit, il est important de cherche à comprendre pourquoi. Parfois c’est parce qu’il est un peu con, mais le plus souvent c’est par parce qu’on a mal expliqué.
On dit souvent qu’il n’y a pas de mauvais élève, et qu’il n’y a que des mauvais profs.
C’est faux. Il y a des tas de mauvais élèves.
Mais proportionnellement, il y a beaucoup plus de mauvais profs que de mauvais élèves.
Merci pour cet article, lu du début à la fin (sisi: on connaît la maison, donc en confiance). J’ai relevé quelques typos, transmises par le formulaire de contact…
s/Il vont cherchez les images et schémas et sautez sur eux/IlS vont chercheR les images et schémas et sauteR sur eux
s/ils vont scannez rapidement la page pour cherche des exemples/ils vont scanneR rapidement la page pour chercheR des exemples
il faut utiliser des phrases simples, pas alambiquées, avec peu de fautes d’orthographe, dans une mise en page claire, car sinon on augmente ce qu’on appelle en ergonomie la “charge cérébrale
:D
Merci pour cet article génial !!!!
@Cédric: tu t’es fais grillé par fero qui m’a envoyé par mail une liste de malade ^^
Excellent article. Quelques irréductibles gaulois essayent de remonter le niveau et cela fait plaisir (seb sauvage, flibuste, mange ta main, site du zéro…). Quelle bouffée de fraîcheur !
Un truc que j’ai appris en enseignant le jeu de go c’est que parmi les connaissances qu’on a les plus importantes à transmettre sont celles qui nous paraissent les plus évidentes, pas les trucs les plus astucieuses les trucs les plus astucieuses ne peuvent être comprises qu’une fois les choses évidentes assimilées.
Wow, ça c’est de l’article !
Sinon perso, je n’aime pas ce qu’est devenu le SdZ :/ ça serait difficile de l’expliquer de façon concise mais en gros j’ai eu quelques déceptions et je trouve que c’est devenu trop commercial …
Comme quoi, aussi, en plus de ne pas pouvoir savoir tous la même chose, on ne peut aussi être tous d’accord sur les même choses :p
Et ce, si bien fait, pour le meilleur des mondes : Ouverture de l’esprit, développement de l’esprit critique, échanges enrichissants, etc etc ^^
Lol à ce propos je trouve même que malgré l
Merci pour ces beaux conseils. L’article est top !
Petites fautes :
– “En même si on y arrive le jour où on A” (le début aussi : “Et même si” ou “En même temps si”)
– J’ai bien aimé la fonction “lambad” :p
Super article. Et respect pour savoir enseigner correctement, c’est quelque chose d’essentiel et d’honorable.
Franchement, y a que du bon dans cet article…
…6 points importants pour ne pas dire “essentiels” sur lesquels il ne faut pas transiger !
Former, ça ne s’improvise pas et ça demande énormément de préparation ; c’est pas juste un sketch qu’on fait devant un auditoire (perso j’estime établir un contrat moral avec mes stagiaires/apprenants quand je commence à gérer un stage ; ils doivent apprendre ce qui leur sera utile, si possible de façon fluide, avec du fun parce qu’en même pas 20 minutes tu peux perdre ta salle si t’es chiant comme une rangée de poireaux plantés dans la boue et surtout…il faut aimer ce qu’on fait, sinon ça se verra tout de suite et là, c’est mort)…
Et puis, même en tant que formateur…
…il faut accepter de se planter de temps en temps et l’assumer (même les meilleurs ne sont pas des machines et il y aura toujours un jour où on se vautrera comme une quiche, parfois pour la plus grande joie des stagiaires) !
Bref, parfois c’est un peu comme un marathon…mais j’avoue que y a un méga pied à prendre quand tu constates que tu as fait passer le truc de la bonne façon et que ça a été un bon moment pour tout le monde… C’est passionnant !
Merci pour l’article Sam… ;-)
Je suis Autodidacte alors je peux pas dire de mal sur des profs que j’ai jamais eu, tout ce que je me rappelle c’est qu’en Seconde il y a de celà très longtemps un prof m’avais dit car je venais d’eteindre un ordi sous win 3.1 sans cliquer sur Sart > Fermer mais en cliquant sur le switch Marche / arrêt de l’ordi :
“Toi tu finiras pas l’année”…
Sérieux des connards comme ça ça vous plombe un un moral d’acier, là où Sam excèle c’est qu’il m’aurait expliqué pourquoi il fallait pas l’éteindre d’un coup.
Perso je m’en fous que le prof soit pas forcément un kador, du moment qu’il comprend que je comprends rien et ça c’est pas donné à tout le monde, loin de là.
Il faut aussi beaucoup de patience pour expliquer à des gens comme moi qui veulent arriver au résultat sans chercher à comprendre comment, du moins dans un premier temps :)
Je rajouterais donc à ce très bon article que bien expliquer les choses c’est beaucoup de patience et expliquer à la personne en face comme à un gosse de 3 ans (ce qui revient à avoir beaucoup de…patience…)
PS: j’ai en effet pas fini l’année…
@JeromeJ: ouai, j’adore danser la lambdada.
@kinezana: oui enfin je triche un peu. Un formateur Python/Django il a une motivation financière substantiellement plus importante qu’un prof de fac, et pour un travail bien moindre. Etre un bon prof prend une énergie de dingue, c’est pour ça qu’il y en a si peu.
@JEEK: +1 pour le contrat moral. Moi ça me bouffe si la personne en face de moi comprend pas. Je VEUX qu’elle comprenne. Je dors mal sinon.
@Max: et regarde ce que ça a donné: tu es tombé dans le porno. Profs de tous bords, prenez soin de vos élèves, sinon ils finiront comme nous !
Excellent article !
Pour rebondir sur le commentaire de Sam : “Etre un bon prof prend une énergie de dingue, c’est pour ça qu’il y en a si peu.” : à l’université, les profs enseignants-chercheurs ont une pression beaucoup plus importante sur la recherche (publication de rang A+ : merci l’AERES…) et passent donc moins de temps à l’enseignement. Tous ne sont pas de mauvais profs, mais certains ne prennent/n’ont juste pas le temps d’être aussi bons qu’ils le voudraient/pourraient…
J’adore la dernière phrase. :o)
Très bon article sinon.
Cela dit, je préfère un mec qui enseigne moins et qui fais pas mal de recherche. Etre juste enseignant c’est le meilleur moyen de devenir obsolète. Il faut toujours enseigner et travailler en même temps, ne serait-ce que bénévolement, ou par jeu. Mais il faut rester dans le coup.
Pour éviter d’en mettre des tonnes dans mon précédant commentaire et rendre “le trombone” mal à l’aise j’ai fait un petit layus sur comment je ponds des screencast “muets” à destination de dev ;)
Lumineux…Comme d’ab’
Un mot pour les orthographicopathes: Les coquilles sont INEVITABLES…Elles sont le dégat collatéral d’une grande concentration sur le fond et sur le suivi de pensée.
Et trés bizarrement, un texte qui ne contient strictement aucune coquilles, me déconcentre du fond, comme si mon attention partait à la recherche de la coquille perdue.
Mais les corrections apportées par les commentaires, ne sont pas pour autant superflues…puisqu’elles participent à l’amélioration de l’orthographe de notre jeune public.
Merci pour le post, tres instructif comme d’habitude.
Je relire ce post de temps en temps,
et tenter de m’appliquer lorsque je dois faire des talks/ateliers.
roro a écrit
“Un mot pour les orthographicopathes: Les coquilles sont INEVITABLES”
Oui, mais on peut aussi utiliser des softs (payants) comme Antidote (Druide informatique), disponible sous Linux, Mac et même des OS exotiques comme Haiku ou Windows.
Ou Grammalecte en gratuit.
Par exemple, si tu soumets à Antidote
“Contenu de cette info je change d’avis”, il te propose
“Compte tenu de cette info je change d’avis”.
Ca marche mec. Tu me l’achètes et tu me l’envoies par email ? Car ça à l’air d’être super important pour toi, au point que tu penses que c’est une dépense nécessaire. Et vu qu’on travaille gratuitement sur ce blog pour fournir le contenu et que tu sembles avoir ce besoin impérieux, il est normal que ce soit toi qui offres la tournée non ?
c genial vraiment cette article publier
Vraiment un très bon article.
Plusieurs points qui pourraient encore compléter cette liste déjà complète :
– Faire des analogies pour expliquer les certains concepts touffus
bon, d’une certaine manière ce point va avec la règle “rendez ça fun” ou alors en la généralisant :
“Soyez didactique”
Car au final, ce sont aussi les techniques de transmission du savoir qui aident à faire passer le message aussi bien à des publics souvent hétérogènes mais en arrivant à capter ou garder leur attention par des méthodes diverses.
et une autre règle qui est implicite mais néanmoins importante :
– Faire en sorte que l’apprentissage soit progressif
Il n’y a rien de plus important (mais aussi de plus dur si on veut bien le faire) que d’avoir une transmission du savoir qui se fasse par paliers et qui soit à chaque étape très régulière
J’ai souvenir de jeux qui avaient cette approche modulaire (on apprends un concept à chaque niveau d’apprentissage) et c’est un plaisir de suivre un rythme qui soit bien dosé à chaque niveau (surtout dans les niveaux tuto/training).
Cet article me fait penser à un concept de traitement texte (ou éditeur de document) que je n’ai malheureusement jamais vu mis en œuvre :
L’idée serait d’avoir un document à tiroirs et présenter les paragraphes/exemples en fonction du profil du lecteur.
On pourrait en plus enrichir l’article de tous les aspects possibles (introduction, abstract, citations, références bibliographiques, notes de bas de page) mais aussi, présenter ce document au lecteur sous une forme plus adaptée à ses besoins et compétences. (par ex. sous la forme de curseurs : de “débutant” à “expérimenté” ou encore d’un “business summary” jusqu’à la version complète avec exemples et référence, le document à géométrie variable pourrait être lu de sa version la plus condensée à celle-là plus brute et exhaustive).
La déclinaison des informations renvoyées pour des documentations techniques permettrait par exemple de montrer les différentes façons de configurer un logiciel (Linux/BSD/Windows/Mac OS X) et ainsi de structurer le document autour d’un squelette avec pour certaines parties des illustrations adaptées selon le public visé.
Ce type d’approche serait tout à fait adapté à des articles de référence tels que les articles encyclopédiques (Wikipedia) qui évoluent beaucoup et bénéficient de nombreux contributeurs (chacun pourrait y apporter sa pierre à l’édifice et les références trop pointues ou trop nombreuses seraient masquées par défaut et proposées à un public désireux d’en savoir plus).
J’aime à rêver qu’un jour on puisse voir un tel outil/éditeur plutôt que de se traîner le sempiternel MS Word et ses déclinaisons qui n’ont pas évoluées depuis presque 30 ans.
Je suis prêt à parier que tous les adultes de la terre savent que le ciel est bleu. :)
@Sabcat : on est pas d’accord sur la définition de “savoir” alors. Parce que pour moi ce n’est pas le cas des aveugles et de certains déficients en couleurs. Ils ont entendu le mot “bleu”, mais n’ont aucune idée de ce que ça signifie. Ensuite, parmi ceux qui qui disent savoir que le ciel est bleu, combien sont capables :
– d’expliquer ce qu’est la couleur bleue
– de démontrer que le ciel est bleu
– de comprendre pourquoi le ciel est bleu
Enfin, “le ciel est bleu” est une phrase fausse car :
– le ciel contient des nuages, des étoiles lointaines et le soleil qui ne sont pas bleus
– selon les conditions atmosphériques, le ciel peut être dis “gris”, ou prendre des teintes violettes/roses/jaunes/vertes, par exemple lors de la pollution ou le coucher du soleil
– la nuit, le ciel n’est pas bleu
– des phénomènes physiques comme les aurores boréales, le rayon vert ou les éclipses changent la couleur du ciel
– il existe de nombreuses teintes de bleu, et le ciel n’est pas uniforme
– la manière dont nous considérons le bleu est généralement à travers la perception sensorielle et non la longueur d’onde de la lumière, et donc nous sommes inégaux dans notre conception du bleu, y compris parmi les personnes sans handicap
Je suppose que tu es un adulte, mais au regard de ces éléments, peut-on considérer que “tu sais que le ciel est bleu” ?
Maintenant, si tu veux t’en tenir à la discussion du temps qui fait, dire “le ciel est bleu” est suffisant. Si tu veut former les gens à la science de la couleur du ciel, ce qui est ici ce dont parle l’article, tu ne peux pas partir du principe que “le ciel est bleu” est une évidence.
Ça me rappelle la prépa où on avait démontré que le ciel est bleu. La où c’est con c’est que je ne me souviens même plus de pourquoi c’est la longueur d’onde bleue la moins filrée…
Ca marche dans l’autre sens quand quelqu’un vous explique quelque chose a sa manière et que vous ne comprenez pas, demandez lui un “schéma” de manière déguisée ou avec une comparaison foireuse voir proche de ce que vous avez comprit :p
Je voudrais répondre à cet article, mais ça nécessiterai un article à lui tout seul.
Former/Enseigner ne signifie pas être la personne qui dispense son précieux savoir aux élèves (contrairement à ce que pense beaucoup trop de prof d’université). selon moi un bon formateur/enseignant doit:
– Dispenser les prérequis de façon la plus simple possible.
– Vérifier avec l’apprenant que les prérequis sont acquis.
– Donner des exercices plus élaboré et le laisser se démerder*
– S’il y a un groupe les laisser interagir entre eux.
– Admirer des travaux souvent pas fini mais avec du potentiel et des idées nouvelles car dictée par aucune expériences passées.
* autrement dit, vérifier qu’il part dans la bonne direction, lui donner éventuellement une information pour lui éviter de perdre 3h sur le net tout en lui faisant potasser la documentation. C’est aussi servir de canard lors de debug fastidieux voir être celui qui pose innocemment une question de façon la plus neutre possible afin de faire obtenir un déclic à l’apprenant bloqué dans une situation.
Super, je vais peut-être devenir pédago dans mon école, je vais me servir de tes conseils!
Merci! :)
Mince ! J’avais gardé (*) cet article en bookmark pendant si longtemps sans l’avoir lu. Ça m’aurait pourtant bien servi lors de la Fête de la Science, où l’on fait de la vulgarisation pour le grand public…
La petite phrase de fin est limite… Mais on connait la maison ^^ Merci encore messieurs et bonne continuation !
(*) Et je vais bien le garder !