Politique de réponse aux incidents de sécurité

Sont couverts le site lecommis.com, le configurateur loué (« Le Commis ») et l'espace des marchands abonnés — ainsi que les données d'ArchBaze, celles de ses marchands, et celles des clients de ces marchands, qui n'appartiennent ni à l'un ni à l'autre.

Sous-traitants : Supabase (base de données et stockage), Vercel (hébergement), et le fournisseur de messagerie propre à chaque marchand.

Par ordre de fiabilité :

• le signalement d'un marchand ou d'un client — aujourd'hui la source principale ;
• le journal des interventions du support, que chaque marchand consulte dans son propre espace, et qui l'avertit par courriel dès que son compte est ouvert ;
• le journal d'audit d'administration : qui a fait quoi, quand, sur quoi ;
• la file des courriels, qui garde chaque envoi tenté et le motif de tout refus ;
• l'écran de sécurité, qui recense les rejets de l'API publique : clé invalide ou révoquée, origine refusée, freinage, quota.

Le niveau peut monter ; il ne descend jamais en silence.

Gestes disponibles, tous en service :

• fermer toutes les sessions d'un compte compromis — changer le mot de passe suffit, la date du changement périme les jetons antérieurs, y compris celui de l'intrus ;
• couper le service d'un marchand ;
• révoquer une clé d'intégration, ou retirer une origine autorisée, ce qui coupe l'intégration sur un domaine compromis ;
• désactiver un compte de connexion sans le supprimer ;
• éteindre le site sans toucher au service vendu aux marchands.

Le journal d'audit, la file des courriels et les rejets de l'API publique établissent la chronologie ; les sauvegardes — complètes, contrôlées à l'écriture, quatorze générations — permettent de comparer un état avant et après. Ce qui est établi s'écrit au moment où il l'est.

La correction suit la règle du dépôt : un banc d'essai qui reproduit le défaut avant le correctif, et une vérification que ce banc sait échouer. Un incident sans banc est un incident qui reviendra.

Les messages adressés à un marchand partent de la messagerie d'ArchBaze ; ceux qu'un marchand adresse à ses propres clients partent de sa messagerie, jamais de la nôtre — c'est la règle du produit, et elle vaut aussi en incident.

• Cloisonnement : le catalogue, les devis et le fichier client d'un marchand ne remontent pas à l'éditeur. Ce qui reste accessible pour le dépannage est journalisé et visible par le marchand lui-même.
• Aucun mot de passe lisible : l'éditeur peut déclencher une réinitialisation, jamais lire un mot de passe.
• Double authentification avec codes de secours, et avis au titulaire si elle est désarmée.
• Freinage de tous les formulaires publics et de la connexion.
• Empreinte des adresses IP plutôt que l'adresse, dans le compteur d'abus du widget.
• 213 bancs d'essai automatisés, dont 19 dédiés à la sécurité et aux données personnelles.
• Conservation et purge : aperçu avant destruction, jamais l'inverse.

Écrit ici plutôt que passé sous silence : une politique qui cache ses limites échoue au moment précis où elle sert.

• La surveillance reste partielle : les cinq incidents qui touchent l'argent — un encaissement non tracé, une option payée et non ouverte — partent désormais par courriel dès qu'ils surviennent, mais les autres défauts ne remontent encore que dans un journal serveur que personne ne lit en continu.
• Il n'y a pas de suppléance : une seule personne exploite le service.
• Les sauvegardes sont manuelles et conservées sur la même machine que ce qu'elles protègent. Automatisation et copie hors site en cours de mise en place.
• Les données de test et de production ne sont pas encore séparées. Séparation en cours.
• Aucune vérification par un tiers indépendant n'a eu lieu à ce jour.
• Aucun exercice d'incident n'a encore été mené.

Cette politique est relue après chaque incident de niveau 1 ou 2, et au moins une fois par an. Chaque limite levée quitte ce chapitre.