« Ce bloc est en cours de modification » : comprendre le verrouillage d’édition

« Cet article est actuellement en cours de modification par [Prénom Nom] » : ce message, une rédactrice d’une agence de communication de Bordeaux l’a vu apparaître en pleine relecture d’un article client, sans avoir pourtant l’impression que quiconque d’autre y touchait au même moment. Le message ne parle pas de blocs individuels, mais de l’article entier — une précision qui change beaucoup à la façon dont on doit interpréter la situation.

Ce verrouillage n’a rien à voir avec l’API Blocks en tant que telle : il repose sur un mécanisme plus ancien, le Heartbeat API, qui existait avant même l’éditeur de blocs et continue de gérer les conflits d’édition simultanée, que le contenu soit du texte brut ou des blocs structurés.

Comment le verrouillage se déclenche

Dès qu’un utilisateur ouvre un article en édition, WordPress enregistre un post meta interne, _edit_lock, contenant un horodatage et l’identifiant de l’utilisateur. Le Heartbeat API, actif dans l’éditeur, envoie une requête toutes les quinze secondes pour rafraîchir ce verrou tant que la page reste ouverte :

// Valeur stockée dans le post meta _edit_lock
1737190245:4
// horodatage Unix : ID utilisateur

Si un second utilisateur ouvre le même article moins de deux Heartbeats après le dernier rafraîchissement du premier, WordPress considère l’article comme verrouillé et affiche l’avertissement, avec un lien pour reprendre l’édition — une action qui déloge le premier utilisateur sans le prévenir directement.

Pourquoi le message semble parfois se tromper

Le scénario qui a piégé la rédactrice bordelaise est fréquent en agence : un collègue avait ouvert l’article la veille, corrigé une virgule, puis fermé l’onglet sans cliquer sur « Enregistrer » ni quitter proprement l’éditeur — par exemple en mettant l’ordinateur en veille. Le Heartbeat cesse alors d’émettre, mais le verrou reste actif jusqu’à expiration, ce qui peut donner l’impression trompeuse qu’une modification est en cours alors que la personne a quitté depuis longtemps.

Le délai d’expiration du verrou est fixé à 150 secondes sans rafraîchissement — dix Heartbeats manqués. Passé ce délai, l’article se déverrouille automatiquement, sans action de personne.

Que faire face à ce message

1. Vérifier d’abord si le collègue mentionné travaille réellement sur l’article au moment présent, en le contactant directement plutôt que de forcer la prise de contrôle à l’aveugle.
2. Si la personne a bien quitté sans fermer proprement l’éditeur, patienter les quelques minutes nécessaires à l’expiration automatique du verrou plutôt que de le casser immédiatement.
3. En cas d’urgence réelle, cliquer sur le lien « Prendre le contrôle » proposé par WordPress — cette action ne provoque aucune perte de contenu enregistré, elle libère simplement le verrou pour l’utilisateur courant.

Réduire la fréquence de ces conflits en agence

Sur un site à plusieurs rédacteurs, quelques pratiques limitent nettement ces situations :

• Établir une convention simple : toujours cliquer sur « Quitter l’éditeur » plutôt que fermer directement l’onglet du navigateur.
• Utiliser le statut de brouillon et les commentaires internes pour signaler qu’un article est réservé à une relecture, plutôt que de compter uniquement sur le verrouillage technique.
• Sur les postes partagés ou les connexions instables, éviter de laisser un onglet d’édition ouvert en arrière-plan pendant de longues périodes.

Ajuster la fréquence du Heartbeat si nécessaire

Sur un hébergement mutualisé sensible à la charge, il est possible de réduire la fréquence des requêtes Heartbeat dans l’éditeur via le filtre heartbeat_settings, ce qui ralentit d’autant la détection de conflit sans la désactiver :

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 30; // secondes, au lieu de 15 par défaut
    return $settings;
} );

Désactiver totalement le Heartbeat dans l’éditeur n’est pas recommandé : au-delà du verrouillage, il gère aussi l’enregistrement automatique périodique des révisions, une sécurité utile en cas de fermeture accidentelle du navigateur.

Un verrou d’édition qui semble injustifié n’est presque jamais un bug : c’est le signe qu’un onglet est resté ouvert quelque part, oublié plutôt qu’actif.

Ce que ce mécanisme ne couvre pas

Le verrouillage protège contre l’écrasement accidentel d’un article entier par deux personnes travaillant en parallèle, mais il ne gère pas la fusion de modifications concurrentes bloc par bloc — contrairement à un éditeur collaboratif en temps réel. Les révisions de contenu, elles, restent un mécanisme distinct et ne sont pas concernées par cette question de verrouillage.

En résumé

Le message de verrouillage d’édition n’a rien de mystérieux une fois qu’on connaît son fonctionnement : un simple post meta rafraîchi par Heartbeat, avec une expiration automatique après deux minutes et demie d’inactivité. En agence, la meilleure prévention reste organisationnelle — quitter proprement l’éditeur — bien plus qu’un réglage technique du Heartbeat lui-même.