Rétablir l’accès utilisé par le site, sans remplacer toute l’intégration
Une connexion qui fonctionnait cesse d’envoyer les notifications ou de communiquer avec un service. Le tableau de bord peut signaler une clé invalide, une autorisation expirée ou un accès refusé. Ces messages ne demandent pas tous une nouvelle clé. Une permission retirée, un compte différent ou un blocage de quota peut produire une panne proche avec une autre correction.
Le résultat recherché est le retour de l’opération prévue avec le compte, l’environnement et les droits nécessaires. Les exemples utilisent un transport existant dans WP Mail SMTP : Gmail pour une reconnexion OAuth, Brevo pour une clé API. Ils servent à réparer une connexion déjà choisie ; ils ne demandent ni nouveau fournisseur ni abonnement supplémentaire. Les mêmes distinctions aident avec d’autres intégrations, dont les menus restent propres à leur outil.
Gardez l’erreur exacte, l’heure et le nom de la connexion, en retirant les secrets. Un jeton ou une clé est un accès au service, pas un texte à coller dans un ticket public. Conservez les réglages initiaux et identifiez ce qui utilise le même accès avant de le révoquer. Une clé partagée avec une autre application peut couper cette dernière si vous la supprimez.
Le parcours exige un administrateur du site et une personne autorisée à gérer le compte externe. Ces rôles peuvent appartenir à deux membres de l’équipe. Sur une plateforme gérée ou un réseau multisite, vérifiez la portée des identifiants partagés. Commencez par une lecture de l’état existant, sans rejouer les opérations qui ont échoué.
Distinguer expiration, révocation, permission et quota
Relevez le code et le texte fournis par l’intégration, puis rapprochez-les de l’état du compte externe. Un statut HTTP 401 signale un problème d’authentification de la requête, mais ne donne pas à lui seul la date d’expiration d’une clé. Un 403 correspond à un refus d’accès et peut demander des droits, une autorisation du compte ou la levée d’un blocage précis. Le détail du fournisseur permet de les départager.
Un 429 indique une limitation de fréquence. Créer une nouvelle clé à chaque occurrence ne corrige pas le rythme des appels et peut compliquer le suivi. Respectez le délai de reprise annoncé lorsqu’il existe, puis examinez la fonction qui multiplie les demandes. Une erreur réseau ou de résolution de domaine précède parfois même la vérification des identifiants.
OAuth permet d’autoriser une application à agir dans un périmètre donné sans lui confier directement votre mot de passe. Son jeton d’accès peut expirer et être renouvelé automatiquement par l’intégration. Une reconnexion manuelle devient pertinente lorsque l’autorisation ou le mécanisme de renouvellement n’est plus accepté, par exemple avec un message invalid_grant confirmé dans ce contexte.
Une clé API peut au contraire avoir une date, être désactivée, avoir perdu des permissions ou ne plus être celle réellement utilisée. Comparez le nom et les derniers caractères affichés dans le service avec votre suivi privé. Une clé masquée composée de quelques caractères et de points n’est pas un secret complet à recopier dans WordPress.
Retrouver la connexion exacte et ses consommateurs
Dans WordPress, ouvrez l’extension responsable et identifiez le transport ou le compte sélectionné. Avec WP Mail SMTP, WP Mail SMTP → Settings → General indique le Mailer et ses paramètres. Notez aussi si d’autres connexions ou règles de routage sont configurées. Une clé corrigée dans une connexion secondaire ne répare pas nécessairement celle qui traite les notifications en panne.
Retrouvez le compte correspondant chez le fournisseur : organisation, projet, adresse autorisée et environnement public ou de contrôle. Une session du navigateur peut être ouverte sur un autre compte que celui du site. Avant toute reconnexion, vérifiez que vous avez accès au bon compte et au moyen de confirmation demandé pour une opération sensible.
Au contrôle du 3 novembre 2026, WP Mail SMTP by WPForms 4.10.3 est attribué à Syed Balkhi, exige WordPress 5.5/PHP 7.4 et déclare une compatibilité jusqu’à WordPress 7.1.4. Les parcours suivants utilisent ses connexions déjà présentes. Ils ne supposent pas les fonctions payantes de connexion en un clic, de secours ou de journal complet.
Pour une clé partagée, dressez la liste des applications qui l’emploient avant sa rotation. Si votre intégration utilise une valeur imposée dans une configuration, l’interface peut être grisée : la modification doit porter sur cette source, par la personne qui la maintient. Ne créez pas une deuxième extension pour contourner cette valeur. Vous devez aboutir à un accès précis, avec un périmètre et un responsable identifiés.
Approche 1 : renouveler l’autorisation OAuth Gmail existante
Cette voie convient lorsqu’une connexion Gmail déjà configurée dans WP Mail SMTP n’accepte plus son autorisation, notamment avec invalid_grant. Vérifiez d’abord l’adresse Google attendue et votre accès au compte. La reconnexion peut interrompre brièvement ce transport ; choisissez un moment où l’équipe peut surveiller les notifications, sans lancer en parallèle une série de tests.
Ouvrez WP Mail SMTP → Settings → General et retrouvez le mailer Google Workspace / Gmail. Dans Authorization, utilisez Remove OAuth Connection lorsque l’ancienne connexion doit être remplacée. Le code actuel emploie ce libellé ; certaines pages de documentation ou traductions affichent Remove Connection. Cette action permet de recommencer l’autorisation et ne doit pas servir à changer accidentellement de compte.
Cliquez ensuite sur Allow plugin to send emails using your Google account. Dans le parcours Google, sélectionnez l’adresse prévue et examinez l’application ainsi que les autorisations demandées. Accordez seulement l’accès correspondant à cette intégration identifiée. Si le compte, l’application ou le périmètre sont inattendus, interrompez le parcours et conservez l’erreur ; ne contournez pas un avertissement en supposant qu’il est sans conséquence.
Au retour dans WordPress, vérifiez l’adresse associée et l’état de connexion. Le résultat attendu est une autorisation active pour le compte voulu, puis un test contrôlé réussi. Aucun jeton ne doit être extrait manuellement du navigateur ni collé dans la page publique du site.
Le retour arrière d’une autorisation retirée ne consiste pas à ressusciter son ancien jeton. Si vous avez choisi un mauvais compte, retirez cette nouvelle connexion et autorisez de nouveau le bon compte. Gardez les paramètres du client OAuth existant pendant cette intervention ; refaire tout le projet Google n’est pas nécessaire pour une simple reconnexion.
Si l’autorisation échoue à nouveau peu après la reconnexion
Une reconnexion répétée indique qu’il faut examiner la durée de l’autorisation et la politique du compte. Pour certaines applications Google externes laissées en statut Testing, les jetons de renouvellement expirent après sept jours, sauf les cas limités prévus pour des informations de profil de base. Une intégration Gmail peut donc retomber en panne sans que son mot de passe SMTP soit en cause.
Demandez à la personne qui gère le projet Google de vérifier son statut, le compte autorisé et les exigences de publication ou de validation applicables. Ne transformez pas cette vérification en consigne de publier n’importe quelle application pour supprimer un avertissement. Le projet doit correspondre à l’usage réel et aux règles du fournisseur. Une politique d’organisation peut aussi limiter la durée d’une session ou les applications admises.
Une erreur de redirection demande de comparer l’adresse de retour indiquée par l’intégration avec celle configurée pour ce client OAuth. Elle ne se répare pas en générant des clés API d’un autre service. Conservez les valeurs initiales avant toute correction de projet et faites vérifier la connexion attendue.
Le résultat recherché est une autorisation qui reste utilisable selon la politique prévue. Si le diagnostic dépasse vos accès, transmettez le type d’erreur, l’heure, le projet et le compte concernés sans jeton. Évitez de supprimer le projet complet ou toutes les autorisations Google de l’utilisateur : d’autres applications peuvent en dépendre.
Approche 2 : vérifier d’abord si la clé Brevo est simplement désactivée
Cette voie convient à une intégration Brevo par API déjà utilisée. Dans le menu du compte Brevo, ouvrez Settings → SMTP & API → API Keys & MCP. Retrouvez la clé par son nom et ses derniers caractères, puis examinez son état, sa date d’expiration et sa dernière utilisation. Les clés API et les clés SMTP sont distinctes ; utilisez la catégorie correspondant au transport configuré dans WordPress.
Une clé sans date fixe peut avoir été désactivée pour inactivité. La documentation actuelle de Brevo indique cette désactivation après quatre-vingt-dix jours sans appel API réussi. Vérifiez que le site utilise bien cette clé, plutôt qu’une autre entrée du même compte. Une alerte visant une ancienne clé inutilisée ne prouve pas la cause de la panne du site.
Si la clé a été désactivée temporairement ou pour inactivité, que son usage est confirmé et qu’aucun problème de sécurité n’est signalé, le menu à trois points permet Activate API key. Contrôlez ensuite le résultat de l’intégration et l’état de la clé. Pour annuler cette réactivation, utilisez Deactivate API key sur cette seule entrée si son arrêt doit être maintenu.
Une clé verrouillée en lecture seule après un incident de sécurité n’est pas une simple expiration à contourner. Traitez le compte et remplacez l’accès selon la procédure du fournisseur. Si la clé est expirée, perdue ou ne doit plus être réutilisée, préparez une nouvelle clé avec le périmètre nécessaire avant de retirer les accès encore utiles.
Créer une nouvelle clé dédiée sans supprimer la précédente trop tôt
Dans API Keys & MCP, utilisez Generate API key avec le compte autorisé à gérer ces accès. Suivez la confirmation d’identité demandée. Donnez à Key name un nom qui identifie le site et l’intégration, puis choisissez une durée dans Expiry adaptée à la politique de votre équipe. La date doit pouvoir être retrouvée avant la prochaine échéance, sans conserver le secret dans une note ordinaire.
Choisissez un accès restreint aux ressources nécessaires, puis récupérez le secret au moment où il est affiché. Stockez-le directement dans l’emplacement privé prévu pour les identifiants de cette intégration. Les derniers caractères visibles dans la liste servent ensuite à reconnaître la clé ; ils ne permettent pas de reconstituer le secret perdu. Si vous avez fermé la vue sans l’enregistrer, créez une autre clé plutôt que de coller sa version masquée. Terminez cette étape avec I’ve saved my key après avoir vérifié que le secret est bien conservé.
Conservez une clé API standard pour l’intégration WordPress décrite ici. L’option de version MCP répond à un autre usage et ne doit pas être activée par simple curiosité au milieu de la réparation. Vous n’avez pas à ajouter un nouveau protocole pour rétablir le transport existant.
Lorsque l’ancienne clé reste valide et n’est pas compromise, le chevauchement avec la nouvelle permet de mettre à jour les consommateurs puis de vérifier la reprise. Si un accès a été exposé, son retrait relève au contraire de la réponse à cet incident ; ne le maintenez pas actif uniquement pour faciliter un retour arrière. Le résultat de cette étape est un nouvel accès identifié, conservé en privé et prêt à être installé au bon endroit.
Accorder les permissions nécessaires au lieu de confondre droits et expiration
Une clé reconnue peut encore être refusée pour la ressource demandée. Avec les permissions restreintes Brevo, chaque ressource commence sans accès. Un message Access denied for resource indique donc une piste différente d’un secret expiré. Relevez la ressource nommée et l’opération qui a échoué avant d’élargir les droits.
Pour Transactional email, la documentation actuelle distingue None, Read et All. Read permet la consultation mais ne permet pas l’envoi. Une intégration chargée d’expédier les notifications doit donc disposer du niveau permettant cette action sur cette ressource. Cela ne signifie pas qu’elle doit obtenir Full sur tout le compte, y compris les autres activités. D’autres fonctions peuvent demander une ressource supplémentaire ; ajoutez seulement ce qui est réellement nécessaire à l’intégration.
Pour corriger une clé existante, retrouvez son menu à trois points, choisissez Edit API key, effectuez la vérification demandée puis ajustez la permission identifiée et utilisez Save changes. Notez son niveau initial. Vérifiez ensuite l’opération prévue, dans un scénario témoin maîtrisé. Pour annuler l’élargissement, remettez le niveau initial si l’intégration n’en a pas besoin.
Les permissions d’une clé API ne remplacent pas les autorisations de l’utilisateur humain qui administre le compte. Elles ne s’appliquent pas non plus automatiquement à une clé SMTP. Si l’erreur persiste, confirmez que WordPress utilise bien la clé que vous venez de modifier : corriger les droits d’une autre entrée ne change rien à la requête refusée.
Mettre la clé dans la connexion qui l’utilise réellement
Dans WP Mail SMTP → Settings → General, retrouvez le mailer Brevo de la connexion concernée. Remplacez son champ API Key par le nouveau secret complet, dans cette interface privée, puis utilisez Save Settings. Conservez From Email et Sending Domain dans leur état prévu si le problème est uniquement l’accès API. Une nouvelle clé ne doit pas devenir un changement de domaine d’expédition non contrôlé.
Si le champ est imposé par une constante, le code actuel de l’extension peut signaler WPMS_SENDINBLUE_API_KEY. La personne qui gère la configuration doit mettre à jour cette source dans l’environnement prévu. Ne publiez pas la ligne contenant sa valeur et ne la transmettez pas dans une commande partagée. Une modification dans un champ sans effet sur la constante ne réparera pas la connexion.
Mettez également à jour les autres consommateurs identifiés de l’ancienne clé, ou donnez-leur leurs accès dédiés si c’est la décision retenue. Distinguez le site public et sa copie de contrôle. Les éventuels processus persistants ou caches de configuration propres à l’intégration doivent être pris en compte par leur mainteneur ; ne redémarrez pas tous les services de l’hébergement au hasard.
Le résultat attendu est l’utilisation effective du nouvel accès par la bonne connexion. Si la précédente clé reste valide, autorisée et non compromise, la valeur conservée en privé peut servir au retour temporaire. Sinon, corrigez le nouvel accès : une clé expirée ou révoquée ne redevient pas fonctionnelle parce que vous la recopiez.
Vérifier la reprise avec une opération témoin bornée
Commencez par l’état de connexion ou le contrôle prévu dans l’intégration. Pour le transport de courrier de l’exemple, WP Mail SMTP → Tools → Email Test permet ensuite d’envoyer un message unique vers une boîte que vous contrôlez. Cette action envoie réellement un courrier ; elle ne doit pas viser un client et ne nécessite pas de rejouer une commande ou une inscription.
Relevez l’heure, le résultat affiché et la réception. Chez le fournisseur, vérifiez la clé ou l’autorisation effectivement utilisée si l’outil fournit cette information. Un nouvel échec peut concerner une autre étape, par exemple l’expéditeur refusé ou une permission précise. Conservez son texte au lieu de conclure que la nouvelle clé est forcément mauvaise.
Pour une intégration qui lit des données, utilisez d’abord sa fonction de consultation ou de vérification de connexion, sans demander une synchronisation massive. Une connexion déclarée active ne prouve pas que tous les périmètres sont accessibles. Vérifiez l’opération représentative qui était interrompue, avec les droits nécessaires et un impact connu.
Après la reprise, examinez les tâches en attente avant leur relance. Certaines actions peuvent déjà avoir abouti malgré une erreur affichée au site. Le retour du transport n’autorise pas à réexpédier toutes les notifications ni à rejouer tous les paiements. Rapprochez les références des opérations et choisissez une reprise ciblée qui évite les doublons.
Retirer les anciens accès et noter la prochaine échéance
Une fois les consommateurs mis à jour et le contrôle réussi, mettez hors service l’ancien accès qui n’est plus nécessaire selon la procédure du fournisseur. Vérifiez son identité avant cette action. Si plusieurs applications partageaient la clé, confirmez leur migration avant son retrait. Une suppression définitive ne doit pas être utilisée comme premier test pour savoir qui en dépend.
Conservez dans votre suivi le nom de la connexion, son responsable, la date d’expiration prévue et l’endroit privé où le secret est géré. Une clé dédiée par intégration rend les prochains changements plus lisibles. Les données de suivi n’ont pas besoin de contenir la clé complète ni un jeton OAuth. Effacez les copies temporaires et les captures qui auraient exposé ces éléments selon les règles de votre équipe.
Si la panne revient, comparez sa date avec l’échéance, la dernière utilisation et les changements de compte ou de permissions. Une absence d’activité légitime n’appelle pas une série d’appels artificiels uniquement pour garder une ancienne clé vivante ; l’accès doit correspondre au besoin réel du service.
- Autorisation OAuth invalide : reconnecter le bon compte, puis examiner la politique si le problème revient.
- Clé désactivée : vérifier la raison avant une réactivation ciblée.
- Permission manquante : corriger la ressource et le niveau nécessaires.
- Clé remplacée : vérifier tous les consommateurs prévus avant le retrait de l’ancienne.
- Quota ou fréquence : traiter le rythme et les limites, sans renouveler les secrets au hasard.
- Connexion rétablie : contrôler séparément la reprise des opérations en attente.
Distinguer les refus sur un service simulé
Sur une copie isolée, l’API HTTP de WordPress a reçu quatre réponses d’un service local. Les libellés servent à lire la différence entre renouvellement, clé et permission. Les valeurs dépendent du fournisseur et de la route. Les libellés du banc ne décrivent pas le contrat de Gmail ou de Brevo.
Pour votre incident, rapprochez le code et le message exacts de la documentation du service. invalid_grant peut indiquer une autorisation expirée ou devenue invalide pour une autre raison. Un refus de droits peut persister après création d’une nouvelle clé si son périmètre reste identique. Une réponse 200 valide seulement l’opération de contrôle exercée.
400 invalid_grant Examiner l’autorisation OAuth existante
401 invalid_api_key Vérifier l’état de la clé et le compte
403 insufficient_scope Vérifier le droit demandé par cette opération
200 ok Confirmer le contrôle de lecture choisiVérifier une reprise sans rejouer les opérations
Dans le banc, chaque vérification a produit un seul identifiant de demande local. Aucun secret réel, envoi de courriel ou appel à un fournisseur n’a été utilisé. Sur votre copie, commencez avec le test de connexion ou la lecture que le service recommande. Vérifiez le compte et le périmètre qui répondent avant de lancer une action avec un effet métier.
Si des événements se sont accumulés, rapprochez leurs identifiants du journal de la destination avant de les reprendre. Relancez seulement un cas dont l’absence est confirmée, avec le mécanisme prévu par l’intégration. Si le test de connexion a rétabli un accès trop large ou le mauvais compte, retirez le changement et reprenez la configuration autorisée.
