Sécurité

Les données de votre atelier — stocks, lots, recettes, ventes, traçabilité — ne sont visibles que des comptes de votre atelier. Ce cloisonnement est appliqué par la base de données elle-même, pas par l'écran, et il est vérifié automatiquement à chaque modification du logiciel. Cette page décrit ce qui est en place aujourd'hui, et ce qui ne l'est pas encore.

• Chaque table est protégée par la sécurité au niveau des lignes de PostgreSQL (Row Level Security) : une requête émise depuis un compte ne voit et ne modifie que les lignes de son atelier.
• L'atelier sur lequel agit une opération est lu dans la session du compte, jamais cru sur la foi d'un identifiant envoyé par le navigateur. Un contrôle placé seulement dans l'écran ne protégerait rien : la console du navigateur suffit à le contourner.
• Les opérations internes qui s'exécutent au-dessus de ce mécanisme contrôlent l'atelier elles-mêmes, dans leur code.
• Un test automatique tente, depuis un atelier, de lire, créer, modifier et supprimer les données d'un autre, sur chaque table et par chaque opération ; il doit échouer partout. Il est rejoué à chaque modification du logiciel.

• Un mot de passe compte au moins dix caractères, dont une minuscule, une majuscule, un chiffre et un symbole. Un mot de passe déjà apparu dans une fuite publique connue est refusé.
• Les mots de passe sont hachés et les échanges chiffrés en transit ; personne, pas même l'éditeur, ne peut lire votre mot de passe.
• Chaque compte peut activer la vérification en deux étapes, par une application d'authentification. Une fois activée, elle est exigée par la base de données : une session ouverte avec le seul mot de passe n'accède à aucune donnée de l'atelier. Elle reste facultative aujourd'hui.
• Les rôles de l'équipe (gérant, atelier) ne s'écrivent que par le logiciel, et un atelier garde toujours au moins un gérant.

• Le stock ne s'écrit que par des opérations complètes — une réception, une fabrication, une vente, une correction — qui aboutissent en entier ou pas du tout. Le navigateur ne peut écrire directement aucune table de stock.
• Chaque mouvement de stock entre dans un journal qui nomme le compte qui l'a produit. Annuler une vente ou une correction y ajoute une écriture inverse ; la ligne d'origine reste au journal.
• Les actes d'administration — changer un rôle, retirer un membre, accepter une invitation, changer d'offre, exporter le dossier, demander ou annuler la fermeture — laissent une trace que le gérant peut consulter. Elle ne porte ni nom ni adresse.

• Le site n'autorise que ses propres scripts : une politique de sécurité du contenu n'admet aucun script injecté ni évalué à la volée, et interdit d'afficher Valotea dans le cadre d'un autre site.
• Le site n'est servi qu'en HTTPS, et le navigateur est invité à s'en souvenir pendant un an.
• Aucun cookie publicitaire, aucun traceur d'un site à l'autre ; les polices sont servies par Valotea lui-même. La mesure d'audience ne dépose aucun cookie — voir la politique de confidentialité.

• La base de données est hébergée par Supabase dans l'Union européenne (Stockholm, Suède). La liste complète des prestataires et de ce qu'ils reçoivent figure dans la politique de confidentialité.
• La base est sauvegardée chaque jour, et chaque sauvegarde est conservée sept jours. La restauration a été éprouvée sur une copie séparée, sans toucher à la production. En cas de sinistre, au plus une journée de saisies pourrait être perdue.

• Chaque modification passe par une vérification automatique avant d'entrer dans le logiciel : le schéma de la base est reconstruit de zéro et toutes ses règles de gestion sont rejouées, y compris le test de cloisonnement.
• La même vérification refuse une modification qui introduirait une dépendance portant une vulnérabilité connue de gravité haute ou critique, ou un secret (clé, mot de passe) dans le code ou dans son historique. Les mises à jour de dépendances sont proposées chaque semaine et relues avant d'être intégrées.
• Chaque règle de sécurité ajoutée est accompagnée d'un test, et ce test est volontairement mis en échec une fois pour vérifier qu'il détecte bien ce qu'il garde.

Une procédure écrite encadre la réponse à un incident : le contenir, faire tourner les secrets exposés, conserver les preuves, rétablir le service. Si une violation touche des données de votre atelier, vous en êtes informé dans les meilleurs délais, comme le prévoit l'article 6 du contrat de sous-traitance. Pour les données dont l'éditeur est lui-même responsable — les comptes, la facturation —, la CNIL est notifiée dans les 72 heures lorsque la loi l'exige. Chaque violation est consignée dans un registre, même quand elle n'appelle aucune notification.

• Le gérant peut exporter à tout moment le dossier complet de l'atelier, en fichiers ouverts (CSV), quelle que soit l'offre souscrite.
• La fermeture d'un atelier se demande depuis les Réglages : soixante jours en lecture seule, annulables, pendant lesquels l'export reste possible, puis l'effacement de l'atelier et des comptes qui n'appartiennent à aucun autre. Une attestation de fermeture se télécharge dès la demande.

• Aucun logiciel n'est à l'abri de toute faille, et Valotea ne fait pas exception. Cette page décrit des mesures, pas une garantie d'absence de risque.
• Valotea n'est titulaire d'aucune certification de sécurité (ISO 27001, SOC 2, hébergement de données de santé…).
• Aucun test d'intrusion n'a encore été mené par un prestataire extérieur.
• Les incohérences de stock, les hausses d'erreurs d'exécution et les rafales de refus de connexion déclenchent une alerte par e-mail à l'éditeur, en général dans le quart d'heure qui suit leur détection ; le reste est relevé chaque semaine. Personne n'est d'astreinte : aucun délai de réaction n'est promis.
• Valotea est édité par une entreprise individuelle : l'éditeur est aujourd'hui la seule personne habilitée à intervenir sur la production, et il est tenu à la confidentialité.

Si vous pensez avoir trouvé une faille de sécurité, écrivez à contact@valotea.fr en décrivant ce que vous avez observé, sans accéder aux données d'un autre atelier ni les modifier.