Découvrez comment le mode lecture seule pendant un incident permet de bloquer les écritures, de préserver les lectures essentielles et d’afficher un message clair dans l’interface quand votre base de données est sous tension.
Quand votre base de données est surchargée, les utilisateurs voient rarement un message "hors service" propre. Ils voient des timeouts, des pages qui se chargent à moitié, des boutons qui tournent indéfiniment et des actions qui marchent parfois puis échouent. Un enregistrement peut être sauvegardé une fois, puis renvoyer une erreur la fois suivante avec "Quelque chose s’est mal passé." Cette incertitude rend les incidents chaotiques.
Les premières choses à lâcher sont généralement les chemins gourmands en écritures : modification d’enregistrements, flux de paiement, envois de formulaires, mises à jour en arrière-plan, et tout ce qui nécessite une transaction et des verrous. Sous tension, les écritures ralentissent, se bloquent mutuellement et peuvent aussi ralentir les lectures en tenant des verrous ou en déclenchant du travail supplémentaire.
Les erreurs aléatoires sont pires qu’une limitation contrôlée parce que les utilisateurs ne savent pas quoi faire ensuite. Ils réessaient, rafraîchissent, cliquent encore, et créent encore plus de charge. Les tickets support augmentent parce que le système "fonctionne un peu", mais personne ne peut lui faire confiance.
Le but du mode lecture seule pendant un incident n’est pas la perfection. C’est de garder les parties les plus importantes utilisables : consulter des enregistrements clés, rechercher, vérifier des statuts et télécharger ce dont les gens ont besoin pour continuer. Vous interrompez ou retardez volontairement les actions risquées (les écritures) pour que la base puisse récupérer et que les lectures restantes restent réactives.
Fixez les attentes clairement. C’est une limite temporaire et cela ne signifie pas que des données sont supprimées. Dans la plupart des cas, les données existantes de l’utilisateur sont toujours là et en sécurité — le système met simplement les changements en pause jusqu’à ce que la base redevienne saine.
Le mode lecture seule pendant un incident est un état temporaire où votre produit reste utilisable pour consulter, mais refuse tout ce qui modifierait les données. L’objectif est simple : garder le service utile tout en protégeant la base de données d’un travail supplémentaire.
Concrètement, on peut toujours consulter des informations, mais pas effectuer d’opérations qui déclenchent des écritures. En pratique, parcourir les pages, rechercher, filtrer et ouvrir des enregistrements fonctionne encore. En revanche, sauvegarder des formulaires, modifier des paramètres, poster des commentaires, téléverser des fichiers ou créer de nouveaux comptes sont bloqués.
Une façon pratique d’y penser : si une action met à jour une ligne, crée une ligne, supprime une ligne ou écrit dans une file, elle n’est pas autorisée. Beaucoup d’équipes bloquent aussi les « écritures cachées » comme les événements analytiques stockés dans la base principale, les logs d’audit écrits de façon synchrone et les horodatages « last seen ».
Le mode lecture seule est le bon choix quand les lectures fonctionnent encore en grande partie, mais que la latence d’écriture augmente, la contention de verrous grandit ou un arriéré d’opérations lourdes en écriture ralentit tout. Passez complètement hors ligne lorsque même les lectures de base timeout, que votre cache ne peut plus fournir l’essentiel, ou que le système n’est plus capable d’indiquer clairement ce qu’il est sûr de faire.
Pourquoi ça aide : une écriture coûte souvent bien plus qu’une simple lecture. Une écriture peut déclencher des index, des contraintes, des verrous et des requêtes de suivi. Bloquer les écritures empêche aussi les tempêtes de réessais, où les clients renvoient sans cesse des sauvegardes échouées et multiplient les dégâts.
Exemple : pendant un incident CRM, les utilisateurs peuvent toujours rechercher des comptes, ouvrir les fiches de contacts et voir les affaires récentes, mais les actions Éditer, Créer et Importer sont désactivées et toute requête de sauvegarde est rejetée immédiatement avec un message clair.
Quand vous passez en lecture seule pendant un incident, l’objectif n’est pas « tout fonctionne ». L’objectif est que les écrans les plus importants se chargent encore, tandis que tout ce qui crée plus de pression sur la base s’arrête rapidement et en sécurité.
Commencez par nommer les quelques actions utilisateur qui doivent rester disponibles même par mauvais temps. Ce sont habituellement des lectures courtes qui débloquent des décisions : consulter le dernier enregistrement, vérifier un statut, rechercher une petite liste ou télécharger un rapport déjà mis en cache.
Décidez ensuite ce que vous pouvez mettre en pause sans causer de dommages majeurs. La plupart des chemins d’écriture sont « agréables à avoir » durant un incident : modifications, mises à jour en masse, imports, commentaires, pièces jointes, événements analytiques et tout ce qui déclenche des requêtes supplémentaires.
Une façon simple de trancher est de classer les actions en trois catégories :
Fixez aussi un horizon temporel. Si vous attendez quelques minutes, vous pouvez être strict et bloquer presque toutes les écritures. Si vous attendez des heures, envisagez d’autoriser un très petit ensemble d’écritures sûres (par exemple réinitialisations de mot de passe ou mises à jour de statut critiques) et mettez tout le reste en file.
Mettez-vous d’accord sur la priorité dès le départ : sécurité avant exhaustivité. Il vaut mieux afficher clairement « les modifications sont en pause » que d’autoriser une écriture qui réussit à moitié et laisse les données incohérentes.
Passer en lecture seule est un compromis : moins de fonctionnalités maintenant, mais un produit utilisable et une base en meilleure santé. L’objectif est d’agir avant que les utilisateurs ne déclenchent une spirale de réessais, timeouts et connexions bloquées.
Surveillez un petit ensemble de signaux que vous pouvez résumer en une phrase. Si deux ou plusieurs apparaissent en même temps, considérez cela comme un avertissement précoce :
Les métriques seules ne doivent pas être l’unique déclencheur. Ajoutez une décision humaine : la personne on-call déclare l’état d’incident et active la lecture seule. Cela évite les débats sous pression et rend l’action auditable.
Rendez les seuils faciles à retenir et à communiquer. « Les écritures sont en pause car la base est surchargée » est plus clair que « nous avons atteint la saturation ». Définissez aussi qui peut basculer le bouton et où il est contrôlé.
Évitez les oscillations entre modes. Ajoutez une simple hystérésis : une fois en lecture seule, restez-y pour une fenêtre minimale (par exemple 10 à 15 minutes) et ne revenez en écriture que lorsque les signaux clés sont normaux depuis un moment. Cela évite aux utilisateurs de voir un formulaire qui marche une minute et échoue la suivante.
Considérez la lecture seule comme un changement contrôlé, pas une improvisation. L’objectif est de protéger la base en arrêtant les écritures tout en gardant les lectures les plus utiles actives.
Si possible, livrez le chemin applicatif avant d’actionner l’interrupteur. Ainsi, activer la lecture seule devient un simple toggle, pas une modification en direct.
READ_ONLY=true. Évitez plusieurs flags qui peuvent diverger.Quand la lecture seule est active, échouez vite avant d’atteindre la base. N’exécutez pas des requêtes de validation puis bloquez l’écriture. La requête bloquée la plus rapide est celle qui ne touche jamais votre base surchargée.
Quand vous activez la lecture seule, l’UI devient une partie de la solution. Si les gens continuent de cliquer sur Enregistrer en obtenant des erreurs vagues, ils réessaient, rafraîchissent et ouvrent des tickets. Un message clair réduit la charge et la frustration.
Un bon pattern est une bannière visible et persistante en haut de l’application. Restez bref et factuel : ce qui se passe, à quoi s’attendre et ce qu’ils peuvent faire maintenant. Ne le cachez pas dans une notification éphémère.
Les utilisateurs veulent surtout savoir s’ils peuvent continuer à travailler. Énoncez-le en langage simple. Pour la plupart des produits, cela veut dire :
Un libellé de statut simple aide aussi les gens à comprendre l’avancement sans deviner. « Investigating » (en cours d’examen) signifie que vous cherchez la cause. « Stabilizing » (stabilisation) signifie que vous réduisez la charge et protégez les données. « Recovering » (rétablissement) signifie que les écritures reviendront bientôt, mais peuvent rester lentes.
Évitez les textes accusateurs ou vagues comme « Quelque chose s’est mal passé » ou « Vous n’avez pas la permission. » Si un bouton est désactivé, indiquez-le : « L’édition est temporairement en pause pendant que nous stabilisons le système. »
Petit exemple : dans un CRM, gardez les pages contact et affaire consultables, mais désactivez Éditer, Ajouter une note et Nouvelle affaire. Si quelqu’un insiste, affichez un court dialogue : « Les modifications sont en pause pour le moment. Vous pouvez copier cette fiche ou exporter la liste, puis réessayer plus tard. »
Le but n’est pas « garder tout visible », mais « garder les quelques pages sur lesquelles les gens comptent » sans ajouter de pression à la base.
Commencez par alléger les écrans les plus lourds. Les tableaux longs avec beaucoup de filtres, la recherche en texte libre sur plusieurs champs et les tris sophistiqués déclenchent souvent des requêtes lentes. En lecture seule, simplifiez ces écrans : moins d’options de filtre, un tri par défaut sûr et une plage de dates limitée.
Privilégiez les vues mises en cache ou pré-calculées pour les pages importantes. Un simple « aperçu du compte » lisant depuis un cache ou une table de résumé est souvent plus sûr que charger des journaux bruts ou faire de nombreuses jointures.
Moyens concrets pour garder les lectures vivantes sans alourdir la base :
Exemple concret : lors d’un incident CRM, gardez Consulter contact, Consulter statut d’affaire et Voir la dernière note. Masquez temporairement Recherche avancée, graphique de revenus et timeline complète des e-mails, et indiquez que les données peuvent être âgées de quelques minutes.
Le plus souvent, la surprise n’est pas l’UI mais les écrivains invisibles : jobs en arrière-plan, synchros planifiées, actions admin en masse et intégrations tierces qui continuent de marteler la base.
Commencez par arrêter le travail en arrière-plan qui crée ou met à jour des enregistrements. Les coupables fréquents sont les imports, synchronisations nocturnes, envois d’e-mails qui écrivent des logs de livraison, rollups analytiques et boucles de réessai qui retentent la même mise à jour échouée. Les mettre en pause réduit rapidement la pression et évite une seconde vague de charge.
Par défaut, mettez en pause ou bridez les jobs lourds en écriture et les consommateurs de queue qui persistent des résultats, désactivez les actions admin massives (mises à jour en masse, suppressions groupées, réindexations importantes) et échouez vite sur les endpoints d’écriture avec une réponse temporaire claire plutôt que de laisser timeout.
Pour les webhooks et intégrations, la clarté vaut mieux que l’optimisme. Si vous acceptez un webhook mais ne pouvez pas le traiter, vous créerez des décalages et du support à gérer. Quand les écritures sont en pause, renvoyez un échec temporaire qui indique à l’émetteur de réessayer plus tard, et assurez-vous que les messages UI reflètent ce qui se passe en coulisses.
Soyez prudent avec le buffering « mettre en file pour plus tard ». Ça paraît amical, mais peut créer un arriéré qui inonde le système dès que vous réactivez les écritures. Ne mettez en file les écritures utilisateurs que si vous pouvez garantir l’idempotence, limitez la taille de la file et montrez à l’utilisateur l’état réel (en attente vs enregistré).
Enfin, auditez les écrivains en masse cachés dans votre produit. Si une automation peut mettre à jour des milliers de lignes, elle doit être forcée hors service en lecture seule même si le reste de l’app se charge.
La manière la plus rapide d’empirer un incident est de traiter le mode lecture seule comme un gadget cosmétique. Si vous ne faites que désactiver les boutons dans l’UI, des écritures passeront encore par les APIs, onglets ouverts, applis mobiles et jobs en arrière-plan. La base reste sous pression, et vous perdez la confiance car les utilisateurs voient « enregistré » à un endroit et des changements manquants ailleurs.
Un vrai mode lecture seule exige une règle claire : le serveur refuse les écritures, à chaque fois, pour tous les clients.
Ces patterns reviennent souvent lors d’une surcharge :
Faites en sorte que le système se comporte de façon prévisible. Implementez un unique interrupteur côté serveur qui rejette les écritures avec une réponse claire. Ajoutez un cooldown : une fois en lecture seule, restez-y un temps défini (par ex. 10–15 minutes) sauf si un opérateur change l’état.
Soyez strict sur l’intégrité des données. Si une écriture ne peut pas se compléter, échouez toute l’opération et indiquez à l’utilisateur la marche à suivre. Un message simple comme « Mode lecture seule : la consultation fonctionne, les changements sont en pause. Réessayez plus tard. » réduit les réessais répétés.
Le mode lecture seule n’aide que s’il est facile à activer et se comporte identiquement partout. Avant les problèmes, assurez-vous d’avoir un unique toggle (feature flag, config, switch admin) que l’on-call peut activer en quelques secondes, sans déploiement.
Quand vous suspectez une surcharge, faites une passe rapide pour confirmer les bases :
Pendant l’incident, gardez une personne dédiée à vérifier l’expérience utilisateur, pas seulement les tableaux de bord. Un contrôle rapide en mode navigation privée repère des problèmes comme des bannières cachées, formulaires cassés ou spinners infinis qui provoquent des rafraîchissements supplémentaires.
Planifiez la sortie avant d’activer la lecture seule. Définissez ce que « sain » signifie (latence, taux d’erreur, retard de réplication) et faites une vérification courte après la remise en marche : créez un enregistrement test, modifiez-le et confirmez que les comptes et l’activité récente sont cohérents.
Il est 10h20. Votre CRM est lent et la CPU de la base est saturée. Les tickets support arrivent : les utilisateurs ne peuvent pas sauvegarder les modifications de contacts et d’affaires. Mais l’équipe a encore besoin de retrouver des numéros, voir les étapes d’affaires et lire les dernières notes avant les appels.
Vous choisissez une règle simple : geler tout ce qui écrit, garder les lectures les plus utiles. En pratique, la recherche de contacts, la fiche contact et la vue pipeline restent accessibles. La modification d’un contact, la création d’une affaire, l’ajout de notes et les imports en masse sont bloqués.
Dans l’UI, le changement doit être visible et calme. Sur les écrans d’édition, le bouton Enregistrer est désactivé et le formulaire reste visible pour que les gens puissent copier ce qu’ils ont saisi. Une bannière en haut indique : « Mode lecture seule activé en raison d’une forte charge. La consultation est disponible. Les modifications sont en pause. Merci de réessayer plus tard. » Si un utilisateur déclenche quand même une écriture (par exemple via une API), renvoyez un message clair et évitez les réessais automatiques qui martèleraient la base.
Opérationnellement, gardez le flux court et reproductible. Activez la lecture seule et vérifiez que tous les endpoints d’écriture la respectent. Mettez en pause les jobs d’arrière-plan qui écrivent (syncs, imports, logging d’e-mails, rollups analytiques). Bridez ou arrêtez webhooks et intégrations qui créent des mises à jour. Surveillez la charge DB, le taux d’erreur et les requêtes lentes. Publiez une mise à jour d’état indiquant ce qui est affecté (modifications) et ce qui fonctionne encore (recherche et consultation).
La récupération n’est pas juste un coup d’interrupteur. Réactivez les écritures progressivement, vérifiez les logs d’erreur pour les sauvegardes échouées et surveillez une possible tempête d’écritures issue des jobs mis en file. Puis communiquez clairement : « Le mode lecture seule est désactivé. La sauvegarde est rétablie. Si vous avez tenté d’enregistrer entre 10h20 et 10h55, merci de vérifier vos derniers changements. »
Le mode lecture seule fonctionne mieux quand il est terne et répétable. L’objectif est de suivre un script court avec des rôles et des vérifications clairs.
Tenez-le sur une page. Incluez vos déclencheurs (les quelques signaux qui justifient la bascule), l’interrupteur exact que vous actionnez et comment confirmer que les écritures sont bloquées, une liste courte de lectures clés qui doivent rester actives, des rôles clairs (qui bascule, qui surveille les métriques, qui gère le support) et des critères de sortie (ce qui doit être vrai avant de réactiver les écritures et comment vidanger les arriérés).
Rédigez et validez les messages maintenant pour éviter les débats pendant une panne. Un petit ensemble couvre la plupart des cas :
Exercez la bascule en staging et mesurez le temps. Assurez-vous que le support et l’on-call trouvent vite l’interrupteur et que les logs montrent clairement les écritures bloquées. Après chaque incident, revoyez quelles lectures étaient vraiment critiques, lesquelles étaient « agréables à avoir » et lesquelles ont accidentellement créé de la charge, puis mettez à jour la checklist.
Si vous développez des produits sur Koder.ai (koder.ai), il peut être utile de traiter le mode lecture seule comme un interrupteur de première classe dans votre app générée afin que l’UI et les gardes côté serveur restent cohérents quand vous en avez le plus besoin.
Les chemins d’écriture se dégradent généralement en premier : enregistrements, éditions, finalisations d’achats, imports et tout ce qui nécessite une transaction. Sous charge, les verrous et les commits lents font que les écritures se bloquent entre elles, et ces écritures bloquées peuvent aussi ralentir les lectures.
Parce que c’est imprévisible. Si les actions fonctionnent parfois et échouent parfois, les utilisateurs réessaient, rafraîchissent et cliquent encore, ce qui augmente la charge et provoque davantage de timeouts et de requêtes coincées.
C’est un état temporaire où le produit reste utile pour consulter les données mais refuse les modifications. Les gens peuvent parcourir, rechercher et ouvrir des enregistrements, mais toute opération qui créerait, mettrait à jour ou supprimerait des données est bloquée.
Par défaut, bloquez toute action qui écrit dans la base primaire, y compris les « écritures cachées » comme les logs d’audit, les horodatages « last-seen » et les événements analytiques stockés dans la même base. Si ça modifie une ligne ou met en file quelque chose qui écrit ensuite, traitez-le comme une écriture.
Activez-le quand vous observez des signes précoces d’escalade des écritures : timeouts, hausse de la latence p95, attentes sur les verrous, épuisement du pool de connexions ou requêtes lentes répétées. Mieux vaut basculer avant que les utilisateurs lancent une tempête de réessais.
Utilisez un interrupteur global et faites appliquer la règle côté serveur, pas seulement dans l’UI. L’interface doit désactiver ou masquer les actions d’écriture, mais chaque point d’écriture doit échouer rapidement avec la même réponse claire avant d’atteindre la base.
Affichez une bannière persistante qui décrit ce qui se passe, ce qui fonctionne encore et ce qui est mis en pause, en langage simple. Rendre explicites les actions bloquées évite que les utilisateurs répètent leurs tentatives et inondent le support de tickets « Quelque chose s’est mal passé ».
Gardez un petit ensemble de pages essentielles et simplifiez tout ce qui déclenche des requêtes lourdes. Préférez des résumés mis en cache, des tailles de page plus petites, un tri par défaut sûr et des données légèrement périmées plutôt que des filtres complexes et des jointures coûteuses.
Mettez en pause ou bridez les jobs d’arrière-plan, les synchronisations, les imports et les consommateurs de queue qui écrivent en base. Pour les webhooks, ne les acceptez pas si vous ne pouvez pas les traiter : renvoyez un échec temporaire pour que l’émetteur réessaie plus tard plutôt que de créer des incohérences invisibles.
Ne désactivez pas seulement les boutons dans l’UI : les APIs, applications mobiles et onglets anciens continueront d’écrire. Évitez aussi de basculer constamment entre modes : imposez une durée minimale en lecture seule et ne repassez en écriture que lorsque les métriques sont stables.