Ce n’est pas le code qui importe, c’est le modèle

« Non, le code n’est pas la nouvelle littératie« , nous prévient Chris Granger (@ibdknox) dans un article portant ce titre. Pourtant, ce développeur n’appartient pas à la cohorte de ceux qui ne voient dans la programmation qu’un savoir technique qu’il n’est pas nécessaire d’acquérir. Non, pour lui, nous nous trompons d’apprentissage ; ce qui importe ce n’est pas le code, mais ce que ce dernier sous-tend : autrement dit notre capacité à modéliser les phénomènes.

Granger, qui a travaillé sur de nombreux projets (il a été un temps chez Microsoft) a notamment coécrit un éditeur de programme, LightTable, doté de plusieurs fonctionnalités originales. Tout d’abord, nous explique Wired UK, il permet de voir les résultats de son code au fur et à mesure qu’on l’écrit ; une chose qui existe déjà avec des systèmes comme Logo ou Scratch, nous rappelle le magazine, mais pas pour des programmes professionnels impliquant des milliers de lignes de code. LightTable permettrait de surcroît de mettre en relation les différentes parties du code et de visualiser ce dernier de manière à le rendre beaucoup plus compréhensible.

screens

Les quatre phases de la modélisation

Granger commence son article par la définition que donne Google du mot « littératie ». C’est-à-dire « la capacité de lire et d’écrire ». Mais la littératie ne s’arrête pas là, explique-t-il (d’ailleurs pour cette définition, le simple mot beaucoup plus commun, « alphabétisme » conviendrait tout à fait). Lire et écrire ne sont que les actes mécaniques matérialisant deux facultés mentales préexistantes : comprendre et composer. En effet, écrire suppose d’être capable de mettre en forme nos pensées, et lire implique de se montrer en mesure de saisir les pensées d’autrui.

Il en va de même dans le domaine de la programmation. Coder est juste un acte mécanique. Mais de quoi est-ce alors l’expression ? En fait, nous dit Granger, le codage serait l’expression de la modélisation. Nous passons notre vie à élaborer des modèles du monde qui nous entoure, pour les actions les plus simples, comme nouer nos chaussures ou pour comprendre des réalités plus complexes, comme le fonctionnement des systèmes économiques. La science que nous devons donc développer consiste à extraire ces modèles de notre tête pour pouvoir les exprimer sous la forme d’une suite d’instructions compréhensibles par un ordinateur. Il définit l’acte de modéliser comme : « Créer une représentation d’un système (ou d’un processus) susceptible d’être explorée ou utilisée« .

La modélisation s’exécute en quatre phases. La première est la spécification : elle consiste à diviser la tâche en parties que nous comprenons et savons fabriquer. Cela supprime toute ambiguïté dans ledit modèle.

La seconde phase, la validation revient à vérifier que notre modèle correspond à nos attentes ou au monde réel. Ensuite, vient le debugging, autrement dit la correction des erreurs. Voir son modèle échouer, ou être incomplet n’est pas grave, insiste Granger. On commence toujours avec un modèle faux ou incomplet. Par exemple, le modèle du monde des petits enfants est basé exclusivement sur la vue. C’est pourquoi ils sont si inquiets dès qu’ils cessent de voir leurs parents. Pour eux dès qu’ils sortent de leur champ de vision, ils ont disparu. Avec le temps, ils vont améliorer leur modèle du monde. Enfin, reste la dernière étape, l’exploration, but de tout ce travail de modélisation. Nous explorons en remettant tous les constituants d’un système à plat, en les changeant, en remontant le système d’une manière différente, en le copiant, puis en faisant tourner les différentes versions, etc.

Comme on s’en doute, Granger ne pouvait pas ne pas aborder le problème de l’éducation des enfants dans son rapport avec le code, débat qui semble agiter autant les esprits outre-Atlantique que dans nos contrées. Pour lui, c’est donc la modélisation qui doit devenir l’apprentissage fondamental, plutôt que la technique informatique proprement dite : « mettre l’accent sur la modélisation pousse l’éducation vers l’idée que la pédagogie consiste essentiellement à conduire les enfants à délibérément créer et explorer le monde autour d’eux ».

Ce n’est pas une idée totalement nouvelle : nous avons déjà parlé d’expérimentations visant à initier les enfants aux concepts de la programmation sans pour autant leur faire utiliser d’ordinateurs.

Des outils encore trop techniques et mal conçus

Bien entendu, les machines facilitent grandement notre tâche. Pourtant, elles sont encore loin de nous fournir une aide optimale. Lorsqu’ils s’attaquent au codage, les gens passent plus de temps à traduire leurs idées pour qu’elles soient compréhensibles par l’ordinateur qu’à créer et tester véritablement leur modèle. C’est là que la programmation devient un « savoir technique » et non universel. On passe plus de temps à essayer de comprendre le fonctionnement d’une API, à déclarer des variables (sans parler des multiples erreurs causées par la multiplication des accolades, des parenthèses, des points-virgules ou des indentations…) qu’à réfléchir au problème qu’on veut comprendre.

« Nous ne voulons pas d’une génération de personnes forcées de se soucier de l’Unicode ou des librairies d’interface utilisateurs. Nous voulons une génération d’écrivains, de biologistes et de comptables capables de tirer parti des ordinateurs »

.

De surcroît, nos logiciels de développement (éditeurs et débuggeurs) ne sont pas conçus pour favoriser réellement l’élaboration ou l’exploration. Il est très difficile de saisir globalement l’architecture d’un programme : on est obligé d’en comprendre l’ensemble (qui peut aisément comporter plusieurs milliers de lignes) pour appréhender le rôle d’une de ses parties. On a vu que LightTable cherche à pallier une partie de ces défauts.

Il y a bien sûr quelques langages élégants qui ont été conçus pour l’exploration de concepts, rappelle Granger, comme LISP ou Smalltalk. Pourtant, même ces systèmes se heurtent à une autre illusion omniprésente dans la pensée informaticienne : la croyance qu’il peut exister des outils multi-fonctions, capables de tout faire, bref, la croyance en un langage de programmation universel.

Or, lorsque nous créons des objets dans le monde physique, nous avons accès à une multitude de matériaux et d’outils. Mais dans le monde de la programmation, on s’attend à ce que nous nous contentions d’un seul et unique instrument. Pour Granger, il vaut mieux utiliser des dispositifs multiples et spécialisés. Excel en est un exemple parfait. Le tableur est un des plus extraordinaires outils de modélisation à notre portée. Tout ce qui peut être représenté sous la forme de grille de nombres peut l’être par Excel. Mais ce dernier ne travaille que sur un seul matériel : les nombres. Il ne servirait à rien de le transformer pour lui donner toutes les fonctions d’un langage de programmation. Autant le laisser faire parfaitement ce qu’il sait faire. Ce dont nous avons besoin, c’est d’une « glu », un moyen de faire fonctionner ensemble une multitude de systèmes différents. C’est d’ailleurs l’ambition d’Eve, le nouveau programme de Granger, qui ira, nous dit-il, encore plus loin que LightTable et permettra enfin cette démocratisation de l’informatique que nous attendons tous :

« Imaginez un monde où chacun a accès au calcul sans avoir à devenir un programmeur professionnel – où un scientifique n’a pas à se reposer sur la seule personne dans son laboratoire à connaître Python, où un enfant pourrait avoir une idée de jeu et le réaliser en deux week-ends, où votre ordinateur peut vous aider à organiser et planifier votre mariage, vos vacances, vos affaires. Un monde où les programmeurs pourraient se concentrer sur la résolution des problèmes difficiles sans être accablés par la plomberie« . Malheureusement, Eve n’est pas disponible à l’heure actuelle, impossible donc de savoir si ce logiciel tiendra ces promesses.

Mais quand la révolution numérique aura-t-elle vraiment lieu ?

Granger termine son essai en se référant à la célèbre conférence que donna, en 1997, le fameux pionnier de l’informatique Alan Kay, « La révolution numérique n’a toujours pas eu lieu (.pdf)« , et d’appeler, naturellement, de ses voeux une telle révolution.

Mais n’est-il pas déjà trop tard ? Dans son allocution, Alan Kay faisait une large place à Squeak, une version de Smalltalk, contenant un système de programmation interactif, Etoys. Et il est vrai que Squeak était un outil extraordinaire, qui permettait de faire des choses fabuleuses même pour des programmeurs déplorables comme moi. Mais, près de 20 ans après cette conférence, Squeak est resté un outil confidentiel. Smalltalk lui-même date des années 70. LISP, qui favorisait aussi l’exploration, est un des plus vieux langages de programmation, le Fortran seul affichant une plus grande ancienneté.

Il semble malheureusement que la perfection technique et conceptuelle ne suffise pas à briser l’inertie d’un marché ou des habitudes de formation professionnelle. Une pierre de plus sans doute, à ajouter au débat sur la stagnation de l’innovation.

Rémi Sussan

En complément, retrouvez le dossier « L’avenir de la programmation » :

À lire aussi sur internetactu.net

4 commentaires

  1. Je suis impressionné par tous les grands concepts qui sont remués avec beaucoup d’abstraction juste pour parler d’un nouvel IDE (un logiciel pour développer des projets informatiques), sans donner d’exemples concrets. Un enfant qui découvre le monde est une image trop abstraite pour parler de modélisation informatique ! Je trouve d’ailleurs assez paradoxal de défendre une idée de la littératie en utilisant des images que même un informaticien aurait du mal à faire correspondre à des réalités de son métier. Ce n’est certainement pas comme ça que le grand public pourra se faire une bonne idée du fonctionnement des programmes.

    Je suis d’accord sur le fait que le code tout seul ne devrait pas être considéré comme la nouvelle littératie. En fait la question est mal posée car en utilisant le terme « litteracy » on risque d’avoir des débats sémantiques qui n’ont aucun intérêt. Les questions sont :
    – doit-on enseigner le code aux jeunes enfants ?
    – que doit-on enseigner en plus du code, ou à la place du code ?

    Si la réponse est « la modélisation », il faut savoir ce que recouvre ce terme. A la lecture de l’article, Chris Granger semble y mettre :
    – analyse/compréhension des problèmes
    – démarche d’essai/erreur
    – résolution de problèmes

    Du coup, tout le monde est à peu près d’accord avec ça. Ce n’est pas franchement une idée intéressante ni nouvelle. L’idée polémique de Chris Granger c’est qu’apprendre à coder n’est pas un bon moyen pour apprendre à modéliser. C’est déjà plus intéressant, mais finalement il ne dit pas grand chose pour défendre son point de vue.

    De mon point de vue, si on apprend à coder par la pratique, sur des projets de taille suffisante, on peut apprendre du même temps la modélisation sans séparation nette entre le code et les modèles.

  2. L’idéal serait-il, au fond, de pouvoir programmer sans savoir programmer ? Comme le dit Bernard Stiegler : « Grâce aux mécanismes d’automatisation, le codage se fera de plus en plus à travers les machines. »

    Dans cette perspective, il faut bien l’avouer, l’enseignement de l’informatique perd encore un peu plus de sa nécessité.

  3. Pourquoi ne parle t il pas d’écriture d’algorithmes par exemple, qui est plus simple et moins trompeuse que « modèle » qui suppose un niveau d’abstraction important? Or, le BA BA de l’apprentissage ce sont les procédures, que nous mettons en effet en oeuvre dans toute notre vie quotidienne mais que nous ne prenons pas le temps d’écrire évidemment (sauf pour les modes d’emploi , c’était mon métier avant!). Ensuite décrire un monde et l’ensemble des entités et des attributs et leurs états, ça devient en effet quelque peu coton et c’est pour cela qu’il faudrait dire quel niveau de langage on utilise, parce que penser en langage objet, ça permet effectivement d’encapsuler tout un tas d’éléments et de les traiter de façon plus analogue à notre expérience ordinaire. C’est pourquoi ce n’est pas le code mais l’algorithmique qui est importante à apprendre, à plusieurs niveaux, depuis la petite procédure comme lacer ses chaussures avec description de tous les cas jusqu’à un niveau plus vaste d’un workflow où l’on peut dire « attribuer un rôle » sans avoir à préciser cela qu’il faudra avoir les identifiants LDAP, les autorisations requises , etc. ca ce seront en effet les machines (via le langage utilisé plus ou moins compilé) qui prendront en charge le boulot en grande partie. Et quand on a cette tournure d’esprit , on peut malgré tout discuter avec ceux qui développent sans pour autant avor à connaitre le code ( et un langage particulier). Ce qui ferait un lien direct avec la logique et donc avec les maths, qui seraient alors vues comme une formation à la logique et non un apprentissage de théorèmes.

  4. @Dominique Boullier : Votre point de vue est très défendable. C’est d’ailleurs à peu près l’avis des organismes qui promeuvent un changement de l’enseignement de l’informatique en France, comme la Société Informatique de France.

    Je pense pour ma part que cet engouement pour l’enseignement de l’algorithmique « pure » est basé sur trois mythes :

    1. Les langages de programmation changent en permanence.
    C’est faux. Le C est apparu en 1972 et, 43 ans plus tard, il est toujours dans les 3 langages les plus utilisés au monde, sans avoir subit de grosses modifications depuis. Si à ça on ajoute le fait que le C permet d’avoir de bonnes bases pour commencer le C++ et le Java, on recouvre une grosse partie des besoins. Les nouveaux langages à la mode comme Go ou Rust ont une syntaxe similaire.
    D’une manière générale, pour apprendre un langage de programmation, il faut comprendre comment la machine va l’interpréter. On ne fait pas qu’apprendre la syntaxe du langage, on apprend aussi les limites de la machine, quelque soit le langage utilisé.

    2. Le code utilise des algorithmes étudiés à l’école.
    C’est faux aussi. Ça arrive, bien entendu, mais en faible proportion. D’une part parce que les algorithmes connus sont déjà disponibles dans des boîtes à outils, ensuite parce que la grande majorité du code est faite pour propager des informations d’un point A à des points B,C et D en adaptant l’information pour qu’elle rentre dans les moules de B, C et D. Le logiciel entier peut résoudre des problèmes, mais la plupart des petits morceaux du logiciel ne résolvent pas de problème connu au sens où par exemple l’algorithme de Dijkstra résout le problème du plus court chemin.
    Pour savoir comment propager des informations, ça aide d’avoir étudié l’algorithmique pour s’être forgé un esprit logique et avoir des repères, mais c’est surtout par la pratique que ces choses là deviennent naturelles.

    3. L’algorithmique est le meilleur formalisme pour représenter le fonctionnement d’un programme.
    En général, c’est faux, pour les raisons évoquées au dessus. C’est pour ça que l’on représente souvent les programmes par des diagrammes UML : diagrammes de classe, diagrammes de séquences etc.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *