schémas d’un PCB

schémas d’un PCB
Ceci est une réflexion inspirée de cet article (avec lequel je suis assez d’accord) :

Je suis totalement pour permettre aux jeunes de découvrir le monde du code : ils utilisent déjà pour la plupart des logiciels et des « choses » qui existent grâce au code. Je ne vois donc pas de raison pour leur fermer la voie. Autant pour la pyrotechnie, l’aviation ou l’armurerie, je comprends, autant pour le code, non.

D’un autre côté, s’ils veulent laisser des profs enseigner le code, il va falloir faire évoluer le système en profondeur. On ne peut pas apprendre à quelqu’un à devenir un codeur, comme on n’apprend pas à quelqu’un à devenir un peintre ou un musicien.

Le code, c’est une machine à erreurs

Premièrement, je vois mal des profs (actuels et en France, je ne saurais le dire pour ailleurs) enseigner aux élèves à coder. Pour la simple raison que l’enseignement actuel est basé sur le par-cœur et sur « l’interdiction » de faire des erreurs.

Pour l’instant, que ce soit en math, en français ou en physique, si tu fais une erreur, on te retire un point : l’erreur c’est mal.

ÉDIT : Arnaud me signale un point de vu intéressant au sujet de la pression faite au niveau des erreurs, en particulier sur le rôle des parents là-dedans plus que celui des enseignants.
(Voyez aussi le premier commentaire sous cet article pour plus de détails sur tout ça ; je ne souhaite pas trop éditer cet article davantage)

Or, la prog, c’est tout le contraire justement.
Personne, même après 30 ans, n’écrit un code qui fonctionne du premier coup. On fait des milliers d’erreurs avant d’avoir une seule fonction qui fonctionne, et on en fera mille autres pour la fonction suivantes, et ainsi de suite.

Dans la plupart des langages, si on fait un code faux, le compilateur indique où se trouve l’erreur, comment la corriger et pourquoi elle est là, mais elle laisse toujours le soin à celui qui code de corriger l’erreur. C’est une sacrée différence avec l’enseignement d’une autre langue comme l’anglais, par exemple, où l’on donne d’abord la bonne réponse (la bonne prononciation, la bonne conjugaison, etc.) puis on dit « répète après moi ».

Je ne connais aucune autre discipline où l’apprentissage est autant basée sur l’erreur que le code.

La musique ? Non : on te dit comment faire un "la", tu fais un "la". Si tu fais un "do" tu es puni, car tu ne fais pas exactement ce qui est demandé.
L’art ? Non. Les math, la grammaire, l’anglais ? Pareil.
Le sport ? Non : c’est pas basé sur l’erreur, mais sur le progrès permanent. C’est important, mais c’est pas pareil. Et puis dans les sports de duel, l’erreur de l’un est le contraire d’une erreur pour l’autre, donc il est impossible de ne pas voir d’erreurs en sport.

En code, il n’y a pas de bonne réponse

Deuxièmement, parce que le code c’est de l’art : il y a 10 000 façons d’arriver au même résultat. Certains auront des avantages que d’autres n’ont pas, mais ça ne veut pas dire qu’il y a des codes "faux" et des codes "justes".

Or, combien de fois, en math par exemple, des points sont retirés sur une copie non pas parce que le résultat est faux, mais parce que la méthode pour parvenir au résultat n’est pas celle vue avec le professeur ? Ça arrive très souvent.

Parfois c’est justifié : dans un cours sur la trigonométrie, si on demande de calculer la longueur d’un côté d’un triangle, il faut utiliser la trigo et pas Pythagore.
Mais la « vraie vie » ne marche pas comme ça, et la prog non plus.

Aussi, qui dit « plusieurs façons de faire », dit « un choix à faire ».

Là encore, vous avez déjà vu la tête d’un gamin à qui on dit « tu choisis la méthode que tu veux » ? Ils sont perdus : ils ne savent pas choisir !
Trop habitués aux consignes du style « En utilisant le cosinus, calculer x. » ou « En vous servant de Pythagore, trouvez x. ». Alors qu’une consigne du style « Déterminez x. » serait tellement mieux, ne serait-ce que pour l’élève déterre lui-même les outils adéquats à la résolution du problème.

Généralement, les examens finaux (brevet, bac) sont fait comme ça : il s’agit de trouver la réponse qu’importe l’outil utilisé. Mais c’est souvent la première fois que l’élève se trouve face à ce genre de question et il panique.

Le code, c’est des tas de choix à faire : quel langage ? quel framework ? quelle fonction ? quelle API ?
Et je ne parle pas des versions, de l’IDE ou du nom des variables… Quand on voit le nombre de gens qui râlent sur la diversité des distributions Linux et sur l’impossibilité de faire un choix, c’est mal barré…

La prog, c’est sans cesse faire des choix, des choix, des choix…

… et bien-sûr, forcément, parfois on fait le mauvais choix : utiliser du C pour faire un formulaire de renseignement pour un contact, c’est une mauvaise idée.
Du coup on a encore un choix : rester sur son erreur pour ne pas perdre 15h de travail ? Ou tout balancer et recommencer avec un autre langage plus adapté ?

Il suffit de voir comment les élèves font de l’art plastique ou font leur exercice de rédaction : c’est rare qu’ils choisissent de recommencer de zéro quand ils ont passé 2h à faire un truc qui n’avance plus…

Programmer, c’est en fait revenir à ce qu’on faisait à l’école maternelle : si je tombe, je me relève. 1 fois, 5 fois, 20 fois : peu importe. Les jeunes enfants n’ont pas peur de détruire leur sculpture en pâte à modeler ou en Lego, s’ils voient que ce qu’ils ont fait ne tient pas debout. Ils cassent tout et ils recommencent.

Demandez maintenant à un ingénieur à jeter un projet mort-né sur lequel il a balancé 100 k€ : il refusera.
Tout ça parce qu’il ne verra que les coûts passé, et non le gain à venir de laisser tomber ça : revenir sur des dépenses passées est impossible, donc autant cesser les dépenses inutiles maintenant plutôt que plus tard, non ?
En toute logique, oui.
Économiquement parlant, aussi.
En pratique, aucun cadre d’entreprise ne fera ça, et c’est psychologique (et cette éternelle « interdiction de faire des erreurs » en est probablement la cause).

Or en prog, justement il faut être logique. Oui, on a le droit de préférer le C au PHP, mais s’il s’agit de faire dans le web, le C est aussi adapté que prendre une voiture F1 pour labourer son jardin.

Faut pas avoir peur de casser des trucs : c’est comme ça qu’on apprend.
Et il ne faut pas non plus avoir peur de faire à sa façon, de faire différemment du prof. En code (contrairement à l’orthographe), la différence est une force.

En code, il n’y a pas d’études puis le travail.

(l’emphase est bien sur le « puis »).

Programmer c’est apprendre tout sa vie, constamment.
Que ce soit une nouvelle API, un nouveau langage, ou tout simplement de nouvelles choses à faire qu’on ne pensait pas possible avant, l’apprentissage est constant.

L’école nous dresse pourtant au contraire à apprendre des choses durant 5 ans, recracher ça en 4 heures lors d’un examen, et après c’est bon, on a le droit d’avoir les clés d’un métier pour mettre en pratique tout ce qu’on a appris. Apprentissage, validation, mise en pratique. De temps en temps on a droit à une formation de mise à niveau.

La prog, encore une fois, c’est différent : on apprend et on met en pratique tout en même temps ; et la validation est-elle instantanée : c’est le compilateur qui nous valide ça à la volée : ton code est faux, ça marche pas, tu t’arrêtes. Ton code est valide, il marche, tu peux continuer.

Si l’on n’est pas prêt à apprendre de nouvelles choses tous les jours, il ne faut pas coder.
Peut-être que dans 5 ans le langage que vous maîtrisez aujourd’hui sera oublié : il faudra vous recycler. C’est pas grave, c’est normal. Mais faudra passer par là.

Ceci est valable pour l’élève qui apprend un langage aujourd’hui, mais aussi pour le prof.

Pour conclure

Pour résumer, si j’ai peur d’une chose, c’est que l’enseignement n’évolue pas assez pour permettre d’apprendre la programmation.

Le code ce n’est pas écrire des choses justes tout le temps. C’est écrire des choses, fausses et justes, puis corriger peu à peu ce qui est faux.
Le code ce n’est pas reproduire les mêmes gestes que l’enseignant. C’est faire le choix de ses propres gestes, du moment que le résultat est celui qui est demandé.
Le code ce n’est pas apprendre 5 ans, valider en 4 heures et travailler durant 40 ans. C’est apprendre en travaillant et valider à la volée tout en même temps.

Enfin, le code est pour l’instant la seule discipline (avec le sport et éventuellement la musique) que la plupart des codeurs ont commencés par eux-mêmes bien avant que l’école ne les mette sur cette voie.

Tous les informaticiens jusqu’à maintenant sont surtout des passionnés qui ont débuté dans leur chambre. Personne, ou alors vraiment très peu de gens, ont tapé leur première ligne de code dans une salle de classe (contrairement à une équation, un poème, un paragraphe en anglais, une réaction chimique ou une carte de l’Europe).

Donc faire découvrir le code à l’école, je suis totalement pour, histoire de révéler des talents cachés chez des jeunes qui adorent ça sans le savoir, mais l’enseigner comme on enseigne les math ou le français, ça promet un échec monumental, qui ne viendra pas de l’élève, ni du prof, ni du langage de programmation enseigné.

image de Dilshan Jayakody

2 commentaires

gravatar
Le Hollandais Volant a dit :

Concernant le rôle des parents :

C’est un point que je n’ai pas abordé, mais c’est clair qu’il aurait sa place ici aussi.
Néanmoins, je n’ai pas dit que le « pointage des erreurs » était la faute des enseignants, mais celui de l’enseignement dans son ensemble.

Retirer un point à chaque erreur (comme dans une dictée) c’est une façon très simple de noter un élève, mais [à mon avis] pas la meilleure pour apprendre. Si l’erreur permet d’apprendre, il faudrait aussi fait le contraire : donner un texte bourré de fautes et mettre un point à chaque fois que l’élève découvre une erreur.

Ça se fait pas mal en faisant échanger les copies entre élèves, et c’est pas mal : comme le disait la remarque d’Arnaud, ça permettrait aussi à l’élève d’avoir seul son erreur face à lui (et il n’aurait donc pas le regard du parent au dessus de lui) : il peut alors la corriger tranquillement, sans pression.

Chose qui est très présente en prog (pour en revenir) :

L'avantage de la programmation permet à l'élève de savoir s'il y a une erreur sans regard extérieur. Cela dédramatise l'erreur et c'est un avantage certain où parfois pour certains élèves le regard extérieur est crispant (on en revient à la pression liée à l'erreur).

***

Concernant le rôle des parents, on cite souvent cette phrase : « les parents, ce sont des gens qui t’apprennent à parler et à marcher, pour ensuite te dire de te taire et de t’asseoir ».

Alors je ne suis pas parent, mais j’ai été enfant moi-même. Et si mes parents m’ont foutu royalement la paix niveau notes (probablement parce qu’elles étaient bonnes — ou peut-être étaient-elles bonnes parce que je n’avais pas de pression ?), et m’ont toujours plutôt encouragés à expérimenter et à essayer des choses plutôt que me dire « fais pas ci - fais pas ça » constamment, il faut voir qu’en effet, la première chose qui empêche les gens d’être curieux, de poser des questions, de découvrir les réponses, etc. ce sont les parents.

Il n’est pas non plus sans mentionner le rôle de la religion là-dedans : quand j’étais petit (il y a 20 ans) je vivais dans un petit village au centre de la France. Tous mes camarades allaient probablement à l’Église, et en tout cas tous parlaient de catéchisme. Sans vouloir caricaturer, et en tout cas pour le catholicisme, poser trop de questions peut vite devenir problématique. Ce n’est pas la science qui a dit que la curiosité était un vilain défaut. Au contraire : en science, le défaut de curiosité est très vilain.

Ce que je veux dire par là, c’est que si l’on arrêtait d’interdire aux enfants d’expérimenter des trucs, de faire des erreurs, voire de se faire mal, on pourrait éventuellement casser cette psychose de l’erreur, et aussi la psychose d’avoir à s’avouer dépassé (chose que j’illustre dans mon article par l’ingénieur qui refuse d’admettre que son projet est pourri).

Ceci est d’ailleurs repris par beaucoup de monde : https://lehollandaisvolant.net/?id=20150513162120

gravatar
Le Hollandais Volant a dit :

Louison me signale ceci :

[…] en 3ème, nous avons eu un cours d'algorithme : le prof nous a mis devant des PC, lancé un logiciels […] et on devait gérer des scénettes avec un scénario imposé […] avec des "briques" qui contenaient des fonctions IF, ELSE, WHILE, BEGIN et END. J'avais trouvé ça super amusant, et c'était l'une de mes première rencontres avec du "code". Aujourd'hui, je suis développeuse. […]

Ca reste un de mes meilleurs souvenirs du collège, et je pense que si je n'avais pas eu ce cours je ne me serai peut-être pas orientée vers l'informatique.

C’est exactement ce que je veux dire (dans l’article) par « révéler des talents cachés chez des jeunes qui adorent ça sans le savoir ».

Personnellement, c’est un peu pareil, dans le sens où c’est le hasard qui m’a jeté dans le bain de l’informatique, de Linux et du code.

Quand je suis arrivé au lycée, le Conseil Régional nous avait donné des CD : un CD avec des logiciels libres (Firefox, OOo, Gimp, Blender, VLC et plein d’autres) et un CD avec une distrib Linux (Knoppix, sous KDE). C’était en 2005.
J’avais pu essayer les logiciels directement sous Windows et la distrib Linux directement sur mon PC (un peu après).

Deux ans après, j’essayais une Ubuntu 7.04.
Un an après, j’installais Ubuntu 8.04 et j’y restais (ça fait plus de 10 ans).
Depuis je suis sous Linux Mint et c’est mon système principal.

Aussi, qui dit Linux, dit nécessairement « ligne de commandes » : ce n’est pas plus compliqué, c’est juste différent que l’interface graphique. On pourrait s’en passer (des interfaces existent pour absolument tout), mais la ligne de commande reste souvent plus rapide que tout.

Après les lignes de commandes simples, j’avais commencé à faire des petites scripts (plusieurs lignes de commandes successives), puis je me suis intéressé au code : HTML, pour débuter, puis CSS et PHP (et donc le début de la programmation à proprement parler). Un peu plus tard, je suis allé voir JS et SQL.

J’ai aussi touché au C, Python, Bash, Batch, mais dans une bien moindre mesure.

Quoi qu’il en soit, si je n’avais pas eu ces CD au lycée, ni quelques amis qui m’ont tiré sous Linux à ce moment là, il est fort probable que je ne serais ni Linuxien, ni codeur, ni blogueur, ni vulgarisateur aujourd’hui.

Il en faut parfois très peu, et j’espère que le code à l’école peut effectivement révéler des talents.

Les commentaires sont fermés pour cet article