Il y a une quinzaine d'années, ajouter de la capacité de stockage dans une entreprise tenait encore du chantier : commander des baies, découper des volumes, étendre des systèmes de fichiers, surveiller des partitions qui se remplissaient la nuit. Le stockage objet a mis fin à ce régime. Une clé, un conteneur, une API : la capacité est devenue un service, la rétention un paramètre, l'accès une affaire d'application et non plus de chemin réseau. Les équipes infrastructure y ont gagné un confort considérable, et personne ne souhaite revenir en arrière.
StratoFoundry vient de ce monde. Notre travail initial portait sur des services S3, et deux de nos produits actuels appartiennent encore à cet univers : S3Guardian, qui réplique les données entre S3 SaaS, S3 on-premise et sources CIFS/NFS, disponible en version 2.0, et S3Proxy, qui découple les applications des changements d'endpoints. C'est précisément parce que ce monde est le nôtre que nous pouvons dire, sans procès d'intention, où s'arrête son contrat.
Ce que le stockage objet a réglé
Le problème traité par l'objet était réel et massif : l'échelle. Grandir sans réarchitecter, retenir selon des règles configurées, exposer les contenus aux applications par API plutôt que par arborescences partagées. Sur ce terrain, les promesses ont été tenues, et l'industrie entière s'est réorganisée autour de ce modèle.
Un bucket reste pourtant un espace de noms, et une clé une adresse à un instant donné. Le stockage conserve ce qu'on lui demande de conserver, selon la rétention configurée. Il ne sait pas qui a écrit une version, sous quelle politique, avec quels droits, dans quel état du dossier métier porté par l'ERP ou le PLM, ni ce que le SIEM (gestion des événements de sécurité) signalait à ce moment-là. Ces informations existent, mais elles vivent ailleurs, dispersées dans les journaux et les référentiels de chaque application. Ce n'est pas un reproche : cette continuité-là n'a jamais fait partie du contrat.
Ce qu'une clé d'objet ne peut pas dire
Prenons un dossier fournisseur ordinaire : contrat, évaluations, pièces techniques, échanges de validation. Au fil des mois, il traverse un SharePoint, un ERP, un PLM, un coffre S3. Chaque système conserve sa représentation, ses métadonnées, ses journaux. Le jour où un incident ou un audit pose une question de temps et de contexte (que savions-nous, quand, sous quelle règle, avec quel droit), la réponse n'est dans aucun de ces systèmes. Elle est entre eux.
Trois choses manquent alors. Une identité persistante : le dossier comme objet logique, adressable à travers ses états successifs, plutôt qu'une suite de versions sans fil commun. Un contexte opérationnel : acteurs, droits, politiques en vigueur, provenance, restés reliés au contenu. Et une histoire gouvernée : des états horodatés, capturés sous des règles explicites, interrogeables à une date choisie, accompagnés d'éléments de preuve. L'échelle seule ne produit rien de tout cela. Il faut le capturer pendant que les événements se produisent.
Une couche de connaissance au-dessus du stockage
C'est le rôle de la Knowledge Layer (couche de connaissance) portée par KARL Core : relier les objets, leurs états successifs, leur contexte et leurs preuves, sans remplacer les systèmes sources. La source autoritative reste la source de vérité. KARL reçoit des événements et du contexte (fichiers et permissions, états métier de l'ERP ou du PLM, runs d'IA et leurs sources, signaux du SIEM, point de récupération et reçu de la sauvegarde ou du S3) et renvoie des preuves, des états de confiance et des instructions de récupération.
L'architecture visée est volontairement sobre : les contenus et les métadonnées gouvernés restent dans le S3 choisi par le client ; le calcul local (modèle local, vectorisation, intégration) n'intervient que si le cas d'usage l'exige ; les modes managé ou contrôlé par le client (identités, clés, temps de confiance, supervision, mises à jour) se définissent par environnement. Dans le périmètre gouverné, chaque écriture crée un état horodaté ; la rétention suit la politique définie et la capacité S3.
Deux honnêtetés tiennent lieu de promesses.
La mémoire gouvernée commence à l'activation du périmètre : KARL ne reconstitue pas une histoire jamais capturée.
Une recherche temporelle honnête distingue le moment déclaré par le système source du moment de capture, qui ne coïncident pas toujours.
Une donnée utile indique ce qu'elle contient. Une donnée gouvernée permet aussi de retrouver ce qu'elle était, d'où elle vient, quelles règles s'appliquaient et ce qui en a été fait. Lorsque cette connaissance devient interrogeable dans le temps et réutilisable par plusieurs applications, utilisateurs et agents, elle prend la valeur d'une Memory Layer : une mémoire d'exploitation construite dans la durée, sur une même histoire gouvernée.
Historique gouverné, sauvegarde, réplication : trois métiers distincts
La confusion coûte cher, alors autant être précis.
- La réplication maintient des copies synchronisées entre endpoints. Elle sert la disponibilité et la localité ; une écriture corrompue s'y propage aussi fidèlement que les autres.
- La sauvegarde assure une rétention indépendante, des points de restauration et des tests de récupération. La protection des workloads reste aux solutions dédiées ; KARL n'opère pas une plateforme de sauvegarde.
- L'historique gouverné conserve identité, états, contexte et preuves dans le temps. Il permet de retrouver une version, de vérifier son intégrité et sa provenance, puis de sélectionner un état de confiance ; la restauration elle-même est exécutée par un workflow autorisé, souvent celui de la solution de sauvegarde.
Ces fonctions se complètent et aucune ne tient lieu d'autre. Elles partagent aussi une exigence : séparer les identités et les clés, éviter le domaine de panne unique (un seul bucket, un seul compte, un seul domaine d'identifiants), garantir la portabilité de l'historique. Souveraineté et résilience dépendent d'un profil de déploiement, d'hypothèses explicites et de procédures testées.
La résilience est une architecture et des procédures testées, pas un adjectif marketing.
Le stockage objet a réglé l'échelle, et il l'a réglée bien. La question suivante est celle de la continuité : quelle histoire voulons-nous pouvoir interroger dans deux ans, sous quelles règles, au bénéfice de qui ? C'est une question d'architecture autant que de produit, et elle se pose tôt, avant que le périmètre à gouverner ne se soit étendu de lui-même.
KARL Core se valide aujourd'hui dans des pilotes contrôlés et bornés, avec des critères de mesure explicites : qualité de preuve, précision de récupération, effort opérateur. Si ces sujets traversent vos propres architectures, échangeons sur une architecture ou un profil de déploiement : c'est par là que commence un périmètre sérieux.
