Arrêtez de tout verrouiller : 3 problèmes d’infra où le lock fait plus de mal que de bien

En 2010, Udi Dahan publie Race Conditions Don’t Exist. Son argument : quand deux acteurs entrent en conflit sur une ressource, le réflexe est de verrouiller. Mais souvent, le verrou crée plus de problèmes qu’il n’en résout. Un post de Michaël Azerhad (formateur DDD chez WealCome) m’a remis cet article en tête, et j’ai relu mon vécu DevOps sous cet angle.

Voici trois situations concrètes que j’ai rencontrées, et ce qui marche mieux que le lock.

Problème 1 : le state lock Terraform qui paralyse les équipes

La situation

Plus de 400 applications gérées via Terraform et GitLab CI/CD. Deux développeurs d’équipes différentes poussent une modification sur des ressources qui partagent le même state. Le premier pipeline acquiert le lock. Le second échoue : Error: Error acquiring the state lock. Le développeur attend, relance, le lock est toujours là. Il relance encore. Trois pipelines sont en attente du même lock.

graph LR
    A["Pipeline A<br/>acquiert le lock"] --> B["Pipeline B<br/>échoue (lock)"]
    B --> C["Dev relance<br/>manuellement"]
    C --> D["Pipeline C<br/>échoue aussi"]
    D --> E["force-unlock<br/>en prod"]
    E --> A
    style E fill:#ff6b6b,color:#fff

Le cercle vicieux de la contention Terraform

Les développeurs frustrés finissent par contourner le système (terraform force-unlock en production). On se retrouve avec un problème bien pire que celui qu’on voulait éviter.

Ce qui marche mieux : découper les states

Le vrai problème n’est pas le lock, c’est que trop de ressources partagent le même state. Quand on découpe par domaine (réseau, compute, données, certificats), chaque state a son propre cycle de vie. Les conflits deviennent rares parce que deux équipes travaillent rarement sur le même domaine au même moment.

Avant	Après
1 state monolithique par application	1 state par domaine (réseau, compute, data)
Contention dès que 2 devs touchent la même app	Conflits rares, chaque domaine a son rythme
`force-unlock` réguliers	Lock presque jamais atteint

Le lock Terraform reste utile pour garantir la cohérence d’un state donné. Mais si on se retrouve à le subir régulièrement, c’est un signal que le périmètre du state est trop large.

Problème 2 : les pipelines CI/CD sérialisés qui bloquent tout le monde

La situation

Plusieurs pipelines de déploiement ciblent le même environnement. Par sécurité, on sérialise : un seul déploiement à la fois, les autres attendent.

Aux heures de pointe (le matin quand tout le monde pousse), 15 à 20 pipelines s’empilent. Les développeurs voient “pending” depuis 40 minutes, perdent confiance, et commencent à déployer manuellement. Le mécanisme de protection a activement dégradé le processus.

Ce qui marche mieux : déployer et surveiller

La vraie question : que se passe-t-il si deux déploiements s’exécutent en parallèle ? Dans la majorité des cas, ils touchent des composants différents. Le conflit réel (deux modifications incompatibles au même instant) est statistiquement rare.

sequenceDiagram
    participant Dev as Développeur
    participant CI as Pipeline CI
    participant Env as Environnement
    participant Mon as Monitoring

    Dev->>CI: Push (jamais bloqué)
    CI->>Env: Déploiement
    Env->>Mon: Health checks
    alt Tout va bien
        Mon-->>CI: OK
    else Problème détecté
        Mon-->>CI: Dégradation
        CI->>Env: Rollback automatique
        CI-->>Dev: Alerte + logs
    end

Déployer, surveiller, corriger si nécessaire

Le coût d’un rollback occasionnel est infiniment inférieur au coût d’une file de 20 déploiements bloqués chaque matin.

Avant	Après
1 déploiement à la fois, file d’attente	Déploiements parallèles
Devs frustrés, déploiements manuels	Rollback automatique si conflit
40 min d’attente aux heures de pointe	Feedback en quelques minutes

Problème 3 : les certificats qu’on croit devoir verrouiller

La situation

Plusieurs équipes demandent simultanément des certificats via une plateforme Venafi. On pourrait croire qu’il faut verrouiller la CA pour éviter les conflits de CN (Common Name).

Pourquoi le lock est inutile ici

L’industrie PKI gère ce problème depuis des décennies sans verrou : si un conflit survient (même CN demandé deux fois), on révoque le doublon et on réémet. Le coût d’un certificat en double est négligeable. Le coût d’un déploiement bloqué en attente de certificat est très concret.

Personne n’a jamais proposé de “verrouiller la CA pendant 5 minutes”. Le métier sait déjà gérer le conflit après coup. C’est un bon indicateur : si un processus de correction existe déjà et coûte peu, le lock est superflu.

Quand faut-il vraiment verrouiller ?

Tout ce qui précède ne veut pas dire que les locks sont toujours inutiles. Voici la grille que j’utilise :

graph TD
    Q["Conflit potentiel"]
    Q --> D{"Peut-on séparer<br/>les périmètres ?"}
    D -->|Oui| BC["Découper<br/>(states, pipelines séparés)"]
    D -->|Non| S{"Un rollback<br/>suffit-il ?"}
    S -->|Oui| SA["Déployer et surveiller<br/>(rollback si problème)"]
    S -->|Non| L["Verrouiller<br/>(approval gate, state lock)"]

    style BC fill:#2ecc71,color:#fff
    style SA fill:#3498db,color:#fff
    style L fill:#e74c3c,color:#fff

Arbre de décision

Les cas où le lock se justifie :

Opérations irréversibles : terraform destroy en prod, suppression de base de données. Mais c’est un verrou humain (peer review, approval gate), pas un lock technique.
Cohérence forte : migration de schéma avec données, rotation de secrets sur tous les consommateurs en même temps.
Limites du provider : quotas cloud, limites d’IP. On ne peut pas corriger un dépassement de quota après coup.

Question	Si oui	Si non
L’opération est-elle irréversible ?	Lock (approval gate)	suivante
Deux exécutions parallèles corrompent-elles un état partagé ?	Lock fin (state lock)	suivante
Un rollback corrige-t-il le problème ?	Pas de lock, surveiller	suivante
Le coût du conflit dépasse-t-il le coût de l’attente ?	Lock	Pas de lock

Dans mon expérience, la majorité des cas se résolvent par du découpage ou du monitoring. Le lock est un dernier recours.

En résumé

Chaque fois qu’on vous demande un lock sur un pipeline ou un state, posez d’abord la question : que se passe-t-il réellement quand le conflit survient ? La réponse révèle presque toujours un processus de correction qui existe déjà.

Le réflexe du lock est compréhensible. Il donne une illusion de contrôle rassurante. Mais à grande échelle, il crée de la contention, de la frustration, et des contournements dangereux.

Pour aller plus loin

Ces idées viennent du monde du Domain-Driven Design (DDD). Udi Dahan appelle “invariants superficiels” les contraintes qu’on croit dures mais que le métier gère déjà sans verrou. Le pattern “accepter puis corriger” s’appelle une Saga, et le découpage en périmètres indépendants correspond aux bounded contexts. Si le sujet vous intéresse :

Udi Dahan, “Race Conditions Don’t Exist” (2010)
Udi Dahan, “Watch out for superficial invariants” (2014)
Michaël Azerhad, fondateur de WealCome, pour la vulgarisation DDD/CQRS en français