Le no-code ne vous
dispense pas de savoir
qui accède à quoi.
Sans une ligne de code, vous avez construit un produit qui stocke des données clients, envoie des e-mails et encaisse des paiements. La plateforme gère l'hébergement et les mises à jour. Elle ne gère pas les règles d'accès à vos données : c'est vous qui les avez configurées, souvent sans que personne ne les relise.
Pas de code source, mais une configuration qui décide de tout.
Sur une application classique, on relit du code. Sur une application no-code, il n'y a rien à relire : le comportement du produit résulte d'un ensemble de réglages effectués dans une interface. C'est ce qui rend ces plateformes accessibles, et c'est aussi ce qui rend leurs failles discrètes — un mauvais réglage ne ressemble pas à une erreur, il ressemble à un écran qui fonctionne.
Le déplacement du risque est net. La plateforme prend en charge des sujets souvent négligés en développement classique : correctifs de sécurité, hébergement, sauvegardes, certificats. En échange, la totalité du contrôle d'accès à vos données repose sur une configuration que rien ne valide.
Les points examinés
Règles de confidentialité des données
- Sur Bubble, les privacy rules se définissent au niveau du type de données. Tant qu'elles ne sont pas posées, la donnée reste accessible même si l'écran ne l'affiche pas.
- Le réflexe le plus répandu — masquer un élément dans l'éditeur — ne protège rien : il change l'affichage, pas l'autorisation.
- Vérification champ par champ des données réellement exposées à un utilisateur connecté, et à un visiteur non authentifié.
Workflows et actions déclenchables
- Quels workflows peuvent être déclenchés par un utilisateur, et avec quelles conditions réellement vérifiées côté serveur ?
- Une action sensible — modifier un montant, changer un statut, supprimer un enregistrement — est-elle protégée autrement que par le fait que le bouton soit caché ?
API et connecteurs
- Points d'entrée d'API exposés par la plateforme, et authentification réellement exigée.
- Clés des services connectés : où sont-elles stockées, et sont-elles visibles côté navigateur ?
- Automatisations tierces qui recopient vos données ailleurs, souvent oubliées de l'inventaire.
Bases de données partagées
- Une base Airtable partagée par lien est accessible à toute personne qui obtient ce lien — y compris après le départ de la personne à qui il avait été transmis.
- Vues publiques et formulaires : ce qu'ils exposent au-delà de ce que l'on croit.
Données personnelles et sous-traitance
- Où sont hébergées les données, et par quelles sociétés sont-elles traitées ?
- Comment répondre à une demande de suppression quand la donnée est répartie entre une plateforme, un outil d'automatisation et une base annexe ?
- Voir la conformité technique RGPD.
No-code et code généré par IA : ne pas confondre
Ces deux familles sont souvent regroupées, à tort. Lovable, Bolt ou Cursor génèrent du code qui vous appartient : il peut être relu, corrigé, et emporté ailleurs. Bubble ou Webflow produisent une application qui vit dans la plateforme : il n'y a pas de code source à examiner, et la portabilité est limitée.
Les questions de fond restent identiques — qui accède à quoi, et qu'est-ce qui le garantit — mais la méthode d'audit diffère. Pour les applications générées, voir l'audit sécurité Lovable et Supabase.
Le moment le plus risqué : la migration
Beaucoup de produits no-code finissent par être réécrits en code classique, lorsque la plateforme atteint ses limites. C'est le moment où le plus de données transitent, où des accès temporaires sont créés — et rarement refermés.
Un audit avant migration établit ce qui est réellement stocké et quelles règles d'accès existent, afin qu'elles soient réimplémentées dans la nouvelle application. Elles ne se transfèrent pas toutes seules.
Audit no-code — questions fréquentes
Une application no-code peut-elle vraiment être auditée ?
Oui, mais l'audit change de nature. Il n'y a pas de code source à relire : l'examen porte sur la configuration de la plateforme — règles de confidentialité des données, workflows déclenchables, points d'entrée d'API, partages de bases et connecteurs tiers. C'est un audit de configuration plutôt qu'un audit de code.
Quel est le risque le plus fréquent sur Bubble ?
Les règles de confidentialité insuffisantes. Sur ce type de plateforme, masquer un élément dans l'interface ne restreint pas l'accès à la donnée sous-jacente : si la règle n'est pas définie au niveau du type de données, l'information reste accessible par d'autres chemins que l'écran prévu.
Le no-code est-il moins sûr que le code ?
Ni plus ni moins, mais les risques se déplacent. La plateforme prend en charge des sujets souvent mal traités en développement classique : mises à jour, correctifs, hébergement. En contrepartie, tout repose sur une configuration que rien ne vérifie, réalisée le plus souvent par une personne non spécialiste de la sécurité.
Quelle différence avec un audit d'application Lovable ou Bolt ?
Lovable et Bolt génèrent du code que vous détenez : il peut être relu ligne par ligne. Bubble ou Webflow produisent une application qui vit dans la plateforme, sans code source consultable. Le périmètre d'audit est donc différent, même si les questions de fond — qui peut accéder à quoi — restent les mêmes.
Que se passe-t-il si je migre plus tard vers du code ?
C'est une trajectoire fréquente, et le moment le plus risqué pour les données. Un audit avant migration permet de savoir ce qui est réellement stocké, quelles règles d'accès existent, et lesquelles devront être réimplémentées dans la nouvelle application — elles ne se transfèrent pas automatiquement.
Qui peut voir vos données
dans votre app no-code ?
Si la réponse demande réflexion, elle mérite d'être vérifiée. 30 minutes en visio, sans engagement.
→ Demander un devis