Le bandeau annonce une maintenance en lecture seule. Les boutons d’enregistrement sont désactivés et le test manuel ne trouve aucune écriture possible. Pourtant, dix minutes plus tard, un import modifie encore des clients et une tâche de fond confirme plusieurs commandes. L’interface est figée ; ce décalage masque les écritures qui continuent en arrière-plan.
Une période sans écriture doit couvrir tous les chemins capables de modifier l’état métier. Les formulaires ne sont qu’un de ces chemins. Imports, consommateurs de messages, tâches planifiées, scripts de support et retours d’API peuvent agir sans qu’un utilisateur ouvre le site.
Pour une application métier développée sur mesure, cette préparation est souvent nécessaire avant une migration ou une opération de maintenance sensible. Le cas fictif présenté ici suit un portail de commandes connecté à un ERP. Il sert à décider ce qui peut continuer, ce qui doit attendre et ce qu’il faut terminer avant d’annoncer un état réellement stable.
La préparation d’une migration d’application existante vers Symfony comprend cette frontière entre consultation, travaux en cours et reprise sur le nouveau modèle.
Définir ce que « lecture seule » signifie pour cette intervention
Une migration de base, un changement de règles métier et une maintenance d’un logiciel externe n’exigent pas forcément le même arrêt. Commencez par formuler la contrainte : aucune modification de commande, aucun nouvel ordre envoyé à l’ERP, ou aucune écriture dans un ensemble de tables pendant la copie ? Un nom de mode ne remplace pas ce périmètre.
Dans notre scénario, le portail doit rester consultable tandis que les commandes et les comptes clients sont migrés. Les journaux techniques et un stockage d’entrée séparé peuvent continuer à recevoir des informations. Ces exceptions sont choisies et documentées ; elles ne sont pas découvertes après coup parce qu’un composant a contourné le blocage.
Qualifier les lectures qui ont des effets secondaires
Une page peut mettre à jour une date de dernière visite, renouveler une session ou déclencher un calcul persistant. Une route appelée en lecture peut lancer une synchronisation automatique. Il faut donc raisonner sur les effets réels, pas uniquement sur la méthode HTTP ou le nom du bouton.
La bonne question de recette est : « Quelle donnée cette action peut-elle changer, directement ou après mise en file ? » Les opérations purement consultatives restent ouvertes si leurs dépendances le permettent. Les autres affichent un état compréhensible ou suivent le parcours d’attente prévu.
Trouver les auteurs d’écriture que le navigateur ne montre pas
L’équipe du portail identifie cinq entrées : un formulaire de commande, un import CSV, une tâche de synchronisation ERP, un webhook de livraison et un outil de correction du support. Le formulaire était le seul chemin protégé par le premier bandeau de maintenance.
| Entrée | Risque pendant la migration | Traitement retenu |
|---|---|---|
| Formulaire | Nouvelle commande dans l’ancien modèle. | Refus serveur explicite, avec conservation du brouillon côté parcours utilisateur. |
| Import CSV | Lot commencé avant la fermeture, encore en cours. | Arrêt à une frontière contrôlée et reprise identifiée. |
| Synchronisation ERP | Écriture locale et ordre externe pendant la copie. | Suspension des nouvelles prises en charge ; examen des opérations déjà engagées. |
| Webhook livraison | Perte de l’événement si le fournisseur reçoit un faux succès. | Réception durable séparée ou réponse de refus compatible avec le contrat du fournisseur. |
| Correction support | Contournement involontaire du blocage. | Barrière commune et procédure d’exception attribuée. |
Cette cartographie doit inclure les anciens scripts et les comptes de service. Un traitement oublié qui tourne une fois par nuit suffit à invalider une fenêtre de copie. Consultez les planifications et les processus réellement actifs, puis faites confirmer leur usage par les équipes qui les exploitent.
Ne créez pas une exception générale pour les administrateurs. Si une correction urgente reste possible pendant l’opération, elle doit arrêter ou invalider la phase qui suppose un état stable. Autoriser l’écriture tout en conservant l’étiquette « gel confirmé » rend la preuve incohérente.
Fermer les nouvelles écritures au point où elles deviennent possibles
Masquer les boutons améliore l’expérience, mais le serveur doit refuser une requête envoyée directement ou depuis un onglet ancien. La barrière appartient au chemin métier partagé par les interfaces, les imports et les traitements. Elle doit aussi couvrir les services qui écrivent sans passer par le contrôleur web.
Faire connaître l’état à toutes les instances
Une variable chargée uniquement au démarrage ne suffit pas si des processus restent actifs avec l’ancienne valeur. Identifiez comment chaque instance reçoit le changement, quand elle le vérifie et comment elle signale son état. Pendant la transition, considérez une instance non confirmée comme une dépendance encore ouverte.
La recette doit utiliser un processus ancien, pas seulement celui qui vient d’être redémarré. Un worker qui a démarré avant la maintenance peut conserver une configuration ou une opération en mémoire. L’équipe doit pouvoir distinguer « ne prend plus de nouveaux travaux » et « a terminé le travail déjà pris ».
Utiliser la protection de base pour ce qu’elle garantit réellement
Une protection au niveau de la base peut compléter le dispositif, selon l’environnement. La documentation PostgreSQL de SET TRANSACTION décrit notamment le mode de transaction en lecture seule et sa portée. Une option appliquée à une transaction ne configure pas, par magie, tous les processus ni tous les stockages de l’application.
Cette protection ne bloque pas non plus un e-mail, un fichier envoyé ou une commande déjà acceptée par l’ERP. Il faut donc vérifier séparément les écritures locales et les effets externes. Une erreur SQL après l’envoi externe peut laisser une opération réalisée mais non enregistrée dans le portail.
Terminer ou isoler les opérations qui ont déjà franchi la barrière
À 18 heures, un import de 500 lignes a traité 320 lignes. Il ne doit ni recommencer les 320 lignes sans contrôle ni disparaître de la vue de l’exploitant. Le système conserve la référence du lot, les lignes terminées, la frontière de reprise et les erreurs. Les 180 lignes restantes restent en attente selon le choix de maintenance.
Dans le même temps, une commande a été transmise à l’ERP, mais sa réponse n’est pas encore revenue. Tuer le processus ne retire pas l’ordre au système distant. Il faut retrouver le résultat par la référence de l’opération et décider quand le reporter localement, en respectant les contraintes de la migration.
Nommer les conditions de passage à l’état stable
La fenêtre peut être considérée comme prête lorsque les nouvelles prises en charge sont fermées, les travaux actifs ont terminé ou sont isolés, et les effets externes ambigus possèdent un traitement défini. Le responsable de l’intervention reçoit ces preuves avant de lancer la copie ou la transformation.
Une attente sans limite n’est pas une stratégie. Fixez les critères d’abandon de l’opération si un traitement ne peut pas être arrêté proprement. Le choix peut être de reporter la maintenance plutôt que de forcer une coupure dont les conséquences métier restent inconnues.
Recevoir les événements sans prétendre les avoir appliqués
Un partenaire peut continuer à envoyer des événements pendant votre intervention. Deux approches sont possibles selon son contrat : les stocker durablement dans un espace compatible avec la maintenance, ou refuser temporairement leur réception avec un comportement que le partenaire sait reprendre. Le choix exige de connaître ses délais, ses nouvelles tentatives et ses moyens de récupération.
Ne renvoyez pas un succès puis ne jetez pas le message. Le fournisseur peut considérer l’envoi terminé. Si vous acceptez l’événement, conservez les éléments nécessaires à sa validation et à son traitement ultérieur, avec les protections adaptées aux données reçues.
Prévoir la capacité de la zone d’attente
Dans un exercice fictif, 60 événements par minute pendant 40 minutes représentent 2 400 événements à conserver. Ce calcul ne dimensionne pas un système réel : il montre pourquoi il faut tenir compte du débit, du poids des messages, des pics et de la durée possible de l’intervention. Une file pleine transforme une maintenance prévue en perte d’information.
Le tableau de suivi distingue reçus, conservés, rejetés et appliqués. Un compteur de réceptions en hausse ne prouve pas que les commandes sont à jour. Le support doit pouvoir expliquer le retard prévu sans annoncer des changements qui n’ont pas encore été enregistrés dans le système métier.
Rouvrir dans un ordre compatible avec le modèle migré
Avant de relancer les producteurs, vérifiez que les consommateurs savent traiter les anciens messages avec le nouveau modèle. Une migration de base réussie peut rendre un message en attente incompatible avec la version courante. La politique peut convertir le message, utiliser un lecteur compatible ou demander une reprise contrôlée ; elle doit exister avant l’accumulation.
Reprenez un petit lot, contrôlez l’état obtenu et observez les effets dans l’ERP. Ensuite, augmentez le débit en fonction de la capacité constatée. Ouvrir simultanément formulaires, imports et tous les workers peut saturer les dépendances au moment où l’équipe essaie encore de vérifier la migration.
La répétition générale d’une migration permet d’exercer cette séquence. Elle doit inclure les messages accumulés et les résultats externes tardifs, pas seulement le chargement de la nouvelle base.
Erreurs fréquentes : déclarer le gel depuis un seul indicateur
Un site qui affiche une page de maintenance peut encore recevoir des appels directs. Une file vide peut être suivie d’un producteur planifié. Une base qui refuse certaines écritures peut laisser partir des effets externes. Ces constats expliquent pourquoi aucun de ces indicateurs, pris seul, ne prouve l’arrêt du périmètre métier.
Une autre erreur consiste à arrêter brutalement tous les processus sans conserver leur position. La reprise devient alors une enquête : quelles lignes ont été appliquées, quels messages ont été acquittés, quelles commandes ont été transmises ? Le temps gagné à la fermeture se paie à la réouverture.
Enfin, un bouton de réactivation trop général masque les dépendances. Le retour au service doit suivre des étapes observables, avec la possibilité d’arrêter l’élargissement. Il ne s’agit pas d’imposer une procédure longue à chaque intervention, mais de rendre explicites les conditions dont cette intervention dépend.
Plan d’action : prouver le gel avec les chemins d’écriture réels
Avant l’intervention, rassemblez les cinq familles d’entrée et nommez leur responsable. Pour chacune, décrivez l’action de fermeture, le signal de fin et la reprise. Les chemins inconnus restent des points à résoudre ; ils ne sont pas supposés couverts par le bandeau.
En recette, déclenchez un import et une opération externe juste avant la fermeture. Envoyez aussi une requête depuis une session déjà ouverte. Vérifiez les refus, les traitements qui terminent et les éléments mis en attente. L’essai doit montrer la frontière exacte à partir de laquelle l’état attendu est stable.
Après la migration simulée, reprenez le lot partiel et les événements conservés. Contrôlez les quantités, les références et l’absence d’effet répété dans le système distant. Le dossier de réception comprend les erreurs attendues et leur résolution, afin qu’un exploitant puisse refaire l’exercice sans improviser.
Pour la production, utilisez ces mêmes critères de passage et un responsable de décision clairement identifié. La réversibilité applicative complète ce travail en vérifiant que les sources, les accès et les procédures permettent réellement à une autre équipe de reprendre le service.
- Reporter la copie si une instance continue de prendre de nouveaux travaux sur les données à migrer.
- Isoler un ordre ERP au résultat inconnu et le rapprocher avant toute nouvelle émission de la même commande.
- Rouvrir un flux pilote après contrôle des messages accumulés ; différer les autres producteurs si le rattrapage dépasse la capacité observée.
Préparer la reprise et les responsabilités de maintenance
L’exercice de restauration par une autre équipe
La fermeture des écritures doit rester compréhensible après un changement de prestataire. L’exercice de réversibilité examine les accès, les sources et les procédures nécessaires pour qu’une autre équipe reconstruise le service, au lieu de dépendre d’une intervention orale de son auteur. Tester la réversibilité de l’application.
Le contrat qui attribue les interventions
La maintenance applicative doit préciser qui décide du créneau, qui intervient sur les dépendances et qui confirme la reprise. Cette lecture complète la recette technique avec les responsabilités utiles lorsque l’application et l’ERP sont exploités par des équipes différentes. Attribuer les responsabilités de maintenance.
Conclusion : la lecture seule est un état vérifié de l’application entière
Le gel d’une interface ne suffit pas à stabiliser les données. Une maintenance fiable relie la fermeture des entrées, le traitement des opérations actives et la conservation des événements qui continuent d’arriver.
Le cas du portail révèle les preuves à attendre : aucun nouvel engagement sur le périmètre fermé, des travaux en cours expliqués et une reprise compatible avec le modèle migré. Ces preuves permettent de décider quand commencer et quand rouvrir.
L’accompagnement Dawap sur le développement et l’évolution des applications métier permet de préparer ces transitions avec vos équipes et vos intégrateurs. L’objectif est une interruption maîtrisée dont les données, les effets externes et la reprise restent compréhensibles.
