Synthèse d'un colloque en trois temps

ou

La valse est un art difficile

Charles Duchateau
 

Synthèse par C. Duchateau du deuxième colloque francophone sur la didactique de l'informatique, les 30, 31 août et 1^er septembre 1990 à Namur.

Avertissement

   Tenter de restituer en une synthèse la diversité des questions, des expériences et des points de vue et entreprendre de concentrer la richesse de nos échanges est, on le devine, une tâche bien difficile. Il ne faut donc pas chercher dans cette synthèse un quelconque « résumé » de l'ensemble des communications présentées ni même un survol plus ou moins exhaustif des thèmes abordés. Il s'agit plutôt d'un regard subjectif et singulier sur divers apports, d'un « picorage » des idées qui m'ont le plus séduit doublé d'une tentative d'organisation « digeste » de ces réflexions. Je n'échapperai sans doute pas à la tentation d'épingler avant tout les approches qui éveillent le plus d'échos dans mes propres préoccupations ou avec lesquelles je me sens davantage « en résonance ».

   Il fallait cependant faire un choix pour la présentation de cette synthèse : mes premières constatations discernaient trois lieux essentiels d'où émanaient les discours constituant ce colloque et donc trois éclairages de la problématique de la didactique de l'informatique ; il me semblait, de plus, qu'au-delà des divergences et des disparités, trois traits essentiels coloraient et marquaient les diverses approches, constituant en quelque sorte la trame de nos échanges. Il n'en fallait pas plus pour que j'organise arbitrairement cette tentative de synthèse sur un rythme ternaire. Comme en outre un examen plus minutieux (ou davantage subjectif) semblait à chaque fois discerner un pôle prépondérant à côté de deux autres plus menus, l'analogie avec le temps fort et les deux temps faibles de la valse s'imposait d'elle-même. Et puis, si la rigueur et le sérieux de nos échanges et de nos propos n'avaient pas toujours la grâce et la légèreté d'une valse, le tempo soutenu auquel se sont déroulées ces trois (encore !) journées mérite bien une référence rythmique et cadencée... [1].

1. Les trois familles de participants et les trois pôles essentiels

   Trois préoccupations dominantes ont marqué les thèmes abordés, reflétant les trois lieux d'où venaient à la fois les auteurs des contributions et les participants.

1.1. Les enseignants de premier cycle de sections comportant une formation forte à l'informatique

   On devine que les universitaires étaient plus que largement représentés en ce qui concerne les communications : la tradition académique a parfaitement intégré ce mode d'expression et le colloque se voulait d'ailleurs explicitement une tribune où puissent être présentés et débattus les résultats de recherches et d'expériences relatives à l'enseignement de l'informatique. Le premier groupe à marquer de son empreinte les thèmes du colloque était donc constitué des universitaires chargés d'un enseignement important de l'informatique dans le cadre de la formation des futurs professionnels (de l'informatique) ou, à tout le moins, responsables de cours à destination d'étudiants recevant une formation forte en informatique : ingénieurs, mathématiciens, physiciens... La plupart s'interrogent d'ailleurs surtout sur l'enseignement dispensé aux étudiants de premier cycle, ceux pour lesquels, sans doute, les problèmes d'apprentissage posent le plus de questions et nécessitent le plus d'imagination et de recherche de la part des enseignants. S'il fallait caricaturer en une phrase les préoccupations sous-jacentes à ce premier groupe, ce pourrait être : « Que faire apprendre aux étudiants débutants et comment l'enseigner ? » Les contraintes imposées par le « terrain » (motivation des étudiants, statut de la formation à l'informatique dans le curriculum global...) cèdent le pas à des interrogations qui trouvent leur point de départ dans l'informatique elle-même ou, en tout cas, dans la perception qu'ont de leur discipline, les informaticiens qui l'enseignent.

1.2. Les enseignants du secondaire ; les formateurs de publics « exotiques »

   II s'agit ici d'un second groupe de participants, presque aussi nombreux que le premier mais beaucoup moins représenté au niveau des communications proposées. Il est vrai que les contraintes formelles imposées pour l'écriture d'une communication « classique » sont souvent étrangères au patrimoine « culturel » des professeurs du secondaire. De plus, mon expérience personnelle me l'a maintes fois prouvé, ces enseignants ne sont pas toujours conscients de la valeur de leurs analyses et de leurs démarches ; ils hésitent trop souvent à partager le fruit de leurs expériences et de leurs réflexions. J'ai joint à ce groupe tous les enseignants responsables de formations à l'informatique à destination d'étudiants pour lesquelles cette formation est accessoire ou, du moins, ne constitue pas l'essentiel des préoccupations. Tous ces formateurs ont en commun le fait que les problèmes émanant du terrain prennent ici fréquemment le pas sur des interrogations qui plongeraient leurs racines dans la discipline informatique elle-même : besoins, intérêts et motivations du public concerné par ces formations, caractère optionnel de l'enseignement de l'informatique, statut et formation des enseignants,... Dans le meilleur des cas, la préoccupation est alors « Comment former à travers l'informatique ? » mais parfois simplement « Que faire face aux motivations et attentes diverses de mes élèves, sans trahir ce que je crois devoir être un enseignement convenable de l'informatique ? ». La forme « colloque » n'est peut-être pas idéale pour permettre cette expression des questions et malaises de ce second groupe de participants.

1.3. Les chercheurs en psychologie de l'apprentissage

   Cette troisième composante était la plus menue (en nombre). Elle apporte au colloque l'éclairage de spécialistes qui, à travers des expérimentations contrôlées, éprouvent et interrogent les concepts et méthodes de l'informatique, du point de vue de leur apprentissage. Si, en caricaturant, les préoccupations du groupe des enseignants universitaires était « Comment pouvons nous enseigner l'informatique ? », la question centrale est ici « Comment les étudiants apprennent-ils l'informatique ? ».

   Fort heureusement, si chacune des composantes apporte son éclairage spécifique à la didactique de l'informatique, leur réunion, avec les échanges et les débats qu'elle provoque est source de richesse et de progrès.

2. Trois traits importants

2.1. Un redoutable effet « entonnoir »

   À côté de questions relatives à l'enseignement de la programmation, l'appel aux communications préparant le colloque, tentait d'ouvrir le champ des préoccupations à d'autres thèmes : « Quelle doit être la place de la familiarisation aux outils logiciels dans la formation globale à l'informatique ? Comment et en quoi leur découverte et leur maîtrise contribuent-elles à l'apprentissage des concepts et modes de pensée de l'informatique ? », ou encore « Peut-on poser quelques jalons d'une épistémologie de l'informatique ? Lesquels ? En quoi peuvent-ils intéresser l'enseignant et influencer son discours ? », et enfin « Quels sont les enjeux culturels liés à l'informatique ? Comment l'enseignement de l'informatique peut-il les prendre en compte ? ».

   La prépondérance des participants du « premier groupe » a, me semble-t-il, transformé la problématique générale de l'enseignement de l'informatique en une affaire, fort importante au demeurant mais plus restreinte, celle de l'enseignement de la programmation. Ainsi, le colloque, laissant dans l'ombre les problèmes d'apprentissage d'autres constituants de l'informatique, réduit la « didactique de l'informatique » à une série de questions sur l'enseignement de l'algorithmique et/ou de la programmation [2] :

• Quelle programmation enseigner au début de la formation des ingénieurs ou des informaticiens ?

• Peut-on enseigner des styles de programmation non classiques ?

• Programmation est-elle synonyme d'algorithmique ?

• Des outils pour faire apprendre la programmation ?

   Cet intérêt marqué pour la programmation fait l'impasse, par exemple, sur les problèmes d'initiation aux outils logiciels, sur la démystification de l'ordinateur [3], sur la définition des éléments de base constitutifs d'une culture informatique.

   On comprend aisément qu'il soit difficile ou inadéquat de faire une place explicite à l'apprentissage des outils logiciels dans la formation universitaire des futurs professionnels. On voit mal un « cours de 30 heures sur MS-Works », puisque la maîtrise de ces progiciels est avant tout « une question de pratique » [4]. De même, on conçoit sans peine que l'enseignant universitaire axe la formation sur l'algorithmique, renvoyant à un effort personnel mais accessoire la maîtrise effective et pratique de Pascal dans telle implémentation.

   Mais, par ailleurs, l'opportunité d'une formation « inutile » à l'algorithmique dans le secondaire est de plus en plus souvent battue en brèche face à l'irruption des outils logiciels. La découverte de ces derniers semble à la fois plus accessible à la majorité des élèves et sensiblement plus « utile » ou « utilisable ». La tendance actuelle est nettement de négliger l'apprentissage de l'algorithmique pour faire une large place aux divers progiciels.

   Alors que mon discours habituel à destination des enseignants du secondaire est, dès lors, un plaidoyer pour que l'on garde une place suffisante à la programmation, je me trouve ici dans la position inconfortable et inhabituelle d'insister auprès des enseignants universitaires et des chercheurs en psychologie de l'apprentissage sur la nécessité d'une réflexion importante sur l'enseignement des outils logiciels et la définition des éléments de base d'une « culture informatique ». Personne ne niera que l'apparition de l'ordinateur personnel et de la masse des logiciels qui l'accompagne s'est doublée de la naissance d'un concept nouveau, celui d'utilisateur. Si demain chacun devient utilisateur d'outils informatiques, il est impératif de s'interroger sur les processus cognitifs sollicités par la maîtrise de ces outils et par les modalités à mettre en œuvre pour leur apprentissage.

   Peut-être n'est-ce pas une tâche pour les informaticiens que de baliser des pistes qui permettront à d'autres de s'approprier les outils ou de s'interroger sur ce que chacun devrait connaître de l'informatique ? Je voudrais cependant apporter deux réflexions personnelles qui plaident pour une prise en compte de ces problèmes et qui soulignent la difficulté de l'entreprise.

1. L'ordinateur n'existe pas, ou, pour être plus précis et moins provocateur, le concept d'ordinateur est inadéquat lorsqu'il s'agit de familiariser les futurs utilisateurs lors des premiers contacts avec la machine. Combien de fois n'ai-je pas entendu la demande « apprenez-moi les manipulations « de base » de l'ordinateur ». Nous savons malheureusement que l'existant c'est toujours le tandem ordinateur-logiciel et qu'il y a, pour l'utilisateur, autant d'univers à explorer que de logiciels à maîtriser. Il est difficile de mettre au jour des règles générales qui gouvernent ces univers : certains sont à connotation « spatiale » comme les éditeurs de texte (l'écran est un espace dans lequel on peut se déplacer pour agir) ; d'autres, comme le système d'exploitation MS-DOS par exemple, sont à connotation « temporelle » (l'écran retrace l'histoire de mes échanges avec l'ordinateur : il n'y a pas de sens à vouloir agir sur des phrases précédant le curseur, c'est du passé). Qui dira la perplexité provoquée chez les utilisateurs novices par les messages sibyllins et mystérieux dont est parfois ponctué le « dialogue » avec l'ordinateur. La « culture (micro)-informatique » se développait autrefois autour des machines et de leurs particularités, elle se fait aujourd'hui autour des outils logiciels. Il est impératif de s'interroger sur les éléments qui la constituent.

2. L'utilisation des outils logiciels est formative. Elle s'inscrit dans une démarche générale de résolution de problème pour laquelle le schéma suivant, emprunté à Jacques Arsac, est bien entendu de mise.

   La difficulté d'utilisation des outils logiciels est liée au passage entre les actions complexes qu'on souhaite effectuer et l'enchaînement des commandes à donner pour réaliser ces actions. Maîtriser un outil logiciel, c'est avoir perçu les tâches qu'il rend possibles et avoir acquis les tours de main sous-jacents à l'effectuation de chacune de ces tâches. Ce n'est donc bien évidemment pas la connaissance des commandes relatives à l'outil qui est formative mais l'identification des problèmes traitables et la mise en œuvre de la suite des commandes nécessaires à ce traitement.

   Chaque « tour de main » constitue en fait un petit « algorithme » mental dont l'utilisateur devient « l'exécutant ». C'est l'acquisition de ces habiletés qui est centrale. Nul doute qu'un relevé de celles-ci facilite l'apprentissage des outils concernés et... sollicite l'attention des informaticiens chargés de la formation des utilisateurs et soucieux de didactique.

2.2. Beaucoup de clés et de serrures, mais la même porte

   Un deuxième trait essentiel est lié aux objectifs avoués d'un enseignement de l'informatique (ou plus souvent de l'algorithmique et de la programmation). Que l'on veuille faire apprendre la bonne vieille programmation impérative, la programmation logique, la programmation fonctionnelle ou autre programmation « orientée objet », c'est, non dans un but utilitaire, mais pour leurs apports, jugés essentiels, à la formation générale des étudiants. Les mots liés à ces apprentissages sont « formation », « modéliser », « abstraire », « résolution de problèmes »...

   Ainsi, clairement, si les clés choisies sont diverses, la serrure que l'on veut forcer et la porte que l'on souhaite ébranler est celle de la formation. On ne fait pas de la programmation parce que c'est utile ou pour une série d'alibis techniques mais tout simplement parce que l'on estime que c'est formateur. II me semble essentiel que cela soit dit et redit, à l'heure où certains veulent chasser ce type d'apprentissages de la formation des élèves du secondaire.

2.3. Au cœur de l'informatique : la réflexion didactique

   II est un troisième trait, important, qu'il faut souligner. C'est l'existence même de réunions comme celle-ci. Que près de 250 personnes se soient, à deux reprises déjà, retrouvées pour échanger et réfléchir à propos de leurs pratiques d'enseignement de l'informatique pourrait étonner. Je crois qu'en réalité la réflexion méthodologique fait partie de l'informatique elle-même, discipline de la méthode par excellence. Et je crois, qu'en partie du moins, une épistémologie de l'informatique (qui reste à développer) plongera ses racines dans le terreau de ce que nous enseignons de l'informatique.

   J'avais, lors de la séance d'ouverture, rappelé la réflexion de Tursky : « Sometimes I think we are performing a cruel experiment by teaching informatics now. Unfortunately these experiments on human beeings are necessary for our research ; informatics is the kind of science that can progress only by its beeing thaugth » [6].

   Elle souligne, me semble-t-il, la pertinence d'une réunion comme ce colloque et engage à beaucoup de tolérance et de modestie les enseignants partisans d'approches diverses (« traditionnelles » [7] ou « nouvelles »). Nul ne détient la vérité en matière de pédagogie, d'enseignement et d'apprentissage : l'informatique n'échappe pas à cette règle.

3. Trois questions

   Un triplet de questions, de natures fort différentes, émerge des communications et des échanges que celles-ci ont provoqués. Et d'abord,

3.1. Quel est le statut de l'informatique ?

   Il me plaît que cette préoccupation ressorte d'un colloque comme celui-ci. Elle montre que les recherches didactiques ne peuvent faire l'économie de questions d'épistémologie et que pour bien enseigner, il faut être au clair avec la nature profonde de ce que l'on veut faire partager. II faudra sans doute bien du temps encore pour que soient posés les premiers jalons d'une épistémologie de l'informatique, mais ces réflexions sont indispensables, ne serait-ce que pour répondre aussi clairement que possible à la question « pourquoi enseigner l'informatique ? ».

   Sans apporter de réponse aux problèmes de statut de l'informatique, le colloque a, me semble-t-il, mis en lumière que l'informatique est une « discipline » [8] sans beaucoup de concepts ou de contenu propre mais bien davantage une « science » de la méthode.

   L'informatique serait-elle, après les mathématiques, la nouvelle servante des autres sciences ? Quiconque a enseigné la programmation sait fort bien que les concepts utilisés sont fort simples et peu nombreux. Il est possible de présenter très familièrement la notion de variable, les structures itératives ou l'appel de procédure et cela sans noyer le poisson dans un charabia technique qui ferait croire que la programmation est complexe parce que l'ordinateur est compliqué (c'est pour la raison exactement opposée : c'est parce que les possibilités « natives » de l'ordinateur sont ridicules que la moindre tâche devient un problème). Mais, la mise en œuvre de ces concepts élémentaires, voire enfantins, est, elle, loin d'être un jeu d'enfant. Et c'est cette incarnation des concepts dans une démarche qui fait le cœur de la méthode. C'est cela qu'il faut faire apprendre et c'est bien parce qu'il s'agit, en partie du moins, de « savoir faire » ou « d'habileté » que, comme la poterie ou la médecine, la pratique de la programmation restera sans doute un long apprivoisement.

3.2. Quel(s) style(s) de programmation enseigner à des débutants ?

   Voilà assurément la question qui a le plus agité (au sens figuré comme au sens propre) nos débats.

   La programmation impérative (ou procédurale) telle qu'elle s'est constituée grâce aux apports de personnalités comme Dijkstra, Arsac, Hoare, Wirth, Gries, Pair et beaucoup d'autres, bénéficie évidemment de la plus longue expérience d'enseignement. C'est aussi celle qui s'incarne dans le plus grand nombre de langages : Pascal, LSE, Fortran, Cobol, Basic... Qu'elle s'attache aux traitements (J. Arsac) ou davantage aux objets manipulés (J. Fleck), qu'elle mette en avant les structures itératives ou la pensée récursive, qu'elle se présente de manière peu formalisée ou se fonde sur le concept de preuve (P.de Marneffe, G. Languy), elle a peu à peu affiné les modalités de son enseignement et cerné les difficultés de son apprentissage.

   Face à cette tradition, se dressent des approches moins habituelles comme celle à la « Abelson/Sussman », incarnées dans des langages comme Lisp ou Scheme. Ce sont celles qui se réclament plutôt du paradigme fonctionnel et dont l'enseignement a été abordé dans le cadre du colloque par J. Haguel, L. Gacogne ou M. Briand et A. Pic.

   Je pense que la programmation impérative traditionnelle (celle des « marches à suivre ») a encore de beaux jours devant elle et que nous n'avons pas fini de faire le tour des problèmes proprement didactiques qu'elle nous pose. Mais je ne partage pas les réactions prudentes ou indignées qu'éveille chez certains adeptes du procédural, l'exploration des voies moins fréquentées du « fonctionnel ». C'est le moment de rappeler l'avertissement de Tursky qui nous rappelle que, quels que soient nos choix d'enseignant, ce sont des « êtres humains » que nous soumettons à nos « expérimentations ». Cela doit bien entendu inciter à la prudence, mais ce n'est pas parce qu'une pratique est le fait du plus grand nombre ou exercée depuis plus longtemps qu'elle acquiert automatiquement l'exclusivité des préoccupations ou le brevet d'excellence.

   Je crois cependant que, comme souvent, ces approches nouvelles ont plus à craindre de l'enthousiasme forcené ou béat de leurs défenseurs que des attaques, fondées ou non, de leurs détracteurs. Je voudrais donc attirer l'attention des adeptes de ces styles nouveaux de programmation sur deux questions importantes :

1. Très fréquemment, ces approches alternatives sont présentées par leurs prosélytes comme des panacées. Les étudiants y apprendraient mieux, plus facilement et avec plaisir des choses plus difficiles. La crédibilité de ces styles différents est intimement liée à une évaluation des résultats des enseignements qui les adoptent et au relevé, là comme ailleurs, des difficultés qui leur sont spécifiques. Une liste des écueils rencontrés, des points délicats, ferait sans doute plus pour la reconnaissance de ces pratiques d'enseignement que les discours triomphalistes destinés à y faire adhérer de nouveaux partisans.

2. Si l'on admet qu'au fond, programmer, c'est faire faire en différé et si l'on partage le point de vue que, quelle que soit la forme prise par les « programmes » qui exprimeront ce faire faire, on sera de quelque manière contraint par les possibilités de l'automate chargé, in fine, de les exécuter, n'y a-t-il pas une difficulté à ce que le mode d'expression adopté soit aussi éloigné des caractéristiques de cet exécutant ? Autrement dit, l'expression « fonctionnelle », en agrandissant démesurément le fossé entre ce qui est exprimé et ce qui se déroulera à l'exécution, ne rend-il pas plus malaisé la perception de la manière dont l'exécution est liée à la forme du programme ? Ou encore, n'est-il pas plus difficile d'imaginer l'exécution d'un programme « Scheme » que d'un programme « Pascal » ? Ceci n'est pas un plaidoyer pour un retour à l'Assembleur, mais une question sur des métaphores nouvelles à installer éventuellement pour faire percevoir la portée et les effets d'un mode d'expression qui dissimule à ce point l'aspect « marche à suivre » des programmes élaborés.

   L'un des problèmes fondamentaux est évidemment de savoir s'il faut soumettre les étudiants successivement ou conjointement à ces styles différents.

   Et enfin, quel que soit le style de programmation adopté, se pose le problème de concilier vision « académique » et réalité professionnelle. Les principes méthodologiques prônés par nos enseignements sont-ils « respectés » par les praticiens de la programmation ou jetés comme de vieilles défroques inadaptées et gênantes.

3.3. Comment, ayant choisi un style de programmation, amener les étudiants à la compétence souhaitée ?

   Les préoccupations sont ici davantage méthodologiques et centrées sur les manières d'organiser enseignement et apprentissage. Les expériences sont nombreuses, diversifiées, parfois contradictoires ; elles reflètent en tout cas pratiques quotidiennes et « savoir faire » des enseignants d'informatique.

L'organisation des apprentissages

   Si certains, comme G. Clavel ou J. Haguel, estiment que la programmation peut, partiellement du moins, s'apprendre « en lisant et comprenant des programmes bien faits » [9] (d'autres, comme P. de Marneffe, nous rappellent cependant que « l'algorithmique doit être créative ». On comprend aisément que les deux approches ne s'opposent nullement et qu'on peut à la fois être adepte de la dissertation française et de la lecture des bons auteurs.

   D'aucuns, comme M. Arcouet, prônent la voie du « développement de projet » avec la liberté de choix et de cheminement qui y est attachée ; d'autres comme J. Haguel, recommandent une « chaîne de travaux conçus pour amener les notions de base dans l'ordre voulu ».

   En tout cas, l'importance des travaux pratiques, qu'ils prennent la forme de travaux dirigés ou de projets personnels, fait l'unanimité.

Le statut de l'erreur

   La programmation (et son enseignement) a été une longue lutte pour s'affranchir des mises au point par essais et erreurs. L'idéal, c'est évidemment de concevoir et de rédiger des programmes corrects. Quel statut faut il réserver à l'erreur : faute ou tremplin ?

   Je dois avouer que c'est l'une des questions essentielles que me posent des approches comme celles de Logo, où l'erreur est érigée en principe et où la construction du savoir s'appuie sur les maladresses et les bévues.

   La question centrale est donc bien ici : peut-on apprendre en se trompant à programmer sans se tromper ?

Descendante ou ascendante ?

   Une autre problématique abordée est celle de l'approche à promouvoir lors de l'apprentissage de la programmation :

   Personnellement, j'en retiendrai en tout cas la méthodologie proposée par G.Clavel où les spécifications sont peu à peu enrichies ou élargies, chaque nouveau programme s'appuyant sur le précédent et le généralisant tout en l'intégrant.

4. Les trois cœurs de l'informatique

   J'ai souligné plus haut combien le statut de l'informatique est au cœur des problèmes de son enseignement. Après avoir tenté de rendre compte de la richesse de nos débats et de nos échanges, on me permettra, pour finir, d'apporter, non mes réponses à cette question centrale, mais mon éclairage personnel sur ce qu'est, aujourd'hui, le « noyau dur » de l'informatique.

   Sans avoir la prétention d'être complet, il me semble discerner trois traits essentiels qui sont, me semble-t-il, au cœur de l'informatique, ou à tout le moins de la « programmation » :

• Faire de l'informatique, c'est tenter sans cesse d'enfermer le « sens » dans la « forme », c'est réduire dans une quête incessante la part de l'inexprimé ou de l'implicite dans nos actes et nos traitements.

• Faire de l'informatique, c'est faire faire en différé. C'est, face à une tâche (de traitement d'informations) d'une part, face à un « exécutant » aux capacités limitées mais connues d'autre part, concevoir et organiser la « marche à suivre » qui fera faire la tâche par l'exécutant.

• Faire de l'informatique, c'est s'astreindre à travailler avec les « boites » plutôt
  qu'avec les « contenus », avec les noms des choses plutôt qu'avec les choses elles-mêmes, avec les « coquilles » formelles plus qu'avec les « fruits » sémantiques.

   Ces trois cœurs profonds de l'informatique sont, bien entendu, intimement liés. C'est à l'intersection de ces trois contraintes que prend place le travail de l'informaticien. C'est aussi le triple regard qu'il est forcé de poser sur les portions du réel que l'on décide d'informatiser [10].

   J'ai à ce jour surtout creusé la seconde question qui me paraît bien être la mœlle de l'algorithmique et de la programmation. Je m'attacherai donc à présent à commenter quelque peu cette vision de la programmation, art et discipline du « faire faire ».

   L'un des objectifs souvent mis en avant lors de l'apprentissage de la programmation, comme l'une des raisons avouées de l'enseigner, est le développement de l'aptitude à la résolution de problèmes. La consultation des ouvrages d'initiation montre de fait qu'il y est constamment question « d'analyser des problèmes ». Mais lorsqu'on se penche sur les énoncés de ces « problèmes » à « analyser » ou « à résoudre », on est étonné de trouver :

   II faut reconnaître qu'il est pour le moins surprenant d'accoler le mot « problème » à ces descriptions de tâches franchement idiotes et fastidieuses.

   Chacun sait que ces énoncés vont pourtant donner naissance à de vrais « problèmes » de programmation. C'est qu'il s'agît à chaque fois, non de nous atteler bêtement à ces diverses tâches, mais de les « programmer », c'est à dire de les faire exécuter par « un autre ». Qu'il s'agisse de l'ordinateur équipé d'un langage procédural classique, que ce soit le même ordinateur transfiguré par un moteur d'inférences ou encore de l'ordinateur-tortue de l'environnement logo, il nous apparaît à chaque fois comme l'exécutant pour qui nous allons concevoir les marches à suivre (algorithmes) qui lui feront faire chacune des besognes décrites.

   Le schéma descriptif d'un problème de programmation se représente donc par :

   L'exécutant y apparaît bien comme un « obstacle » entre le programmeur et la tâche à faire faire. C'est cet obstacle qui fait de chacune des tâches abordées un problème, puisqu'il va s'agir, sur base des « aptitudes » de l'exécutant, de concevoir la marche à suivre qui prendra le contrôle de ce dernier pour lui faire exécuter le travail souhaité.

   Comme l'illustre le schéma ci-dessus, l'une des difficultés essentielles de l'algorithmique est la cœxistence de ces deux univers : celui de la tâche ou de la marche à suivre, statique et figé ; celui de l'exécutant, dynamique et évolutif. Le problème centra! de la programmation [11] c'est cette contrainte de la description figée, au sein de l'algorithme, d'un processus qui se déroulera, l'exécution.

   Dans le cas de la programmation impérative classique, on sait que les constituants essentiels du monde de l'algorithme (pour employer un terme plus classique que celui de marche à suivre) sont : la précision des objets manipulés, les instructions d'action élémentaires et, surtout, les instructions d'organisation (structures de contrôle) qui en constitueront la charpente.

   À cet univers, s'oppose celui de l'exécutant.

   Inutile d'insister sur le fait que pour qu'un problème d'algorithmique soit bien posé, non seulement la lâche doit être soigneusement précisée, mais encore, l'exécutant à qui on la destine doit être parfaitement connu. Cette connaissance comporte obligatoirement la description de l'environnement de l'exécutant, la précision des actions dont il est capable et, enfin, la donnée des structures de contrôle auxquelles il est « sensible » et des conditions qu'il est capable de tester.

   Je vais en rester ici de cette description succincte de l'un des trois traits fondamentaux de l'informatique. À la lumière de ce « faire faire », caractéristique de l'algorithmique, on comprend mieux, je pense, le statut tout à fait spécifique du concept de problème en informatique et l'on devine toute la richesse des aptitudes cognitives développées par les apprentissages sous-jacents.

Conclusions

   Bien que la « programmation » ait été au centre de nos échanges, l'avenir de son enseignement dans le secondaire ou à destination de publics de non spécialistes (utilisateurs, enseignants, ...) me paraît bien sombre. L'attrait des outils logiciels, tout auréolés de leur utilité, risque bien de réduire à la portion congrue la découverte de l'algorithmique. L'enseignement d'une informatique-outil dans le secondaire (ou même le primaire) me paraît souhaitable et j'ai plaidé pour que les informaticiens ne négligent pas l'étude des modalités et difficultés d'exploration de ces univers qu'ils ont créés.

   Mais peut-être, à côté d'un cours d'informatique « générale » où se trouveraient abordés à la fois les progiciels classiques mais aussi les questions de « culture informatique », faudrait-il un cours d'algorithmique qui ose clairement dire son nom. On préserverait ainsi à la fois le souhait de ceux qui estiment que la maîtrise des outils informatiques est souhaitable sans léser ceux qui voient dans l'apprentissage de l'algorithmique une merveilleuse -mais difficile- occasion de formation. Le cours d'informatique « générale » devrait être « pour tous » et se placer assez tôt dans le curriculum du secondaire. Celui d'algorithmique devrait être optionnel et réservé aux dernières années de la formation.

   Dans tous les cas, l'enseignement de l'algorithmique devrait explorer des voies nouvelles, par exemple en s'attachant à des exécutants dont les possibilités (primitives) permettent de faire faire des tâches plus significatives que celles permises par les langages classiques. Logo nous a en quelque sorte montré le chemin : il faut créer d'autres mondes, imaginer d'autres exécutants qui permettent ce passage du savoir faire au savoir faire faire, cœur de l'algorithmique.

   Les problèmes liés à l'enseignement de l'informatique et à son apprentissage sont et resteront nombreux. Il faudra élargir les questions, au delà de la programmation, à la définition des éléments de base d'une culture informatique. La didactique de l'informatique a encore de beaux jours devant elle. C'est heureux : l'informatique de demain sera autant ce que nous en auront dit et enseigné que ce qu'auront permis les efforts des ingénieurs, techniciens et développeurs.

Charles Duchateau
Facultés Universitaires Notre-Dame de la Paix, Namur

Paru dans les Actes du deuxième colloque sur la didactique francophone de l'informatique, 1991, AFDI-CeFIS, Presses universitaires de Namur, pages 301-321.
Reproduit avec les aimables autorisations de l'auteur et de l'éditeur.

NOTES

[1] J'ajouterai, à titre tout personnel et anecdotique que la préparation de cette synthèse est également placée sous le signe du chiffre 3 puisqu'il s'agit d'un cocktail réunissant un tiers de lecture et réflexions, un tiers de plage et de soleil et un (bon) tiers de sangria.

[2] Neuf communications portent dans leur titre les mots programmation ou algorithmique.

[3] Par d'autres chemins que la voie royale de l'apprentissage de la programmation.

[4] Encore que cela me rappelle furieusement l'apprentissage « sur le tas » de la programmation, lorsque les aptitudes cognitives mises en œuvre par son exercice étaient ignorées parce que réduites à la maîtrise d'un langage de programmation. Et de la même manière que l'on a (heureusement) glissé des « cours de FORTRAN » à des formations à la « méthodologie de la programmation », peut être faudra-t-il passer des « cours » sur LOTUS ou dBASE à des initiations aux univers de pensées sécrétés par l'emploi de ces logiciel.

[5] Je me permettrai de référencer les citations extraites de diverses communications uniquement par le nom de leur auteur.

[6] « What is Computer Science or Informatics » in W. M. Tursky (éd.), Programming Teaching Techniques, Nonh Holland Publ. Co., 1973, p. 208.

[7] Pour autant que l'on puisse parler de « tradition » dans le cas d'une discipline enseignée depuis moins de trente ans.

[8] D'autres diront « science », « technique », « art » ou « savoir ». Peut-être le vocable n'existe-t-il pas encore qui permettrait de désigner ce mélange de « méthodes », de « procédés », de « conceptions »...

[9] Toutes les courtes citations faites sont là pour illustrer et nourrir le propos. La pensée de leurs auteurs ne se limite évidemment pas à ces quelques mots, extraits et isolés de leur contexte. Je renvoie aux contributions originales qui précèdent pour une prise en compte complète de la richesse des propos des auteurs cités.

[10] En prenant bien garde à ne pas confondre le « réel » et « l'informatisable » ce qui est et ce que l'informatique peut prendre en compte (Voir à ce propos la communication de C. Hœffsaes).

[11] On aura bien entendu deviné que, dans ce contexte, j'emploie indifféremment les termes « algorithmique » et « programmation ».