L'IA remplacera-t-elle le développeur ? Le vrai et le faux

Sur LinkedIn, un débat revient chaque semaine. D’un côté : « Aucune IA ne battra un développeur qui comprend le métier, qui refuse une fonction inutile et qui assume ses choix en production. Le code se génère, la décision de l’écrire, non. » De l’autre, un commentaire moqueur : plus personne ne lit l’assembleur, on fait confiance au compilateur ; et un directeur ne relit pas le code de ses équipes, il juge ce qui entre et ce qui sort. Alors, humains ou IA, quelle différence ?

Les deux ont raison sur un point. Et les deux ratent le même.

Ce qui est vrai

La décision reste humaine. Une IA produit cinq cents lignes en trente secondes. Elle ne se demande pas si ces lignes doivent exister, si la fonction sert vraiment le métier, ni ce qu’elle coûtera à maintenir. C’est ce jugement que l’on paie, pas la frappe.

Le pilotage par les résultats existait déjà. Un directeur technique d’une grande équipe ne relit pas chaque ligne. Il juge des livraisons, des incidents, des délais. De ce point de vue, qu’une équipe soit faite de développeurs ou d’agents d’IA change moins qu’on ne le dit : on pilote l’entrée, la sortie et les erreurs.

Le terrain concurrentiel décide. Celui qui coupe son budget parce que « l’IA code » fait du surplace pendant que son concurrent garde le sien et va beaucoup plus loin.

Ce qui est faux, ou à moitié

« Comme pour l’assembleur, on finira par faire confiance. » La comparaison est séduisante, mais elle ne tient pas. Un compilateur est déterministe : la même entrée donne toujours la même sortie, et des décennies de tests l’ont rendu fiable. Une IA donne deux codes différents pour la même demande, et parfois un code faux qui a l’air juste. La confiance ne viendra pas de l’habitude, elle viendra des tests automatiques, des contrôles et des relectures ciblées.

« L’équipe est déjà une boîte noire. » Vrai pour le pilotage, faux pour la responsabilité. Derrière une équipe humaine, quelqu’un répond d’une panne et sait pourquoi tel choix a été fait. Derrière un agent, la responsabilité remonte à ceux qui l’ont branché, et l’explication du choix n’existe souvent nulle part.

« Il suffit de tout brancher, l’IA code à ta place. » Les mesures disent autre chose. En juillet 2025, une étude contrôlée du laboratoire METR a suivi des développeurs expérimentés sur leurs propres projets : avec l’IA, ils ont mis environ 19 % de temps en plus, alors qu’ils pensaient avoir gagné 20 %. Les outils ont progressé depuis, et l’étude ne portait que sur seize personnes, mais elle rappelle une chose : l’impression de vitesse n’est pas la vitesse.

Notre position : relire là où ça compte

Faut-il relire chaque ligne produite par une IA ? Non. Ce serait perdre l’essentiel du gain. Faut-il n’en relire aucune ? Non plus. La bonne réponse dépend de la surface d’attaque.

Un site vitrine statique ou headless n’est pas de la génétique. Il n’a ni base de données exposée ni serveur applicatif à pirater. On y livre du code peu relu, généré puis testé, et ça se passe en général bien : nous le faisons tous les jours.

L’œil humain reste en revanche obligatoire partout où une erreur coûte cher :

• l’authentification et les droits : qui peut se connecter, qui voit quoi ;
• les connexions à d’autres outils : API, webhooks, jetons d’accès ;
• les secrets : une clé glissée dans le code envoyé au navigateur est publique ;
• les formulaires : validation des champs, anti-spam, données personnelles et RGPD ;
• le paiement : montants, remboursements, webhooks du prestataire ;
• les dépendances : une bibliothèque ajoutée par l’IA, parfois inconnue ou abandonnée, est du code tiers qui entre dans votre produit.

Le détail des contrôles est dans notre article sur la sécurité d’une application, et la raison pour laquelle un site statique expose si peu dans celui sur la faille PHP d’octobre 2026.

Moins cher, ou plus loin ?

On n’est plus en 2025 : les interventions humaines sur un projet web ont vraiment diminué. Ce gain, il faut choisir quoi en faire, et la réponse dépend de la situation de l’entreprise.

1. Aller plus loin avec le même budget : plus de fonctions, plus de tests, plus de marchés. C’est la voie de celui qui se bat sur un terrain concurrentiel.
2. Démarrer plus vite et pour moins cher : un premier produit en ligne en quelques semaines, pour vérifier une idée avant d’investir davantage.

Nous proposons les deux voies à nos clients. Ce que nous ne proposons pas, c’est la troisième, celle qu’on entend trop : couper le budget et compter sur l’IA pour faire le même travail sans personne pour le diriger. Notre article sur le vibe coding raconte comment ces projets finissent.

Notre avis

Les « dinocodeurs » ont tort de croire que relire chaque ligne protège leur métier. Les enthousiastes ont tort de croire qu’on peut tout brancher et ne plus rien regarder. Le métier se déplace : moins d’écriture, plus de décisions, d’architecture et de vérification. Et ce qui justifie le prix d’un bon développeur, ce n’est pas le nombre de lignes qu’il tape. C’est sa capacité à dire « celles-ci ne doivent pas exister » et à savoir lesquelles relire. Notre article sur le rôle humain face à l’IA va plus loin sur ce jugement.

Sources

1. Une étude contrôlée du laboratoire METR (nouvel onglet)metr.org