Sécuriser une application créée avec l'IA : 6 contrôles avant la mise en ligne

Introduction

Votre application tourne. Vous l'avez construite avec un assistant IA ou un outil no-code, elle affiche les bonnes pages, les bons boutons, et un ami a réussi à s'y connecter. Vous êtes à quelques jours de la mettre devant de vrais utilisateurs. C'est le bon moment pour une question que beaucoup de fondateurs se posent trop tard : qui peut lire, modifier ou supprimer les données de mes utilisateurs ?

Une application qui fonctionne n'est pas forcément une application sûre. L'IA produit du code qui répond à la demande qu'on lui fait ; elle ne sait pas toujours ce que vous n'avez pas demandé, comme limiter l'accès aux données ou cacher une clé. Ce guide vous donne six contrôles à faire vous-même, sans savoir coder, avant la mise en ligne. Il ne remplace ni un expert en sécurité ni les obligations légales de votre activité : il vous évite les erreurs les plus courantes et vous aide à savoir quoi demander à un tiers.

Pourquoi une application créée avec l'IA mérite un contrôle

Un assistant de code livre ce que vous décrivez. Si vous demandez « une page où chaque client voit ses commandes », il construit la page. Il ne vérifie pas forcément qu'un client ne peut pas voir celles d'un autre en changeant un identifiant dans l'adresse. Cette catégorie d'erreur porte un nom dans le référentiel OWASP : le contrôle d'accès défaillant, classé en première position dans l'édition 2025 du Top 10.

Trois raisons rendent ce contrôle particulièrement utile pour un premier produit :

• Le code n'a pas été relu par un humain. Quand personne ne lit chaque fichier, une faille peut rester invisible jusqu'au jour où quelqu'un la trouve.
• Les données sont réelles dès le premier utilisateur. Adresses e-mail, messages, paiements : une fuite peut engager votre responsabilité, même pour un MVP.
• Les corrections coûtent moins cher avant le lancement. Changer une règle d'accès sur dix lignes de données est simple ; le faire après des milliers d'inscriptions l'est beaucoup moins.

Pour la méthode de construction elle-même, voyez notre guide du vibe coding pour fondateurs et celui sur la création d'un MVP avec l'IA.

Les six contrôles avant la mise en ligne

1. Contrôler qui accède aux données

C'est le contrôle le plus important. Si votre application utilise Supabase, la documentation officielle est claire : il faut activer la sécurité au niveau des lignes (RLS) sur chaque table d'un schéma exposé. Sans elle, une table exposée est lisible et modifiable par tout rôle qui y a accès.

La documentation précise aussi que, une fois la RLS activée, aucune donnée n'est accessible via l'API avec une clé publique tant que vous n'avez pas créé de règles (« policies »). C'est le comportement voulu : on ferme tout, puis on ouvre ce qui est nécessaire. Elle signale enfin que les vues contournent la RLS par défaut, parce qu'elles sont généralement créées avec l'utilisateur principal de la base : une vue construite sur une table protégée peut donc exposer des lignes que les règles devaient cacher.

Le test à faire sans coder. Créez deux comptes de test. Avec le premier, enregistrez une donnée (une commande, un message). Connectez-vous avec le second et essayez de la voir, la modifier, la supprimer. Essayez ensuite sans être connecté. Si l'un de ces essais réussit, la règle d'accès est incorrecte ou absente. Demandez à votre assistant IA d'afficher les règles actives table par table, et relisez-les.

2. Garder les clés secrètes hors du navigateur

Tout ce qui est envoyé au navigateur est lisible par n'importe quel visiteur. Pour les applications Next.js, la documentation indique que les variables dont le nom commence par `NEXT_PUBLIC_` sont intégrées au code envoyé au navigateur au moment de la construction, tandis que les autres restent côté serveur. Une clé secrète ne doit donc jamais porter ce préfixe.

La documentation Supabase est aussi nette pour la clé « service_role » : elle contourne la RLS, donc elle doit rester côté serveur, et il ne faut jamais utiliser une clé secrète dans le navigateur ni l'exposer à ses clients.

Trois vérifications simples :

• Ouvrez votre site, affichez le code source des fichiers chargés par la page, et cherchez le début de vos clés. Aucune clé secrète ne doit apparaître.
• Vérifiez que le fichier qui contient vos secrets (souvent nommé `.env`) n'est pas publié avec le code. La documentation Next.js rappelle qu'on ne doit presque jamais le versionner.
• Si une clé secrète a été publiée une seule fois, considérez-la comme compromise : remplacez-la, ne vous contentez pas de la masquer.

3. Séparer les droits des utilisateurs

Deux catégories du Top 10 OWASP 2025 concernent directement vos écrans de connexion : le contrôle d'accès défaillant et les défaillances d'authentification. L'idée est simple : être connecté ne donne pas le droit de tout faire.

Posez-vous trois questions. Existe-t-il une page ou une action réservée aux administrateurs ? Est-elle protégée par une vérification côté serveur, et pas seulement cachée dans l'interface ? Un utilisateur ordinaire qui connaît l'adresse de cette page peut-il y accéder ? Cacher un bouton n'est pas une protection : c'est le serveur qui doit refuser la demande.

4. Limiter et surveiller les dépendances

Une application moderne s'appuie sur des dizaines de bibliothèques écrites par d'autres. L'édition 2025 du Top 10 OWASP consacre une catégorie aux défaillances de la chaîne d'approvisionnement logicielle. Pour un MVP, trois réflexes suffisent :

• Demandez à votre assistant la liste des bibliothèques ajoutées et leur raison d'être. Supprimez celles qui n'ont plus d'usage.
• Méfiez-vous d'un paquet au nom proche d'un paquet connu : une faute de frappe peut installer autre chose que ce que vous pensiez.
• Mettez les bibliothèques à jour avant le lancement, puis à intervalles réguliers, en testant l'application après chaque mise à jour.

5. Soigner la configuration et les messages d'erreur

La mauvaise configuration est la deuxième catégorie du Top 10 OWASP 2025, et la mauvaise gestion des situations exceptionnelles en est la dixième. En pratique : un visiteur qui provoque une erreur ne doit pas voir de détails techniques (chemins de fichiers, requêtes, noms de tables). Provoquez volontairement une erreur (une adresse inexistante, un formulaire vide, un mauvais mot de passe) et lisez ce qui s'affiche. Les messages doivent rester neutres : « une erreur est survenue », pas une trace technique.

Vérifiez aussi que l'environnement de test n'est pas accessible au public avec des données réelles, et que les comptes de démonstration créés pendant la construction sont supprimés.

6. Garder des traces et des sauvegardes

Le Top 10 OWASP 2025 compte aussi les défaillances de journalisation et d'alerte. Pour un MVP, l'objectif est modeste : savoir, après coup, qui a fait quoi et quand. Assurez-vous que les connexions et les actions sensibles (suppression, changement d'e-mail, export) laissent une trace conservée quelques semaines, et qu'une alerte vous prévient en cas d'erreur répétée.

Une sauvegarde ne vaut que si elle a été restaurée au moins une fois. Planifiez ce test avant la mise en ligne : restaurer sur un projet vide, vérifier que les données reviennent.

Check-list de mise en ligne

Si vous ne retenez qu'une page de ce guide, retenez celle-ci. Cochez chaque ligne avec une preuve (capture d'écran, résultat d'un test), pas avec un « je crois que ».

• Deux comptes de test ne peuvent pas voir ni modifier les données l'un de l'autre.
• Un visiteur non connecté ne peut rien lire qui soit privé.
• Aucune clé secrète n'est visible dans le navigateur ni dans le dépôt de code.
• Les pages et actions d'administration refusent un compte ordinaire, côté serveur.
• La liste des bibliothèques est connue et à jour.
• Une erreur provoquée n'affiche aucun détail technique.
• Une restauration de sauvegarde a été testée.

Les erreurs fréquentes

• Croire qu'un site « qui marche » est un site sûr. Le test de fonctionnement ne dit rien sur ce que les autres utilisateurs peuvent voir.
• Activer la protection et ne rien tester. Une règle mal écrite peut tout ouvrir ou tout bloquer ; seuls les essais avec deux comptes le montrent.
• Mettre une clé secrète dans le code envoyé au navigateur pour « faire marcher plus vite ».
• Cacher au lieu de refuser. Retirer un bouton de l'interface ne remplace pas une vérification côté serveur.
• Laisser des comptes et des données de test en production après le lancement.
• Demander à l'IA « sécurise mon application » sans critère. Donnez-lui la liste des six contrôles et demandez-lui la preuve de chacun.

Quand demander un regard extérieur

Ce guide couvre les erreurs courantes d'un premier produit. Faites relire votre application par un professionnel de la sécurité ou un développeur expérimenté si vous stockez des données sensibles (santé, finances, mineurs), si vous prenez des paiements, ou si vous visez des clients qui vous demanderont des garanties écrites. Arrivez avec la check-list remplie et les preuves : la discussion sera plus courte et moins chère.

Questions fréquentes

Faut-il connaître la programmation pour faire ces contrôles ?

Non pour la plupart. Les tests avec deux comptes, la recherche de clés dans le navigateur et la lecture des messages d'erreur ne demandent aucune compétence technique. Pour modifier les règles d'accès, vous pouvez demander à votre assistant IA, en lui fournissant le résultat attendu et en vérifiant ensuite par vos propres tests.

L'IA peut-elle sécuriser mon application à ma place ?

Elle peut aider à écrire les règles et à lister les bibliothèques, mais elle ne remplace pas votre vérification. Demandez-lui des preuves vérifiables (quelles règles sont actives, quelle clé est utilisée où), puis contrôlez par des essais.

Ces contrôles suffisent-ils pour un produit avec des paiements ?

Non. Ils réduisent les erreurs courantes, mais un produit qui traite des paiements ou des données sensibles demande un regard professionnel et le respect des règles propres à votre secteur.

Que faire si je découvre une clé secrète publiée ?

Remplacez-la tout de suite chez le fournisseur, mettez à jour votre application avec la nouvelle clé, puis vérifiez dans les journaux du fournisseur si la clé a été utilisée par quelqu'un d'autre.

Conclusion

Une application créée avec l'IA peut très bien être solide, à condition de ne pas confondre « ça marche » et « c'est protégé ». Six contrôles, une check-list avec preuves et une semaine suffisent à écarter les erreurs les plus courantes avant de présenter votre produit à de vrais utilisateurs.

Si votre application n'est pas encore construite, la sécurité fait partie de la méthode dès le premier jour. C'est ce que nous travaillons avec les entrepreneurs pendant la création de leur première version testable.

Mettre en ligne vite est un avantage ; mettre en ligne sans avoir testé qui voit quoi est un pari que vous n'avez pas à faire.

Sources

• Supabase, Row Level Security, documentation consultée le 29 octobre 2026.
• Next.js, Environment Variables, documentation consultée le 29 octobre 2026.
• OWASP, Top 10:2025, consulté le 29 octobre 2026.