En bref — l'IA agentique ne supprime pas le métier de développeur, elle en déplace la valeur. Hier, la légitimité venait de savoir quoi utiliser et pourquoi ; aujourd'hui, n'importe qui peut prétendre bâtir un système critique en pilotant une IA. Entre ces deux mondes, une question décide de tout : où place-t-on le curseur de responsabilité de la machine — à l'exécution, ou à la compréhension ? Ma conviction : le métier ne disparaît pas, il se déconstruit pour mieux se reconstruire — et chaque développeur est responsable de ne pas rater cette marche.

Pendant des décennies, ce qui faisait la légitimité d'un développeur expérimenté tenait en une phrase : savoir quoi utiliser, quand, et pourquoi. On apprenait des concepts, on accumulait des cicatrices de production, et c'est cette expérience — anticiper qu'une structure tiendra la charge, qu'un choix d'architecture se paiera plus tard, qu'un raccourci pris aujourd'hui devient une dette demain — qui distinguait le senior du débutant. La valeur n'était pas dans le code produit, mais dans le jugement qui présidait à sa production.

L'IA agentique rebat cette carte. Désormais, n'importe qui peut décrire une intention à un agent et obtenir, en quelques heures, quelque chose qui ressemble à un système d'entreprise. Et je veux être clair d'emblée : ce n'est pas, en soi, une mauvaise nouvelle.

Créer de la valeur vite : ce que l'entreprise attend depuis toujours

Ce que l'IA agentique permet — produire de la valeur rapidement — est précisément ce que les entreprises attendent des développeurs depuis des décennies. Personne, dans une organisation, n'a jamais payé pour de l'élégance technique en soi : on paie pour un problème résolu, un produit livré, un délai tenu. On a longtemps opposé « vite » et « bien » ; l'IA agentique promet de rapprocher les deux, au moins sur le terrain de la vitesse. Refuser cette réalité par principe serait une posture, pas un argument. La vraie question n'est pas de savoir si l'on doit s'en servir, mais comment — et avec quelle conscience de ce que l'on délègue.

Deux philosophies dans une période de transition

Nous vivons un moment charnière où cohabitent deux façons radicalement différentes d'exercer le métier.

D'un côté, les développeurs qui savent développer : pourquoi tel choix technique plutôt qu'un autre, pourquoi préférer telle structure, comment anticiper un problème — technique ou produit — avant qu'il ne surgisse. Ils ont été formés à produire en réfléchissant. Pour eux, l'IA est un outil de plus dans une main déjà sûre.

De l'autre, les développeurs qui ne font que transposer une vision produit à l'IA agentique. Ils décrivent un résultat attendu et laissent la machine combler tout l'espace entre l'intention et l'implémentation. Le code existe, il fonctionne parfois, mais la chaîne de décisions qui l'a produit leur échappe.

Je ne dresse pas ce contraste pour disqualifier les seconds : transposer une vision produit est une compétence réelle, et beaucoup de valeur naîtra de là. Je le dresse pour nommer ce qui les sépare vraiment — et qui n'est ni le talent ni l'outil, mais l'endroit où chacun place la responsabilité de la machine.

Le curseur de responsabilité : exécution ou compréhension

Tout se joue là. On peut confier à une IA agentique une responsabilité d'exécution — comme on la confierait à un développeur junior : « voici la tâche, voici les contraintes, exécute, je relis ». Ou bien une responsabilité de compréhension — comme on la confierait à une agence : « voici mon besoin, débrouille-toi, je juge le résultat ».

Ces deux postures ne sont pas équivalentes, et la différence n'est pas technique : elle est éthique et professionnelle. Déléguer l'exécution, c'est rester garant de chaque décision structurante. Déléguer la compréhension, c'est accepter de ne plus savoir pourquoi le système est ce qu'il est. Sur un site vitrine, le second choix est anodin. Sur un système critique d'entreprise, il est vertigineux.

C'est pourquoi définir ce qu'on accepte de déléguer n'est pas un détail de méthode, mais le cœur de la pratique. Ma règle, je la formule simplement : l'IA écrit le code à ma place, jamais elle ne sait à ma place. Tout ce qui entre dans une de mes bases passe par ma lecture, avec l'exigence que j'appliquerais à la pull request d'un junior — parce qu'un agent produit du code qui a l'air correct, et que c'est précisément ce qui le rend dangereux : l'erreur se niche dans un cas limite, une hypothèse implicite, une faille qu'aucune relecture pressée ne verra. Du code généré reste du code à sécuriser comme un autre.

Une révolution qui s'apprend par étapes

Le scénario le plus plausible pour demain, qu'on s'en réjouisse ou non, c'est qu'on laissera l'IA gérer une part croissante du cycle produit — jusqu'à, peut-être, l'essentiel. Si c'est la trajectoire, alors la question n'est pas « faut-il y aller » mais « comment commencer ». Et il faut commencer quelque part, aujourd'hui.

Ma conviction, c'est qu'on n'entre pas dans cette révolution d'un bond. On y entre par étapes, et l'ordre compte : d'abord confier des tâches simples ; comprendre vraiment comment l'IA agentique fonctionne — ses forces, ses faiblesses, ses limites ; lui poser des garde-fous ; l'assimiler à sa routine ; créer de la valeur réelle avec, sans jamais lâcher la vérification. C'est à ce prix que, demain, le métier pourra glisser vers ce qu'il deviendra sans doute : la supervision et la parallélisation de travaux menés par des IA.

J'insiste sur l'ordre parce que j'ai essayé de le brûler. Aller trop vite, déléguer trop tôt une responsabilité trop large : je l'ai fait, et le résultat a été catastrophique. Ce n'est pas parce qu'on s'installe du jour au lendemain devant une workstation surpuissante, trois écrans et les logiciels les plus pointus du marché qu'on produit, dès le premier jour, du travail solide. L'outil n'a jamais fait le maître. C'est un apprentissage, et il ne tolère pas qu'on saute des marches.

Un effet de levier qui dépasse le code

Le changement le plus profond n'est pas que l'IA écrive du code à notre place — c'est qu'elle relève le plafond de complexité qu'une seule personne peut porter. Ce qui exigeait hier une équipe — une application, son infrastructure, ses données, son support — devient peu à peu gérable par un individu qui orchestre des IA. L'unité de production se resserre, et l'effet de levier individuel explose. Demain, « gérer une tâche complexe » ne voudra plus dire la découper entre dix personnes, mais la piloter seul, en parallélisant des agents.

Et il serait myope de croire que cela s'arrête au développement. Le même mécanisme touche tous les métiers du savoir — la finance, le droit, le design, le marketing. L'IA agentique est un levier généraliste, pas un gadget de développeur ; ses conséquences économiques et organisationnelles débordent largement notre profession : des équipes plus petites qui produisent davantage, des modèles d'affaires repensés, des organigrammes redessinés. Le développeur n'est qu'un cas particulier — le premier servi, peut-être — d'une transformation bien plus vaste. Et c'est justement parce que cette complexité se concentre sur une seule paire d'épaules que la question du curseur de responsabilité devient vitale : plus une personne porte, moins elle peut se permettre de ne pas comprendre ce qu'elle porte.

Un métier qui se déconstruit pour mieux se reconstruire

Voilà comment je vois cette période : le métier de développeur se déconstruit pour mieux se reconstruire. Ce qui faisait notre valeur hier — la maîtrise de la production — se déplace vers la maîtrise de la décision, du cadrage, de la supervision. Ce n'est pas une perte de compétence, c'est un changement de centre de gravité. Et comme tout changement de ce genre, il ne se subit pas : il se travaille.

Or ce travail, personne ne le fera à notre place. Chaque développeur porte sa part de responsabilité dans sa propre formation à ces sujets. La veille technologique a toujours fait partie du métier — on ne s'est jamais demandé s'il fallait suivre l'évolution des langages ou des frameworks. La veille sur l'IA agentique n'est pas différente, sinon par son ampleur. La négliger pour autre chose qu'une conviction personnelle assumée, c'est creuser, sciemment ou non, un fossé entre l'ancienne et la nouvelle génération de développeurs — un fossé qui, lui, ne se comblera pas tout seul.

Je ne sais pas exactement à quoi ressemblera ce métier dans cinq ans. Mais je sais où je choisis de me tenir : du côté de ceux qui apprennent à piloter ces outils en gardant la compréhension, plutôt que de ceux qui les subiront. La révolution a commencé — autant la traverser en sachant pourquoi l'on fait chaque choix.