Une application générée par IA peut fonctionner assez bien pour être ouverte à de vrais utilisateurs alors que certaines règles ne sont garanties que par l’interface. C’est là que le risque commence.

Ces failles ne sont pas propres à Lovable, Bolt ou Claude Code. On les retrouve aussi dans du code écrit à la main. La différence tient au rythme : le prototype grandit vite, plusieurs choix sont ajoutés sans vue d’ensemble, puis une réponse convaincante de l’IA est confondue avec une vérification.

Lors d’une reprise, je retrouve souvent les signaux suivants.

1. Le bouton est caché, mais l’action reste accessible

L’interface n’affiche pas le bouton « Supprimer » à un utilisateur standard. Pourtant, la route appelée par ce bouton ne vérifie pas toujours le rôle côté serveur.

Une personne qui connaît l’URL ou modifie la requête peut alors déclencher l’action. La même erreur permet parfois de consulter un écran d’administration en entrant directement son adresse.

Testez chaque action interdite et vérifiez que le serveur la refuse, au lieu de vous fier à ce que l’interface affiche pour chaque rôle.

2. Changer un identifiant donne accès aux données d’un autre client

Le parcours affiche une URL comme /dossiers/123. L’application vérifie que l’utilisateur est connecté, récupère le dossier 123, puis le renvoie.

Il manque une condition : ce dossier appartient-il à l’organisation de la personne connectée ?

Dans une app multi-tenant, cette erreur est particulièrement sérieuse. Le design peut être impeccable et l’authentification fonctionner, mais l’isolation des données reste absente. L’OWASP décrit ce défaut comme une référence directe non sécurisée : chaque accès à un objet doit vérifier l’autorisation côté serveur, même si son identifiant est difficile à deviner.

Les permissions font partie des douze points d’un audit de prototype IA précisément parce qu’elles doivent être testées sur chaque ressource critique.

3. Une clé secrète a été placée dans le navigateur ou dans Git

Les prototypes connectent vite une API d’email, de paiement ou d’IA. Une clé peut finir dans un fichier copié depuis un exemple, une variable exposée au navigateur ou un ancien commit.

Supprimer la ligne dans le dernier commit ne suffit pas toujours. Git conserve l’historique. GitHub recommande de révoquer ou de faire tourner le secret en premier, avant d’envisager un nettoyage de l’historique : la procédure officielle détaille les étapes et leurs effets de bord.

Une clé déjà partagée dans une conversation, un dépôt public, une capture ou un fichier envoyé à plusieurs personnes doit être considérée comme compromise.

4. Le paiement dépend de la page de confirmation

Le client paie, le prestataire le renvoie vers /merci, puis cette page marque la commande comme réglée.

Ce parcours paraît logique, mais le client peut fermer l’onglet avant le retour. À l’inverse, une personne peut tenter d’ouvrir directement la page de confirmation. L’état du paiement doit être confirmé côté serveur à partir d’une source fiable, avec une gestion des événements reçus en retard ou plusieurs fois.

Le symptôme visible est souvent une différence entre le tableau du prestataire de paiement et la base de l’application.

La documentation Stripe sur les webhooks précise qu’un même événement peut être reçu plusieurs fois. Elle recommande de conserver les identifiants déjà traités afin d’écarter les doublons.

5. Une erreur laisse le produit dans un état intermédiaire

Une inscription crée le compte, réserve une ressource et envoie un email. Si la troisième étape échoue, que reste-t-il ?

Dans beaucoup de prototypes, l’erreur est affichée mais les deux premières actions ne sont ni annulées ni rendues reprenables. L’utilisateur recommence et crée un doublon. L’équipe corrige ensuite le doublon à la main, sans traiter la cause.

Quand plusieurs actions dépendent les unes des autres, l’application doit savoir lesquelles ont réussi et comment reprendre proprement.

6. Les erreurs sont invisibles hors de l’écran de l’utilisateur

Un écran blanc apparaît, mais aucun événement n’est envoyé. Un email n’arrive pas, mais rien ne signale l’échec. Une tâche s’arrête la nuit et personne ne le découvre avant le message d’un client.

Sans journaux exploitables ni alerte sur les parcours critiques, le support travaille à l’aveugle. Quelques journaux bien choisis suffisent s’ils enregistrent les erreurs avec le contexte utile, sans y copier des secrets ou des données personnelles inutiles.

La CNIL rappelle que la journalisation aide à détecter les accès non autorisés et les incidents. Elle doit elle-même être encadrée, car un journal peut devenir une nouvelle base sensible.

7. La sauvegarde existe, mais personne ne l’a restaurée

Une base managée annonce des sauvegardes automatiques. C’est utile, mais trois questions restent ouvertes : quelle période est couverte, qui peut lancer une restauration et combien de temps faut-il pour retrouver un service exploitable ?

Une sauvegarde non testée est une promesse du fournisseur, pas encore une procédure de reprise pour votre produit.

La vérification peut rester simple : restaurer une copie dans un environnement isolé, contrôler quelques données et noter les étapes. Le but est de découvrir la procédure avant l’incident.

Quand les corrections commencent à se contredire

Une faille isolée peut être corrigée. Le risque augmente quand chaque correction révèle une règle différente selon les pages : rôle admin ici, owner ailleurs, organisation lue depuis l’URL sur une route et depuis la session sur une autre.

À ce stade, une demande comme « sécurise cette page » ajoute souvent une couche sans remettre le modèle d’accès à plat. Cartographiez les règles avant de poursuivre.

Quand vous pouvez continuer sans audit

Si l’application reste une démo sans vrais comptes, paiements ou données personnelles, continuez à apprendre avec elle. Corrigez les problèmes visibles, gardez le dépôt privé et évitez d’y placer des secrets.

En revanche, avant un premier client, utilisez les vérifications de l’article sur le passage d’un prototype Lovable en production. Une faille supposée sur les données ou les paiements mérite d’être vérifiée avant d’ajouter de nouvelles fonctions.

Un audit ne promet pas qu’aucun incident n’arrivera. Il sert à rendre les principaux risques visibles et à décider lesquels traiter avant le lancement.

Si l’un de ces signaux touche déjà de vrais utilisateurs, réservez un échange de 30 minutes avec TechSprint. Nous commencerons par qualifier le risque, sans présumer qu’il faut tout refaire.

Fabrice Payet — fondateur de TechSprint, La Réunion.