Fin 2022, le monde s'est réveillé avec un seul nom partout : ChatGPT. Du jour au lendemain, tout le monde en parlait. Une IA capable d'écrire en quelques secondes un code qui prendrait une journée entière à un développeur. On s'est dit que c'était un gadget. On s'est trompé.
Les outils ont suivi, vite. Lovable, Claude Code, et tant d'autres. Chacun promettant d'aller plus vite, de coder mieux, de remplacer une partie du travail manuel. Aujourd'hui, en 2026, c'est presque hebdomadaire : un nouveau modèle sort, internet s'enflamme, on l'essaie, on l'oublie, le suivant arrive.
J'ai vécu cette accélération de l'intérieur, comme beaucoup de développeurs. Et avec elle, une question qui revient sans cesse : comment travailler avec ces outils sans perdre ce qui fait de nous de bons développeurs ? Faut-il leur faire confiance ? Où s'arrête l'aide, et où commence le risque ?
Cet article essaie d'y répondre. Pas avec des certitudes, mais avec des faits : les avantages réels de l'IA pour un développeur, et les risques (techniques, organisationnels, parfois même cognitifs) qu'elle apporte avec elle.
Comment travailler avec l'IA
Garder la responsabilité finale : l'IA est un « pair programmer junior »
L'IA n'est pas un oracle. C'est un collègue junior, très rapide, mais sans mémoire du projet. Il faut le traiter comme tel.
Addy Osmani, ingénieur chez Google, le dit clairement dans son retour d'expérience : il reste l'ingénieur responsable de tout ce qu'il merge, et ne livre un code qu'après l'avoir compris. Si le code généré lui semble étrange, il creuse, comme il le ferait avec un collègue qui propose quelque chose de louche.
Distinguer vibe coding et AI-assisted coding
Il y a deux façons d'utiliser l'IA en programmation.
- Le vibe coding : on décrit ce qu'on veut, l'IA fait tout, on ne comprend pas vraiment le résultat. Rapide, mais fragile.
- L'AI-assisted coding : le développeur garde la main. Il itère avec l'IA, mais reste celui qui décide, structure et valide.
Claire Longo, ingénieure en machine learning, insiste sur ce point dans ses bonnes pratiques : sans bases solides en ingénierie logicielle, on ne sait ni formuler la bonne demande, ni repérer les erreurs. On ne peut donc pas vraiment encadrer l'IA.
Préparer le terrain avant de générer
L'IA ne corrige pas une base de code défaillante. Elle l'amplifie.
Robert Hafner, dans son guide sur les assistants de code, est direct : sur une base de code saine, l'IA maintient cette qualité. Sur une base de code en mauvais état, elle l'aggrave, et plus vite.
Avant de générer du code avec l'IA, il faut donc s'assurer d'avoir :
- des tests existants ;
- une documentation à jour ;
- des standards de code clairs ;
- une architecture du projet claire et connue de l'équipe.
Ce ne sont plus des recommandations. Ce sont des prérequis.
Travailler par petites itérations validées
Plus on laisse l'IA itérer seule, sans contrôle humain entre les étapes, plus le risque augmente.
Une étude publiée en 2025 le mesure : sur 400 échantillons de code, les vulnérabilités critiques augmentent de 37,6 % après seulement cinq itérations de raffinement par l'IA seule. Le raffinement automatique ne rend pas le code plus sûr. Il le rend souvent moins sûr.
L'équipe Google Cloud, après plusieurs sprints d'ingénierie avec Gemini, recommande une méthode simple : demander à l'IA d'écrire un plan avant d'agir (un fichier plan.md), puis valider chaque étape avant de passer à la suivante.
Maintenir un fichier de contexte projet
Un assistant IA n'a pas de mémoire entre les sessions. Il faut la lui donner.
La même équipe Google Cloud propose de créer un fichier de contexte (par exemple GEMINI.md ou CLAUDE.md) mis à jour à la fin de chaque session de travail. Architecture, versions des dépendances, décisions prises : tout y est noté. L'IA repart avec le contexte du projet, pas de zéro.
Ne jamais sauter la revue de code
L'IA ne remplace pas la revue de code. Elle la rend plus importante.
Le rapport DORA 2025, basé sur près de 5 000 professionnels interrogés, est clair sur ce point : l'IA ne répare pas une équipe, elle amplifie ce qui existe déjà. Une équipe avec une revue de code rigoureuse en profite. Une équipe sans discipline de revue voit ses problèmes s'aggraver, plus vite.
Garder des moments de code « sans IA » pour ne pas perdre la main
Un bon développeur reste un développeur, même sans assistant.
Addy Osmani recommande de coder volontairement sans IA, de temps en temps, pour garder ses compétences de base affûtées. Selon lui, l'IA amplifie l'expertise existante, elle ne la remplace pas. Sans base solide, le risque est réel : produire quelque chose qui semble fonctionner, jusqu'à ce que tout s'effondre.
Les avantages
Des gains de vitesse, sur les bonnes tâches
Le chiffre le plus cité vient d'une expérience contrôlée menée avec GitHub Copilot : 95 développeurs devaient écrire un serveur HTTP en JavaScript. Le groupe équipé de l'assistant a terminé 55,8 % plus vite que le groupe sans assistant. Les développeurs les moins expérimentés sont ceux qui en ont le plus profité.
Ce gain est réel, mais il dépend de la tâche. Sur un exercice bien délimité, partant de zéro, l'IA excelle. Sur un projet mature et complexe, le résultat peut s'inverser, comme on le verra dans les risques.
Comprendre du code legacy, et arriver plus vite dans un projet
Expliquer du code fait partie des usages les plus répandus. D'après le rapport DORA 2024, les développeurs utilisent l'IA d'abord pour écrire du code et résumer de l'information, puis pour expliquer du code qu'ils ne connaissent pas.
C'est là que l'IA est la plus utile quand on rejoint un projet : demander ce que fait un module, d'où vient une donnée, pourquoi une fonction existe. Elle répond en quelques secondes là où il fallait parfois des heures de lecture ou attendre qu'un collègue soit disponible. À une condition : vérifier ses réponses dans le code, car une explication fausse peut sembler aussi convaincante qu'une juste.
Des tests et de la documentation à moindre coût
Les tâches que l'on repousse le plus volontiers sont souvent celles que l'IA fait le mieux : écrire les cas de test d'une fonction, documenter une API, résumer une décision.
Le rapport DORA 2024 le mesure : une hausse de 25 % de l'adoption de l'IA est associée à une amélioration de 7,5 % de la qualité de la documentation, le gain le plus fort de tous les facteurs étudiés. Les tests suivent la même logique : l'IA propose des cas, le développeur vérifie qu'ils testent vraiment quelque chose.
Un effet amplificateur pour les équipes déjà structurées
C'est la conclusion centrale du rapport DORA 2025 : 90 % des répondants utilisent l'IA au travail, et plus de 80 % estiment qu'elle a augmenté leur productivité. Pour la première fois, le rapport observe un lien positif entre l'adoption de l'IA et le débit de livraison.
Mais ce gain va surtout aux équipes qui ont déjà des tests automatisés, une gestion de versions rigoureuse et des boucles de retour rapides. Pour elles, l'IA accélère un système qui tient déjà debout.
Les risques
La sécurité
Le code généré par l'IA n'est pas sûr par défaut. Le rapport 2025 de Veracode, qui a testé plus de 100 modèles sur 80 tâches de code, conclut que 45 % des réponses introduisent une faille de sécurité connue. Le code compile, il fonctionne, et il est vulnérable.
Un risque plus récent vient des dépendances. Une étude présentée à USENIX Security 2025 a analysé 576 000 échantillons de code produits par 16 modèles : 19,7 % des paquets recommandés n'existaient pas. Plus de 205 000 noms de paquets inventés, dont une grande partie revient d'une génération à l'autre. Un attaquant n'a qu'à publier un paquet malveillant sous l'un de ces noms, et attendre qu'une IA le recommande. C'est ce qu'on appelle le slopsquatting.
Le faux sentiment de sécurité
Le risque le plus sournois n'est pas que l'IA se trompe. C'est qu'on ne le voie pas.
Une étude de Stanford l'a montré dès 2023 : les participants aidés par une IA ont écrit du code moins sûr que ceux qui codaient seuls, et ils étaient plus nombreux à croire que leur code était sûr. Les participants qui se méfiaient de l'IA et reformulaient leurs demandes produisaient moins de failles.
Le même décalage se retrouve sur la productivité. En 2025, METR a mené un essai contrôlé avec 16 développeurs expérimentés, sur 246 tâches réelles dans leurs propres projets open source. Avec l'IA, ils ont mis 19 % de temps en plus. Pourtant, après coup, ils estimaient que l'IA les avait rendus 20 % plus rapides. METR précise que ce résultat reflète les outils du début 2025, mais l'écart entre la perception et la mesure reste la vraie leçon.
Les développeurs eux-mêmes commencent à le sentir. Dans l'enquête Stack Overflow 2025, plus de 49 000 développeurs ont répondu : 46 % se méfient de la précision des outils d'IA, contre 33 % qui leur font confiance. Leur première frustration : des solutions « presque justes, mais pas tout à fait ».
Les risques organisationnels
Produire plus de code n'est pas la même chose que produire un meilleur logiciel.
Le rapport DORA 2024 associe une hausse de 25 % de l'adoption de l'IA à une baisse de 7,2 % de la stabilité des livraisons. L'explication avancée : des changements plus gros, plus difficiles à relire. Le rapport 2025 confirme que l'effet négatif sur la stabilité persiste : l'IA accélère le développement, et cette accélération expose les faiblesses en aval.
La dette technique suit. En analysant 211 millions de lignes de code, GitClear a observé qu'en 2024, pour la première fois, les lignes copiées-collées ont dépassé les lignes déplacées, un indicateur de refactoring. La part du code refactoré est passée de 25 % des lignes modifiées en 2021 à moins de 10 % en 2024. On ajoute du code plus vite qu'on ne le range.
Le risque cognitif
Déléguer la réflexion a un coût, et il se mesure.
En janvier 2026, Anthropic a publié une étude menée avec 52 développeurs, surtout juniors, qui devaient apprendre une bibliothèque qu'ils ne connaissaient pas. Ceux qui utilisaient l'IA ont obtenu 17 % de moins au quiz final, sur des notions qu'ils venaient pourtant d'utiliser. Le gain de temps, lui, n'était pas significatif. Mais la façon d'utiliser l'IA changeait tout : ceux qui s'en servaient pour poser des questions et comprendre s'en sortaient bien, ceux qui lui déléguaient l'écriture du code beaucoup moins.
Une étude de Microsoft Research et Carnegie Mellon, présentée à CHI 2025 auprès de 319 professionnels, va dans le même sens : plus on fait confiance à l'IA, moins on exerce son esprit critique. À l'inverse, plus on a confiance en ses propres compétences, plus on vérifie.
C'est le cercle qu'il faut éviter : moins on pratique, moins on sait vérifier, plus on fait confiance à l'IA.
Un risque propre aux agents : l'injection de prompt et la fuite de données
Les assistants ne se contentent plus de suggérer du code. Ils lisent des tickets, parcourent des dépôts, exécutent des commandes. Et ils ne font pas la différence entre une instruction de leur utilisateur et un texte malveillant caché dans ce qu'ils lisent.
Simon Willison a donné un nom à la combinaison dangereuse : la « trifecta létale ». Un agent qui a en même temps accès à des données privées, qui lit du contenu non fiable et qui peut communiquer vers l'extérieur peut être détourné pour exfiltrer ces données.
Ce n'est pas théorique :
- En mai 2025, Invariant Labs a montré qu'un simple ticket déposé sur un dépôt public GitHub pouvait pousser l'agent d'un développeur à lire ses dépôts privés et à en publier le contenu dans une pull request publique. Le problème ne venait pas d'un bug, mais d'un agent qui avait accès à tout à la fois.
- En juillet 2025, une instruction demandant d'effacer des fichiers locaux et des ressources cloud a été glissée dans l'extension Amazon Q pour VS Code, puis publiée dans une version officielle. AWS a retiré la version et indique qu'aucune ressource client n'a été touchée.
Conclusion
En 2022, ChatGPT nous a surpris. En 2026, l'IA fait partie du quotidien de presque tous les développeurs. La question n'est plus « faut-il l'utiliser ? ». Elle est dépassée. La vraie question, c'est « comment l'utiliser sans se perdre ? ».
J'ai essayé d'y répondre honnêtement dans cet article. Pas en diabolisant ces outils. Pas en les idolâtrant non plus.
La vérité, c'est que l'IA amplifie ce qui existe déjà. Une équipe rigoureuse, avec de bonnes pratiques, une vraie culture de revue de code et des tests solides, devient encore meilleure avec l'IA. Une équipe désorganisée, elle, devient plus chaotique, plus vite. Le rapport DORA 2025 l'a confirmé avec les données de près de 5 000 professionnels.
L'IA ne corrige pas les mauvaises habitudes. Elle les accélère.
Alors ce qui fait un bon développeur en 2026 n'a pas fondamentalement changé. Comprendre ce qu'on écrit. Tester. Relire. Rester responsable du code qu'on livre. Ce qui a changé, c'est que ces exigences sont devenues non négociables. Avec l'IA, on va plus vite. Si les fondations sont fragiles, on tombe aussi plus vite.
L'outil est puissant. Mais le développeur reste le pilote.