Ou pourquoi C#, Java, Python et les autres pourraient devenir nos prochains assembleurs
J’ai déjà vu une révolution informatique gagner techniquement et perdre humainement.
C’était au milieu des années 1990.
Delphi 1 venait de sortir. À l’époque, j’étais très impliqué dans l’écosystème Borland, conférencier connu dans ce milieu, auteur de livres et assez proche de la direction de l’entreprise. Le directeur informatique d’Europe Assistance m’avait demandé de venir évaluer sérieusement Delphi.
Il connaissait Pascal. L’idée de voir revenir ce langage, considérablement modernisé et associé à un environnement de développement remarquablement productif pour son époque, lui plaisait.
Il ne voulait toutefois pas d’une démonstration commerciale.
Il voulait savoir si l’on pouvait réellement faire du logiciel d’entreprise avec.
Nous avons donc choisi un vrai problème.
Et pas exactement un « Hello World ».
Quand la meilleure solution n’est pas adoptée
L’un des problèmes essentiels d’Europe Assistance consistait à déterminer quelle aide envoyer à quelqu’un qui appelait pour obtenir du secours.
Dit comme cela, il suffirait de trouver le prestataire disponible le plus proche.
Sauf que le monde réel est rarement aussi accommodant.
- Il y a les frontières.
- Les conflits.
- Les guerres.
- Les événements climatiques.
- Les tremblements de terre.
- Les routes impraticables.
- Les zones qu’on ne traverse pas.
- Les ressources indisponibles.
Le dépanneur géographiquement le plus proche n’est donc pas nécessairement celui qui pourra arriver le plus vite.
Pendant plusieurs semaines, avec l’un de leurs ingénieurs que je formais en même temps à Delphi et à l’orienté objet, nous avons réalisé cette application.
Et cela a fonctionné.
Très bien même.
Le temps de développement était inférieur à ce qu’aurait nécessité une équipe traditionnelle, alors même qu’une partie de mon temps était consacrée à former l’ingénieur avec lequel je travaillais.
Le programme compilé était rapide.
L’interface était tout à fait convenable pour l’époque.
La démonstration technique était faite.
Objectivement, le directeur informatique aurait dû décider d’adopter Delphi.
Il réfléchit plusieurs semaines.
Puis il me donna sa réponse.
En substance :
« Je connais chacun des programmeurs qui travaillent ici. Pour certains, je connais leur femme, leurs enfants. Je sais que quelques-uns ne réussiront pas à suivre le passage à l’orienté objet. Et je n’ai pas le cœur de les renvoyer. »
Delphi ne fut donc pas adopté. En tout cas à ce moment-là et je n'ai pas eu d'infos dans les années qui ont suivi.
Pas parce qu’il ne fonctionnait pas.
Pas parce que Pascal était mauvais.
Pas parce que l’expérience avait échoué.
Mais parce qu’une technologie n’entre pas dans une entreprise seulement avec ses qualités techniques.
Elle entre avec des êtres humains.
Ce jour-là résume probablement mieux l’histoire réelle de l’informatique que beaucoup de chronologies des langages.
Les faits sont des points
On peut évidemment raconter autrement l’histoire de la programmation.
Et on aura raison.
Simula développait déjà des concepts objets dans les années 1960. La première référence écrite au langage date de 1962.
Smalltalk est venu ensuite.
Les travaux universitaires sur l’objet sont anciens.
Tout cela est exact.
Mais les faits sont des points.
L’histoire commence lorsque nous décidons comment relier ces points.
Dire qu’un concept existait en 1962 ne dit pratiquement rien des raisons pour lesquelles des entreprises l’ont adopté — ou ne l’ont pas adopté — vingt ou trente ans plus tard.
L’histoire académique demande :
« Quand cette idée est-elle apparue ? »
L’histoire industrielle demande :
« À quel moment des entreprises ont-elles estimé qu’elles n’avaient plus réellement le choix ? »
Et surtout :
« Qu’est-ce qui les y a contraintes ? »
Ce sont deux vérités différentes construites à partir de faits qui, eux, peuvent parfaitement être identiques.
J’ai vécu une partie de cette histoire.
Et je peux affirmer au moins ceci : nous n’avons pas changé de méthodes, de langages et de paradigmes uniquement parce que des chercheurs avaient inventé quelque chose de plus élégant.
Nous changions parce que nous étions acculés.
Toujours davantage
- Les ordinateurs devenaient plus puissants.
- La mémoire augmentait.
- Les disques grossissaient.
- Les processeurs accéléraient.
Et, immédiatement, les utilisateurs demandaient davantage.
- Toujours davantage.
- Plus de données.
- Plus de traitements.
- Plus d’écrans.
- Plus de règles métier.
- Plus d’utilisateurs.
- Plus d’intégrations.
- Plus de fonctionnalités.
Les logiciels ont donc grandi.
Puis grandi encore.
Et à mesure qu’ils grandissaient, les moyens que nous utilisions pour les construire atteignaient leurs limites.
C’est, à mes yeux, la véritable histoire des langages informatiques.
Non pas une marche triomphale vers l’élégance.
Une fuite permanente devant la complexité.
Nous avons passé notre temps à monter d’un étage
Au commencement, nous parlions presque directement aux machines.
Puis vint l’assembleur.
Les suites numériques devinrent des instructions symboliques.
MOV.
ADD.
JMP.
C’était déjà une immense amélioration : nous utilisions toujours le langage conceptuel du processeur, mais sous une forme adaptée à notre cerveau.
Puis cela ne suffit plus.
- Les programmes grossissaient.
- Les architectures évoluaient.
- Les besoins augmentaient.
Alors sont arrivés des langages de plus haut niveau.
Et quantité d’autres.
Leur chronologie exacte importe finalement assez peu pour mon propos.
Ils répondaient à des besoins différents, mais ils partageaient une propriété fondamentale :
Ils permettaient à l’être humain de s’éloigner un peu plus de la machine.
Une instruction humaine pouvait désormais se transformer en plusieurs instructions machine.
Le compilateur prenait en charge cette traduction.
Parfois en passant lui-même par de l’assembleur.
Parfois autrement.
Et progressivement, nous avons oublié ce qu’il y avait dessous.
Nous oublions toujours la couche précédente
C’est probablement la constante la plus intéressante de cette histoire.
Chaque fois qu’une nouvelle couche d’abstraction devient suffisamment fiable, nous cessons progressivement de nous intéresser à celle qu’elle masque.
Aujourd’hui, j’écris principalement du C#.
Combien de fois ai-je réellement besoin d’examiner le CIL généré ?
Très rarement.
Et pourtant la Common Language Infrastructure définit précisément ce langage intermédiaire ainsi que l’environnement d’exécution permettant à plusieurs langages de haut niveau de partager une même infrastructure.
Combien de développeurs .NET inspectent quotidiennement le code machine finalement exécuté par leur processeur ?
Presque aucun.
Cela ne signifie pas que le CIL ou l’assembleur ont disparu.
Cela signifie quelque chose de beaucoup plus intéressant :
Ils ont disparu de notre champ de préoccupation.
Ils sont toujours là.
Mais nous n’avons plus besoin de penser avec eux.
Et lorsqu’on observe l’histoire de la programmation sous cet angle, une question devient difficile à éviter.
Et si C#, Java et les autres étaient simplement les prochains assembleur ?
Puis nous avons inventé les LLM.
Et cette fois, quelque chose change profondément.
Pour la première fois, nous disposons d’une couche d’abstraction capable de recevoir nos intentions dans le langage que nous utilisons déjà entre humains. (Pour ceux qui savent encore le parler, le wesh fait des ravages malgré tout...).
Plus besoin d’apprendre une syntaxe pour lui dire ce que nous voulons.
Je peux écrire :
« Analyse ce projet, trouve l’origine de cette concurrence d'accès, propose une correction qui respecte l’architecture existante et ajoute les tests permettant d’éviter une régression. »
La formulation peut rester imparfaite.
Je peux préciser.
Discuter.
Contredire.
Ajouter du contexte.
Demander une autre solution.
Et la machine peut ensuite écrire le C# que j’aurais auparavant dû produire moi-même.
Nous venons potentiellement d’ajouter un nouvel étage à la pile :
Intention humaine → langage naturel → IA → langage de programmation → représentation intermédiaire → code machine
Or l’histoire nous a appris quelque chose.
Lorsqu’un nouvel étage fonctionne suffisamment bien, les humains finissent par oublier celui qui se trouve juste dessous.
Pourquoi en irait-il autrement cette fois ?
« Tu développes en quoi ? »
Pendant des décennies, cette question avait du sens.
— Tu développes en quoi ?
— En C++.
— En Delphi.
— En Java.
— En C#.
— En Python.
Cette réponse disait énormément de choses sur nous.
Elle indiquait souvent notre environnement technique, nos outils, nos habitudes, parfois notre secteur d’activité.
Elle devenait presque une identité.
Nous étions « développeurs C++ ».
« Développeurs Java ».
« Développeurs .NET ».
Mais peut-être sommes-nous en train de vivre les dernières années pendant lesquelles cette question signifie réellement :
« Quel langage écris-tu ? »
Demain, « Tu développes avec quoi ? » pourrait vouloir dire :
— Avec quel modèle ?
— Avec quel agent ?
— Avec quel environnement agentique ?
— Avec quels outils ?
— Avec quelle chaîne de vérification ?
— Avec quel système de tests et de validation ?
Et quelqu’un pourrait parfaitement produire une application .NET sans se considérer une seule seconde comme « développeur C# ».
Comme aujourd’hui je produis du code machine sans me considérer comme programmeur assembleur.
Le plus intéressant est encore après
On pourrait s’arrêter ici et conclure que nous allons simplement remplacer le C# par le français ou l’anglais.
Je pense que ce serait manquer la moitié du phénomène.
Pourquoi une IA devrait-elle éternellement écrire du C# ?
Voilà la vraie question.
Nos langages de programmation sont extraordinaires.
Mais ils possèdent une caractéristique dont nous parlons rarement :
Ils ont été conçus pour nous.
- Pour notre cerveau.
- Pour notre mémoire limitée.
- Pour notre manière de découper les problèmes.
- Pour notre besoin de donner des noms aux choses.
- Pour notre besoin de relire.
- Pour notre besoin de maintenir.
- Pour notre besoin de communiquer avec d’autres humains.
Nous inventons des classes.
- Des méthodes.
- Des interfaces.
- Des variables joliment nommées.
- Des conventions.
- Des indentations.
- Des commentaires.
- Des modules.
- Des namespaces.
Une bonne partie de cette organisation existe pour permettre à notre pauvre cerveau biologique de conserver une représentation mentale d’un logiciel trop complexe pour lui.
Or que se passe-t-il si ce ne sont progressivement plus des humains qui écrivent et relisent ce code ?
Pourquoi imposer nos béquilles intellectuelles à une IA ?
Une IA a-t-elle réellement besoin que la variable s’appelle customerRepository ?
A-t-elle besoin que la méthode fasse moins de vingt lignes parce qu’un humain finirait autrement par s’y perdre ?
A-t-elle besoin que le code soit organisé d’une manière que nous jugeons « élégante » ?
Peut-être.
Pour l’instant.
Parce que nous sommes toujours dans la boucle.
Parce que nous devons contrôler ce qu’elle fait.
Parce que nos compilateurs, nos outils, nos analyseurs et nos systèmes existants utilisent ces représentations.
Mais à terme ?
Les compilateurs utilisent déjà massivement des représentations intermédiaires qui n’ont pas été conçues comme des langages agréables à utiliser quotidiennement par un développeur.
LLVM IR se définit précisément comme une représentation intermédiaire commune capable de représenter des langages de haut niveau et d’être utilisée par les différentes phases de compilation.
Pourquoi une intelligence artificielle ne finirait-elle pas par utiliser ou inventer d’autres représentations intermédiaires particulièrement adaptées à son fonctionnement ?
À ce moment-là, C#, Java, C++ ou Python pourraient ne même plus être nécessaires dans certaines chaînes de production.
Pas parce qu’ils seraient devenus de mauvais langages.
Simplement parce qu’ils auraient accompli leur fonction historique.
Borland avait déjà compris le problème humain
Ce qui est amusant, avec le recul, c’est que l’on retrouve précisément cette préoccupation dans l’histoire de Turbo Pascal.
Turbo Pascal mise à jour 5.5, en 1989, introduisit l’orienté objet dans cette lignée du langage. Le manuel Borland de l’époque explique lui-même que son modèle objet se rapproche davantage de C++ que de Smalltalk et insiste sur le fait que Turbo Pascal est destiné au développement de production plutôt qu’à la recherche.
Mais le plus révélateur se trouve peut-être dans la publicité.
Borland présentait Turbo Pascal 5.5 comme le langage objet « pour le reste d’entre nous » et insistait explicitement sur la possibilité, pour un programmeur Turbo Pascal existant, de passer facilement de la programmation structurée à la programmation orientée objet, tout en conservant la compatibilité avec les sources antérieures.
Tout est là.
On ne demandait pas au programmeur de jeter ce qu’il savait.
- On lui construisait un pont.
- On conservait Pascal.
- On conservait ses habitudes.
- On conservait ses structures.
- On lui ajoutait progressivement les objets.
Puis Delphi 1 est arrivé le 14 février 1995 avec son environnement graphique, sa VCL et son support de Windows 3.1.
Et malgré tous ces efforts pour rendre la transition acceptable, le directeur informatique dont je parlais plus haut estimait encore qu’une partie de ses développeurs ne réussirait pas à franchir ce pont.
Voilà ce que les chronologies technologiques montrent rarement.
La compatibilité n’est pas uniquement une caractéristique du logiciel.
Elle est aussi une caractéristique des êtres humains.
Et c’est là que l’IA est différente
Le passage à l’objet demandait un effort.
Il fallait changer sa façon de concevoir.
Il fallait apprendre l’encapsulation.
- L’héritage.
- Le polymorphisme.
- La responsabilité des objets.
- Les relations entre eux.
Et surtout accepter qu’une partie de ce que nous maîtrisions auparavant ne suffisait plus.
La transition était donc lente.
- Il fallait former.
- Convaincre.
- Attendre.
- Recruter de nouveaux profils.
- Laisser partir certains autres.
Les entreprises possédaient une sorte de constante de temps humaine qui ralentissait la révolution.
Avec l’IA, cette constante pourrait être beaucoup plus faible.
Parce que l’interface proposée n’est pas plus compliquée que l’ancienne.
Elle est plus simple.
Elle consiste à parler.
Cela ne signifie évidemment pas que piloter correctement une IA soit facile (ni que parler le français correctement soit une évidence à notre époque).
Ceux qui le pensent découvrent rapidement l’écart entre obtenir du code et obtenir un bon système logiciel.
Mais le premier contact ne nécessite pratiquement aucune formation.
Il suffit d’essayer.
Et c’est là que quelque chose a basculé. Un garçon boucher peut se bricoler un soft pour compter ses steaks et ses merguez en faisant fièrement du "vibe coding" et pérorer sur les réseaux sociaux que les informaticiens sont morts. Oui, bien sûr, et la marmotte etc... (Sans rire je me suis déjà pris la tête avec des gens comme ça sur les réseaux dans les derniers mois, cet article ce n'est que du vécu).
« Tu as compris ce que j’ai compris ? »
Depuis quelque temps, j’ai une sensation étrange lorsque je parle avec d’autres informaticiens expérimentés.
Nous n’avons pas besoin de nous expliquer très longtemps.
Il existe presque ce moment de silence où chacun regarde l’autre en pensant :
« Tu as compris ce que j’ai compris ? »
Et le regard d’en face répond :
« Oui. »
Nous avons vu ce que ces outils étaient capables de faire.
Pas dans une démonstration commerciale.
Sur notre code.
Dans nos projets.
Avec nos contraintes.
Avec leurs défauts aussi.
Nous savons qu’ils hallucinent.
Nous savons qu’ils produisent parfois du code presque correct, ce qui est souvent pire que du code évidemment faux.
L’enquête Stack Overflow 2025 est d’ailleurs loin de décrire une profession béatement confiante : 46 % des répondants déclaraient davantage se méfier de l’exactitude des outils IA qu’y faire confiance, et 66 % citaient les solutions « presque correctes » parmi leurs principales frustrations.
Mais dans la même enquête, 84 % déclaraient déjà utiliser ou prévoir d’utiliser des outils d’IA dans leur processus de développement, et 51 % des développeurs professionnels interrogés en faisaient un usage quotidien.
Méfiance et adoption peuvent donc progresser simultanément.
Cela pourrait même être le signe d’une technologie devenue sérieuse.
Nous ne l’utilisons plus parce qu’elle nous impressionne.
Nous l’utilisons malgré ses défauts et parce qu'on sent bien que même ceux qui ne veulent pas le dire s'en servent. Un peu comme l'onanisme, tout le monde le pratique mais en parler serait jugé honteux...
La productivité ? Attention aux chiffres magiques
Je pourrais écrire ici qu’un développeur accompagné d’une IA travaille cinq fois ou dix fois plus vite.
Ce serait spectaculaire.
Ce serait aussi intellectuellement malhonnête.
Nous ne savons pas encore mesurer proprement cette transformation.
METR avait même obtenu en 2025 un résultat particulièrement contre-intuitif : sur seize développeurs open source expérimentés travaillant sur leurs propres dépôts, les outils d’IA disponibles au début de 2025 avaient augmenté le temps nécessaire aux tâches de 19 %. Mais entre deux des tas de LLM de plus en plus puissants sont sortis. Cela ne permet de conclure que pour 2025, pas pour aujourd'hui.
Et d'ailleurs la situation a changé suffisamment vite pour rendre la deuxième expérience elle-même difficile à interpréter.
En février 2026, METR expliquait que certains développeurs refusaient désormais de participer lorsqu’ils risquaient d’être affectés au groupe sans IA (le truc honteux évoqué plus haut...). Les nouvelles mesures suggéraient une accélération, mais avec des biais de sélection suffisamment importants pour empêcher d’en mesurer correctement l’ampleur.
Je trouve cette difficulté presque plus intéressante que le chiffre.
Quelques mois auparavant, on cherchait à savoir si les développeurs allaient utiliser l’IA.
Quelques mois plus tard, certains ne voulaient déjà plus travailler sans elle et n'osaient pas le dire.
Voilà le basculement qui m’intéresse.
On ne peut pas désapprendre ce qu’on vient de voir
C’est peut-être cela qui rend la situation actuelle tellement particulière.
Une fois qu'on sait qu'il y a une porte dérobée dans une pièce et qu'on l'a repérée, il est presque impossible d'y vivre tous les jours sans avoir envie de savoir ce qu'il y a derrière cette porte. Trop tard, on sait qu'elle est là. On veut l'ouvrir. C'est plus fort que tout. Impossible "d'oublier".
Une fois que vous avez confié à un bon agent une tâche qui aurait occupé une journée…
Une fois que vous l’avez vu parcourir plusieurs dizaines de fichiers…
Comprendre l’architecture…
Modifier le code…
Écrire des tests…
Compiler…
Observer ses propres erreurs…
Les corriger…
Puis revenir avec un résultat exploitable…
Il devient très difficile de reprendre exactement le même travail le lendemain comme si vous n’aviez rien vu.
- On peut discuter des chiffres.
- On peut discuter des benchmarks.
- On peut discuter de la qualité.
- On peut discuter des risques.
Mais on ne peut pas effacer l’expérience.
Et c’est probablement ainsi que commencent les vraies ruptures.
Pas lorsque tout fonctionne parfaitement.
Lorsque suffisamment de personnes ont compris qu’elles ne travailleront plus jamais exactement comme avant.
Alors à quoi bon apprendre C# ?
Poussons le raisonnement.
S’il devient progressivement inutile d’écrire soi-même la majorité du code, pourquoi continuerions-nous à enseigner un langage de programmation comme aujourd’hui ?
La question choquera.
Elle doit être posée quand même.
Apprendre pendant des mois les subtilités syntaxiques d’un langage que l’on ne tapera peut-être presque jamais soi-même pourrait effectivement devenir aussi anachronique que d’apprendre le fonctionnement détaillé d’un carburateur pour obtenir son permis sur une voiture électrique.
Mais je ferais ici une distinction importante.
Ne plus enseigner la programmation comme aujourd’hui ne signifie pas ne plus enseigner l’informatique.
Bien au contraire.
Je pense que nous allons devoir enseigner davantage de concepts fondamentaux et moins de syntaxe.
Il faudra toujours comprendre :
- L’algorithmique,
- Les structures de données,
- La complexité,
- Les architectures,
- Les systèmes distribués,
- La concurrence,
- La mémoire,
- La sécurité,
- Les transactions,
- Les réseaux,
- Les bases de données,
- Les invariants,
- Les tests,
- Les effets de bord.
Les recommandations CS2023 de l’ACM, de l’IEEE Computer Society et de l’AAAI vont d’ailleurs encore dans ce sens : elles intègrent explicitement la question de l’IA générative tout en maintenant les fondements algorithmiques, mathématiques, architecturaux et les fondements des langages de programmation dans le socle de la discipline.
La syntaxe, en revanche, pourrait perdre brutalement de sa valeur.
- Savoir écrire une boucle n’est pas la même chose que comprendre un algorithme.
- Savoir déclarer une classe n’est pas la même chose que savoir découper un domaine métier.
- Savoir utiliser async n’est pas la même chose que comprendre la concurrence.
Pendant longtemps, nous avons pu confondre ces compétences parce que l’une était nécessaire pour exprimer l’autre.
L’IA est en train de les dissocier.
Le paradoxe : moins de code, mais davantage d’informatique
Voilà peut-être le paradoxe de la prochaine génération de développeurs.
Elle pourrait écrire beaucoup moins de code…
…et devoir comprendre beaucoup mieux ce qu’est réellement un logiciel.
Lorsque la production devient abondante, le problème change.
Le problème n’est plus :
« Peux-tu produire cette chose ? »
Il devient :
« Peux-tu déterminer si cette chose est correcte ? »
Puis :
« Peux-tu expliquer pourquoi elle est correcte ? »
Puis :
« Peux-tu garantir qu’elle restera correcte lorsque le contexte changera ? »
Ce n’est plus un métier de frappe.
C’est un métier de jugement.
Et cela me conduit à une conclusion qui peut sembler paradoxale :
Les IA pourraient détruire beaucoup de postes de programmeurs tout en augmentant la valeur des véritables informaticiens.
Les deux populations se recouvrent évidemment aujourd’hui.
Mais peut-être beaucoup moins demain.
Et les ESN dans tout cela ?
Il existe ensuite un éléphant assez volumineux dans la pièce.
Les SSII devenues ESN.
Je ne parle évidemment pas de toutes.
Certaines ont conservé un véritable savoir-faire de conception, d’architecture, d’intégration et de réalisation.
Mais une partie non négligeable du secteur s’est progressivement organisée autour d’une idée beaucoup plus simple, plus rentable et avec zéro risque et responsabilité :
Placer le maximum de personnes chez le client et espérer qu’elles y restent le plus longtemps possible.
Mais le jour-homme est une unité économique formidable tant qu’un problème important nécessite beaucoup d’hommes et beaucoup de jours.
Mais que se passe-t-il si cette relation cesse d’être vraie ?
Si un senior correctement équipé peut produire en quelques semaines ce qui demandait auparavant plusieurs personnes pendant plusieurs mois, le problème du client est résolu.
Celui de l’ESN commence !
Comment facturer cinq personnes pendant six mois si une personne très compétente, assistée de plusieurs agents, peut obtenir un résultat comparable beaucoup plus rapidement ?
- On pourra résister.
- On pourra créer des processus.
- Ajouter des réunions.
- Inventer de nouvelles couches de gouvernance.
- Expliquer que l’IA ne comprend pas le métier.
Tout cela sera parfois vrai. Mais on ne triche pas avec les faits bien longtemps. C'est une stratégie de survie à courts termes, or nous ne faisons pas face à un ennui passager, à une élection présidentielle qui, comme à chaque fois, ralentit le business qui repart ensuite peu importe le résultat. Attention, danger, le phénomène qui nous occupe ici réclamera plus que quelques tours de magie car il est là pour rester !
Un modèle économique qui facture essentiellement du temps possède un problème structurel lorsque la technologie commence précisément à économiser ce temps. Quand le temps et le nombre de personnes pour le produire deviennent anecdotiques, les boîtes d'intérim déguisées en ESN ont des sourcis à se faire...
Je ne pleurerai pas. Ils ont été les fossoyeurs de l'informatique sérieuse que les IA font revivre. Celle des analystes, des architectes et non des fourmis corvéables à souhait engagées de façon précaire "sur mission". Si ces boîtes disparaissent faute de savoir s'adapter ce ne sera que "retour de karma".
Dura lex, sed lex.
Le plateau comme symbole de puissance
Il y a aussi quelque chose de presque anthropologique dans nos organisations.
Certains dirigeants ont longtemps aimé les grands plateaux de développeurs, surtout les patrons français, le côté vieille noblesse qui prouvait sa puissance en montrant ses nombreux chevaux dans leurs stalles et qui aujourd'hui exhibent leurs plateaux de développeurs dans des open-spaces où les humains sont parqués comme des poules pondeuses par l'industrie agroalimentaire...
- Cent personnes.
- Deux cents personnes.
- Des rangées de bureaux.
- Des écrans partout.
- Des chefs d’équipe.
- Des responsables de pôles.
- Des réunions.
- Des organigrammes.
C’était visible. Autour que leur grosse cylindrée de marque.
Impressionnant.
Une manifestation de puissance. Ou un fantasme de puissance qui vient compenser une impuissance ?
Comme autrefois on pouvait montrer ses terres, ses chevaux ou ses usines.
L’informatique, elle, devient de moins en moins spectaculaire à regarder.
La puissance se compacte.
Et la puissance intellectuelle produite par l’IA se compacte encore davantage. Et je ne parle du Télétravail qui tombe sous le sens dans une profession équipée de matériel puissant, de liaisons fibrées et du savoir-faire pour organiser en quelques secondes une réunion à 5 personnes réparties sur le globe...
Demain, la production d’un plateau entier pourra peut-être tenir dans quelques machines, quelques abonnements à des modèles et une poignée de personnes réellement très compétentes. Un bureau, deux architectes séniors et une quelque DGX posés dans un coin...
Cela produira de drôles de salles.
Beaucoup d’espace.
Beaucoup moins de monde.
Et probablement quelques directions générales très nostalgiques de l’époque où la puissance pouvait se compter visuellement en têtes, comme le bétail. Les DRH feront aussi certainement la tête, mais ce ne sera que juste retour de bâton, l'esclave qui pactisait contre ses frères était généralement mal vu à l'heure de l'abolition... Le simple changement de nom de "direction du personnel" à "direction des ressources humaines" est une insulte grave faite à tous les salariés dans le respect qu'ils méritent à être considérés comme des humains et non des ressources. Je ne me ferai pas que des amis avec cette remarque mais l'invite sérieusement les concernés qui liront à s'interroger sincèrement. Tous ne sont pas mauvais, je garde confiance en la nature humaine.
Ce ne sont pas seulement les développeurs qui doivent réfléchir
Les développeurs ont évidemment compris qu’ils étaient concernés.
Mais ils ne sont pas seuls.
- Les DSI doivent réfléchir.
- Les directions générales doivent réfléchir.
- Les recruteurs doivent réfléchir.
- Les écoles doivent réfléchir.
- Les enseignants doivent réfléchir.
- Les cabinets de conseil doivent réfléchir.
- Les ESN doivent réfléchir.
- Les éditeurs doivent réfléchir.
Tous ceux dont le modèle repose sur une certaine rareté de la capacité à produire du logiciel doivent réfléchir.
Car cette rareté est précisément ce que l’IA attaque.
Serons-nous les derniers à parler couramment C# ?
J’appartiens à une génération qui a appris les langages comme on apprend réellement une langue.
- Nous les avons pratiqués.
- Nous avons pensé dedans.
- Nous avons connu leurs bizarreries.
- Leurs idiomes.
- Leurs limitations.
- Leurs évolutions.
Je peux regarder du C# et presque immédiatement sentir qu’un morceau de code « ne va pas ».
Cette relation intime avec un langage pourrait devenir beaucoup plus rare.
Les futurs informaticiens connaîtront probablement encore les concepts.
Certains continueront certainement à connaître profondément les langages.
Il restera des spécialistes.
Comme il reste aujourd’hui d’excellents programmeurs assembleur. Rares, et donc chers, donc embauchés qu'en dernier recours car le système fordien a horreur de la compétence rare. Chaque élément de la chaîne doit être interchangeable, machines comme humains, tout le business est basé là-dessus.
Mais la majorité ?
Peut-être que dans vingt ans quelqu’un regardera nos discussions actuelles sur les nouveautés de C#, Java ou C++ avec la même curiosité attendrie que nous regardons aujourd’hui des débats sur l’optimisation d’un code assembleur 8086.
Pas parce que ces débats étaient stupides.
Parce que le niveau auquel se situe le problème aura changé.
La mort des langages ?
Le titre de cet article est donc volontairement excessif.
Je ne pense pas que C#, Java, C++, Rust ou Python vont nécessairement disparaître demain matin.
Certains pourraient rester très longtemps.
Les représentations formelles resteront indispensables.
Les machines ne vont pas exécuter des intentions vagues exprimées dans un français approximatif.
Nous aurons toujours besoin de déterminisme, de types, de contrats, de contraintes et de représentations vérifiables.
Mais rien n’impose que nous, humains, continuions à manipuler directement ces représentations.
C’est cela, la véritable machine à effacer les langages.
L’IA ne les efface peut-être pas de l’ordinateur.
Elle les efface entre l’ordinateur et nous.
Exactement comme le compilateur a effacé une grande partie de l’assembleur de notre quotidien.
Comme le runtime a effacé le code machine.
Comme les frameworks ont effacé quantité de détails techniques que nous n’avons plus besoin de connaître quotidiennement.
La couche existe.
Nous cessons simplement de la voir.
L’homme qui chuchotait à l’oreille de GPT-6
Alors que faudra-t-il savoir faire ?
Probablement beaucoup moins taper.
Et beaucoup plus penser.
- Savoir expliquer précisément un problème.
- Savoir fournir le bon contexte.
- Savoir découper une mission.
- Savoir contraindre un agent.
- Savoir choisir ses outils.
- Savoir mesurer.
- Tester.
- Auditer.
- Observer.
- Détecter les incohérences.
Reconnaître une mauvaise architecture derrière un code parfaitement compilable.
Comprendre suffisamment profondément le métier et l’informatique pour pouvoir dire à une machine extrêmement productive :
« Non. Ce que tu viens de faire est faux. Recommence. »
Peut-être appellerons-nous cela encore « développer ».
Peut-être pas.
Peut-être que « développeur C# » paraîtra un jour aussi étrange que « programmeur opcode ».
Et peut-être que la compétence rare sera de devenir celui qui sait obtenir d’une IA ce que les autres n’arrivent pas à obtenir.
L’homme qui chuchotait à l’oreille de GPT-6.
L’image prête à sourire.
Mais le fond, lui, est sérieux.
Et les autres ?
Car nous arrivons au point inconfortable.
Tout le monde ne franchira pas cette transition.
Je l’ai déjà vu.
Il y a trente ans, un directeur informatique a refusé une technologie qu’il savait bonne parce qu’il connaissait les personnes qui travaillaient pour lui et savait que certaines ne pourraient pas suivre.
La différence est qu’à l’époque il pouvait décider d’attendre (mais a-t-il tenu lui-même longtemps comme DSI ? je ne suis pas certain, il a probablement été remplacé par plus jeune, plus mordant, plus réformateur).
L’entreprise pouvait continuer quelques années avec ses technologies existantes.
Le marché lui en laissait probablement le temps.
Je ne suis pas certain que nous disposerons cette fois du même luxe.
Et c’est peut-être cela qui me préoccupe le plus.
Pas l’IA.
Pas les LLM.
Pas la disparition éventuelle de C#.
La vitesse.
Nous sommes des animaux beaucoup plus que des machines rationnelles
Nous aimons raconter l’histoire technologique comme une succession de décisions logiques.
- Une meilleure technologie apparaît.
- On l’évalue.
- Elle démontre sa supériorité.
- On l’adopte.
- C’est très joli.
Ce n’est pas ainsi que les humains fonctionnent.
- Nous avons peur.
- Nous protégeons nos habitudes.
- Nos positions sociales.
- Nos revenus.
- Notre prestige.
- Nos équipes.
- Parfois nos amis.
Nous pouvons parfaitement savoir qu’une décision est rationnellement préférable et choisir l’autre.
Nous pouvons refuser une technologie parce qu’elle menace quelqu’un que nous aimons.
Ou l’adopter parce que nous avons peur que le concurrent le fasse avant nous.
Nous sommes capables de défendre avec une extraordinaire intelligence des décisions prises pour des raisons parfaitement irrationnelles.
C’est aussi cela qu’il faudra intégrer dans toutes les prévisions sur l’IA.
Les faits ne suffisent pas.
Les courbes ne suffisent pas.
Les benchmarks ne suffisent pas.
Les faits sont les points.
Ce sont les humains qui tracent les lignes entre eux.
Cette fois, la ligne se dessine très vite
Je ne sais pas exactement où nous allons.
Personne ne le sait.
- Je ne sais pas quels langages existeront dans vingt ans.
- Je ne sais pas combien de développeurs seront nécessaires.
- Je ne sais pas à quoi ressembleront les écoles d’informatique.
- Je ne sais pas quelles ESN auront réussi leur transformation.
- Je ne sais même pas si le mot « prompt » nous fera rire dans dix ans tellement il paraîtra rudimentaire.
Mais je sais une chose.
Nous avons vu quelque chose.
Nous l’avons touché.
Nous l’avons utilisé.
Et beaucoup d’entre nous ont compris au même moment qu’un verrou venait de sauter.
On peut encore discuter de la vitesse.
On peut encore discuter de l’ampleur.
On peut encore discuter des conséquences.
Mais il devient très difficile de faire comme si nous n’avions rien vu.
L’intelligence, dit-on, est la faculté de s’adapter.
Je ne sais pas si cette définition est exacte.
Mais nous allons probablement avoir une occasion grandeur nature de la tester !
Alors la vraie question n’est peut-être plus :
« Est-ce que l’IA va changer notre métier ? »
Cette question-là commence à dater.
La question est désormais :
« Maintenant que nous avons compris qu’il change, qu’allons-nous faire ? »
Stay Tuned!
Tag(s) à suivre :