Données clients accessibles : le test en deux minutes sur une application créée par IA

Votre application affiche un écran de connexion, donc vos données clients sont gardées. Les prestataires qui réparent ces applications décrivent l'inverse, sur trois échantillons différents. Trois vérifications que vous pouvez faire vous-même ce soir, et trois questions à poser à celui qui construit.

Un prestataire qui répare des applications no-code écrit sur Reddit (r/lovable, juillet 2026) qu'environ un tiers de celles qu'il a relues laissent leurs données clients accessibles à n'importe quel visiteur, et qu'il lui faut deux minutes pour le constater. Votre application créée par IA affiche un écran de connexion ; cela ne dit rien de ce que garde la base.

Ce que voient ceux qui réparent ces applications

Deux prestataires qui vivent de la réparation d'applications no-code décrivent la même panne. Le premier dit en avoir sauvé plus de trente en un an (r/nocode, juin 2026) et n'en avoir trouvé aucune qui protège tous ses types de données : il en reste toujours un, laissé ouvert pendant la construction et jamais refermé. Le second, qui relit des applications Lovable, en compte environ un tiers dont la base répond à qui la sollicite (r/lovable, juillet 2026). Un commentateur de Hacker News qui dit auditer ce genre de sites tous les jours ajoute avoir trouvé au moins trente clés d'accès laissées en clair (février 2026). Ces trois voix vendent un service de sécurité : leurs chiffres décrivent leur clientèle, pas l'ensemble du marché. Ils portent quand même sur trois échantillons distincts et racontent la même chose.

L'écran de connexion ne garde rien

Votre application, c'est un affichage d'un côté et une base de données de l'autre. L'affichage décide de ce qui apparaît à l'écran ; la base décide de ce qui sort quand on lui demande. Quand personne n'a écrit de règle table par table (qui a le droit de lire les clients, qui a le droit de lire les commandes), la base répond à toute demande de la même façon, et l'écran continue de paraître normal. Une application peut donc marcher pendant des mois, encaisser des paiements et servir de vrais utilisateurs, pendant que la porte de derrière reste ouverte. La sécurité se décide dans la base, table par table, et l'écran ne peut pas la rattraper.

Trois vérifications que vous pouvez faire ce soir

La première : ouvrez l'adresse publique de votre application dans une fenêtre de navigation privée, sans vous connecter, et notez chaque page qui affiche quelque chose de réel (une liste, une fiche client, un tableau de bord, une page de réglages). La deuxième : créez deux comptes d'essai avec deux adresses différentes, saisissez une donnée reconnaissable dans chacun, puis vérifiez depuis le premier compte que rien du second n'apparaît nulle part, y compris dans les recherches et les exports. La troisième : demandez un export de vos données depuis un compte ordinaire et lisez ce qu'il contient ; un export plus généreux que le compte qui l'a demandé signale une règle manquante. Ces trois gestes se font sur votre propre application, en un quart d'heure, sans rien installer.

Trois questions à poser à celui qui construit

Elles se posent en français, à une agence, à un freelance ou à l'équipe d'agents qui travaille pour vous. Un : chaque table de ma base a-t-elle sa propre règle d'accès écrite, et laquelle ? Deux : quand un compte réclame une donnée qui ne lui appartient pas, que répond le serveur, et quel test le prouve ? Trois : qu'est-ce qui empêche un visiteur de la démonstration d'écrire dans la base qui sert mes vrais clients ? Une réponse qui rassure sans nommer une seule règle vaut pour une absence de réponse, et mérite d'être reposée par écrit. Notez que ces questions se posent en français ordinaire : elles demandent un interlocuteur qui accepte de vous répondre en clair, comme les cinq pièges du développement par IA le montrent déjà.

Ce qu'une méthode change, et ce qu'elle ne change pas

Chez Maestro, les droits d'accès se décident dans le cahier des charges, avant la construction : qui voit quoi, qui modifie quoi, ce qu'un visiteur non connecté peut atteindre. Marcel découpe ensuite le travail en étapes et Félix écrit les tests de chaque étape avant qu'une ligne de code n'existe, ce qui oblige à formuler la règle d'accès en toutes lettres au lieu de la supposer. Aucun de ces garde-fous ne rend une application invulnérable, et nous sommes mal placés pour le prétendre : un beta-testeur a trouvé en août une clé de base de données visible dans notre propre code, corrigée depuis. Une méthode réduit le nombre d'endroits où la règle manque. Elle ne remplace pas une relecture par quelqu'un dont la sécurité est le métier.

En pratique

Faites les trois vérifications ce soir sur votre application en production, dans l'ordre, et écrivez ce que vous trouvez sur une feuille. Si l'une des trois vous inquiète, coupez l'accès public le temps de comprendre : une application hors ligne pendant deux jours coûte moins cher qu'un fichier clients qui circule. Si vous construisez encore, ajoutez la ligne « qui a le droit de lire quoi » à votre cahier des charges avant la première étape de construction, et gardez-la sous les yeux à chaque validation. Notre page Vos données détaille où vivent les vôtres quand vous travaillez avec Maestro.