Parce qu'une opération métier implique souvent PLUSIEURS écritures qui doivent réussir ENSEMBLE : sans transaction, une interruption au milieu (panne, coupure réseau, erreur) laisse les données dans un état INCOHÉRENT — le pire défaut possible en gestion. Le problème concret : (1) Enregistrer une commande, c'est souvent : créer l'en-tête de commande, créer les lignes, décrémenter le stock, mettre à jour le total du client. Quatre écritures pour UNE opération métier. (2) Sans transaction, si le poste plante (ou le réseau tombe) après la deuxième écriture, vous obtenez une commande sans lignes, ou un stock débité sans commande correspondante. (3) Ces incohérences sont SILENCIEUSES : rien ne signale l'anomalie, l'application continue de fonctionner, et le problème se découvre des semaines plus tard lors d'un inventaire ou d'un contrôle comptable. (4) Les corriger exige alors une analyse manuelle des données — long, coûteux et risqué. Ce que garantit une transaction : (1) TOUT OU RIEN : soit toutes les écritures sont validées, soit AUCUNE ne l'est. Il n'existe pas d'état intermédiaire durable. (2) Concrètement : on ouvre la transaction, on effectue les écritures, puis on VALIDE (tout devient définitif) ou on ANNULE (tout est défait, la base revient à son état initial). (3) En cas d'incident, le moteur défait automatiquement ce qui n'a pas été validé. (4) La base reste donc TOUJOURS dans un état cohérent. Le rôle en MULTI-UTILISATEURS : (1) Les transactions gèrent aussi l'ISOLATION : les modifications en cours d'un utilisateur ne perturbent pas ce que voient les autres tant qu'elles ne sont pas validées. (2) Sans cela, un utilisateur pourrait lire des données à moitié écrites par un autre — et prendre des décisions sur des informations transitoires. (3) Elles s'articulent avec les BLOCAGES, qui empêchent deux modifications simultanées du même enregistrement de s'écraser mutuellement. Les bonnes pratiques : (1) Identifiez les opérations MÉTIER indivisibles : celles où plusieurs écritures n'ont de sens qu'ensemble (commande + lignes + stock ; écriture comptable au débit et au crédit ; transfert entre deux comptes). (2) Encadrez-les par une transaction. (3) Gardez les transactions COURTES : une transaction ouverte maintient des verrous et peut bloquer les autres utilisateurs. N'ouvrez jamais une transaction en attendant une saisie utilisateur — c'est une erreur classique qui fige l'application pour tout le monde. (4) Gérez les ERREURS : en cas d'échec, annulez explicitement et informez clairement l'utilisateur du sort de son opération. (5) Testez les scénarios d'interruption (coupure en cours de traitement) : c'est le seul moyen de vérifier que votre gestion fonctionne. (6) Les transactions accélèrent aussi souvent les traitements par LOT (regroupement des écritures). En résumé : les TRANSACTIONS sont indispensables parce qu'une opération métier se traduit rarement par une seule écriture — enregistrer une commande implique l'en-tête, les lignes, le stock, parfois le total client — et que ces écritures n'ont de sens qu'ENSEMBLE. Sans transaction, une panne, une coupure réseau ou une erreur survenant au milieu laisse la base dans un état INCOHÉRENT (commande sans lignes, stock débité sans commande), défaut d'autant plus grave qu'il est SILENCIEUX : rien ne l'annonce, l'application continue, et l'anomalie se découvre des semaines plus tard lors d'un inventaire ou d'un contrôle comptable, avec une correction manuelle longue et risquée. La transaction garantit le TOUT OU RIEN : on ouvre, on écrit, puis on valide (tout devient définitif) ou on annule (tout est défait) — et en cas d'incident, le moteur défait automatiquement ce qui n'a pas été validé. En multi-utilisateurs, elle assure en outre l'ISOLATION, empêchant les autres de lire des données à moitié écrites. Les règles pratiques : encadrez les opérations indivisibles, gardez les transactions COURTES (jamais ouvertes en attendant une saisie utilisateur, sous peine de bloquer tout le monde), gérez explicitement les erreurs et testez les scénarios d'interruption.

Par les mécanismes de BLOCAGE (verrouillage) : soit on empêche la modification concurrente (blocage pessimiste), soit on détecte au moment d'enregistrer que la donnée a changé entre-temps (approche optimiste) — l'essentiel étant qu'aucune modification ne soit écrasée SILENCIEUSEMENT. Le problème (la « mise à jour perdue ») : (1) Deux utilisateurs ouvrent la fiche du même client à 10h00. (2) Le premier modifie le téléphone et enregistre à 10h02. (3) Le second modifie l'adresse et enregistre à 10h03 — mais il travaillait sur la version de 10h00. (4) Résultat : sa sauvegarde écrase la modification du premier. Le téléphone revient à son ancienne valeur, et personne ne s'en aperçoit. C'est la « mise à jour perdue », un classique du multi-utilisateurs — silencieux, donc dangereux. Approche 1 — le blocage PESSIMISTE : (1) Principe : dès qu'un utilisateur ouvre l'enregistrement pour modification, il est VERROUILLÉ. Les autres ne peuvent pas le modifier (ils sont avertis, éventuellement en lecture seule). (2) Avantage : le conflit est impossible, la règle est simple à comprendre. (3) Inconvénients : si l'utilisateur part déjeuner en laissant la fiche ouverte, l'enregistrement reste bloqué. Il faut prévoir des libérations automatiques (délais) et gérer les blocages orphelins (poste éteint brutalement). (4) Adapté quand : les modifications concurrentes sont fréquentes et les conflits coûteux. Approche 2 — l'approche OPTIMISTE : (1) Principe : on laisse tout le monde travailler, mais AU MOMENT D'ENREGISTRER on vérifie que l'enregistrement n'a pas été modifié entre-temps (par comparaison avec la version lue, ou via un indicateur de version). (2) Si la donnée a changé, on AVERTIT l'utilisateur au lieu d'écraser. (3) Avantage : aucun blocage prolongé, meilleure fluidité — adapté quand les conflits sont rares. (4) Inconvénient : l'utilisateur peut perdre sa saisie s'il doit recommencer ; il faut donc soigner le traitement du conflit. Que faire lors d'un conflit détecté : (1) INFORMER clairement : « Cette fiche a été modifiée par un autre utilisateur pendant votre saisie. » Ne jamais écraser en silence. (2) Proposer une action : recharger la version actuelle, comparer, forcer sa version en connaissance de cause. (3) Idéalement, indiquer QUI a modifié et QUAND. (4) Si possible, éviter que l'utilisateur perde tout son travail. Les bonnes pratiques générales : (1) Ne bloquez que le NÉCESSAIRE et le moins longtemps possible : verrouiller au moment d'enregistrer plutôt que dès l'affichage réduit énormément les conflits. (2) Utilisez les TRANSACTIONS pour les opérations composées. (3) Réduisez la durée d'ouverture des fiches en modification. (4) TESTEZ à plusieurs : ces défauts n'apparaissent JAMAIS lors d'un test monoposte — c'est pourquoi ils arrivent en production. Simulez délibérément des accès simultanés. (5) En Client/Serveur, le moteur gère nativement une bonne part de ces mécanismes : appuyez-vous dessus. (6) Pour les données critiques, tracez les modifications (qui, quand, quoi) : cela facilite l'arbitrage en cas de litige. En résumé : gérez les modifications concurrentes par un mécanisme de BLOCAGE explicite, car le risque réel est la « mise à jour perdue » — deux utilisateurs ouvrent la même fiche, et le second écrase silencieusement les modifications du premier sans que personne ne s'en aperçoive. Deux stratégies existent. Le blocage PESSIMISTE verrouille l'enregistrement dès l'ouverture en modification : le conflit devient impossible, mais il faut gérer les verrous oubliés (utilisateur parti déjeuner, poste éteint) par des libérations automatiques. L'approche OPTIMISTE laisse chacun travailler et VÉRIFIE au moment d'enregistrer que la donnée n'a pas changé entre-temps, en avertissant l'utilisateur le cas échéant — plus fluide quand les conflits sont rares, mais il faut soigner le traitement du conflit pour ne pas faire perdre la saisie. Dans tous les cas, la règle absolue est de ne JAMAIS écraser en silence : informez clairement (idéalement en indiquant qui a modifié et quand) et proposez une action. Réduisez les conflits en verrouillant le plus tard et le moins longtemps possible, utilisez les transactions pour les opérations composées, et surtout TESTEZ À PLUSIEURS : ces défauts n'apparaissent jamais en test monoposte, c'est précisément pour cela qu'ils surgissent en production.