« 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.

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 » :

• 1e partie : programmer, une activité culturelle ?
• 2e partie : la programmation pour les non-programmeurs
• 3e partie : programmer le langage naturel
• 4e partie : programmer la complexité
• 5e partie : programmer le vivant
• 6e partie : programmer le multivers