Checklist sécurité pour une application créée avec l'IA

Des outils d'IA comme Lovable, Bolt ou Cursor peuvent construire une application qui fonctionne en quelques jours. Ils sont bons pour les écrans et le parcours principal. La sécurité est la partie la plus facile à oublier, parce que rien ne paraît anormal pendant une démo. Vous êtes le seul utilisateur, et vous n'essayez jamais de casser votre propre application. Cette checklist s'adresse aux fondateurs qui ne sont pas techniques. Pour chaque point, elle dit quoi vérifier, comment le vérifier et à quoi ressemble une bonne réponse. Parcourez-la avant d'inviter des personnes que vous ne connaissez pas.

Comment utiliser cette checklist

Suivez les parties dans l'ordre. La première est la plus importante, car une erreur à cet endroit peut exposer tous vos utilisateurs d'un coup. Pour chaque point, notez une des trois réponses : oui, non, ou je ne sais pas. Comptez « je ne sais pas » comme un non.

Avant de commencer, il vous faut : deux comptes de test avec deux adresses e-mail différentes, deux navigateurs (ou une fenêtre normale et une fenêtre de navigation privée), un téléphone, et l'accès à tous les tableaux de bord de votre application : hébergement, base de données, paiements et e-mails.

Cette liste ne porte que sur la sécurité. Pour la question plus large de savoir si votre application est prête pour le public, lisez ce qui doit être vrai avant de lancer auprès de vrais utilisateurs.

Accès aux données et clés secrètes

Dans beaucoup d'applications créées avec l'IA, le code qui tourne dans le navigateur parle directement à la base de données. Les règles de la base (celles qui disent qui peut lire ou modifier chaque ligne de données) sont alors le seul vrai verrou sur les données de vos utilisateurs.

• Faites le test des deux comptes. Connectez-vous avec le compte A et créez un élément. Copiez l'adresse de sa page. Ouvrez cette adresse en étant connecté avec le compte B. Puis changez d'un caractère le numéro ou le code dans l'adresse, et réessayez. Bonne réponse : B voit une erreur, ou rien du tout.
• Chaque table a ses règles. Si votre application utilise Supabase, chaque table doit avoir la sécurité au niveau des lignes (row level security) activée, avec des règles qui limitent chaque utilisateur à ses propres lignes. Nous expliquons comment le vérifier dans le tableau de bord, étape par étape, dans votre base Supabase est-elle ouverte.
• Aucune clé secrète dans le navigateur. Votre application utilise des clés pour parler aux services de paiement, d'e-mail et d'IA. Certaines clés sont faites pour être publiques. Les clés secrètes, non. Demandez à la personne qui construit l'app, ou à votre outil d'IA, la liste de toutes les clés et l'endroit où chacune est stockée. Bonne réponse : les clés secrètes restent sur le serveur, dans les réglages de l'hébergement, jamais dans le code qui tourne dans le navigateur.
• Le code n'est pas public par erreur. Si votre code est stocké sur GitHub, vérifiez que le dépôt est privé. Des clés enregistrées dans un dépôt public peuvent être trouvées et copiées.
• Les pages d'administration sont protégées sur le serveur. Cacher le bouton admin ne protège rien. Connectez-vous comme un utilisateur normal et tapez l'adresse d'une page d'administration. Bonne réponse : l'accès vous est refusé.

Connexion et mot de passe oublié

La connexion est la porte d'entrée de votre application. Le mot de passe oublié est la porte de derrière, et on la teste beaucoup moins.

• Un lien de réinitialisation sert une fois et expire. Demandez une réinitialisation, utilisez le lien, puis ouvrez de nouveau le même lien. Bonne réponse : le deuxième essai échoue.
• La page « mot de passe oublié » ne révèle pas qui a un compte. Tapez un e-mail qui a un compte, puis un e-mail qui n'en a pas. Le message doit être le même. Sinon, n'importe qui peut tester quels e-mails appartiennent à vos utilisateurs.
• L'e-mail est confirmé avant toute action importante. Un nouveau compte ne doit pas accéder aux fonctions privées, ni envoyer de messages à d'autres, tant que son adresse e-mail n'est pas confirmée.
• Se déconnecter déconnecte vraiment. Déconnectez-vous, puis appuyez sur le bouton retour, ou ouvrez l'adresse d'une page enregistrée. Bonne réponse : l'application vous demande de vous reconnecter.

Paiements et envoi de fichiers

L'argent et les fichiers sont les endroits où une petite erreur devient vite coûteuse.

• Le prix est fixé sur le serveur. Si c'est le navigateur qui indique au service de paiement combien facturer, un utilisateur peut modifier le montant. Demandez où le prix est décidé. Bonne réponse : dans votre service de paiement ou sur le serveur.
• L'accès est donné après confirmation du paiement. Arriver sur la page « merci » ne prouve pas que le client a payé. Le service de paiement envoie un message à votre serveur (on appelle cela un webhook), et l'application doit agir uniquement sur ce message. Testez-le : ouvrez directement l'adresse de la page de confirmation, sans payer. Rien ne doit se débloquer.
• Les envois de fichiers ont des limites. N'acceptez que les types de fichiers dont vous avez besoin, par exemple des images et des PDF, et fixez une taille maximale.
• Les fichiers privés restent privés. Factures, contrats et pièces d'identité ne doivent pas se trouver dans un dossier public. Copiez le lien d'un fichier envoyé et ouvrez-le dans une fenêtre privée, sans être connecté. Bonne réponse : il ne s'ouvre pas.

Une démo doit seulement marcher pour vous. Un produit doit tenir face à des gens que vous ne rencontrerez jamais.

Des limites contre les abus

Tous les visiteurs ne sont pas des utilisateurs. Certains sont des programmes automatiques (des robots) qui essaient des milliers de mots de passe, créent de faux comptes, envoient du spam par vos formulaires, ou appellent votre fonction d'IA encore et encore, à vos frais.

• Les tentatives de connexion sont limitées. Après quelques mauvais mots de passe, l'application doit ralentir ou bloquer un moment les nouveaux essais.
• Les formulaires sont protégés. Les formulaires d'inscription, de contact et d'invitation ont besoin d'une limite par adresse, et souvent d'une vérification que le visiteur est une personne.
• Les fonctions payantes ont un plafond. Les réponses d'IA, les SMS et les e-mails coûtent de l'argent à chaque envoi. Fixez une limite par utilisateur et par jour. Quand le fournisseur le permet, fixez aussi une limite de dépense ou une alerte.

Sauvegardes, erreurs et journaux

• Les sauvegardes se font seules, et une restauration a été testée. Sachez jusqu'à quelle date vous pouvez revenir, et qui sait restaurer.
• Le suivi des erreurs est actif. Un outil de suivi des erreurs enregistre chaque panne et vous prévient. Vérifiez que les alertes arrivent chez une personne qui les lit.
• Les erreurs montrées aux utilisateurs restent simples. Un utilisateur doit voir « une erreur s'est produite », pas des noms de tables ou des morceaux de code. Ces détails aident un attaquant.
• Les journaux ne contiennent pas de secrets. Les mots de passe, les numéros de carte et les liens de réinitialisation ne doivent jamais être écrits dans les journaux (les fichiers où l'application note ce qu'elle fait).

À qui appartiennent les comptes

La meilleure sécurité ne sert à rien si vous ne pouvez pas entrer dans vos propres comptes, ou si une personne partie peut encore y entrer.

• Chaque compte est à votre nom. Nom de domaine, hébergement, base de données, code, paiements, envoi d'e-mails et l'outil d'IA lui-même, tous avec une adresse e-mail de votre entreprise que vous contrôlez.
• La double authentification est activée. Un code reçu sur votre téléphone en plus du mot de passe, pour chacun de ces comptes.
• Aucun mot de passe partagé. Chaque personne qui vous aide a son propre accès, et vous le retirez quand elle arrête.
• Une seule liste de l'endroit où tout se trouve. Gardez une note courte de chaque service, de qui y a accès et de l'endroit où sont les clés, dans un lieu sûr.

Que faire de vos réponses

Commencez par les données et les clés. Si une de ces deux parties contient un non, corrigez-le avant d'inviter qui que ce soit, même si votre lancement prend une semaine de retard. Les autres parties peuvent souvent être corrigées pendant un test avec un petit groupe.

Ce n'est pas un défaut des outils d'IA en eux-mêmes. Ils construisent ce que vous demandez, et la plupart des demandes portent sur des fonctions, pas sur des verrous. Vous pouvez demander à votre outil d'IA de vérifier chaque point de cette liste, et il vous aidera souvent. Mais certains points, comme les règles de la base de données et le code du serveur, ne se voient pas à l'écran. Une personne qui n'a pas écrit le code trouve ce que son auteur n'a pas vu. Nous expliquons d'où viennent ces failles dans pourquoi un prototype IA casse avec de vrais utilisateurs.

Pour savoir rapidement où vous en êtes, notre test de lancement gratuit en 2 minutes pose des questions simples et montre les points encore ouverts. Et si plusieurs réponses sont des non, voyez comment nous finissons et sécurisons les applications créées avec l'IA, en commençant par un audit du code et des données.