Multisite WordPress : réparer les adresses après un changement de type de réseau

Reconnaître une conversion incomplète du réseau

Après avoir changé un réseau WordPress de sous-domaines en sous-répertoires, ou dans l’autre sens, certains sites renvoient 404, ouvrent le site principal ou perdent leur connexion. L’accueil principal peut continuer à fonctionner pendant que les autres adresses deviennent incohérentes. Le résultat recherché est de retrouver chaque site, ses contenus et son administration sous une adresse clairement définie.

Ce guide concerne un WordPress autohébergé en multisite déjà constitué. Il ne décrit pas la création d’un réseau vierge ni la migration d’un site indépendant. La conversion est une intervention avancée : la constante SUBDOMAIN_INSTALL indique un mode de fonctionnement, mais ne convertit pas à elle seule les adresses enregistrées, le DNS, les certificats et les redirections.

Commencez par noter la date, la valeur précédente et les fichiers ou données réellement modifiés. Si vous avez seulement suivi un tutoriel qui remplace une constante et des règles, la solution immédiate sera souvent de revenir à l’ensemble précédent. Si une conversion préparée a déjà transformé les données, il faut examiner sa correspondance d’adresses avant de restaurer quoi que ce soit. Évitez de créer de nouveaux sous-sites pour remplacer les adresses cassées : vous risqueriez d’obtenir des sites vides distincts de ceux qui portent vos contenus.

Établir l’inventaire avant de choisir une correction

Le super administrateur ouvre Administration du réseau, Sites et relève l’identifiant ainsi que l’adresse de chaque site. Conservez la distinction entre le site principal, les sous-sites ordinaires et ceux qui possèdent un domaine personnalisé. Un domaine déjà rattaché peut devoir rester inchangé, même si la structure des nouveaux sous-sites évolue.

Dans la liste des sites, ouvrez la fiche Modifier du sous-site et relevez l’identifiant figurant dans l’adresse de la fiche. Dans Informations, notez l’adresse de routage. Dans Réglages, relevez séparément les valeurs home et siteurl si ces champs sont disponibles. Ajoutez une colonne « hôte et chemin attendus » pour comparer la fiche au résultat d’une visite normale. Une adresse présente dans le tableau de bord ne démontre ni que le DNS pointe au bon serveur ni que le certificat couvre le nom.

Pour chaque site important, ajoutez une ancienne URL d’article, une image et l’adresse de son administration. Gardez ce relevé hors du répertoire public. Il permettra de reconnaître une page qui appartient au mauvais site, même si le serveur renvoie un succès HTTP. Si WordPress ne démarre plus assez pour produire la liste, exploitez un inventaire antérieur ou la copie sauvegardée avec le responsable technique. Ne déduisez pas les identifiants à partir des noms de dossiers ni de l’ordre d’affichage des sites.

1. Relever l’identifiant, l’adresse actuelle et l’adresse attendue de chaque sous-site.
2. Identifier les exceptions dont le domaine personnalisé doit rester inchangé.
3. Associer à chaque identifiant une page, un média et un accès d’administration déjà connus.

Choisir entre retour rapide et conversion préparée

Le retour rapide convient lorsque la bascule n’était pas préparée, que les anciennes URL restent l’objectif et que vous disposez de la configuration précédente. Il consiste à rétablir un ensemble cohérent, puis à vérifier les mêmes pages qui fonctionnaient auparavant. Il ne nécessite pas de terminer une migration dans l’urgence.

La conversion préparée convient lorsque le changement répond à un besoin confirmé et qu’une copie représentative du réseau permet de répéter l’opération. Elle demande une correspondance des adresses, des accès au serveur, au DNS et à la base, ainsi qu’un plan pour les contenus créés pendant l’intervention. Un administrateur local ne doit pas mener seul ce changement commun.

Un troisième besoin mérite d’être distingué : donner un domaine indépendant à un ou deux sous-sites. Le rattachement natif d’un domaine peut répondre à cette demande sans convertir tout le réseau. Examinez cette possibilité avant de décider une transformation globale. Quel que soit le parcours, définissez la condition d’échec : mauvais site affiché, administration inaccessible, données absentes ou ancienne URL sans destination correcte. Une page d’accueil qui semble correcte n’est pas un critère suffisant pour déclarer la conversion réussie.

Revenir en arrière lorsque seuls les fichiers ont changé

Ce parcours suppose que la conversion n’a modifié aucune adresse stockée, option ou référence dans les contenus. Les écritures normales arrivées depuis la tentative doivent être conservées. Avec SFTP ou le gestionnaire de fichiers, le mainteneur sauvegarde d’abord l’état actuel pour garder la trace de l’incident. Il compare ensuite wp-config.php et les règles serveur de la copie avec les versions fonctionnelles précédentes, puis rétablit les éléments de recette changés par la bascule.

L’exemple ci-dessous correspond uniquement à un réseau qui fonctionnait auparavant en sous-domaines. Remettez une seule définition de SUBDOMAIN_INSTALL à sa valeur précédente, avant le chargement de wp-settings.php. Si l’ancien réseau était en sous-répertoires, la valeur précédente est false : n’utilisez pas true simplement parce que l’exemple le montre.

Sur Apache, restaurez le bloc de règles WordPress qui correspondait à cet état en préservant les autres directives légitimes. Sur Nginx, faites restaurer la configuration du service par son responsable ; modifier .htaccess n’a pas cet effet. Si des enregistrements DNS ont également été changés, leur restauration doit être coordonnée avec ce même objectif. Vérifiez alors les anciennes URL et la connexion dans un profil d’essai. Si les données avaient aussi été transformées, arrêtez ce parcours limité et utilisez un retour cohérent couvrant la base.

Consignez les réglages de DNS et de redirection qui ont réellement changé, avec leurs valeurs précédentes. Si vous n’avez pas de trace assez fiable pour exclure une écriture dans les données du réseau, ne choisissez pas ce parcours sur la seule apparence des fichiers. La validation du scénario se fait d’abord sur la copie. Une décision de reprise publique appartient au responsable du réseau.

1. Confirmer à partir du journal d’intervention que le changement n’a écrit aucune adresse de sous-site ni option.
2. Rétablir en recette les fichiers et règles qui correspondaient au type d’origine, puis vérifier une ancienne URL de chaque catégorie.
3. Si le site affiché ou les options diffèrent de l’inventaire, arrêter le retour limité et reprendre le plan de restauration cohérente.

define( 'SUBDOMAIN_INSTALL', true );

Éviter une restauration partielle lorsque les données ont changé

Si la bascule a modifié les domaines, chemins, options ou liens internes, remettre seulement les anciens fichiers crée un nouvel assemblage incompatible. Listez les opérations effectuées et leurs sauvegardes. Une restauration doit ramener les données et la configuration à un point compatible, tout en préservant les événements arrivés depuis ce point.

Le responsable utilise le dispositif de sauvegarde prévu pour le réseau, avec les fichiers et la base correspondants. Avant la restauration, il conserve un export de l’état actuel et recense les nouveaux articles, inscriptions ou commandes. Il organise la limitation temporaire des écritures avec les personnes concernées, au lieu de restaurer un instant ancien pendant que d’autres continuent à travailler.

Une restauration complète est pertinente seulement si son impact sur ces données récentes a été traité. S’il faut conserver une partie de l’activité, la reprise sélective devient une opération préparée avec le mainteneur, pas une commande SQL improvisée. À l’issue du retour, contrôlez un sous-site de chaque catégorie et comparez les identifiants avec l’inventaire. L’objectif est de retrouver les sites existants avec leurs données, pas seulement leurs anciennes URL. Gardez les preuves de l’essai de conversion pour préparer une nouvelle tentative hors de l’incident.

Dans le relevé de reprise, associez chaque jeu de fichiers à l’instant correspondant de la base et aux règles serveur. Ajoutez la liste des écritures arrivées après cet instant et leur propriétaire. Pour une boutique ou un réseau qui accepte des contributions, prévoyez une vérification des états avant et après reprise. Un point déclaré compatible pour le routage peut encore manquer des données récentes.

Préparer la correspondance des adresses sur une copie

Pour poursuivre une conversion volontaire, partez d’une copie cohérente du réseau. Faites vérifier avant le démarrage que sa configuration désigne la base de recette et que ses caches persistants, tâches, courriels et paiements sont isolés de la production. Une adresse ou un chemin de fichiers différent ne suffit pas si les deux installations partagent le même stockage ou les mêmes automatismes. Conservez une sauvegarde de la copie pour pouvoir répéter l’opération et mesurer ses effets.

Établissez une correspondance site par site avec l’identifiant, l’ancien domaine, l’ancien chemin, la nouvelle adresse et les exceptions. Par exemple, un sous-site fictif atelier.reseau.example/ peut devenir reseau.example/atelier/. Dans le sens inverse, un chemin devient un hôte distinct. Les domaines personnalisés conservés doivent être signalés comme exceptions, pas transformés par un remplacement général.

Vérifiez les collisions avant de saisir les nouvelles adresses. Une page principale déjà située sous /atelier/ ne peut pas être ignorée si ce chemin devient celui d’un sous-site. Examinez aussi les préfixes d’articles du site principal et les anciens chemins des médias. Donnez une destination précise à chaque famille d’URL. Une fois ce relevé validé, le mainteneur peut préparer les changements de structure sur la copie. L’inventaire d’origine reste la référence pour vérifier que le même site et les mêmes contenus se trouvent derrière la nouvelle adresse.

Ajoutez au tableau le statut attendu pour deux cas limites, par exemple une page du site principal dont le chemin ressemble à un sous-site et un domaine personnalisé déjà rattaché. Une correspondance qui crée deux destinations possibles doit être tranchée avant les changements. Vérifiez aussi les liens contenant des paramètres utiles et les préfixes qui servent au routage.

1. Préparer une table ancienne URL, nouvelle URL, identifiant et exception pour chaque site.
2. Réserver un emplacement de retour qui associe base, fichiers et règles.
3. Valider les collisions de chemins et garder séparés les domaines personnalisés.

Préparer DNS, serveur et certificat avant les nouvelles URL

Le parcours suivant vise un réseau standard dont le domaine principal et la racine d’installation restent inchangés. Une installation déplacée simultanément vers un autre serveur, plusieurs réseaux dans la même base ou une architecture de chemins personnalisée demande un plan supplémentaire. Ne cumulez pas ces transformations avec la conversion de type.

Dans le sens sous-répertoires vers sous-domaines, préparez chaque nouvel hôte dans la zone DNS faisant autorité et dans le panneau des domaines de l’hébergeur. Tous doivent être servis par l’installation WordPress commune, avec un certificat valable pour les noms utilisés. Pour quelques sites créés manuellement, un wildcard DNS n’est pas une obligation systématique. La politique de création à la demande peut changer ce besoin.

Dans le sens inverse, vérifiez que le serveur transmet correctement les chemins des sous-sites à WordPress et qu’aucun répertoire réel ne détourne ces requêtes. Conservez les anciens hôtes disponibles pour leurs futures redirections HTTPS : un visiteur doit établir la connexion TLS avant de recevoir une redirection. Le contrôle attendu est que chaque nouvelle adresse atteint le serveur prévu. Il ne prouve pas encore que WordPress sélectionnera le bon sous-site ; cette étape vient avec ses adresses et ses règles cohérentes.

Coordonner la constante et les règles du type cible

Sur la copie, le mainteneur conserve les fichiers précédents puis prépare un ensemble correspondant au type cible : SUBDOMAIN_INSTALL vaut true pour les sous-domaines et false pour les sous-répertoires. Il ne change pas le domaine principal ou le chemin réseau lorsque ceux-ci restent identiques dans le plan. La constante n’est qu’un des éléments de cet ensemble.

Pour Apache, utilisez les règles multisite adaptées à la version, au type et au chemin réel de l’installation ; les instructions de configuration réseau sont personnalisées. Remplacez le bloc WordPress concerné, en préservant les règles propres à l’hébergement et les protections légitimes. Un extrait trouvé pour un autre réseau ne constitue pas une configuration complète.

Pour Nginx, le responsable adapte la configuration effectivement chargée par le service. L’essai suivant vérifie sa syntaxe et l’ouverture des fichiers référencés ; le binaire et les paramètres doivent correspondre au service réel. Un succès ne vérifie ni les contenus ni la sélection du site. Le rechargement suit ensuite la procédure de l’hébergeur, après validation. À la moindre erreur de syntaxe, restaurez le fichier préparé plutôt que de recharger une configuration invalide. Les adresses stockées doivent aussi être transformées avant les contrôles fonctionnels de la conversion.

1. Préparer les règles du type cible et l’accès indépendant au panneau de maintenance.
2. Appliquer le lot de modifications dans une fenêtre fermée de recette, avec un instantané de retour.
3. Si le serveur refuse la configuration ou que le tableau de bord réseau ne répond plus, restaurer la recette et corriger l’ordre des étapes.

nginx -t

Mettre à jour les sous-sites existants, puis comparer leurs options

Dans la copie, le super administrateur ouvre Administration du réseau, Sites, puis Modifier pour chaque sous-site ordinaire prévu au relevé. Dans Informations, il saisit la nouvelle Adresse du site (URL) complète et enregistre. L’identifiant du sous-site doit rester le même. Les sites au domaine personnalisé conservé sont traités comme des exceptions explicites. La fiche du site principal ne sert pas à transformer arbitrairement son domaine.

L’écran Informations peut mettre à jour home et siteurl séparément. Dans le code consulté, il compare l’hôte et le chemin de chaque option à ceux de l’ancienne fiche. Une valeur personnalisée peut rester en place. Relevez les deux valeurs avant et après. Avant de lire les options en ligne de commande, vérifiez le chemin et la base de recette, puis exécutez uniquement la première ligne ci-dessous. Elle affiche l’identifiant du site chargé par WP-CLI pour la nouvelle URL. Dans cet exemple, il doit être 3, tel que relevé dans l’inventaire. Si l’identifiant diffère ou si le chargement échoue, arrêtez et vérifiez le ciblage. Exécutez les deux lectures seulement après cette concordance. Le résultat WP-CLI ne valide pas le routage HTTP.

Dans un réseau standard, les valeurs doivent correspondre aux URL prévues pour ce sous-site. Si une ancienne valeur subsiste, examinez l’onglet Réglages de la fiche réseau du site et les personnalisations éventuelles avant de corriger uniquement l’option identifiée, avec sauvegarde de sa valeur précédente. Une différence délibérée liée à une installation particulière ne doit pas être effacée. N’ajoutez pas de constantes globales WP_HOME et WP_SITEURL pour imposer une même adresse à tous les sites. Si l’accès réseau se perd pendant l’essai, restaurez la copie et corrigez le déroulé avant de recommencer.

1. Ouvrir le sous-site par son identifiant dans Administration du réseau → Sites → Modifier.
2. Sur la copie, changer uniquement la fiche qui correspond à cet identifiant et vérifier l’URL attendue.
3. Confirmer l’identifiant chargé par WP-CLI avant de lire home et siteurl. Comparer les options à l’inventaire et expliquer les écarts.

wp --path='/chemin/copie-wordpress' --url='https://reseau.example/atelier/' eval 'echo get_current_blog_id(), PHP_EOL;'
wp --path='/chemin/copie-wordpress' --url='https://reseau.example/atelier/' option get home
wp --path='/chemin/copie-wordpress' --url='https://reseau.example/atelier/' option get siteurl

Examiner les liens internes avec une simulation limitée

Les adresses de routage et les références stockées dans les contenus sont deux ensembles différents. Une fiche de sous-site correcte peut laisser des images, menus ou blocs pointant vers l’ancien hôte. Commencez par observer quelques liens cassés, puis déterminez les tables et les composants qui stockent réellement ces références. Les options d’un constructeur ou d’une extension peuvent nécessiter une procédure particulière.

WP-CLI sait traiter des données PHP sérialisées. L’exemple limite la simulation aux deux tables d’un sous-site fictif. Vérifiez d’abord le chemin et la base de la copie, l’identifiant chargé par WP-CLI et les noms exacts des tables de ce site. Remplacez les exemples par les valeurs de l’inventaire. WP-CLI charge WordPress pour ce type de commande. L’isolation des services externes et du cache reste nécessaire, même avec --dry-run.

L’option --dry-run produit un relevé sans enregistrer les remplacements. L’exclusion de la colonne guid préserve ce champ d’identification. Lisez les correspondances et vérifiez que les tables appartiennent bien au sous-site visé. Le mainteneur ne passe à une écriture ciblée qu’après sauvegarde, validation de la sélection et essai de son retour arrière. Les options, menus et données de composants hors de ces tables restent à examiner séparément. Un résultat de simulation n’est ni une migration de toutes les tables ni une preuve que chaque lien public fonctionne.

La barre finale fait partie de la chaîne recherchée. Elle exige une barre après l’ancien hôte dans la chaîne, sans limiter le remplacement à des URL placées au début d’un champ. Le relevé peut inclure une adresse dans du texte, un attribut ou une valeur sérialisée. Vérifiez séparément les liens vers la racine sans barre finale, les variantes HTTP et les URL encodées. Les tables sans clé primaire peuvent être ignorées. Si le relevé ou le rendu diverge, revenez au point de retour de recette plutôt que d’inverser un remplacement général.

wp --path='/chemin/copie-wordpress' --url='https://reseau.example/atelier/' search-replace 'https://atelier.reseau.example/' 'https://reseau.example/atelier/' wp_3_posts wp_3_postmeta --skip-columns=guid --dry-run

Préparer des redirections qui préservent chaque destination

Une fois les nouvelles adresses fonctionnelles sur la copie, préparez la correspondance des anciennes URL publiques. Un article doit rejoindre son équivalent, et non l’accueil principal du réseau. Vérifiez les chemins, la pagination utile, les fichiers téléchargés et les paramètres dont les fonctions du site ont besoin. Certaines destinations méritent une règle spécifique plutôt qu’une transformation mécanique.

Le responsable des redirections choisit la couche déjà utilisée : panneau d’hébergement, serveur Web ou composant maintenu pour cette fonction. Il sauvegarde les règles initiales et ajoute les nouvelles correspondances sans conserver une règle inverse qui créerait une boucle. Les redirections permanentes ne sont déployées publiquement qu’après confirmation de la destination finale. Elles peuvent être mémorisées par les navigateurs et demandent donc une attention particulière au retour arrière.

Pour les domaines et chemins qui restent inchangés, aucune redirection de migration ne doit être ajoutée sans nécessité. Contrôlez que la règle ne capture pas les domaines personnalisés conservés ni les URL d’administration. Les requêtes de formulaires et les retours d’authentification doivent suivre le comportement prévu par leurs composants, pas une règle globale appliquée à tous les échanges. Le résultat attendu est une destination correcte, sans chaîne inutile ni changement vers le mauvais sous-site.

Valider les contenus, les connexions et les cas limites

Utilisez l’inventaire préparé pour ouvrir, sur la copie, l’accueil, un article et une image de chaque catégorie de site. Comparez le contenu et le titre du sous-site, pas seulement le code de réponse. Une page du site principal affichée à la place d’un sous-site est un échec, même sans message d’erreur. Vérifiez également un ancien lien à travers sa redirection.

Dans un profil de navigateur réservé aux essais, connectez-vous comme utilisateur autorisé, ouvrez l’administration puis rechargez-la. Le changement entre hôtes et chemins peut modifier la portée des cookies. Si la session boucle, observez le domaine et le chemin des cookies et comparez les constantes personnalisées ; n’assouplissez pas globalement leur sécurité. Gardez un accès de maintenance indépendant du navigateur pour restaurer la copie.

Contrôlez aussi le site principal : les préfixes des articles et les collisions avec les nouveaux chemins demandent une attention spécifique dans une structure en sous-répertoires. Les médias d’un ancien réseau peuvent suivre des conventions différentes de celles d’une installation récente. Ne déplacez pas tous les répertoires uploads pour faire correspondre visuellement leur nom aux nouvelles URL. Documentez les cas qui échouent, corrigez leur cause précise, puis répétez seulement les contrôles concernés et leurs dépendances.

1. Vérifier l’accueil, un article et un média connus de chaque type de site.
2. Comparer les chaînes de redirection, le domaine et le chemin des cookies attendus et l’accès à une session de recette autorisée.
3. Inscrire par site le résultat et le critère précis de retour arrière.

Répéter la bascule et le retour sur le réseau fictif

Réservez un instantané de départ appelé A. Sur le réseau fictif reseau.test, l’identifiant 2 appartient à Atelier et l’identifiant 3 à Archives. Le site principal garde son adresse. Dans le sens sous-domaines vers sous-répertoires, l’accueil Atelier passe de http://atelier.reseau.test/ à http://reseau.test/atelier/. Son article /repere/ passe à /atelier/repere/. Faites le même relevé pour Archives. Ajoutez un média existant et l’accès à l’administration pour chaque site. Donnez aux contenus des repères différents pour détecter un mauvais aiguillage, même quand la page renvoie 200.

Notez également une adresse de domaine personnalisé à conserver, un chemin public du site principal à protéger et une ancienne URL sans destination. Si un article ou une page du site principal occupe déjà /atelier/, arrêtez la préparation et choisissez une autre correspondance. Gardez dans l’instantané A la base, les fichiers de la copie, la configuration du serveur et les règles de redirection initiales. Laissez les médias en place lorsque leur emplacement est déjà compatible. Relevez la valeur initiale de la constante et les valeurs enregistrées pour chaque site.

Sur la copie isolée, préparez le serveur pour les chemins cibles, puis appliquez ensemble la configuration réseau et les nouvelles adresses des sites du relevé. Confirmez pour chacune le même identifiant et les valeurs de home et siteurl prévues. Testez les destinations avant d’ajouter la redirection. Relevez ensuite le statut et l’en-tête Location des anciennes URL sans suivre la redirection. Vérifiez la destination séparément et comparez son contenu. Une règle provisoire 302 sur la copie permet d’ajuster ce relevé pendant la recette. Utilisez les réponses permanentes appropriées seulement quand les correspondances publiques sont validées.

Pour l’article Atelier, testez un lien ancien terminé par ?source=lettre. La destination attendue est /atelier/repere/?source=lettre si ce paramètre est utile. Testez aussi un ancien chemin sans équivalent. Il doit conserver le comportement prévu pour une page absente. Vérifiez les médias et l’administration avec un accès de recette séparé. Pour les nouveaux sous-domaines, consultez le diagnostic de résolution et d’état des sous-sites. Lorsque la résolution et l’hôte sont corrects, utilisez le guide sur les sous-sites en 404 pour un défaut qui reste localisé.

Le sens sous-répertoires vers sous-domaines se répète dans une branche séparée de la recette ou après un point de sauvegarde. Préparez les nouveaux hôtes et leur certificat pour les essais HTTPS. Reprenez les mêmes identifiants, remettez les chemins des sous-sites à / et vérifiez de nouveau chaque destination. Pour ce sens, l’ancienne adresse /atelier/repere/ doit rejoindre http://atelier.reseau.test/repere/ sur la copie HTTP. Activez les redirections d’un seul sens à la fois et protégez l’accès du site principal. Les URL historiques qui ont déjà changé une première fois doivent aboutir directement à la destination actuelle.

Déclenchez le retour de recette si un identifiant change, si un média connu manque, si un ancien lien mène au mauvais site ou si le réseau ne permet plus l’administration prévue. Fermez les écritures de la copie et rétablissez le lot A, y compris les redirections précédentes. Rejouez les témoins d’origine depuis un profil vierge. Si la copie contient des contributions produites entre-temps, conservez-les à part avant toute réimportation. Le retour est validé quand l’inventaire, les adresses historiques, les contenus repères et les accès attendus correspondent de nouveau à A.

• Relever les paires d’adresses, les identifiants, les exceptions et les témoins avant la bascule.
• Tester les nouvelles destinations avant les redirections, puis les anciennes adresses et les paramètres utiles.
• Répéter le sens inverse à part, puis restaurer A et vérifier les témoins initiaux.

Préparer la remise au responsable du réseau

La bascule publique ne commence qu’avec un déroulé répété sur la copie, ses fichiers exacts, sa correspondance d’adresses et son plan de retour. Choisissez un créneau adapté à l’activité. Préparez une sauvegarde cohérente récente et un relevé des écritures qui doivent être suspendues ou reprises. La décision ne repose pas sur le seul fait qu’un essai local a chargé une page.

Remettez au responsable la chronologie, les fichiers concernés, la correspondance des adresses, les variantes de redirection et les résultats obtenus sur la copie. Indiquez les points qui restent à confirmer pour l’environnement public, notamment les noms de production, le DNS et la portée des cookies. Le retour prévu doit couvrir ensemble données, configuration et routage. Précisez qui décide d’arrêter si des données ou un sous-site attendu manquent.

Enfin, mettez à jour les liens internes, les URL canoniques et les sitemaps concernés, puis surveillez les erreurs et les accès aux anciennes adresses. Le référencement peut fluctuer pendant la découverte des nouvelles URL ; aucun délai fixe ne garantit sa stabilisation. Conservez le relevé de correspondance et la procédure de maintenance pour les prochains changements.