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 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.
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’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, 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, 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 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.
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é. 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 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. 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, la quantité de
bugs corrigés ou encore le nombre d’articles scientifiques publiés.
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. 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.
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.
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.