30 points par GN⁺ 2026-01-18 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • 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

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.