L’illusion dangereuse du développeur seul avec l’IA
Traduit de l’anglais. Lire l’original en English.
Le piège du “ça marche”
Des outils comme Claude Code, Cursor et GitHub Copilot nous font livrer des fonctionnalités plus vite qu’à la main. Je les utilise tous les jours. Mais je vois un schéma dans des projets open source et dans des bases de code d’entreprise où la personne qui écrit le prompt cesse de faire partie du processus.
Ça se passe comme ça. Vous traitez l’IA comme quelqu’un que vous avez embauché et à qui vous faites confiance pour bien faire. Vous écrivez le prompt. Vous copiez le résultat. Vous déployez. Si ça compile ça sort.
C’est comme ça qu’on obtient des trous de sécurité où passe un camion. J’ai trouvé de l’authentification côté navigateur, des chemins de fichiers non validés et un accès au shell sans restriction dans plusieurs interfaces web qui, selon leurs propres auteurs, étaient entièrement générées par IA. Des portes fermées avec la clé collée à côté.
L’IA est un junior avec un turbo
Imaginez un développeur junior qui tape mille mots par minute et connaît toutes les bibliothèques qui existent. Ajoutez-lui deux traits de plus.
Il n’a aucune idée de ce qu’est un problème de sécurité sauf si quelqu’un le lui dit. Et il ne dit jamais qu’il ne sait pas quelque chose. Il vous donne une réponse sûre d’elle et fausse.
Laisseriez-vous cette personne pousser en production sans que personne ne relise ? Bien sûr que non.
C’est exactement ce que fait un projet mené seul avec l’IA. Le modèle est très bon pour résoudre ce qu’il a sous les yeux et il n’a aucune raison de penser à ce qui arrive quand quelqu’un envoie une requête que vous n’avez pas prévue. Un paramètre de chemin avec ../../ ne fait pas partie de la tâche demandée donc il n’entre jamais dans le tableau.
La boucle qui produit des bugs
Le mode de défaillance que je vois le plus est la boucle de contexte. Vous donnez un bug à l’IA. Elle vous rend du code. Le code échoue encore. Vous collez l’erreur et vous recevez une version “corrigée”.
Cinq tours plus tard quelque chose tourne. Vous avez aussi un tas de correctifs qui ont chacun réglé un symptôme et le modèle a perdu la forme du système avec lequel il a commencé. Il ajuste maintenant du code au message d’erreur au lieu du design.
C’est là que les vulnérabilités entrent. Dans la hâte de passer les tests au vert une vérification de permission saute. La validation d’entrée disparaît parce qu’elle gênait. Une clé se retrouve écrite en dur parce que la variable d’environnement était pénible. Personne ne le remarque parce que tout le monde regarde le test qui passe enfin.
Comment vraiment utiliser l’IA
La réponse n’est pas d’utiliser moins d’IA. La réponse est de rester à votre place. Vous êtes l’ingénieur responsable et l’IA est la personne avec qui vous travaillez.
N’acceptez pas de code que vous ne pouvez pas expliquer
Si l’IA écrit un bloc que vous ne comprenez pas alors arrêtez. Demandez-lui d’expliquer le bloc ligne par ligne. Si vous ne pouvez toujours pas dire pourquoi c’est sûr alors partez du principe que ça ne l’est pas. Cette seule règle attrape presque tous les dégâts avant qu’ils n’arrivent.
Contestez le résultat
Parlez-lui comme à un collègue qui a écrit quelque chose de négligé.
- “Tu as retiré le jeton CSRF dans ce refactor. Pourquoi il devait partir ?”
- “Ce gestionnaire d’entrée semble vulnérable au XSS. Réécris-le avec de la sanitisation.”
- “Tu utilises
dangerouslySetInnerHTMLici. Il y a un moyen plus sûr ?”
La dernière vaut la peine d’être dite à voix haute parce que le modèle répète le schéma qu’il a utilisé la dernière fois. Nommer le problème suffit souvent pour obtenir une meilleure réponse au tour suivant.
Lisez le diff
Ne lisez pas seulement le fichier final. Lisez ce qui a changé.
A-t-il supprimé une vérification de permission en rangeant autre chose ? A-t-il retiré un appel de validation parce que le chemin heureux n’en avait pas besoin ? Les modèles travaillent dans une fenêtre de contexte et perdent silencieusement des contraintes posées deux heures plus tôt. Le diff est le seul endroit qui montre ce qui a quitté le bâtiment.
Gardez les vérifications hors du chat
On peut convaincre un modèle qu’un test passe. Votre CI non. L’authentification et l’autorisation vivent dans le code et dans le pipeline où l’agent doit les satisfaire. La validation d’entrée vit à la frontière où les données arrivent plutôt que dans un prompt dont vous espérez qu’il se souvienne.
Conclusion
L’IA rend un ingénieur solide beaucoup plus rapide et fait échouer plus vite un processus négligé. Si votre intention est de livrer maintenant et de voir ce qui se passe alors le modèle vous aidera à faire exactement ça. Si votre intention est de livrer quelque chose qui tient alors il vous aidera aussi. L’intention est la vôtre dans les deux cas.
C’est vous qui conduisez. L’IA lit la carte et discute la sortie avec vous et cette discussion est la partie utile.