Mesurer le stockage sans lire vos fichiers

Une suite qui promet un quota de stockage unifié — « X Go, toutes applications confondues » — se crée une obligation technique : mesurer ce que chacun stocke, partout, en permanence. Et une suite qui promet la confidentialité se crée une obligation inverse : ne pas regarder. Le plan de contrôle de stockage de comet vit exactement sur cette crête. Son principe tient en une phrase : on compte des octets, on ne lit jamais le contenu. Voici comment ce principe devient une architecture.

Des deltas d'octets, pas des fichiers

Le service de métrologie de comet ne parcourt jamais les données des applications. Ce sont les applications qui rapportent — et elles ne rapportent que des deltas d'octets : « +2 Mo pour cet utilisateur dans Drive », « −500 Ko dans Mail ». Un événement d'usage ressemble à ceci :

{
  "app": "drive",
  "userId": "u-102394",
  "deltaBytes": 2097152,
  "idempotencyKey": "drive:upload:ck2f8a…:v1"
}

Quatre champs, et c'est tout. Pas de nom de fichier, pas de chemin, pas de type MIME, pas d'aperçu. Le plan de contrôle sait qu'un utilisateur a écrit deux mébioctets dans Drive ; il ne saura jamais si c'était un contrat, une photo ou une sauvegarde de jeu. Cette ignorance n'est pas une politesse : c'est une propriété du contrat d'interface. Le champ pour indiscret n'existe pas.

L'idempotence, ou comment compter juste dans un monde qui rejoue

Le champ le plus important de cet événement est idempotencyKey. Les systèmes distribués rejouent : un timeout suivi d'une nouvelle tentative, un service qui redémarre et renvoie sa file. Sans protection, chaque rejeu fausserait les compteurs — et un compteur d'octets faux, c'est un quota injuste.

Chaque événement porte donc une clé d'idempotence dérivée de l'opération métier qui l'a produit. À l'ingestion, le service applique une règle unique : une clé déjà vue est ignorée. Sous cette garde, l'écriture est double et atomique — l'événement est ajouté à un registre (le journal de tout ce qui a été compté, qui rend les totaux auditables et recalculables) et le total de l'utilisateur pour l'application est mis à jour par upsert dans la même transaction. Une application peut donc renvoyer ses deltas autant de fois que nécessaire : le total, lui, ne bouge qu'une fois.

La réconciliation : converger vers la vérité des apps

Même idempotent, un système de comptage par deltas dérive : un événement jamais émis à cause d'un crash au mauvais moment, un bug qui compte une opération à moitié. Plutôt que de prétendre que cela n'arrive pas, le plan de contrôle l'assume : la vérité n'est pas dans les compteurs, elle est dans les applications.

Périodiquement, le service de métrologie interroge chaque application sur un point interne qui expose son usage réel — la somme des octets qu'elle stocke effectivement, par utilisateur. Si le total compté s'écarte de cette vérité, le service écrit des événements d'ajustement — par le même canal idempotent que le reste — pour faire converger les compteurs. La dérive n'est pas niée, elle est bornée : entre deux réconciliations au pire, puis résorbée.

Le quota en trois temps : réserver, écrire, confirmer

Compter ne suffit pas ; il faut aussi décider — accepter ou refuser une écriture. Or une vérification naïve (« lire le total, comparer, écrire ») laisse passer les dépassements dès que deux téléversements arrivent en même temps. Le quota de comet fonctionne donc en trois temps :

1. réserver    → l'app demande l'admission des octets entrants ;
                 le service pose une réservation (avec TTL)
2. écrire      → l'app écrit réellement les données
3. confirmer   → la réservation devient un delta compté
   (ou libérer → l'écriture a échoué, la réservation tombe)

La règle d'admission tient compte de tout : usage global de l'utilisateur toutes applications confondues, plus les réservations actives, plus les octets entrants — le tout devant rester sous le quota. Deux téléversements simultanés ne peuvent plus se faufiler ensemble sous la barre : le premier réserve, le second voit la réservation.

Et si le client disparaît entre la réservation et la confirmation — onglet fermé, connexion perdue ? La libération est automatique : le code appelant libère en cas d'échec, et la réservation porte de toute façon une durée de vie au-delà de laquelle elle expire d'elle-même. Un téléversement abandonné ne peut pas confisquer du quota indéfiniment.

Refuser proprement : le 507 structuré

Quand le quota est atteint, le refus est net et outillé : l'application reçoit un 507 Insufficient Storage — le code HTTP prévu pour ce cas — accompagné d'un corps structuré indiquant le quota, l'usage courant et les octets demandés. L'interface peut alors dire la vérité utile : « il vous reste 120 Mo, ce fichier en fait 300 », plutôt qu'un « une erreur est survenue » générique.

Deux règles de bon sens complètent le dispositif. Les suppressions ne sont jamais bloquées : un utilisateur au-dessus de son quota peut toujours faire de la place — un système qui empêche de supprimer pour cause de dépassement serait une nasse. Et le refus s'applique avant d'écrire, jamais après : on ne stocke pas d'abord pour réclamer ensuite.

Fail-open : la disponibilité prime

Dernière décision, la plus discutée : que faire quand le service de métrologie est injoignable ? Refuser toutes les écritures « par prudence » ? Ce serait transformer un service de comptage en point de défaillance unique pour toute la suite — une panne de la métrologie empêcherait de sauvegarder un document.

comet fait le choix inverse, en connaissance de cause : fail-open. Si le service ne répond pas, l'écriture procède. Le risque accepté est borné et rattrapable : un dépassement temporaire de quota, résorbé dès que le service revient — les deltas mis en file sont livrés, la réconciliation corrige le reste. L'asymétrie justifie le choix : un octet de trop se recompte, un document jamais sauvegardé est perdu. Entre un décompte momentanément approximatif et une suite momentanément inutilisable, nous choisissons le premier — et le registre garantit qu'« approximatif » ne dure jamais.

Ce que le plan de contrôle ne saura jamais

Reprenons de l'altitude. Le service de métrologie de comet connaît, pour chaque utilisateur et chaque application, un nombre d'octets — et l'histoire auditée de ce nombre. Il ne connaît ni un nom de fichier, ni un objet, ni un octet de contenu : les données restent dans les applications, le plan de contrôle ne voit que des compteurs.

C'est le principe de minimisation appliqué à l'architecture : le système qui décide (admettre ou refuser une écriture) ne reçoit que ce dont sa décision a besoin — des nombres. Un quota unifié n'exige pas un œil qui voit tout. Il exige un comptable rigoureux, idempotent, réconcilié — et aveugle au contenu. C'est exactement ce que nous avons construit.