Les tutoriels et les manuels

L’idée de ce billet m’est venue lorsque j’ai aidé une énième personne qui avait suivi un tutoriel sans vraiment le comprendre, cette personne avait une difficulté sur des commandes que je n’avais jamais utilisé : la lecture d’une page de manuel et d’un bout de documentation m’ont suffi à le guider. Cela m’a pris 30 secondes à trouver la réponse, 10 minutes (cumulées) à l’aider de bout en bout. J’ai alors réussi à formuler l’idée suivante (rien de nouveau sous le soleil hein, juste des mots que je mets sur une idée latente)…

Lorsque j’ai « appris l’informatique », on pouvait se sentir un peu livré à soi-même. Forums, tutoriels, tout cela n’était pas vraiment courant. Il y avait les newsgroups, mais il ne fallait pas s’attendre à obtenir une aide personnalisée ! Et pourtant, on apprenait vite les choses, il suffisait de réellement s’y intéresser. Il y a toujours eu des documentations et des exemples, il fallait juste comprendre comment ça fonctionne avant de pouvoir mettre ce que l’on veut en place et l’utiliser.

Aujourd’hui, les gens veulent que « ça marche, tout de suite ». Alors ils suivent des tutoriels et utilisent des forums comme des salons de messagerie quasi-instantanée. En réalité, les « apprentis informaticiens » d’aujourd’hui n’ont plus la patience et la curiosité de ceux d’hier… Ils ne veulent plus comprendre, ils veulent utiliser.

J’ai plusieurs fois été en face de personnes, débutants en informatiques mais intéressés par un peu de bidouillage, m’affirmant que c’est comme ça que l’on apprend : on utilise des tutoriels pour mettre en place quelque chose, ensuite on l’utilise et au fur et à mesure on comprend comment ça marche. Mais il n’en est rien ! En réalité, quand on suit ce chemin, on met en place quelque chose qui a été décidé par un autre puis, quand on a un problème, on va sur un forum pour demander de l’aide, sans nécessairement comprendre ni le problème, ni sa solution.

Les tutoriels

Lorsque l’on suit un tutoriel, on installe en réalité des éléments décidés par un autre, avec une imbrication que cet autre a mise en place. Une façon de faire bien précise, parmi des centaines ou des milliers d’autres. On ignore même bien souvent qu’il existe de très nombreuses manières de faire, on s’en tient à ce qu’on lit sur un tutoriel.

Le premier problème de cette approche, c’est qu’on n’a aucune assurance quant à la qualité du tutoriel. Même sur des sites reconnus, on trouve des écrits de très mauvaise qualité. Il est très difficile d’écrire de bons tutoriels. J’en sais quelque chose : de nombreux articles que j’écris dans Linux Pratique sont sous la forme de tutoriels. Quand on écrit un tutoriel, il faut le reproduire, réfléchir à la situation dans laquelle peut se trouver la personne qui lit, imaginer que cette personne n’a aucune compétence, penser à préciser la moindre commande que l’on utilise… Malheureusement, j’ai lu bien peu de tutoriels de cette qualité. Même dans les miens, je retrouve parfois quelques approximations après publication… j’ose toutefois affirmer que je fournis des écrits un peu au-dessus de la moyenne ; après tout, ça fait plus de 12 ans que j’écris…

Le second problème découle du premier : quand une personne suit un tutoriel et qu’elle « sent » que ça ne fonctionne pas, plutôt que d’essayer de comprendre et de résoudre le problème, elle cherche un autre tutoriel en espérant que celui-ci « fonctionnera » mieux. Mais un autre tutoriel, ça veut dire une autre approche, des autres idées, parfois des autres logiciels mis en œuvre : finalement, ça met plus le désordre qu’autre chose, car la personne installe différents logiciels, qui ont parfois le même but, selon des préconisations différentes et avec une configuration différente. Et bien sûr, cette personne ne prend pas le temps de défaire ce qui a été fait précédemment : après tout, le second tutoriel est censé aboutir au même résultat et, quand on n’a pas compris qu’il y a de nombreuses façons de faire, on croit simplement que les chemins se rejoindront. Mais c’est rarement le cas. Bien sûr, tout le monde n’est pas comme ça. Mais je dois me rendre à l’évidence : c’est un cas de figure que je rencontre assez souvent sur le forum Ubuntu-fr.

Enfin, le troisième problème que j’identifie est lié à la nature même des tutoriels : on met en place ce qu’un autre a décidé. Et parfois, on termine par mettre en place des choses dont on n’a pas besoin. Je vais prendre deux exemples concrets afin d’exposer mon propos…

Mon premier exemple sera un serveur de messagerie. Quand on cherche un tutoriel sur la mise en place d’un serveur de messagerie, on tombe facilement sur des écrits qui débouchent en une installation bien trop complexe : Postfix, Courier-IMAP, Courier-POP, Procmail, Amavis, MySQL… C’est un assemblage de technologies que j’hésiterais même à mettre dans des grosses sociétés. Rien que MySQL, un serveur de bases de données : pourquoi MySQL ? Pour stocker la configuration de Postfix ! C’est-à-dire qu’il y aura une base MySQL avec une table qui contiendra les domaines gérés (un seul, dans le cas d’un novice), les adresses e-mails gérées (certainement moins d’une dizaine, dans le cas d’un novice), les redirections (même punition), etc. Et la mise en place de la configuration de Postfix dans MySQL, ce n’est pas à la portée de tout le monde ! Amavis, pour le filtrage des virus et des spams ? Mais ClamSMTP et SpamPD sont bien plus simples à aborder ! Tout cela, c’est bien pour un hébergeur… pas pour un débutant !

Un autre exemple est le serveur web. On retrouve de nombreux tutoriels expliquant l’installation d’Apache, de MySQL et de PHP… très bien. Mais on y ajoute PHPmyadmin, sans dire quelle est la réelle utilité de cet outil (ma réponse ? quasiment aucune utilité pour la plupart des gens). Et on fait des tartines sur tout ça, pour finalement dire aux gens de conserver la configuration par défaut du serveur web Apache. On n’explique pas l’existence et l’utilité du répertoire /srv. On ne dit pas ce qu’est réellement un VirtualHost. On n’explique pas les différents MPM. Ces tutoriels, qui peuvent parfois s’étaler sur de nombreuses pages, peuvent être résumés en une commande associée à un paragraphe explicatif. Les informations réellement intéressantes, on ne les y retrouve pas, ou tellement filtrées qu’elles ne sont pas comprises par les lecteurs. À ce propos, j’ai participé à l’écriture d’un hors-série de Linux Magazine, sous forme de mook (un mix entre « magazine » et « book ») ; vous voulez des bons tutoriels sur ce sujet ? Achetez ce mook, vous ne serez pas déçu !

Les manuels

En réalité, si on veut vraiment apprendre quelque chose, si on veut comprendre ce que l’on fait et être capable d’administrer la solution que l’on met en place, il faut lire les documentations officielles. On retrouve une expression qui était très courante quand je débutais : RTFM ! Read the fucking manual ! C’est limpide, non ? Tout est expliqué dans le manuel.

Les manuels des logiciels ont de très nombreux avantages :

  • ils sont écrits par celui qui a écrit le logiciel (ou par quelqu’un de proche du développeur) : le manuel officiel n’est pas une documentation sortie de nulle part, c’est un écrit qui est validé par ceux-là mêmes qui ont créé le logiciel ;
  • ils détaillent chaque aspect du logiciel, décrivent son fonctionnement et indiquent les options utilisables et leurs arguments : on n’est pas réduit à l’utilisation d’un seul aspect, on peut choisir de mettre en œuvre ce que l’on veut ;
  • ils contiennent des exemples : car une bonne documentation n’est pas abstraite, bien souvent on retrouve des exemples dans les documentations officielles des logiciels ; ces exemples ne sont pas des tutoriels, on n’est pas « tenu par la main » pour dérouler une configuration de A à Z, mais ça nous permet de voir comment les différents éléments s’articulent et de penser notre propre approche.

Bien sûr, certaines documentations sont parfois incomplètes, voire même inexistantes. Tout n’est pas parfait. Mais pour des logiciels phares comme Apache, MySQL ou Postfix, on n’a pas d’excuse : de la documentation, il y en a des centaines de pages.

C’est comme ça que j’ai appris. N’allez pas croire que j’ai acquis toutes mes connaissances en cours. Mon diplôme est un DUT GTR : « Génie des Télécommunications et Réseaux ». J’y ai appris plein de choses sur les réseaux, l’informatique industrielle, mais je n’ai eu que quelques heures de cours sur Linux ; pourtant, c’est ma spécialité aujourd’hui. Je suis autodidacte, j’ai appris avec les documentations officielles. Lorsque je lis des tutoriels, c’est uniquement pour en extraire quelques idées ; je n’ai jamais suivi un tutoriel pour mettre en place quoi que ce soit. Et je ne pense pas être meilleur qu’un autre : j’ai pris le temps qu’il faut pour apprendre, c’est tout ; tout le monde en est capable.

Alors allez-y, ne soyez pas timide, plongez dans les docs, apprenez réellement à comprendre ce que vous utilisez, ne vous contentez pas de taper des lignes que vous ne comprenez pas !

Sur le même sujet

comments powered by Disqus