Le rêve récurrent de remplacer les développeurs, tous les 10 ans

• Depuis plus de 50 ans, les tentatives visant à simplifier le développement logiciel pour réduire la dépendance aux développeurs se répètent
• Depuis COBOL dans les années 1960 jusqu’aux outils CASE, Visual Basic, au low-code/no-code, puis plus récemment aux assistants de code IA, le même schéma se reproduit
• Chaque technologie a amélioré la productivité, mais le processus de réflexion nécessaire pour gérer la complexité reste toujours du ressort de l’humain
• L’IA amplifie les capacités des développeurs, mais ne remplace pas la compréhension des problèmes métier ni le jugement
• Cette répétition met en lumière non pas les limites des outils, mais la complexité des problèmes ; au final, l’essentiel reste d’investir dans les capacités de réflexion humaines

---

Le début d’un schéma récurrent

• Tous les 10 ans environ, une nouvelle promesse apparaît : « cette fois, développer sera plus facile »
  • Après le programme Apollo en 1969, le logiciel s’est imposé comme une technologie clé
  • Mais il est apparu que le développement exigeait des connaissances spécialisées, de la concentration et du temps
• C’est à partir de là qu’a commencé ce rêve persistant : « simplifier le développement pour réduire les besoins en main-d’œuvre »

COBOL : la croyance que les métiers pourraient coder eux-mêmes

• COBOL, comme son nom Common Business-Oriented Language l’indique, a été conçu pour permettre aux responsables métier d’écrire du code comme des phrases en anglais
• Mais en pratique, la complexité de la logique, des structures de données et de la conception des systèmes demeurait ; au final, une nouvelle catégorie de développeurs COBOL spécialisés s’est formée
• La vision selon laquelle « tout le monde peut coder » ne s’est pas concrétisée

Les années 1980 : la promesse de génération automatique des outils CASE

• Les outils CASE (Computer-Aided Software Engineering) sont apparus avec la promesse de générer automatiquement du code à partir de diagrammes
• Les entreprises ont investi massivement, en espérant un gain de productivité multiplié par 10
• Mais le code généré a échoué en raison de problèmes de performance, de difficultés de maintenance et de décalages avec les modèles
• Comme la compréhension de la complexité logique restait indispensable, le problème n’a pas été résolu

Les années 1990 : l’approche de Visual Basic et Delphi

• Grâce au glisser-déposer, ces outils ont facilité la création d’interfaces utilisateur et abaissé la barrière d’entrée du développement
• Les applications simples étaient possibles, mais pour les systèmes complexes nécessitant intégration, sécurité, performance et maintenance, des développeurs expérimentés restaient indispensables
• En conséquence, la demande de développeurs n’a pas diminué ; elle a au contraire augmenté

Depuis les années 2000 : frameworks web, low-code et no-code

• Ruby on Rails a mis en avant la « convention plutôt que la configuration », tandis que les plateformes low-code/no-code promettaient un « développement sans code »
• Dans certains domaines, elles ont permis d’accélérer les réalisations et d’élargir la participation, mais le besoin en développeurs professionnels n’a cessé d’augmenter
• La question revient sans cesse : « pourquoi ce schéma se répète-t-il ? »

La nature de la complexité

• Le logiciel peut sembler simple au premier abord, mais en réalité, la complexité explose dans les détails des situations concrètes et la gestion des exceptions
  • Exemples : conflits de réservation de stock, échecs de paiement, interruption d’un service d’e-mail
• Ces arbitrages de détail constituent précisément l’essence même du développement, et aucun outil ne peut les éliminer

Un nouveau chapitre à l’ère de l’IA

• Les assistants de codage IA génèrent du code en langage naturel et peuvent fournir des explications, aider au débogage et suggérer des améliorations
• C’est un progrès réel, mais la définition du problème, la sécurité, l’intégration et les choix de maintenance restent encore du ressort de l’humain
• L’IA amplifie la productivité des développeurs, mais ne remplace ni le jugement ni la compréhension du contexte

Des capacités de développement toujours insuffisantes

• La technologie a progressé à pas de géant, mais la demande en logiciels dépasse toujours l’offre
• Les entreprises cherchent un moyen de « produire plus, plus vite » et placent leurs espoirs dans des outils de simplification du développement
• Pourtant, le goulot d’étranglement ne se situe ni dans la vitesse de frappe ni dans la syntaxe, mais dans la capacité à raisonner sur la complexité

Les questions que les dirigeants devraient poser

• La bonne question n’est pas : « cet outil va-t-il remplacer les développeurs ? », mais plutôt :
  • « aide-t-il à résoudre des problèmes complexes ? »
  • « réduit-il les tâches répétitives pour permettre de se concentrer sur des problèmes créatifs ? »
  • « exige-t-il l’acquisition de nouvelles compétences techniques ? »
• Ces questions permettent de reconnaître les limites des outils et le caractère inévitable de la pensée humaine

La leçon de 50 ans : le problème n’est pas mécanique, il est intellectuel

• COBOL a simplifié la syntaxe, CASE a supprimé une partie de la saisie, et l’IA génère désormais des fonctions entières, mais la difficulté fondamentale demeure
• Le développement logiciel est un acte qui consiste à donner une forme concrète à la pensée, et cela ne peut pas être remplacé par des outils
• Comme en architecture ou en diagnostic médical, le processus de réflexion lui-même constitue la valeur essentielle

La direction à prendre

• De nouveaux outils continueront d’apparaître, mais l’investissement dans les capacités de réflexion humaines reste le plus important
• Il faut expérimenter l’IA, le low-code et les nouveaux frameworks, tout en faisant de la capacité à comprendre la complexité une compétence centrale de l’organisation
• Comme pour le programme Apollo, la précision de la réflexion compte davantage que les outils dans la réussite

Pourquoi ce rêve continue

• Le « rêve de remplacer les développeurs » n’est pas un échec, mais une forme d’optimisme qui stimule l’innovation dans les outils
• Chaque tentative a échoué à produire un remplacement complet, mais a permis de créer une nouvelle génération d’outils utiles
  • COBOL a favorisé l’essor du développement des systèmes métier
  • CASE a fait progresser la modélisation visuelle
  • Visual Basic a élargi l’accessibilité au développement
  • L’IA accélère l’évolution des méthodes de développement
• Au fond, la contrainte ne vient pas des outils, mais de la complexité des problèmes que nous cherchons à résoudre
• Il n’est pas nécessaire de rejeter les nouveaux outils ; il faut reconnaître l’importance d’attentes réalistes et du jugement humain

[GN⁺]

Réactions sur Hacker News

• En voyant cette vague d’innovation de l’IA, on réalise qu’une grande partie du code relève non pas d’une complexité essentielle, mais d’une complexité accidentelle
  Ce qui est un travail conceptuel pour les humains devient un travail procédural pour l’IA
  Par exemple, autrefois, il fallait apprendre plusieurs concepts pour écrire public static void main(String[] args) en Java, alors que pour l’IA, il suffit de lui donner un prompt du type « écris la méthode d’entrée d’une classe » pour qu’elle génère ce code de manière presque certaine
  Ce qui est un travail procédural difficile pour les humains est facile pour l’IA, mais la société est structurée autour de ce type de travail procédural, donc quand l’innovation se diffuse, certains montent et d’autres souffrent

  • Je pense qu’on sous-estime l’expérience et l’expertise nécessaires pour poser les bonnes questions

• L’idée que « le no-code va remplacer les développeurs » revient à chaque fois, mais en pratique elle a surtout créé davantage d’emplois de développeurs
  COBOL, VB, Squarespace, et maintenant l’IA — quand les outils abaissent les barrières à l’entrée, davantage de gens essaient de construire quelque chose, et lorsqu’ils atteignent les limites, ils ont finalement besoin de vrais développeurs
  Les tâches simples et répétitives disparaissent, mais définir ce qu’il faut construire et déboguer reste nécessaire

  • J’espère moi aussi que cette expansion va continuer, mais au final tout dépend de l’apparition d’une nouvelle demande
    Si l’IA peut coder seule des projets complexes, la demande de développeurs pourrait baisser, puisque les humains n’auraient plus à se soucier des détails
    Par le passé, il y a eu de grandes vagues comme Internet, le cloud, le mobile ou le machine learning, mais je ne suis pas certain que de tels « grands problèmes » continueront d’apparaître
  • C’est un cas classique du paradoxe de Jevons — quand quelque chose devient moins cher, le marché grandit au contraire
  • Bien sûr, cette fois pourrait être différente. Si l’IA tient vraiment ses promesses, le nombre de développeurs pourrait diminuer
  • Les machines agricoles ont rendu les agriculteurs plus efficaces, mais aujourd’hui il y a au contraire davantage d’agriculteurs
  • Affirmer que « le nombre de développeurs ne baisse pas » est trop catégorique. Si l’IA arrive aussi à déboguer et à interpréter les besoins, la situation pourrait changer

• Depuis 20 ans, on observe le même schéma dans l’administration système
  La promesse selon laquelle « un niveau d’abstraction plus élevé démocratise le travail des experts » revient sans cesse, mais en réalité cela produit surtout une réinvention coûteuse
  Des outils comme Kubernetes sont censés avoir masqué la complexité, mais au final les développeurs réapprennent les mêmes problèmes d’une manière plus coûteuse, sans connaître les concepts de base
  Excel en est l’exemple type — il a généré des erreurs affreuses, mais il a réussi grâce à son accessibilité
  Au fond, nous voulons à la fois « l’accessibilité d’Excel et la fiabilité de l’ingénierie », mais nous ne pouvons pas avoir les deux

  • Dans ce cas, les primes d’assurance ou les politiques d’indemnisation vont-elles changer avec l’usage de logiciels non déterministes ?
  • Si Kubernetes n’a pas réduit le travail, cela voudrait dire que 95 % des grandes entreprises sont idiotes
    En réalité, à mesure que l’échelle augmente, la complexité du travail monte d’un cran
  • Toute abstraction est une abstraction qui fuit. Même en C, le résultat peut varier selon le compilateur

• Si ce schéma se répète, c’est à cause des incitations du marché
  Les entreprises doivent présenter l’IA comme une solution miracle pour faire monter leur cours de Bourse, si bien qu’elles vendent surtout une croyance plutôt qu’une performance réelle
  Quand la réalité finira par apparaître, le marché deviendra chaotique

  • Le marché n’est pas une force de gravitation universelle. Il faut un ordre politique pour qu’un marché existe
  • Si le produit fonctionnait vraiment comme promis, ils se consacreraient au développement au lieu de se focaliser sur la « critique des sceptiques »

• En réalité, on aurait pu réduire le nombre de développeurs
  Si les entreprises avaient été plus sélectives dans leurs recrutements et leurs investissements en formation
  Mais dans les faits, c’est l’inverse qui s’est produit, et les frameworks web ont été conçus moins pour améliorer la productivité que pour réduire les coûts de formation et élargir le vivier de main-d’œuvre

  • Je ne suis pas d’accord. Les bons frameworks améliorent la maintenabilité et la productivité

• Les managers intermédiaires et les dirigeants ne voient les départements techniques que comme des centres de coûts
  Ils mentionnent donc l’IA dans tous les communiqués et proclament des réductions de coûts salariaux
  En réalité, ils réduisent surtout les coûts en remplaçant les effectifs par de la main-d’œuvre offshore, pas grâce à l’IA
  Les équipes onshore restantes absorbent davantage de travail et augmentent ainsi leur productivité

  • Pourtant, dans les zones offshore aussi, les licenciements se produisent de la même façon
    Ce n’est pas une question de réduction du coût du travail, mais d’un recul général de l’investissement
    Au final, l’IA absorbe le capital via les investissements dans les datacenters, ce qui réduit l’emploi
  • L’idée que « les ventes ne peuvent pas exister sans produit » a de nombreux contre-exemples historiques

• Le but de l’IA n’est pas de remplacer les développeurs, mais d’élever le niveau d’abstraction pour traiter des problèmes plus complexes
  En partant du câblage des premiers ordinateurs, puis de l’assembleur, du C, de Python et des frameworks, les développeurs ont progressivement travaillé sur des problèmes de plus haut niveau
  Cela dit, les étapes précédentes étaient toutes des transformations déterministes et vérifiables, alors que l’IA générative est non déterministe, ce qui change la donne
  À ce sujet, on peut lire The Story of Mel

  • Mais des entreprises, y compris le CEO d’Anthropic, s’intéressent davantage à la réduction des coûts et au remplacement qu’à cet objectif philosophique
  • Malgré tout, les gens continueront à parler de « remplacement des développeurs »
  • Chaque niveau d’abstraction doit permettre de regarder ce qu’il y a à l’intérieur
    Avec les LLM, on ne peut pas voir les tokens, l’AST, l’IR, etc. comme avec un compilateur, donc c’est opaque
  • Le véritable objectif des entreprises d’IA est d’automatiser tout le travail intellectuel
  • Plus le niveau d’abstraction monte, plus la précision et le contrôle diminuent
    Un système non déterministe fondé sur le langage naturel n’a rien à voir avec les abstractions des générations précédentes
    C’est pourquoi l’analogie avec « le passage de l’assembleur au C » n’est pas pertinente

• Comme le disait Dijkstra, la science est détestée parce qu’elle est difficile, et les scientifiques qui détiennent ce pouvoir le sont aussi
  Lien vers le texte original EWD1041

• À l’inverse, les développeurs ont toujours rêvé d’automatiser les métiers non techniques
  L’IA est simplement la version la plus récente de ce rêve

  • Verra-t-on un jour un monde à la Star Trek où tous les métiers seront de bons métiers ?

• Au début des années 2000, Rational Rose UML était une matière obligatoire à l’université
  À l’époque, le CEO d’une startup affirmait que « désormais, il suffit de dessiner des diagrammes et le code sera généré automatiquement, donc on n’a plus besoin de développeurs »
  Mais au final, cette prophétie ne s’est pas réalisée

[kayws426]

Les machines écrivent du code pour les machines.
Le château de sable bâti par les humains au-dessus du langage machine est de toute façon voué à s’effondrer.
... enfin, on peut toujours raconter ça aussi lol