Quand les IA génèrent du code, elles écrivent aussi des bugs à la chaîne

GitHub Copilot, ChatGPT, Claude… Les assistants d’IA qui crachent du code sur demande sont partout. En quelques secondes, ils pondent des fonctions complètes, des scripts, voire des applications entières. Sur le papier, c’est le rêve. Dans la vraie vie, c’est plus compliqué.

Le problème ? Ces outils ne comprennent rien à ce qu’ils écrivent. Ils recrachent des patterns qu’ils ont vus des millions de fois dans leur entraînement. Du coup, quand le pattern est mauvais, le code généré l’est aussi. Et ça arrive beaucoup plus souvent qu’on ne le croit.

Des failles de sécurité par milliers

Une étude de l’université de Stanford a analysé 1 600 projets où du code IA avait été utilisé. Résultat : 40% contenaient au moins une vulnérabilité critique. Injection SQL, gestion foireuse des mots de passe, validation inexistante des entrées utilisateur… Le florilège habituel.

Le truc, c’est que ces erreurs sont invisibles au premier coup d’œil. Le code fonctionne. Il fait ce qu’on lui demande. Mais il le fait mal, avec des trous béants côté sécurité. Et comme beaucoup de développeurs font confiance à l’IA sans tout vérifier ligne par ligne, les bugs passent en prod.

Concrètement, un développeur junior qui demande à ChatGPT de générer un système de login risque de se retrouver avec du code qui stocke les mots de passe en clair. Ou qui les hash avec MD5. Techniquement, ça marche. Niveau sécurité, c’est catastrophique.

L’effet copier-coller à l’échelle industrielle

Les IA ne créent rien. Elles recyclent. Et elles recyclent ce qu’elles ont vu le plus souvent dans les dépôts GitHub publics. Le souci, c’est que ces dépôts contiennent aussi des tonnes de mauvais code.

Du code obsolète, des librairies dépréciées, des pratiques abandonnées depuis dix ans… Tout ça se retrouve dans le corpus d’entraînement. Résultat : l’IA suggère d’utiliser une version d’OpenSSL qui date de 2015, ou de structurer une base de données comme on le faisait avant l’arrivée des ORM modernes.

En fait, c’est comme si on demandait à quelqu’un qui a appris à coder en lisant tous les tutoriels du web, bons et mauvais, de vous pondre une appli. Il va mixer les bonnes pratiques avec les horreurs qu’il a croisées. Sauf que lui, au moins, il peut réfléchir. L’IA, non.

Du côté des associations ou organisations qui documentent leurs activités en ligne, on retrouve d’ailleurs parfois cette même problématique de données obsolètes ou mal structurées. Un peu comme ce site qui compile les informations administratives des associations françaises : la masse de données est énorme, mais leur qualité dépend beaucoup de la source initiale.

Les développeurs seniors ne sont pas épargnés

On pourrait croire que seuls les débutants se font piéger. Pas du tout. Une enquête menée auprès de 500 développeurs avec plus de cinq ans d’expérience montre que 68% d’entre eux ont déjà intégré du code généré par IA sans le modifier. Et parmi eux, 52% ont découvert après coup que ce code contenait des bugs.

Le problème, c’est la confiance aveugle. Quand l’IA te sort 50 lignes de code propres, bien indentées, avec des noms de variables qui ont du sens, ton cerveau se dit : “OK, c’est bon”. Tu survoles, tu valides. Sauf que les bugs les plus vicieux ne se voient pas comme ça.

Un développeur senior racontait récemment avoir intégré une fonction de traitement de fichiers générée par Copilot. Tout roulait, sauf que la fonction ne gérait pas les erreurs d’accès disque. En environnement de test, zéro souci. En prod, avec des milliers de fichiers par jour, crash aléatoires. Impossible à déboguer pendant trois jours.

L’IA comme collègue incompétent

Au final, utiliser une IA pour coder, c’est un peu comme bosser avec un stagiaire ultra-rapide mais qui ne pose jamais de questions. Il fait ce que tu lui demandes, mais il ne comprend pas le contexte. Il ne sait pas que ton projet doit tourner sur des serveurs avec peu de RAM. Il ignore que tu utilises une architecture microservices. Il se fout complètement de tes contraintes métier.

Résultat : il te pond du code générique qui marche en théorie, mais qui ne colle pas à ta situation réelle. Et c’est toi qui te tapes le boulot de tout revoir, corriger, adapter. Au final, tu gagnes du temps ? Pas sûr.

Des boîtes commencent à mettre en place des process de review systématique du code généré par IA. Exactement comme on fait de la review de code entre humains. Ça prend du temps, mais c’est le seul moyen d’éviter la catastrophe. Parce que oui, une IA peut écrire du code rapidement. Mais elle peut aussi très rapidement te flinguer ton app.

Le débat fait rage dans la communauté dev. Certains refusent catégoriquement d’utiliser ces outils, les considérant comme des usines à dette technique. D’autres les adorent pour les tâches répétitives : générer des tests unitaires, écrire du boilerplate, créer des fichiers de config. Tout le monde s’accorde sur un point : ne jamais faire confiance aveuglément à ce qu’une IA génère.

Parce qu’au bout du compte, c’est pas l’IA qui va se prendre l’incident en prod à 3h du mat’. C’est toi.