Après avoir proposé, dans un billet précédent, un rapide aperçu de deux positions qui me semblent caractéristiques du débat sur le sujet, venons-en à notre propos.
Les mauvaises raisons pour apprendre l’informatique aux enfants
Éliminons d’abord les arguments censés justifier l’apprentissage du code mais qui se révèlent spécieux :
- Premier argument spécieux (qu’on trouve par exemple ici) : il faut apprendre à coder pour ne plus être passif sur internet (et face au numérique en général), pour pouvoir exprimer sa créativité.
Certes, l’écriture de programmes est un moyen de se montrer créatif, mais elle est loin d’être la seule, on peut aussi créer des vidéos, faire des photos, du dessin, de la musique, écrire des textes… pour ne citer que les activités les plus évidentes. Et, il faut le préciser, ces activités, même si elle se font avec un ordinateur, ne nécessitent en rien de savoir programmer. Bien plus, cette volonté hégémonique du code de s’arroger en seul espoir de créativité numérique tend à entretenir une confusion assez répandue dans le grand public au sujet de l’informatique : toute personne qui travaille avec un ordinateur devient « informaticien » et se trouve du même coup capable de répondre à n’importe quelle question liée au numérique (choix d’un appareil photo numérique, utilisation de tel ou tel logiciel, configuration de tel périphérique, voire réparation de matériel défectueux…). Cette confusion disparaît peu à peu, puisque de plus en plus de personnes utilisent un ordinateur à titre professionnel et se rendent compte qu’elles ne sont pas devenues informaticien pour autant ; il me semble que la moindre des choses est que ce ne soient pas les informaticiens eux-mêmes qui contribuent à la faire persister (à moins que ce ne soit pour préserver leur aura de toute-puissance 😉 ).
- Second argument spécieux (défendu ici par exemple) : il faut former des informaticiens, parce que la France en manque.
Quelle que soit la validité de ce constat (et certains le contestent), l’enseignement du code dès le collège, voire l’école primaire, ne peut pas être une solution, il n’est pas sensé de vouloir répondre aux problèmes du marché de l’emploi d’aujourd’hui avec des personnes qui n’entreront dans la vie active que dans 10 ou 15 ans. Surtout, il est absurde de lancer un programme d’éducation généralisé pour répondre aux besoins d’un seul secteur : peut-on justifier de former tous les jeunes à un métier pour n’en conserver qu’une toute petite minorité (parce que même si beaucoup d’emplois sont à pourvoir dans ce domaine, il n’y aura pas des millions de postes créés pour accueillir tous les enfants de France qu’on aura convaincus de devenir développeurs) ? J’ai entendu une variante de cet argument à la radio au sujet des data analysts qui manquent en France : la formation pour posséder les compétences requises pour exercer ce métier est longue, il n’est donc pas possible de reconvertir des professionnels d’un secteur proche, mais il faut commencer à former les jeunes très tôt… On croit rêver ! Dans le même ordre d’idées, j’ai une proposition : il est connu que les zones rurales de France manquent de médecins, je propose donc d’initier les enfants de ces régions à la médecine dès la maternelle, pour résoudre ce problème au plus tôt.
- Troisième argument spécieux, auquel je n’avais pas pensé tout de suite : il faut former les élèves au code pour renouveler la pédagogie.
Cet argument est évoqué (et contesté) par Hubert Guillaud dans un article sur le site Internet Actu. J’avoue que cet argument me semble tellement saugrenu que je n’y avais pas pensé, mais, à la lumière de l’article d’Hubert Guillaud, j’ai reconsidéré certaines positions exprimées ici ou là qui en relèvent probablement. Cet argument résulte purement et simplement d’une confusion qui vient probablement de l’exemple d’écoles comme 42 ou web@cadémie. En effet, ces établissements proposent de former des développeurs en utilisant des pédagogies innovantes : travail de groupe, projets, enseignants jouant un rôle de tuteurs et non de transmetteurs de savoir etc. Par une confusion assez naturelle entre le fond et la forme, certains observateurs sont amenés à proposer ce modèle pour l’école publique, en apportant l’eau du bain avec le bébé, si j’ose dire. Autrement dit, puisque ces écoles enseignent efficacement le code (contenu) avec des pédagogies actives (méthode), il faut enseigner le code avec des pédagogies actives dans l’enseignement scolaire. On voit bien ce que cette confusion a de ridicule : s’il est probablement justifié de s’inspirer des méthodes de ces écoles pour d’autres enseignements, cela ne veut évidemment pas dire qu’il faut en même temps importer le contenu enseigné.
Pourquoi il faut apprendre l’informatique
Je voudrais raconter quelques anecdotes pour illustrer pourquoi, selon moi, il est nécessaire que tout le monde soit formé à l’informatique.
Communiquer à propos du numérique
Une utilisation évidente d’une meilleure connaissance de ce qui concerne l’informatique serait simplement la communication au sujet de l’informatique… Ainsi je constate que l’usage de mots dans un sens vague (voir à contresens), usage qu’affectionne particulièrement le marketing, induit une sorte de fluidité, de labilité du sens. Par exemple, il est toujours amusant de voir des gens parler d’applications en hésitant sur les mots : « logiciel, application, programme… » alors que ces termes sont peu ou prou synonymes dans beaucoup de cas. « Ce que l’on conçoit bien s’énonce clairement » et réciproquement…
Il y a des exemples plus pernicieux : on parle depuis quelques années de « cloud computing ». Cette logique consiste à distribuer dynamiquement des ressources informatiques entre différents matériels : ces ressources peuvent être de la puissance de calcul, de la mémoire vive, de l’espace de stockage, de la bande passante etc. L’avantage est qu’ainsi l’utilisation des ressources peut être optimisé selon les besoins particuliers d’un certain moment. L’exemple fréquent de ce type d’usage est celui des sites de grandes compétitions sportives, qui sont assez peu consultés en temps normal, mais sont au contraire extrêmement sollicités pendant le déroulement de ces manifestations et en particulier pendant leurs temps forts. Une architecture traditionnelle obligerait soit à avoir de très gros serveurs et une grande bande passante pour faire face à la demande des pics d’affluence, et qui resteraient très sous-utilisés en temps normal, soit avoir des serveurs proportionnés à l’activité majoritaire de l’année et qui s’effondreraient pendant les périodes de pics. Le cloud computing permet de mobiliser automatiquement les ressources nécessaires pour faire face aux pics, tout en utilisant ces ressources pour un autre usage le reste du temps (par exemple pour héberger les sites d’autres compétitions sportives dont les temps forts sont à un autre moment). Le terme « cloud » signifie que le serveur qui héberge (dans notre exemple) n’est pas une machine physiquement identifiable, mais que ce peut être plusieurs machines, si nécessaire, dispersées sur internet, souvent représenté sous la forme d’un nuage (sans doute pour montrer qu’il n’existe pas de routes prédéfinies sur internet et que les données suivent un cheminement qui reste opaque à l’utilisateur).
Or, peu après le début du cloud computing, certains ont commencé à parler de données « in the cloud » comme synonyme de « online », c’est-à-dire de données sur internet, même si elles étaient stockées précisément sur un serveur physique bien défini et donc absolument pas dans le nuage. On voit bien à qui cela peut profiter : des commerciaux peu scrupuleux profitent de la vague du cloud computing et de son côté « tendance » pour vendre leur produit, même s’il n’y a aucun rapport objectif. En se généralisant, cette approximation entre dans le langage courant, et l’expression perd de son sens, rendant la communication plus difficile. (Et je ne parle même pas du fait que 51% des Américains croient que la météo affectent le fonctionnement du cloud computing)
Une initiation à quelques notions de base du fonctionnement de l’informatique éviterait ces incompréhensions.
Et cette question se pose de façon encore plus quotidienne : par exemple, quand un organisme quelconque (public ou privé) a besoin de faire appel à un prestataire informatique : réalisation d’un site web, développement d’une application… L’imprécision du vocabulaire pour décrire ne serait-ce que l’interface attendue amène parfois à des incompréhensions improductives.
Mais il est un domaine où ces incompréhensions sont encore beaucoup plus préjudiciables : les questions liées à l’assistance à l’utilisateur. Je donnais l’exemple de la voiture dans mon premier billet sur ce sujet et en y réflechissant davantage, cette analogie me semble plus intéressante que je ne l’avais cru d’abord. Lorsque ma voiture est en panne, je peux aller voir un garagiste et lui expliquer mon problème. N’importe quel automobiliste est capable de décrire son problème assez précisément et en particulier sans se tromper sur les éléments de l’interface utilisateur du véhicule : personne n’appelle ‘pédale’ le levier de vitesse ou ‘volant’ le frein à main. Pourtant, dans la pratique, on pourrait se passer de ces informations : je pourrais montrer une pédale en disant « quand j’appuie ici et qu’en même temps je bouge ça », en montrant le levier de vitesses, « il se passe ceci ou cela ». Je n’ai jamais rencontré de situation où je n’étais pas avec le garagiste auprès de la voiture. Bien sûr, je ne comprends toujours rien à ce qui se passe sous le capot de ma voiture : quand, après avoir changé l’embrayage, un mécanicien m’a expliqué que les dégâts étaient plus importants que prévu et qu’il avait dû démonter le volant moteur, j’ai pris l’air étonné et vaguement consterné qu’il semblait attendre, mais je n’ai aucune idée de ce que peut être ce volant et, à vrai dire, je n’en ai cure…
Revenons à notre sujet : d’après l’Observatoire du numérique, 49% des salariés utilisent régulièrement internet dans leur travail et 66% des particuliers l’utilisent fréquemment (tous les jours ou presque). Et cela ne prend pas en compte, naturellement, tous ceux qui utilisent un ordinateur sans accéder à internet. Parmi eux, je ne pense pas exagérer en disant, que ceux qui peuvent faire directement appel à un technicien à qui ils peuvent montrer leur problème sans avoir le décrire, sont un petit groupe de privilégiés. Beaucoup vont avoir à se faire assister à distance, par courriel ou par téléphone. Or il est toujours étonnant de voir la difficulté de beaucoup à décrire le problème qu’ils rencontrent : on ne peut pas savoir quelle est la réalité que recouvre le terme « onglet » ou « bouton », quand ils ne se contentent pas de dire « ça ne marche pas ». Du coup les plateformes d’assistance, adoptent un protocole très contraignant et abêtissant, qui présuppose d’emblée que toute information apportée spontanément par le demandeur est nulle et non avenue. Je suis sûr que vous voyez de quoi je parle : le technicien, à qui vous venez d’expliquer que vous avez redémarré trois fois votre box sans résultat, qui vous annonce : « Tout d’abord, nous allons essayer de redémarrer votre box »… Si les utilisateurs d’informatique (c’est-à-dire tout le monde) étaient capables de désigner les éléments d’une interface graphique, que de temps gagné dans l’univers ! que de frustration évitée !
Ce qui manque : des notions de base pour comprendre et donc décrire les aspects les plus superficiels du fonctionnement d’un programme informatique et son interface.
Pour savoir communiquer avec un ordinateur
Il y a quelques années, une de mes missions consistait à créer des comptes sur un ENT pour les élèves de collèges des Pyrénées-Atlantiques. Naturellement, j’avais écrit un petit programme qui, à partir d’un fichier de tableur, générait l’identifiant de l’élève sur l’ENT, puis créait son compte, et l’inscrivait dans un groupe qui correspondait à sa classe. Les établissements devaient donc me fournir un fichier de tableur, organisé selon quelques colonnes, avec un élève par ligne :
Classe, nom, prénom
Mon programme lisait ces fichiers, ligne par ligne, générait, à chaque ligne, l’identifiant de l’élève (par exemple en prenant la première lettre du prénom et les 8 première lettres du nom), créait le compte, ajoutait l’élève au groupe déterminé par sa classe.
Or beaucoup d’établissements me transmettaient des fichiers qui ne respectaient pas ce modèle. Par exemple, leur fichier comportait une première ligne qui ne comprenait que la classe, suivi de la liste des 30 élèves de cette classe, sans mentionner leur classe, puis une ligne correspondant à la classe suivante etc. Ou alors, ils m’envoyaient un fichier dans lequel les prénoms et les noms étaient dans une même cellule.
En somme, ces fichiers étaient parfaitement compréhensibles pour un humain, mais inutilisables pour un ordinateur. Heureusement, je servais d’interface entre les personnes qui créaient ces fichiers et la machine, et je disposais des outils pour régler ces problèmes. Si cette interface n’avait pas existé, ces utilisateurs auraient été confrontés à des messages d’erreur ou des fonctionnements imprévus, sans forcément comprendre d’où venait le problème.
Ce qui leur manquait était la connaissance de base pour pouvoir se faire comprendre d’un ordinateur : structurer ses données.
Un autre exemple : presque personne n’utilise les styles dans un traitement de textes. Cela me frappe particulièrement avec les stagiaires avec lesquels je suis amené à travailler. Un étudiant de 2014 a pourtant déjà eu l’occasion de produire souvent des documents numériques relativement longs : dossiers de TPE au lycée, mémoires, notes et travaux de recherche variés, rapports de stages… Les styles sont pourtant extrêmement utiles pour produire un tel document : ils permettent d’avoir une vision du plan d’un document, d’en manipuler le plan sans avoir à se préoccuper du contenu des différentes parties, de générer automatiquement un sommaire, d’uniformiser la présentation (et la modifier rapidement) etc. Qu’une personne de mon âge ne connaisse pas cette fonction, cela peut se concevoir, puisque nous n’avons jamais appris à utiliser ce genre d’outils, mais qu’un jeune, qui a le B2i (l’utilisation des styles dans un traitement de textes fait pourtant partie des items de ce brevet), ne l’utilise pas, cela dépasse mon entendement…
Ce qui manque à ces utilisateurs de traitements de texte est encore une connaissance de base (à peu près la même que dans l’exemple précédent) : savoir structurer ses données sémantiquement, c’est-à-dire selon leur sens, pour qu’un ordinateur puisse comprendre ce sens (« cette partie de texte est un titre, cette autre partie est un paragraphe »).
Troisième exemple : dans le cadre de mon activité professionnelle, je suis souvent amené à consulter des feuilles de calcul (Excel en général) créés par différentes personnes. L’avantage d’un tableur est de pouvoir appliquer des traitements variées aux données saisies : calcul, tri, comparaison… Bien souvent, il n’est pas possible d’utiliser ces outils dans ces feuilles de calcul, car les données n’y sont pas représentées de la bonne façon : cellules mélangeant à la fois du texte et des chiffres, ensembles de cellules (ligne et colonnes par exemple) correspondant à des données hétérogènes etc.
Quel est le problème ? Il faut choisir un outil qui correspond aux traitements qu’on a besoin d’appliquer aux données et structurer les données de façon à ce qu’elles puissent être traitées par l’outil choisi. Une présentation tabulaire peut souvent avoir du sens, par exemple pour donner une vision synoptique de plusieurs phénomènes (un exemple presque au hasard où une telle vision synoptique a un sens : tableau synoptique des évangiles) mais l’utilisation d’un tableau ne justifie pas nécessairement celle d’un tableur.
Un dernier exemple, un peu différent, dans cette catégorie : j’ai souvent été amené à parler d’IFTTT à des personnes variées (documentalistes d’établissements scolaires, chargés de communication d’organismes variés etc.). Pour mes lecteurs qui ne le connaitraient pas, IFTTT (pour IF This Then That) est un service en ligne très pratique qui permet de lancer une certaine opération lorsque un certain événement se produit : par exemple, lorsque je publie une image sur Facebook, le service la publie sur Twitter. On le voit, cela n’a rien de « technique », « algorithmique » ou compliqué ; c’est un outil qui peut être utile pour n’importe qui qui est amené à publier des choses sur Internet (et pas seulement à publier, puisque je peux l’appliquer à des opérations « privées » : ajout d’une ligne dans une feuille de calcul Google, d’une note dans Evernote etc.) Je me suis rendu compte que pour beaucoup, l’utilisation de ce service ne paraissait pas intuitive, sauf… pour les développeurs. Pourquoi ? Parce que la notion d’événement leur est familière (je me souviens de mon émerveillement un peu déçu quand j’ai compris que l’algorithme de n’importe quelle interface graphique n’est rien d’autre qu’une boucle sans fin qui attend des actions de l’utilisateur, comme cliquer sur un bouton ou saisir du texte, pour déclencher une opération), de même qu’une structure comme « si… alors… ». Est-ce qu’IFTTT est un outil pour les développeurs ? Pas du tout ! Un développeur pourra facilement écrire quelques lignes de codes qui permettront de faire la même chose en beaucoup mieux !
Lutter contre l’effet magique
C’est entendu, tout le monde utilise le numérique, plus ou moins, d’une façon ou d’une autre. On est souvent étonné par la vision merveilleuse qu’en ont beaucoup d’utilisateurs. Quand je dis « vision merveilleuse », je parle aussi bien d’émerveillement béat que de terreur superstitieuse.
Quelques exemples de comportements de ce genre.
Il y a quelques mois, lors d’une présentation sur l’identité numérique, l’intervenante présentait un des nombreux sites qui permettent de voir les « traces » qu’on laisse sur internet. Une des enseignantes présentes a demandé : « Si je mets mon nom et que mon mari fréquente des sites pornographiques, ça va s’afficher ? » Internet pose des problèmes pour la vie privée, mais s’il suffisait de mettre le nom d’une personne dans un formulaire pour savoir comment elle occupe ses soirées, je crois que ça se saurait…
Ce qu’elle ne savait pas : le fonctionnement élémentaire du web et des transferts de données qu’il permet.
Plus généralement, je constate, chez beaucoup de personnes avec qui je suis en contact au plan professionnel ou personnel, une sorte de résignation, de renoncement : le numérique est une boîte noire et ne peut pas être autre chose. Qu’on n’essaie pas d’entrer dans le détail du fonctionnement d’une application par exemple, c’est normal, mais qu’on renonce à en comprendre le fonctionnement le plus superficiel, c’est une logique qui m’échappe…
Ce qui manque : le désir d’aller comprendre un tout petit peu quelques notions de base des outils que l’on utilise tous les jours.
Autre exemple, assez différent, mais qui entre dans la même logique de compréhension : beaucoup de forums, même ceux qui ne sont en rien des forums de geeks, utilisent pour mettre en forme les messages un petit langage de balisage, souvent spécifique, plus ou moins librement inspiré du HTML ou des ce qu’on appelle parfois la syntaxe wiki. Bien sûr, ces sites proposent une interface permettant de ne pas avoir à ajouter ces balises à la main, mais lors du clic sur un bouton, très souvent, les balises apparaissent dans le texte. La première réaction du néophyte est de se dire en relisant son message : « Tiens des caractères incohérents ont été ajoutés à mon texte, j’ai dû faire une mauvaise manipulation », et de supprimer les caractères en question… Pour les non-néophytes que nous sommes vous et moi, cette réaction semble absurde, mais je l’ai vue de mes propres yeux !
Bien sûr, pour l’utilisateur normal, il est vite évident qu’il ne faut pas les supprimer, mais à cause de l’incompréhension, il arrive souvent qu’une modification du texte déconnectée de la modification adéquate des balises provoque un affichage qui n’est pas celui qu’on veut.
Là encore, le fonctionnement élémentaire d’un langage de balises lèverait facilement ce problème.
A la lumière de toutes ces observations, et de beaucoup d’autres du même ordre, j’en suis venu à considérer qu’il devient nécessaire d’apprendre des notions d’informatique : à la fois quelques rudiments de « science informatique » et quelques notions de base de « technique informatique ». Cela ne recouvre ni l’usage de l’informatique en lui-même (par exemple écrire un texte avec un traitement de textes), ni l’apprentissage de l’écriture de code (on peut écrire du code sans pour autant rien comprendre de plus à ces enjeux et à ces questions de haut niveau). Il faut une « culture générale numérique », comme il faut une « culture générale littéraire » ou une « culture générale scientifique ».
