L'état courant et le registre : les deux mémoires d'un système d'exploitation d'entreprise

Une gestionnaire de crédit ouvre la boîte d’approbation. Un agent a proposé de libérer une commande bloquée : le client a réglé deux factures en retard ce matin, l’encours est revenu sous la limite, la proposition cite les deux paiements. Elle approuve. Trois mois plus tard, le client conteste des frais, et l’auditeur pose une question simple : que savait le système à 9 h 14 ce jour-là, et qui a décidé ?

Les modules ne peuvent répondre à la première moitié que si rien n’a été écrasé depuis. La table des paiements montre le solde d’aujourd’hui, pas celui de ce matin-là. La commande affiche son statut actuel, pas celui que l’agent a vu. La proposition elle-même a disparu de la boîte, puisqu’on y a donné suite. Un système dans lequel les agents proposent et les personnes approuvent produit des décisions à un rythme où « nous allons reconstituer » cesse d’être une réponse. Il lui faut une seconde mémoire.

Pourquoi le magasin des modules ne peut pas être la seule mémoire

Le magasin de données sous les modules est construit pour une chose : changer l’état courant de l’entreprise en toute sécurité. Une commande, un verrou, une transaction, des index réglés pour trouver vite une seule ligne. C’est exactement ce qu’il doit être, et rien ici ne propose de le remplacer.

La superintelligence pose aux mêmes données d’autres questions, et chacune met ce magasin à l’épreuve.

Lire à grande échelle. Une proposition sur un client lit des milliers de lignes dans les commandes, les factures, les paiements et les réclamations. Un modèle qui évalue le risque de livraison sur tout le carnet de commandes en lit des millions. Des lectures de cette taille entrent en concurrence avec les transactions que le magasin existe pour protéger.

L’historique. Le magasin contient ce qui est vrai maintenant. La plupart des questions posées à un agent portent sur un changement : quelle était la limite quand la commande a été acceptée, depuis combien de temps ce fournisseur dérive, si la marge de ce client baisse depuis trois trimestres. Un magasin qui écrase ne peut pas y répondre ; une mémoire qui conserve les versions le peut.

Toute l’entreprise à la fois. La commande est dans le commerce, la réclamation dans le service client, la palette dans les stocks, l’arrêt dans les opérations. Dans un seul système d’exploitation, ils partagent un modèle de données, ce qui est le but du système. Ils n’ont pas pour autant un endroit commode où tout lire d’un coup sans toucher aux tables dans lesquelles les modules écrivent.

Ce que l’agent a vu. Une proposition n’est défendable que si les données dont elle est issue peuvent être montrées plus tard, exactement telles qu’elles étaient. Cela demande un instantané, pas une valeur courante.

La réponse de Hurukan tient en deux mémoires sous une seule ontologie : l’état courant, que les modules changent seconde après seconde, et le registre, historique immuable et versionné de chaque événement, de chaque proposition et de chaque décision. La couche Données qui porte les deux est en construction ; voici comment elle est conçue.

De quoi le registre est fait

Le registre n’est pas un produit. Ce sont trois décisions, prises chacune une fois.

Les formats de fichier sont les briques. Chaque événement et chaque instantané d’une table est écrit dans des fichiers d’un format ouvert. Les lignes qui circulent entre modules et connecteurs partent en Apache Avro, où le schéma voyage avec les données et où la compatibilité entre l’écrivain et le lecteur est une règle formelle. Les données qui reposent et se lisent par colonne partent en Apache Parquet, où une question sur deux colonnes parmi des millions de lignes ne touche que deux colonnes. Quel format sert quelle tâche est le sujet de Parquet et Avro : l’événement entre modules et le registre que lit la superintelligence.

Un format de table est le plan. Des fichiers seuls forment un tas. Un format de table — Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon — tient les métadonnées qui disent quels fichiers composent une table à un instant donné, quel est son schéma et comment elle a changé. Comme les fichiers eux-mêmes ne sont jamais modifiés, chaque version de la table reste lisible : c’est de là que vient le voyage dans le temps (time travel), et avec lui la réponse à « qu’a vu l’agent à 9 h 14 ». Choisir entre eux, c’est choisir une piste d’audit, et ce choix est fait dans La piste d’audit est une table : Delta Lake, Iceberg ou Hudi.

Un catalogue dit où est la vérité. Quelque chose doit tenir le pointeur vers la version courante de chaque table et décider qui peut la lire. Ce catalogue, et non les fichiers, est l’endroit où la souveraineté se gagne ou se perd. Il tourne sur l’infrastructure que l’entreprise choisit, et la couche sécurité et souveraineté le traite comme une partie du patrimoine propre de l’entreprise.

Comment voyage un événement

Un module change l’état courant : un paiement est comptabilisé. Le même changement est publié comme événement sous un contrat — un schéma nommé, avec une version. Un pipeline dépose l’événement dans le registre comme nouveau fichier sous les métadonnées de la table, dans le délai que le métier a demandé. Une fois par nuit suffit pour un rapport de marge. Il faut des minutes pour une décision de crédit. Il faut des secondes pour une file de travail en atelier, et les secondes coûtent plus que les minutes, raison pour laquelle le niveau est une décision et non un réglage par défaut.

Le registre s’écrit dans un seul sens. Les agents et la superintelligence le lisent, avec l’ontologie qui leur dit ce que signifient une « commande bloquée » ou un « fournisseur qui dérive ». Ils n’y écrivent pas directement. La sortie d’un agent est une proposition qui arrive dans la boîte d’approbation ; une personne approuve ; le module change l’état courant ; le changement est publié comme événement ; l’événement entre dans le registre. Le journal des décisions est lui-même une table du registre, avec la proposition, ses sources, l’approbateur et l’heure.

Ce que l’agent a vu, et qui a décidé

Cette boucle est ce qui rend la question de l’auditeur soluble. Le registre à 9 h 14 est une version des tables, pas une reconstitution. La proposition est une ligne avec les identifiants des lignes qu’elle a lues. L’approbation est une ligne avec le nom d’une personne. Rien dans la chaîne ne dépend de la mémoire de quelqu’un.

La même propriété sert ceux qui construisent le système. Quand une nouvelle version d’un agent est évaluée, une journée d’événements peut être rejouée depuis le registre contre elle et ses propositions comparées à celles que les personnes ont réellement approuvées. Le registre est le jeu d’évaluation.

Les agents construisent la couche Données, sous approbation

Hurukan est construit et étendu par des agents, et la couche Données ne fait pas exception. Un agent rédige le pipeline qui dépose un nouveau type d’événement. Un agent propose le changement de schéma quand un module gagne un champ, et le contrôle de compatibilité contre le registre de schémas s’exécute avant que quiconque lise la proposition. Un agent planifie le compactage des petits fichiers et l’expiration des anciens instantanés. Chacune de ces actions est une proposition avec un diff et un résultat de test, et une personne l’approuve. L’approbation est enregistrée comme toute autre.

Ce qui reste aux personnes est ce qui ne peut être annulé ni déduit : le contrat entre modules, la rétention de l’historique et la suppression des données d’une personne, le choix du format et du catalogue, et toute montée de version du protocole d’une table qui exclurait un lecteur plus ancien.

Le registre que vous emportez

Chaque pièce du registre est dans un format que d’autres moteurs lisent. Si l’entreprise part, elle part avec son historique : les fichiers, les métadonnées de table et le catalogue, sur sa propre infrastructure. Là où l’entreprise a déjà des outils qui lisent un format — un parc Microsoft, une filiale sous Snowflake — les mêmes fichiers peuvent être exposés dans ce format sans copie, ce qui est le sujet de Un seul registre, lisible par les outils que vous avez déjà. Et là où les agents de domaine ont besoin de l’état courant plutôt que de l’historique — la file de travail, le stock, la boîte d’approbation — un format de table conçu pour les flux garde cet état lisible sans interroger sans cesse le magasin des modules, ce qui est le cas de Paimon.

Un test à faire aujourd’hui

Prenez une décision que votre entreprise a prise le trimestre dernier sur la base d’un rapport : une limite de crédit, un réapprovisionnement, un prix. Essayez de produire les données exactement telles qu’elles étaient le jour de la décision, et le nom de la personne qui l’a prise. Comptez les heures. Ce nombre est le coût d’une mémoire unique, et c’est à cela que sert le registre.