Enseigner l'informatique, à l'université, à de futurs utilisateurs : pourquoi, quoi et comment?

Transcription

1 Enseigner l'informatique, à l'université, à de futurs utilisateurs : pourquoi, quoi et comment? Conférence présentée au colloque "50 ans d'informatique, 25 ans d'informatique dans l'enseignement", Fribourg, septembre Charles DUCHÂTEAU 1 Introduction Pour des raisons que je me propose d'analyser, le curriculum universitaire de nombreux étudiants comporte aujourd'hui une introduction à l'informatique. Ces étudiants sont essentiellement des utilisateurs (actuels ou potentiels) de systèmes informatisés et d'instruments logiciels. L'ancienne réponse, lorsqu'il s'agissait d'initier qui que ce soit à l'informatique, qui se résumait le plus souvent à une initiation à l'algorithmique ou même à la programmation à travers l'apprentissage d'un langage de type Pascal, n'est sans doute plus aujourd'hui ni appropriée, ni suffisante. Quels doivent dès lors être les contenus et les principes organisateurs de ces "cours de service"? Comment concilier la maîtrise nécessaire des instruments logiciels avec l'exigence d'un cursus universitaire qui ne peut se satisfaire d'une accumulation de modes d'emploi? "L'informatique des utilisateurs" est-elle autre chose qu'un fatras de pratiques, d'usages et de savoir faire? En un mot : quelle informatique enseigner à ceux qui ont et auront essentiellement à utiliser les outils qu'elle a sécrétés. Ce sont quelques éléments de réponse à ces questions que je voudrais évoquer dans la présente contribution. 2 Pourquoi ces réflexions : ma situation d'enseignant. Même s'il est de bon ton que l'auteur d'une contribution comme celle-ci soit en quelque sorte absent, en tant que sujet, des problèmes évoqués, il est évident que ces réflexions sont la suite directe de mon expérience d'enseignant, confronté à des cours "d'informatique" de premier cycle à destination d'étudiants utilisateurs. Quelles que soient les réponses générales apportées aux questions mentionnées plus haut, quelles que soient mes opinions sur la nécessité d'une initiation à l'informatique dans certaines formations universitaires, et donc sur la pertinence même de ces questions, j'ai chaque semaine à enseigner à des étudiants de premier cycle en biologie, en géographie ou en pharmacie à qui l'on m'a simplement demandé de "parler d'informatique en excluant toute pratique intempestive de la programmation". Et comme les détracteurs de Zénon qui lui démontraient la possibilité de la marche en marchant, c'est en enseignant qu'il m'a fallu répondre à ces questions sur la possibilité d'enseigner une "informatique des utilisateurs" à des non futurs informaticiens. 1 Je suis actuellement chargé d'un cours de 30 heures (à raison de 2 heures par semaine pendant un trimestre), assorti de 15 heures de travaux pratiques assurées par un collaborateur, à destination d'étudiant(e)s de seconde candidature 2 en biologie, en géographie et en géologie et d'un (mini) cours de 15 heures (sans travaux pratiques) dispensé aux étudiant(e)s de première candidature en sciences pharmaceutiques. Ces deux publics représentent chacun plus d'une centaine d'étudiant(e)s, les contraintes étant celles qu'on trouve habituellement dans les cours de premier cycle : je ne suis pas en mesure de gérer globalement un environnement et un horaire à travers lesquels ces étudiant(e)s seraient "en contact avec l'informatique" (ou à tout le moins en relation avec des 1 2 En incluant dans ce terme d'informaticien toutes les sections (mathématique, ingénieurs,...) qui font une grosse consommation de formalisme et où l'on peut se permettre d'enseigner "l'informatique des informaticiens"; dans un premier temps en tout cas, l'identité "prise de contact avec l'informatique" = "enseignement de la programmation" y est acceptable (et chaque jour mise en oeuvre au sein de nos universités). seconde année du premier cycle universitaire. ARTFRIB.DOC 28 novembre

2 environnements informatisés); je suis réduit à dispenser de manière très classique une succession de cours magistraux, face à des étudiants assis dans un amphithéâtre et qui vont ingurgiter 55 minutes d'informatique en sandwich entre 55 minutes de physique et 55 minutes de botanique. 3. Les travaux pratiques sont assurés par un assistant : les étudiants par groupes d'une vingtaine accèdent à une salle de micro-ordinateurs, par période de 2 heures, et découvrent, à 2 par machine, les premiers savoir faire relatifs au traitement de texte et au tableur Les arguments avancés pour placer "l'informatique" dans le cursus du premier cycle universitaire Il y a quinze ans encore, l'informatique n'avait aucune place dans le curriculum universitaire des sections mentionnées. Au delà des circonstances et des enjeux locaux, quelques arguments ont été (et restent) avancés par les autorités académiques des sections d'étude concernées pour inscrire l'informatique au programme des cours. Ces arguments ont varié dans le temps, ils n'ont pas tous la même importance et ne sont pas toujours défendus par les mêmes personnes. 3.1 L'argument du "microscope électronique" C'est celui où le cours d'informatique est motivé par l'utilisation des ordinateurs : il est semblable à celui qui justifie (en partie) les cours de physique, comme préalables à une utilisation "consciente" et "éclairée" du microscope électronique. Les principes et les lois de la physique qui sous-tendent le fonctionnement du microscope électronique doivent être connus de ses utilisateurs. Le cours de physique comporte d'ailleurs généralement un chapitre-alibi : "principes de fonctionnement du microscope électronique". Cet argument est important, mérite qu'on s'y arrête et nous place d'ailleurs dans un profond embarras lorsqu'il s'agit d'évoquer - à l'instar du microscope- les "principes qui expliquent et sous-tendent le fonctionnement de l'ordinateur". - Selon le niveau de description souhaité, les principes évoqués relèvent de la physique, de l'électronique, de l'algèbre booléenne, de l'algorithmique,...où de ce que l'on trouve dans la plupart des traités sur l'architecture interne (processeur, mémoire,...) ou globale (périphériques, unité centrale, mémoires de masse). On ressent toute l'insuffisance de ces descriptions matérielles pour que l'utilisateur, aux prises avec son logiciel de traitement de texte favori, comprenne "comment ça marche" et acquière une représentation cohérente et efficace de ce qu'il a en face de lui. - Une description qui se borne à prendre en charge l'ordinateur seul n'a aucune chance d'être satisfaisante puisque l'ordinateur "seul" n'existe pas (Cf. ci-dessous). Ce que tout utilisateur a sous les yeux, c'est toujours un système, un tandem "ordinateur-logiciel", le second membre de ce couple étant susceptible de changer à l'infini : le système informatique du musicien n'a rien a voir avec celui de l'architecte, qui n'a lui même que peu de rapport avec celui de la dactylo. L'argument du microscope électronique est cependant fort important : il nous met en demeure d'énoncer les principes généraux, les invariants qui expliquent et sous-tendent toute utilisation d'un système informatique (ordinateur + logiciel). Si nous ne sommes pas en mesure d'apporter une réponse satisfaisante à cette question, alors c'est que "l'informatique 3 4 Ce n'est évidemment pas mon propos d'évoquer les avantages et inconvénients de l'organisation des premiers cycles universitaires belges (et autres...). L'enseignement y est constitué d'une série de prêches où le professeur, face à des auditoires importants, parles en s'aidant de moyens plus ou moins évolués (tableau, rétroprojecteur, diapositives,...). Les étudiant(e)s écoutent (!), notent (!!) et répondent (!!!) aux rares questions de l'enseignant. Si j'insiste sur ces contraintes organisationnelles, c'est que j'ai par ailleurs la chance de vivre une réalité toute différente dans la partie de mon enseignement consacrée à la formation continuée d'enseignants : j'y dispose de 4 heures successives, dans un local très proche d'une salle équipée de micro-ordinateurs. Les "enseignant(e)s-étudiant(e)s" y sont une vingtaine, volontaires, et je gère à ma guise l'organisation de la demi-journée de travail et d'apprentissages. ARTFRIB.DOC 28 novembre

3 des utilisateurs" est un mythe. 3.2 L'argument "c'est indispensable pour certains cours qui vont suivre" C'est aussi un argument traditionnel pour justifier les curriculums de premier cycle. On y fait des mathématiques à cause des cours de physique et des cours de physique parce qu'ils sont nécessaires pour certaines parties du cours de chimie, et des cours de chimie parce qu'il y a de la biochimie au second cycle,... Ainsi l'une des justifications de mon cours d'informatique à destination des biologistes est l'existence, au second cycle, d'un cours sur les utilisations d'un package de calculs statistiques. Je ne suis pas certain que le contenu des cours de mathématiques ainsi justifiés ne déborde largement de ce que le cours de physique utilisera et que ce même cours de physique ne fasse lui-même une très large place à des chapitres inutiles pour le cours de chimie, etc.. Peut-être pourrons-nous, en tout cas, dans la foulée, à l'instar de ce qui se fait dans les autres cours, proposer un cours d'informatique qui déborde des contraintes de l'utilisation future d'un package de statistiques. 3.3 L'argument "c'est indispensable dans la vie professionnelle" Il correspond à la constatation pertinente d'une informatisation croissante de secteurs de plus en plus larges des activités professionnelles. Ainsi, puisque demain, au sein de leur officine, mes étudiant(e)s de première année de pharmacie d'aujourd'hui auront "à faire à l'ordinateur", il faut préparer cette utilisation à venir, afin que les pharmaciens de demain se trouvent armés face à la machine, face aussi à tous ceux qui essayeront de leur vendre matériel et logiciel. Notons cependant que les informaticiens qui utilisent aujourd'hui des systèmes informatiques n'ont généralement pas reçu de formation correspondante lors de leurs études, mais ce n'est pas une raison pour prôner un statu quo! Par ailleurs, il est peu efficace, d'inscrire au programme de première année une formation dont il ne restera sans doute que quelques souvenirs émus, lorsque dans 5 ou 6 ans, ces étudiant(e)s entreront dans la pratique professionnelle. D'autre part, l'important laps de temps qui sépare le moment où le cours est dispensé du moment où il deviendrait utile dans la vie professionnelle plaide, lui aussi, pour une formation qui place l'accent sur les principes et les invariants plutôt que sur les modes et les péripéties et qui mette en avant des grilles d'analyse du paysage informatique plutôt qu'une simple description du paysage actuel. 3.4 L'argument "ça fait aujourd'hui partie d'une culture universitaire de base" C'est un argument fréquemment employé pour les cursus universitaires de premier cycle et qui entraîne et explique le caractère "généraliste" de ceux-ci. L'informatique s'est taillée une place à part entière au sein de l'université : il y a un Institut ou un Département d'informatique à côté de ceux, plus anciens, dédiés aux mathématiques, à la chimie ou à la biologie. Ces départements en prennent bonne note en faisant une petite place à la discipline du nouveau venu. 3.5 L'argument "c'est formateur" Il est similaire à celui qui reconnaît un caractère formateur (dès l'enseignement secondaire d'ailleurs) à la pratique des mathématiques ou de la physique. Cet argument se teinte d'ailleurs fort souvent d'un certain caractère préventif ou défensif : "même si ça vous paraît inutile, peu importe puisque c'est formateur". La pratique de l'informatique aurait les mêmes vertus formatrices, ce qui dispenserait d'interroger davantage son utilité en premier cycle. - Je suis fort sensible à cette relativisation du critère d'utilité immédiate. C'est vrai que notre formation, nos habiletés cognitives, nos capacités à résoudre des problèmes, ARTFRIB.DOC 28 novembre

4 résultent d'une mystérieuse alchimie et transcendent en quelque sorte les matières à travers lesquelles nous les avons développées 5. - Cet argument s'appliquait particulièrement à un cours qui faisait une large place à la programmation, non pour son utilité immédiate ou future (peu de biologistes ou de pharmaciens auront à programmer) mais pour son caractère formateur. J'ai développé ailleurs cette thèse [Duchâteau 90] que d'autres avaient défendue avant moi [Arsac 80]. L'argument est sérieux, même si d'autres ont montré que c'est au bout d'une exposition suffisante à la pratique de l'algorithmique et de la programmation que les effets formateurs (et transférables) se font sentir [Romainville 88]. Malheureusement l'argument est bancal dès lors qu'on demande de chasser de ce cours d'informatique pour utilisateurs la partie algorithmique qui en était redevable. A ces arguments évoqués par les décisions académiques, j'en ajouterais personnellement un autre : 3.6 L'argument "l'informatique réveille de vieux problèmes" Comme je vais tenter de le montrer, un certain enseignement de l'informatique permet de rencontrer immédiatement, de manière simple et opérationnelle, des questions centrales à d'autres disciplines. "Information" et "connaissance" ou "forme" et "sens" sont aussi au coeur de la linguistique même si l'on y parle plus volontiers de "signifiant" et "signifié". Les efforts et les débats de la sémiologie sont aussi, sans conteste, au coeur de l'informatique, comme les problèmes philosophiques posés par l'intelligence des machines (?). S'il est pour moi une raison essentielle d'enseigner l'informatique c'est celle-là : elle réveille et jette son éclairage spécifique sur des problèmes vieux comme l'humanité : qu'appelonsnous "sens", "intelligence" ou "conscience" [Hofstadter 87]? qu'est ce que "nommer" [Arsac 87]? qu'est-ce qu'un "signe"?... Je vous laisse le soin de conclure si ces divers arguments justifient une place faite à l'enseignement de l'informatique au sein de certains cursus universitaires. La réponse dépend d'ailleurs sans doute de manière cruciale de ce que recouvre les termes "enseignement de l'informatique" et c'est à la définition de ce que pourrait être cet enseignement que je consacrerai la seconde partie de cette contribution. 4 Le changement d'exigences des disciplines utilisatrices Deux changements sont à signaler depuis l'instauration, en 1983, des cours mentionnés : - Dans un premier temps, le cours d'informatique à destination des biologistes, géographes et géologues était un cours à option de fin du second cycle (4ème année du cursus universitaire). C'est probablement des contraintes locales qui ont entraîné son déplacement à la fin du premier cycle et son caractère obligatoire. Certains des arguments mentionnés plus haut ont également été mis en avant pour le déplacement du cours vers le premier cycle et son caractère obligatoire : préparation de cours de 2ème cycle, composante d'une formation scientifique de base,... - Le changement le plus notable concerne le "cahier des charges" du cours, la définition du contenu souhaité par les départements concernés. Après la période du début du "tout algorithmique" (sur laquelle je ne reviendrai pas : les stratégies sont là bien connues et j'ai développé ailleurs quelques choix méthodologiques sous-jacents [Duchâteau 90]), on m'a suggéré un contenu plus utile, qui fasse une plus large part aux préoccupations des utilisateurs, qui mette les étudiant(e)s "à l'aise" face aux ordinateurs, tout en gardant les exigences d'une formation universitaire,... bref, de passer de l'enseignement d'une "informatique des informaticiens" à celui d'une "informatique des utilisateurs". Ce changement est révélateur : il est vrai qu'on peut tracer une histoire de l'informatique en la scandant par les générations successives des ordinateurs, mais l'essentiel est sans doute ailleurs. L'évolution conduit, me semble-t-il, à distinguer 2 périodes, l'événement marquant la 5 Cf. la "pédagogie des vidanges perdues" dans [Duchâteau 92 b]. ARTFRIB.DOC 28 novembre

5 césure, au milieu des années 80, étant l'apparition du concept d'utilisateur (corollaire de l'apparition des "outils logiciels"). La première période, celle de l'informatique "des informaticiens", voyait essentiellement dans l'ordinateur une machine qu'il fallait programmer; la seconde, celle de l'informatique "des utilisateurs", fait passer l'ordinateur au second plan, pour lui substituer la profusion d'instruments logiciels que nous connaissons et qui a donné naissance à ce concept d'utilisateur naïf. (Cf. l'analyse des phases d'automatisation et d'informatisation dans [Van Weert 94] ). Les parfums de mystère, de respect (le centre de calcul, sanctuaire), de castes (l'informaticien, "grand prêtre") ont fait place aux arguments de simplicité ("Cinq minutes et vous êtes dans le coup"), de convivialité, d'efficacité,... Plusieurs ont montré la fausseté, ou à tout le moins, l'exagération de ces arguments (souvent commerciaux). Ils posent en tout cas de manière cruciale la question de l'existence de cette "informatique des utilisateurs". Si la difficulté essentielle de l'utilisation est de trouver l'interrupteur, si c'est "plus simple que de conduire une voiture", que pouvons-nous enseigner qui ne soit pas un mode d'emploi et une série de savoir faire ad-hoc? Si, par contre, des traits fondamentaux, des principes essentiels, émergent de la multiplicité des instruments logiciels et des environnements informatisés, alors, ce sont ces principes organisateurs qu'il nous faut enseigner. 5 Méthodologie Comme fort souvent, au delà des contenus enseignés et qui sont, somme toute, assez classiques, c'est l'organisation de ces contenus et la méthodologie utilisée pour leur présentation qui est primordiale. Le cours s'articule donc autour : - De quelques grands principes explicatifs, dont peuvent être déduits, à peu de frais, des conséquences vécues par les utilisateurs. Fréquemment, ces principes prennent la forme de slogans ou de courtes assertions, davantage susceptibles d'imprégner ou de marquer ce que retiendront les étudiant(e)s. Par exemple : "Ne dites plus «informatique», dites «informeatique»", "L'ordinateur n'existe pas", "TOUT ce que fait un ordinateur, il le fait gouverné par un programme", "Programmer, c'est faire faire en différé", "L'informatique n'est pas plus la science des ordinateurs que la météorologie n'est celle des thermomètres", "Le critère du copain portugais",... - De quelques questions simples, mais dont le traitement va conduire à déduire des réalités importantes. Par exemple : "d'où viennent finalement les programmes présents dans la mémoire centrale de mon ordinateur et qui vont le faire travailler?", "que faut-il pour qu'une information, quelle que soit la forme sous laquelle elle se présente, puisse être traitable par l'ordinateur?", "qu'est ce que l'ordinateur envoie à l'imprimante?",... - De fils conducteurs qui vont permettre une présentation cohérente d'aspects essentiels. Ainsi, par exemple, une grosse partie du cours développe et précise une "définition" préalable (partielle et partiale) de ce qu'est un ordinateur : "machine, à traiter des informations, de manière formaliste, et pour autant qu'on lui ait indiqué comment mener à bien ce traitement". Par ailleurs, l'évolution des langages de programmation, du langage machine aux langages évolués, est, par exemple, examinée selon un triple point de vue, qui sert de fil conducteur : "Comment désigne-t-on les données à traiter? Quelles sont les actions permises et comment les désigne-t-on? Comment organise-t-on ces actions?". - De raisonnements déductifs qui sur base de principes énoncés et provoqués par des questions vont conduire à des conclusions intéressantes. Ainsi, ARTFRIB.DOC 28 novembre

6 Principe TOUT ce que fait un ordinateur, il le fait gouverné par un programme Constatation Dès son branchement, l'ordinateur "fait des choses" Conclusion Un programme fait agir l'ordinateur dès le début Principe Pour qu'un programme puisse faire agir l'ordinateur il doit être en mémoire centrale Conclusion Ce programme doit rester en mémoire centrale et y persister même lorsque l'ordinateur n'est pas branché Conclusion Une zone de la mémoire centrale doit garder les informations qui y sont contenues même sans alimentation électrique Conclusion Il existe de la mémoire morte Schéma 1 D'autres raisonnements déductifs du même genre conduisent, par exemple, à la conclusion que quel que soit le logiciel utilisé, il a dû commencer, quel que soit le chemin qui l'a conduit dans la mémoire vive de mon ordinateur, par exister comme programme exécutable dans la mémoire vive d'un ordinateur avec comme "source initiale" le clavier de cet ordinateur. C'est évidemment alors le moment de parler des possibilités de fournir à travers le clavier un "programme" à l'ordinateur, et d'évoquer l'existence des langages de programmation et des compilateurs associés. ARTFRIB.DOC 28 novembre

7 6 Le contenu Je ne peux évidemment ici développer complètement les contenus abordés. Je vais cependant tenter de mettre en avant les facettes essentielles en montrant comment la méthodologie décrite est mise en oeuvre. Comme signalé ci-dessus, c'est une pseudo-définition de l'ordinateur, qui sert de fil conducteur aux premiers chapitres, l'ordre dans lequel les constituants de cette définition sont abordés étant fort important : 6.1 "traiter des informations" Sur base d'un relevé de situations de "traitement d'information", l'essentiel est de déboucher sur le schéma bien connu et qui constituera l'un des fils conducteurs : Informations reçues (Entrées) Traitements Informations rendues (Sorties) Informations consultées Schéma 2 Il est important également de procéder à un relevé des sens possibles du verbe "traiter" dans ce contexte : transformer, communiquer, modifier, "de manière formaliste" Le caractère formaliste des traitements permis par l'ordinateur (les seuls auxquels l'informatique peut s'atteler) est le fondement même du cours. Un classement d'exemples est opéré pour conduire dans un premier temps à remplir et construire un tableau : Traitements portant sur des nombres Traitements portant sur le langage Autres - Traitement formel ou aisément formalisable Traitement difficilement (non!) formalisable (Sens, signification,...) Schéma 3 Un critère "opérationnel" est proposé pour classer les traitements d'information sur un continuum : Très facilement formalisable Très difficilement (non!) formalisable additionner conjuguer dériver Résumer Ecrire une dissertation Schéma 4 ARTFRIB.DOC 28 novembre

8 le "critère du copain portugais" : la difficulté plus ou moins grande d'expliquer à cet ami des traitements divers, y compris sur des textes en français (qu'il ne peut donc "comprendre"), permet de mesurer la difficulté de "formaliser" ces traitements. L'application de ce critère à la conjugaison française d'une part (ou des indications formalistes de traitement -donc un programme- sont possibles), à la synthèse d'un texte français d'autre part (où aucune indication formaliste valable ne semble envisageable) conduit à éclairer les termes formel, formalisable, formalisé,... Sur la lancée, une définition de l'informatique est proposée (sous forme de slogan) : "l'informatique est l'entreprise consistant à faire reculer vers la droite, dans le tableau présenté, la ligne grisée séparant les 2 types de traitement" ou encore "L'objet de l'informatique est de transformer des traitements formalisables en traitements formalisés". C'est dans ce chapitre que, d'emblée, on va se heurter au problème de l'intelligence nécessaire pour mener à bien ces traitements, puisqu'on est tenter de surcharger le schéma : Très facilement formalisable Très difficilement (non!) formalisable Bête, réflexe, inconscient imbécile, stupide Intelligent, sophistiqué raison, entendement abstraction, intuition pensée Schéma 5 On aura compris que c'est seulement le squelette de la démarche envisagée au sein du cours qui est proposée ici : plusieurs heures sont en réalité consacrée à ces notions centrales : formalisable, formalisé. Un slogan résume alors l'ensemble de la démarche "Ne dites plus «informatique», dites «informeatique»!". 6.3 "des informations" C'est une question, évoquée ci-dessus, qui sert ici de point de départ, la réponse fournissant un fil conducteur à ce nouveau chapitre : Pour qu'une information (ou un ensemble d'informations) soit acceptable par l'ordinateur il faut que nous puissions la représenter, la coder, par une série finie de nombres entiers. Après un examen de ce concept de codage, on peut passer en revue diverses informations en tentant de proposer à chaque fois un mode de représentation sous la forme d'une série finie d'entiers. On va donc ainsi déboucher sur le codage des textes (codes ASCII, ANSI,...), des nombres réels (virgule flottante), des images (représentations bitmap et vectorisées), des sons (échantillonnage et convertisseur analogique/numérique),... ce codage étant chaque fois soutenu et motivé par le principe énoncé. On prépare de cette manière aussi bien la compréhension du rôle des périphériques d'entrée (codage) ou de sortie (décodage), que la constatation du fait que l'ordinateur, quoi qu'il paraisse faire, calcule, que le classement des logiciels de dessin (bitmap ou vectoriel), etc.; c'est aussi le moment d'expliquer la difficulté et les enjeux de la reconnaissance optique des caractères et de la reconnaissance de la parole. Les processus de discrétisation qui sont à l'oeuvre dans ce "codage en nombres entiers" exigé par l'ordinateur sont bien entendu abordés, tout le chapitre culminant dans une constatation finale, longuement développée : "Nous passons d'une civilisation de l'analogique à une civilisation du numérique, et l'ordinateur est l'un des moteurs de cette transition". Il est inutile à ce stade (puisque la machine ordinateur et son alphabet binaire n'a pas ARTFRIB.DOC 28 novembre

9 encore été abordée) de se perdre dans les méandres du codage binaire en insistant sur des aspects somme toute anecdotiques : il suffit d'avoir saisi que "pour l'ordinateur, tout est nombre" (peu importe ici la manière dont ces nombres sont codés au sein de la machine). A nouveau, je ne puis donner qu'une idée décharnée du contenu de ce chapitre; j'espère avoir rendu perceptible le fil conducteur et l'unique question qui, appliquée à des informations de formes très diverses, conduit à un large périple dans le monde de la numérisation. 6.4 "pour autant qu'on lui ait indiqué comment mener à bien ce traitement" (1) Si le point de vue adopté est celui de l'utilisateur d'un système informatique, cette facette se décline en deux slogans : TOUT ce que fait un ordinateur il le fait, gouverné par un programme (= des indications de traitement). ou encore L'ordinateur n'existe pas L'essentiel, on l'aura compris, est de prévenir l'utilisateur de ce que, à tout moment, son interlocuteur est non "l'ordinateur" mais un couple "ordinateur - indications de traitement (programme, logiciel)" et que, dès lors, un ordinateur "nu", n'existe pas. Il est indispensable d'avoir saisi qu'au cours d'une même session de travail, si la machine reste ce qu'elle est, le second partenaire du couple, le programme, change plusieurs fois, parfois subrepticement. Ces constatations ont des corollaires importants. Ainsi, il est impossible de dresser une liste des manipulations "de base" de l'ordinateur, comme il est impossible de citer une touche du clavier dont la frappe, en toutes circonstances, ait toujours le même effet. 6 "Dans l'utilisation d'un système informatique 7, rien n'est toujours valable" (autre slogan). D'autres conséquences seront, le moment venu, tirées de ces principes : la nécessité d'un programme d'amorçage en mémoire morte, le rôle du système d'exploitation dans le chargement en mémoire vive des applications,... Il est important, à côté du point de vue de l'utilisateur, qui n'utilisera jamais qu'un ordinateur déjà muni des indications de traitement nécessaires, de présenter l'autre point de vue, celui du programmeur, à qui incombe la tâche d'imaginer et de fournir ces indications de traitement. Le point de vue, dans ce cas change complètement : ce que le programmeur a en face de lui c'est non pas un outil à maîtriser mais un exécutant à commander, exécutant à qui il faut fournir une marche à suivre, pour lui faire faire, en différé, les traitements souhaités. On s'en doutait, la courte phrase "pour autant qu'on lui ait indiqué comment mener à bien ce traitement" cache tout l'univers de la programmation, celui du "faire faire en différé". Une question reste évidemment en suspens :pas plus que l'utilisateur, le programmeur n'a en face de lui un exécutant qui soit l'ordinateur "nu" (qui n'existe jamais). Quel est dès lors, dans le cas de la programmation, la partie "logicielle" de l'interlocuteur du programmeur? Ces questions et d'autres abordées dans ce chapitre seront reprises, une fois le chapitre sur l'architecture clôturé. 6.5 "machine" La question conductrice est ici "comment le Schéma 2, qui préside à tout traitement d'informations, s'incarne-t-il dans une réalisation matérielle (l'ordinateur)?". Le schéma classique : 6 7 Bien évidemment, c'est peu à peu au fil des utilisations d'un système informatique, que l'utilisateur intégrera ces réalités importantes. Il est essentiel, cependant, de l'en prévenir et de préparer cette constatation. Le terme est employé à dessein et remplace avantageusement celui d'ordinateur, à cause des réflexions proposées ici. ARTFRIB.DOC 28 novembre

10 Périphériques d'entrée (Entrées) Données à traiter Unité centrale + Indications de traitement Périphériques de sortie (Sorties) Mémoires externes Schéma 6 peut alors être présenté, en insistant sur les 2 choses qui vont "nourrir" l'ordinateur : les informations (données) et les indications de traitement (programmes). Etant donné ce qui a été dit à propos du codage, la définition des périphériques d'entrée est immédiate : ce sont des dispositifs qui transforment des informations, sous une forme qui nous est habituelle, en une suite finie de nombres entiers, et cela automatisant au maximum le processus (et en en déchargeant dès lors l'utilisateur). La définition duale est aussi donnée pour les périphériques de sortie. On peut alors passer en revue divers périphériques d'entrée : clavier, souris, scanner, micro + convertisseur analogique / numérique,... et de sortie : écran, imprimante,... en insistant sur ce rôle de codage ou décodage. Vient ensuite une présentation de l'unité centrale en mettant en avant le fait que la mémoire centrale contient des programmes exécutables et des données (codées en nombres entiers) sur lesquelles ces programmes font agir le processeur. C'est le moment de fournir, tant en ce qui concerne la mémoire que le processeur, divers paramètres d'évaluation (et les unités qui les accompagnent) et d'aborder (sans détails techniques superflus) les principes de fonctionnement. Le jargon habituel doit également être rencontré : bit, octet, codage binaire,... Cette partie est, somme toute, fort classique, même si on n'y perd pas une occasion d'illustrer à nouveau les principes précédemment énoncés (comme le caractère très formaliste de l'unité de mesure de quantité d'informations : on compte en caractères!). 7 Et la suite Le cours ne s'arrête évidemment pas là : un chapitre (déjà évoqué) aborde l'évolution des langages de programmation et tente d'illustrer les difficultés essentielles de cette activité. (Cf [Duchâteau 90]). Un chapitre est consacré à l'historique de l'informatique et, essentiellement de la microinformatique, avec là aussi des fils conducteurs explicites et une explication du présent à la lumière du passé récent. (Cf [Duchâteau 92b] pour une idée). Le logiciel (système d'exploitation, logiciel d'application) est abordé en mettant en avant l'évolution des interfaces utilisateur de ces instruments,... 8 Conclusions Il serait lassant de poursuivre. J'espère avoir illustré l'esprit dans lequel le cours est construit et la démarche mise en oeuvre. J'espère avoir répondu aussi, partiellement du moins, à la question de la définition de ce que seraient quelques principes sous-jacents à une informatique des utilisateurs. Peut-être la quête des ces principes organisateurs est-elle une utopie? Peut-être les savoir et les représentations correspondant aux savoir faire que les utilisateurs exigent ne peuvent-ils être vraiment acquis qu'à travers les utilisations d'environnement informatisés [Duchâteau 94]? En tout cas, beaucoup d'enseignants des premiers cycles universitaires sont aux prises avec les mêmes difficultés de contenus et de démarches j'ai tenté ici d'apporter une pierre à la réflexion commune. Cette dernière reste plus que jamais nécessaire. ARTFRIB.DOC 28 novembre

11 9 Bibliographie [Arsac 80] ARSAC J. Premières leçons de programmation. Cedic / Nathan, Paris, [Arsac 87] ARSAC J. Les machines à penser. Des ordinateurs et des hommes. Editions du Seuil, Paris, [Arsac 91] ARSAC J. Préceptes pour programmer Dunod, Paris, [Baron 89] BARON G-L. L'informatique discipline scolaire? Le cas des lycées. Presses Universitaires de France, Paris, [Duchâteau 90] DUCHATEAU C. Images pour programmer. Apprendre les concepts de base. De Boeck-Wesmael, Bruxelles, [Duchâteau 92 a] DUCHATEAU C. Comment définir une "culture informatique"? in JRI-Journal de Réflexion sur l'informatique. n 23, 23/24, octobre 1992 FNDP-Institut d'informatique., Namur, 1992, pp [Duchâteau 92 b] DUCHATEAU C. L'ordinateur et l'école! Un mariage difficile? CEFIS, Facultés N-D de la Paix, Namur, [Duchâteau 94] DUCHATEAU C. Faut-il enseigner l'informatique à ses utilisateurs? in Actes de la quatrième rencontre francophone de didactique de l'informatique. Québec, avril 94. AQUOPS, Montréal, [Hofstatdter 87] HOFSTADTER D., DENNETT D. (EDIT). Vues de l'esprit. Fantaisies et réflexions sur l'être et l'âme. InterEditions, Paris, [Romainville 88] ROMAINVILLE M. Une analyse critique de l'initiation à l'informatique : quels apprentissages et quels transferts? in Actes du colloque francophone sur la didactique de l'informatique. Université René Descartes, Paris, 1, 2, 3 septembre Editions de l'epi, Paris, 1989, pp [Van Weert 94] VAN WEERT T., TINSLEY D. (EDRS). Informatics for Secondary Education. A Curriculum for Schools. Produced by a working party of the IFIP Working Group 3.1. Unesco, Paris, ARTFRIB.DOC 28 novembre

12 Charles DUCHÂTEAU CeFIS, Facultés N-D. de la Paix rue de Bruxelles, 61 B-5000 NAMUR Tél Fax cduchateau@cc.fundp.ac.be ARTFRIB.DOC 28 novembre