Le supplément d'Art du programmeur

Face à une IA capable de compiler nos intentions en programmes fonctionnels, je m’interroge : notre métier se réduit-il à l’assemblage de syntaxe, ou cache-t-il une dimension qui échappe par nature au calcul ?

J’avais 17 ans quand j’ai enfin mis la main sur “The Art of Computer Programming” de Donald Knuth.
À l’époque, en 1989, les livres de référence sur la programmation étaient rares et les 4 volumes de TAOCP faisaient figure de “bible”; il reste encore pour moi un ouvrage de référence que chaque informaticien devrait lire.

Mais avec le recul, je suis surtout frappé par le décalage entre le titre et le contenu.
En lisant l’art de programmer un ordinateur, il est surprenant de découvrir un contenu aussi scientifique, académique, structuré, exhaustif et formel.
Avec le temps, j’en suis venu à voir la programmation autrement :
La programmation n’est pas, à mes yeux, une science exacte.
Plus précisément :  la programmation ne relève pas seulement de la science ; elle relève aussi d’une forme d’art.

Un art rigoureux, exigeant , qui ne se laisse pas réduire à l’application de méthodes ou de théorèmes.

Avant d’aller plus loin, précisons ce que j’entends ici par “art”.
Au risque de me faire crucifier par un professeur de philosophie, je limiterai ici le mot Art aux trois aspects suivants :

• la beauté
• le savoir-faire
• l’intuition, la part non réductible à des règles

Je n’argumenterai pas sur la beauté  d’un algorithme de Huffman ou l’élégance d’une solution récursive, même si beaucoup de développeurs comprennent très bien de quoi il s’agit. Je conçois que, pour beaucoup, cela paraisse au mieux saugrenu, au pire inintelligible, comme peut l’être la beauté du jazz pour qui n’en perçoit pas les codes.

Mais les deux autres sens, à eux seuls, suffisent déjà à caractériser ce qui fait la singularité de la programmation.

Toute tentative de réduire la programmation à une science est, selon moi, vouée à l’échec. Il y manquera toujours quelque chose : le savoir-faire, le métier, parfois l’intuition.

L’histoire du développement logiciel nous fournit plusieurs exemples :

Le formalisme du cycle en V où on transpose des méthodologies comptables issues de l’industrie en ignorant presque complètement le “savoir-faire”¹ et le “métier”. Cette approche formelle et scientifique, bien que détaillée et sensée, a souvent échoué à saisir les spécificités d’un métier et le poids réel du savoir-faire, qui se manifeste souvent très concrètement à travers l’expérience et la séniorité des personnes impliquées.

On a vu la même illusion avec certaines vagues industrielles autour de Java, de l’UML et des AGL : à force d’outils, de génération et de cadres méthodiques, on allait enfin produire du logiciel plus fiable presque mécaniquement. Java a été un succès industriel massif, mais cette promesse-là n’a jamais tenu. Les bugs n’ont pas disparu, la complexité non plus, et le métier n’a jamais cessé de compter.

Loin de moi l’idée de nier les fondements scientifiques de la programmation : La complexité algorithmique, la logique booléenne, le formalisme des grammaires et la théorie de l’information de Shannon ne sont que quelques exemples des bases sur lesquelles  l’informatique théorique s’est construite.

Mais cela ne suffit pas. Souvent, la différence se fait ailleurs : dans l’intuition, dans le style, dans l’expérience. L’intuition de Larry Wall, par exemple, lorsqu’il conçoit un langage pensé d’abord pour les programmeurs plutôt que pour la machine, relève déjà de cette part difficilement réductible à des règles.

À l’heure de l’IA générative, notre métier ne peut pas se réduire à assembler des lignes de code.

C’est quand nous cherchons plus que l’exécution correcte, quand nous injectons dans le code notre intuition, notre expérience, parfois même une forme de beauté, que nous y ajoutons un petit supplément d’Art.

Cette part d’Art n’a rien d’ésotérique. Elle se travaille.

Par la recherche de l’action juste (le savoir-faire)
Utiliser la structure adaptée, l’algorithme efficace, gérer les ressources.

Par la recherche de la faille (l’intuition)
Voir ce qui est ténu, détecter le signal faible, pour changer d’angle de vue.

Par l’attention à l’esthétique de la contrainte (la beauté)
Simplifier pour parfaire, rendre lisible pour lever toute ambiguïté

C’est à ce moment que l’alchimie opère : non plus quand du code fonctionne, mais quand il devient l’expression d’une expérience, d’un métier et d’une forme de beauté.

Il m’aura fallu rédiger ce billet pour découvrir, trois décennies plus tard, un article de 1974 dans lequel Knuth explicite une vision finalement pas si éloignée de la mienne