Le code construit par l'IA est-il vraiment sécurisé ? Une FAQ pour les builders

Je reçois une variante de cette question dans presque chaque appel d'onboarding, généralement formulée avec précaution, comme si la personne s'attendait à moitié à ce qu'on la rassure. Elle ne devrait pas être rassurée. La sécurité est l'un des rares domaines où une bonne dose de paranoïa est correctement calibrée, que le code ait été écrit par un humain ou par un modèle. Voici les questions qu'on me pose réellement, avec les réponses les plus directes possibles.

Le code écrit par une IA est-il moins sécurisé que celui écrit par un humain ?

En moyenne, et sans contrôle, oui — légèrement. Une étude de Stanford datant de quelques années (Perry et al., souvent citée comme le premier vrai regard sur ce sujet) a montré que les développeurs utilisant un assistant de code IA produisaient du code moins sécurisé qu'un groupe témoin, et — c'est la partie qui devrait vous inquiéter davantage — évaluaient leur propre code comme plus sécurisé qu'il ne l'était réellement. La confiance augmentait tandis que la qualité baissait. Les scans de sécurité GenAI plus récents de Veracode donnent aussi un chiffre approximatif : environ 4 échantillons de code généré par IA sur 10 testés introduisaient au moins une faille exploitable, généralement quelque chose de banal comme une vérification d'entrée manquante ou une valeur par défaut faible. Rien de tout cela ne signifie que le code écrit par IA est intrinsèquement condamné. Cela signifie que le code écrit par IA et non relu comporte le même risque que le code humain non relu, et c'est justement dans le « non relu » que réside le vrai danger. Un modèle qui écrit vite et n'est jamais vérifié commettra les mêmes erreurs qu'un développeur junior un vendredi après-midi — juste plus vite, et en plus grand nombre.

Que deviennent mes clés API et mes secrets ?

C'est celle qui m'empêche vraiment de dormir, parce que c'est l'erreur invisible jusqu'à ce qu'elle ne le soit plus. Le mode de défaillance n'est pas spectaculaire — personne ne se fait pirater son serveur comme dans un film. C'est une clé collée dans une conversation, renvoyée dans un fichier généré, committée, et qui se retrouve tranquillement en clair dans un dépôt six mois plus tard, quand quelqu'un lance un scanner de secrets par curiosité. Sur cette plateforme, les secrets ne se trouvent jamais dans le code source généré — ils sont injectés au moment de l'exécution depuis un stockage chiffré, cantonné à votre tenant, et les agents de build ont pour consigne de les référencer par leur nom, jamais par leur valeur. Mais si vous construisez ailleurs, ou si vous collez des identifiants directement dans une fenêtre de chat avec n'importe quel outil, considérez que ce texte fait désormais partie d'un journal proche de l'entraînement quelque part, sauf indication contraire explicite du fournisseur. Par principe, faites tourner tout ce que vous avez tapé dans une boîte de chat, le jour même où vous terminez vos tests.

Quelqu'un peut-il pirater mon site via un prompt, comme une attaque par injection de prompt ?

Deux choses différentes sont souvent confondues ici, et la distinction compte. L'injection de prompt contre le constructeur — quelqu'un qui manipule l'IA qui construit votre application pour lui faire faire quelque chose que vous n'avez pas demandé — est un risque réel et étudié, et c'est pourquoi les agents de build fonctionnent avec des permissions d'outils restreintes plutôt qu'un accès shell complet, et pourquoi tout ce qui touche à votre système de fichiers ou à votre pipeline de déploiement passe par un journal d'actions explicite que vous pouvez auditer après coup. L'injection de prompt contre votre application déployée est une préoccupation distincte, qui ne s'applique que si votre application elle-même intègre un LLM à l'exécution — un chatbot de support, une fonctionnalité de recherche IA, ce genre de chose. Si c'est le cas, traitez tout texte qu'un utilisateur peut saisir comme une entrée non fiable pour ce modèle, exactement comme vous le feriez pour une requête SQL. La règle est ancienne, la nouveauté, c'est juste le système qui analyse la chaîne.

Le constructeur vérifie-t-il lui-même son code contre les vulnérabilités avant de le livrer ?

Les contrôles automatisés détectent de manière fiable les problèmes courants et répétitifs : secrets codés en dur, absence d'authentification sur un endpoint qui en a manifestement besoin, requêtes SQL construites par concaténation de chaînes plutôt que par paramètres, dépendances avec une CVE connue. Ce qu'ils ne détectent pas bien, ce sont les failles de logique métier — celles où chaque ligne de code prise isolément est correcte, mais où la vulnérabilité se cache dans l'interstice entre deux fonctionnalités que personne n'a pensé à vérifier ensemble. Un code de réduction qui se cumule à l'infini avec un bonus de parrainage. Un flux de réinitialisation de mot de passe qui révèle si un e-mail existe dans le système. Cela nécessite quelqu'un qui comprend à quoi sert l'application pour, pas seulement ce que fait le code, et aucun scanner — IA ou autre — ne les détecte encore de manière fiable. La revue automatisée est un plancher, pas un plafond.

Et les paquets tiers qu'elle installe — est-ce un risque de chaîne d'approvisionnement ?

Oui, et c'est honnêtement un risque plus important dans la réalité que le code écrit par l'IA elle-même. La plupart des applications sont composées à 80-95 % de dépendances en nombre de lignes ; le code qu'écrit un constructeur n'est qu'une fine couche par-dessus npm, PyPI, ou tout autre écosystème utilisé par la stack. Un paquet malveillant ou détourné peut vous compromettre indépendamment de qui ou de quoi a écrit le code de liaison autour — voyez les incidents event-stream et colors.js pour un exemple concret de la manière dont cela se déroule en pratique. Les mesures d'atténuation sont ennuyeuses mais efficaces : figer les versions plutôt que suivre la dernière, préférer les paquets avec un vrai historique de maintenance à ceux publiés la semaine dernière, et exécuter un audit de dépendances (`npm audit`, `pip-audit`, ou tout ce qui convient à votre stack) comme une habitude permanente, pas une étape ponctuelle avant le lancement.

Qui est responsable en cas de faille ?

C'est vous — légalement, presque toujours, si c'est votre application et les données de vos clients. Cela surprend les gens qui supposent que « c'est l'IA qui l'a écrit » déplace la responsabilité ailleurs. Ce n'est pas le cas, pas plus que faire appel à un entrepreneur ne déplace la responsabilité d'une violation du code du bâtiment loin du propriétaire. Les plateformes assument la responsabilité de l'infrastructure qu'elles contrôlent : comment les secrets sont stockés, comment les données des tenants sont isolées, si la couche d'hébergement elle-même est corrigée. Mais la logique applicative que vous avez spécifiée, les données que vous avez choisi de collecter, et les conditions que vous avez proposées à vos utilisateurs vous appartiennent. Si vous gérez quoi que ce soit de sensible — détails de paiement, informations de santé, tout ce qui relève du RGPD ou du CCPA — lisez le véritable accord de traitement des données de la plateforme que vous utilisez au lieu de supposer que « construit par IA » implique une quelconque couverture juridique supplémentaire. Ce n'est pas le cas.

Une fondatrice m'a dit un jour, mi-sérieuse, qu'elle faisait plus confiance au code de l'IA qu'au sien propre parce qu'« au moins, elle ne se fatigue pas à 2h du matin ». Peut-être. Mais les humains fatigués savent généralement qu'ils sont fatigués. Une IA n'a aucune idée qu'elle vient de faire une erreur, et elle vous dira que le code est terminé avec exactement le même ton confiant, qu'il soit impeccable ou criblé de failles. La confiance n'est un signal de sécurité pour aucune des deux sources.

Dois-je payer pour un vrai audit de sécurité avant de lancer ?

Si vous encaissez des paiements, stockez quoi que ce soit qu'un régulateur qualifierait de données personnelles, ou construisez pour un client professionnel qui exigera de toute façon un rapport SOC 2 — oui, et ne laissez pas le coût vous en dissuader. Un audit ciblé sur une petite application coûte de quelques centaines à quelques milliers de dollars selon la portée, ce qui est peu cher comparé à une lettre de notification de violation de données. Si vous construisez un projet personnel, un outil interne, ou quelque chose sans véritable donnée utilisateur en jeu, un audit payant est excessif ; utilisez plutôt la couche gratuite et bon marché — analyse des dépendances, parcours manuel de chaque frontière d'authentification (l'utilisateur A peut-il voir les données de l'utilisateur B en modifiant une URL ?), et un second regard humain sur tout ce qui touche à l'argent ou aux mots de passe.

Quelle est l'erreur de sécurité la plus fréquente, et à quel moment survient-elle ?

Pas au lancement — trois mois après, quand l'application fonctionne et que plus personne ne la surveille. C'est une route d'administration laissée sans protection parce qu'elle n'a jamais été testée que par la personne qui l'a construite, connectée en tant qu'elle-même. C'est un endpoint de débogage qui renvoie des traces de pile complètes en production. C'est un mot de passe par défaut sur une base de données censée être « juste pour les tests » et jamais changé. Rien de tout cela n'est exotique. C'est l'équivalent, en sécurité, de laisser un double des clés sous le paillasson parce qu'on était pressé une fois et qu'on a oublié qu'il était là. La solution n'est pas un meilleur outil, c'est une habitude de cinq minutes : une fois par mois, regardez votre application comme le ferait un attaquant pendant cinq minutes avant de la regarder comme le ferait un créateur fier.