Protéger ce qui est encore ouvert
Vous rédigez dans WordPress quand une fenêtre de connexion réapparaît. Le texte est encore dans l’éditeur, mais vous ne savez pas si les dernières modifications ont atteint le serveur. Laissez l’onglet ouvert. Évitez de le recharger, de fermer le navigateur ou d’effacer les données du site avant d’avoir mis votre travail à l’abri. Un titre marqué « enregistré » il y a quelques minutes peut correspondre à une version qui précède le dernier paragraphe.
Si l’éditeur le permet, copiez le titre et le passage ajouté dans un fichier de travail privé, sous un nom daté. Avec l’éditeur de blocs, si la commande Copier tous les blocs est accessible dans le menu d’options, vous pouvez aussi conserver leur structure. Vérifiez le contenu copié avant de fermer l’onglet. Si un composant ne se copie pas correctement, relevez séparément ses valeurs, les médias sélectionnés et ses liens. Sur une machine partagée, utilisez un emplacement approuvé auquel les autres utilisateurs n’ont pas accès.
Si la fenêtre de reconnexion masque l’éditeur, utilisez-la si vous reconnaissez l’adresse de connexion, ou rouvrez l’administration habituelle dans un autre onglet du même profil. Gardez l’onglet de rédaction en place. Si la session revient, copiez le passage encore visible avant toute actualisation demandée. Ne collez pas un brouillon confidentiel dans un service public pour l’enregistrer en urgence. Le premier objectif est une copie que vous pouvez relire sans dépendre de la session WordPress.
Rouvrir l’administration et comparer les deux versions
Dans un nouvel onglet du même profil, ouvrez l’adresse habituelle du tableau de bord et reconnectez-vous avec le compte qui rédigeait. En multisite ou lorsque vous gérez plusieurs sites WordPress.com, vérifiez aussi le site et l’article choisis. Un titre identique peut exister dans une autre copie. Comparez l’identifiant de l’article quand il apparaît dans l’adresse d’édition. Dans WordPress, ouvrez Articles ou Pages, trouvez le brouillon et examinez la version enregistrée, sans modifier l’onglet initial.
Relisez le début et la fin du passage où le problème est survenu. Si le serveur a déjà reçu la modification, évitez de la coller une seconde fois. Si une sauvegarde automatique ou une révision utile apparaît, comparez-la d’abord au contenu actuel. Selon l’éditeur et le contenu, l’historique peut inclure une version antérieure ou une proposition de récupération. Un texte qui n’a jamais quitté le navigateur peut manquer à cet historique. Votre copie locale et la version enregistrée se vérifient donc séparément.
Si le texte manque côté serveur, réintégrez d’abord le seul passage confirmé dans la version que vous avez rouverte. Gardez les modifications d’un collègue qui auraient été enregistrées pendant la coupure. Utilisez Enregistrer le brouillon ou l’action adaptée à l’état du contenu. Si vous travailliez sur un article déjà publié, convenez du mode de reprise avant une mise à jour publique. Vérifiez enfin le passage dans une nouvelle ouverture du contenu. Conservez votre copie de secours jusqu’à cette vérification.
Reproduire la coupure avec un brouillon de démonstration
Sur une copie WordPress, enregistrez un brouillon fictif, puis ajoutez un nouveau paragraphe. Relevez l’heure de connexion et celle de l’incident. Si vous avez besoin de comprendre une déconnexion, faites tester la session avec un compte de démonstration. Le mainteneur peut reproduire la perte de session sur la copie sans toucher aux comptes de travail. Comparez ensuite ce que voit encore l’onglet d’édition à la version que le serveur renvoie dans un autre onglet.
Dans l’essai local, le serveur a invalidé les sessions d’un compte fictif. L’administration demandait alors de se reconnecter, tandis que le texte en cours était toujours lisible dans l’éditeur ouvert. Le brouillon enregistré ne contenait pas encore ce passage. Après conservation du texte et reconnexion, le passage a été remis dans le même brouillon, puis enregistré et relu. Un essai séparé avec une durée courte sur la copie a reproduit une expiration réelle. Cette durée servait uniquement à la recette.
Sur votre site, utilisez une courte phrase de démonstration distincte du texte de travail. Vous devez pouvoir la reconnaître dans la version enregistrée et dans l’onglet ouvert. Pour revenir à l’état précédent après un essai volontaire, retirez cette phrase du seul brouillon de démonstration ou abandonnez la copie. Une fois le travail de rédaction sécurisé, poursuivez avec le parcours qui correspond au comportement observé.
Si la session se ferme à intervalles comparables
Notez l’heure de connexion, l’heure de la première erreur et ce que vous faisiez juste avant. Recommencez sur un brouillon de démonstration avec le même compte et la même adresse. Si le délai revient dans plusieurs profils, faites comparer le comportement à la durée prévue par le gestionnaire de connexion. Le site peut avoir une politique interne, une connexion unique gérée par l’organisation ou une règle d’extension. Une réauthentification après un délai constant oriente vers une échéance, tandis qu’une coupure isolée peut aussi suivre la révocation d’une session. L’heure seule ne permet pas d’établir la cause.
Sur un site auto-hébergé, le mainteneur peut comparer l’heure du serveur, la validité de la session et les règles qui personnalisent sa durée. Demandez-lui s’il y a eu un changement de mot de passe, une fermeture des autres sessions ou une intervention sur les accès au même moment. Conservez seulement le compte concerné, l’heure et le statut observé. La valeur d’un cookie, un jeton ou un mot de passe ne sont pas nécessaires pour ouvrir ce diagnostic. Sur WordPress.com, vérifiez de même si l’administration du même site demande une connexion dans un autre onglet du profil.
Si la politique est voulue, organisez la rédaction en fonction de cette durée. Enregistrez les étapes importantes et gardez une copie de travail lorsque le texte n’est pas encore prêt à être sauvegardé. L’option de mémorisation à la connexion dépend de la politique de l’organisation et du poste utilisé. Elle ne résout ni une session révoquée ni une bascule vers un autre domaine. Si le délai s’avère erroné, faites corriger la règle identifiée sur une copie puis vérifiez à nouveau la durée avant de l’appliquer.
Si la coupure n’apparaît que dans un navigateur
Après avoir protégé le brouillon, créez un profil navigateur vierge ou utilisez un navigateur de contrôle. Ouvrez exactement la même adresse d’administration et le même brouillon fictif. Comparez le résultat en gardant le compte, le site et le réseau constants. Un profil vierge demande normalement une nouvelle connexion au début. Vérifiez surtout que cette connexion tient pendant l’enregistrement d’une modification. Une fenêtre privée n’est pas forcément exempte d’extensions si certaines sont autorisées dans ce mode.
Si le profil habituel échoue et le profil propre tient, examinez les réglages propres au site dans le navigateur habituel. Vérifiez si une extension supprime les données de navigation, si le stockage du site est bloqué ou si le navigateur efface les cookies à la fermeture. Testez une seule modification à la fois. Si un nettoyage est nécessaire, attendez d’avoir mis le travail de l’onglet initial à l’abri, puis effacez uniquement les données du site identifié. Reconnectez-vous et vérifiez la sauvegarde d’un court texte témoin avant de reprendre le travail réel.
Pour annuler un réglage de contrôle, remettez son ancienne valeur ou fermez le profil de test. L’effacement de données locales ne se remonte pas comme une case à cocher. La copie du brouillon et une nouvelle authentification permettent de reprendre le travail. Si les deux profils échouent de façon comparable, reprenez le relevé des adresses et de la durée au lieu de recommencer les nettoyages.
Si l’adresse change en ouvrant ou en enregistrant
Relevez l’adresse de la page au moment de l’édition, celle du formulaire de connexion et celle de la requête d’enregistrement qui échoue, si elle est visible dans l’onglet Réseau. Comparez le protocole, le nom d’hôte et le chemin. Par exemple, votre tableau de bord habituel se trouve sur https://site.example.test/wp-admin/, mais un favori ouvre https://www.site.example.test/wp-admin/. Selon la configuration des cookies et des redirections, le navigateur peut présenter la session à l’un des noms et demander une nouvelle connexion sur l’autre.
Dans l’essai local, le profil authentifié ouvrait l’administration sur l’adresse attendue, tandis que l’autre nom de boucle locale et un profil vierge renvoyaient vers la connexion. Ces deux observations reproduisent des causes possibles sans prouver laquelle s’applique à votre site. Commencez par votre lien officiel d’administration et remplacez les favoris anciens. Sur WordPress.com, le domaine public et l’adresse d’administration peuvent différer selon la configuration du site. Vérifiez l’adresse d’administration indiquée par votre tableau de bord avant de conclure à une erreur.
En auto-hébergement, demandez au responsable de relever les valeurs de Réglages → Général et les éventuelles constantes WP_HOME et WP_SITEURL. Une installation en sous-répertoire peut utiliser deux adresses différentes volontairement. Vérifiez aussi la redirection du serveur et le protocole que le proxy transmet à WordPress. Faites corriger seulement la valeur responsable sur une copie avec un accès de secours. Si la connexion échoue après la correction, remettez la valeur initiale depuis l’accès prévu et testez de nouveau le chemin d’administration.
Vérifier si seule la sauvegarde échoue
Si vous pouvez encore ouvrir votre profil dans un autre onglet sur le même domaine, examinez l’erreur de l’éditeur avant de conclure que la session entière est fermée. Après avoir protégé le texte, reproduisez le problème sur un brouillon fictif. Dans les outils de développement, ouvrez Réseau, puis déclenchez une sauvegarde. Relevez l’adresse de la requête et le premier statut significatif. Une redirection vers la connexion sur plusieurs pages d’administration donne un indice différent d’un seul 403 lors de la sauvegarde. Un 403 peut aussi être lié à un contrôle de sécurité, à des droits sur le document ou à une information d’authentification devenue ancienne dans l’onglet.
Si une page rouverte après la reconnexion s’enregistre normalement, réintégrez la copie du passage dans cet éditeur rafraîchi. Si l’erreur subsiste, vérifiez avec un autre brouillon que vous êtes bien autorisé à modifier, dans le même site et avec le même compte. Une panne limitée à un seul document conduit à vérifier son état et les droits associés. Une réponse qui arrive en HTML alors que l’éditeur attend des données peut venir d’une page de connexion ou d’un intermédiaire. Relevez le type de réponse et le chemin, sans partager le corps d’un brouillon ni les en-têtes d’authentification.
Comparer les relevés sans exposer le texte ni la session
Pour transmettre l’incident, donnez l’heure, le fuseau, le navigateur, le nom du site, l’identifiant de la page si vous pouvez le communiquer en interne et l’action qui a échoué. Indiquez si le profil se chargeait dans un nouvel onglet, si la panne se produit dans un profil vierge et si le nom d’hôte a changé. Ces observations aident à séparer une échéance commune, une particularité du navigateur et une divergence d’adresse. Utilisez un brouillon de démonstration si le mainteneur doit reproduire l’erreur.
Les captures d’écran et exports réseau peuvent contenir des cookies, des jetons, le texte saisi et des informations sur d’autres sites. Préférez un relevé succinct des URL, statuts et horaires. Retirez les paramètres sensibles avant de le joindre à un ticket. Si un mot de passe a été changé ou qu’une session a été volontairement révoquée, notez seulement le moment et le périmètre de l’opération. Pour une coupure qui touche tous les rédacteurs, demandez de vérifier les journaux d’authentification et les changements récents avant de modifier la durée de session de tout le site.
Reprendre une séance de rédaction et vérifier le résultat
Après la correction confirmée, reconnectez-vous par le lien habituel. Ouvrez le brouillon témoin et enregistrez une petite modification. Fermez ce seul onglet après confirmation de l’enregistrement, puis rouvrez le document depuis la liste des articles. Vérifiez que le texte est présent, que le contenu garde son statut de brouillon et que l’adresse reste celle attendue. Si la coupure ne se produisait qu’après un délai particulier, testez aussi une session qui traverse ce délai selon la politique retenue.
Réintégrez ensuite la partie restante du vrai travail, en vérifiant les médias, les liens et la version conservée. Gardez la copie de secours le temps prévu par votre organisation, puis retirez-la de l’emplacement provisoire. Si le problème revient, comparez le nouvel incident au dernier relevé avant de changer un autre réglage. Le brouillon est récupéré lorsque la version relue depuis le serveur contient le passage attendu. Le diagnostic de session est terminé lorsque l’équipe peut reproduire le comportement voulu pendant une séance de rédaction normale.
Quand reprendre le brouillon à plusieurs
Si une autre personne doit poursuivre la rédaction, convenez d’une seule version de travail avant de remplacer un passage. Dans la liste des articles, identifiez le brouillon avec son titre et son identifiant. Notez quels paragraphes ont été copiés au moment de la coupure et l’heure à laquelle vous avez relu le serveur. Si WordPress signale que quelqu’un édite le document, contactez cette personne avant de reprendre la main. Vous pouvez lui transmettre uniquement le passage manquant par le canal interne prévu et lui demander de confirmer ce qu’elle a réintégré. Relisez ensuite la version enregistrée à deux endroits, au point de reprise et à la fin du passage, pour repérer une omission ou un doublon.
