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. Si vous parlez d’une algo de parcours, éviter 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.