Nous faisons tourner StandardOS sur StandardOS

Infrastructure et hébergement

Disponibilité

Surveillée en continu depuis l'extérieur de notre propre infrastructure, et le résultat est public, y compris quand il est mauvais. Nous préférons que vous voyiez un incident ici plutôt que de l'apprendre de nous après coup. État du service en direct → (en anglais)

Localisation des données

Toutes les données clients sont stockées dans l'UE (Supabase, région Irlande). Nous choisissons des régions de l'UE partout où le service touche des enregistrements clients.

Diffusion

Les applications sont servies uniquement en TLS 1.2+, avec HSTS. Les fichiers statiques passent par un CDN ; aucun enregistrement client en périphérie.

Sauvegardes

Sauvegardes quotidiennes gérées de la base principale, conservées dans la même région de l'UE, avec alerte automatique si une sauvegarde prévue n'apparaît pas. Une copie chiffrée hebdomadaire est également conservée hors du fournisseur de base de données, pour qu'une défaillance de ce compte n'emporte pas toutes les copies.

Restauration

Vérifiable plutôt qu'affirmée. Comme chaque enregistrement est chaîné par empreinte et que les racines quotidiennes sont publiées, une base restaurée peut être confrontée à une copie que nous ne contrôlons pas : c'est la vérification même que nous remettons à votre auditeur. Une restauration modifiée ne correspondrait pas, et nous le saurions au lieu de le supposer.

Intégrité des enregistrements, notre différence

Piste d'audit infalsifiable

Chaque modification de vos enregistrements SMSI (documents, risques, déclaration d'applicabilité, preuves, non-conformités, audits, revues, et les accès accordés) est écrite dans un journal en ajout seul, chaîné par empreinte. Chaque entrée scelle la précédente, avec l'auteur de la modification, si bien que réécrire l'histoire ou en changer l'auteur casse la chaîne de façon visible. Les personnes connectées ont un accès en lecture seule à ce journal au niveau de la base ; il n'existe de chemin de suppression pour personne.

Ancrages quotidiens

Chaque nuit, nous relevons la tête de chaque chaîne et l'envoyons le lendemain matin (07:00 UTC) aux propriétaires et administrateurs de l'organisation. Une fois ce reçu dans votre boîte, il est sur un serveur que nous n'exploitons pas : une réécriture ultérieure produirait une tête qui ne correspondrait plus à celle que vous détenez déjà. Les racines quotidiennes sont aussi publiées ouvertement, pour que chacun puisse les archiver. Cela ne rend pas la falsification impossible. Cela la rend détectable par qui a gardé son courrier. Les racines quotidiennes publiées → (en anglais)

Vérifiabilité

Les exports contiennent les empreintes et le contenu sur lequel elles sont calculées, ainsi que la règle de hachage exacte. Vous pouvez recalculer toute la chaîne vous-même, dans n'importe quel langage, sans que StandardOS tourne. La spécification et un script sans dépendances qui le fait en une centaine de lignes sont publiés, et c'est ce script que notre propre CI exécute sur une vraie chaîne à chaque push. Nous n'avons pas trouvé d'autre outil sur ce marché qui permette à un client de vérifier l'historique sans faire confiance à l'éditeur. Si vous en connaissez un, dites-le-nous et nous corrigerons cette page. La spécification et le script →

Contrôle d'accès

Isolation des locataires

Sécurité au niveau des lignes sur chaque table, appliquée dans la base elle-même plutôt que dans le code applicatif, et testée en CI (pgTAP) à chaque changement.

Authentification

Connexion par mot de passe avec hachage moderne, connexion via Microsoft et Google, ou authentification unique SAML 2.0 via le fournisseur d'identité de l'organisation, qu'un propriétaire configure sur la page Sécurité et peut rendre obligatoire pour tous les membres. Les sessions sont courtes et renouvelées. Chacun peut activer un second facteur (TOTP) sur son compte, et un propriétaire peut l'exiger : pour les connexions par mot de passe, ou pour toute connexion quel que soit le fournisseur. Les deux exigences sont appliquées dans la base, pas dans l'interface : une session qui ne les respecte pas ne voit aucune donnée de l'organisation.

Notre propre accès

Rôles internes au moindre privilège. Chaque action d'un opérateur sur un locataire est écrite dans un registre en ajout seul que nous ne pouvons ni modifier ni supprimer, et que le locataire lit sur sa propre page Piste d'audit, sous les actions du personnel de StandardOS. L'identité de celui de nos salariés qui a agi n'est pas divulguée, car ce sont des données personnelles de nos employés ; l'entrée dit donc ce qui s'est passé, quand, et ce qui a changé. Ce registre est en ajout seul et non chaîné par empreinte : la chaîne et ses ancrages protègent vos enregistrements, pas notre journal d'accès, et nous préférons dire lequel est lequel.

Pratiques de développement

Gestion des changements

Chaque changement passe par la CI : vérification des types, tests, tests des politiques de base de données, et recherche de secrets à chaque commit.

Vérifié hors du produit

Chaque push construit une vraie chaîne d'empreintes dans Postgres, l'exporte et la revérifie avec le script sans dépendances que nous publions, exécuté avec Node seul et sans StandardOS. Un changement de la règle de hachage qui aurait oublié de mettre à jour la spécification fait échouer notre build plutôt que votre audit.

Isolation testée dans la base

La sécurité au niveau des lignes est vérifiée avec pgTAP contre un Postgres réel à chaque push. Les politiques sont testées là où elles s'appliquent, et non relues à l'œil dans le code applicatif.

Secrets

Recherchés en CI et de nouveau par un hook git avant que le code ne quitte une machine de développement, avec tout l'historique du dépôt analysé et propre.

Dépendances

Verrouillées et revues ; alertes automatiques de vulnérabilité sur l'ensemble du graphe de dépendances.

Discipline sur l'IA

Dans le produit, une sortie assistée par IA est toujours un brouillon signalé comme tel jusqu'à confirmation humaine. La même règle vaut pour notre façon de construire.

Vie privée et protection des données

RGPD

Responsable de traitement danois. Notre contrat de sous-traitance au titre de l'article 28 est publié intégralement sur getstandardos.com/legal/dpa, pour tous les clients et toutes les formules, sans signature ni rendez-vous commercial. Le détail de ce que nous traitons et pourquoi figure dans la politique de confidentialité.

Aucun traçage

Aucun traceur d'analyse ni de publicité sur ce site ; pas de bandeau cookies, parce qu'il n'y a rien à accepter.

Diagnostics

Les adresses e-mail, adresses IP, identifiants d'enregistrement, cookies et en-têtes d'autorisation sont retirés des rapports d'erreur avant qu'ils ne quittent nos serveurs. Configuré dans le code et revu à chaque changement, plutôt que promis dans une politique.

Sortie

Export complet en un clic, dans des formats ouverts, à tout moment : pendant l'essai, pendant l'abonnement, et 90 jours après une résiliation. L'enfermement n'est pas une stratégie de rétention.

Sous-traitants

Volontairement peu nombreux. Les changements sont annoncés ici, avec préavis aux clients. Cette liste et celle de notre politique de confidentialité(en anglais) sont la même liste, affichée deux fois. Dernière modification le 2026-07-28.

Divulgation responsable

Vous avez trouvé une vulnérabilité ? Écrivez-nous à security@getstandardos.com et nous accusons réception sous deux jours ouvrés. Nous n'engageons pas de poursuites contre la recherche de bonne foi, nous vous tenons informé pendant la correction, et nous créditons ceux qui le souhaitent. Merci d'éviter d'accéder aux données d'autres organisations. La sécurité au niveau des lignes devrait rendre cela impossible, et nous aimerions sincèrement savoir si ce n'est pas le cas.