Cette page décrit la posture de résilience de l'architecture. Plusieurs mécanismes sont encore en développement actif ; la conception est figée et les menaces sont réelles. Si vous souhaitez connaître le statut de mise en œuvre par élément, contactez-nous — nous partagerons les progrès actuels sous NDA.
Infrastructure
Conçu pour continuer à fonctionner quand quelque chose ne fonctionne pas.
Chaque partie de l'infrastructure de Clavitor a été conçue en posant la même question pour chaque dépendance, chaque fournisseur, chaque couche : que se passe-t-il si cela échoue ? Nous avons étudié cette question sur l'ensemble de la pile et conçu l'architecture de manière à ce que la réponse soit toujours la même : le coffre-fort continue de fonctionner.
Cette page liste ce à quoi nous avons pensé. Les mécanismes spécifiques — comment nous résolvons chacun d'eux — restent privés ; les clients sophistiqués peuvent recevoir ces détails sous NDA. Publier la liste des menaces est une preuve d'honnêteté concernant l'ingénierie. Publier les défenses est un schéma gratuit pour les adversaires.
Ce que nous avons conçu
Pannes d'infrastructure cloud hyperscale
Les principaux fournisseurs de cloud tombent en panne. Pas souvent, mais visiblement, et lorsqu'ils le font, ils emportent avec eux de larges pans d'Internet. Nous avons conçu en partant du principe qu'un hyperscaler unique connaîtra finalement un jour de panne mondiale. Clavitor continue de servir les identifiants lorsque cela se produit.
Catastrophes régionales et événements cinétiques
Un événement régional — une frappe de drone sur un centre de données, une coupure de câble sous-marin, une catastrophe naturelle, une guerre régionale — peut mettre hors service une région cloud entière. Le 1er mars 2026, les deux régions AWS Moyen-Orient sont tombées en panne lors du même incident. Nous l'avons pris comme une leçon, pas une hypothèse. L'architecture traite un événement régional comme un mode de défaillance courant que les clients ne remarquent pas.
Pannes de fournisseurs DNS
Si l'entreprise qui héberge votre DNS tombe en panne, votre service disparaît même si toutes les autres parties de votre pile sont saines. C'est vrai pour Cloudflare, Route 53, tous les principaux fournisseurs DNS. Nous avons considéré ce qui se passe lorsque notre fournisseur DNS connaît un mauvais jour.
Pannes d'autorités de certification
Si votre autorité de certification est inaccessible lorsque votre certificat doit être renouvelé, votre TLS tombe en panne. Si une autorité de certification est compromise, tous les certificats qu'elle a émis deviennent invalides. Nous avons considéré ce qui arrive au TLS lorsque l'infrastructure de l'AC se comporte mal.
Problèmes de registraire de domaine
Si votre registraire suspend votre compte ou est compromis, votre domaine disparaît ou est redirigé, quel que soit l'hébergement DNS. Nous avons considéré ce qui se passe si notre registraire fait défaut.
Problèmes d'opérateur TLD
L'organisation qui gère un domaine de premier niveau (.com, .ai, .io) est elle-même un point unique de défaillance. Les TLD plus petits sont exploités par des organisations plus petites avec moins de profondeur opérationnelle. Nous avons considéré ce qui se passe si un opérateur TLD connaît une mauvaise semaine.
Pannes de fournisseurs d'e-mail
Si votre fournisseur d'e-mail est en panne, les codes de récupération de compte n'arrivent pas, les confirmations d'inscription n'arrivent pas, la boîte de réception du support client est inaccessible. Nous avons considéré ce qui arrive à l'authentification et à la récupération lorsque notre fournisseur d'e-mail est inaccessible — et surtout, ce qui arrive au reste du produit pendant que l'e-mail est en panne.
Dépendance SMS / numéro de téléphone
De nombreux services se rabattent sur les SMS pour la vérification lorsque l'e-mail est en panne. Nous avons pris cela en compte et avons décidé de ne pas le faire. Demander un numéro de téléphone ajoute une catégorie de données personnelles que nous ne voulons pas collecter, expose les clients aux attaques de SIM-swap et ajoute une dépendance supplémentaire vis-à-vis d'un fournisseur. Nous avons choisi une meilleure voie.
Pannes du plan de contrôle opérationnel
Les outils que nous utilisons pour gérer notre propre infrastructure peuvent eux-mêmes tomber en panne : le maillage d'orchestration, la couche de coordination, le pipeline de déploiement. Chacun est une relation fournisseur qui peut échouer. Nous avons considéré les conséquences de chacun et avons progressivement réduit notre dépendance vis-à-vis des plans de contrôle exploités par des fournisseurs.
Bugs logiciels
La cause la plus probable d'une panne uniforme est un bug dans notre propre logiciel, déployé partout à la fois. Aucune distribution géographique n'aide lorsque chaque copie en cours d'exécution plante de la même manière. Nous avons pris cela en compte et avons conçu nos pratiques de déploiement — déploiements progressifs (canary), retour arrière rapide, interrupteurs d'urgence — en conséquence.
Actions de fournisseurs au niveau du compte
Suspension de compte, litiges de facturation, blocages réglementaires et application des conditions d'utilisation peuvent désactiver toute relation fournisseur en un seul coup. Nous avons considéré les conséquences de la résiliation unilatérale de chaque relation fournisseur critique et avons conçu une protection contre le verrouillage par fournisseur unique à chaque niveau.
Défaillances corrélées
Certains événements provoquent la panne de plusieurs éléments à la fois — une coupure majeure de câble affectant plusieurs routes, une attaque coordonnée sur plusieurs services, une catastrophe naturelle frappant à la fois un système primaire et ce qui était censé être sa sauvegarde. Nous avons spécifiquement considéré les modes de défaillance corrélés : la défaillance de "la sauvegarde" au moment même où le primaire est également en panne. L'architecture est conçue de manière à ce qu'aucun événement unique ne provoque la panne du primaire et de son basculement.
Dépendances catastrophiques de données personnelles
Les clients du coffre-fort ne devraient pas avoir à choisir entre la sécurité et la récupérabilité de leurs propres données. Nous avons considéré chaque endroit où le coffre-fort de l'utilisateur dépend de quelque chose d'autre qu'il pourrait perdre : son numéro de téléphone, son compte e-mail, un appareil unique, un mot de passe unique. Chacun de ces éléments a été soit éliminé, soit contourné par conception.
Joignabilité de l'équipe opérationnelle
Une entreprise de coffre-fort doit être joignable par sa propre équipe en cas d'incident. Nous avons considéré ce qui arrive à notre capacité de réponse lorsque l'Internet autour de nos propres opérateurs se dégrade.
Horizon cryptographique
La cryptographie n'est pas statique. Nous avons considéré le chemin de migration à long terme pour chaque primitive cryptographique dont nous dépendons, y compris le post-quantique.
Ce contre quoi nous ne prétendons pas protéger
Nous sommes explicites sur les limites de ce que l'ingénierie d'infrastructure peut accomplir.
Mettrait l'Internet mondial hors service pendant des jours. Rien que l'infrastructure ne puisse faire n'aide ; les clients ne peuvent de toute façon pas accéder à quoi que ce soit.
Une classe d'événements contre laquelle aucune infrastructure commerciale ne peut se défendre unilatéralement.
Nous sommes honnêtes à ce sujet — et nous concevons tout le reste pour qu'il soit résilient en partant du principe qu'ils ne se produiront pas.
Détails de l'architecture sous NDA.
La liste ci-dessus est ce que nous avons considéré. Le détail de la manière dont chaque défense est conçue — la topologie spécifique, les choix de fournisseurs, les procédures de basculement, les protocoles cryptographiques — est partagé avec les clients d'entreprise sous NDA, avec leurs équipes de sécurité, dans leur processus d'approvisionnement.