Sécurité

La sécurité de cette boutique repose sur trois principes : les données sont chiffrées en transit et au repos, chaque utilisateur ne voit que ce qui appartient à son propre compte d'entreprise, et les décisions concernant l'argent et les droits sont toujours prises sur le serveur — jamais dans le navigateur.

Ce dernier point compte plus qu'il n'y paraît : tout ce qui s'exécute dans le navigateur peut être modifié par le visiteur. C'est pourquoi le serveur recalcule à chaque commande les prix, les remises par palier, le traitement de la TVA et les autorisations, quelles que soient les données envoyées par la page.

• Moindre privilège : chaque composant n'obtient que l'accès réellement nécessaire.
• Défense en profondeur : si une mesure échoue, d'autres protègent encore vos données.
• Minimisation des données : nous ne stockons rien qui ne serve pas à traiter votre commande.
• Traçabilité : les actions sensibles laissent une trace dans les journaux.

Tout le trafic entre votre navigateur et la boutique passe par HTTPS avec TLS 1.2 ou supérieur. Les requêtes HTTP sont redirigées vers HTTPS et le site envoie un en-tête HSTS, si bien que votre navigateur refuse ensuite lui-même toute connexion non chiffrée.

Le serveur envoie également un ensemble d'en-têtes de sécurité qui réduisent la marge de manœuvre d'une attaque.

• Content-Security-Policy : définit les scripts, styles, images et connexions autorisés, empêchant l'exécution de code injecté.
• X-Content-Type-Options : nosniff — le navigateur ne peut pas réinterpréter les types de fichiers.
• X-Frame-Options / frame-ancestors : la boutique ne peut pas être intégrée dans le cadre d'un autre site (clickjacking).
• Referrer-Policy : aucune URL complète avec paramètres n'est transmise en quittant le site.
• Permissions-Policy : caméra, microphone et géolocalisation sont bloqués ; la boutique n'en a pas besoin.

Les comptes reposent sur une plateforme d'authentification gérée. Les mots de passe ne sont jamais stockés en clair : ils sont enregistrés via une fonction de hachage moderne avec sel et ne sont ni lisibles ni réversibles, même par nous. Il n'existe pas d'auto-inscription anonyme avec droits élevés ; les nouveaux comptes professionnels sont rattachés à une entreprise.

Après connexion, vous recevez un jeton d'accès de courte durée et un jeton de renouvellement. Le jeton d'accès expire automatiquement, donc un jeton divulgué n'est utilisable que brièvement. La déconnexion révoque la session.

• L'authentification à deux facteurs (2FA) via une application dédiée est activable par utilisateur.
• Les adresses e-mail sont vérifiées avant l'activation complète d'un compte.
• La récupération de mot de passe passe par un lien à usage unique et à validité courte.
• Les tentatives de connexion sont limitées afin d'empêcher les attaques par devinette.
• Vous pouvez aussi vous connecter en toute sécurité pendant le paiement ; votre panier est conservé.

Un compte d'entreprise peut regrouper plusieurs collaborateurs. Chacun dispose d'un rôle définissant ses droits : commander, consulter uniquement, ou administrer le compte. Les rôles sont stockés dans une table distincte, pas dans le profil utilisateur — précisément pour empêcher quiconque de se promouvoir administrateur en modifiant son profil.

Les contrôles de rôle s'effectuent toujours dans la base de données via des fonctions auxiliaires fixes en lecture seule. Le navigateur sait quoi afficher, mais ne décide jamais de ce que vous avez le droit de faire.

• Acheteur : peut commander dans la limite de crédit convenue et saisir des références de commande.
• Lecteur : peut consulter commandes et factures, sans pouvoir commander.
• Administrateur : peut ajouter des collaborateurs, ajuster les droits et gérer les données de l'entreprise.
• Les collaborateurs de l'entreprise A ne peuvent techniquement pas accéder aux commandes, factures ou prix de l'entreprise B.

La base de données n'est pas ouverte. Chaque table contenant des données clients applique la sécurité au niveau des lignes, avec des règles explicites déterminant, ligne par ligne, qui peut lire, créer, modifier ou supprimer. Sans règle correspondante, une ligne est tout simplement invisible, même en cas de requête mal écrite dans l'application.

De plus, les privilèges par défaut sur le schéma ont été révoqués et ne sont accordés que de manière ciblée. Les données publiques — textes produits, dimensions, catégories — sont volontairement lisibles ; tout ce qui relève d'un client ne l'est pas.

• Commandes, devis, factures et adresses sont liés à l'entreprise de l'utilisateur connecté.
• Les envois via les formulaires de contact et de devis peuvent être créés mais jamais relus publiquement.
• Les fonctions d'administration sont protégées par un contrôle de rôle distinct et inaccessibles aux comptes ordinaires.
• Les fonctions de base de données à privilèges élevés ont un chemin de recherche figé et ne sont pas exécutables par des visiteurs anonymes.

Les paiements passent par Stripe, prestataire certifié PCI-DSS. Vos données de carte ou iDEAL sont saisies dans l'environnement de Stripe et ne transitent jamais par nos serveurs ni notre base de données. Nous ne recevons que le statut de paiement et une référence de transaction.

Le montant à payer est composé sur le serveur : prix des articles, remises par palier, frais de port et TVA sont recalculés depuis la base de données. Un panier manipulé ou un prix modifié dans le navigateur ne peut donc pas donner une commande moins chère.

• Les retours de Stripe arrivent via un webhook dont la signature est vérifiée cryptographiquement.
• Les webhooks sont idempotents : une notification reçue en double ne crée pas de commande en double.
• Une commande n'est marquée payée qu'après confirmation de Stripe, pas au retour dans le navigateur.
• Le traitement de la TVA (dont l'autoliquidation intracommunautaire) est déterminé côté serveur, avec validation du numéro de TVA via VIES.

Les formulaires et les points d'accès sensibles sont soumis à une limitation de débit : le nombre de tentatives par visiteur sur une fenêtre de temps est plafonné. Cela freine le spam automatisé, le sondage de comptes et l'épuisement de notre capacité d'envoi d'e-mails.

Le compteur de cette limitation est verrouillé : les utilisateurs ne peuvent ni l'appeler ni l'influencer ; seul le serveur le met à jour.

• Les formulaires de devis, de contact et d'inscription sont limités par adresse IP et par compte.
• Toutes les entrées sont validées côté serveur (type, longueur, format) avant tout enregistrement.
• Les téléversements de fichiers sont limités en type et en taille et stockés hors de l'environnement applicatif.
• Les paramètres de recherche et de filtrage sont analysés et validés, jamais insérés tels quels dans une requête.

La boutique est une application moderne rendue côté serveur, où l'accès à la base de données passe exclusivement par des fonctions serveur typées. Les requêtes sont paramétrées, ce qui prive l'injection SQL de prise, et les sorties sont échappées par défaut par le framework, ce qui contre le cross-site scripting.

Les secrets tels que les clés d'API ne figurent jamais dans le code source ni dans le bundle du navigateur. Ils sont lus comme variables d'environnement protégées au moment de l'exécution d'une fonction serveur.

• Le code client et le code serveur sont strictement séparés ; les modules serveur ne peuvent pas atterrir dans le bundle navigateur.
• Les dépendances sont analysées périodiquement à la recherche de vulnérabilités connues, puis mises à jour.
• Les modifications sont testées sur un environnement de prévisualisation avant la mise en ligne.
• La base de données est régulièrement examinée par un analyseur de sécurité (règles manquantes, droits trop larges).

L'application fonctionne sur une infrastructure gérée avec renouvellement automatique des certificats, mitigation DDoS au niveau réseau et un réseau edge réparti mondialement. La base de données se trouve dans un centre de données situé dans l'Union européenne et le stockage est chiffré au repos.

Des sauvegardes quotidiennes sont réalisées, avec restauration à un instant donné. Les procédures de restauration sont testées régulièrement.

• Chiffrement au repos au niveau de la base de données et du stockage d'objets.
• Sauvegardes quotidiennes avec durée de conservation et restauration point-in-time.
• L'accès administrateur à l'infrastructure est limité à quelques personnes et protégé par 2FA.
• Les contrôles d'état et les erreurs serveur sont surveillés pour détecter rapidement les incidents.

Les événements importants — tentatives de connexion, changements de statut de commande, actions d'administration et erreurs serveur — sont journalisés. Les journaux ne contiennent ni mots de passe ni données de paiement et sont conservés douze mois au maximum.

En cas de suspicion de violation de données, nous évaluons immédiatement l'ampleur, comblons la faille et informons les personnes concernées ainsi que, lorsque le RGPD l'exige, l'autorité de contrôle dans les 72 heures.

La sécurité est une responsabilité partagée. La plupart des incidents ne commencent pas sur le site, mais par un mot de passe réutilisé ou un e-mail d'hameçonnage convaincant.

• Utilisez un mot de passe unique et long, conservé dans un gestionnaire de mots de passe.
• Activez l'authentification à deux facteurs pour tous les membres du compte d'entreprise.
• Retirez immédiatement du compte les collaborateurs qui quittent l'entreprise.
• Nous ne demandons jamais votre mot de passe ni votre code 2FA par e-mail ou par téléphone.
• En cas de changement de coordonnées bancaires sur une facture, vérifiez toujours par téléphone au numéro indiqué sur ce site.

Vous avez découvert une faiblesse ? Signalez-la avant de la rendre publique. Envoyez un e-mail avec une description, l'URL concernée et les étapes de reproduction. Nous accusons réception, vous tenons informé et vous créditons nommément si vous le souhaitez une fois le problème corrigé.

Nous vous demandons de ne pas mener d'attaques automatisées perturbant le service, de ne pas accéder aux données d'autres clients et de ne rien modifier ni supprimer.