Les failles les plus fréquentes dans une app générée par l'IA

Les failles d'une application générée par IA se ressemblent beaucoup, parce qu'elles viennent des mêmes oublis : on a construit ce qui doit marcher, pas ce qui doit résister. Voici le catalogue des plus courantes, chacune expliquée en une phrase et avec une façon de la repérer.

L'immeuble et ses points faibles

Pensez à la façade d'un immeuble : une fenêtre restée entrouverte, une clé sous le paillasson, une porte de service jamais fermée. Aucune n'est spectaculaire, mais il suffit d'une seule pour entrer. Il en va de même pour une application.

Les huit failles typiques

1. Des données lisibles par tous. La base de données ne vérifie pas qui a le droit de lire quoi. Un utilisateur connecté peut alors voir les informations d'un autre. C'est l'une des plus fréquentes, et l'une des plus lourdes de conséquences. Voir les règles d'accès à la base.
2. Des clés visibles dans le code. Une clé d'accès à un service tiers (paiement, e-mail, IA) se retrouve dans la partie du code envoyée au navigateur, donc lisible par n'importe qui. Voir les clés API exposées.
3. Des contrôles faits seulement à l'écran. Un bouton « supprimer » est caché aux simples utilisateurs, mais le serveur accepte la demande de n'importe qui. Cacher n'est pas interdire : la vérification doit se faire côté serveur.
4. Des pages d'administration mal protégées. L'adresse du back-office est devinable, et rien n'oblige à être administrateur pour l'ouvrir.
5. Des saisies prises pour argent comptant. Un champ de texte accepte tout, y compris du code malveillant. Selon le cas, cela ouvre la porte à des attaques comme l'injection SQL ou le XSS.
6. Aucune limite sur les demandes. Rien n'empêche quelqu'un d'essayer mille mots de passe par minute, ou de faire exploser votre facture d'un service payant. C'est le rôle du rate limiting.
7. Des messages d'erreur trop bavards. En cas de problème, l'application affiche des détails techniques utiles à un attaquant : noms de tables, chemins, versions.
8. Des composants jamais mis à jour. Le code s'appuie sur des bibliothèques toutes faites. Si l'une d'elles a une faille connue et corrigée, mais que personne ne met à jour, la faille reste ouverte.

Pourquoi l'IA les laisse passer

L'outil répond à votre demande, rarement à ce que vous n'avez pas demandé. Si vous écrivez « affiche la liste des commandes », il affiche la liste des commandes. Il ne se demande pas toujours « de qui sont-elles ? ». Et lorsque le résultat fonctionne à l'écran, rien n'alerte personne : une faille ne fait aucun bruit tant que personne ne l'exploite.

Autre difficulté : ces failles sont invisibles en usage normal. Vous ne les rencontrerez pas en testant votre application comme un client. Il faut volontairement chercher à contourner.

Comment les repérer soi-même

Sans aucune compétence technique, trois gestes valent le coup :

• ouvrir deux comptes de test et vérifier qu'ils sont bien cloisonnés ;
• tester l'adresse d'une page privée une fois déconnecté ;
• regarder, avec une personne qui sait lire le code, si des clés y apparaissent.

Au-delà, une relecture extérieure est plus efficace, parce qu'elle suit une méthode : elle passe chaque catégorie en revue au lieu de tomber sur les problèmes au hasard.

Pour la vue d'ensemble, lisez d'abord mon application générée par IA est-elle sécurisée ?.

À retenir

Les failles d'une application générée par IA tiennent le plus souvent à des oublis, pas à des erreurs savantes : accès aux données, clés visibles, vérifications absentes. Chacune se corrige, à condition d'être cherchée.

Et pour votre produit ?

Un audit passe votre application en revue sur ces catégories et vous remet une liste ordonnée : ce qui est urgent, ce qui peut attendre. Si vous voulez savoir où vous en êtes, nous pouvons en parler pendant un échange de 30 minutes.