BlogQualité · 1 octobre 2026

Prototype généré par IA : les angles morts de sécurité

Un prototype créé avec un agent IA peut être très réussi et pourtant fragile. Les points de sécurité à vérifier avant d'y mettre de vraies données.

Tous les articles Nous écrire

Prototype généré par IA : les angles morts de sécurité

Les agents IA permettent aujourd'hui de construire en quelques jours un prototype qui aurait demandé des semaines. C'est une avancée réelle, et nous l'utilisons nous-mêmes. Mais un prototype qui fonctionne n'est pas un prototype sûr. L'agent a répondu à la demande, « fais un écran qui affiche les dossiers », sans forcément se demander qui a le droit de voir quels dossiers. Ces angles morts ne sont pas propres à l'IA : on les retrouve dans tout code écrit vite. Ils deviennent simplement plus fréquents quand la production s'accélère. Voici les points à vérifier avant de confier de vraies données à un prototype.

1. Les autorisations côté serveur

Une porte cadenassée dans un pan de mur qui laisse un passage libre à côté. — Masquer un bouton ne ferme pas l'accès.

C'est l'angle mort le plus courant. L'interface cache un bouton « Supprimer » aux utilisateurs qui n'en ont pas le droit, mais le serveur, lui, accepte la demande si on l'envoie directement. N'importe qui sachant ouvrir les outils de développement de son navigateur peut alors contourner l'interface.

Le classement OWASP Top 10, référence publique des risques applicatifs, place le contrôle d'accès défaillant en première position. La règle est simple à énoncer : chaque action, chaque lecture et chaque écriture doit vérifier côté serveur que l'utilisateur a le droit d'agir sur cette donnée précise.

Le cas particulier des identifiants

Une adresse du type /factures/1042 invite à essayer /factures/1043. Si le serveur ne vérifie pas que la facture appartient bien à l'utilisateur connecté, il la renvoie. Ce défaut, décrit depuis longtemps, reste l'un des plus répandus.

2. Les secrets dans le code

Pour qu'un prototype fonctionne vite, il est tentant de placer directement dans le code la clé d'une API, le mot de passe de la base ou le jeton d'un service de paiement. Si ce code est partagé, publié sur un dépôt ou, pire, envoyé au navigateur, ces secrets sont exposés.

À vérifier :

aucun secret dans le code source ni dans l'historique du dépôt ;

aucun secret dans le code exécuté par le navigateur ;

des secrets stockés dans des variables d'environnement ou un coffre dédié ;

une rotation des clés si l'une d'elles a pu fuiter.

Le guide de l'OWASP sur la gestion des secrets détaille ces bonnes pratiques.

3. Les entrées non contrôlées

Tout ce qui vient de l'utilisateur doit être considéré comme suspect : champs de formulaire, paramètres d'adresse, fichiers envoyés. Sans validation côté serveur, on s'expose aux injections (une requête de base de données détournée), à l'exécution de scripts dans la page d'autres utilisateurs, ou à l'envoi de fichiers malveillants.

Les bibliothèques modernes protègent contre une partie de ces risques par défaut, à condition de les utiliser comme prévu. Un prototype assemblé rapidement contourne parfois ces protections sans le savoir.

4. Les dépendances

Un agent IA ajoute volontiers une bibliothèque pour résoudre un problème. Chacune est du code écrit par d'autres, avec ses propres failles éventuelles. Il arrive aussi qu'un nom de paquet proposé n'existe pas, ou ressemble à s'y méprendre à un paquet connu : installer sans vérifier, c'est risquer d'intégrer un paquet malveillant.

Les bons réflexes : vérifier l'origine et la maintenance de chaque dépendance, retirer celles qui ne servent plus, et activer une analyse automatique des vulnérabilités connues.

5. Les données personnelles

Un prototype de démonstration utilise des données fictives. Le jour où l'on y saisit de vraies données de clients ou de salariés, le RGPD s'applique pleinement. Son article 32 demande des mesures de sécurité adaptées au risque, et son article 33 impose de notifier à l'autorité de contrôle une violation de données dans les meilleurs délais, et si possible dans les 72 heures. Il vaut mieux se poser les questions avant : où sont hébergées les données, qui y accède, sont-elles sauvegardées et chiffrées ?

6. Les fonctions qui appellent un modèle d'IA

Si l'application elle-même intègre un modèle de langage (un assistant, un résumé automatique), de nouveaux risques apparaissent : instructions malveillantes cachées dans un document, fuite de données vers le modèle, actions déclenchées sans contrôle. L'OWASP publie une liste dédiée aux risques des applications utilisant des grands modèles de langage. Le principe directeur : le modèle ne doit jamais avoir plus de droits que l'utilisateur pour lequel il agit.

Comment procéder

Il ne s'agit pas de jeter le prototype. Il s'agit de le relire avec les bonnes questions, dans le bon ordre : autorisations, secrets, entrées, dépendances, données, puis le reste. Chez Hultra Studio, cette relecture fait partie de l'évaluation que nous menons avant toute reprise, décrite dans la méthode Hultra. Aucune relecture ne garantit une sécurité absolue ; elle réduit les risques connus et met en place les moyens de réagir.

Questions fréquentes

Le code généré par IA est-il moins sûr que le code écrit à la main ?

Pas par nature. Les mêmes défauts existent dans du code écrit vite par une personne. La différence tient au volume : on produit plus de code, plus vite, et la relecture doit suivre.