Pourquoi le code généré par l'IA exige un review humain (et pourquoi c'est normal)

Le dev logiciel vit une révolution. Des outils comme Claude ou ChatGPT transforment une idée en code fonctionnel en jours, pas en semaines. Tu décris une fonctionnalité, tu valides les diffs, tu itères, tu déploies. Ça booste la productivité comme jamais.

Mais attention, il y a un hic.

J'ai passé un après-midi à reviewer du code issu de ce workflow. Un outil interne simple, pas critique, mais typique de 2024. Pas de folie AI ici. Juste 28 problèmes, surtout sécurité, avec des failles OWASP Top 10 connues depuis 20 ans.

Ce n'est pas l'IA qui déraille. C'est la vitesse qui dépasse la réflexion structurée anti-risques.

Le vrai souci : la question que tu n'as pas posée

Le code était solide. Architecture cohérente. Composants bien découpés. Librairies pertinentes. À vue d'œil, indistinguishable d'un weekend solo.

La faille est ailleurs. Dans le "avant" le premier commit.

L'IA excelle à exécuter tes ordres. "Fais-moi un système de gestion users" ? Voilà. Mais elle ne pose pas les bonnes questions : qui y accède ? Quelles données sensibles ? Auth où ? Et si on bypass le frontend ?

Elle livre la feature. Pas l'architecture sécurisée qui te laisse dormir.

Exemple concret : la fonction admin sans garde-fou

Imagine une serverless function pour les ops admin : créer users, reset passwords, supprimer comptes. Logique de garder les creds puissants server-side, jamais exposés browser.

Problème : zéro check auth.

Pas faible, pas mal choisi. Aucun. Ouvre DevTools, trouve l'endpoint, POST direct : tu crées des admins, resets, nukes la DB.

Le frontend cachait bien le bouton aux non-admins. Intention sécurisée. Mais inutile : la sécu UI, c'est de l'illusion.

Classique bypass auth, OWASP depuis 2003. Pourquoi l'IA l'a zappé ? Le prompt : "fonction pour admins créer users". Elle le fait. Pour tous, car tu n'as pas dit "seulement admins".

L'IA ignore tes oublis.

La DB sécurisée... sur le papier

Autre cas classique. Ta DB gère row-level security (RLS) pour limiter accès par user ID. Top pour une API key shippée en JS.

Un dev demande multi-user à l'IA. Elle ajoute tables avec RLS nickel. Parfait.

Mais les 5 tables existantes – tes données business – ? Oubliées. RLS activé ou pas ? La migration s'en fout.

npm run db:push sur infra neuve : nouvelles tables blindées, legacy grandes ouvertes à qui connaît l'endpoint.

L'IA n'est pas fausse. Juste incomplète. Elle résout le prompt étroit, sans alerter sur l'hypothèse implicite (tout sécuriser ?).

Comment adapter ton workflow dev

Pas question de virer l'IA. La vitesse compte. Mais impose un review humain sur l'architecture, pas que la syntaxe.

Ce qui marche :

Checklist sécu upfront. Qui appelle l'endpoint ? Sans perm, que se passe-t-il ? Données publiques ? RLS partout ? Documente les assomptions.

Threat modeling par seniors, pas line-by-line. Mes 28 issues ? Oversights architecturaux. IA pour générer, humains pour anticiper risques.

Prompts explicites sur auth. Pas "endpoint user management". Mais "endpoint user management accessible seulement logged-in admin, documente tes choix auth".

Tests auth séparés. Vérifie que non-auth peuvent pas agir, pas juste que auth peuvent.

Le pattern à retenir

L'IA ne pond pas du code insecure. Elle exécute pile ce que tu demandes, et rate tes oublis.

C'est un atout : responsive, pas d'hallucinations. Mais la responsabilité bascule. L'IA applique ton design sécu à l'échelle. Pas le contraire.

Mon code ? Un humain a dit "endpoint sans auth". Fix en minutes. Vuln 20 ans d'âge vs workflow 2024 : le workflow gagne, grâce à l'œil expert.

Modèle durable : IA pour vitesse, humains pour structure. Indissociables.

Évite ces pièges dans ton code ? Chez NameOcean, on voit des startups galérer avec la tech debt des features rushées. Notre plateforme d'hébergement cloud intègre la sécu structurelle : rate limiting, gestion API keys, audit logs automatiques. Même si tu oublies de demander. Idéal pour shipper vite sans stress.