Informaticien depuis 35 ans, ma touche préférée est devenue Enter

Informaticien depuis 35 ans, ma touche préférée est devenue Enter

Je n’ai probablement jamais été aussi productif de toute ma carrière. Et pourtant, il m’arrive de passer une bonne partie de mes journées à regarder des intelligences artificielles travailler. Petit récit, vu de l’intérieur, d’une révolution qui transforme notre métier plus vite que nos habitudes.

Difficulté: accessible. Aucune ligne de code dans cet article, ce qui, vu le sujet, est parfaitement cohérent.

Introduction

J’ai plus de 35 ans d’informatique derrière moi et, pendant toutes ces années, ce que j’ai aimé dans ce métier n’a jamais vraiment été de taper du code. Ce que j’aimais, c’était le problème: ce moment où l’on se retrouve devant quelque chose qu’on ne sait pas encore faire et où il faut chercher, essayer, se tromper et recommencer jusqu’à trouver la petite idée qui débloque tout. J’ai été architecte de très gros systèmes, j’ai toujours essayé de garder une longueur d’avance technique et, avec Flutter, j’ai poussé la technologie assez loin pour être reconnu comme l’un des experts de référence au niveau mondial. La partie « présentation », en revanche, m’a toujours un peu moins passionné. Déplacer un bouton de trois pixels vers la gauche ou arbitrer entre deux nuances de bleu n’a jamais été le sommet de mes journées, et les designers qui ont travaillé avec moi pourront en témoigner.

Aujourd’hui, je ne programme pratiquement plus. Personne ne me l’interdit, mon IDE fonctionne parfaitement et je pourrais très bien ouvrir un fichier pour écrire une fonction à la main, comme au bon vieux temps. C’est simplement devenu très difficile d’expliquer pourquoi je le ferais.

De l’assistant qu’on tient par la main au collègue à qui l’on confie une mission

Depuis avril 2024, je suis de très près l’évolution des frontier models et je les utilise au quotidien, de GPT-4o et Claude Sonnet 3.5 à l’époque jusqu’à GPT-6 Astra et Claude Fable 5.1 aujourd’hui. Dans la suite de cet article, je les appellerai mes « copains ». Pas parce que je confonds un LLM avec un ami, mais parce que nos échanges ressemblent de plus en plus à ceux qu’on aurait avec un collègue brillant, disponible à toute heure et doté d’une qualité rare: il ne lève jamais les yeux au ciel quand je change d’avis pour la quatrième fois.

Au début, la relation était nettement moins reposante. En 2024 et pendant une bonne partie de 2025, il fallait soigner chaque prompt, découper les tâches, brider ses ambitions et tout vérifier, systématiquement. Je demandais quelque chose, mon copain partait légèrement à côté, je précisais, il corrigeait trois choses et en cassait deux autres, je lui signalais les deux autres, il s’excusait très poliment… puis allait casser quelque chose ailleurs. C’était déjà extraordinairement utile, mais on travaillait encore avec l’IA, un peu comme avec un assistant très doué qu’il ne fallait jamais quitter des yeux.

Le premier semestre 2026 a tout changé, du moins dans mon utilisation quotidienne. Les modèles se sont mis à comprendre ce que je voulais dire même quand je l’expliquais mal, à reformuler mes requirements mieux que moi, à débusquer les non-dits et à creuser les analyses bien plus loin que ce que j’avais demandé. Il m’arrive régulièrement de lire la reformulation d’une idée que j’avais lancée de manière brouillonne et de penser: « Oui, c’est exactement ça. C’est même mieux dit que dans ma tête. » C’est flatteur pour l’outil et légèrement vexant pour l’auteur. Depuis juillet, une nouvelle marche a été franchie: les agents tiennent leur objectif sur la durée, lancent eux-mêmes les tests, lisent les résultats, corrigent et retestent, et vont parfois jusqu’à prendre le contrôle d’un environnement pour vérifier en temps réel que ce qu’ils viennent de construire fonctionne vraiment. On ne parle plus d’autocomplétion intelligente, on parle d’un collègue à qui l’on confie une mission.

Et moi, dans tout ça? Je suis devenu manager. Sans augmentation, évidemment.

Ma journée type: analyser, approuver, Enter… et attendre

Concrètement, sur la plupart de mes projets (à l’exception de ceux où le client préfère se passer de l’IA, ce qui est parfaitement son droit), mon workflow tient en quelques lignes. J’ai une idée, je l’explique à un copain et je lui demande de l’analyser, puis de contre-analyser sa propre analyse, parce que l’expérience m’a appris qu’une idée qui paraît géniale pendant cinq minutes mérite précisément qu’on essaie de la démolir pendant les dix suivantes. Nous affinons ensemble, il me propose un plan, je le relis, je corrige ce qui me gêne et j’appuie sur Enter.

Ensuite, j’attends.

Comme attendre un seul agent devient vite frustrant, j’en lance un deuxième sur un autre projet, puis un troisième, parfois un quatrième ou un cinquième. Pendant quelques minutes, le sentiment de puissance est grisant: j’ai l’impression d’être devenu une multinationale à moi tout seul. Puis vient ce moment étrange où le premier agent réfléchit, le deuxième lance ses tests, le troisième lit la documentation d’une librairie dont j’ignorais l’existence le matin même, le quatrième attend visiblement quelque chose de ma part, et moi, je bois mon café. Je pourrais d’ailleurs gagner encore du temps en dictant mes instructions au micro, mais je continue à taper par respect pour mon entourage, qui n’a aucune envie de m’entendre répéter toute la journée « Non, ce n’est pas ce que je voulais dire, reprends depuis le début ».

Le plus drôle, c’est que je lance parfois tellement de choses en parallèle que je ne sais plus très bien où j’en suis. Il m’est déjà arrivé de fermer une fenêtre pour découvrir qu’un agent avait terminé depuis vingt minutes et attendait sagement mon feu vert. Même mes IA finissent donc par s’ennuyer en m’attendant, ce qui est, reconnaissons-le, assez vexant.

Et quand le résultat n’est pas celui que j’espérais? Cela arrive encore, et je serais malhonnête de prétendre le contraire. Mais lorsque j’analyse ces déceptions, j’arrive presque toujours à la même conclusion, assez humiliante: c’était de ma faute. Des instructions trop vagues ou au contraire trop détaillées, des sous-entendus que j’étais le seul à comprendre, pas assez d’exemples, ou l’envie de tout faire d’un seul coup. Savoir exprimer précisément ce que l’on veut est devenu une compétence technique à part entière, et probablement l’une des plus sous-estimées du moment.

Ce n’est pas qu’une impression personnelle

Les chiffres publiés ces derniers mois racontent la même histoire. L’enquête Developer Ecosystem 2026 de JetBrains, menée de mai à juillet auprès de plus de 15.000 développeurs professionnels, indique que 90% d’entre eux utilisent des agents de codage au travail au moins une fois par semaine, et 68% tous les jours. Selon leurs propres estimations, près de la moitié du code qu’ils produisent serait désormais entièrement généré par des agents. Le Dev Barometer de BairesDev, publié en septembre, montre à quelle vitesse les choses bougent: 42% des développeurs interrogés déclarent que l’IA écrit au moins la moitié de leur code, contre 12% un an plus tôt. Ils estiment gagner treize heures de programmation par semaine, mais deux tiers d’entre eux passent aussi plus de temps qu’avant à relire ce que l’IA a produit.

Ce dernier chiffre résume bien la situation. Nous n’avons pas simplement inventé un outil qui permet d’écrire du code plus vite: nous avons commencé à confier la production du code à la machine, tout en gardant pour nous la responsabilité de ce qu’elle produit.

OpenAI a même fabriqué le clavier qui va avec

S’il fallait un objet pour symboliser cette transition, OpenAI l’a sorti en juillet avec le fabricant Work Louder: le Codex Micro, un petit clavier à 230 dollars conçu pour piloter des agents de développement. Chaque touche « agent » s’illumine pour indiquer si l’agent correspondant réfléchit, travaille, attend ou a terminé (en ambre quand il attend après vous, ce qui dans mon cas risque d’être la couleur dominante), un joystick lance des workflows et une molette permet de régler le niveau de raisonnement du modèle. Le premier produit matériel de l’histoire d’OpenAI est donc un clavier. Un clavier pour ne plus taper.

Prenons quelques secondes pour apprécier le chemin parcouru. Pendant des décennies, nous avons perfectionné les claviers pour que les développeurs tapent du code plus vite, et nous fabriquons maintenant des claviers pour surveiller les IA qui tapent le code à notre place, avec une molette pour décider à quel point notre collègue artificiel doit se fatiguer les neurones. À ce rythme, le clavier du développeur de 2030 n’aura plus que deux touches: Enter et « Non, ce n’est pas ce que je voulais dire ». Éventuellement une troisième, « Tu es sûr? », parce que la prudence reste une vertu professionnelle.

Mes connaissances valent moins, mon expérience vaut davantage

Sur un point, je n’ai plus aucune illusion: en matière de connaissances pures, je ne fais pas le poids. Un frontier model connaît des langages que je n’ai jamais pratiqués, des frameworks que je n’ai jamais ouverts, des algorithmes que j’ai oubliés depuis trente ans et plus de publications que je ne pourrais en lire en plusieurs vies. Quand je dis qu’il en sait mille fois plus que moi, ce n’est évidemment pas une mesure scientifique, mais c’est à peu près ce que je ressens.

Les certifications en deviennent d’ailleurs assez savoureuses. Quand je prépare un examen, je demande à mon copain d’être mon instructeur: il construit le programme, m’explique chaque domaine dans le détail, m’interroge, repère mes lacunes et me prépare des examens blancs. Je réussis, je reçois un joli certificat attestant que moi, humain, je maîtrise la matière, et au premier vrai problème professionnel sur le sujet, je lui dis: « Copain, analyse-moi ça. » Il m’a donc appris ce qu’il fallait pour prouver que je le savais, afin que je puisse ensuite lui demander de l’appliquer à ma place. La boucle paraît absurde, mais elle ne l’est qu’à moitié: c’est précisément parce que je connais la matière que je sais reconnaître quand sa réponse est bonne… et surtout quand elle ne l’est pas.

Même le code des autres a perdu son mystère. Reprendre un projet existant a longtemps été une aventure, avec comme point culminant cette fonction de 1.800 lignes que personne n’osait toucher parce qu’elle semblait gérer simultanément la facturation, l’impression et probablement la machine à café. Aujourd’hui, je confie le repository à un copain qui en reconstitue l’architecture et les dépendances en quelques minutes, que le code soit spaghetti ou parfaitement structuré, et sans jamais se plaindre. Il lui manque juste cette grande tradition du métier qui consiste à ouvrir le projet de son prédécesseur en s’exclamant « Mais quel abruti a écrit ça? », avant de lancer un git blame et de découvrir que c’était soi-même, trois ans plus tôt. Nous gardons donc une nette avance culturelle.

Là où l’expérience fait toute la différence, c’est dans le jugement. Trente-cinq ans de projets m’ont appris à regarder une architecture techniquement magnifique et à sentir qu’elle est beaucoup trop compliquée pour le problème posé, à repérer le choix qui coûtera très cher dans trois ans, ou à me méfier d’une démo impeccable qui deviendra un cauchemar à maintenir. Ils m’ont surtout appris une règle d’or: quand une solution paraît extraordinairement élégante, il faut commencer par chercher où se cache le problème. C’est d’autant plus précieux que les IA ont un talent remarquable pour présenter une mauvaise idée avec suffisamment d’assurance pour vous donner envie de la mettre en production. Mon rôle consiste désormais à fixer la destination: mon copain propose l’itinéraire et prend le volant, et je vérifie qu’il n’a pas décidé de passer par Vladivostok pour aller de Bruxelles à Paris.

Alors oui, je m’ennuie parfois. Mais c’est un ennui de privilégié

Je ne regrette pas une seconde les demi-journées passées à comprendre pourquoi une librairie refusait de compiler, les merge conflicts de 2.000 lignes ou le bug d’encodage qui n’apparaissait que le vendredi après 17 heures. L’IA a fait disparaître une quantité phénoménale de travail pénible et me permet de construire incomparablement plus: explorer une idée en quelques jours plutôt qu’en plusieurs semaines, confronter plusieurs architectures avant de choisir, travailler dans une technologie que je connais à peine, mener plusieurs projets de front. De toute ma carrière, je n’ai jamais disposé d’autant de possibilités.

Ce qui me manque parfois, c’est la difficulté. Pas la difficulté inutile, mais celle qui vous garde plusieurs heures devant un problème jusqu’au petit déclic: « Ça y est, j’ai trouvé. » Donnez à un amateur de mots croisés un bouton « Résoudre la grille » et sa productivité devient spectaculaire: il peut désormais boucler 300 grilles par jour. Vous avez juste légèrement raté le concept des mots croisés. C’est un peu ce que je ressens, certains jours, devant mes écrans.

Mais à y regarder de plus près, la difficulté n’a pas disparu, elle a changé d’étage. La question n’est plus « comment vais-je programmer ça? », mais « est-ce vraiment ça qu’il faut construire, comment l’exprimer sans ambiguïté, quelles contraintes imposer et comment vérifier que le résultat est réellement bon? ». Une étude du NBER publiée en mai, Writing Code vs. Shipping Code, l’illustre joliment: en suivant plus de 100.000 développeurs GitHub, ses auteurs constatent que les agents autonomes font pratiquement tripler le nombre de commits, alors que les releases effectivement livrées n’augmentent que d’environ 30%. Écrire du code n’est plus le goulot d’étranglement. Décider quel code mérite d’exister, le valider et le livrer, si. Pendant des décennies, nous avons attendu les ordinateurs; ce sont désormais eux qui nous attendent, ce qui ne manque pas d’ironie quand on repense aux heures passées devant les barres de progression de Windows 98.

Pas de marche arrière possible, et c’est tant mieux

On parle beaucoup d’un éventuel ralentissement des frontier models. Imaginons même le scénario extrême: plus aucun progrès pendant cinq ans. Est-ce que je reviendrais à ma manière de travailler de 2023? Pas une seconde. Les modèles actuels suffisent déjà à transformer en profondeur la façon de produire du logiciel, et il reste des années de gains à récolter simplement en apprenant à bien les utiliser. Beaucoup d’organisations s’en servent encore comme d’un Google un peu plus malin, d’autres attendent prudemment d’y voir plus clair avant d’autoriser les agents (ce qui est plutôt sage tant qu’aucune gouvernance n’est en place), et certaines organisent encore une réunion de trois heures pour décider si l’équipe peut installer un plugin. La technologie a pris plusieurs longueurs d’avance sur les organisations, et c’est là que se trouve aujourd’hui le vrai chantier: gouvernance, sécurité, confidentialité des données, conformité et adaptation des processus.

Le métier d’informaticien ne disparaît donc pas. Ce qui s’efface progressivement, c’est le programmeur en tant que producteur principal du code. La compétence remonte d’un étage: le code devient abondant et c’est le jugement qui devient rare, c’est-à-dire la capacité à transformer un besoin flou en exigences exploitables, à arbitrer entre des compromis, à reconnaître une mauvaise solution même quand elle fonctionne et à assumer la responsabilité du résultat. À ce jeu-là, 35 ans de projets, de réussites et de quelques échecs mémorables (et très instructifs) ne sont pas un handicap. C’est un levier.

Et maintenant?

Soyons clairs: je n’assiste pas tristement à la fin de ma carrière. Je suis aux premières loges d’une transformation que je trouve fascinante, même si elle produit parfois des situations franchement absurdes. Après 35 ans passés à apprendre à parler aux ordinateurs, les voilà qui comprennent suffisamment bien notre langue pour faire une grande partie du travail à notre place. Nous expliquons, ils analysent et construisent, nous vérifions, arbitrons et assumons. Puis nous appuyons à nouveau sur Enter.

Ce matin encore, j’ai lancé quatre agents sur trois projets différents. Je viens de vérifier: tout le monde travaille, sauf moi. Je vais donc aller me chercher un café. Ça, au moins, je tiens à le faire moi-même.

Et si vous vous demandez comment faire travailler ces « copains » dans votre organisation sans qu’ils passent par Vladivostok, c’est précisément mon métier. Parlons-en.

Sources

• JetBrains Research, AI Coding Agents: Adoption Trends, août 2026 (Developer Ecosystem Survey 2026, plus de 15.000 développeurs professionnels, données collectées de mai à juillet 2026).
• BairesDev, Dev Barometer Q3 2026, septembre 2026 (705 développeurs dans plus de 60 pays).
• Mert Demirer, Leon Musolff et Liyuan Yang, Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools, NBER Working Paper 35275, mai 2026.
• OpenAI et Work Louder, Codex Micro, juillet 2026.