À propos de didactique de l'informatique

Françoise Gaydier
 

Bien que ma thèse soutenue en 2011 « Simulation informatique d'expérience aléatoire et acquisition de notions de probabilité au lycée » relève de la didactique des mathématiques, j'ai du faire un passage obligé par quelques questions concernant la didactique de l'informatique. J'ai extrait de cette thèse quelques passages du chapitre 10 intitulé : « L'enseignement de l'algorithmique-programmation ».

   Il y avait dans les programmes de l'option informatique de l'enseignement général une part importante d'algorithmique-programmation ; le savoir-faire visé était : écrire un algorithme permettant la résolution d'un problème, le traduire dans un langage de programmation et faire exécuter ce programme par un ordinateur.

   Une telle tâche relève d'un type de tâche sur lequel il y eut des recherches didactiques pendant cette période, que nous appellerons dans la suite période de l'option informatique.

   Ces recherches ont eu une double particularité :

• elles ont été menées en même temps que se constituait la discipline informatique dans l'enseignement secondaire général ;

• elles associaient directement les enseignants de lycée engagés dans cet enseignement, enseignants qui n'étaient pas a priori « didacticiens », mais se trouvaient confrontés à divers problèmes didactiques pour lesquels personne n'avait encore d'expérience : l'enseignement universitaire était lui-même très jeune, et personne ne pouvait s'appuyer sur sa propre expérience d'élève.

   Les compétences en algorithmique-programmation étaient acquises à l'origine sur le terrain de l'entreprise, avant de devenir un objet d'enseignement universitaire, puis scolaire.
...

   Figurent dans les préambules des programmes de mathématiques depuis cette période, y compris les « programmes 2000 » une description des compétences que les élèves scientifiques doivent posséder, et mettre en oeuvre sans qu'il soit jamais précisé comment ils les acquièrent. Cette partie de la prescription est restée en grande partie lettre morte, entre autres raisons parce que la majorité des enseignants de mathématiques ne se sentait pas qualifiée pour assumer cet enseignement.

   Il apparaît que, les simulations informatiques d'expériences aléatoires dans l'enseignement secondaire relevant aussi de l'algorithmique-programmation, il est nécessaire de faire ici un détour sur des questions didactiques spécifiques à l'algorithmique-programmation.
...

   L'enseignement de l'informatique en tant que discipline à part entière s'est développé [dans la période de l'option informatique ici évoquée] très vite dans l'enseignement général, peut-être d'autant plus vite que les débouchés en terme d'emplois semblaient immenses : les élèves et leurs familles pensaient prendre une assurance sur l'avenir en choisissant cette option (qui fut dès l'année 1984 sanctionnée par une épreuve au baccalauréat au même titre que les autres enseignements optionnels).

   Cependant, les métiers de l'informatique ont évolué très vite, les « programmeurs » disparaissant au bénéfice des « analystes programmeurs » ; les langages de programmation ont évolué aussi,  exigeant très vite des « recyclages ».

   Cela a pu faire douter de l'existence d'un noyau de connaissances scientifiques stable attaché à l'informatique.
...

   Les programmes de cette option informatique comprenaient tout à la fois une partie d'étude du matériel, une partie d'algorithmique-programmation, et une partie « informatique et société » (la loi dite « informatique et libertés » a été votée en 1978).
...

   Un tel enseignement n'avait, bien sûr, aucune tradition dans l'enseignement secondaire, pas plus à dire vrai qu'à l'université : les départements d'informatique sont restés longtemps des appendices d'UER scientifiques, les enseignants venant d'horizons divers.
...

   La prescription de simulations informatiques d'expériences aléatoires dans les programmes de mathématiques de lycée des années 2000 puis 2010 doit donc être replacée dans ce contexte :

• à l'origine, utilisation des TICE par l'enseignant pour introduire ou soutenir l'enseignement de notions du programme de probabilité, l'enseignant étant l'acteur principal des simulations informatiques ; le programme de seconde évoque l'utilisation par l'élève de la touche « rand » de la calculatrice, tandis que le programme de terminale S évoque des simulations « extérieures » générant des résultats statistiques communiqués aux élèves pour traiter de l'adéquation de la loi équi-répartie aux données expérimentales ;

• puis, avec l'introduction d'une épreuve pratique (expérimentale) de mathématiques au baccalauréat scientifique, création par les élèves de simulations sur tableur, le tableur étant supposé exiger peu de connaissances en algorithmique programmation.

• Et enfin création par les élèves de simulations d'expériences aléatoires dans un langage impératif : les élèves sont initiés dès la seconde à l'algorithmique-programmation

   Ni les documents d'accompagnement des programmes des années 2000, ni les documents d'accompagnement du programme de seconde de la rentrée 2009, ni les programmes (2000 ou 2010) n'évoquent d'éventuels problèmes didactiques concernant ce type d'activité.

   Nous limiterons notre propos à certains aspects qui « risquent » d'apparaître lorsqu'on met des élèves en situation de créer des simulations informatiques d'expériences aléatoires.

   Nous nous centrerons sur la difficulté à construire un algorithme, et particulièrement un algorithme comportant une itération, en nous appuyant sur deux contributions au « Colloque francophone sur la didactique de l'informatique » qui s'est tenu à Paris en 1988 : contribution de Jacques Arsac, professeur d'informatique à l'université, et de Janine Rogalski, chercheur en didactique.

« La didactique de l'informatique : un problème ouvert ? »

   C'est le titre de la contribution d'Arsac (1988) à ce colloque, qui énonçait :
« Dès le début des années 60, les professeurs qui enseignaient les ordinateurs, leur structure et leur architecture, leur programmation, leurs applications dans les domaines numériques et non numériques prirent conscience qu'une science nouvelle était en gestation (computer science aux USA, datalogie en Scandinavie, informatique en France) et que cela posait de sérieux problèmes d'enseignement. Quels étaient les contours de cette science ? Que fallait-il enseigner ? À qui ? Avec quels prérequis ? »

   Arsac décrit brièvement la constitution de la science informatique : à la fin des années 1960, « la programmation était un empirisme », ou, selon Knuth (1968), un art.

   L'empirisme ici consiste pour le programmeur à construire son programme de façon essentiellement intuitive et personnelle, en comptant sur l'exécution d'un certain nombre de jeux de données où le programme fonctionnera correctement (c'est à dire fournira les résultats attendus pour ces données), pour se convaincre que le programme est juste, c'est à dire fait bien ce pour quoi il a été commandé.

   Les défauts des logiciels construits par empirisme sont rapidement devenus socialement trop coûteux : ces logiciels étaient non fiables et non modifiables entre autres défauts.

   Des chercheurs avaient posé la question des preuves de programme. D'autres (ou les mêmes) essayent de dégager des méthodes scientifiques de programmation : Programmation descendante par Naur (1969) et Programmation structurée par Dijkstra (1972).

   Arsac poursuit :
« À la suite de ces travaux de recherche, la programmation changea de nature. Elle approcha du statut de discipline scientifique (A discipline of programming, Dijkstra, 1976), puis fut reconnue comme science (The science of programming, Gries, 1981). Ces méthodes scientifiques changèrent la façon de programmer, et l'on vit apparaître la « méthodologie de la programmation » comme champ de recherche, avec des méthodes de programmation comme résultat concret. Les premières naquirent dans le cadre relativement restreint de l'informatique de gestion (Warnier, 1973 ; Jackson, 1975). Des méthodes de portée plus générale, et partant moins précises dans leurs détails, furent proposées pour aider à la création de nouveaux algorithmes (Dijkstra, 1976 ; Arsac, 1980 ; Gries, 1981 ; Ducrin, 1984). Tout ceci ne pouvait manquer d'avoir un impact sur l'enseignement. »
...

   Faut-il, demande Arsac en 1989, former les élèves ?

« L'élève doit-il savoir quelque chose de l'ordinateur et de la façon dont on lui fait réaliser une tâche, ou peut-on considérer matériel et logiciel comme une boîte noire ? Quelle compétence est demandée au professeur ? Doit-il être un expert en traitement de texte, tableur ou gérant de bases de données ? Doit-il savoir de l'informatique ? Doit-il être compétent en programmation ? »

   On pouvait encore en 1989 se demander si les connaissances informatiques seraient stables dans le temps ; l'histoire de l'informatique avait été tellement vite :

• augmentation de la capacité de la mémoire utilisable dans l'unité centrale,

• augmentation de la  capacité de la mémoire de masse,

• multiplicité (et en même temps standardisation) des supports de la mémoire de masse,

• augmentation de la  vitesse de calcul,

• et surtout développement de langages de programmation de plus en plus ouverts, vers une programmation de plus en plus près de la pensée du programmeur (et partant plus éloignée du langage machine), c'est à dire de plus en plus proche de l'algorithme tel que le programmeur le conçoit pour résoudre un problème selon un cahier des charges donné, avec divers styles de programmation, selon le type de problème à résoudre, ou l'outil de programmation à disposition.

   Il apparaissait que, quelle que soit l'évolution de l'informatique, une formation de base et de masse était nécessaire, pour que les usagers de l'ordinateur soient des usagers éclairés.

   Citons encore Arsac :
« Tout ceci pose de manière grave le problème du contenu des enseignements d'informatique pour tout public autre que les futurs professionnels de cette discipline (en admettant que pour eux la question soit résolue, ce qui paraît tout de même une hypothèse raisonnable). Faut-il apprendre aux gens le maniement d'outils dont on connaît la rapide obsolescence ? Peut-on estimer que des fonctions essentielles ont été mises en évidence qui perdureront dans les futurs produits, et qu'à travers les réalisations actuelles, ce sont elles que l'on enseigne ? Est-ce bien cela qui est actuellement pratiqué ? Faut-il au contraire renoncer à l'idée de boîte noire, jusqu'où faut-il aller ? Quelle quantité de programmation est nécessaire pour comprendre ce que peuvent, et peut-être ne peuvent pas les ordinateurs ? »

   Voilà clairement posée la question de la transposition didactique des connaissances d'une discipline scientifique toute neuve, et qui évolue à une vitesse inédite pour les disciplines enseignées jusque là.

   Concernant la programmation, Arsac écrit en 1988 :
« Il semble à peu près compris que programmer n'est pas résoudre un problème, c'est le faire résoudre par une machine. Les élèves ou les étudiants savent résoudre la plupart des problèmes qu'ils auront à programmer, qu'il s'agisse de trouver quel jour de la semaine tombe un jour donné, ou d'écrire en lettres un montant donné en chiffres, ou de trier une suite de nombres. Or pour faire faire un travail par un exécutant qui n'a pas été construit de façon spécifique pour ce travail là (les ordinateurs sont des machines universelles à traiter l'information), il faut fournir une méthode à cet exécutant. On est donc confronté au problème suivant : formuler la méthode de résolution d'un problème que nous savons résoudre.

Certains pensent que la difficulté est dans la formalisation de la méthode : nous savons faire, mais nous savons mal dire comment nous faisons. On essaie alors d'expliciter notre propre façon de faire. On manifeste l'enchaînement de nos actions au moyen d'un organigramme, puis on code le résultat dans un langage de programmation : l'analyse informatique part d'une analyse du vécu. Il y a des cas où c'est efficace (...)

De nombreux ouvrages sont fondés sur cette démarche pédagogique. »

   Arsac explique qu'en réalité, on ne programme pas la résolution d'un problème donné  à partir d'une explicitation des procédures que l'acteur humain met en oeuvre pour résoudre le problème « à la main », procédures qu'il suffirait de transcrire dans un langage exécutable par la machine. Il illustre cette affirmation avec les programmes de tris : la résolution d'un problème de tri « à la main » se fait par un assemblage plus ou moins désordonné de procédures de tris locaux, que l'acteur adapte au fur et à mesure de l'avancement de la tâche. Arsac conclut sur ce point :
« Pourquoi opéreraient-ils de façon systématique ? Il suffit qu'ils réussissent...

   En réalité, on a une méthode d'enseignement qui part du programme à écrire, puis le paraphrase en français courant en disant que c'est comme cela que nous faisons. C'est une duperie inacceptable.
...

   L'enseignement de la programmation se heurte à cette difficulté fondamentale : comment fabriquer une méthode pour résoudre un problème ? On appelle cela « l'algorithmique ». Le terme me paraît abusif : l'algorithmique est l'étude des algorithmes, de ce qu'ils permettent de calculer, de la façon dont on peut les composer, les prouver, mesurer leur complexité... Ce n'est pas cela qui est en cause, c'est bien moins ambitieux : seulement trouver, face à un problème donné, une méthode qui en viendra à bout. Il faut développer la créativité des élèves ou des étudiants.

   Il n'y a pas de réponse universelle. Il n'y a pas un algorithme pour la fabrication d'algorithmes. Il y a des façons de faire. Il y a des méthodes de raisonnement plus adaptées que d'autres : la programmation impérative aussi bien que la programmation récursive se fondent sur le raisonnement par récurrence. Il est important de le savoir, parce que cela fournit un cadre intellectuel. Mais la difficulté demeure : comment trouve-t-on une hypothèse de récurrence qui deviendra le coeur de la procédure récursive, ou l'invariant de boucle pour un programme impératif. »

Françoise Gaydier
docteur en sciences de l'éducation
professeure de l'option informatique (1981-1991)
professeure de mathématiques

Cet article est sous licence Creative Commons (selon la juridiction française = Paternité - Pas d'utilisation commercial - Pas de Modification).
http://creativecommons.org/licenses/by-nc-nd/2.0/fr/

Bibliographie

Arsac J. (1977). La construction de programmes structurés, Dunod, Paris.

Arsac J. (1980). Premières leçons de programmation, Cedic- Nathan, Paris.

Arsac J. (1987). Des pédagogies pour l'option informatique, Pratiques et savoir-faire des élèves de l'option informatique, 4, p. 1-13.

Arsac J. (1989). La didactique de l'informatique : un problème ouvert ? Contribution au Colloque francophone sur la didactique de l'informatique (1988). Actes publiés par l'EPI.
http://epi.asso.fr/revue/dossiers/d07p009.htm

Dijkstra E. W., Dahl O. J., Moare C. A. R. (1972). Structured programming, Academic Press, London.

Dijkstra E. W. (1976). A discipline of programming, Prentice Hall.

Ducrin A. (1984). Programmation, Paris, Dunod.

Gries D. (1981). The science of programming, Springer Verlag. Berlin.

Jackson M. A. (1975). Principles of program design, Academic Press, Londres.

Knuth D. (1968). The art of computer programming, vol 1, Addison Wesley, 1968.

Naur P. (1969). Programming by action clusters, BIT 9, 3, p. 250-258.

Warnier J. D. (1973). Les procédures de traitement et leurs données, Éditions d'organisation, Paris.