“Relire le travail des autres, c’est tellement 2ème trimestre 2026 ! On vit dans le futur, maintenant !”
Flottement de 1-2 minutes, l’auteur se rend probablement compte que c’est une mise en avant un peu trop brutale sur un sujet controversé. “C’est une blague, rien n’a été décidé — ce n’est que mon avis ^^”.
Je n’ai pas grand-chose contre l’idée que les gens ne soient pas d’accord avec moi. Ni contre le fait que certains de mes collègues se plaisent dans l’utilisation de l’IA. Mais il y a une chose que j’ai mis beaucoup de temps à comprendre, et qui est assez révélatrice selon moi.
En discussion informelle, l’autre jour, un dév très senior prenait beaucoup plus la parole que d’habitude. On avait commencé à parler IA, comme à chaque réunion désormais, qu’elle soit rapide comme un daily (“T’as pensé à demander à Claude ?”) ou un free-talk.
Il faut le décrire un peu, pour comprendre. N. est un développeur expérimenté. Le genre “vrai ingénieur”, sorti d’école d’ingénieur il y a plus de vingt ans, branché pour dénouer des sacs de code apparemment incompréhensibles. Et pourtant, je sentais qu’il avait besoin de dire quelque chose sur l’IA. Je savais qu’il était enthousiaste et qu’il travaillait volontiers avec, mais je ne m’attendais pas à ça :
“Moi je n’ai pas codé depuis six mois, et je suis très heureux comme ça. C’est ce que j’aime avec l’IA, ne plus avoir besoin de coder.”
Ne plus avoir besoin de coder, et en être heureux. Mon problème, c’est que ça va à l’encontre de ce que j’imaginais. Comme j’aime bien coder, j’ai cru depuis l’avènement des agents semi-autonomes (genre Claude Code), que certaines personnes pouvaient être soulagées de ne plus coder. Comme un voile sur leur syndrome de l’imposteur, tellement fréquent (et apparemment totalement disparu dans les équipes !) en programmation. Que les autres, celles et ceux qui comme moi aimaient coder, était plutôt soit assez tristes de moins coder, soit appréciaient de se sentir un peu plus efficaces, soit n’utilisaient pas l’IA pour coder autre chose que les trucs de base, ceux qu’on aurait donnés à un junior pour l’entraîner et l’aider à apprendre.
Cela change totalement ma perception. Dans les messages enthousiastes, à chaque fois que la direction parlait d’IA (“J’y vois une opportunité”, “Super, on va pouvoir être plus productifs”), je voyais des manœuvres politiques ou de communication personnelle. Se faire bien voir, en gros.
Or, à ma stupéfaction, c’est désormais un but en soi pour des dévs, y compris très à l’aise avec le code : ne plus coder. Certes, on se souvient que “la valeur n’a jamais été dans le code”, mais c’est plus mantra de managers qu’une réalité vécue par les quelques développeurs que j’ai interrogés. Par contre, je découvre clairement “L’intérêt n’est plus dans le code”.
Attention, contrairement au débat sur la valeur, où j’affirme que le code est tout de même une barrière forte, je ne dis absoluement pas que l’intérêt de notre métier ne réside que dans le code. Au contraire, et je sais qu’on peut être plus ou moins à l’aise avec le code, comme on peut être plus ou moins à l’aise avec l’UX et les logiques métier, ou avec l’architecture, etc. Il y a plein de nuances de programmeurs, et la richesse des équipes vient généralement de la combinaison de ces profils.
Mais qu’on soit à l’aise avec “ne plus coder du tout”, quitte même à perdre la compréhension fine de ce que fait notre app, telle méthode, etc, ça me dépasse. Et pourtant… c’est une question à explorer. Si les étoiles s’alignent, si d’un côté on a un management qui par rationalisation des coûts, même fantasmée, préfère que ses dévs ne codent plus, et si de l’autre côté on a des dévs qui acceptent avec enthousiasme de ne plus coder et trouvent donc leur plaisir dans autre chose… cette “grande transformation” du métier de dév pourrait bien avoir lieu au final.
Il ne s’agirait donc plus que d’une question de “qui va continuer à être développeur” (peut-être pas tout à fait les mêmes profils), et évidemment “combien de postes on a”, puisque la promesse de l’IA (et l’envie des managers) est évidemment de réduire le nombre de dévs nécessaires.
Bref, tout ceci pourrait être très simple et le code pourrait ne plus être qu’un passe-temps pour la plupart des gens. Vous continuez à aimer coder ? Rien ne vous empêche de le faire sur votre temps libre. Après tout, il y a très peu de place pour être écrivain, ça n’empêche absolument personne d’écrire le week-end.
Le seul problème que j’y vois, au final, c’est la confiscation du débat. Qu’importe si vous n’aimez plus coder, qu’importe si vous considérez que ce n’est plus important. On est encore nombreux à penser que l’artisanat du code a une valeur qui, une fois perdue, va avoir un impact sur la qualité logicielle, son empreinte écologique, son rôle social. Et que si l’on continue à se comporter en sociopathes égotiques, c’est notre industrie tout entière qui n’aura bientôt plus de valeur positive pour la société.
Le problème, c’est qu’on n’a plus le droit de le dire dans les équipes. Tout doute, toute interrogation est interprété au mieux comme une frilosité, au pire comme un refus d’avancer. Cette incapacité à discuter de ce qu’est une innovation ou un progrès dans une équipe dédiée à une industrie qui pousse l’innovation devrait nous interroger collectivement. On n’en est pas là.
]]>“Relire le travail des autres, c’est tellement 2ème trimestre 2026 ! On vit dans le futur, maintenant !”
Flottement de 1-2 minutes, l’auteur se rend probablement compte que c’est une mise en avant un peu trop brutale sur un sujet controversé. “C’est une blague, rien n’a été décidé — ce n’est que mon avis ^^”.
Je n’ai pas grand-chose contre l’idée que les gens ne soient pas d’accord avec moi. Ni contre le fait que certains de mes collègues se plaisent dans l’utilisation de l’IA. Mais il y a une chose que j’ai mis beaucoup de temps à comprendre, et qui est assez révélatrice selon moi.
En discussion informelle, l’autre jour, un dév très senior prenait beaucoup plus la parole que d’habitude. On avait commencé à parler IA, comme à chaque réunion désormais, qu’elle soit rapide comme un daily (“T’as pensé à demander à Claude ?”) ou un free-talk.
Il faut le décrire un peu, pour comprendre. N. est un développeur expérimenté. Le genre “vrai ingénieur”, sorti d’école d’ingénieur il y a plus de vingt ans, branché pour dénouer des sacs de code apparemment incompréhensibles. Et pourtant, je sentais qu’il avait besoin de dire quelque chose sur l’IA. Je savais qu’il était enthousiaste et qu’il travaillait volontiers avec, mais je ne m’attendais pas à ça :
“Moi je n’ai pas codé depuis six mois, et je suis très heureux comme ça. C’est ce que j’aime avec l’IA, ne plus avoir besoin de coder.”
Ne plus avoir besoin de coder, et en être heureux. Mon problème, c’est que ça va à l’encontre de ce que j’imaginais. Comme j’aime bien coder, j’ai cru depuis l’avènement des agents semi-autonomes (genre Claude Code), que certaines personnes pouvaient être soulagées de ne plus coder. Comme un voile sur leur syndrome de l’imposteur, tellement fréquent (et apparemment totalement disparu dans les équipes !) en programmation. Que les autres, celles et ceux qui comme moi aimaient coder, était plutôt soit assez tristes de moins coder, soit appréciaient de se sentir un peu plus efficaces, soit n’utilisaient pas l’IA pour coder autre chose que les trucs de base, ceux qu’on aurait donnés à un junior pour l’entraîner et l’aider à apprendre.
Cela change totalement ma perception. Dans les messages enthousiastes, à chaque fois que la direction parlait d’IA (“J’y vois une opportunité”, “Super, on va pouvoir être plus productifs”), je voyais des manœuvres politiques ou de communication personnelle. Se faire bien voir, en gros.
Or, à ma stupéfaction, c’est désormais un but en soi pour des dévs, y compris très à l’aise avec le code : ne plus coder. Certes, on se souvient que “la valeur n’a jamais été dans le code”, mais c’est plus mantra de managers qu’une réalité vécue par les quelques développeurs que j’ai interrogés. Par contre, je découvre clairement “L’intérêt n’est plus dans le code”.
Attention, contrairement au débat sur la valeur, où j’affirme que le code est tout de même une barrière forte, je ne dis absoluement pas que l’intérêt de notre métier ne réside que dans le code. Au contraire, et je sais qu’on peut être plus ou moins à l’aise avec le code, comme on peut être plus ou moins à l’aise avec l’UX et les logiques métier, ou avec l’architecture, etc. Il y a plein de nuances de programmeurs, et la richesse des équipes vient généralement de la combinaison de ces profils.
Mais qu’on soit à l’aise avec “ne plus coder du tout”, quitte même à perdre la compréhension fine de ce que fait notre app, telle méthode, etc, ça me dépasse. Et pourtant… c’est une question à explorer. Si les étoiles s’alignent, si d’un côté on a un management qui par rationalisation des coûts, même fantasmée, préfère que ses dévs ne codent plus, et si de l’autre côté on a des dévs qui acceptent avec enthousiasme de ne plus coder et trouvent donc leur plaisir dans autre chose… cette “grande transformation” du métier de dév pourrait bien avoir lieu au final.
Il ne s’agirait donc plus que d’une question de “qui va continuer à être développeur” (peut-être pas tout à fait les mêmes profils), et évidemment “combien de postes on a”, puisque la promesse de l’IA (et l’envie des managers) est évidemment de réduire le nombre de dévs nécessaires.
Bref, tout ceci pourrait être très simple et le code pourrait ne plus être qu’un passe-temps pour la plupart des gens. Vous continuez à aimer coder ? Rien ne vous empêche de le faire sur votre temps libre. Après tout, il y a très peu de place pour être écrivain, ça n’empêche absolument personne d’écrire le week-end.
]]>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”.
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.
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.
]]>