Opinions : Croquis mensuel de Pascal Francq – Juillet/Août 2017
Pascal Francq

L'art de programmer

Lorsque j’explique que je conçois et programme des algorithmes, mes interlocuteurs me regardent généralement interloqués comme si j’étais une sorte d’extraterrestre. Pour de nombreuses personnes, la programmation semble relever d’une forme de chamanisme.
Pour d’autres, la programmation relève d’un «simple» acte technique spécialisé au même titre que la résolution d’une équation différentielle. Les enseignements d’informatique dans les universités, de surcroît souvent intégrés dans des facultés de sciences, renforcent cette perception.
Je ne me suis pourtant jamais vu comme un technicien, et encore moins comme un sorcier du silicium. C’est plutôt l’habit d’artiste que j’imagine revêtir lorsque je commence à développer. Et je vais tenter de montrer que ce n’est pas qu’une forme de coquetterie de ma part.
Ce billet est sans doute quelque peu frivole. J’espère néanmoins qu’il proposera peut-être quelques pistes de réflexion sur l’une ou l’autre question posée par l’informatisation de nos sociétés, notamment sur son enseignement.

L’ingénierie informatique

J’ai déjà évoqué la différence qui existe, selon moi, entre l’informatique et les mathématiques appliquées. Là où la première m’apparaît relever principalement de l’ingénierie, les secondes s’inscrivent clairement dans le champ disciplinaire des mathématiques (dont elles constituent l’une des branches).
La différence pourrait sembler a priori terminologique. J’y vois pourtant une rupture. À mes yeux, l’ingénierie implique que le périmètre du problème auquel on s’attaque est trop vague et/ou trop large pour qu’une solution idéale soit calculée.
Prenons comme exemple la construction d’un pont. Lorsque des ingénieurs le conçoivent, ils ne peuvent pas prendre toutes les éventualités en compte, celles-ci étant trop nombreuses. En théorie, rien ne garantit donc que le pont ne s’écroulera pas. Pourtant, en pratique, le plus souvent, il tient !
En fait, l’ingénieur cherche la meilleure solution possible, même s’il ne peut jamais promettre que ce soit la solution idéale. Dans l’exemple des ponts, les ingénieurs combinent des équations tenant compte des principaux éléments (stabilité, vents, poids du trafic, etc.) avec des coefficients de sécurité.

Dans les règles de l’art

Ce qui apparaît de prime abord comme de «simples astuces» repose sur des faits objectifs, eux-mêmes produits des sciences actuelles. La formation d’ingénieur s’articule d’ailleurs sur l’apprentissage des mathématiques (analyse, algèbre, etc.) et des lois de la Nature (physique, chimie, etc.).
Mais contrairement à la résolution de problèmes typiques des «sciences pures», on y ajoute aussi des éléments «subjectifs». Ces derniers découlent de l’expérience humaine accumulée au fil du temps et des évolutions technologiques.
Le développement de logiciels s’attelant à des problèmes un tant soit peu élaborés relève de la même démarche. Certes, l’ingénieur informaticien [A]  [A] L’utilisation de l’expression «ingénieur informaticien» ne fait pas explicitement référence à un enseignement particulier, mais plutôt à un ensemble de compétences et à une certaine approche dans la résolution de problèmes informatiques. Je connais ainsi des personnes qui sont des ingénieurs informaticiens même si elles ne sont pas titulaires du grade correspondant. La réciproque est hélas vraie aussi, la formation «d’ingénieur informaticien» n’étant malheureusement pas toujours à la hauteur des attentes. se base sur les mathématiques appliquées (théorie de la complexité, calculs de graphes, etc.). Mais il mobilise également d’autres compétences.
Souvent, les solutions idéales des mathématiques appliquées s’avèrent impossibles à implanter par manque de ressources computationnelles (puissance de calcul, mémoire, etc.). L’ingénieur en invente alors de nouvelles, consistant parfois, d’ailleurs, en des «formes dégradées» de solutions idéales [B]  [B] Un exemple simple est le remplacement d’un calcul trop complexe par une approximation acceptable..
Ce subtil équilibre à trouver entre «faits objectifs» et «expériences subjectives» que les ingénieurs – en informatique comme dans d’autres domaines – sont censés rechercher revient à résoudre un problème dans les «règles de l’art».
Pour autant, peut-on, comme je l’évoque dans l’introduction, assimiler la pratique de l’ingénieur informaticien cherchant à tâtons le chemin vers la résolution d’un problème dans «les règles de l’art» à celle d’un artiste en quête d’inspiration dans la production d’une œuvre ?

La programmation, une expérience esthétique

Le processus de préparation d’un programme pour un ordinateur numérique est particulièrement attrayant, non seulement parce que c’est économiquement et scientifiquement valorisant, mais aussi parce que cela peut être une expérience esthétique comparable à la composition d’un poème ou d’une musique. [C]  [C] Il s’agit de ma propre traduction.
C’est par ces mots que Donald E. Knuth débute la préface de la troisième édition de son monumental The Art of Computer Programming [1]. Cette série d’ouvrages pose les bases de l’algorithmique informatique. Bien que peu lu [D]  [D] Si les ouvrages de Donald E. Knuth trônent certainement dans la bibliothèque de nombreux ingénieurs et informaticiens, l’étendue des sujets abordés ainsi que leur rigueur en rendent la lecture approfondie ardue. De plus, les nombreux exercices proposés à la fin de chaque chapitre, dont certains pourraient faire l’objet d’une thèse, finissent parfois par désespérer les lecteurs les plus courageux., comme tous les livres importants, cette œuvre dispose d’une véritable aura auprès des informaticiens.
Au-delà de la référence à l’expérience esthétique de l’avant-propos, le titre même est symptomatique. Pour un tel projet programmatique, Donald E. Knuth aurait pu utiliser «Science». La dénomination «computer science» existe en effet depuis 1959 [2]. Mais c’est bien «Art» qu’il choisit.
Je pense que ce choix traduit l’idée qu’il n’existe jamais une seule manière de développer un programme (complexe). Là où la science ne reconnaît, à un moment donné, qu’une seule explication «objective» ou l’absence de celle-ci [E]  [E] Lorsqu’il n’y a pas de réel consensus sur une explication, les scientifiques parlent d’hypothèses («multiples explications possibles»), certaines étant plus probables que d’autres. Bien entendu, l’évolution scientifique n’est pas statique et se caractérise par des révolutions paradigmatiques. Une explication en remplace alors une autre. Mais, à un moment donné, la majorité des scientifiques s’accordent sur une explication ou son absence. Si les convictions de chaque scientifique influencent bien évidemment ses recherches, ces convictions ne font pas partie de la science en tant que telle. Notons que les mathématiques admettent parfois plusieurs démonstrations pour une même hypothèse., l’informatique implique une dimension subjective.

La multiplicité des solutions à un même problème

Prenons les logiciels qui jouent aux échecs ou à go. En théorie, on peut construire un arbre de décisions de toutes les solutions possibles et déterminer les branches qui maximisent les chances de victoire. Mais le trop grand nombre de ces solutions rend cette option irréaliste en pratique.
Pendant longtemps, les ingénieurs informaticiens combinèrent des arbres de décisions partiels avec des heuristiques formalisant différentes règles pratiques (souvent formulées par des joueurs professionnels). C’est notamment cette stratégie qui permet à Deep Blue de battre Garry Kasparov.
Aujourd’hui, on privilégie les techniques d’apprentissage automatique dites du «big data». Des réseaux de neurones artificiels sont entraînés sur des centaines de millions de parties pour «apprendre» à jouer correctement. Le programme récemment victorieux au jeu de go se base sur cette stratégie.
Mais, dès lors que chaque stratégie cherche la meilleure solution possible sachant qu’elle ne sera jamais la solution optimale, aucune ne peut prétendre incarner «la vérité informatique ». Certes, l’une peut se montrer plus performante qu’une autre, mais ça ne lui confère pas une supériorité dans l’absolu.
En d’autres termes, il n’existe pas d’approche logicielle unique à un problème donné, mais l’ingénieur informaticien peut emprunter plusieurs voies. Tel un écrivain qui rédigera plutôt de la poésie ou de la prose, il choisira l’approche avec laquelle il est le plus familier, celle qu’il trouve la plus élégante.

Un logiciel élégant ?

L’élégance renvoie explicitement à une dimension esthétique, et le lecteur non informaticien pourrait se demander en quoi un logiciel peut être élégant. Le Larousse définit l’élégance comme une «qualité de ce qui est exprimé avec justesse et agrément, avec une netteté sobre, sans lourdeur».
Cette définition permet notamment de classer une démonstration mathématique comme élégante ou non. De même, on peut diviser les programmes suivant qu’ils sont élégants ou non. Rien d’étonnant en vérité dès lors que les algorithmes, objets mathématiques par excellence, forment la colonne vertébrale d’un logiciel.
Début 2017, une revue scientifique américaine spécialisée en informatique publie un bref article proposant quatre critères [F]  [F] En pratique, ces critères pourraient tout aussi bien s’appliquer aux démonstrations mathématiques. C’est une conséquence des liens structurels entre informatique et mathématiques, la première reposant en grande partie sur les secondes. que devrait rencontrer un logiciel pour être qualifié d’élégant [3]. Ces critères s’intègrent parfaitement dans la définition de l’élégance susmentionnée.
Les deux premières caractéristiques sont triviales. Un programme doit d’abord privilégier le minimalisme en étant court et simple. Le second critère est l’accomplissement : un logiciel doit pouvoir faire ce qu’il est censé faire.
La modestie constitue la troisième dimension. Trop souvent, on espère trouver une solution à tous les problèmes en une seule fois grâce à un «algorithme universel». Si la généricité n’est pas mauvaise en soi, la complexité découlant d’une universalité espérée étouffe souvent toute élégance.
L’auteure propose la révélation comme dernier critère. Un logiciel doit «nous apprendre quelque chose de nouveau ou nous rappeler quelque chose d’oublié» [3]. L’ingénieur informaticien exploite, par exemple, une propriété sous-jacente d’un problème (telle une symétrie) pour le résoudre efficacement.
Mais l’élégance d’un programme implique-t-elle automatiquement que la programmation soit un art ? En fait, la dimension artistique découle en plus du fait que la programmation implique l’utilisation d’un support : le code source [G]  [G] Les logiciels sont développés grâce à des langages de programmation qui permettent d’écrire les instructions qui devront être exécutées par l’ordinateur. L’ensemble des instructions d’un programme écrites dans un langage de programmation s’appelle le code source du programme..

La programmation, une forme d’écriture

J’ose même établir un parallèle entre l’écriture de code source et l’écriture «classique». Loin de se limiter à une simple analogie, le vocabulaire commun utilisé pour décrire les deux types de production souligne une forme de convergence esthétique.
Car, tout comme pour un texte de qualité, on attend en effet d’un «bon» programme qu’il soit «bien écrit». Et, en y regardant de plus près, la similitude entre ces deux types d’écriture n’est pas seulement sémantique.
Tout d’abord, dans les deux cas, la rédaction doit être claire. Pour un texte, il s’agit de construire des phrases limpides en choisissant un vocabulaire adapté [H]  [H] Certains auteurs, tels certains philosophes allemands et français, semblent se faire un devoir d’écrire de la manière la plus obscure possible. Pour autant, avec le recul, et quelque que soit la qualité du fond, on finit toujours par considérer cela comme un aspect négatif de leur œuvre (pensons, par exemple, à Georg Wilhelm Friedrich Hegel).. Semblablement, pour du code source, on veillera à utiliser les instructions les plus lisibles et à les regrouper en des séquences intelligibles.
Ensuite, on exige d’un programme (texte) qu’il soit bien structuré. Cette structuration démarre par des routines (paragraphes) cohérentes. Celles-ci sont regroupées logiquement en objets et modules (chapitres). Le tout est rassemblé en bibliothèques logicielles (livres).
Une interface de programmation applicative (API) désigne la normalisation de l’écriture des routines et de leur organisation. Or, à l’instar d’un livre, une API doit être cohérente. Un livre suit une certaine homogénéité dans la forme (concepts, dénomination de personnages, etc.). De même, une API respecte un ensemble de conventions (par exemple pour nommer les variables).
Un aspect important d’un logiciel est sa documentation qui comprend les informations nécessaires pour le comprendre et l’utiliser. Ici aussi, une similarité existe avec le livre. Notons particulièrement les commentaires [I]  [I] Tous les langages de programmation proposent une manière d’ajouter du texte libre dans un code source qui ne doit pas être interprété comme des instructions. Par exemple, en langage assembleur, le signe % permet d’indiquer que ce qui suit sur la ligne doit être ignoré par le compilateur. Cette possibilité permet de documenter les instructions du code source. Un exemple fictif :
% On charge le contenu de l’adresse 0xA000 dans l’accumulateur
LOAD 0xA000
dans le code code source (notes de bas de page) ou un index des routines et des objets (index terminologique).
Le code source d’un logiciel partage une autre caractéristique avec la poésie : l’importance de la présentation. Dans les deux cas, on emploie l’indentation, l’alignement, l’espacement, voire les couleurs, pour aider visuellement le lecteur à appréhender la structure générale.
Enfin, un élément essentiel pour produire des logiciels de qualité est le réusinage du code [4]. Comme pour l’écriture «classique», il s’agit d’adopter un processus itératif. On commence par une première mouture du code source, puis, par passes successives, on l’affine.

Les hackers, artistes du code

Si tout le monde peut participer à la production artistique (à commencer par le débutant qui apprend un instrument), l’art se caractérise néanmoins par des producteurs auxquels est attribué un statut singulier : les artistes. Je me limiterai ici à les définir comme «reconnus par les autres comme produisant une œuvre».
Une communauté souvent évoquée sur ce blog jouit d’un statut similaire en informatique : les hackers. Dans mon billet d'octobre 2015 qui leur était consacré, j’écrivais déjà qu’ils défendent une réelle méritocratie basée sur «l’art de développer des programmes performants et “élégants”».
Pour les hackers, seules les capacités informatiques sont valorisées au sein du collectif. Dans les premiers temps du MIT, où le mouvement hacker naît, un enfant de 12 ans est ainsi reconnu par les hackers comme l’un des leurs grâce à ses réalisations logicielles innovantes [5].
La reconnaissance par les pairs est au cœur du système de valorisation des hackers [6]. Les hackers estiment que seuls les autres hackers sont capables d’évaluer l’excellence de leurs développements en termes de créativité, d’élégance et de qualité d’écriture du code source.
Emmanuel Kant affirme que la perception de la beauté (artistique) est subjective, et qu’elle dit plus sur celui qui perçoit que sur la réalité de l’objet perçu [7]. Il y a bien un processus similaire chez les hackers. Ils se définissent aussi comme les personnes sachant juger de la qualité d’un logiciel.

La commercialisation de l’art et du code

Tout comme les artistes, la plupart des hackers accordent peu d’importance à la réussite financière [8]. Le plus souvent, la qualité intrinsèque des productions (musique, romans, logiciels, etc.) importe bien plus que les retombées économiques potentielles.
Les relations parfois difficiles entre les hackers et les entreprises trouvent en partie leurs origines dans l’opposition qui existe parfois entre qualité d’une solution et rentabilité. Cet antagonisme prend deux formes.
Tout d’abord, les intérêts commerciaux poussent parfois à la diffusion de solutions logicielles de faible qualité. La défiance récurrente entre les hackers et Microsoft exemplifie bien cet aspect. Les premiers reprochent notamment au second de vendre des logiciels peu sûrs.
La seconde forme tient au caractère logarithmique de l’amélioration qualitative logicielle [J]  [J] Notons que dans la plupart des domaines (art, science, sport, etc.), l’amélioration qualitative suit également une courbe logarithmique.. Au fur et à mesure de cette amélioration, l’investissement en temps (et donc en argent) grandit alors que le différentiel de qualité diminue. Si les informaticiens souhaitent continuellement améliorer la qualité de leur production, les managers s’y opposent lorsqu’il n’y a aucun avantage commercial à la clé.
L’éthique hacker s’oppose dès lors à la doctrine néolibérale et à son cortège d’indicateurs quantitatifs découplés de toute réalité qualitative. Citons parmi les métriques imbéciles présentes aujourd’hui le nombre de lignes de code source écrites [K]  [K] Un tel critère pousse à produire plus de lignes que nécessaire pour écrire et documenter un code source, ce qui viole les principes d’élégance des programmes et ceux de la qualité du code source., la quantité de bugs corrigés [L]  [L] Corriger un grand nombre de bugs n’est possible que si le programme en contient un grand nombre dès le départ, c’est-à-dire quand les programmes sont très mal écrits. De plus, différentes études montrent que cette pratique incite certains programmeurs à ajouter des bugs exprès de manière à valoriser ensuite le fait qu’ils en corrigent. Entre-temps, ces logiciels sont utilisés… ou encore le nombre d’articles scientifiques publiés [M]  [M] Les chercheurs sont plus intéressés à publier qu’à écrire du code source de qualité pouvant être facilement réutilisé. Il en résulte un frein important à la circulation des innovations informatiques à l’intérieur et à l’extérieur de la communauté scientifique en informatique..
L’art se trouve traversé par les mêmes phénomènes. De la promotion des blockbusters en passant par la production d’œuvres prêtes à consommer à la Stock Aitken Waterman, on observe partout les dégâts artistiques résultant d’une main mise croissante du commercial.

Une syntaxe et un vocabulaire simplifiés

Si les similarités entre art et programmation informatique apparaîtront désormais au lecteur comme évidentes, des différences les distinguent bien entendu, la plus importante étant que le cadre normatif de la programmation est bien plus strict que celui de l’art.
On pourrait débattre longtemps sur les libertés réelles d’un artiste. La mode, le contexte social et culturel (Pablo Picasso n’aurait certainement pas été Pablo Picasso à la Renaissance), l’état des technologies ou encore le parcours personnel d’un artiste influencent une œuvre.
Mais l’artiste garde une très grande latitude. Son expression peut passer par le verbe, la musique, la peinture, la sculpture, etc. De plus, pour chaque mode d’expression, une multitude de formes existent (guitare électrique ou synthétiseur, prose ou vers, sur toile ou sur papier, etc.).
L’ingénieur informaticien est plus contraint dans son mode d’expression du fait qu’il utilise un langage de programmation pour donner vie à ce qu’il imagine. Il en trouvera certes de très nombreux à sa disposition, mais le nombre de paradigmes de programmation reste très limité.
En outre, les caractéristiques d’un langage de programmation paraissent bien simplistes au regard des possibilités offertes à l’artiste. Alors qu’un auteur dispose de plusieurs milliers de mots et le musicien d’une gamme infinie de timbres, l’ingénieur informaticien jongle avec un vocabulaire d’une centaine de mots et des règles de grammaire plus que sommaires.

Une créativité pour dépasser les limites

Il ne faudrait pour autant pas conclure que la forme quelque peu élémentaire de la programmation informatique restreint la créativité. C’est même plutôt le contraire. Cette forme limitée implique en réalité que les chemins pour atteindre les incroyables potentialités de l’informatique sont plus sinueux.
Pour contourner les capacités computationnelles limitées des premiers ordinateurs dans les années 1960, les ingénieurs informaticiens inventèrent de nombreuses astuces («hacks» en anglais ce qui donnera «hacker») pour rendre les programmes plus rapides et moins gourmands en mémoire [6].
Si les ordinateurs sont plus puissants, les problèmes auxquels s’attaque l’informatique deviennent également plus complexes. Comme je l’ai indiqué plus haut, de nombreux ingénieurs informaticiens cherchent encore à éluder les capacités existantes.
Malgré les grandes écoles et les capitaux des gros groupes, l’innovation informatique viendra probablement toujours majoritairement des hackers [N]  [N] Les entreprises, notamment celles du numérique, l’ont bien compris puisqu’elles cherchent à recruter des hackers en leur proposant des cadres professionnels bien moins contraignants que ceux des «informaticiens lambda».. Pour le dire autrement, la capacité à créer sans cesse de nouveaux hacks demeure plus décisive que la maîtrise de tel ou tel langage de programmation.

Que doit faire l’école en informatique ?

C’est pourquoi je pense que le débat actuel du «codage à l’école» passe à côté de l’essentiel. Pour rappel, il est de bon ton aujourd’hui de défendre l’introduction de cours de programmation dans le cursus scolaire obligatoire. L’idée est de susciter des vocations qui déboucheront demain, assurent les défenseurs de cette idée, sur de nouveaux Google ou Apple.
Mais maîtriser un langage de programmation n’a rien de compliqué en tant que tel. La Toile regorge de tutoriaux qui facilitent la prise en main de la programmation et de nombreuses bibliothèques logicielles open source fournissent une multitude de fonctions de base.
L’innovation informatique se trouve dans la manière d’assembler les briques très élémentaires d’un langage de programmation pour réaliser un programme innovant. Ce n’est donc pas la maîtrise de la programmation en soi qui se révèle essentielle, mais les capacités de conception et de projection.
Or celles-ci s’acquièrent dans le cadre d’une solide formation générale. Si les sciences «dures» et les mathématiques en sont des éléments essentiels, des disciplines comme l’histoire ou la rhétorique participent à la formation d’un élève susceptible d’appréhender des problématiques complexes.
Transformer chaque élève en programmeur ne m’apparaît donc pas comme prioritaire. Introduire la programmation pourrait certes motiver certains élèves. Mais est-ce plus important qu’une introduction aux doctrines politiques (absente des cursus) ou à la musique (en voie de disparation) ?
Par contre, il faut enseigner une culture informatique qui permette aux jeunes de mieux comprendre le monde informatisé dans lequel ils grandissent et les enjeux auxquels ils sont confrontés (pensons simplement à la vie privée). Je défends depuis longtemps la mise en place de «cours d’éducation numérique» dès l’école primaire.

Une créativité en danger ?

Alors que l’informatique étend son emprise sur nos sociétés chaque jour un peu plus, j’ai parfois le sentiment que son évolution n’est pas toujours à la hauteur de son succès.
Pourtant, la puissance actuelle disponible et les progrès théoriques permettent de concevoir des applications inimaginables il y a quelques années encore. Que ce soient les avancées en intelligence artificielle ou la complexité de l’informatique mobile, l’innovation en informatique est multiple.
Le problème se situe plutôt, selon moi, dans le manque de hackers pour relever les défis posés par l’informatique moderne. Là où la croissance de l’informatique en exigerait un plus grand nombre, l’industrie et les institutions d’enseignement préfèrent trop souvent des informaticiens préformatés.
De trop nombreux informaticiens et chercheurs se contentent de suivre la mode technologique (aujourd’hui les réseaux de neurones artificiels) et d’exploiter les bibliothèques logicielles les plus populaires sans réellement chercher à comprendre comment elles fonctionnent.
Cette absence de regard critique sur les solutions informatiques engendre deux menaces : d’une part, le déploiement de technologies immatures voire dangereuses (et ses problèmes de cybersécurité), d’autre part, un manque de diversité, et donc d’innovation, parmi ceux qui les développent – ce second danger renforçant de surcroît le premier.
Or, il est tout à fait possible d’éviter ces écueils potentiels. D’abord par un enseignement (notamment en informatique) d’avantage basé sur la créativité que sur la maîtrise de théorèmes et de méthodologies rigides. Ensuite par une recherche en informatique se focalisant sur l’innovation réelle, en redonnant du temps aux chercheurs au lieu d’exiger une production quantitative abrutissante. Mais ceci est une autre histoire…

Références

[1] Donald E. Knuth, The Art of Computer Programming. Vol. 1, Fundamental Algorithms, 3ᵉ éd., Addison-Wesley, 1997.

[2] Louis Fine, «The Role of the University in Computers, Data Processing, and Related Fields», Communications of the ACM, 2(9), pp. 7–14. , 159.

[3] Robin K. Hill, What Makes a Program Elegant?, Communications of the ACM, 60(3), p. 13, 2017.

[4] Eric S. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly, 2001.

[5] Steven Levy, Hackers. Heroes of the Computer Revolution, Penguin Books, 1993.

[6] Pascal Francq, Internet: Tome 1, La construction d’un mythe, Éditions Modulaires Européennes, 2011.

[7] Emmanuel Kant, Critique de la faculté de Juger, Œuvres II, Pléiade, Gallimard, 1790.

[8] Pekka Himanen, The Hacker Ethic: A Radical Approach to the Philosophy of Business, Random House, 2001.