Sécuriser une application créée avec l'IA : connexion, rôles, sauvegardes
Sécuriser une application créée avec l'IA : clés secrètes, connexion, rôles, liens clients, sauvegardes, avec la demande à Claude et le test à l'écran.
L'essentiel
Une application créée avec l'IA est sûre quand six points ont été vérifiés : les clés secrètes restent sur le serveur, chaque page exige la connexion, chaque rôle ne voit que ce qu'il doit voir, les liens clients sont impossibles à deviner, les envois en rafale sont bloqués, et une sauvegarde a déjà été restaurée. Pour chaque point, une demande à Claude Code et un test à l'écran suffisent.
Sommaire
- Quelles failles trouve-t-on dans une application faite vite avec l'IA ?
- Comment garder les clés secrètes hors du navigateur ?
- Comment vérifier que chaque page exige la connexion ?
- Comment limiter chaque rôle à ce qu'il doit voir ?
- Comment protéger les liens clients et les formulaires publics ?
- Comment savoir si vos sauvegardes fonctionnent ?
- Comment demander à Claude de chercher les failles lui-même ?
- Quelles sont les limites de ces vérifications ?
- Questions fréquentes
- Par où commencer
Pour sécuriser une application créée avec l'IA, vérifiez six points avant d'en ouvrir l'accès : les clés secrètes, la connexion, les rôles, les liens clients, les envois en rafale et les sauvegardes. Claude Code règle chacun de ces points quand vous le lui demandez, et un test à l'écran le confirme.
Cet article s'adresse à qui a construit un outil avec Claude Code sans savoir programmer. Pour chaque point, vous aurez la phrase à dire à Claude et le test à faire vous-même.
Quelles failles trouve-t-on dans une application faite vite avec l'IA ?
Une faille est un passage laissé ouvert par erreur, par lequel quelqu'un voit ou modifie ce qui ne le concerne pas. Claude Code construit ce que vous décrivez, et les règles que vous n'avez pas formulées peuvent manquer. Trois failles reviennent souvent : une clé secrète envoyée au navigateur, une page accessible sans connexion, des droits trop larges.
Pendant la construction du CRM de Rugstar, une clé secrète est partie sur GitHub. C'est l'un des douze pièges racontés dans la formation, avec leur règle.
| Point à vérifier | La faille typique | Le test à l'écran |
|---|---|---|
| Clés secrètes | Une clé lisible dans le navigateur | Claude liste chaque clé et sa place |
| Connexion | Une page qui s'ouvre sans connexion | Chaque adresse ouverte en navigation privée |
| Rôles | Des droits trop larges | Un compte en lecture seule tente d'enregistrer |
| Liens clients | Un lien du type /suivi/42, facile à deviner | Un caractère changé mène à une page introuvable |
| Envois en rafale | Des mots de passe essayés à la chaîne | Six mots de passe faux bloquent la connexion |
| Sauvegardes | Une copie jamais restaurée | La sauvegarde de la nuit restaurée dans la base d'essai |
Comment garder les clés secrètes hors du navigateur ?
Une clé secrète est un long code qui ouvre un service à votre nom, comme un mot de passe : la base de données, l'envoi d'e-mails, les paiements. Elle reste sur le serveur, l'ordinateur de Vercel qui fait tourner l'application. Tout ce que reçoit le navigateur, Chrome ou Safari, peut être lu par la personne qui s'en sert.
Next.js, la technique utilisée par Claude, suit une règle simple. Une variable dont le nom commence par NEXT_PUBLIC_ est recopiée dans le code envoyé au navigateur, et les autres restent sur le serveur. Une clé secrète ne porte donc jamais ce préfixe.
Sur votre ordinateur, les clés vivent dans le fichier .env.local, que le projet exclut de GitHub. En ligne, elles sont rangées dans les variables d'environnement de Vercel, des réglages gardés à part du code, comme le montre l'article sur la mise en ligne avec GitHub, Vercel et Turso.
Fais un tableau de toutes les clés secrètes du projet : le service que chacune ouvre, l'endroit où elle est rangée, et si elle peut arriver dans le navigateur. Aucune clé ne doit être écrite dans le code ni envoyée au navigateur. Corrige ce qui ne va pas, puis dis-moi quelles clés changer chez leur service.
Le test : dans le tableau rendu par Claude, chaque clé est rangée dans .env.local et dans Vercel. Une clé déjà passée sur GitHub se change chez le service qui l'a délivrée, parce que GitHub garde chaque version passée du code.
Comment vérifier que chaque page exige la connexion ?
La connexion classique se fait par e-mail et mot de passe haché, c'est-à-dire transformé en code illisible avant d'être enregistré. Une autre formule évite les mots de passe oubliés : la connexion par lien envoyé par e-mail, un lien valable peu de temps et utilisable une seule fois.
Derrière chaque écran, une API reçoit les informations, par exemple la fiche à enregistrer. Une API doit répondre « non autorisé » à un visiteur non connecté. Quand elle le renvoie vers la page de connexion, l'écran croit à un succès et affiche « Enregistré » sans rien enregistrer. Ce faux « Enregistré » fait partie des douze pièges de la formation. Un journal des connexions montre enfin chaque tentative.
Toutes les pages de l'outil exigent la connexion, sauf la page de connexion et les pages de suivi client. Toute adresse d'API répond « non autorisé » à un visiteur non connecté. Ajoute un journal des connexions, visible par l'administrateur seulement : date et heure, adresse e-mail, résultat, appareil. Donne-moi ensuite la liste de toutes les adresses de pages.
Le test : ouvrez une fenêtre de navigation privée, qui ne connaît aucune connexion en cours, et collez-y les adresses une par une. Chacune doit afficher la page de connexion. Tapez ensuite un mot de passe faux, puis ouvrez le journal : la tentative refusée doit y figurer.
Comment limiter chaque rôle à ce qu'il doit voir ?
Un rôle dit ce qu'une personne a le droit de voir et de faire. Sur le CRM de Rugstar, les comptes ont des rôles différents : fondateur, commercial, designer, et un administrateur. L'article sur les droits d'accès des employés aide à découper les vôtres.
Cacher un bouton protège peu, car une modification peut être envoyée directement à l'API : le serveur vérifie donc le rôle à chaque action. Pour le prouver, créez un compte d'essai en lecture seule.
Ajoute un rôle « Lecture seule » : la personne voit les contacts, les devis et les commandes, sans bouton pour créer, modifier ou supprimer. Le serveur refuse toute modification venant de ce rôle, même envoyée directement à l'API. Crée un compte d'essai avec ce rôle et montre-moi la réponse du serveur quand il tente d'enregistrer un devis.
Le test : connecté avec ce compte, vous ne voyez aucun bouton Enregistrer ou Supprimer, et la réponse montrée par Claude est un refus. La page Utilisateurs, tapée à la main, reste fermée.
Comment protéger les liens clients et les formulaires publics ?
Les pages faites pour vos clients s'ouvrent sans connexion et demandent deux protections de plus.
Des liens clients impossibles à deviner
Chez Rugstar, chaque client suit sa commande sur une page de suivi, sans compte. Une adresse comme /suivi/42 se devine en essayant 43. L'adresse contient donc un jeton, une longue suite de caractères tirée au hasard.
Les pages de suivi client utilisent un jeton long tiré au hasard à la place du numéro de commande, et montrent uniquement la commande de ce client. Ajoute sur la fiche commande un bouton « Changer le lien », qui rend l'ancien lien inutilisable.
Le test : en navigation privée, le lien client doit s'ouvrir sans connexion. L'inverse arrive aussi : une page publique qui renvoyait vers la connexion. Un seul caractère changé dans le lien mène à une page introuvable.
Des limites contre les envois en rafale
Un envoi en rafale désigne des demandes répétées en peu de temps, par un robot ou par un bug : des mots de passe essayés à la chaîne, un formulaire envoyé en boucle. Les e-mails comptent aussi : parmi les pièges de la formation figurent trop d'e-mails partis d'un coup depuis un domaine neuf.
Après cinq mots de passe faux en quinze minutes pour une même adresse, bloque la connexion quinze minutes avec un message clair. Le formulaire de demande de devis accepte trois envois par heure depuis un même appareil. Les e-mails automatiques s'arrêtent à un plafond par jour, réglable dans la page Réglages.
Les chiffres de cette demande sont des réglages à choisir vous-même. Le test : six mots de passe faux de suite font apparaître le message de blocage.
Comment savoir si vos sauvegardes fonctionnent ?
Une sauvegarde est une copie complète de la base de données, rangée ailleurs. Restaurer veut dire remettre cette copie en place. Tant qu'une sauvegarde n'a jamais été restaurée, on ignore si elle contient tout. Une commande « push force » peut vider des tables : seule une sauvegarde rend alors les données.
Ajoute une page « Sauvegardes », réservée à l'administrateur. Chaque nuit, une sauvegarde complète de la base réelle se range hors de la base. La page liste les sauvegardes avec leur date, leur taille et le nombre de fiches par table. Un bouton restaure une sauvegarde dans la base d'essai, jamais dans la base réelle.
Le test : restaurez la sauvegarde de la nuit dans la base d'essai, puis ouvrez l'application sur cette base. Les fiches de la veille doivent y être. Voyez aussi la sauvegarde de la base de données et les tests sans casser la version en ligne.
Comment demander à Claude de chercher les failles lui-même ?
La documentation d'Anthropic, consultée en septembre 2026, décrit trois moyens.
- La commande
/security-reviewrelit les modifications en cours pour y chercher des failles. - Le module security-guidance fait relire à Claude chaque modification qu'il écrit, et la fait corriger dans la même session.
- Pour le code déjà écrit, elle conseille de demander à Claude de relire un dossier ou un fichier précis.
Pour tout relire, ouvrez une nouvelle session, qui part de zéro, et choisissez le mode Plan : Claude explore le projet et propose, sans rien modifier.
Relis toute l'application comme un auditeur de sécurité, sans rien modifier : clés secrètes hors du navigateur, connexion exigée sur chaque page et chaque API, droits de chaque rôle contrôlés par le serveur, liens clients impossibles à deviner, limites contre les envois en rafale, sauvegardes. Pour chaque problème, donne le fichier, la gravité et le test à faire à l'écran, du plus grave au moins grave.
Corrigez ensuite un problème à la fois, avec un test à l'écran après chacun. Ces relectures lisent le code ; le site en ligne se vérifie par vos tests.
Quelles sont les limites de ces vérifications ?
- Selon la documentation d'Anthropic, la relecture par Claude peut manquer des problèmes.
- Une application qui garde des données sensibles, ou qui sert beaucoup de clients, mérite un regard professionnel : voyez l'audit d'une application codée par l'IA.
- Les dossiers patients demandent un hébergement de données de santé certifié. La comptabilité légale, la banque et la paie restent dans les logiciels prévus pour.
- La sécurité s'entretient : après chaque changement important, repassez la liste.
Questions fréquentes
Une application créée avec l'IA est-elle sûre ?
Une application créée avec l'IA est sûre quand six points ont été vérifiés : clés secrètes, connexion, rôles, liens clients, envois en rafale et sauvegardes. Claude Code règle chacun de ces points sur demande, et un test à l'écran confirme le résultat.
Claude Code peut-il vérifier lui-même la sécurité d'une application ?
Claude Code peut relire une application pour y chercher des failles, avec la commande /security-review ou une demande d'audit en mode Plan. Ces relectures peuvent manquer des problèmes, selon la documentation d'Anthropic, et les tests à l'écran restent donc à faire.
Où ranger les clés secrètes d'une application créée avec Claude Code ?
Les clés secrètes d'une application créée avec Claude Code se rangent dans le fichier .env.local, exclu de GitHub, et dans les variables d'environnement de Vercel. Avec Next.js, une clé secrète ne porte jamais le préfixe NEXT_PUBLIC_, qui la recopierait dans le code envoyé au navigateur.
Faut-il faire auditer une application créée avec l'IA par un professionnel ?
Faire auditer une application créée avec l'IA par un professionnel se justifie quand elle garde des données sensibles ou qu'elle sert beaucoup de clients. Pour un outil interne, la liste de cet article et une relecture par Claude couvrent les failles décrites ici.
Par où commencer
Commencez par un test rapide : collez l'adresse de chaque page de votre outil dans une fenêtre de navigation privée, et notez celles qui s'affichent sans connexion. Dans la semaine, lancez la demande d'audit en mode Plan, corrigez les clés secrètes et la connexion, créez le compte en lecture seule, puis restaurez une sauvegarde dans la base d'essai.
Pour installer Claude Code, suivez les deux leçons gratuites. Le tronc commun de la formation consacre ensuite une partie à la sécurité et à la fiabilité.
Apprenez à construire vos propres outils
Korbolia est une formation vidéo qui vous apprend à créer vos logiciels avec Claude Code, sans écrire de code : un tronc commun, puis les spécialités qui servent votre métier. Les deux premières leçons sont gratuites.
Victor vous guide dans Korbolia, le cours pour construire soi-même ses outils avec Claude Code, sans savoir programmer.
Korbolia est une formation indépendante. Elle n'est ni affiliée à Anthropic ni approuvée par Anthropic. Claude et Claude Code sont des marques d'Anthropic. Les autres marques citées appartiennent à leurs propriétaires, et Korbolia n'est lié à aucune d'elles.