Détection et résolution des conflits

1) Ce qu'il faut considérer comme un conflit

Un conflit est une situation où deux ou plusieurs sources de changement revendiquent des états incompatibles d'une même entité, ressource ou invariant.

Syntaxique : modifications croisées d'un seul fichier/clé (merge conflict dans Git, patch-collisions dans Kustomize).
Sémantique : un document correct selon le schéma perturbe l'invariant d'affaires (le montant du débit est ≠ crédit, la limite est dépassée).
Opérationnel/temporel : courses d'écriture/lecture, événements en double, divergence causale.
Domaines : opérations concurrentes sur une ressource (double vente d'un billet, overbook d'un produit).

Le défi : détecter le conflit le plus tôt possible, expliquer sa cause et choisir en toute sécurité l'une des actions : récupération automatique, rétraction, fusion, compensation, escalade.

2) Mécanismes de détection

2. 1 Versance et comparaison des états

ETag/If-Match dans REST, rowversion/xmin dans DB - identification de la mise à jour lost.
3-way merge (base, ours, their) : Met en surbrillance les modifications incompatibles.
Checksum/Hash par champ/document - comparaison bon marché.

2. 2 Marques temporaires et causales

Lamport clock : ordre total « proche du temps ».

2. 3 Invariants et restrictions

Schémas et validateurs (JSON Schema/OpenAPI) : validation syntaxique.
Invariants : unicité, non-négativité, équilibre, règles ACL.
Contrôles d'intégrité : Index FK/UNIQUE/EXCLUSIF, constraints partiels.
Assert's de domaine dans le code/les stratégies (OPA/Kiverno/Conftest).

2. 4 Détection dans les flux d'événements

Idempotency Key/Dedup Store (par exemple Redis/DB avec TTL) : rejet des prises.
Transactional/Exactly-once en streaming : transactional id, producteur epoch, consumer-offset.
Sequence gap detection : sauts, répétitions (n, n + 1, n + 1).

2. 5 Observation et alarme

Prométrie des erreurs/conflits/rétroactions.

3) Stratégies de résolution

3. 1 Entièrement automatique (sécurisé par définition)

CRDT (Conflict-free Replicated Data Types): G-Counter, PN-Counter, OR-Set, LWW-Register, Map/Graph CRDT.

Garantir la convergence sans coordination ; le choix de la sémantique perte/conservation est important.
Opérations commutatives : s'appliquent dans n'importe quel ordre (incréments, annexes de journal).
Idempotent handlers : la répétition ne change pas le résultat (upsert par la clé, put-if-absent).
Fusion optimiste des structures : 'deep merge + policy' avec un ordre déterministe.

3. 2 Semi-automatique (avec politique)

3-way merge + règles de tableau ('replace'append 'uniqueBy (key) | patchBy (key)').
LWW (Last-Write-Wins) : simple mais risque de perdre l'exactitude causale.
Priorités des sources : « Entrée interactive> flig du fichier> défauts ».
Règles commerciales : « si la limite est dépassée - confirmation partielle/compensation ».

3. 3 Coordination

OCC/MVCC (blocage optimiste/polyvalence) : rapprochement des versions, rétrospective.
Verrous pessimistes : 'SELECT... FOR UPDATE ', blocs distribués (Redlock/DB-lock/etcd).
Consensus (Raft/Paxos) : un leader décide de l'ordre ; il y a moins de conflits, le prix c'est la latence.

3. 4 Homme-en-circuit (HITL)

UI pour l'arbitrage manuel (en particulier le contenu, les tarifs, les catalogues).
Pré-promotion de diffa, explication de la politique, boutons : « accepter ours/their », « combiner les champs », « créer une compensation ».

4) Modèles par couches d'architecture

4. 1 API/REST/gRPC

Concurrence optimiste : 'If-Match : <etag>', 409/412 en cas de conflit → le client se rétracte en tenant compte de la nouvelle ETag.
Idempotency-Key dans POST (paiements/commandes).
Sémantique 409 : communiquez la raison et les actions proposées.

4. 2 Entrepôts de données

RDBMS : MVCC (snapshot isolation), indices uniques, indices partiels.
KV/Doc stores : versions/révisions (rev), compare-and-swap (CAS).
Réplication multimaster : appliquez l'horloge de version/CRDT ou « write to leader only » aux entités critiques.

4. 3 Files d'attente/streaming

Exactly-once (pratiquement - « efficace une fois ») : producteur transactionnel + write-to-sink atomique.
Dedup sur consumer : stockage des derniers N id, logique upsert/merge.
Modèle Outbox/Inbox : publication cohérente des événements.

4. 4 Configurations et IaC

3-way merge dans GitOps, policy-gates (OPA/Kyverno) avant application.
Kustomize/Helm : stratégies déterministes de merge et interdiction des « clés inconnues ».
Terraform : plan-diff comme signal de conflit « drift vs desired ».

5) Algorithmes et exemples

5. 1 3-way merge (simplifié)

text resolve(base, ours, theirs):
diff1 = delta(base, ours)
diff2 = delta(base, theirs)
if independent(diff1, diff2): return apply(base, diff1 ⊕ diff2)
if conflictsOnlyInArrays: return arrayPolicyMerge(...)
else:
return CONFLICT with hunks

5. 2 OCC pour REST Ressource

http
Client reads
GET /accounts/42 -> ETag: "v17", body: {balance: 100}

Trying to write off
PUT /accounts/42
If-Match: "v17"
{balance: 50}

If someone has managed before
HTTP/1. 1 412 Precondition Failed
{error: "version_mismatch", currentEtag: "v18"}

Le client relit, applique le delta à l'état actuel et répète.

5. 3 Conflit sémantique (invariant)

pseudo on Debit(accountId, amount):
current = read(accountId)
if current. balance - amount < 0:
return REJECT ("insufficient _ funds") # write early detection (accountId, version = current. version+1, balance=current. balance - amount)

5. 4 CRDT : OR-Set (croquis)

Les éléments sont ajoutés avec un tag unique, la suppression - par tag spécifique.
Le conflit « add vs remove » est résolu grâce aux tags : remove supprime uniquement les add-tags visibles.

6) Politique de résolution : comment formaliser

1. Ordre des sources (chaîne prioritaire).

2. Stratégies par type de données : scalaires/objets/matrices/multimédia.

3. Modèle causal : Utilisez-vous des versions, Lamport, clocks vectoriels.

4. La sémantique de la perte : ce qui peut être perdu avec LWW, où un consensus est nécessaire.

5. Fenêtres temporelles : TTL pour la déduplication, fenêtres d'idempotence.

6. Escalade : lorsque le permis auto est interdit, les exigences d'UI/approval.

7. Compensation : Stratégie SAGA « cancel/compensate » pour le réaménagement des invariants.

7) Métriques et SLO

conflicts_total{type} est la fréquence par type.
conflicts_resolved_auto_ratio est la part des permis auto.
mean_time_to_resolution est le délai moyen avant le règlement.
lost_update_incidents - incidents de mises à jour perdues.
idempotency_hit_rate est la proportion de clés Idempotency qui ont fonctionné.
divergence_depth est la profondeur de divergence des répliques (vecteurs de version).

Exemple SLO : « ≥ 99 % des conflits syntaxiques sont résolus automatiquement en ≤ 5 s, sémantique en ≤ 15 min avec HITL ».

8) Scénarios pratiques

8. 1 Paiements

Clé : Idempotence (Idempotency-Key), OCC sur la balance, SAGA pour les étapes réversibles.
Conflit : double prélèvement → déduction + vérification de la version du bilan → compensation partielle.

8. 2 Inventaire/billets

Options : verrouillage pessimiste des emplacements/emplacements ; une réservation optimiste avec TTL expirant ; file d'attente « compare-and-reserve ».

8. 3 Contenus/catalogues

3-way merge + HITL : l'éditeur sélectionne le total ; Règles auto pour les champs « sécurisés » (étiquettes SEO n'affectant pas le prix).

8. 4 GitOps/Kubernetes

Rendu et validation avant application ; reject on unknown keys; interdiction de « --force » sans rhubarbe.
Drift-détection et policy-enforced retour.

9) Anti-modèles

LWW partout : simplicité au prix d'une perte de causalité.
Retraits cachés sans idempotence : doublons en forme d'avalanche.
Absence de politique de tableau explicite : perte « silencieuse » des points de configuration.
Mutex mondiaux au-dessus des réseaux : SPOF et verrous de longue durée.
Rémunération « aveugle » sans vérification des causes : conflits répétés.

10) Chèque de mise en œuvre

• Identifiez les types de conflits dans le domaine et les invariants.
• Sélectionnez le mécanisme de versionalité (ETag/xmin/vector clock).
• Inclure l'idempotence dans les POST/commands critiques.
• Définissez une stratégie de merge par type de données (scalaires/tableaux/objets).
• Activer les validateurs de schéma et les vérifications de domaine jusqu'à commit.
• Ajustez les métriques des conflits et des alarmes.
• Pour les entités critiques, le leader/consensus, ou CRDT.
• Travailler sur HITL-flow et UX (diff, commentaires, journal d'audit).
• Documenter le SLO et les procédures de rémunération (SAGA).

11) FAQ

Q : Quand choisir le CRDT et quand le consensus ?
R : Le CRDT convient lorsque la consistance eventuelle est valide et que la haute disponibilité/les enregistrements locaux sont importants. Consensus - pour les données avec des invariants rigides et un ordre strict des opérations (bilans monétaires, droits d'accès).

Q : La LWW est-elle suffisante ?
R : Pour les caches, les métriques et les index secondaires - souvent oui. Pour les données utilisateur et l'argent - presque toujours pas.

Q : Comment choisir une fenêtre de déduplication ?
R : Orientez-vous vers le délai de réapprovisionnement maximum attendu + jitter réseau, ajoutez un stock de 3-5 × p99.

Q : Dois-je toujours faire HITL ?
R : Non. Laisser HITL aux conflits controversés/de valeur ; le reste est automatisé et logé.

12) Résultats

La détection et la résolution efficaces des conflits sont une combinaison de versionalité, d'étiquettes causales, d'invariants et de politiques claires, complétées par des algorithmes appropriés (CRDT/OT/OCC/MVCC/consensus) et l'observabilité. Les systèmes où le conflit est « normal » restent accessibles et prévisibles ; les systèmes où le conflit est une « exception » se brisent au moment le plus inapproprié. Choisissez un modèle, formalisez les règles et mesurez le résultat.