Cet article fait suite à un mal être depuis quelques mois à propos des IA et des coding agents et des interrogations que je porte sur l'avenir de notre métier.

Pour commencer je vais déjà faire un petit disclaimer :

Comme beaucoup d'articles de mon blog, je partage souvent mon avis et celui-ci ne fera pas exception.

Cependant garde en tête que le domaine de l'intelligence artificielle et dans mon cas celui des agents de codage (coding agents) évolue constamment et mon avis peut aussi être amené à changer.

C'est pour ça que cet article reflète mon avis qu'à l'heure où j'écris ces lignes et je dois avouer que j'ai eu beaucoups de difficultés pour trouver un angle d'attaque.
Je n'ai rien écrit depuis presque 3 mois. Et non par manque de sujet mais parce que je ne trouve plus de motivation à écrire des articles liés au code.

J'ai cette étrange impression que le monde du dev s'accélère et que la frontière entre dev et d'autres métiers devient floue.

1. De la ligne de code au prompt : ma chronologie d'une accélération

Fin 2022

On a assisté à l'émergence de ChatGPT (OpenAI) et de son agent conversationnel.

On pouvait lui demander à peu près n'importe quoi, il n'était pas connecté à de la data fraîche (au web quoi) donc l'utilité était très restreinte pour du dev (sauf si tu bossais dans un langage qui n'a pas eu d'évolution majeure depuis son dernier crawl d'infos).

Début 2023

Arrivée de Claude (Anthropic) dans le game. Un peu pareil que son concurrent en terme d'intérêt à ce moment là.


Pour ma part les IA en général ne m'intéressaient que très peu à ce moment. Je débutais ma reconversion dans le développement web et la pertinence des réponses à mes questions que je pouvais leur poser me faisait perdre plus de temps qu'autre chose.

Je lui demandais souvent les mêmes tâches "basiques" durant mon apprentissage, souvent les mêmes questions et j'ai alors compris que l'IA n'allait pas m'aider à apprendre, mais à exécuter. Et hors de question pour moi de créer du code que je ne comprends pas.

2024

Sont apparus sur le marché les premiers coding agents : Cursor et Github Copilot.
Personnellement j'ai voulu tester Github Copilot (GC) pour son aspect "proche" du code dans l'IDE. Il me correspondait plutôt bien, pas intrusif.

Je ne parlerai pas de Cursor car je n'ai jamais été curieux de le tester.
Ça faisait à peine un an que j'étais junior, j'étais encore un bébé dev avec un sacré syndrome de l'imposteur (et OUI clairement, l'IA a ce talent pour exacerber ce truc). Alors un IDE qui code tout à ta place, j'étais pas prêt à ça.

Grâce à GC j'avais ainsi cette sensation de garder le contrôle du code. Il était peu fiable sur du gros contexte alors ça m'allait bien, je continuais avec ma logique, mon code et lui suivait sur les tâches répétitives (itération de tableaux etc …).

Je suis resté 1 an avec Github Copilot, j'avais une relation presque "exclusive" avec lui.

D'ailleurs à cette période, utiliser l'IA c'était tabou, quasiment parler de sorcellerie ou de triche. Un code produit par l'IA c'était un code sale, presque honteux.

Je m'intéressais très peu aux autres canaux conversationnels comme GPT et Claude qui, pour moi, étaient restés bloqués en 2023.

2025

Mon employeur est passé chez Junie, l'IA embarquée dans l'écosystème JetBrains (PHPStorm). ça m'allait bien, c'était comme Github Copilot. Pas trop intrusif, désactivable au besoin.

J'étais libre de coder comme je le voulais. A ce moment là l'usage de l'IA a commencé à se démocratiser et son usage s'est libéré. On était moins honteux de l'utiliser.

Durant cette même année, Anthropic sort l'artillerie lourde : Claude Code armé de ses munitions Haiku, Sonnet et Opus. A lancer dans son terminal. J'y accorde à ce moment que peu d'intérêt.

Je pense qu'à l'époque c'était même la seule news tech qui avait de l'importance sur LinkedIn. 

Tout le monde ne parlait que de ça, les vendeurs de formation était déjà des "AI expert" en 3 semaines, des personnes qui n'avaient jamais touché une ligne de code faisaient leur propre landing page et était devenu expert en code. Du code bourré de failles de sécurité, des clés API en clair dans des pages javascript …

J'étais encore absent de l'écosystème d'Anthropic, je regardais de loin histoire de faire une veille minimale mais je continuais avec mon agent dans mon IDE, c'était suffisant pour mon besoin.

Coder avait encore du sens pour moi, j'aimais ça (pourquoi j'en parle au passé ... j'en sais rien car j'adore toujours autant !).

Construire des interfaces, des APIs et des systèmes sûrs c'est ce pourquoi j'ai voulu faire ma reconversion. Je continuais à découvrir des trucs, à apprendre, à expérimenter etc … et le lancement de mon blog me permettais aussi d'ancrer ce que j'apprenais. Et j'avais toujours en moi cette honte d'utiliser l'IA, comme si ce n'était pas mon boulot, il fallait que ce soit moi.

2026 (1er Semestre)

Début d'année, je poste deux articles mais l'envie de publier s'estompe. La vague IA et les questionnements sur son utilisation me donne le cafard. Pourquoi publier des articles sur du code qui peut être généré par IA. Même si pour moi c'était une évidence, coder pour soi et partager c'est bien, j'avais quand même une tristesse en moi, je sentais que mon métier était en train de basculer.

En Mars j'ai eu la chance de participer à ma première conférence tech : La SymfonyLive de Paris (ça me fait penser que je n'ai pas débriefé ici de cette expérience).

SymfonyLive Paris 2026
SymfonyLive de Paris 2026

 

Et dans cette conférence, un talk particulier a résonné en moi : "Développer un coding agent en PHP, dans les coulisses du Harness" de Fabien Potencier, le fondateur de Symfony. Un talk complet sur l'utilisation de l'IA, des agents de codage et de la sécurité que l'on met autour pour s'assurer une livraison de qualité.

Pendant la conférence, petit sondage de Fabien dans l'assemblée à mains levées :

  • Qui code avec une IA dans l'IDE : ≃ 40%
  • Qui code avec des coding agents en terminal : ≃ 70%
  • Qui ne code plus du tout : ≃ 2 - 3%
  • Qui refuse l'IA : < 1%

(Pas forcément 100%, certains sont dans plusieurs catégories mais la tendance était là).

Là j'ai pris une claque. Plus de la moitié utilisent des agents sans IDE et certains commencent même à les utiliser de manière autonome et cyclique. J'étais à ce moment-là vraiment en train de rater quelque chose.

 

2. Mon premier agent

Je rentre chez moi, ni une ni deux : npm install -g @anthropic-ai/claude-code .

Claude Code

Déjà je me dis "c'est bizarre de coder sans IDE", donc premier réflexe, j'ouvre un IDE. Fun Fact, ça sert a rien et ça on le verra juste après.

Je regarde des tutos, je lis la doc d'Anthropic, j'ai l'impression de découvrir un nouveau langage. Les skills, les context window, les différents modèles, les hooks, la gestion des tokens, les routines etc … Ça fait énormément d'informations juste après un npm install.

A ce moment là je test des trucs, et ce que je lui demande de faire, ça m'aurait pris 4h, lui 5min. Je le challenge sur des cas d'usage, je le trouve toujours pertinent. J'étais dans une certaine euphorie.

Rapidement, face à tout ce code produit,  je me rends bien compte que mon IDE ne me sert plus car le code que l'agent fournit, est impossible à vérifier pour un humain. Pas qu'il code mal avec des $maVariable1, juste qu'il code trop par rapport à un humain. 

J'ai donc naturellement ajouté des tests dans mes itérations. Les tests sont plutôt cohérents, il faut bien les décrire pour éviter des tests de style "vérifie si 1 + 1 = 2". Mais une fois en place, ça passe. Et si le test ne passe pas, il ne doit pas modifier le test, mais modifier le code (très important … sinon les tests ne servent à rien si on les change à chaque fois).

Le code est OK, les tests sont OK. Maintenant tu peux push sur le repo. Avant de push par contre j'aimerai une doc technique, donc on ajoute une brique à la pipeline : "Génère moi une doc sur le git diff". Et ainsi de suite …

Bien entendu, en 5 paragraphes, j'ai mis 2 ou 3 semaines à trouver la bonne façon de faire pour moi.

C'est satisfaisant, on voit notre application se générer sous nos yeux, stable par les tests pour éviter les régressions (car Claude c'est un pro de la régression quand même).

 

3. La douche froide

Depuis la conférence en mars 2026 jusqu'à début mai, je me suis renseigné sur l'IA, les R.A.G, comment faire de la tokenisation, etc. C'est un sujet passionnant, mais très vite j'ai ressenti un manque. Ce manque que j'avais à mes débuts, celui de coder et d'apprendre.

Le problème avec les agents c'est qu'on a une dose d'adrénaline très vite. Un prompt, une boucle d'action et hop on a eu notre shoot d'adré. À quand la suivante ? Simple, au prochain prompt. Et tu commences à coder à 20h, tu sors de ta session il est 4h du mat'.

On passe d'un métier de créateur de code à celui d'orchestrateurs d'agents. Et personnellement, faire faire tout le boulot à l'IA, ce n'est pas quelque chose qui me convient. Mais pourquoi ?

L'illusion de l'apprentissage

Ce que Claude fournit c'est du code de qualité (uniquement si on met en place des boucles de correction !).

Parfois il va utiliser des patterns de conception que même moi je n'aurais pas utilisés. Je regarde le code, je me dis que c'est très sympa comme pattern et OK. Sauf qu'au final ce pattern, je le regarde et c'est tout, je ne l'ai jamais pratiqué seul, je n'apprends pas. J'ai l'illusion d'apprendre.

Pour ce passage, je vais ajouter la vidéo de Micode dans mes sources pour étayer ce propos.

Même dans des vidéos tutoriels de certains développeurs techs, on les voit passer leur temps à faire du Claude Code. C'est triste je trouve.

L'isolation du développeur

Avant l'arrivée des agents conversationnel spé code, sur des forums et ou des groupes discord, ça pullulait de questions/réponses, de visions différentes intéressantes à explorer.
Mais depuis j'ai remarqué que dans les communautés des devs et des étudiants, il y a de moins en moins d'entraide.

Evolution des questions sur StackOverflow
Evolution des questions sur StackOverflow (pragmaticengineer.com)

Où sont les reviews de code senior-junior ? Depuis que l'IA peut interagir sur des dépôts de code, il n'y a plus ce partage entre générations de développeurs. Et pour moi c'est regrettable. Pendant les reviews j'ai appris et transmis beaucoup de choses.

Parfois des petits trucs mais toujours intéressant et ça permettait d'apprendre et de se construire une vraie relation d'équipe durant ce partage. Je garde de bons souvenirs de certaines reviews autant sur le plan technique que sur le plan humain.

Le F.O.M.O

Derrière cet acronyme se cache "Fear of Missing Out". La peur de manquer quelque chose, de manquer l'info essentielle pour être "dans le coup".
Et ça, quand on entre dans l'univers des agents de code, c'est compliqué de s'en défaire.

À l'époque de l'avènement des frameworks JavaScript (oui oui… je t'assure que ça a existé 😅), quasiment toutes les semaines, un nouveau framework. Sur NPM on en compte 50 majeurs et 300 à peu près de niche.
Et bien avec les agents c'est pareil, tout évolue (trop ?) vite ! Les skills on a peur d'en rater, un nouvel outil pour améliorer son agent c'est pareil, une nouvelle technique d'optimisation de tokens etc …

C'est difficile de trouver de l'information autre que le sujet des IA à présent, comme si le code n'avait plus d'importance.

L'analyse du besoin

Avec les agents on a toujours quelque chose à faire, on ne se repose pour ainsi dire jamais. Avant on se disait "OK, la feature là va me prendre une demi-journée, je la commencerai plus tard…" maintenant un client vient te demander une feature (inutile), pas de souci !

Avant on aurait plutôt discuté avec lui, analysé son besoin, et peut-être que ça n'aurait pas été pertinent de la développer. Maintenant le temps n'est plus une dimension de négociation, on le fait et c'est tout.

Expert en tout

Avant les agents, une frontière était présente entre les développeurs et les clients. Pour moi ce n'était pas par snobisme, par sécurité. La garantie qu'un code déployé avait respecté les standards du développeur et de son expérience. Je ne dis pas qu'on crée du code sans bug, mais notre apprentissage nous a rendus sensibles à tout un tas de domaines comme la sécurité, l'infrastructure, le SEO etc. On approfondissait le sujet par nécessité et par passion.

On trouve maintenant dans le monde du dev, grâce (ou à cause ?) des agents de codage, plein de personnes qui ne font que « prompter » du code, sans regard critique (ou alors juste un autre prompt : "est-ce que ça va casser quelque chose ?"), et je trouve que la frontière s'est brisée. C'est une bonne chose pour un non tech mais c'est dangereux également.

C'est là que la différence est énorme entre un développeur et un prompteur (aussi appelé vibecodeur) où le dev va savoir pourquoi et comment ça fonctionne (et où ça casse) tandis qu'un prompteur ne fera que constater que ça marche (ou que ça casse).

Combien de SaaS ont vus le jour depuis 2025 où la sécurité n'était pas au rendez-vous, où l'argument c'est "il vaut mieux se lancer que ne rien faire" sauf que quand on joue avec les données personnelles de clients, ça ne fonctionne pas comme ça.

L'IA donne cette fausse sensation d'être devenu des experts en tout.

Experts en tout

La dépendance d'une techno que tu loues

Ça m'embête vraiment de dépendre d'une techno que je ne possède pas.

Déjà je suis sur Linux, j'essaye de me passer des GAFAM quand c'est possible et là… je suis devenu dépendant d'un système qui pourrait du jour au lendemain soit me couper l'accès à mes agents, soit augmenter le tarif et je devrais capituler et passer à la caisse.

Pour moi c'est non, il faut garder le contrôle de son code !

Quand Claude produit du code, je continue à vérifier si je serais capable d'aller le déboguer.

Je ne l'utilise jamais pour créer à partir de zéro, j'ai toujours la main sur les briques "originelles" du projet, de cette façon il analyse comment je code et quand il produit, il le fait en essayant d'imiter les briques initiales.

Les plus malins vont dire que je pourrais héberger un modèle self hosted sur un Mac mini ou faire du cloud computing. Les paramètres des modèles d'un mac mini sont de très loin équivalente à ceux des serveurs d'Anthropic et le cloud computing n'est pas acceptable dans le budget.

4. Comment sortir de tout ça ?

Je suis bien conscient d'avoir peint un tableau plutôt noir des agents et peut-être que ma vision est biaisée par ma passion de coder.

Mais déjà est-ce que je me passerai des agents ? Bien sur que non, ils me rendent bien des services, mais est-ce qu'il faut les utiliser tout le temps ? La réponse est nuancée et j'y répondrai à la fin.

Gardons notre esprit critique face à l'IA. En tant que dev, je pense qu'il est indispensable de mettre des boucles de rétroactions dans les hooks de l'agent afin qu'il enchaîne en cascade des étapes de contrôle de manière déterministe pour livrer un code de qualité qui puisse nous ressembler. Des tests et de la documentation comme on le faisait avant.

Les boucles de rétroaction, les tests automatisés, on a déjà connu ça dans les pipelines CI/CD, c'est un fait. Mais ils étaient écrits par nous et on comprenait le code qu'on écrivait. Je pense qu'il faut que ça reste comme ça ! (Même si maintenant on voit apparaître des langages AI first incompréhensible pour des humains).

Parlons des étudiants et des juniors. J'ai eu la chance d'arriver dans la génération de devs sans IA, j'ai donc connu l'apprentissage à l'aide de la doc, des forums comme StackOverflow, etc. J'ai appris la frustration de rester bloqué pendant des nuits entières sur un bug insoluble (coucou la variable non initialisée !).

À présent quand un étudiant arrive, dans sa boîte à outils, c'est Claude Code ou Codex. Et on repart sur le point du dessus : l'illusion de l'apprentissage. Alors oui, on a le droit aux différents modes d'apprentissage avec un professeur IA mais il faut se resteindre à ne pas obtenir la réponse et personnellement je pense que ce n'est pas la bonne solution (car si on a la possibilité d'obtenir une réponse à moindre coût, on finira invariablement par prendre des raccourcis).

Accepterait-on maintenant d'être bloqué aussi longtemps, d'avoir une frustration grandissante alors qu'il suffit de demander la solution au bout d'une heure de blocage ? Je suis sûrement aigri, mais si on ne m'avait pas contraint à l'époque, je n'aurais probablement jamais eu la patience d'attendre aussi longtemps pour me débloquer.

Peut être un avis tranché sur la phrase suivante mais … Les agents ne devraient être utilisés que lorsque l'on a acquis suffisamment d'expérience pour auto-critiquer son code.

Le métier évolue, c'est certain, et il serait illusoire de prétendre le contraire. Mais cette même IA qui donne aux développeurs l'illusion d'être experts en sécurité, en infrastructure ou en DevOps, donne aussi aux non-développeurs l'illusion de savoir coder.

C'est le même problème des deux côtés du miroir. Libre à nous donc de l'utiliser intelligemment, en continuant d'apprendre par nous-mêmes et en sachant reconnaître les limites de ce qu'on maîtrise vraiment. Si je veux auditer une infrastructure, je fais appel à un collègue en cybersécurité, pas à un prompt.

Savoir dire "ce n'est plus de mon ressort, j'appelle quelqu'un qui gère vraiment le sujet" n'est pas un aveu de faiblesse. C'est exactement ce qui distingue un développeur d'un prompteur.

Il faut aussi continuer de faire des reviews entre seniors et juniors, c'est trop important pour l'échange intergénérationnel. Nous sommes en train de créer une société où les juniors n'ont plus leur place ! Avant ce n'était déjà pas simple pour eux, mais maintenant c'est une mission presque impossible.

La conclusion de cet article finalement c'est ce qui ressortait de la conférence de Fabien, ce sont tous les filets de sécurité que l'on met sur nos agents pour produire du code correct et documenté. Restons maitres de nôtre code !

5. Et mon blog alors ?

Cet article je le vois comme une sorte de thérapie.

Les sujets abordés sur le blog ne traiteront quasiment jamais d'optimisation IA, non pas parce que ce n'est pas intéressant, mais juste parce que la vision que j'ai du développement, ce n'est pas de prompter.

Quand Deep Blue a émergé puis a battu Kasparov aux échecs, c'était évidemment un choc pour l'époque, la machine qui bat l'humain. Pourtant on continue à trouver des joueurs d'échecs dans le monde entier malgré une IA sachant calculer mieux que l'humain. On ne joue pas aux échecs pour battre l'algorithme, on y joue pour la beauté du jeu et le dépassement de soi. Le code devrait rester identique.

Deep Blue vs Kasparov

Je continuerai donc ce blog pour comprendre le code que je produis manuellement ou artificiellement, par amour de mon métier et l'envie de toujours progresser en tant qu'individu et par passion de transmettre.

Le partage et la transmission sont pour moi des valeurs essentielles dans notre métier et c'est aussi là que l'on fait nos plus belles rencontres. Durant mon cursus, j'ai rencontré de belles personnes de tout horizon avec qui j'échange très règulièrement. Je trouve tellemet dommage que l'IA nous recentre sur nous même.

Je profite de cet article pour te proposer deux autres si tu es junior :

L'informatique ça n'a jamais été seulement parler à une machine, mais aussi faire équipe avec des humains !

En cette fin d'article, je souhaite te remercier Marilena pour m'avoir encouragé à écrire cet article, difficile de trouver le bon angle d'attaque, j'espère ne pas m'être éparpillé ! Ta relecture m'a beaucoup aidé ! Et bien évidement merci à toi Fabien Potencier de m'avoir fait découvrir les coding agents de la meilleure façon possible lors de cette conférence !