Quand le savoir faire ne suffit plus

Quand le savoir faire ne suffit plus ...
(ou
Qu'y a-t-il au cœur de la pensée algorithmique et de la programmation ?)
Ch. DUCHATEAU
Centre pour la Formation à l'Informatique dans le Secondaire (CeFIS)
Facultés Universitaires N-D de la Paix,
NAMUR
Le flou dans lequel la plupart des gens tiennent le terme "algorithmique" (beaucoup le faisant rimer avec
"mathématique" quand ce n'est pas, tout crûment, avec "logarithmique") le tient à l'écart des débats sur la
place de l'informatique dans la culture et la formation. On ne sait pas bien ce que recouvre ce mot, et le
brouillard qui l'entoure le met à l'abris des critiques et des jugements. Par contre il est bien difficile d'oser
encore le mot "programmation" sans passer, surtout aux yeux des "connaisseurs" (entendez ceux qui
manipulent sans complexe un ordinateur), pour un diplodocus de l'informatique, membre d'une espèce en
voie de disparition. "Comment, à l'heure des "menus déroulants", des "logiciels conviviaux" et autres
"hyper-medias", vous n'allez pas ENCORE ressortir le Pascal de grand-papa !!! Quand le premier venu
sera bientôt capable de manipuler sans complexe "système expert" et "banque de données", vous n'allez
pas ENCORE nous accabler avec "l'approche descendante", la "programmation structurée" et autres
séquelles rébarbatives et assommantes d'une époque révolue !!!"
Ce rejet est bien perceptible dans les milieux de l'éducation : l'enseignement de l'informatique, et
particulièrement de la programmation, a parfois pris une petite place dans le curriculum de l'enseignement
secondaire. On se trouve à présent face à une double attitude : d'une part celle rejetant purement et
simplement tout enseignement de l'informatique ou, à tout le moins, exigeant de l'expurger des pratiques
aussi inutiles que la programmation, et d'autre part celle prônant son annexion par les mathématiques.
Dans le premier cas, la dépouille de la défunte formation à l'informatique serait partagée entre les autres
disciplines, chacune arrachant les morceaux qui lui conviennent, l'essentiel étant de toute manière que les
"outils informatiques" soient manipulés au sein des divers cours : le prof de math fera un peu
d'algorithmique, on utilisera les tableurs au cours d'économie, les gestionnaires de fichiers au cours de
géographie ou d'histoire, le traitement de texte partout, et, en prime, un EIAO 1 omniprésent familiarisera
sans peine les élèves avec l'ordinateur et le monde de l'informatique.
La seconde éventualité placerait l'apprentissage de l'informatique dans le giron de celui des
mathématiques. Il est vrai que ce sont souvent les professeurs de mathématiques qui assurent le cours
d'informatique et que, dès lors, l'initiation à la programmation fait la part (trop) belle aux situations
"mathématiques". Mais cette annexion aurait pour effet de réserver a priori la découverte de la pensée
algorithmique aux "forts en math" et d'amputer le terrain couvert par la programmation de domaines
importants.
Avant de jeter ainsi, dans la fosse commune des concepts révolus et des activités surannées,
l'algorithmique et la programmation (qui en est l'incarnation), je souhaiterais que cette inhumation se fasse
dans la clarté et qu'on sache clairement ce qu'on est en train d'enfouir au mausolée des idées
poussiéreuses et des conceptions vieillottes... Il est vrai que si le critère d'utilité immédiate est au centre
de nos préoccupations, la programmation mérite de fait un enterrement de première classe. Mais, elle ne
restera pas longtemps seule dans l'oubliette des approches dépassées et des théories désuètes : le
même critère d'utilité l'y fera accueillir bientôt les mathématiques, l'analyse littéraire, la poésie et la
musique...
1
enseignement intensément inmanquablement intelligemment apauvri assisté par ordinateur
1
Quand le savoir faire ne suffit plus ...
Je vais m'attarder ici sur ce qui fait le coeur de la pensée algorithmique et de la démarche de
programmation en montrant qu'elles nous font franchir les frontières de notre monde mental habituel, celui
du "savoir faire", pour nous faire pénétrer dans un monde nouveau et fascinant, celui du "savoir faire
faire".
1. Vous avez dit problème ?
Dans le champ sémantique où prend place la programmation, on trouve certainement les termes
"ordinateur", "langages" mais aussi, à coup sûr, pour qui a un peu fréquenté ces parages, les vocables
"analyse" et "problème". Je remettrai à leur place tantôt l'ordinateur et les langages de programmation,
mais il est impératif de souligner d'emblée ce que recouvre, lorsqu'il est question d'algorithmique et de
programmation, l'expression "analyser un problème".
Il suffit pour cela de repartir de l'un ou l'autre énoncé "classique" ou, en tout cas, bien connu des adeptes
de la programmation et présents dans les ouvrages qui en parlent.
On y trouve, par exemple :
"analyser le problème de donner la date de demain, sachant quel jour nous sommes"
ou
"le problème consiste à écrire en toutes lettres un nombre exprimé en chiffres"
ou encore
"résoudre le problème de déterminer le plus grand de trois nombres"
Si vous êtes un habitué du monde de la programmation, ces énoncés vont vous paraître bien anodins.
Faites alors l'expérience de les proposer à des gens non encore contaminés. Vous verrez, dans leurs
yeux étonnés, à quel point il est choquant d'accoler, comme ci-dessus, le mot "problème" aux tâches
franchement imbéciles qui sont décrites. Pourquoi diable parler de problème à propos du fait de pouvoir
dire quel jour nous serons demain ou d'être capable de choisir le plus grand de trois nombres? Parlez-moi
d'un beau "problème" de robinets, de trains qui se croisent ou de partages inégaux; là, d'accord : ce n'est
pas simple et la plupart d'entre nous ne gardent que des souvenirs émus de la peine, sinon des larmes,
que leur ont couté ces "vrais problèmes"!
Même si nous allongeons la liste de nos énoncés en proposant de "trier des nombres" ou de "chercher
un nom dans une liste", nous aurons bien du mal à faire comprendre pourquoi nous parlons "d'analyse "
et de "problèmes" là où l'on ne voit qu'activités fastidieuses.
Pourquoi, dès lors conférons nous tout de même le statut de "problèmes" à ces propositions de "tâches"
ennuyeuses et débiles ? Et qu'aurons nous "résolu" lorsque nous décrèterons que notre travail de
programmation est terminé ?
Répondre à ces questions, c'est cerner ce qui fait l'essentiel de la démarche de programmation, ce qui est
au coeur de la pensée algorithmique. Et ce noyau dur tient en peu de mots :
PROGRAMMER
c'est
FAIRE FAIRE
Si chacune des tâches décrites ci-dessus va donner lieu à un véritable problème, c'est simplement parce
qu'il s'agit, non de l'effectuer nous même (ce qui, vraiment, n'aurait aucun intérêt), mais plutôt d'expliquer
2
Quand le savoir faire ne suffit plus ...
à "un autre" comment il va pouvoir s'y prendre pour la mener à bien.
2. Faire et faire faire : tâche et problème
La situation qui nous est familière peut être schématisée par
Moi + Outil
Tâche
Ainsi, par exemple :
Moi + machine à écrire
composition d'un texte
Moi + calculatrice
calcul d'une moyenne
Moi + bac à fiches
gestion des emprunts de livres
ou
ou
Même si l'ordinateur est utilisé, à travers les outils logiciels que propose l'informatique, la situation reste,
au fond, inchangée :
Moi + traitement de texte2
composition de texte
Moi + tableur
calcul d'une moyenne
Moi + gestionnaire de fichiers3
gestion des emprunts de livres
ou
ou
La situation dans laquelle me place la programmation est bien différente :
Moi
Exécutant
Tâche
Marche à suivre
Je ne suis plus aux prises directement avec la tâche à réaliser et, si l'ordinateur entre dans le champ de
mes préoccupations de programmeur, ce n'est certes pas comme un outil qui va m'aider à venir à bout du
traitement proposé. Il serait si simple de rester dans la situation familière ou je fais les choses; il me faut
ici passer dans la problématique inconfortable où je vais devoir les faire faire. L'ordinateur n'apparaît plus
alors comme un outil, mais comme l'exécutant à qui je vais devoir fournir toutes les explications
nécessaires pour qu'il puisse mener à bien, à ma place, une tâche que je pourrais (souvent) effectuer
moi-même, pratiquement sans réfléchir. Il constitue, en quelque sorte, un obstacle entre moi et la tâche à
effectuer. Mon problème, c'est de concevoir et de rédiger la marche à suivre à laquelle se conformera
aveuglément cet exécutant-ordinateur et dans laquelle j'aurai entièrement décortiqué en constituants
élémentaires la tâche à réaliser.
Le schéma se complète donc :
2
On me permettra ce raccourci pour "ordinateur équipé d'un logiciel de traitement de texte"
3
Je ne parle évidemment pas ici des utilisations d'outils logiciels qui participent au monde de l'algorithmique : définition d'une
feuille de style lors de l'utilisation d'un logiciel de traitement de texte, conception de macros pour automatiser des séquences
d'opérations d'un tableur, usage d'un logiciel de gestion de fichiers en mode "programme",...
3
Quand le savoir faire ne suffit plus ...
Moi
Exécutant
Tâche
il exécutera
je conçois
elle gouvernera
Marche à suivre
On remarquera l'emploi du futur : le "faire faire" exigé par la programmation n'est pas un "faire faire" en
direct. Toutes les consignes nécessaires, il me faut a priori les enfermer dans une marche à suivre, un
algorithme : l'exécution aura lieu en différé sans qu'il me soit possible alors d'intervenir pour en rectifier le
déroulement. Cette problèmatique constitue pour moi le coeur de la pensée algorithmique : savoir faire ne
suffit plus, il faut être capable de savoir faire faire, en différé !
Ainsi, un problème, dans le monde de la programmation consiste
- face, d'une part, à une tâche, décrite aussi précisément que possible,
- face, d'autre part, à un exécutant aux capacités limitées mais parfaitement connues,
à rédiger la marche à suivre indispensable pour faire faire cette tâche par cet exécutant.
On comprend mieux, dès lors en quoi les énoncés proposés plus haut constituent de vrais problèmes de
programmation ; il suffit d'accepter de les réécrire :
"analyser le problème de faire donner la date de demain, sachant quel jour nous sommes"
et
"le problème consiste à faire écrire en toutes lettres un nombre exprimé en chiffres"
et
"résoudre le problème de faire déterminer le plus grand de trois nombres"
Et nous savons qu'il y a un monde entre "être capable d'effectuer les tâches proposées" et "pouvoir les
faire faire par l'exécutant-ordinateur". Ce monde, c'est celui de la programmation, justement !
Encore un mot : il manque évidemment à chacun des énoncés ci-dessus, la description précise des
caractéristiques de l'exécutant à qui nous destinons les marches à suivre correspondantes. Il va de soi
qu'il s'agit à chaque fois de l'ordinateur, transfiguré par sa compréhension apparente de l'un ou l'autre
langage de programmation (de type procédural). Je voudrais cependant insister lourdement sur le fait que
pour qu'un problème soit correctement et complètement posé en programmation, il faut disposer d'une
description précise à la fois de la tâche à faire faire et de l'exécutant qui devra l'effectuer. Autrement dit, la
conception d'un algorithme doit évidemment prendre en compte ce qu'il faut faire (faire) mais aussi ce
dont est capable l'exécutant qui en sera chargé.
3. Quelques exemples
La programmation habituelle
Le processus qui est au coeur de la pensée algorithmique s'incarne le plus souvent dans la
programmation "habituelle", telle qu'on peut la vivre lorsque l'interlocuteur est l'ordinateur équipé d'un
compilateur (ou d'un interpréteur) Pascal, LSE, Basic, ...
4
Quand le savoir faire ne suffit plus ...
S'il fallait alors dresser une caricature de l'exécutant, il suffirait de dire que nous avons à faire à un
manipulateur d'informations, à condition de dépouiller ce dernier terme des attributs de "sens" et de
"connaissance" que nous lui attachons habituellement. Il va sans dire, dès lors, que les tâches traitables
sont celles consistant en des manipulations formelles (= basées sur la seule forme, la seule apparence)
d'informations.
Cette restriction des capacités de l'exécutant aux seuls maniements formels d'informations ne pose aucun
problème dans les tâches de traitements de nombres, qui sont, par essence, formalistes. Par contre,
lorsque l'on opère sur des informations de type "texte", cette contrainte de s'en tenir strictement aux
manipulations formelles est presque insupportable. Au delà de quelques aspects techniques sans grande
importance, le problème est identique à celui auquel je serais confronté s'il me fallait faire faire les
traitements attendus à propos d'un texte rédigé en français, par un ami portugais ne comprenant pas un
traitre mot de notre langue. S'il s'agit seulement de lui faire compter les mots du texte, mes explications
(en portugais) ne vont pas me demander trop d'effort. Je vous laisse le soin d'imaginer ce que peut être
ma perplexité, si je souhaite lui faire résumer le même texte...
Cette nécessité d'enfermer le "sens" dans la "forme", de traquer sans cesse la "sémantique" dans la
"syntaxe", le "contenu" dans le "contenant" caractérise l'activité de programmation "classique". J'y
reviendrai plus loin.
Au delà de ces caractéristiques de l'exécutant-ordinateur qui colorent fortement la démarche de
programmation, on retrouve bien le schèma déjà présenté :
Analyste-programmeur
Exécutant
manipulateur d'informations
Tâche de traitement
formel d'informations
Algorithme
Je ne peux m'y attarder ici, mais le chemin qui conduit de la tâche à son exécution par l'ordinateur est
jalonné de quelques étapes, articulées autour de questions phares, qui balisent le parcours et autour
desquelles on peut articuler l'apprentissage.
Analyste-programmeur
Exécutant
manipulateur d'informations
Quoi faire ?
Spécifications
Programme
Comment faire ?
Stratégies
Comment dire ?
Comment faire faire ?
Algorithme
5
Tâche de traitement
formel d'informations
Quand le savoir faire ne suffit plus ...
Le lecteur intéressé par les développements de toute cette problématique du "faire faire" dans le cadre de
la programmation "classique" peut consulter [4],[7] ou [8].
LOGO
Depuis plusieurs années déjà, l'environnement d'apprentissage proposé par le langage LOGO, et
spécialement ses aspects graphiques, est exploité dans les classes. Je ne souhaite pas ici analyser la
pertinence globale de ce choix, mais seulement montrer que LOGO place l'apprenant au coeur de la
pensée algorithmique et du monde de la programmation. Et ce n'est absolument pas à cause de la
présence de l'ordinateur.
Ceux qui prétendent que LOGO permet aux enfants de dessiner sont vraiment à côté du vrai processus.
Quel intérêt y aurait-il d'ailleurs à dessiner des cercles, des carrés ou des maisons ? A travers LOGO,
l'enfant ne dessine pas, il fait dessiner ! Ce qu'il a devant lui, ce n'est pas un ordinateur, ni non plus une
panoplie d'outils graphiques, c'est un exécutant-tortue à qui il va pouvoir donner des ordres de
déplacements, pour qui il va concevoir des marches à suivre. Et il y a un monde, à nouveau, entre
"dessiner un cercle" et "concevoir à l'avance, pour l'exécutant-tortue, la marche à suivre comportant
toutes les indications indispensables pour lui faire tracer un cercle"4.
Ici encore, le processus est identique :
Apprenant
Tortue
Dessin
Marche à suivre
Les machines à commande numérique
Voici, en apparence, un monde bien différent de celui de l'informatique. Pourtant, le saut qualitatif lors du
passage d'un travail classique au tour ou à la fraiseuse à ce "même" travail sur des machines à
commande numérique fait basculer dans l'univers de l'algorithmique. La machine, l'outil, qu'on manipulait
"en direct", pour fabriquer la pièce souhaitée, s'est muée en exécutant qui exige de son "programmeur",
qu'il déplie en une marche à suivre explicite la succession et l'enchaînement des opérations
indispensables. Les "savoir faire" qui présidaient au travail du tourneur ne suffisent plus : il faut "savoir
faire faire" en fournissant à travers un mode d'expression, comme par exemple le GRAFCET, le
"programme" qui sera suivi (en différé) par l'exécutant-tour.
4
J'ai vu des professeurs de mathématiques passer des heures pour imaginer comment faire dessiner deux cercles
concentriques par la tortue. Ils auraient pu tracer ces cercles en quelques secondes !
6
Quand le savoir faire ne suffit plus ...
Travailleur
Tour à commande
numérique
Réalisation d'une
pièce
Marche à suivre
Ici encore, la connaissance des possibilités de l'exécutant-machine est indispensable avant de concevoir
l'enchaînement des indications de mouvement et des opérations qui feront fabriquer la pièce souhaitée.
L'enseignement assisté par ordinateur
Je voudrais à la lumière de ce passage au faire faire, coeur de la démarche algorithmique, souligner
quelques limites de l'EAO.
L'ordinateur peut être pour l'enseignant un auxilliaire irremplaçable. Qu'il s'agisse de dessiner une courbe,
de prendre en charge des calculs fastidieux, de simuler un phénomène, d'effectuer du drill..., il s'avère un
outil précieux, que l'enseignant peut choisir d'intégrer dans ses stratégies, le moment venu. L'EAO
désigne tout naturellement alors un "enseignant assisté (ou aidé) par l'ordinateur". On a parfois,
inconsciemment sans doute, caché sous ce même sigle EAO un "enseignement assuré par ordinateur".
Cela, c'est évidemment du fantasme, et parler de l'ordinateur "tuteur" et de programmes "tutoriels" me
semble, à tout le moins, exagéré ou fort optimiste.
Qu'il me suffise, pour marquer les limites des programmes d'EAO d'évoquer une situation bien banale:
celle d'un dialogue entre l'enseignant et l'apprenant. L'enseignant va pouvoir réagir aux réponses fournies
par l'élève, demander des précisions supplémentaires, détecter dans les erreurs commises les
mécompréhensions, proposer d'autres exemples, ... Bref, s'il s'agit d'un vrai dialogue, entre deux êtres
humains, l'un désireux d'apprendre, l'autre soucieux de faciliter cet apprentissage, on débouche sur une
diversité proprement imprévisible de déroulements possibles.
Si l'ordinateur entre dans la relation, il ne s'agit plus alors de dialoguer "en direct", les yeux dans les yeux,
avec l'apprenant; il faut "faire dialoguer", en ayant prise, évidemment, que sur l'un des deux interlocuteurs,
le seul dont on va préciser les actions et réactions dans l'indispensable marche à suivre.
Enseignant
Ordinateur transfiguré
par un langage-auteur
Dialoguer
avec l'apprenant
Programme "tutoriel"
J'espère que l'on sent toute l'utopie de vouloir "gérer d'avance un dialogue". La seule solution
envisageable reste alors de réduire ce dialogue à une caricature où l'on permet seulement à l'apprenant
de "biffer la mention inutile".
Les tentatives pour "faire enseigner" l'exécutant-ordinateur ont cependant, pour ceux qui s'y essayent, un
7
Quand le savoir faire ne suffit plus ...
aspect extrêmement bénéfique. C'est celui de servir de révélateur de tous les flous et implicites sousjacents à la démarche d'enseignement. Devoir "expliquer", dans le détail, à cet exécutant, comment aider
à apprendre, oblige l'enseignant-programmeur à déplier complètement ses objectifs, ses stratégies, ses
savoir faire,... Il est tenu de poser devant ses propres yeux, de décortiquer comme un objet d'étude, sa
démarche d'enseignement, d'y traquer tous les "à peu près", toutes les imprécisions, toutes les réactions
sans fondement,...L'exécutant est alors un merveilleux miroir qui renvoit, froidement, au formateur une
image sans complaisance de son manque de stratégies efficaces et de réflexions préalables5.
Certaines utilisations de logiciels
J'ai clairement souligné ci-dessus la différence de statut entre les outils que sont les progiciels habituels
et l'exécutant que constitue l'ordinateur équipé d'un langage de programmation.
Puisque j'en suis à indiquer des exemples variés de situations où l'on fait faire en différé, je ne peux bien
sûr manquer de relever les occasions que donnent certains progiciels de manifester cette pensée
"anticipative".
Les traitements de texte actuels, ceux du "WYSIWYG" 6 effectuent en direct les commandes de
présentation données par l'utilisateur. Qu'il demande par exemple de centrer un titre, l'effet est immédiat
et visible : le titre est centré. On sait que cela n'a pas toujours été le cas : les antiques logiciels de
traitement de texte demandaient qu'on truffe le texte proprement dit d'un certain nombre de "codes" qui ne
modifiaient en rien ce qui était montré à l'écran. C'est seulement lors de l'impression, que ces codes
étaient interprétés comme des instructions de mise en page et qu'on mesurait leur effet. Combien
d'erreurs de "programmation" ont conduit, dans ce contexte à l'obtention d'un texte entièrement souligné,
ou complètement en caractères gras, ...
Même les traitements de texte évolués actuellement disponibles comportent des facettes qui nous placent
au sein du monde du "faire faire". Ne parlons pas des possibilités de mettre en place des "macros", qui ne
sont jamais que des expressions plus ou moins ésotériques de véritables marches à suivre qui, le
moment venu, automatiseront certains actions complexes. Mais la simple conception d'une banale feuille
de style, telle que la permettent aujourd'hui la plupart des logiciels de traitement de texte, nous oblige à
penser "en différé". Nous sommes tenus d'anticiper le résultat souhaité en précisant des "souhaits" de
mise en page, qui ne deviendront effectifs que lors de l'appel du style ainsi défini. Au moment où je fixe
les caractéristiques formelles ( le "style") d'un paragraphe à venir, mes choix n'ont pas d'effet immédiat et
visible; c'est seulement quand je ferai appliquer le style préalablement décrit à une portion de texte
existant que mes indications seront suivies et conduiront (parfois) au résultat escompté.
Dans ce cas aussi, le schèma est :
Utilisateur du logiciel
de traitement de texte
Ordinateur équipé
du logiciel
Mise en page
du texte
feuille de style
5
L'ordinateur n'est certes pas le seul "révélateur" de ces pratiques : la conception des "cours programmés", par le dépliage
complet des contenus et des stratégies auquel elle obligeait, était aussi un moyen privilégié de remettre en cause certaines
"méthodes" routinières des enseignants.
6
"What You See Is What You Get": on voit à l'écran exactement ce qu'on obtiendra à la sortie du texte sur l'imprimante.
8
Quand le savoir faire ne suffit plus ...
Et enfin ...
Il y aurait bien d'autres exemples pour éclairer et préciser ce "faire faire" qui est au centre de la pensée
algorithmique. Qu'il me suffise de schématiser le processus qui est au coeur de la composition musicale
Compositeur
Musicien
(exécutant)
Exécution d'une
oeuvre
partition
ou encore la problématique qui est au centre de la réalisation d'un produit audio-visuel (émission
télévisée, fim,...) :
Auteur-scénariste
réalisateur
équipe-technique
réalisation d'un film,
d'une émission vidéo
scénario
La liberté de moyens, la sensibilité, les choix artistiques caractérisant le réalisateur et son équipe
technique ne doivent pas faire oublier qu'ici aussi, le scénario constitue une "marche à suivre" à laquelle
on se tiendra et qui contient, en germe, le résultat final. Comme lors de la programmation classique,
l'auteur doit imaginer pendant la conception du scénario-marche à suivre, ce que donnera la réalisation
des indications et instructions qu'il est en train d'y enfermer. J'ai, personnellement, été frappé du
parallélisme entre cet univers et celui de la programmation ... à ceci près qu'on peut toujours corriger un
programme incohérent ou dont l'exécution ne fournit pas les résultats attendus et qu'il est inutile de
réécrire un scénario qui a débouché sur une émission insatisfaisante...
4. Quelques traits de la pensée algorithmique
On devine déjà la richesse et l'exigence de ce passage au "faire faire". Je citerai, en vrac, quelques
caractéristiques essentielles de cette pensée, correspondant à des attitudes et des facultés qu'elle va
contribuer à développer chez ceux qui veulent la partager, à travers, par exemple, l'apprentissage de la
programmation :
-
-
-
Pour faire faire une tâche, il faut passer en quelque sorte du rôle d'acteur à celui de metteur en
scène : il faut pouvoir prendre du recul, imaginer des possibles, choisir des stratégies
adaptées,...
La programmation comporte une chasse impitoyable aux flous et aux implicites; elle oblige à
déplier (déplier= ex-pliquer) complètement la tâche à réaliser, en ne laissant dans l'ombre
aucun de ses aspects.
Le fait de devoir a priori TOUT dire de la manière d'effectuer la tâche oblige à être exhaustif, à
ne rien laisser dans l'ombre, à percevoir tous les possibles, à tenir compte des "cas limites".
Concevoir une marche à suivre, c'est avant tout organiser; la difficulté ne réside pas dans la
richesse du répertoire d'actions dont l'exécutant est capable mais, au contraire, dans la
manière dont il va falloir combiner et enchaîner le petit nombre de ses possibilités. Le point
central, c'est de pouvoir décortiquer une tâche trop complexe en constituants plus élémentaires
9
Quand le savoir faire ne suffit plus ...
-
qui, convenablement organisés, permettront de venir à bout du travail exigé.
Le fait d'être soumis à la censure finale de l'exécutant rend critique vis à vis de ses propres
productions.
Si l'on regarde de plus près l'activité de programmation, elle se caractérise par la faculté de
pouvoir enfermer dans une expression figée et statique (le texte de la marche à suivre) toute la
dynamique qui présidera au déroulement de l'exécution; c'est une attitude un peu
"schizophrène" où tout en organisant le texte de la marche à suivre, on anticipe ce que sera
son exécution : on ne peut être un concepteur que si, en même temps on est capable de "se
mettre dans la peau de l'exécutant". Ainsi, on garde un pied dans le monde de la tâche à faire
exécuter et l'autre dans l'univers de l'exécutant et de ses possibilités.
On pourrait sans doute allonger cette liste en parlant de la rigueur ou de la cohérence indispensable, de
l'imagination nécessaire à la recherche de stratégies efficaces, des capacités d'introspection
("comment est-ce que je m'y prends face à cette tâche ?"), du sens de l'écoute et du dialogue (au cours
de l'étape la plus compliquée du processus, celle du "quoi faire?", où l'on se renseigne sur ce qui est
attendu),...
Si les caractéristiques décrites ci-dessus sont présentes dans toutes les situations où l'on sera amené à
"faire faire" en différé, d'autres facettes tiennent à la "personnalité" de l'exécutant auquel s'adresse la
programmation classique. J'ai eu l'occasion de souligner qu'il s'agit d'un gestionnaire formaliste
d'informations.7 Cette caractéristique va contraindre à ne jamais référer au "sens" de ce qu'on fait
manipuler. Notre interlocuteur est "quelqu'un" à qui il faut TOUT dire, même ce qui fait partie du "sens
commun" implicitement partagé par tous. Ici aussi les questions posées seront neuves. Par exemple :
-
sur quel critère de "forme", décidons nous qu'une succession de lettres n'a aucune chance
d'être un "mot" ?
comment "formaliser" l'écheveau sémantique des relations qui lient, dans notre cerveau, les
concepts ?
...
Si cette entrave de formalisation oblige à expliciter et à analyser bien des comportements "naturels", il faut
cependant être conscient du caractère fort particulier de l'approche ainsi exigée. Le piège ici c'est de
ramener le sens ou la connaissance à ce qu'on peut aisément enfermer dans des "boites" et dans les
liens qu'on tresse explicitement entre elles. Il faut garder sans cesse en tête l'avertissement de T. Eliot,
prolongé de la remarque de M. Aspen (Cf [9]):
"Qu'est devenue la sagesse que nous avons perdue dans la connaissance?
Qu'est devenue la connaissance que nous avons perdue dans l'information?
Qu'est devenue l'information que nous avons perdue dans les données?"
5. Conclusions
Personne ne prétend évidemment que la programmation est la seule activité capable de développer les
attitudes mises en évidences ci-dessus. Ce "faire faire" est en fait une modalité extrêmement particulière
d'exercice de la pensée organisatrice et rationnelle. Il faut se défendre absolument des amalgames
douteux dans lesquels on qualifie d'algorithmique n'importe quelle attitude rigoureuse et organisée. On ne
fait pas de l'algorithmique "sans le savoir" quand on résoud un problème d'arithmétique ou quand on
utilise un logiciel de traitement de texte. Tenter de recouvrir du manteau de l'algorithmique des domaines
qui lui sont étrangers est aussi vain que d'en ignorer la texture particulière et les qualités propres.
Je ne veux pas plaider davantage pour l'intérêt et et la richesse de l'apprentissage de ce type de pensée,
7
Cf [2] pour plus de détails.
10
Quand le savoir faire ne suffit plus ...
à travers, par exemple une initiation correcte à la programmation. D'autant qu'il est bon d'en souligner les
dangers et les limites. Comme toute approche modélisante, la programmation gomme bien des aspérités
du réel; je dirais volontiers que la démarche de programmation "rabote" souvent la complexité
proprement "intraitable" de la réalité. Le profond danger, c'est de ne pas percevoir ce caractère réducteur
de la pensée algorithmique et de finir par identifier et confondre "ce qui existe" et "ce qu'on peut prendre
en compte", le "traitable" et "le réel". Des antidotes s'avèrent dès lors indispensables, comme présenter
des situations complexes qui permettront de fixer les bornes et les limites de ce pays du "faire faire".
6. Bibliographie
[1]
ARSAC J.
Premières leçons de programmation.
Cedic-Nathan, Paris, 1980.
[2]
ARSAC J.
Les machines à penser. Des ordinateurs et des hommes.
Editions du Seuil, Paris, 1987.
[3]
DUCHATEAU C.
Enseigner l'informatique en octobre 1986.
dans "Construire une éthique de l'eneignement scientifique".
Presses Universitaires de Namur, 1986, pp 102-125.
[4]
DUCHATEAU C.
Programmer ! Pour une découverte des méthodes de la programmation.
Wesmael-Charlier, Namur, 1983.
[5]
DUCHATEAU C.
Du savoir faire au savoir faire faire.
Cours 467 : l'informatique dans l'enseignement. (CPS 84-311).
Conférence Suisse des Directeurs Cantonaux de l'Instruction Publique.
[6]
DUCHATEAU C.
Additionner deux entiers ... et faire additionner deux entiers.
Mathématique et Pédagogie, 63, 1987, pp 33-66.
[7]
DUCHATEAU C.
Incursion au pays du Faire Faire.
Mathématique et Pédagogie,
46, 1984, pp 23-38 (1ère partie)
47, 1984, pp 47-56 (2ème partie)
48, 1984, pp 63-76 (3ème partie)
[8]
DUCHATEAU C.
Images pour programmer
(A paraître)
[9]
Sociéte d'information et formation générale.
Conférence internationale sur l'Education et les Nouvelles Technologies de l'Information,
Juillet 1984, OCDE
11