Torras.ai

Pendant la majeure partie de l'histoire de l'ingénierie logicielle, le progrès a suivi un schéma clair : l'abstraction remplace la mécanique.

Nous avons commencé par programmer les machines de la manière la plus littérale possible. Les premiers développeurs écrivaient directement des instructions machines, manipulant les registres et les adresses mémoire. C'était puissant, mais coûteux sur le plan cognitif. Chaque détail devait être géré manuellement.

Le langage assembleur a abstrait le binaire brut en instructions symboliques. Il n'a pas supprimé la complexité, mais l'a rendue gérable.

 mov eax, [price]
 sub eax, [tax]
 mov [net_amount], eax

Puis sont arrivés les langages de plus haut niveau. Parmi les premiers figuraient Fortran et COBOL, chacun représentant un saut conceptuel significatif. Fortran permettait aux ingénieurs d'exprimer des formules mathématiques d'une manière plus proche de leur raisonnement habituel. COBOL a tenté quelque chose d'encore plus ambitieux : rapprocher la programmation du langage des affaires.

Une instruction COBOL typique pouvait ressembler à :

SUBTRACT TAX FROM PRICE GIVING NET-AMOUNT

Plutôt que l'expression plus compacte que l'on verrait dans de nombreux langages ultérieurs :

net_amount = price - tax;

Les créateurs de COBOL pensaient que si les programmes ressemblaient à l'anglais, les utilisateurs métiers pourraient plus facilement les lire, voire les écrire. C'était une tentative précoce de réduire l'écart entre l'intention humaine et l'exécution machine.

Pourtant, COBOL n'était pas de l'anglais. C'était un langage formel conçu pour ressembler à l'anglais. Il restait rigide, déterministe et lié à une syntaxe stricte. Les humains devaient toujours s'adapter à la structure de la machine. L'abstraction réduisait la charge cognitive de la programmation bas niveau, mais n'éliminait pas la couche de traduction entre l'intention et l'implémentation.

Cette couche de traduction a défini la profession d'ingénieur logiciel pendant des décennies.

Intention déclarative : le cas de SQL

Il y a eu un autre moment important dans cette évolution, souvent négligé : l'arrivée de SQL.

Structured Query Language (SQL) était différent de la plupart des langages de programmation qui l'ont précédé. Il était déclaratif. Au lieu de dire au système comment récupérer les données — quels index parcourir, quelles boucles exécuter, quelles jointures calculer en premier — le développeur décrivait simplement quelles données étaient nécessaires.

 SELECT name, balance 
 FROM accounts 
 WHERE balance > 1000;

Cela représentait un changement d'abstraction profond. L'ingénieur exprimait une intention. Le moteur de base de données décidait du plan d'exécution.

En ce sens, SQL était plus proche du langage naturel que la plupart des langages procéduraux. Il se lisait presque comme de l'anglais. Il se concentrait sur la description du résultat souhaité plutôt que sur la prescription de la séquence d'opérations nécessaires pour l'obtenir.

Et pourtant, malgré son accessibilité, SQL n'est jamais vraiment devenu un langage pour les utilisateurs métiers. Il est resté technique. Écrire des requêtes correctes nécessitait de comprendre les schémas, les relations, les implications de performance, la normalisation, l'indexation et le comportement transactionnel. L'abstraction simplifiait l'exécution, mais n'éliminait pas le besoin d'expertise.

SQL a été une démonstration précoce que décrire quoi au lieu de comment est puissant. Mais la couche de traduction existait toujours. Les humains devaient encore penser en syntaxe structurée et formelle. Le système optimisait l'exécution, mais n'interprétait pas l'intention ambiguë.

La couche de traduction

Traditionnellement, construire un logiciel nécessitait un processus de conversion :

1. Un problème métier est exprimé en langage naturel.
2. Un développeur traduit cette description en exigences structurées.
3. Ces exigences sont traduites en code.
4. La machine exécute ce code.

La valeur centrale du développeur a longtemps résidé dans cette capacité de traduction. La connaissance de la syntaxe, la familiarité avec les frameworks et la mémorisation des fonctions de bibliothèque faisaient partie de l'efficacité et de la précision de cette traduction.

Cependant, l'arrivée des grands modèles de langage a commencé à modifier cette dynamique de manière fondamentale.

Aujourd'hui, il est possible d'écrire quelque chose comme :

 Design a modular payment processing system with idempotent operations, 
 audit logging, retry logic with exponential backoff, 
 and integration tests simulating network failures. 
 It must follow the existing application’s architecture and conventions, 
 including the same coding style, framework choices, database patterns
 (ORM, migrations, transactions),logging/observability stack, 
 configuration approach, and deployment practices. Reuse existing 
 libraries and utilities wherever possible, and avoid introducing new 
 dependencies unless strictly necessary. 

Ceci n'est pas du code. C'est une intention structurée.

Et pourtant, un système d'IA performant peut transformer cette intention en squelette de code, en cas de test, et même en schémas architecturaux en quelques secondes.

Ce n'est pas simplement l'automatisation du code répétitif. C'est l'automatisation de la traduction.

Le déplacement de la rareté

Chaque couche d'abstraction modifie ce qui est rare.

Lorsque les compilateurs sont devenus fiables, mémoriser les instructions assembleur a cessé d'être précieux. Lorsque les frameworks ont mûri, écrire à la main le code d'infrastructure a cessé d'être un facteur différenciant.

Aujourd'hui, alors que les systèmes d'IA génèrent du code syntaxiquement correct et souvent structurellement solide, la rareté se déplace à nouveau.

Les compétences précieuses incluent de plus en plus :

• Articulation précise des exigences
• Décomposition de systèmes complexes en composants gérables
• Définition explicite des contraintes et des cas limites
• Raisonnement architectural
• Évaluation critique des résultats générés
• Discipline de test et de validation

Mémoriser la syntaxe ou se souvenir de détails obscurs d'API devient moins central, car ces tâches sont de plus en plus automatisées.

Cela n'élimine pas le besoin de connaissances techniques approfondies. Au contraire, cela amplifie l'importance du jugement. Les ingénieurs doivent toujours comprendre les implications de performance, les compromis de sécurité, les risques de concurrence et les limites du système. Mais l'acte mécanique d'écrire du code n'est plus le seul goulot d'étranglement.

L'intention devient l'atout durable.

L'anglais comme couche de programmation

Dire que l'anglais devient une couche de programmation ne signifie pas que les langages formels disparaissent. Les compilateurs, les runtimes et les environnements d'exécution fonctionnent toujours sur du code structuré.

En réalité, l'anglais — ou plus précisément, le langage naturel structuré — devient la couche d'abstraction la plus élevée au-dessus des langages de programmation traditionnels.

Le flux ressemble de plus en plus à ceci :

 Intention (langage naturel)
 → Génération structurée (IA)
 → Code formel
 → Exécution machine

Dans ce modèle, le code devient un artefact intermédiaire. Il peut être régénéré, refactorisé et optimisé automatiquement. Ce qui reste stable, c'est la définition du problème et la clarté des contraintes.

La qualité du système final dépend moins de la capacité du développeur à se souvenir de la syntaxe que de sa capacité à décrire ce que le système doit faire, dans quelles conditions, avec quelles garanties, et face à quels modes de défaillance.

Le langage naturel devient exécutable non pas parce qu'il est intrinsèquement précis, mais parce que les systèmes d'IA sont devenus des interprètes capables.

Qui va construire les logiciels maintenant ?

Ce changement soulève une question plus profonde que celle de la formation des ingénieurs. Il pose la question de savoir qui va programmer.

Si les systèmes d'IA peuvent traduire une intention structurée en logiciel exécutable, les utilisateurs métiers pourront-ils enfin construire directement ce dont ils ont besoin ? Le langage naturel deviendra-t-il suffisamment précis pour que les experts métier puissent décrire des systèmes sans intermédiaires ?

L'histoire invite à la prudence. COBOL a tenté de rapprocher la programmation du langage des affaires. SQL a permis aux utilisateurs de décrire les données qu'ils voulaient plutôt que la manière de les récupérer. Les deux ont représenté des changements d'abstraction significatifs, et pourtant les deux sont restés des outils techniques. La couche de traduction n'a pas disparu ; elle s'est simplement déplacée.

Peut-être que cette fois-ci sera différente. Peut-être que les systèmes d'IA absorberont suffisamment de complexité pour permettre aux utilisateurs non techniques d'opérer en toute sécurité à un niveau d'abstraction supérieur.

Ou peut-être que les professionnels techniques resteront essentiels — non pas comme dactylographes de la syntaxe, mais comme concepteurs de contraintes, architectes de systèmes et garants de la justesse.

Même si l'anglais — ou toute autre langue naturelle, d'ailleurs — devient la couche d'abstraction la plus élevée, quelque part en dessous, COBOL continuera de traiter des transactions, les compilateurs continueront d'optimiser les instructions, et le code formel s'exécutera toujours de manière déterministe.

Les abstractions évoluent. L'infrastructure persiste. La valeur se déplace vers le haut.

Que l'IA démocratise complètement la programmation ou élève simplement le rôle des ingénieurs à une couche supérieure, seul l'avenir le dira.