Désolé mais je ne crois pas à "La valeur n'a jamais été dans le code"

Il était une fois un buzzword

J’ai toujours été fasciné par les tendances.

Un matin, vous vous réveillez et vous aller développer ce jour précis une envie à la fois très personnelle et très forte. Un manteau. Un vélo. Une paire de chaussures. Votre désir est intime et parfaitement personnel, original. C’est le vôtre, et le vôtre seulement.

Mais voilà, quelques jours plus tard, vous rencontrez quelqu’un•e dans la rue avec exactement le même objet. Une personne qui a cet exact vélo que vous pensiez être le seul à vouloir, à propos duquel vous aviez même passé du temps à raisonner, à vous convaincre que c’était la meilleure acquisition pour vous. Quelques semaines plus tard, la moitié des habitant•e•s de votre quartier semble animée du même esprit libre et original que vous pensiez avoir.

Le monde professionnel n’est pas immunisé à ces épisodes de révélation collective. Avec sa hiérarchie et ses mécanismes de pression sociale et culturelle propres, c’est même là où ils fonctionnent le mieux. Les tendances n’y sont pas des tendances et deviennent rapidement des doctrines et de la chair à idélogie managériale.

C’est ainsi que des millions de managers finissent par ressortir à longueur de réunion l’exacte même citation du même livre de développement personnel. Sans surprise, à une époque où les entreprises (et notamment les startups de la tech) se gorgent d’“énergie masculine” et de la métaphore du “poste de commandement”, le livre en question est souvent écrit par un ancien officier militaire.

Mais ce n’est pas le sujet (dit-il après 5 paragraphes de blabla).

Récemment, j’ai entendu une phrase qui m’a sincèrement stupéfait :

“La valeur d’un programmeur n’a jamais été dans le code.”

Je ne me souviens pas où je l’ai entendue en premier. Ce dont je peux me souvenir, c’est la vitesse à laquelle cette phrase apparemment anodine est devenue une vérité validée par la doxa. Un•e manager l’a dite. Plus un•e collègue. Puis un•e membre de la direction. Quelques jours plus tard, n’importe quel blog tech avait atteint la même vérité indépassable dans une opération de révélation simultanée et spontanée.

L’idée, en gros, est la suivante : les développeurs ne tirent pas leur valeur professionnelle de leur connaissance de langages de programmation, ou de leur capacité à produire du code compréhensible par une machine. Leur valeur réelle est ailleurs (supposément) : dans la “résolution de problème”.

Une masterclass en jargon corporatif

Cette phrase est une masterclass en matière de réthorique d’entreprise.

D’abord, elle repose sur un autre cliché très établi de l’industrie du logiciel : l’idée que les développeurs sont fondamentalement des “résolveurs de problèmes”. Chaque jour, il semble que nous fassions face à un puzzle insoluble qui se dresse entre l’entreprise et le succès. Nous ne sommes pas des codeurs, nous sommes des stratégistes. Des ingénieurs. Des architectes de solutions.

Cette croyance est tellement répandue qu’elle sert maintenant de justification fondamentale à une autre croyance, qui la renforce en retour. Si le “codage” est partiellement automatisé, alors le codage n’a jamais été la partie qui apportait de la valeur ajoutée.

Pratique.

Le problème, ce n’est pas de dire que le développement logiciel implique la résolution de problèmes. Bien sûr que c’est le cas. Le problème c’est que cette phrase est tellement usée qu’elle en a perdu toute signification.

La plupart des développeurs — et ce n’est pas une insulte, la plupart du temps j’en fais partie — ne passe pas ses journées à concevoir des rovers à envoyer sur Mars, ou des systèmes distribués pour l’ESA. Une part massive de la tech est aujourd’hui occupée à concevoir des applications CRUD, des dashboards internes, des applications de mise en relation type “Marketplace”, des funnels de réservation, des sites vitrines, des outils marketing et des systèmes e-commerce.

Des problèmes résolus mille fois par des centaines de développeurs.

Cela ne signifie pas que ce travail n’a pas de valeur. Une partie en a beaucoup, mais considérer chaque création d’admin Rails ou de landing page en React un challenge pour une unité d’élite relève de la supercherie.

Il arrive un point où “résoudre des problèmes” devient tellement vague que je considère la cuisson de mes œufs comme la résolution de mon problème de faim. Et pourtant…

Et pourtant, le slogan tient bon. Il enfle, circule, est repris de bouche en bouche. La raison m’apparait simple : il remplit deux fonctions en une.

D’abord, il rassure les développeurs paniqués par l’arrivée de l’IA et des “agents codeurs”.

Ensuite, et c’est probablement le plus important, il redéfinit en creux où la valeur professionnelle est censée se trouver, pile au moment où la génération de code elle-même devient plus simple et plus accessible financièrement.

C’est un changement qui est plus économique et social que technique. Historiquement, dire que la valeur n’est pas dans le code est un non-sens. L’industrie a passé des décennies à jalouser le code, à le garder derrière les murailles de la propriété intellectuelle, à créer une mythologie autour du code, à surpayer ceux capables de le produire et à construire son propre prestige autour du code. Des sous-cultures professionnelles entières ont émergé autour de la maîtrise de langages, de frameworks, d’algorithmes et de systèmes.

Et d’un coup d’un seul :

“En fait, le code n’a jamais été au centre de la valeur.”

Vraiment ? Si la valeur économique des développeurs n’avait effectivement jamais été liée à la fonction même de coder, je doute que la tech aurait autant dépensé à traiter les développeurs simultanément comme des divas insupportables et des spécialistes indispensables. Les mèmes comme les récentes périodes fastes en disent long.

Les langages de programmation ne sont pas des langages humains

Une partie de la confusion vient à mon avis du fait qu’on sous-estime la nature des langages de programmation.

Un langage informatique n’est pas un langage humain.

La conversation humaine est tolérante. Approximative, redondante. Parlez français avec un accent à couper au couteau et vous aurez toujours (normalement) des encouragements, parce que votre interlocuteur comprend l’intention, le contexte et l’ambiguïté. Les humains compensent naturellementculturellement pour les erreurs.

Pas les ordinateurs.

Les langages de programmation requièrent une forme de précision radicalement différente (sauf JavaScript, diront les mauvaises langues). Ils vous forcent à être explicites, à utiliser des structures formelles et à penser d’une autre façon : l’approximation et l’ambiguïté ne font plus votre charme, elles sont les instruments de votre ruine.

Certains langages ont tenté d’être plus lisibles, ou expressifs. Ruby en est un exemple, peut-être le plus connu dans la communauté Ruby (;)). Les développeurs Ruby décrivent généralement leur langage car “élégant” car il permet au code de ressembler presque à du langage naturel :

Account.where(first_name: "Bill").active.registered_last_month

C’est vrai, cela semble très simple à lire. En réalité, cela ne l’est que dans un contexte très spécifique.

Un développeur Ruby comprend que ce code est probablement une chaîne de requête ActiveRecord. Il en comprend son périmètre, les conventions implicites. Il en reconstruit les couches d’abstraction invisibles.

En réalité, cette ligne n’apparaît comme “naturelle” que grâce à l’accumulation de conventions qui en a compressé en partie la complexité. En clair, ce code peut apparaître “élégant” pour une développeuse Java qui découvre Ruby. Pas pour une personne qui découvre le code.

Plus important encore : écrire un tel code n’a rien à voir avec le lire.

Les expressions active et registered_last_month ne sont pas des mots magiques décidées par l’Académie de la langue Ruby après le rejet d’expressions considérées comme trop wokes. Ce ne sont pas forcément des expressions construites dans Ruby lui-même. Quelqu’un a dû concevoir ces abstractions, que ce soit au niveau du langage, d’un framework, d’une librairie ou même de la base de code elle-même. Quelqu’un doit décider ce que veut dire “active”, ou “registered”, comment le temps est géré, ce qui se passe dans les cas limites, ce que l’ordre du chaînage veut dire en terme de performance de la requête, de composabilité, de maintenance future.

La ligne de code n’est que la surface résituelle d’un processus cognitif beaucoup plus important. Et surtout, à mon avis, ce processus cognitif est en partie rendu possible par la capacité à “parler en code”.

C’est la partie la plus souvent oubliée par le discours ambiant sur l’IA. Aucun•e ingénieur•e logiciel sérieu•x•se ne peut penser que le développement est juste une question d’écriture de syntaxe. Une application CRUD générée automatiquement en quelques minutes n’a jamais été l’essence de notre artisanat.

Dans un mouvement inverse, réduire la programmation à de la “résolution de problèmes” est tout aussi malhonnête, par négation de la spécificité technique et cognitive de la construction logicielle elle-même.

Écrire du logiciel, c’est concevoir des abstractions, penser en terme de système, raisonner dans le temps, sous la contrainte d’un management, en gardant en tête l’anticipation des changements futurs et des modèles mentales pour la gestion des bugs. Le code n’est jamais distinct de tous ces paramètres. Le code est leur sublimation.

La valeur est donc bien dans le code, mais la voir requiert la capacité à voir tous les niveaux de travail mis dans un produit fini.