--- title: "Un seul registre, lisible par les outils que vous avez déjà : XTable et UniForm" url: "https://hurukan.com/fr/blog/un-seul-registre-lisible-par-vos-outils" description: "XTable et Delta UniForm rendent un registre lisible en Delta, Iceberg ou Hudi sans copie. Ce qu'ils traduisent, ce qu'ils ne traduisent pas." --- # Un seul registre, lisible par les outils que vous avez déjà : XTable et UniForm 16 octobre 2026·4 min de lecture·La rédaction Un ingénieur données vu de dos à un bureau avec deux écrans côte à côte, chacun montrant la même table abstraite bleue et grise dans une disposition différente, un seul câble bleu reliant les deux machines, un open space lumineux flou en arrière-plan L’équipe finance fait tourner ses rapports dans Power BI sur Microsoft Fabric. Une filiale rachetée l’an dernier fait ses rapports dans Snowflake. Les ingénieurs données du groupe préfèrent Trino. Chaque outil lit bien un format de table, donc chacun a sa propre copie du grand livre des ventes, rafraîchie selon son propre calendrier, et la marge trimestrielle existe en trois versions légèrement différentes jusqu’à ce que quelqu’un en choisisse une. Une entreprise n’arrive pas à un nouveau système d’exploitation les mains vides. Elle arrive avec ces outils, ces habitudes et ces copies. Le [registre](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires) de Hurukan est conçu pour être lu par eux sans être copié pour eux. Deux projets rendent cela possible, et comprendre ce qu’ils font et ne font pas est une question de souveraineté, pas de plomberie. ## Pourquoi la traduction est seulement possible Delta Lake, Apache Iceberg et Apache Hudi stockent les données de la même manière : des fichiers Parquet qui ne sont jamais modifiés. Ils diffèrent par les métadonnées écrites à côté de ces fichiers — la liste des fichiers qui composent la table maintenant, le schéma, les partitions, les statistiques. Un format de table est un plan posé sur les briques, et les briques sont communes. Une table écrite dans un format peut donc recevoir un second plan. Rien n’est copié ; un second jeu de métadonnées est écrit en pointant vers les mêmes fichiers, et un moteur qui lit le second format trouve une table là où il en attend une. La couche Données qui porte le registre de Hurukan est en construction, et c’est l’une des propriétés autour desquelles elle est conçue. ## Apache XTable : un traducteur qui tourne à côté de la table [Apache XTable](https://xtable.apache.org/) est un projet en incubation à l’Apache Software Foundation. Il lit les métadonnées d’un format source et écrit celles d’un ou plusieurs formats cibles « sans copier ni déplacer les fichiers de données sous-jacents ». La version courante est 0.4.0-incubating d’août 2026 (vérifié le 21 octobre 2026). Il tourne comme un outil ou une tâche planifiée, avec une synchronisation complète qui reconstruit les métadonnées cibles et une synchronisation incrémentale qui ne reporte que ce qui a changé depuis la dernière exécution. Sa [documentation](https://xtable.apache.org/docs/how-to) est honnête sur les limites : les tables Hudi et Iceberg en disposition merge-on-read ne sont pas prises en charge, ni les tables Delta qui utilisent des vecteurs de suppression. La description que Microsoft fait d’OneLake indique qu’il utilise XTable pour présenter des tables dans plus d’un format, signe utile de la place du projet sur le marché. ## Delta UniForm : un second plan écrit au moment du commit [Delta UniForm](https://docs.delta.io/latest/delta-uniform.html) fait le même travail depuis l’intérieur de Delta Lake. Quand il est activé sur une table, Delta écrit des métadonnées Iceberg (et, en préversion, des métadonnées Hudi) après chaque commit, de façon asynchrone, de sorte qu’un lecteur Iceberg voit la table nativement. Il exige le mappage des colonnes, une version de lecteur d’au moins 2 et une version d’écrivain d’au moins 7, ainsi que la fonction de table `IcebergCompatV2`. Delta 4.3.0 de juin 2026 a ajouté la conversion Iceberg incrémentale atomique (vérifié le 21 octobre 2026). Les limites sont le miroir de celles de XTable : le côté Iceberg ou Hudi est en lecture seule ; les vecteurs de suppression, le type `VOID` et le flux de données de changement ne traversent pas. Dans un parc Microsoft, l’effet est visible dans [OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-iceberg-tables), qui virtualise les tables Delta en Iceberg avec un décalage documenté de quelques secondes à deux minutes, pour des tables de moins de cinq mille commits. Apache XTable Delta UniForm Où il tourne à côté de la table, comme une tâche dans l’écrivain Delta, au commit Formats source Delta, Iceberg, Hudi (et d’autres en 0.4.0) Delta seulement Formats cible l’un des trois Iceberg ; Hudi en préversion Écritures depuis le second côté non non Catalogue et permissions non traduits non traduits ## Ce qui est traduit et ce qui ne l’est pas Les métadonnées sont traduites. La liste des fichiers, le schéma, les partitions, les statistiques. Trois choses ne le sont pas, et chacune est une décision qui reste à l’entreprise. **Le format d’écriture.** Un format reste celui dans lequel on écrit. C’est là que siège le propriétaire de la table, que se fixe la rétention et que s’exécute une suppression au titre du droit de la protection des données. Les autres formats en sont des vues. **Le catalogue.** Un lecteur dans Snowflake ou Fabric doit toujours savoir où est la table et si cette personne peut la lire. Des métadonnées traduites ne portent pas de permissions. Hurukan garde les permissions sur le serveur et le catalogue sur l’infrastructure que l’entreprise choisit, ce qui est la substance de la [couche sécurité et souveraineté](https://hurukan.com/fr/system/securite-et-souverainete). **Les fonctions que l’autre format ne connaît pas.** Une table Delta avec des vecteurs de suppression, ou une table Iceberg lue à travers un format auquel une fonction manque, refusera la traduction ou montrera un résultat différent. Le plan de test d’une telle table la lit à travers chaque format en usage et compare le nombre de lignes, les agrégats et le délai entre une écriture et sa visibilité de l’autre côté. Dans Hurukan, cette suite de tests est quelque chose qu’un agent peut produire à partir du schéma et qu’une personne approuve avant que le second format soit offert à quiconque. ## Dépendance dans les deux sens La crainte habituelle à propos d’un système d’exploitation pour toute l’entreprise est qu’il l’enferme. Le registre y répond de l’intérieur : formats ouverts, fichiers et catalogue sur l’infrastructure de l’entreprise, lisibles par d’autres moteurs. XTable et UniForm y répondent de l’extérieur : les outils que l’entreprise paie déjà continuent de lire le même registre, dans le format qu’ils préfèrent, sans copie à réconcilier. Les intégrations avec Microsoft 365 Copilot et les autres assistants sont prévues, pas actives ; les formats de fichier sous eux sont déjà ouverts. Quel format Hurukan écrit en premier est un choix de catalogue et de parc plutôt que de fonctions, et il est fait dans [La piste d’audit est une table](https://hurukan.com/fr/blog/la-piste-d-audit-est-une-table). ## Un test à faire aujourd’hui Listez les tables qui existent dans plus d’un outil de votre entreprise. Pour chacune, notez quelle copie est celle à laquelle les gens font confiance, et quand les autres ont été rafraîchies pour la dernière fois. Si la seconde colonne est vide, cette table est candidate à un seul registre avec deux plans plutôt qu’à deux tables portant un seul nom. - Apache XTable - Delta UniForm - formats de table - dépendance fournisseur - Microsoft Fabric ## À lire aussi - [Une identité pour les personnes et les agents : qui peut quoi](https://hurukan.com/fr/blog/une-identite-pour-les-personnes-et-les-agents) - [L'état courant et le registre : les deux mémoires d'un système d'exploitation d'entreprise](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires)