Une application générée par IA est fonctionnelle avant d'être sûre. Quatre points concentrent l'essentiel du risque : l'authentification, les règles d'accès aux données, la protection des clés d'API et la gestion des sauvegardes. Ces vérifications prennent quelques heures et doivent être faites avant l'ouverture au public, pas après le premier incident.
Pourquoi le risque est spécifique ici
Un modèle génère du code plausible. Il produit volontiers une interface qui n'affiche que vos données, sans que le serveur empêche réellement quelqu'un d'accéder à celles des autres. Le filtre est alors cosmétique : invisible à l'usage, exploitable en quelques minutes par une personne curieuse.
Contrôle côté client désigne une restriction appliquée dans le navigateur, contournable par l'utilisateur.
Contrôle côté serveur désigne une restriction appliquée par la base de données ou le serveur, non contournable depuis le navigateur.
Seul le second protège réellement.
La checklist en 8 points
1. Authentification en place. Inscription, connexion, déconnexion, réinitialisation de mot de passe fonctionnelles. Vérifiez qu'aucune page sensible n'est accessible sans session valide.
2. Règles d'accès au niveau de la base. Chaque table contenant des données utilisateur doit imposer, côté serveur, que l'on ne lit et n'écrit que ses propres lignes. Testez avec deux comptes distincts.
3. Aucune clé secrète dans le navigateur. Les clés d'API privées, jetons de service et identifiants de fournisseurs restent côté serveur. Une clé publique est prévue pour être exposée ; une clé secrète ne l'est jamais.
4. Validation des données reçues. Ne faites pas confiance au formulaire : contrôlez les types, longueurs et valeurs autorisées côté serveur.
5. Rôles et privilèges séparés. Les droits d'administration ne se déduisent pas d'une valeur stockée dans le navigateur. Ils se vérifient côté serveur, dans une table dédiée.
6. Paiements délégués. Passez par un prestataire de paiement reconnu ; ne stockez jamais de données de carte bancaire vous-même.
7. Sauvegardes et restauration testées. Une sauvegarde jamais restaurée n'est pas une sauvegarde. Faites l'essai une fois.
8. Journalisation et alertes. Conservez une trace des erreurs et des accès sensibles, avec une alerte sur les anomalies.
Méthode de vérification en 4 étapes
1. Créer deux comptes de test. Objectif : simuler deux clients. Action : saisir des données dans chacun. Résultat attendu : aucun croisement visible.
2. Tenter l'accès direct. Objectif : contourner l'interface. Action : depuis le compte A, tenter d'ouvrir une ressource appartenant au compte B en modifiant l'identifiant dans l'adresse. Résultat attendu : refus. Erreur fréquente : se contenter de constater que le lien n'apparaît pas à l'écran.
3. Inspecter ce qui part du navigateur. Objectif : repérer les secrets exposés. Action : parcourir les requêtes réseau et le code chargé. Résultat attendu : aucune clé privée visible.
4. Simuler la perte de données. Objectif : valider la reprise. Action : restaurer une sauvegarde sur un environnement de test. Résultat attendu : une procédure connue et documentée.
Tableau des risques et priorités
| Risque | Conséquence possible | Difficulté de correction | Priorité |
|---|---|---|---|
| Absence de règles d'accès côté serveur | Fuite de données entre utilisateurs | Faible si traité tôt | Critique |
| Clé secrète exposée dans le navigateur | Usage frauduleux, facturation détournée | Faible | Critique |
| Rôle administrateur vérifié côté client | Élévation de privilèges | Moyenne | Critique |
| Validation d'entrée absente | Données corrompues, comportements imprévus | Faible | Élevée |
| Absence de sauvegarde testée | Perte définitive de données | Faible | Élevée |
| Journalisation absente | Incident non détecté, analyse impossible | Faible | Moyenne |
Deux exemples (hypothétiques)
Exemple hypothétique 1 — un portail client. L'interface filtre correctement les dossiers par utilisateur, mais la base ne le fait pas. Un client averti modifie un identifiant dans l'adresse et consulte le dossier d'un autre. Correction : activer les règles d'accès au niveau de la base et retester avec deux comptes.
Exemple hypothétique 2 — une application appelant un modèle d'IA. La clé d'API est incluse dans le code envoyé au navigateur pour simplifier. Elle peut être extraite et utilisée par un tiers, aux frais du propriétaire. Correction : déplacer l'appel côté serveur et révoquer la clé exposée.
Erreurs fréquentes
Croire qu'une page cachée est une page protégée. Correction : protéger la donnée, pas le lien.
Repousser la sécurité à la fin. Fréquent car elle ne se voit pas. Conséquence : reprise coûteuse. Correction : la traiter dès la création des tables.
Réutiliser une clé exposée après l'avoir « retirée » du code. Une clé publiée est compromise. Correction : la révoquer et en générer une nouvelle.
Donner à tous les utilisateurs les mêmes droits par facilité. Correction : définir au minimum utilisateur et administrateur, vérifiés côté serveur.
Questions fréquentes
Une application créée avec l'IA est-elle moins sûre ?
Pas intrinsèquement : le code généré suit souvent de bonnes pratiques. Le risque vient de l'absence de relecture par une personne capable de repérer une protection manquante. La sécurité dépend donc du processus de vérification, pas de l'origine du code.
Qu'est-ce qu'une règle d'accès au niveau de la base ?
C'est une condition appliquée par la base de données elle-même à chaque requête, qui détermine quelles lignes un utilisateur donné peut lire ou modifier. Contrairement à un filtre écrit dans l'interface, elle s'applique même si la requête est envoyée directement, sans passer par votre application.
Comment savoir si une clé peut être exposée ?
Référez-vous à la documentation du fournisseur : les clés dites publiques, publishable ou anon sont conçues pour être visibles côté navigateur. Toute clé qualifiée de secrète, privée ou service doit rester côté serveur. En cas de doute, considérez la clé comme secrète.
Faut-il faire auditer son application ?
Pour une application interne à faible enjeu, une vérification méthodique suffit souvent. Dès qu'il y a des données personnelles de clients, des paiements ou une exposition publique significative, une relecture par une personne expérimentée en sécurité est un investissement raisonnable avant l'ouverture.
Que faire en cas de fuite de données ?
Coupez l'accès concerné, révoquez les identifiants compromis, mesurez l'étendue à partir des journaux, puis corrigez la cause. Si des données personnelles sont concernées, le règlement européen impose des obligations de notification à l'autorité compétente dans des délais courts : vérifiez les exigences applicables auprès de la CNIL.
Les mots de passe doivent-ils être gérés par mon application ?
Il est préférable de s'appuyer sur un service d'authentification établi plutôt que d'implémenter soi-même le stockage des mots de passe. Ces services gèrent le chiffrement, les tentatives répétées, la réinitialisation et la connexion par fournisseur externe, autant de points où une implémentation maison échoue souvent.
À quelle fréquence sauvegarder ?
Cela dépend de la quantité de données que vous acceptez de perdre. Pour une application métier active, une sauvegarde quotidienne constitue un minimum courant, complétée par un test de restauration périodique. Documentez la procédure : en situation d'incident, personne n'improvise correctement.
Conclusion
Avant d'ouvrir votre application, vérifiez d'abord les règles d'accès côté base et l'absence de clés secrètes dans le navigateur : ces deux points couvrent la majorité des incidents évitables. Prochaine action : créer deux comptes de test et tenter d'accéder aux données de l'un depuis l'autre.
Ces vérifications sont intégrées au programme de la formation vibe coding en ligne.