La durabilité ACID est l'une des quatre propriétés fondamentales des transactions dans les systèmes de gestion de bases de données (SGBD). L'acronyme ACID signifie Atomicité, Cohérence (Consistency), Isolation, Durabilité. Voici la définition précise de la durabilité dans ce contexte :

Durabilité (Durability)
La durabilité garantit que, une fois qu'une transaction est validée (commit), ses effets persistent de manière permanente, même en cas de défaillance du système (panne matérielle, coupure de courant, crash logiciel, etc.).

Exigences concrètes :

Persistance des données :

Les modifications apportées par une transaction validée doivent être enregistrées de manière permanente sur un support de stockage non volatile (disque dur, SSD, etc.).
(Exemple : si un virement bancaire est validé, le solde mis à jour ne doit pas disparaître après un redémarrage du serveur.)

Résistance aux pannes :

Le SGBD doit utiliser des mécanismes pour survivre aux défaillances, comme :
Journalisation (Write-Ahead Logging, WAL) : les modifications sont d'abord écrites dans un journal (log) durable avant d'être appliquées aux fichiers de données. En cas de crash, le journal permet de rejouer (redo) les transactions validées et d'annuler (undo) celles non terminées.
Points de contrôle (checkpoints) et sauvegardes : pour borner le volume de journal à rejouer et réduire le temps de récupération.
Synchronisation forcée (fsync) : les enregistrements de journal sont physiquement écrits sur le disque avant de confirmer le commit.

Garantie post-validation :

Une fois que le SGBD renvoie un accusé de réception (« commit successful ») à l'application, la transaction ne peut pas être perdue, même si le système tombe en panne immédiatement après.

Exemple concret :
Scénario : un utilisateur effectue un virement de 100 € du compte A vers le compte B.
La transaction est validée (commit).
Une panne électrique survient 1 seconde après.
Comportement attendu : après redémarrage, le SGBD restaure l'état des comptes A et B à partir du journal, et les 100 € sont bien transférés.

Mécanismes techniques sous-jacents (non exhaustifs) :
Journalisation WAL : règle selon laquelle aucune modification n'est considérée comme validée avant que son enregistrement de journal ne soit durable.
Double écriture (double-write buffer) : utilisée dans certains moteurs (par ex. InnoDB) pour éviter les pages partiellement écrites (torn pages).
Stockage non volatile : écriture sur supports persistants avec désactivation ou maîtrise des caches d'écriture volatils.

Limites et nuances :
La durabilité absolue n'existe pas en pratique (destruction physique du support, perte simultanée des réplicas). Elle est donc relative à un modèle de pannes et à la fiabilité du matériel.
Certains SGBD offrent des niveaux de durabilité configurables (ex. : PostgreSQL avec synchronous_commit = off, gains de performance au prix d'un risque de perte des dernières transactions validées en cas de crash).
Dans les systèmes distribués, la durabilité est souvent répliquée (commit synchrone sur plusieurs nœuds) ou au contraire relaxée (écriture asynchrone) pour favoriser la latence ou la disponibilité.

Repères historiques :
Le concept de transaction et ses propriétés (atomicité, cohérence, durabilité) ont été formalisés par Jim Gray (prix Turing 1998), notamment dans The Transaction Concept (1981) ; l'acronyme ACID a été introduit par Theo Härder et Andreas Reuter en 1983. La récupération après panne est classiquement implémentée par l'algorithme ARIES (Mohan et al., IBM), utilisé notamment dans DB2 ; PostgreSQL, lui, s'appuie sur un WAL de type redo-only combiné au MVCC (sans phase d'undo physique).