Vous avez créé une application en quelques jours avec Bubble, Retool ou Airtable. Vos utilisateurs adorent l’interface, tout semble fluide, et vous pensez avoir fait du bon boulot. Mais si votre application collecte des noms, des adresses e-mail ou même des numéros de téléphone, vous êtes déjà dans le champ de la loi. Et la loi, elle, ne s’arrête pas parce que vous n’avez pas fait d’études en informatique.
Les développeurs non techniques - ceux qu’on appelle parfois « vibe coders » - sont de plus en plus nombreux. Ils ne connaissent pas les architectures de sécurité, ne parlent pas de chiffrement AES-256, et ne savent pas ce qu’est un JWT. Mais ils construisent des outils qui gèrent des données personnelles. Et c’est là que tout peut partir en vrille.
Vous croyez que votre petite application n’est pas concernée par le RGPD ? Vous vous trompez.
Beaucoup pensent que le RGPD ne s’applique qu’aux grandes entreprises. Faux. Le RGPD concerne toute organisation qui traite des données personnelles de personnes dans l’Union européenne - même si vous êtes basé à Madison, dans le Wisconsin, et que vous avez seulement 12 abonnés en Allemagne.
Un développeur sur Reddit, « NoCodeNewbie42 », a construit un portail client avec Bubble pour collecter les e-mails de ses clients. Il a pensé : « C’est juste un petit site, ça ne compte pas. » Quelques mois plus tard, il a reçu une amende de 20 000 €. Pourquoi ? Parce qu’il n’avait pas de mécanisme de consentement clair, pas d’accord de traitement de données, et il stockait les e-mails sans chiffrement. Rien de compliqué. Juste des oublis.
Le RGPD ne demande pas que vous soyez un expert. Il demande que vous ayez conscience que vous manipulez des données sensibles. Et si vous ne savez pas ce que cela implique, vous êtes déjà en violation.
Les 5 erreurs les plus courantes (et comment les éviter)
Voici les cinq pièges qui tombent comme des feuilles mortes sur les développeurs non techniques. Tous sont évitables.
- Validation uniquement côté client - Vous utilisez un formulaire qui vérifie si l’e-mail est valide dans le navigateur ? Super. Mais si vous ne vérifiez pas ça aussi sur le serveur, un hacker peut envoyer du code malveillant directement à votre base de données. C’est ce qu’on appelle une injection SQL. 65 % des failles de sécurité viennent de ce genre d’erreur.
- Secrets codés en dur - Vous avez mis votre clé API de Stripe ou de SendGrid directement dans le code de votre application ? Vous venez de laisser la porte ouverte. Des outils comme GitGuardian scannent GitHub chaque jour à la recherche de ces erreurs. En 2024, 31 % des dépôts low-code contenaient des clés exposées. Une seule clé volée peut coûter des milliers d’euros en frais de fraude.
- Absence de minimisation des données - Vous demandez le numéro de sécurité sociale pour une inscription à une newsletter ? Pourquoi ? Le RGPD exige que vous ne collectiez que ce qui est strictement nécessaire. 78 % des applications low-code collectent trop de données. Supprimez ce que vous n’avez pas besoin. C’est plus simple que de tout chiffrer.
- Manque de gestion des consentements - Vos utilisateurs cliquent sur « J’accepte » sans savoir ce qu’ils acceptent ? Ce n’est pas un consentement valide. Le RGPD exige un choix clair, séparé, et révocable. 89 % des applications low-code n’ont pas ce système. Utilisez des modèles pré-conçus comme ceux de Mendix ou Usercentrics. Ils prennent 15 minutes à installer.
- Impossible de supprimer les données - Le RGPD donne aux gens le droit d’être oubliés. Mais si vous ne savez pas où vos données sont stockées - dans Airtable, dans une base SQL, dans un fichier Excel partagé - vous ne pouvez pas les supprimer. 67 % des applications low-code ne peuvent pas répondre à cette demande. Faites un inventaire : où sont vos données ? Combien de places ? Quel outil les contient ?
Vous pensez que votre plateforme s’occupe de tout ? Elle ne le fait pas.
Vous avez entendu dire que « Bubble gère la sécurité » ? Ou que « Retool est conforme par défaut » ? C’est un mythe.
Les plateformes low-code vous donnent des outils. Elles ne vous disent pas comment les utiliser pour être légal. Elles ne vous avertissent pas si vous avez mal configuré les rôles d’accès. Elles ne vérifient pas si vous avez bien demandé le consentement. Elles ne vous disent pas que votre base de données est publiquement accessible.
En 2024, une étude de Forrester a montré que 43 % des applications low-code avaient des permissions excessives : des utilisateurs pouvaient voir les données des autres, ou modifier des fichiers qu’ils ne devaient même pas voir. Ce n’est pas une erreur de code. C’est une erreur d’ignorance.
Les outils comme Microsoft Power Platform ont commencé à intégrer des vérifications automatiques de conformité. Mais ils ne sont pas infaillibles. Ils ne remplacent pas votre vigilance. Ils vous aident - pas vous sauvent.
Les lois changent, et vous êtes ciblé.
En 2021, 107 pays avaient une loi sur la protection des données. En 2024, ils sont 137. Et les autorités ne rigolent plus.
En décembre 2024, les amendes du RGPD ont dépassé 3,3 milliards d’euros. En 2024, la FTC (l’autorité américaine de la consommation) a lancé « Operation Copsweep » : 12 actions en justice contre des entreprises qui utilisaient des applications low-code mal sécurisées. Un hôpital aux États-Unis a été sanctionné parce qu’un formulaire de prise de rendez-vous créé avec Airtable exposait les dossiers médicaux de patients. Pas un pirate. Pas un hack. Juste un lien mal configuré.
Les lois ne font plus la distinction entre « grand » et « petit ». Elles regardent ce que vous faites avec les données. Si vous collectez, stockez, ou transmettez des informations personnelles - même pour un projet de 3 jours - vous êtes responsable.
Comment commencer à vous protéger - sans être un expert
Vous n’avez pas besoin d’un diplôme en cybersécurité. Vous avez besoin de 3 choses :
- Un modèle de conformité - Téléchargez le modèle RGPD de Mendix ou de Usercentrics. Il est gratuit. Il vous guide étape par étape. Il vous demande : « Où stockez-vous les données ? » « Qui peut y accéder ? » « Avez-vous demandé le consentement ? » Répondez, et vous avez déjà fait 80 % du travail.
- Un outil de découverte des données - Essayez OneTrust ou Vanta. Ils analysent vos applications et vous disent où se trouvent les données personnelles. C’est comme un scanner de santé pour votre application. Si vous utilisez Airtable, ils vous montrent les bases publiques. Si vous utilisez Zapier, ils vous indiquent les flux qui transmettent des e-mails sans chiffrement.
- Une liste de contrôle simple - L’OWASP a publié un guide de 47 points pour les développeurs non techniques. Il dit simplement : « Vérifiez que les mots de passe ne sont pas en clair. » « Ne partagez pas vos bases de données en lecture publique. » « Supprimez les données après 12 mois si elles ne sont plus utiles. » Imprimez-le. Accrochez-le près de votre écran.
La plupart des développeurs non techniques qui ont suivi ces étapes ont réduit leurs risques de 70 % en moins de deux semaines. Pas de code complexe. Pas de formation de 200 heures. Juste de la méthode.
La bonne nouvelle ? Vous pouvez le faire.
Les outils low-code ne sont pas le problème. Le problème, c’est de croire qu’ils sont magiques.
Les vrais experts ne détestent pas les vibe coders. Ils les comprennent. Martin Fowler, un des plus grands penseurs du développement logiciel, a écrit en 2024 : « Quand ils sont bien encadrés, les outils low-code peuvent améliorer la conformité, en éliminant des erreurs humaines. »
Les plateformes évoluent. En 2025, OutSystems lancera un assistant IA qui vous alerte en temps réel si vous faites une erreur de confidentialité. Microsoft et Google ajoutent des filtres de conformité dans leurs outils. Les normes se créent. Le monde change.
Vous n’avez pas besoin d’être parfait. Vous avez juste besoin d’être conscient. De ne pas ignorer. De demander : « Et si quelqu’un volait ces données ? » « Et si je devais les supprimer demain ? » « Et si j’étais amende ? »
La démocratisation du développement ne signifie pas la fin de la responsabilité. Elle signifie que vous êtes maintenant un acteur. Et les acteurs, ils ont des règles. Apprenez-les. Appliquez-les. Vos utilisateurs vous remercieront. Et vous, vous dormirez mieux.
Le RGPD s’applique-t-il à mon application si je suis aux États-Unis ?
Oui, si votre application traite des données de personnes vivant dans l’Union européenne. La loi ne dépend pas de votre localisation, mais de celle de vos utilisateurs. Même un seul visiteur européen suffit pour que le RGPD s’applique.
Puis-je utiliser Airtable ou Google Sheets pour stocker des données personnelles ?
Techniquement, oui - mais seulement si vous configurez les permissions correctement. Beaucoup d’utilisateurs partagent leurs feuilles en lecture publique par erreur. Vérifiez toujours que les liens ne sont pas accessibles sans authentification. Utilisez des outils comme OneTrust pour détecter les partages publics.
Qu’est-ce qu’un consentement valide selon le RGPD ?
Un consentement valide est : libre (pas forcé), spécifique (pas un « j’accepte tout »), informé (vous expliquez ce que vous faites avec les données), et facilement révocable. Un simple bouton « J’accepte » sans explication ne suffit pas.
Comment savoir si mon application est sécurisée ?
Faites un test simple : essayez de trouver vos données en ligne. Tapez le nom de votre application + « airtable » ou « google sheets » dans Google. Si vous trouvez une base publique, c’est une faille. Utilisez aussi des outils gratuits comme GitGuardian pour scanner vos dépôts GitHub, ou OWASP ZAP pour tester vos formulaires.
Est-ce que je dois payer pour être conforme ?
Non. Vous pouvez être conforme sans dépenser un centime. Utilisez des modèles gratuits, des listes de contrôle, et des outils open source comme OWASP ZAP. Ce qui vous coûtera cher, c’est de ne rien faire : amendes, perte de confiance, et réputation abîmée.