Blockchain Tables Oracle : comment prouver qu’une donnée n’a pas été modifiée ?

C’est un scénario que beaucoup d’organisations connaissent : un auditeur ou un responsable conformité exige une preuve et pas une simple explication qu’une donnée confidentielle ou critique stocké dans la BDD n’a pas été modifiée depuis sa création. Une demande légitime, sauf que dans une base Oracle cette preuve n’existe pas par défaut.

Prenons un exemple simple, le même qu’Oracle a choisi pour sa propre documentation : un registre de dépôts bancaires. Un client dépose de l’argent à son agence, on enregistre la date, le montant et l’agence concernée. Puis un jour, lors d’un contrôle interne, on vous demande de prouver que ce dépôt a bien été enregistré à cette date-là, pour ce montant précis, et que rien n’a bougé depuis.

Et c’est là que ça devient compliqué, parce qu’en pratique :

• N’importe quel compte BDD disposant des bons privilèges peut modifier une ligne dans cette table par erreur ou pour de mauvaises raisons.
• Le Unified Auditing d’Oracle trace qui a fait quoi, mais il ne bloque rien.
• Et un trigger qui bloque les modifications n’offre jamais une garantie totale, car un trigger ça se désactive.

Ce qui est demandé aujourd’hui ce n’est plus l’assurance que les données sont intègres, c’est un mécanisme intégré à la base qui rend la falsification impossible, ou au moins immédiatement détectable, et c’est exactement ce que font les Blockchain Tables d’Oracle.

Concrètement, c’est quoi ?

Oubliez la cryptomonnaie. “Blockchain” ici veut juste dire que chaque ligne s’accroche à la précédente.

Une fois qu’une ligne est écrite, elle ne peut plus être modifiée ni supprimée avant la fin d’une période de rétention que vous fixez vous-même. Le mécanisme repose sur une empreinte (un hash) calculée à partir du contenu de chaque ligne, à laquelle s’ajoute l’empreinte de la ligne précédente. Si quelqu’un parvenait à trafiquer une ligne en contournant le SGBD (en allant par ex directement dans les Datafiles) cette empreinte ne correspondrait plus, et l’incohérence se propagerait, visible dans toute la chaîne qui suit.

Les Blockchain Tables, introduites nativement avec Oracle Database 21c, ont été rétroportées vers la version 19c dès la RU 19.10, permettant aux environnements restant sur la version 19c (Long Term Support) de bénéficier de cette fonctionnalité.

Passons à la pratique

Prenons l’exemple d’une table qui enregistre chaque dépôt effectué en agence.

SQL> CREATE BLOCKCHAIN TABLE depots_agence (
    id_depot     NUMBER GENERATED ALWAYS AS IDENTITY,
    agence       VARCHAR2(50) NOT NULL,
    date_depot   DATE NOT NULL,
    montant      NUMBER(10,2) NOT NULL
)
NO DROP UNTIL 0 DAYS IDLE
NO DELETE UNTIL 16 DAYS AFTER INSERT
HASHING USING "SHA2_512" VERSION "v1";  2    3    4    5    6    7    8    9

Table created.

Langage du code : PHP (php)

Quelques précisions sur l’exemple:

• NO DROP UNTIL 31 DAYS IDLE : bloque la suppression de la table tant qu’elle n’a pas été inactive 31 jours. À ajuster selon votre politique de rétention réelle.
• NO DELETE LOCKED verrouille définitivement l’impossibilité de suppression.

Insérer un dépôt

SQL> INSERT INTO depots_agence (agence, date_depot, montant)
VALUES ('AGENCE_CENTRE', DATE '2026-09-01', 4500.00);

COMMIT;  2
1 row created.

Commit complete.
Langage du code : JavaScript (javascript)

Essayer de la modifier

SQL> UPDATE depots_agence
SET montant = 9000.00
WHERE id_depot = 1;  2    3
UPDATE depots_agence
       *
ERROR at line 1:
ORA-05715: operation not allowed on the blockchain or immutable table

Même en possédant les privilèges nécessaires sur la table, la base refuse, et c’est tout l’intérêt.

Pareil pour une suppression

SQL> DELETE FROM depots_agence WHERE id_depot = 1;
DELETE FROM depots_agence WHERE id_depot = 1
            *
ERROR at line 1:
ORA-05715: operation not allowed on the blockchain or immutable table

Vérifier que la chaîne n’a pas été trafiquée

SQL> SET SERVEROUTPUT ON;

DECLARE
verified_rows NUMBER;
BEGIN
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS(
schema_name => ‘FINANCE_AUDIT’,
table_name => ‘DEPOTS_AGENCE’,
number_of_rows_verified => verified_rows
);
DBMS_OUTPUT.PUT_LINE(‘Lignes vérifiées : ‘ || verified_rows);
END;
/

SQL> SQL> Lignes vérifiées : 1

PL/SQL procedure successfully completed.

Si une ligne a été modifiée en dehors du contrôle normal d’Oracle (corruption de fichier, tentative de bidouillage bas niveau), cette procédure le signale immédiatement, avec une erreur explicite.

Regarder le détail du chaînage

SQL> SET LINESIZE 200
SET PAGESIZE 100

COLUMN orabctab_seq_num$       FORMAT 9999          HEADING "Seq"
COLUMN orabctab_creation_time$ FORMAT A35            HEADING "Date creation"
COLUMN orabctab_user_number$   FORMAT 9999999        HEADING "User#"
COLUMN orabctab_hash$          FORMAT A40             HEADING "Hash (tronque)"

SELECT
    orabctab_seq_num$,
    orabctab_creation_time$,
    orabctab_user_number$,
    RAWTOHEX(orabctab_hash$) AS orabctab_hash$
FROM depots_agence
ORDER BY orabctab_seq_num$;

  Seq Date creation                          User# Hash (tronque)
----- ----------------------------------- -------- ----------------------------------------
    1 02-SEP-26 07.55.19.532798 PM +00:00        0 9C55E878F16D55CC49CEB34D831B82F052B30E9C
                                                   D70F825186B1777E1179355AAFEF46F8B74ADE29
                                                   B0D45652AAA80A96AA86A64D8FE415FCB02B7AC2
                                                   EAE9B8BA


SQL>
Langage du code : PHP (php)