Mes données sont-elles en sécurité avec un générateur IA ?
Mes données sont-elles en sécurité avec un générateur IA ?
Il faut séparer deux choses. Le projet lui même est hébergé chez nous tant que vous ne l'exportez pas. Les données de vos utilisateurs, elles, vivent dans les comptes que vous branchez : Supabase pour la base et les identifiants, Stripe pour les paiements. Vous en gardez la maîtrise et la responsabilité.
De quelles données parle-t-on exactement ?
De trois familles qu'il ne faut jamais mélanger dans le raisonnement, sous peine de se rassurer sur la mauvaise. La confusion entre elles explique la plupart des mauvaises surprises constatées après la mise en ligne.
La première famille, ce sont vos données de conception : la description que vous écrivez, les textes, les images, la structure du projet. Elles servent à produire le site et elles constituent votre matière de travail.
La deuxième, ce sont les données de vos visiteurs et clients : un formulaire de contact rempli, un compte créé, une commande passée, un paiement. Ce sont les plus sensibles, et ce sont aussi celles dont vous répondez légalement. La troisième, enfin, ce sont vos clés d'accès aux services connectés, qui méritent le même soin qu'un mot de passe bancaire.
Où vivent les données de vos utilisateurs ?
Chez les fournisseurs que vous branchez, sur des comptes qui vous appartiennent. C'est le point d'architecture le plus important de cet article, et il change complètement la réponse à la question du titre.
| Service branché | Ce qu'il stocke | Compte propriétaire |
|---|---|---|
| Supabase | Base de données, comptes utilisateurs, fichiers | Le vôtre |
| Stripe | Paiements et abonnements | Le vôtre |
| Resend | Envoi et journal des courriels | Le vôtre |
| Vercel | Hébergement si vous exportez | Le vôtre |
| GitHub | Code source exporté | Le vôtre |
| Google Analytics | Statistiques de visite | Le vôtre |
Concrètement, quand un visiteur crée un compte sur votre application, ses identifiants sont enregistrés dans votre projet Supabase, pas dans une base commune à tous les clients d'un éditeur. Le raccordement est décrit dans brancher Supabase sur un projet.
Cette organisation a un avantage rarement souligné : le jour où vous changez d'outil de fabrication, vos données ne bougent pas. Elles étaient déjà chez vous.
Que change le fait d'utiliser vos propres comptes ?
Il déplace le pouvoir, et donc le risque, du bon côté. Vous voyez ce qui est stocké, vous exportez quand vous voulez, vous supprimez quand vous voulez, et vous n'avez pas à demander la permission à un intermédiaire pour accéder à votre propre fichier clients.
Il déplace aussi le devoir. Personne ne va configurer les règles d'accès de votre base à votre place, ni surveiller vos clés, ni vérifier que votre table de commandes n'est pas lisible par n'importe qui. Une base mal réglée reste mal réglée, quel que soit l'outil qui a écrit la page qui l'interroge.
Prenez donc le temps de traiter deux points le jour de la mise en production : les droits d'accès aux tables sensibles et le stockage des clés en dehors du code visible. La partie identification est abordée dans créer une connexion utilisateur.
Le RGPD est-il pris en charge automatiquement ?
Non, et méfiez vous de tout outil qui le prétend. Le règlement s'applique à vous en tant que responsable de traitement, c'est à dire à la personne qui décide de collecter des données et de ce qu'elle en fait. Un générateur produit une page, il ne peut pas endosser cette responsabilité.
Ce qui reste à votre charge tient en une liste courte et parfaitement faisable : afficher des mentions légales exactes, publier une politique de confidentialité qui décrit vraiment ce que vous collectez, obtenir un consentement pour les traceurs non nécessaires, ne demander que les informations dont vous avez réellement l'usage, et savoir répondre à une demande de suppression.
La dernière ligne est celle qu'on oublie. Si un client vous écrit pour demander l'effacement de ses données, il faut pouvoir le faire vraiment, dans la base comme dans les courriels et les exports. En France, la CNIL publie des guides pratiques pour les petites structures, et ils valent mieux que n'importe quel modèle recopié sur un forum.
Un projet généré est-il solide côté sécurité applicative ?
Il est vérifié sur un point précis, pas sur tous. Avant la remise, le projet est ouvert dans un bac à sable : une construction qui ne s'affiche pas n'est pas livrée. Cette étape répond à la question « est-ce que cela fonctionne », pas à la question « est-ce que cela résiste à quelqu'un de mal intentionné ».
Il faut le dire franchement, parce que c'est exactement le genre d'approximation qui coûte cher : une génération automatique ne remplace pas une revue de sécurité. Zugo ne remplace pas une équipe de développement sur un produit complexe, et une application qui manipule des données de santé, des données bancaires ou des données de mineurs entre précisément dans cette catégorie.
Pour un site vitrine, une page de réservation ou une boutique simple branchée sur Stripe, le niveau de risque est celui de n'importe quel site du même type, et les précautions ordinaires suffisent. Pour tout ce qui touche à des données réglementées, faites relire le projet par un professionnel avant l'ouverture au public. C'est un coût, et il est nettement inférieur à celui d'une fuite.
Quelles précautions prendre avant de mettre un formulaire en ligne ?
Six vérifications, dans cet ordre. Elles prennent une demi heure et couvrent la grande majorité des incidents observés sur des petits sites.
| Vérification | Question à se poser |
|---|---|
| Champs collectés | Ai je vraiment besoin de chaque information demandée ? |
| Destination des envois | Où arrive le message, et qui y a accès ? |
| Accès à la base | Une table sensible est-elle lisible sans authentification ? |
| Clés et jetons | Une clé apparaît-elle dans une page publique ? |
| Mentions et politique | Le visiteur sait-il ce que je fais de ses données ? |
| Test réel | Ai je rempli le formulaire moi même de bout en bout ? |
La première ligne est la plus rentable de toutes, et la moins appliquée. Une donnée que vous ne collectez pas ne peut ni fuir, ni être réclamée, ni vous obliger à quoi que ce soit. Un formulaire de contact n'a presque jamais besoin d'une date de naissance.
Le test réel arrive en dernier parce qu'il valide tout le reste. Remplissez le formulaire depuis un autre appareil, vérifiez que le message arrive, que l'enregistrement se fait, et que rien n'apparaît là où cela ne devrait pas.
Que se passe-t-il si vous arrêtez d'utiliser l'outil ?
Vous partez avec votre travail. Les sources du projet s'exportent vers GitHub, puis se déploient sur votre propre compte Vercel, et le site sort alors entièrement de notre hébergement. Vos données, elles, n'ont jamais quitté vos comptes de services.
Cette porte de sortie mérite d'être essayée avant d'en avoir besoin, pas le jour où vous en avez besoin. Un export réalisé une fois, calmement, vous apprend en quelques minutes ce que vous récupérez exactement et sous quelle forme. Le parcours est décrit dans exporter le code de son projet.
Prenez également l'habitude d'une copie régulière de ce qui compte : les textes, les visuels, un export de la base. La question des sauvegardes est traitée dans comment sauvegarder son projet, et c'est le genre de discipline dont on mesure la valeur une seule fois, au très mauvais moment.
Comment décider si votre projet peut partir en ligne ?
Posez vous une question unique et honnête : quelle est la donnée la plus sensible que ce projet va manipuler ? Un formulaire de contact avec un nom et un courriel ne joue pas dans la même catégorie qu'un espace client contenant des documents personnels.
Si la réponse reste dans le registre ordinaire, appliquez la liste de vérification ci dessus et publiez. Si elle touche à la santé, à l'argent d'autrui, à des mineurs ou à des documents d'identité, faites relire avant, et acceptez que cette relecture fasse partie du projet plutôt que d'être un luxe.
Enfin, gardez une trace écrite de ce que vous collectez et pourquoi. Ce document sert le jour d'un contrôle, mais il sert surtout à vous : la moitié des données superflues disparaissent au moment où l'on doit justifier leur présence. Vous pouvez construire un premier projet en gardant cette discipline dès le départ depuis zugo.dev.