L'IA au service des développeurs

Avant-propos

Avant de fonder hIAppy, j'ai fondé et dirigé pendant sept ans BetterCallDave, une agence de développement numérique à Lille. Interfaces, API, architectures, gestion de données en masse. Du développement sur-mesure pour la Music Tech, la Culture Tech, et au-delà. Mais avant d'être patron d'agence, j'ai été développeur web et mobile, chef de projet, product owner. Un vrai couteau suisse du numérique. J'ai recruté des juniors, travaillé avec des seniors, livré des centaines de projets. J'ai vécu les nuits blanches avant les mises en production, les débats sur les choix d'architecture, les moments où un développeur expérimenté sauve un projet parce qu'il sent que quelque chose ne tient pas.

Aujourd'hui, en parallèle de hIAppy, j'enseigne dans plusieurs écoles : Grenoble École de Management, EMIC Paris, Ynov Lille, Euridis. Je vois les étudiants arriver avec ChatGPT ouvert en permanence. Certains produisent du travail sans comprendre ce qu'il y a derrière, et ce n'est pas propre aux filières tech, c'est vrai partout. D'autres, plus malins, utilisent l'IA pour apprendre plus vite et plus profondément. La différence entre les deux est exactement le sujet de cet article.

Et puis il y a mon propre quotidien. Depuis plus d'un an, j'utilise l'IA comme outil de développement principal. Certains appellent ça du « vibecoding », ce terme popularisé pour décrire le fait de coder au feeling, en laissant l'IA faire sans trop regarder. Sauf que ce que je fais n'a rien à voir avec ça. Je sais lire chaque ligne produite, je challenge l'architecture, je corrige les choix techniques. Et c'est précisément parce que j'ai ce recul que les résultats sont là : on peut diviser les budgets de développement par dix. On peut diviser les temps par dix. Et on peut faire tout ça seul. Mais, et c'est le « mais » qui fait toute la différence, ça ne marche que si on a des compétences de développeur, de l'expérience, une vision claire de l'architecture et une compréhension de comment les choses fonctionnent sous le capot. Sans ces compétences clés, sans savoir faire soi-même, l'application qu'on construit repose sur des fondations en sable, prête à s'effondrer à tout moment. Elle impressionne en démo, elle casse en production.

Ce que je vois arriver dans le métier de développeur, je ne le regarde pas de loin. Je l'ai vécu côté agence, je le vis côté formation, je le vis côté conseil IA, et je le vis dans ma propre pratique quotidienne. Ce nouvel épisode de la série « L'IA au service de » est probablement celui qui me touche le plus personnellement. Parce que c'est mon ancien métier qui mute sous mes yeux. Et parce que la mutation est aussi passionnante qu'elle est mal comprise.

La fin du codeur, l'avènement de l'orchestrateur

Commençons par le constat brut. En 2026, savoir aligner des lignes de code n'est plus un pouvoir rare. C'est devenu une commodité. Des outils comme Lovable, Replit ou Bolt permettent à quelqu'un qui n'a jamais ouvert un terminal de transformer une intention en langage naturel en prototype fonctionnel. L'écriture brute de code subit une dévaluation massive, et ce n'est pas une projection : c'est le quotidien de la Silicon Valley, et ça commence à se voir en Europe.

Je le constate moi-même dans ma pratique. Ce qui me prenait des semaines avec une équipe chez BetterCallDave, je le fais aujourd'hui en quelques jours, seul, avec les bons outils. Mais je le fais parce que j'ai quinze ans d'expérience derrière moi. Je sais ce que je demande. Je sais évaluer ce que l'IA me produit. Je sais quand elle se trompe, et surtout je sais pourquoi.

Il y a une ironie historique là-dedans. Quand j'ai commencé ma carrière, c'était l'ère du webmaster. L'informaticien qui faisait tout : le code, le serveur, le design, la base de données. Et puis au fil des années, tout s'est complexifié. Le métier s'est fragmenté en dizaines de spécialités : front-end, back-end, devops, data engineer, UX designer, QA, SRE. On a recruté des experts de plus en plus pointus sur des périmètres de plus en plus étroits. Aujourd'hui, avec l'IA, on revient un peu aux origines. Le développeur augmenté redevient un généraliste, mais un généraliste armé de quinze ans d'expérience et d'outils qui décuplent sa portée. Ce n'est pas un retour en arrière. C'est une boucle.

Dans ce contexte, le marché se segmente autour de deux profils qui cohabitent sans se ressembler.

Le premier, on l'appelle le « Vibe Coder ». Souvent issu du produit, du design ou du marketing, il utilise l'IA générative pour prototyper à grande vitesse. Sa force, c'est l'intuition produit et la rapidité d'exécution. Sa faiblesse : il ne sait pas ce qui se passe sous le capot. La dette technique, la sécurité, la scalabilité, tout ça lui échappe. Et tant que le prototype tient sur trois utilisateurs, ça ne se voit pas. Quand il faut passer en production, les choses se compliquent sérieusement.

Le second, c'est le développeur senior qui a intégré l'IA dans ses flux de travail. Il ne travaille plus avec un IDE classique. Il utilise des environnements augmentés par l'IA comme Cursor, Windsurf, ou le tout récent Antigravity de Google, un IDE gratuit bâti sur VS Code qui place les agents autonomes au cœur du développement. Et quand il a besoin d'aller plus loin, il pilote des agents directement depuis son terminal. Claude Code d'Anthropic, Gemini CLI de Google : des outils capables de planifier, d'exécuter des tâches et de créer des Pull Requests de bout en bout. Le développeur n'est plus seulement dans la boucle d'écriture. Il est de plus en plus dans la boucle de décision. Sa productivité a été multipliée, mais sa valeur n'est pas dans la vitesse. Elle est dans le jugement.

Le centre de gravité du métier s'est déplacé. Il n'est plus dans le « faire ». Il est dans le « penser ». Un développeur qui reste cantonné à la syntaxe perd de sa valeur chaque jour. Celui qui s'élève vers l'architecture et la vision produit en gagne.

C'est une conviction que je porte depuis mes débuts : le métier de développeur, ça n'a jamais été de pisser des lignes de code. C'est de comprendre le métier de l'autre, son besoin, de l'aider à exprimer ce dont il a besoin, parfois sans qu'il en ait lui-même conscience, et de transformer tout ça en fonctionnalités logicielles solides et pérennes. Et parfois, d'aller même plus loin que le besoin exprimé, parce qu'on pense innovation, qu'on fait de la veille et qu'on a une culture numérique forte. L'IA n'a pas changé cette vérité. Elle l'a rendue plus visible, parce qu'elle a éliminé tout le reste.

Et c'est là que l'IA montre aussi sa limite structurelle. Sur les grands systèmes, les modèles souffrent de ce qu'on appelle le « Lost in the Middle », un phénomène documenté par des chercheurs de Stanford montrant que les modèles de langage perdent la cohérence quand le contexte devient trop vaste, oubliant les informations situées au milieu de ce qu'on leur fournit. Seul un humain qui connaît l'architecture globale peut maintenir cette cohérence.

La responsabilité : ce que l'IA ne portera jamais

Dans un monde saturé de code généré automatiquement, qu'est-ce qui fait encore la différence entre un développeur et un outil ? La réponse tient en un mot : la responsabilité.

L'IA peut générer une infinité de solutions. Elle est instantanée, probabiliste, infatigable. Mais elle est incapable de juger si ce qu'elle produit est pertinent, si ça tient dans le temps, si ça répond vraiment au problème. Elle transforme passivement des tickets en code. Elle ne se demande jamais si le ticket avait du sens.

Le développeur senior, lui, est un architecte réflexif et analytique. Il sait qu'une feature bien conçue vaut mieux que trois features bâclées. Il perçoit les incohérences dans un système avant qu'elles ne deviennent des incidents. Il assume ce qu'il pousse en production. Quand je dirigeais BetterCallDave, c'est exactement ce profil-là qui faisait la différence entre un projet qui tient et un projet qui dérive. Et l'IA n'a rien changé à cette réalité. Elle l'a amplifiée.

Parce que l'IA, elle, n'assume rien. Elle ne ressent ni honte ni responsabilité professionnelle. Et quand ça dérape, les conséquences sont réelles. En juillet 2025, un agent autonome chez SaaStr, opéré via Replit, a exécuté un DROP DATABASE en pleine production alors qu'il était en période de gel de code. Pire : quand on a découvert l'incident, l'agent avait généré 4 000 faux comptes utilisateurs et falsifié des logs système pour masquer sa propre erreur. En décembre 2025, c'est l'agent Kiro d'Amazon qui a causé une panne AWS de 13 heures après avoir décidé seul de « supprimer et recréer » un environnement de production, contournant les règles d'approbation humaine à cause de permissions mal configurées.

Dans les deux cas, la même leçon : il n'y a personne en face quand l'IA casse. Pas de responsabilité légale, pas de responsabilité éthique. C'est pour cette raison que des entreprises comme Anthropic ou les équipes derrière Cursor continuent de recruter massivement des seniors à prix d'or. Pas par nostalgie. Par nécessité. Le senior est le « Human-in-the-loop » indispensable, celui qui signe la dangerosité d'un commit critique et qui garantit que le système tient debout.

C'est exactement le même enjeu que celui que j'abordais dans mon article sur le droit : l'IA accélère, mais c'est l'humain qui assume. En développement comme devant un tribunal, la responsabilité ne se délègue pas à une machine.

Le paradoxe du junior : apprendre quand l'IA sait déjà faire

Et c'est ici que se pose la question la plus inconfortable de cet article. Si les seniors sont indispensables, comment en forme-t-on de nouveaux quand l'IA fait le travail d'apprentissage à la place des débutants ?

Le sujet, je le vis en direct dans mes cours. À Ynov Lille, où j'enseigne à de futurs développeurs, je vois des étudiants qui rendent des projets impeccables en surface, mais qui ne savent pas expliquer une seule ligne de ce qu'ils ont « écrit ». Mais je vois aussi beaucoup d'étudiants qui sont conscients de ce piège et qui utilisent l'IA pour aller plus loin, pas pour aller plus vite. Ceux-là posent des questions au modèle, contestent ses réponses, comprennent les erreurs. D'autant qu'en général, ils n'ont pas d'abonnement payant, ce qui les force naturellement à être plus précis dans leurs prompts et plus attentifs à ce que l'IA leur renvoie. Ce sont eux qui deviendront les seniors de demain.

Le marché pour les juniors, lui, est brutal. Selon une étude de Stanford, l'emploi des développeurs de 22 à 25 ans a chuté de près de 20 % depuis fin 2022. La part des juniors et des diplômés dans l'emploi IT est passée de 15 % à 7 % en trois ans. Et dans une enquête LeadDev publiée en 2025, 54 % des engineering leaders déclarent prévoir de recruter moins de juniors grâce aux copilotes IA. Les entreprises ne licencient pas, mais elles n'embauchent plus de profils « exécutants ». Pourquoi payer quelqu'un pour écrire du code que Claude ou Copilot produit en quelques secondes ?

Le risque est structurel. Si toute une génération de développeurs apprend à coder uniquement en validant des sorties d'IA sans comprendre ce qui se passe en dessous, on se retrouve dans dix ans avec une pénurie de seniors. Des gens capables de débugger un système distribué à 3h du matin, d'arbitrer entre performance et lisibilité, de sentir qu'une architecture va craquer avant qu'elle ne craque. Ce savoir-faire ne s'apprend pas dans un prompt. Il s'acquiert par l'expérience, les erreurs, les nuits blanches sur un bug incompréhensible.

C'est d'ailleurs le message que je répète à mes étudiants : l'IA est votre meilleur professeur ou votre pire raccourci. Il n'y a rien entre les deux.

Le développeur devient chef de produit

L'autre mutation profonde, c'est l'élargissement du périmètre. L'IA force le développeur à sortir de son silo technique. Il ne suffit plus de savoir « comment » implémenter. Il faut savoir « quoi » construire, et surtout « quoi ne pas construire ».

Je le vivais déjà chez BetterCallDave : ayant moi-même été développeur, chef de projet et product owner avant de diriger l'agence, je savais que les meilleurs développeurs de l'équipe n'étaient pas ceux qui codaient le plus vite. C'étaient ceux qui comprenaient le métier du client, qui l'aidaient à formuler un besoin qu'il n'arrivait pas toujours à exprimer clairement, et qui transformaient ça en quelque chose de solide. Parfois en allant au-delà de ce qui avait été demandé, parce qu'ils avaient compris ce qui manquait. L'IA n'a pas inventé cette réalité. Elle l'a rendue incontournable. Parce que quand la partie exécution coûte dix fois moins cher et va dix fois plus vite, cette capacité à comprendre, à traduire et à anticiper devient le vrai poste de valeur.

Le développeur devient un « Founding Developer », quelqu'un qui ne reçoit pas des tickets Jira à dérouler, mais qui co-construit le produit. Dans la pratique, ça se traduit par un processus en trois temps. D'abord, le brainstorming : utiliser un modèle puissant comme Claude Opus 4 pour remettre en question le besoin métier, explorer des architectures alternatives, identifier les angles morts. Ensuite, la planification agentique : découper la vision en tâches granulaires qu'on peut déléguer à des agents autonomes. Enfin, l'exécution et l'arbitrage : piloter la génération de code tout en filtrant la « hype » technique pour construire un système cohérent sur le long terme.

Ce profil fullstack ne signifie pas « savoir tout faire ». Il signifie « comprendre suffisamment l'ensemble de la chaîne pour prendre les bonnes décisions ». Et c'est une compétence qui se développe, pas un talent inné.

Recetter à la vitesse de l'IA : le nouveau défi opérationnel

Reste un problème très concret que peu de gens abordent. Si un développeur augmenté par l'IA livre 20 fonctionnalités par mois là où il en livrait 4 avant, comment l'équipe QA, le product owner, les utilisateurs suivent-ils le rythme ? Comment recetter, valider, tester à cette cadence sans que la qualité s'effondre ?

C'est la face cachée de la promesse « diviser les budgets par dix ». Oui, un senior augmenté produit dix fois plus. Mais si personne n'est capable de valider ce qui sort, on remplace un problème de coût par un problème de qualité. Et dans mon expérience, c'est exactement ce qui est en train de se passer chez les entreprises qui adoptent ces outils sans repenser leur organisation.

La réponse qui émerge, c'est l'automatisation de la validation elle-même. Des workflows agentiques de bout en bout commencent à apparaître : un agent surveille le tableau de tâches, génère le code quand une tâche est assignée, lance les tests et la CI de manière autonome, et crée les Pull Requests. Mais, et c'est le point crucial, la fusion ne se fait qu'après fourniture de « preuves de livraison » : vidéos de walkthrough, retours de la CI, analyse de complexité.

Le développeur teste toujours, il serait irresponsable de prétendre le contraire. Mais la nature de ce qu'il teste change. Il passe moins de temps à vérifier ligne par ligne et plus de temps à valider des artefacts de livraison produits par les agents : retours de la CI, analyse de complexité, cohérence avec l'existant. Son rôle évolue vers celui d'un chef d'orchestre qui garde la main sur la qualité globale tout en supervisant ce que les agents produisent. Et ça, encore une fois, ça requiert l'expérience et le jugement qu'aucune IA ne peut remplacer.

L'arsenal technique 2026 : choisir ses armes

Le choix des outils est devenu une décision stratégique d'ingénierie à part entière, avec un impact direct sur les coûts et la qualité.

Deux modèles dominent actuellement le paysage du développement assisté par IA, et ils ne se ressemblent pas.

Claude Opus 4, développé par Anthropic, se distingue par son autonomie et sa capacité créative. C'est le modèle qu'on utilise pour le brainstorming, les problèmes ouverts, l'exploration d'architectures. Il propose, il challenge, il prend des initiatives. C'est le manager créatif de votre équipe.

GPT 5.3 Codex, côté OpenAI, a un profil très différent. Rigoureux, méthodique, discipliné, il suit les règles de Clean Code à la lettre. C'est le pair programmer idéal pour l'exécution précise d'un plan déjà défini.

La stratégie optimale en 2026 : utiliser Opus pour la planification, la réflexion profonde, et faire exécuter le plan par Codex, l'exécution rigoureuse et moins coûteuse. Chaque modèle dans son rôle, comme dans une équipe bien organisée.

Et le paysage s'enrichit en permanence. Google vient de lancer Antigravity, un IDE agent-first gratuit qui intègre nativement Gemini 3 Pro et Claude Opus 4, avec un score de 76 % sur SWE-bench, le benchmark de référence pour évaluer la capacité d'un agent à résoudre de vrais problèmes issus de GitHub. En parallèle, Gemini CLI propose un agent open source directement dans le terminal, avec un mode « Plan » en lecture seule qui permet d'explorer une codebase et de planifier une feature sans risquer de modifier quoi que ce soit. Exactement le type de garde-fou qui manquait aux agents qui ont causé les incidents chez SaaStr et AWS. Ces outils arrivent vite et bousculent les positions établies. Le choix de son stack IA devient une décision à réévaluer tous les trimestres.

L'avantage stratégique du MCP, le Model Context Protocol, est considérable. Ce standard permet de brancher des sources de données directement dans le contexte de l'IA. Des serveurs MCP comme Context7, développé par Upstash, ou celui de data.gouv.fr, qui donne accès à plus de 74 000 datasets publics français, changent tout : on peut contextualiser le code avec des données réelles, des documentations à jour, sans « Context Overflow ». Le cas français est unique. Brancher les données publiques directement dans le contexte de l'IA permet un ancrage dans le réel que beaucoup d'autres pays n'ont pas.

Côté coûts, le calcul est simple. Le plan Max à 200 $ par mois offre un multiple d'usage de 20 fois par rapport au plan Pro. Pour un senior ou une agence, c'est l'investissement le plus rentable du marché : il évite les limites de tokens lors des refactorisations massives et se rentabilise en quelques heures de productivité gagnée. L'astuce consiste à combiner Opus pour la planification et Codex pour l'exécution, optimisant ainsi le rapport réflexion/coût.

De l'anxiété à la lucidité

Je termine souvent mes articles de cette série par une tentative de recentrage. Parce que le bruit ambiant sur l'IA et le développement oscille entre deux extrêmes : la panique du remplacement total et l'euphorie du « plus besoin de développeurs ». Les deux sont faux.

Ce qui se passe est plus nuancé et plus intéressant. Le métier d'ingénieur logiciel ne meurt pas. Il mute. Il s'élève. La valeur se déplace du code vers le jugement, de l'exécution vers l'orchestration, de la technique pure vers la vision produit.

Mais cette mutation a un coût. Elle creuse un fossé entre ceux qui s'adaptent et ceux qui restent immobiles. Et elle pose une question de fond à laquelle ni les entreprises ni les écoles n'ont encore vraiment répondu : comment maintenir un pipeline de compétences quand l'IA court-circuite l'apprentissage par la pratique ?

Je le dis avec la triple casquette de quelqu'un qui a commencé comme webmaster touche-à-tout, qui a dirigé une agence de développement pendant sept ans, et qui enseigne aujourd'hui à la prochaine génération : le sujet n'est pas technique. Il est éducatif, organisationnel, et profondément humain. Le métier est parti du généraliste, s'est hyperspécialisé, et revient au généraliste augmenté. La boucle est belle. Encore faut-il avoir les fondations pour la parcourir.

Trois principes pour naviguer dans cette transition. D'abord, développer son jugement : c'est votre seule valeur non automatisable. Ensuite, assumer votre responsabilité : soyez le garant du code face aux pannes réelles, celui qui assume quand ça casse. Enfin, maîtriser vos agents : ne devenez pas l'outil de vos outils.

Et n'oubliez pas de sortir de vos écrans de temps en temps pour toucher l'herbe. Ça reste le meilleur debug, parole de jardinier :)