Pourquoi enseigner la programmation ?
Par David Monniaux le samedi, juillet 26 2014, 17:39 - Enseignement - Lien permanent
Pour des raisons personnelles et professionnelles, j'ai manqué la grande polémique sur l'opportunité d'enseigner « le code » à l'école ; mais après tout, y avait-il besoin de l'avis d'un enseignant d'informatique alors que tant de personnes qui n'ont jamais ni suivi ni fait de cours de programmation se sont exprimées sur le sujet ? J'aimerais toutefois évoquer ce qui, à mon avis, dans un enseignement de programmation, contribue à la formation générale de l'esprit (ce qui ne veut pas dire que je soutiens tout enseignement de programmation dispensé à tout niveau et de n'importe quelle manière).
Savoir décomposer un problème
L'enseignement de la programmation évoque souvent des questions de choix de langage (faut-il commencer par Python, Java, ou un langage destiné plus particulièrement à l'enseignement), d'où la critique que, le monde informatique évoluant vite, ce que les étudiants apprennent soit démodé quelques années plus tard. Outre une certaine surestimation du renouvellement en informatique (le langage C a 40 ans, et ne parlons pas de Fortran et Cobol…), cette critique passe à côté d'un fait important : la principale difficulté de l'apprentissage de la programmation, ce ne sont pas les particularités, souvent inintéressantes, de tel ou tel langage ou de tel ou tel système, c'est la capacité, ou l'incapacité, à prendre un problème complexe et à le diviser en sous-problèmes bien identifiés et de complexité maîtrisable, de former des hypothèses sur ces sous-problèmes et de les tester, et d'identifier ce qui est important et ce qui ne l'est pas. Ceci implique, notamment, la capacité à fixer des objectifs intermédiaires et à les évaluer.
Prenons un exemple concret. Une amie aurait voulu un logiciel qui prenne l'ensemble des fichiers audio stockés dans son ordinateur et en fasse une liste triée par durée d'écoute. Les systèmes de gestion à sa disposition ne permettaient pas de produire une telle liste. Je lui ai donc proposé un petit programme, qui dans un premier temps fournissait la liste des fichiers d'un seul répertoire, puis explorait les sous-répertoires. Ce qui est intéressant, c'est sa réaction à la première version du programme, que je lui avais demandé d'essayer : elle était inutile, disait-elle, vu qu'elle n'explorait pas les sous-répertoires. Visiblement, l'idée qu'avant d'accoupler deux difficultés (l'extraction des données d'un fichier audio, d'une part, et le parcours récursif de sous-répertoires, d'autre part), il faut tester chacune indépendamment, ne lui était pas naturelle.
Les étudiants qui n'ont pas acquis cette « compétence », pour employer le vocabulaire éducatif à la mode, ne parviennent pas à réaliser leurs projets : soit que devant l'ampleur de la tâche, ils ne sachent pas par quoi débuter, soit qu'ils passent trop de temps sur des détails au risque, de toute façon, de devoir revenir dessus.
Savoir se remettre en cause
On sait bien que ce qui est pénible dans la programmation, c'est le déboguage, autrement dit la recherche de la source d'un dysfonctionnement dans un logiciel. La première difficulté du déboguage est la remise en cause des certitudes et de la fierté du développeur.
On voit parfois des étudiants qui, devant leur programme qui ne fonctionnent pas, évoquent la possibilité d'un bug non pas dans leur propre production, mais dans l'environnement de développement utilisé. C'est bien sûr une occurrence du proverbe « un mauvais ouvrier a toujours de mauvais outils », avec ce trait bizarre d'incongruité ou d'excessive confiance en soi qu'il y a à évoquer en première hypothèse la possibilité d'un dysfonctionnement dans un système professionnel et utilisé par des millions de personnes plutôt que dans le programme d'un débutant…
De même, on entend souvent des étudiants se plaindre d'avoir été notés « injustement ». Comme le rappelle Gilles Dowek, l'exécution incorrecte d'un programme est un fait objectif : s'il affiche 3 ou s'arrête inopinément alors qu'il devrait afficher 10, il n'y a nulle possibilité d'invoquer la sévérité excessive de l'enseignant ou de dénoncer la subjectivité de la notation d'une dissertation.
Un logiciel est une création de l'esprit : il n'y a pas de contingence matérielle. Un dysfonctionnement d'un logiciel créé par un individu (la responsabilité est bien entendue plus facile à diluer s'il s'agit d'un groupe d'individus) est donc, sauf bug dans l'environnement de programmation, due à une erreur de conception, une erreur de pensée. Ceci est difficile à admettre, et la première difficulté du déboguage est de savoir se remettre en cause et d'admettre que l'on a fait une erreur.
Douter de tout, jusqu'à preuve du contraire
La grande difficulté du déboguage est que l'on arrive sur le programme avec des idées préconçues sur ce que chacune de ses parties est censé faire. Le mot « censé » est important, puisque, vu que l'on cherche un bug, c'est fort probablement qu'il y a une partie du logiciel qui ne se comporte pas comme on le pensait. Or, très souvent, on part sur une idée préconçue sur ce qui ne fonctionne pas et pourquoi.
Il y a quelques années, des étudiants me montraient une procédure de (si je me rappelle bien) parcours de graphe, qui m'avait l'air correcte, mais qui ne fonctionnait pas correctement. Cette procédure en appelait une autre qui gérait une structure de données simple. Je demandai ce que celle-ci faisait ; on me paraphrasa son nom. Je demandai s'ils étaient sûrs qu'elle faisait réellement ce que son nom laissait supposer. Il me fallut insister pour que les étudiants consentissent à vérifier cette procédure, qui était effectivement la coupable.
Je ne voudrais pas que l'on pense que je m'exonère des faiblesses humaines que j'attribue aux étudiants, aussi je dois avouer qu'il m'est parfois arrivé, devant le travail incorrect d'un étudiant, de penser avoir rapidement trouvé la cause du problème, en me trompant largement.
Pour déboguer efficacement, il faut donc se méfier des idées préconçues et des supputations, et procéder avec méthode. Recommandation que l'on peut appliquer dans bien d'autres domaines d'activité.
Douter des idées préconçues
En informatique, il est courant d'avoir des idées préconçues sur ce qui coûte cher ou non (en temps de calcul, en mémoire, etc.). Ces idées sont parfois adossées à un cadre théorique (étude de la complexité des algorithmes, classes de complexités de problèmes) ; mais se pose alors la question de l'applicabilité de résultats théoriques, obtenus sur un modèle simplifié de l'exécution d'un ordinateur, et donc les critères (par exemple, complexité dans le pire cas général) peuvent ne pas être pertinents pour le problème à résoudre effectivement — on touche ici à un problème épistémologique.
Or, ces idées préconçues s'appliquent parfois au cas d'espèce étudié… mais parfois non, et elles induisent alors en erreur — d'où le dicton de Daniel J. Bernstein, « Profile, don't speculate! » — « mesurez réellement les consommations en ressources plutôt que de supputer ».
Qui plus est, mesurer ces consommations n'est pas forcément aisé (par exemple, dans certains cas, il est pertinent de mesurer des consommations amorties sur un grand nombre d'action, et non la consommation de chaque action individuelle), et un choix inapproprié d'exemples ou de technique de mesure peut biaiser les résultats.
Il s'agit, là encore, de problèmes que l'on retrouve dans bien d'autres branches d'activités : dans d'autres sciences et techniques, bien sûr, mais aussi en politique — combien de débats sur des supputations et non sur des faits, sur des chiffres dont on ne sait pas comment et sur quels échantillons ils ont été obtenus, combien de mesures proposées qui n'auraient qu'une influence négligeable au regard de ce qu'elles seraient censées corriger…
Observer et réfléchir à des réponses pertinentes
Une partie des étudiants, devant un dysfonctionnement dans un programme pourtant pas si faux que cela, n'abordent pas la difficulté méthodiquement, mais au contraire essayent des modifications pas toujours très pertinentes, voire même sans rapport avec le problème rencontré. Au final, ils finissent souvent par produire quelque chose de plus faux que leur premier jet.
Par ailleurs, il est courant que les étudiants, malgré toutes les invitations des enseignants, ne lisent pas les messages d'erreur affichés par le système. Je n'ai pas d'explication ou de théorie quant à ce fait, mais je le constate année après année.
Ainsi, là où il faudrait s'informer et réfléchir posément à ce qui peut mal aller, l'étudiant va souvent absolument vouloir « faire quelque chose », un petit peu au hasard ou sur la base d'idées préconçues ; puis comme ça ne fonctionne toujours pas, il essaye autre chose, etc.
On peut sourire devant pareil comportement, mais que font d'autre nos parlementaires quand, dans la hâte et pour réagir à un « fait divers », et sans prendre le temps de s'informer, ils produisent une loi de circonstance afin de démontrer qu'ils « agissent » ?
L'apprentissage de la méthode
On peut résumer ce qui précède par : la programmation (et surtout le déboguage) nécessite un esprit méthodique, qui sait diviser un problème en sous-problèmes, tester et évaluer des hypothèses, et se remettre en question ; les esprits confus ou qui se perdent dans les détails n'arrivent pas à mener à bien leurs projets. Son apprentissage, mené sérieusement, devrait donc développer certaines qualités d'esprit transposables à d'autres domaines.
Ces qualités sont, en bonne partie, les mêmes que celles nécessaires pour les travaux scientifiques ; on pourrait aussi les développer au travers des sciences expérimentales. Cependant, il est bien plus simple et rapide d'arriver avec la programmation sur des problèmes intéressants, alors qu'en physique, chimie ou biologie les expériences sont plus longues, nécessitent du matériel et posent éventuellement des problèmes de sécurité.
Les difficultés des mesures et le danger des préjugés s'appliquent, bien sûr, également aux sciences sociales. Du cours de sciences économiques et sociales de seconde, je ne me rappelle que d'une chose : la facilité avec laquelle on peut se laisser abuser par les chiffres, suivant comment ceux-ci sont présentés (par exemple : comment on peut avoir, sans mensonge ni trucage, à la fois le salaire moyen qui baisse dans chaque catégorie professionnelle tout en ayant une augmentation du salaire moyen de la population entière des travailleurs). L'avantage de l'informatique est que l'on peut aborder cette question de la mesure, de la méthode de mesure, des préconceptions sur son résultat, sans que la réflexion ne soit incommodée par des considérations politiques et des supputations sur les biais idéologiques des enseignants.
Que faire ?
La question de l'enseignement de l'informatique à l'école primaire et dans le secondaire est posée en France depuis une trentaine d'années. Dans les années 1980, le « plan informatique pour tous » mettait des ordinateurs Thomson MO5 et TO7 dans les écoles primaires et les collèges ; si certains instituteurs, dont mon maître de CM2, savaient programmer, il semble que ce plan ait été un échec notamment en raison de manque de formation pour les enseignants et de manque de personnel compétent pour gérer le parc informatique. Dans les années 1990, il existait une option informatique au baccalauréat ; celle-ci a été supprimée par la suite, pour des raisons que j'ignore.
La programmation, orientée vers le calcul numérique scientifique, était enseignée dans les classes préparatoires aux grandes écoles scientifiques. Jusqu'en 1997 existait à l'agrégation de mathématiques une option informatique, portant il me semble en partie sur les mathématiques discrètes. Celle-ci a été supprimée, puis on a réintroduit plus tard une option informatique portant notamment sur la logique et les automates.
Parallèlement, on a introduit dans l'enseignement secondaire et supérieur des formations « informatiques » qui sont, si je ne m'abuse, plutôt des formations à certains usages de l'informatique (bureautique) et à leur cadre juridique.
Tout ceci nous montre bien l'inconstance, l'incohérence et l'inconscience des décideurs publics en la matière. Quant au débat public, il semble comporter d'une part ceux qui pensent que mettre de la programmation à l'école primaire est nécessaire pour l'économie (j'en doute fortement, pour tout avouer), d'autre part ceux qui pensent que la programmation est une activité « technique » qui n'a pas sa place dans l'enseignement général puisqu'elle ne forme pas la pensée. J'ai voulu répondre aux seconds.
Commentaires
À toutes ces raisons d'enseigner la programmation, qui sont des raisons de formations de l'esprit (mais que l'on retrouve, sous d'autres formes, dans d'autres domaines...) j'en rajouterai une assez simple, "citoyenne".
Dans le monde d'aujourd'hui, on utilise des ordinateurs à tire-larigot. Des ordinateurs qui peuvent faire beaucoup de choses, si tant est qu'ils aient été programmé.
Savoir ce que programmer, ce qu'on peut faire et ne pas faire avec un ordinateur, c'est se donner aussi les moyens de critiquer les outils qui nous sont proposés, et ne pas être des consommateurs passifs...
@Maïeul: Oui, j'envisageais de parler de « lutter contre la pensée magique » mais ce billet était déjà trop long. Je vais peut-être rédiger un deuxième billet.
Complètement d'accord avec la "rectification de point de vue" qu'apporte ce billet.
Reste qui si on veut qu'ils implémentent (et un argument du papier est que le compilo, l'interpreteur ou l'execution sera inhumain et amoral, donc il faut implementer), il faut aussi choisir un langage, un environnement etc. Mais bon, au moins les fins sont mieux posées avec un tel billet. Il contraste avec le point de vue de Fioraso qui semble être : il faut former des codeurs pour être compétitif et créer des emplois.
Merci beaucoup d'exprimer aussi clairement tout cela !
Il manquerait presque un mapping avec les parties de l'enseignement primaire censé apporter *dès à présent* les compétences décrites dans l'article.
Le vrai mirage des politiques c'est de croire que l'apprentissage pourra se faire sans efforts grâce à l'aspect ludique du "codage" (désolé fallait que je le place au moins une fois) sur machine.
Merci DM. Je vous ai lu avec attention mais à mon grand regret vous ne donnez pas d'avis personnel sur le niveau d'enseignement dans lequel l'enseignement de l'informatique serait bienvenu ou s'imposerait, ni dans quel cadre. Nul ne doute de l'intérêt de l'enseignement informatique, mais la question qui se pose est bien celle-là.
Notez que beaucoup d'experts de l'informatique ont donné leur avis sur la question (SIF, EPI, Académie des sciences, INRIA, FING etc.)... mais assez peu d'enseignants du primaire, qui connaissent pourtant bien les élèves de cet âge et leurs capacités. Et effectivement j'ai lu assez peu d'interventions d'enseignants en informatique : ils émanaient pour la plupart de professeurs du secondaire (souvent de mathématiques ou de technologie) dans le cadre de l'option ISN. Notez également à ce sujet qu'ils enseignent (d'après ce que j'ai pu lire) essentiellement la programmation web.
PS : j'utilise un logiciel paramétrable à l'infini qui permet justement de trier des fichiers musicaux par durée, fréquence, date d'écoute etc. ;-)
Vu d'ici, le débat médiatisé a rapidement transformé l'enseignement de la programmation en enseignement de l'HTML, qui ne me semble avoir aucun des avantages décrits dans ce billet.
Au mieux il s'agit d'une synecdoque pour désigner les applications JavaScript agissant sur du HTML5, pour avoir rapidement et portablement des résultats, mais je crains que ce ne soit qu'un renoncement et une technisation de plus.
« Par ailleurs, il est courant que les étudiants, malgré toutes les invitations des enseignants, ne lisent pas les messages d'erreur affichés par le système. Je n'ai pas d'explication ou de théorie quant à ce fait, mais je le constate année après année. »
Ma théorie est qu'il s'agit d'une instance du conditionnement des utilisateurs à ignorer les messages d'erreur dans des boîtes des dialogue, qui s'est généralisée à ignorer tous les messages d'erreur, voire tous les messages évidemment émis par un programme.
Combien de fois ai-je informé quelqu'un qui me demandait de l'aide que « le problème est bien décrit dans la boîte de dialogue que tu viens de fermer. » et la réponse est inveriablement « hein ? quelle boîte de dialogue ? » (pour une personne sachant ce qu'est une boîte de dialogue, sinon le vocabulaire est adapté mais la sémantique est la même) ?
Un message d'erreur du compilateur me semble avoir la même position mentale qu'une boîte de dialogue d'erreur : quelque chose d'inattendu qui se met en travers du chemin vers un objectif, et qui est évacué du champ conscient et/ou de l'écran aussi vite que possible, en restant focalisé en continu sur l'objectif.
En primaire : Lire, écrire, compter.
Qu'on arrête de dire "mathématiques" en primaire, c'est ridicule. "Calcul" serait plus adapté. Est ce qu'on dit "littérature comparée"?? non, on dit qu'on apprend qlqs poésies pour enfant ou que sais je...
Pour ce qui est de l'info, il faut bien sûr distinguer l'info théorique (des maths), la capacité à coder et la capacité à se servir d'un ordinateur/téléphone portable etc.
La capacité à s'en servir reflète bien le mode de pensée. Pour toute une génération à qui on a appris des choses à l'école sans réfléchir et surtout sans jamais remettre en cause l'autorité apprenante, c'est foutu. Jamais ils ne seront jamais à l'aise avec un ordinateur.
Pour ce qui est des gens en primaire/collège/lycée actuellement, un cours d'info théorique seraient hors de propos et un cours d'info pratique totalement inutile (sauf pour ceux qui n'ont pas du tout accès à tout ça...mais ça devient de plus en plus rare).
Reste donc le "code". Si c'est pour leur apprendre à trier un tableau, autant rester coucher. Ça ne va intéresser "personne". Par contre, faire disons un petit jeu dans un langage très simple, voire même graphique 'à la labview' pourquoi pas.
Problème évident : quelle plate-forme de devel serait suffisamment simple Qui va enseigner ça
@Loys Bonod: Bien qu'ayant été agrégé titulaire, je n'ai jamais enseigné dans le primaire ou le secondaire. Pour émettre une opinion précise sur ce sujet, je dois donc me baser donc sur mes propres souvenirs d'élève, qui datent de plus de 20 ans... En raison de mon ignorance des programmes, des emplois du temps et des options présentées, je me suis donc borné à des remarques d'ordre général répondant au discours — dont vous semblez nier ou minimiser l'importance, mais qui est bien présent — selon lequel l'informatique n'aurait aucun intérêt dans le cadre de l'enseignement général car à ce niveau il faut développer la pensée.
Puisque vous m'invitez à parler de l'enseignement primaire, je repense à ce qui se faisait dans le plan « informatique pour tous » et relève une difficulté. Dans le temps, il était possible de programmer simplement, je veux dire par là que si on voulait tracer une ligne il suffisait de taper une instruction du style
LINE x1,y1,x2,y2
; si on se met à jouer avec des outils Web tout se complique (rien que comprendre comment on doit déployer les fichiers...). Mais peut-on motiver des élèves avec une tortue LOGO tandis qu'ils voient à côté des graphismes de haute qualité ? J'ai entendu parler d'environnements de développement et de langages adaptés aux enfants, mais je n'ai pas encore essayé, faute de temps...(Quant à votre logiciel de classement audio, je ne doute pas que de tels logiciels existent. Cependant, en l'espèce, je voulais voir rapidement ce qu'il était possible de faire en Python pour répondre à un tel problème. Je n'ai mentionné cette anecdote que parce qu'elle me semble illustrer la difficulté pour bon nombre de personnes à découper un problème en parties assez indépendantes que l'on résout les unes après les autres, ou à admettre une résolution progressive d'un problème.)
@Loys Bonod, Natacha: Le manuel d'option ISN de Gilles Dowek prend Java comme langage d'exemple et ne me semble pas spécialement comporter de programmation Web.
Je ne sais pas trop ce que cela veut dire que « programmer en HTML » (suggestion qui me semble probablement découler d'une déformation journalistique). S'il s'agit d'expliquer aux enfants qu'on obtient du gras en écrivant
<b>
, j'ai peur que cela ne soit assez inutile et dépassé (de nos jours, on produit les pages Web avec des logiciels d'édition, des CMS... rarement en les tapant directement à la main). S'il s'agit de faire des choses jolies ou d'animer tout cela avec du Javascript, j'ai peur, comme Natacha, que la technicité ne soit considérablement trop grande en raison de la multiplicité d'interfaces biscornues. La programmation Web au point de faire quelque chose de joli et montrable, c'est un emploi à temps plein.J'aurais aimé connaître l'avis de votre instituteur. Je crois que nous avons le même profil. Nous ne devons pas être trop nombreux. Ma dernière classe remonte à 1997.
Il est difficile, à un professeur des écoles de 2014, de donner un avis sur quelque chose qu'il n'a jamais connu.
J'ai fait «programmer» en Basic à la garderie du soir de l'école que je dirigeais, jusqu'au jour où un psycho-machin décréta que faire programmer des enfants, en Basic, c'était les massacrer en mathématiques à cause de la boucle caricaturale GOTO.
Or, bien au contraire, cela permet de faire des progrès fantastiques en calcul, en résolution de problèmes, dès qu'on introduit des variables.
Voici ce que je referais aujourd'hui si j'avais encore l'énergie suffisante:
http://www.rriou.infini.fr/basic-25...
Je ne suis ni informaticien ni mathématicien. Si j'ai écrit de grosses bêtises, merci de me le signaler.
Programmer des petits jeux (en Python, Java), au dires de professeurs d'ISN que je connais, c'est ce que font 80 à 90 % des lycéens qui prennent l'option ISN. Je suis donc surpris du retour de M. Bonod. Effectivement, figure bien dans le programme d'ISN une présentation du HTML, mais cela semble un point mineur de celui-ci, et pas le plus fécond pour le projet que les élèves auront à rendre. On peut se référer par exemple à cette page de l'académie de Versailles, qui regroupe les ressources à l'attention des professeurs d'ISN.
Sur le reste du billet, on ne peut que féliciter son auteur pour la clarté de l'exposé des faits.
On se pose effectivement la question de savoir à quel niveau enseigner cela à nos jeunes pousses. On devrait souhaiter que chaque discipline développe la capacité de l'élève à douter et à se remettre en cause, à décomposer un problème en sous-problèmes, à observer et élaborer une réponse pertinente. On devrait bannir de l'enseignement les disciplines qui ne développent pas ces "capacités". Des idées de candidats ?
Certaines disciplines le font par un travail sur le monde extérieur (sciences physique, SVT, étude de textes littéraires, histoire, langues), l'informatique (voire les mathématiques) par le travail sur un mondé créé de toutes pièces. Mais pour en arriver à travailler ces capacités, il faut déjà une certaine bases de connaissances qui permette de comprendre un problème et de comparer ce qu'on observe à ce que l'on sait.
Au niveau CP, je ne vois pas beaucoup mieux que la tortue Logo, vu le manque de culture des élèves. Le logo donnait un langage simplifié permettant rapidement d'observer le résultat d'une action programmée, donc réfléchie. Les jeux à graphismes ultra développés auxquels jouent les enfants ne leur proposent généralement que des résultats instantanés à certaines pressions de boutons. Je ne suis pas sûr que beaucoup de jeux proposent des expériences de réflexion telles que proposées par la tortue logo que l'on devait programmer pour qu'elle réalise un dessin choisi à l'avance, ni que les jeunes soient complétement blasés par la pauvreté des graphismes à cet âge.
Pour la programmation web en spécialité ISN, je me réfère par exemple à ce témoignage, où on parle même de créer des applications pour smartphones :
http://binaire.blog.lemonde.fr/2014...
Il est vrai que Python s'ajoute souvent au programme des deux heures hebdomadaires. Un exemple : http://fsincere.free.fr/isn/present...
Les programmes officiels précisent que "l'enseignant choisit un langage de programmation selon les critères suivants : simplicité d'utilisation, liberté d'installation, présence d'outils associés, existence d'une communauté d'utilisateurs et de bibliothèques facilitant le développement."
@Loys Bonod: Donc programmation en Javascript, par exemple.
Ce n'est pas stupide : il est beaucoup plus attrayant pour les élèves de faire des choses modernes et « montrables » (aux amis, à la famille), par exemple un site Web dynamique ou une appli pour Smartphone, que des petits programmes qui calculent ou trient des choses (un peu comme en EMT, on nous faisait faire des objets avec une utilité de vie courante, comme des classeurs ou des pochettes...).
Vous me répondrez sans doute que le but de l'enseignement n'est pas d'être attrayant, mais de former les esprits ; mais être attrayant permet parfois de mettre les esprits dans un état où ils sont susceptibles de recevoir la formation, de la même façon qu'un exposé vif rencontre plus de succès dans une conférence scientifique qu'un discours barbant et monocorde.
J'écoutais cet après-midi France culture dans le poste radio. On y causait Doisneau et Prévert. Et si on enseignit la photo aux élèves ? Ah non, parce que c'est sûr, on va les mettre à faire du photoshop ou consort, au lieu de les faire réfléchir à un sujet, à un cadrage, à la lumière, au contre-jour, à l'ouverture, au temps de pose.
Deux remarques brutes de décoffrages.
Je débat, personnellement, souvent sur le langage de programmation à utiliser dans un cours de programmation. Mais jamais sur le langage de programmation à enseigner. Enseigner la programmation est différent d'enseigner un langage. Le langage de programmation, dans un cours de programmation, sera un support par lequel on manipulera les concepts enseignés, et son choix est du coup important pour qu'il ne masque pas les concepts derrières les détails.
Après avoir joué quelques minutes avec, Scratch a l'air vraiment pas mal (en plus, je lis ici qu'il peut s'interfacer à Lego Mindstorm !). Néanmoins Logo restera, pour moi, le parangon du fun. Certes l'interaction est très simpliste, mais du coup, on ressent vraiment ce qu'on fait.
A ceux qui parlent de Logo: je pense que vous cherchez quelque chose comme Aseba : https://aseba.wikidot.com/
Peut s'enseigner à des enfants de huit ans, et permet de commander non seulement des robots simulés, mais aussi le robot physique.
Je renchéris sur Natacha pour le problème des messages d'erreur pas lus. Dans un monde où 95 % des messages non sollicités sont des agressions publicitaires ou des "make money fast", faut-il s'étonner que personne ne lise plus les messages non sollicités ?
Il y a un léger problème qui transparait dans votre article de blog. Vous pensez que l'apprentissage de l'informatique pourrait permettre d'entrainer les élèves à décomposer des problèmes en sous-problèmes, à leur apprendre une certaine rigueur, etc.
En somme, le fait de travailler une compétence dans un cours informatique permettrait de transférer les acquis dans d'autres matières, voire dans la vie de tout les jours.
Manque de chance, il y a un paquet d'études sur le transfert d'apprentissage qui montrent clairement que l'apprentissage de compétences générales (far transfert) n'est tout simplement pas possible ou alors anecdotique.
Et l'apprentissage de l'informatique ne fait pas exception : on a des études très claires (par exemple : Pea and Kurland 1984 - Salomon and Perkins 1987) qui nous disent qu'apprendre à programmer permet juste d'apprendre à programmer et n'a aucun effet dans des tâches éloignées de la programmation.
Et c'est encore pire pour ce qui de la capacité à décomposer des problèmes en sous-problèmes, qui n'est absolument pas entrainée par l'apprentissage de la programmation. Et cela s'explique facilement.
Contrairement à ce qu'on peut penser les novices ont naturellement tendance à découper les problèmes en sous-problèmes, quelque soit le domaine. Pire : c'est ce qui fait qu'ils ont du mal à trouver la solution : de découpage, nommé means-end analysis par les spécialistes en psychologie cognitive, a en effet tendance a saturer la mémoire de travail des novices.
En comparaison, les experts résolvent de nouveaux problèmes en reconnaissant des motifs présents dans chaque programme/énoncé/problèmes. Ces motifs permettent de résoudre des problèmes par analogie ou par accès direct à des informations en mémoire : cette méthode est nettement plus économe en mémoire de travail.
Pour la programmation, ces motifs peuvent être perceptifs, liés à la syntaxe, ou des catégories de problèmes. On pourrait citer l'exemple des design patterns, ou les rôles des variables. Le sujet est abordé dans l'article nommé " Expert programming kownledge : a schema based approach ", ainsi que dans l'étude nommée " A simulation of memory for computer programs ".
Et ces motifs sont aussi ce qui permet d'avoir de bonnes performance dans les tâches de debugging : si vous croyez que placer l'élève devant des programmes qui ne marchent pas lui ferait acquérir un esprit méthodique ou une capacité à surmonter ses idées pré-concues (courantes dans d'autres matière, en passant), vous faites fausse route.
Et évidemment, apprendre à programmer consiste à acquérir ces motifs, motifs qui ne sont pas réutilisables dans des situations qui ne sont pas liées à la programmation. C'est ce qui fait que celui qui apprend à programmer apprend juste à programmer, rien de plus.
Et ce mécanisme est valable quelque soit le domaine. Cela a d'ailleurs des implications pédagogiques générales, regroupées dans ce qu'on appelle la théorie de la charge cognitive, que je voit en détail dans mon article sur la pédagogie : https://zestedesavoir.com/tutoriels...
Comme quoi, il faut se méfier des évidences quand on parle de pédagogie. Et dire qu'apprendre la programmation sert à quelque chose a de bonnes chances de faire partie des idées pré-conçues et des évidences qui font plus de mal que de bien.
@Mewtow: Je ne connaissais pas ces études, merci pour les pointeurs. Si j'ai bien compris votre propos, les aptitudes intellectuelles acquises sur un type particulier de travail ou d'exercice se transposent pas ou peu à d'autres contextes.
Mais alors, comment justifier l'immense majorité des enseignements de toute discipline, censés non pas former directement à des tâches utiles, mais à « former l'esprit » ? Par exemple, certains prétendent (au vu d'études) que la lecture d'œuvres de fiction de haute qualité littéraire améliore nos capacités d'empathie et de compréhension des autres ; mais si ce qui est acquis dans un contexte ne s'applique pas à un autre, cela ne devrait pas avoir d'influence !
Je me permets de partager mon expérience. En école d'ingénieur, nous avons eu des cours d'algorithmique, en utilisant Java.
Je n'avais aucune idée de ce qu'était l'algorithmique à l'époque.
J'étais complètement incapable de faire le lien entre le cours théorique et l'application pratique qui était le codage. Donc je me suis retrouvé devant l'ordinateur en ayant l'impression de n'être aucunement formé à programmer.
De plus on m'a expliqué qu'il fallait recopier bêtement des lignes de type "public static void main string arg(){" (très approximatif, mes souvenirs commencent à dater). Et je pense que c'est à ce moment là que j'ai eu un blocage je crois, car j'ai eu l'impression de prendre le problème par le mauvais bout, de travailler sur des bases que je ne maîtrisais pas.
D'ailleurs pour l'anecdote, une blague circulait dans nos amphis et salle de TD "Java péter un câble", bref j'étais pas le seul à vraiment être doué
@Mewtow: je ne serais pas aussi catégorique que vous sur le non transfert des capacités cognitives. Le but de l'apprentissage est certes de créer des heuristiques et de créer des automatismes spécifiques. Cependant, cela se fait plus efficacement quand on adopte une démarche métacognitive, reconstruit les règles et surtout fait le lien entre ce qui est en train d'être appris et le savoir antérieur. Si l'on procède ainsi, on acquiert pas seulement une connaissance mais également des méthodologies transférables. Il me semble que Perkins et Salomon 89 relativisent un peu le biais anti-généraliste de S&P 87 que vous citez. Il me semble que le far transfer n'a pas lieu justement parce que les enseignants adoptent souvent des méthodologies qui ne le permettent pas. La programmation telle que la décrit David et surtout le fait qu'il insiste sur le déboggage me parait de nature à favoriser la métacognition et par conséquent la High road transfer dont parlent S&P.
Je comprends l'article de David comme disant en gros: " Si on enseigne vraiment la programmation (contra un ensemble de recettes pour programmer) alors ce sera utile parce que ça produira des élèves modestes, méthodiques et circonspects; toutes qualités qui sont utiles dans d'autres domaines." Ça ne casse certes pas trois pattes à un canard mais je crois que c'est vrai, non seulement pour la programmation mais également pour la quasi-totalité des disciplines. N'importe quoi, enseigné avec méthode à des jeunes, favorise le développement de leur esprit. Je ne crois pas que ça s'oppose à la littérature en psycho co. David et vous seriez d'accord pour dire que si on apprend en revanche aux élèves des recettes d'expert alors ça ne servira strictement à rien d'autre qu'à savoir faire une partie de ce que sait faire un expert. Mais justement, l'expert automatise tout ce qui est fastidieux pour pourvoir réfléchir de manière créative dès que ses heuristiques ne fonctionnent plus.
@sylvainj: Java n'est pas un bon langage d'initiation, exactement pour les raisons que vous dites (« incantations » du type
public static void main(String[] args)
, fonctionnement orienté objet dont l'utilité n'est pas forcément claire à qui n'a jamais programmé, mais mélangé à du procédural, etc.).On le choisit cependant parce qu'il est moins pénible que C et que d'autre part c'est un « vrai langage ». En effet, quand on donne des cours d'initiation à la programmation sur des langages « universitaires » (OCaml...) ou industriels mais peu répandus (Ada...), il y a toujours des étudiants (ou des cadres d'entreprise « débouchés ») qui se plaignent que les enseignants sont dépassés des réalités industrielles et font apprendre des langages « inutiles ».
@Hady ba: Oui, le gros problème d'une partie de l'enseignement secondaire, notamment en sciences, est qu'on apprend des séries d'« exercices types », qui suscitent des automatismes non transposables en dehors du cadre scolaire (ou, pire, des automatismes néfastes). Il faut dire que cela correspond à une demande croisée de nombreux étudiants (le « par cœur » donne des résultats prévisibles), de certains sociologues et pédagogues (le « par cœur » serait plus égalitaire), de certains enseignants (c'est plus facile à noter et moins sujet à réclamation) et de nombreuses familles d'élèves (qui vivent dans l'idée que ce qui est important est de recracher des leçons apprises).
Une anecdote : quand j'enseignais en DEUG MASS, j'avais fini par répondre à des étudiants qui me cassaient les pieds sur des points de détail de Java que ce n'était pas important (par exemple, quand on ne connaît pas la priorité respective de deux opérateurs, on met des parenthèses). Ils m'ont dénoncé auprès du responsable du module en m'accusant d'incompétence. Il faut dire qu'une partie des examens consistait à poser des questions de cours sans intérêt, par exemple sur la priorité des opérateurs...
C'est pour cela que la question du langage d'apprentissage et de l'environnement de développement est importante : il faut minimiser la quantité de détails techniques à connaître.
Sinon, je repose la question : si le far transfer est une illusion, alors ne faut-il pas supprimer une bonne partie des enseignements du secondaire ? À quoi cela sert-il, par exemple, de rédiger des dissertations ? Si cet exercice n'apporte aucune compétence (y compris compétence de pensée), pourquoi le maintenir ? Quid des mathématiques (en dehors de ce qui a une application immédiate au calcul des poids, surfaces et impôts) ?
"Sinon, je repose la question : si le far transfer est une illusion, alors ne faut-il pas supprimer une bonne partie des enseignements du secondaire ?"
Ben, c'est simple, il faut ne laisser que l'enseignement professionnalisant!
@sylvainj: Vous soulevez un point profond (la connexion de concepts théoriques avec la pratique). Quelques anecdotes :
C'est amusant cette histoire de "far transfer", parce que de ce qu'en ai compris, c'est une des principales composante de ce que j'ai vécu scolairement, et à peu près tout ce qu'il m'en reste aujourd'hui.
Je tombais d'ailleurs des nues quand j'ai constaté que mes condisciples cloisonnaient leurs connaissances et leurs compétences par matières, et j'ai eu des expériences sociales douloureuses quand j'ai essayé d'utiliser des cours dans un contexte non-scolaie (comme estimer l'angle solide sous lequel on voit l'écran de cinéma pour choisir sa place, ou utiliser des notions mécanique des fluides pour diagnostiquer la machine à café qui faisait des cafés trop courts dans certaines conditions).
J'ai probablment mal compris. Ou alors je suis une anomalie.
@Natacha: j'ai aussi entendu parler de l'inverse: des enfants qui savaient faire des calculs de prix/monnaie pour payer mais qui ne savaient pas faire à l'école des calculs semblables. Quelqu'un aurait des références sur ce sujet ?
@David Monniaux (24) : Pour les mathématiques, vous conviendrez qu'elles sont un prérequis à l'apprentissage d'autres sciences, donc qu'elles n'ont même pas besoin de se justifier par une formation de l'esprit transférable en dehors de son champ d'application. On a, du reste, supprimé les maths en filière L, on peut donc avoir son bac sans savoir 2 et 3 (avant aussi, vu le coefficient, mais bon..)
@ David Monniaux - message N° 19
Tenter de n'apprendre que des choses qui se révéleront utiles plus tard dans notre vie professionnelle ou personnelle pose un gros problème : comment savoir ce qui sera utile plus tard pour un élève ? C'est vraiment impossible et on est obligé d'apprendre des choses qui ont de bonnes chances de nous être inutiles (pour nous, mais pas pour tout le monde).
Après tout, un paquet de monde ne retirera aucune utilité de ses cours d'Anglais au collège, mais vu qu'on ne sait pas qui aura besoin de savoir parler ou écrire anglais, on préfère l'apprendre à tout le monde.
Pareil pour les mathématiques du lycée, qui ne serviront qu'aux métiers scientifiques ou techniques, et à quelques autres métiers.
Même à l'intérieur d'un domaine, on ne peut pas se limiter à n'apprendre que ce qui nous sera utile : cela demanderait d'individualiser les parcours au point qu'il faudrait faire des cours à la carte, sans compter que le marché du travail ne permettrait pas forcément ce genre de fantaisies.
Prenons mon cas d'étudiant en informatique qui souhaite travailler dans l'embarqué : les seuls cours qui ne seront réellement utiles sont les cours d'architecture des ordinateurs, sur les OS, de C, d'algorithmique. Inversement, quelqu'un qui veut faire du développement logiciel normal aura besoin de cours d'orienté objet, sur les bases de données, etc.
Et on doit surement trouver les mêmes choses dans les autres cursus, comme le cursus de géologie/biologie à la fac, ou les études de commerce.
On est obligé d'apprendre des choses inutiles. La seule solution que je vois pour tenter de limiter l'apprentissage de choses inutiles, c'est de spécialiser progressivement les cursus scolaires, et de créer des filières en regroupant des matières dont on peut mutualiser les cours ou qui ont des liens entre elles.
@ Messages 26; 27; et 28.
Les situations évoquées dans ces messages relèvent plus du transfert proche (near transfert), pas du transfert lointain (far transfert). Là où le transfert lointain se base sur d'hypothétiques compétences générales applicables dans un grand nombre de situations, le transfert proche consiste simplement à réutiliser des connaissances dans des problèmes analogues à des problèmes déjà vus (par analogie ou en reconnaissant des catégories de problèmes assez spécifiques à un domaine).
Dans les situations mentionnées (l'exemple de la table de hachage, ainsi que celui donné par Feynmann, ou encore avec les calculs de prix/scolaire), les élèves ont peuvent réutiliser directement des connaissances antérieures. Le problème est que l'élève n'arrive pas récupérer ces connaissances antérieure de sa mémoire à partir des informations fournies dan l'énoncé. C'est une simple question d'organisation des connaissances en mémoire, et c'est le signe que les élèves n'ont pas suffisamment créé de liens dans leur mémoire.
Au passage : si le transfert lointain a de très fortes chances de ne pas exister pour l’informatique, le transfert proche existe bel et bien. Il m'est déjà arrivé de voir des liens entre certaines connaissances en informatique et en électronique/télécommunications. On peut trouver des cas de transfert proche entre ces domaines, voire même des connaissances mutualisables entre ces domaines (traitement de signal, architecture des ordinateur, langage VHDL, une partie de l'algorithmique, etc).
Autant dire que si apprendre l'informatique a de bonnes chances d'être totalement inutile en primaire/collège/lycée, certaines filières gagneraient à avoir des cours d'informatiques : on pourrait même penser à fusionner les première années de certaines filières techniques pour profiter ce ces transferts proche (filières d'informatique, d’électronique, télécommunications, etc).
@Mewtow: Ce qui me chiffonne avec vos arguments, c'est qu'ils s'appliquent à bon nombre d'enseignements, y compris obligatoires.
L'immense majorité de ceux qui passent le baccalauréat n'analyseront pas de littérature ne rédigeront jamais de texte « littéraire » ; dans ce cas, quelles sont les « compétences transférables » de la dissertation ou du commentaire composé ?
Quant à l'histoire et à la géographie, est-ce que leur seul but est de faire apprendre des faits, ou est-ce qu'on essaye d'inculquer quelques notions plus larges et générales (par exemple : l'histoire aide à relativiser les certitudes locales).
le point de vue d'xkcd sur le sujet
Il y a bien un jeu de connaissances et de compétences qui est directement réutilisable par presque tout le monde : celles utiles au débat démocratique, « presque tout le monde » étant tous ceux qui ont une part audit pouvoir démocratique (donc ceux qui ont des droits civiques), raisonnablement approximable à « tout le monde » dans le système scolaire.
Par exemple, la seconde loi de la thermodynamique, pour prendre des décisions à la fois saines et démocratiques sur les questions énergétiques.
@DM Merci pour les éclairages sur Java. Finalement ça révèle peut-être que l'enseignement de l'algorithmique vient beaucoup trop tard : une fois en école d'ingénieur, le but est de nous rendre opérationnel pour l'Entreprise. Un enseignement plus tôt dans la formation pourrait probablement détacher de l'urgence d'être à tout prix opérationnel et de travailler sur les bases avec un langage plus adapté à la formation.
En effet les exemples que vous présentez sur le détachement formation théorique et pratique est effectivement pertinent. En y réfléchissant, il n'y a pas que dans ces TP que je me suis senti désemparé.
DM, vous croyez vraiment qu'on étudie les textes littéraires pour que les élèves éprouvent davantage d'"empathie" envers les autres ?^^
@Loys Bonod: Cette justification de la présence d'épreuves littéraires, type commenter la Princesse de Clèves, aux concours de l'administration est de Pierre Assouline.
On m'a également suggéré, dans les commentaires de ce blog, que des études montrent que ceux qui lisent beaucoup de vraie littérature avec des sentiments complexes font preuve de plus d'empathie dans les relations humaines.
Selon vous, qu'est-ce que l'élève est censé en retirer ?