Est-ce mal pour les développeurs d’utiliser l’IA? Ça dépend de qui réfléchit

Une pull request arrive un vendredi après-midi. Elle est propre, les tests passent, et elle a été écrite en environ une heure. Vous posez une seule question au développeur : pourquoi le résultat est-il mis en cache à cet endroit? Il ne sait pas. L’IA l’a écrit, ça fonctionnait, et il est passé à autre chose.

Ce moment résume à lui seul tout le débat sur les développeurs et l’IA. Plus personne de sérieux ne se demande si l’IA peut écrire du code. Elle le peut. La vraie question, c’est qui fait la réflexion.

Je crée des thèmes et des plugins WordPress, je gère un site en production et j’enseigne le développement web à temps partiel. J’utilise l’IA tous les jours. Voici où je situe la limite, et ce que la recherche dit de chaque côté.

Est-ce que je triche dans le processus de développement si j’utilise l’IA?

Ça dépend de qui a fait la réflexion. Si vous avez fait du vibe coding pour tout le projet et que vous ne pouvez pas me dire ce que le code fait, alors oui, vous avez sauté la partie du travail qui compte. Si l’IA vous a aidé pendant que vous gardiez l’esprit critique, en choisissant l’approche, en lisant chaque ligne et en la testant, alors non. Vous utilisez un bon outil.

Andrej Karpathy a lancé l’expression « vibe coding » en février 2025 pour décrire une façon de travailler où l’on décrit ce qu’on veut, on accepte tout ce que l’IA produit et on cesse de lire le code. Il parlait de projets de fin de semaine, et pour ça, c’est très bien. Un prototype jetable, un script qu’on n’exécutera qu’une fois, une petite expérience pour voir si une idée tient la route : laissez-vous aller.

Les problèmes commencent quand du code produit en vibe coding se retrouve en production. Les paiements, les connexions, les formulaires qui recueillent des renseignements personnels, tout ce dont un client dépend. Là, « ça avait l’air de fonctionner » n’est pas une norme.

Mon test est donc simple. Pourriez-vous expliquer ce changement à un collègue sans l’IA ouverte? Pourriez-vous défendre pourquoi c’est construit ainsi et pas autrement? Pourriez-vous le réparer à 2 h du matin quand ça plante? Si oui, vous avez utilisé un outil. Si non, vous avez confié le travail à quelqu’un d’autre.

L’IA rend-elle vraiment les développeurs plus rapides?

Parfois, et moins souvent qu’on le ressent. Les données les plus citées viennent de METR, un groupe de recherche qui a mené un essai randomisé au début de 2025 auprès de 16 développeurs open source expérimentés, sur 246 tâches réelles dans des projets qu’ils connaissaient bien. Chaque tâche était assignée au hasard : IA permise ou non. Avec l’IA permise, les tâches prenaient 19 % plus de temps.

Ce qui m’a marqué : avant l’étude, les développeurs s’attendaient à ce que l’IA les rende environ 24 % plus rapides, et même après, ils croyaient avoir été environ 20 % plus rapides. La sensation de vitesse et la vitesse réelle allaient dans des directions opposées.

METR a refait l’expérience à la fin de 2025 avec des outils plus récents et a publié une mise à jour en février 2026. Cette fois, l’estimation allait dans l’autre sens : environ 18 % plus rapides pour les développeurs qui sont revenus, et environ 4 % plus rapides pour les nouvelles recrues. Mais METR a jugé ses propres données fragiles. Beaucoup de développeurs refusaient désormais de travailler sans IA, et certains mettaient de côté les tâches qu’ils ne voulaient pas faire à la main, de sorte que l’étude manquait justement des personnes et des tâches pour lesquelles l’IA aide le plus. Sa conclusion honnête : les développeurs sont probablement plus rapides qu’au début de 2025, et personne ne peut encore dire de combien.

Ça ne veut pas dire que l’IA n’aide jamais. Selon moi, ces développeurs connaissaient leurs projets à fond, et c’est là que l’IA a le moins à apporter. Pour du code répétitif, une syntaxe qu’on ne connaît pas ou une première version de tests, le gain peut être réel. Mais on ne peut pas se fier à la sensation. Si vous voulez savoir si l’IA rend votre équipe plus rapide, mesurez le temps entre le début d’une tâche et sa livraison, révision et correctifs compris, et non le temps qu’il a fallu pour afficher une première version à l’écran.

La vitesse que vous ressentez n’est pas la vitesse à laquelle vous livrez.

L’IA devrait-elle changer votre processus de développement?

Non. L’IA devrait être un outil, pas un processus. Votre processus reste le même : comprendre le problème, choisir l’architecture, rédiger la spécification, construire, réviser, tester, livrer. L’IA, c’est quelque chose qu’on prend en main à l’intérieur de ces étapes pour arriver à destination avec moins d’effort ou moins d’erreurs. Ce n’est pas le chemin.

Beaucoup d’entreprises font l’inverse. Elles adoptent l’IA pour accélérer le processus, puis mesurent le succès à la vitesse à laquelle le code apparaît. En chemin, on perd de vue le vrai objectif. Les utilisateurs se fichent de la rapidité avec laquelle le code a été généré. Ce qui les intéresse, c’est que ce que vous avez livré compte pour eux et continue de fonctionner.

Le programme de recherche DORA de Google arrive au même constat, mais par l’autre bout. Son rapport 2025 sur le développement logiciel assisté par l’IA, fondé sur un sondage auprès de près de 5 000 professionnels des technologies, révèle qu’environ 90 % d’entre eux utilisent maintenant l’IA au travail, et que l’IA agit comme un amplificateur : elle grossit les forces des équipes qui fonctionnent déjà bien, et les problèmes de celles qui fonctionnent mal. Une équipe dotée d’un processus clair obtient une version plus rapide et plus précise d’elle-même. Une équipe qui n’en a pas obtient plus de chaos, plus vite.

Alors avant de vous demander comment l’IA peut accélérer votre processus, assurez-vous d’en avoir un qui vaut la peine d’être accéléré.

« Traiter l’IA comme un développeur junior », est-ce un bon conseil?

Seulement si vous savez encadrer un junior. C’est l’un des conseils les plus répétés dans l’industrie en ce moment : traitez le résultat de l’IA comme une pull request d’un développeur junior rapide. Lisez-la, remettez-la en question, testez-la, et ne la fusionnez jamais sur simple confiance.

Jusque-là, c’est juste. Le piège, c’est le mot « junior ». Encadrer des juniors est une compétence en soi. Quand j’ai dirigé des développeurs et accompagné des juniors, le travail ne consistait jamais seulement à lire leur code à la fin. Il fallait fixer l’architecture avant qu’ils commencent, écrire une spécification assez claire pour ne pas être mal interprétée, maintenir les standards et repérer tôt un mauvais virage.

Traiter l’IA comme un junior sans cette expérience, ça ne fonctionne pas. Si vous ne pouvez pas poser les bases, l’IA les posera à votre place, et vous ne saurez pas si elles sont solides. Si la base repose sur du sable, la fondation est fragile, peu importe la qualité de chaque fichier pris isolément. Garbage in, garbage out : une consigne vague de quelqu’un qui ne sait pas à quoi ressemble du bon code produit du code assuré et plausible, mais faux d’une manière qu’il ne remarquera pas.

Le conseil devrait plutôt être : traitez l’IA comme un junior, si vous êtes qualifié pour en encadrer un. Si vous ne l’êtes pas encore, c’est la compétence à développer en premier.

Le code écrit par l’IA est-il sûr à livrer?

Pas sans une vraie révision. Le GenAI Code Security Report 2025 de Veracode a testé plus de 100 modèles de langage sur 80 tâches de programmation et constaté que le code généré introduisait des failles de sécurité du OWASP Top 10 dans 45 % des cas. Le cross-site scripting était le pire : les modèles n’ont pas su s’en protéger dans 86 % des tâches concernées, ce qui compte pour quiconque crée des thèmes et des extensions WordPress, où l’échappement des données de sortie fait partie du quotidien. Les modèles plus récents écrivent du code qui fonctionne mieux, mais pas du code plus sécuritaire, et les plus gros modèles n’ont pas fait significativement mieux que les plus petits.

Il y a aussi un risque plus discret. Une étude sur les hallucinations de paquets présentée au USENIX Security Symposium en 2025 a fait écrire 576 000 échantillons de code à 16 modèles, puis vérifié les 2,23 millions de paquets demandés par ces échantillons. Parmi eux, 19,7 % n’existaient pas. Pour les modèles commerciaux, le taux était d’au moins 5 %, et d’environ 22 % pour les modèles open source. Les attaquants l’ont remarqué : ils publient des paquets malveillants sous les noms que les modèles ont tendance à inventer, si bien qu’un développeur qui installe tout ce que l’IA suggère peut introduire un logiciel malveillant directement dans son projet. Ça porte maintenant un nom : le slopsquatting.

Rien de tout ça ne signifie que le code de l’IA est pire que celui d’un humain par défaut. Ça signifie qu’il faut le réviser comme celui d’une personne, avec quelques vérifications en plus :

• Lisez chaque ligne avant la livraison, surtout tout ce qui touche aux entrées, aux sorties, aux connexions ou aux données personnelles.
• Vérifiez que chaque paquet ajouté par l’IA existe vraiment, qu’il est maintenu et que c’est bien celui que vous visiez.
• Lancez vos analyses de sécurité et vos tests sur les changements de l’IA exactement comme vous le feriez pour le travail de n’importe qui d’autre.
• Méfiez-vous du code qui a l’air terminé. Plausible ne veut pas dire correct.

L’IA peut-elle faire de vous un moins bon développeur?

Oui, si vous lui laissez faire votre apprentissage à votre place. En janvier 2026, Anthropic a publié une étude randomisée auprès de 52 ingénieurs, pour la plupart juniors, qui apprenaient Trio, une bibliothèque Python qu’aucun d’eux n’avait utilisée auparavant. Certains avaient un assistant IA; les autres codaient à la main. Ensuite, tout le monde a passé un quiz sur ce qu’il venait d’utiliser. Le groupe avec l’IA a obtenu en moyenne 50 %, contre 67 % pour le groupe qui codait à la main. Le plus grand écart portait sur le débogage, la compétence dont on a le plus besoin quand le code écrit par l’IA déraille. Et le groupe avec l’IA n’était pas vraiment plus rapide.

Ce qui compte le plus, c’est la façon dont les gens ont utilisé l’assistant. Ceux qui posaient des questions conceptuelles, demandaient des explications en plus du code ou posaient des questions de suivi pour vérifier leur compréhension ont conservé l’essentiel de leur apprentissage. Ceux qui ont simplement confié la tâche à l’IA, ou qui s’y sont appuyés de plus en plus au fil du temps, s’en sont le moins bien tirés.

Je le constate aussi en enseignement. Deux étudiants peuvent remettre le même formulaire de contact fonctionnel. Demandez à chacun d’ajouter une règle de validation, et la différence saute aux yeux : celui qui a demandé pourquoi le code fonctionne fait la modification en quelques minutes, alors que celui qui a collé la réponse repart d’une nouvelle requête. Les étudiants qui progressent avec l’IA sont ceux qui lui demandent pourquoi, pas seulement d’écrire le code.

Si vous êtes au début de votre carrière, c’est la section la plus importante. Utilisez l’IA comme un tuteur qui explique, pas comme un nègre littéraire qui fait le travail. Le jour où quelque chose plantera en production, vous aurez besoin de la compréhension que vous avez bâtie, pas du code que vous avez copié.

Comment j’utilise l’IA sans lui céder le travail?

Je garde la réflexion et je confie à l’IA les parties qui n’en demandent pas. Voici ma façon de travailler, sous forme de liste que vous pouvez reprendre :

1. L’architecture, c’est moi. Je décide comment les pièces s’assemblent avant qu’une seule ligne de code soit écrite.
2. La spécification vient d’abord. Je note ce que le code doit faire, et ce qu’il ne doit jamais faire, avant de demander quoi que ce soit à l’IA.
3. La base et le code critique, c’est moi. Tout ce dont dépend le reste du système, je l’écris moi-même.
4. L’IA m’aide à aller plus vite sur les parties routinières : code répétitif, modifications répétitives, premières ébauches.
5. L’IA met à l’épreuve ce que je construis : cas limites que j’aurais pu manquer, second avis sur une approche, tests auxquels je n’avais pas pensé.
6. Je révise chaque modification avant la mise en ligne. Si je ne peux pas l’expliquer, elle n’est pas fusionnée.
7. Les parcours utilisateur sont testés de bout en bout avec Playwright, de sorte que les flux sur lesquels les gens comptent sont vérifiés dans un vrai navigateur, peu importe qui a écrit le code.

Vous trouverez plus de détails sur ma façon de travailler avec l’IA sur la page d’accueil, et sur la façon dont j’ai dirigé et formé des développeurs sur la page À propos.

À quoi les équipes et les gestionnaires qui embauchent doivent-ils s’attendre?

Attendez-vous à ce que tout le monde utilise l’IA, et jugez les gens sur leur compréhension de ce qu’ils livrent. Le Developer Survey 2026 de Stack Overflow, publié en octobre 2026 auprès de plus de 30 000 répondants, a révélé que 66 % des développeurs qui utilisent l’IA se servent d’agents de codage, et que 73 % de ceux qui utilisent des assistants ou des agents IA le font tous les jours.

La confiance, c’est une autre histoire. Dans le sondage 2025 de Stack Overflow, seulement 33 % des développeurs disaient faire confiance à l’exactitude des outils d’IA, contre 43 % l’année précédente. En 2026, 93 % ont affirmé avoir besoin de voir d’où provient une réponse avant de lui faire confiance. Et les développeurs tracent leur propre limite : seulement 20 % utilisent l’IA pour déployer, exploiter ou dépanner des systèmes en production.

Pour les équipes, cela signifie :

• N’interdisez pas l’IA, et ne l’imposez pas non plus. Attendez-vous à ce qu’elle soit utilisée, et gardez la même norme de révision pour chaque modification, peu importe qui ou quoi l’a écrite.
• Mesurez ce que vous livrez et la fréquence à laquelle ça casse, pas la vitesse à laquelle le code apparaît.
• Faites de l’architecture et des spécifications la responsabilité de quelqu’un avant même que l’IA n’entre en jeu.

Pour les gestionnaires qui embauchent, demander « utilisez-vous l’IA? » ne vous apprend plus rien. Demandez plutôt aux candidats de vous guider à travers du code qu’ils ont écrit et d’en expliquer les décisions. Demandez ce qu’ils vérifieraient avant de fusionner une modification générée par l’IA. Le développeur qui sait répondre à ces questions est celui qu’il vous faut, avec ou sans IA.

Avant de fusionner votre prochaine modification faite avec l’aide de l’IA, essayez de l’expliquer à voix haute sans avoir l’IA sous les yeux. Si vous y arrivez, livrez-la. Sinon, ce n’est pas une raison d’arrêter d’utiliser l’IA. C’est le signe de l’endroit où la réflexion doit encore se faire.