---
title: "La piste d'audit est une table : Delta Lake, Iceberg ou Hudi"
url: "https://hurukan.com/fr/blog/la-piste-d-audit-est-une-table"
description: "Qui a changé quoi, et qu'a vu l'agent en proposant ? Delta Lake, Iceberg et Hudi répondent autrement. Choisissez selon le catalogue et l'infrastructure."
---

# La piste d'audit est une table : Delta Lake, Iceberg ou Hudi

26 septembre 2026·5 min de lecture·La rédaction

Un auditeur vu de dos à une longue table dans une salle de réunion vitrée, trois registres reliés ouverts côte à côte, un ordinateur portable montrant une liste de versions abstraite bleue et grise, une fine bande de lumière bleue le long du bord de la table

Un auditeur pose une question simple sur un paiement approuvé en mars : qu’a vu à l’écran la personne qui l’a approuvé, et qu’avait lu l’agent qui l’a rédigé avant de le proposer ? Dans la plupart des entreprises, la réponse est une reconstitution. Quelqu’un sort une sauvegarde, quelqu’un d’autre fouille une boîte mail, et le résultat est une supposition informée sur un état qui n’existe plus.

Dans Hurukan, chaque proposition d’agent et chaque décision humaine est un événement du registre de l’entreprise, et le registre est conçu pour que cette question ait une réponse nette : une version des tables telles qu’elles étaient à cet instant. Cette propriété ne vient pas des fichiers. Elle vient du format de table posé dessus. Ce texte traite de ce que les trois formats de table ouverts font de la question, et de la manière de choisir entre eux. La couche Données est en construction ; voici comment elle est conçue. Le raisonnement qui justifie d’avoir un registre est dans [l’état courant et le registre](https://hurukan.com/fr/blog/l-etat-courant-et-le-registre-deux-memoires).

## Ce qu’une piste d’audit attend d’une table

Les fichiers du registre ne sont jamais modifiés. Un changement écrit de nouveaux fichiers et une nouvelle version des métadonnées de la table qui dit quels fichiers comptent désormais. Trois choses en découlent pour l’audit.

**Chaque version est adressable.** « La table telle qu’elle était le 12 mars à 14 h 02 » doit être une requête valide, pas une restauration. Dans les formats ci-dessous, c’est le voyage dans le temps (time travel), et c’est le mécanisme derrière « qu’a vu l’agent ».

**Chaque version a un auteur.** Les métadonnées d’un changement doivent porter qui ou quoi l’a fait : une personne, un agent agissant sur approbation d’une personne, ou une tâche système comme le compactage. Hurukan enregistre l’acteur dans son propre journal des décisions, mais la version de la table est la preuve que le journal correspond aux données.

**Les anciennes versions expirent à dessein, pas par accident.** Garder chaque version pour toujours est un coût ; les retirer est une décision de rétention et, pour les données personnelles, de suppression. Cette décision appartient à une personne, et le format de table doit la rendre explicite.

## Trois manières de tenir le plan

Chaque format tient un plan des fichiers qui composent la table. Le plan est là où vit l’audit.

**Delta Lake** tient un journal : un répertoire `_delta_log/` avec un fichier JSON par commit, nommé par un numéro de version à vingt chiffres, chacun listant des actions telles que `add`, `remove`, `metaData` et `protocol`, avec des points de contrôle Parquet périodiques pour qu’un lecteur ne rejoue pas tout l’historique. Le [protocole](https://github.com/delta-io/delta/blob/master/PROTOCOL.md) le définit ; la version courante est [4.4.0](https://github.com/delta-io/delta/releases) (vérifié le 21 octobre 2026). La rétention du journal est de 30 jours par défaut et `VACUUM` de 7 jours, ce qui signifie que le voyage dans le temps ne remonte que jusqu’où ces deux réglages le permettent.

**Apache Iceberg** tient un arbre : un fichier de métadonnées de table pointe vers un instantané, l’instantané vers une liste de manifestes, les manifestes vers les fichiers de données et de suppression avec leurs statistiques. Un commit est une permutation atomique du pointeur vers le fichier de métadonnées, et la permutation se fait dans le catalogue. La [spécification](https://iceberg.apache.org/spec/) est en version 3, avec les vecteurs de suppression, la traçabilité des lignes et le type VARIANT ; la version courante est [1.12.0](https://github.com/apache/iceberg/releases) (vérifié le 21 octobre 2026).

**Apache Hudi** tient une chronologie (timeline) : chaque action sur la table — commit, compactage, nettoyage, retour arrière, restauration — est un instant doté d’un état, et l’historique de la chronologie est archivé dans une structure LSM. Les enregistrements ont des clés et un index, de sorte qu’un changement sur un client touche un groupe de fichiers plutôt qu’une partition. Les tables sont Copy-on-Write ou Merge-on-Read, et la version [1.2.1](https://hudi.apache.org/releases/release-1.2) a ajouté la version de table 9 (vérifié le 21 octobre 2026). La documentation de la [chronologie](https://hudi.apache.org/docs/timeline) décrit les états.

Les trois répondent à l’auditeur. La différence est l’endroit où la réponse est conservée et qui d’autre peut la lire.

## Choisir selon le catalogue, pas selon la liste de fonctions

Les listes de fonctions ont convergé : transactions, voyage dans le temps, évolution de schéma, suppressions ligne par ligne et écritures en flux existent dans chacun. Ce qui n’a pas convergé, c’est l’endroit où la version courante d’une table est déclarée, et c’est là que se décide la souveraineté.

**Pour Delta Lake, c’est le répertoire du journal lui-même**, si bien que tout moteur capable de lire le stockage peut trouver la version courante. En pratique, le catalogue autour est Unity Catalog ou, dans Microsoft Fabric, OneLake, qui stocke ses tables en Delta Parquet selon la [documentation de Microsoft](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview).

**Pour Iceberg, c’est le pointeur du catalogue**, et le catalogue parle une [spécification REST](https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml) ouverte. Apache Polaris, projet de premier niveau depuis février 2026 avec la version 1.8.0, l’implémente ; Snowflake, AWS S3 Tables, le catalogue lakehouse de Google et Databricks lisent et écrivent tous des tables Iceberg à travers elle (vérifié le 21 octobre 2026).

**Pour Hudi, c’est la chronologie sur le stockage**, lue nativement par Spark, Flink, Trino et Presto ; les autres plateformes atteignent en général une table Hudi par traduction de métadonnées.

La question pour une entreprise n’est donc pas « quel format a le meilleur audit ». C’est : sur l’infrastructure de qui tourne le catalogue, quels moteurs doivent lire le registre, et le registre peut-il être emporté si le fournisseur change ? La réponse de Hurukan est que le catalogue et les fichiers tournent sur l’infrastructure que l’entreprise choisit, comme décrit sous [sécurité et souveraineté](https://hurukan.com/fr/system/securite-et-souverainete), et que le format découle des moteurs que l’entreprise possède déjà, et non l’inverse.

## Ce qui reste aux personnes

Les agents sont bons pour la partie mécanique de la couche Données : rédiger le calendrier de compactage, écrire la tâche qui fait expirer les anciens instantanés, proposer un changement de partition quand les requêtes ralentissent. Chacune de ces actions est une proposition dans la boîte d’approbation, avec son raisonnement, et chacune est enregistrée une fois approuvée. Trois décisions ne sont jamais déléguées.

**Rétention et suppression.** Jusqu’où remonte le voyage dans le temps est le même réglage que la durée pendant laquelle une donnée personnelle survit à une demande de suppression. Une personne le fixe par table et le signe.

**Montées de version du protocole.** Activer une fonction de table plus récente peut exclure un moteur plus ancien qui lit encore le registre. Le gain est réel ; le lecteur qui s’éteint aussi. Une personne arbitre.

**Le format lui-même.** Le changer plus tard est possible, comme l’explique le texte suivant de cette série sur [XTable et UniForm](https://hurukan.com/fr/blog/un-seul-registre-lisible-par-vos-outils), mais c’est un projet, pas un réglage.

## Un test à faire aujourd’hui

Prenez une décision du trimestre dernier sur laquelle un auditeur pourrait raisonnablement vous interroger : une limite de crédit relevée, un fournisseur approuvé, une remise accordée. Notez, à partir de vos systèmes seuls, ce que le décideur a vu à cet instant. Comptez les systèmes que vous avez dû ouvrir et les endroits où vous avez dû deviner. Ce compte est la distance entre votre registre actuel et un registre dont la piste d’audit est une table.

-   formats de table
-   Delta Lake
-   Apache Iceberg
-   Apache Hudi
-   piste d'audit

## À 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)