J’obtiens une notification d’erreur en essayant de configurer mon identifiant client Google OAuth2. J’ai réussi à le faire dans le passé et cela a toujours fonctionné. Avec ce nouveau compte Gmail que j’ai, j’obtiens toujours l’erreur :
Bonjour @Benjamin2
L’erreur que tu vois (« The attempted action failed, please try again ») provient en réalité de la Google Cloud Console elle-même, pas de n8n. C’est un message générique indiquant que le système de Google a rencontré un problème lors de la tentative d’enregistrement de tes paramètres de client OAuth. Cela se produit généralement à cause d’un conflit dans ton navigateur plutôt qu’à cause d’une erreur dans ta configuration n8n.
La cause la plus courante est d’être connecté à plusieurs comptes Google dans la même session de navigateur, ce qui confond souvent la Google Cloud Console. Pour corriger ce problème, la solution la plus rapide est d’ouvrir une fenêtre Incognito ou Privée et de te connecter uniquement au compte Google spécifique que tu utilises pour cette configuration. Si cela ne fonctionne pas, essaie de désactiver les extensions du navigateur (comme les bloqueurs de publicités) ou de vider le cache et les cookies de ton navigateur.
Denièrement, vérifie que tu as bien sélectionné « Web application » comme type d’application. Lorsque tu colles ton URI de redirection depuis n8n, assure-toi qu’il n’y a pas d’espaces accidentels au début ou à la fin du lien. Puisque tu auto-héberges via Hostinger, vérifie également que ta variable d’environnement n8n WEBHOOK_URL est correctement configurée et inclut le préfixe https://, car un protocole manquant peut amener Google à rejeter la demande.
Merci beaucoup @kjooleng pour les conseils. J’ai essayé tout ce que tu as dit
mais j’obtiens toujours la même notification d’erreur.
Puisque les modifications du navigateur ne l’ont pas résolu, j’arrêterais de traiter cela comme un problème d’n8n pour le moment et je testerais le projet Google lui-même. Si le même compte Google ou projet ne peut pas créer de client OAuth, le problème se situe probablement du côté de Google plutôt que dans n8n. Pouvez-vous confirmer s’il s’agit d’un projet tout neuf ou d’un projet réutilisé à partir d’une configuration plus ancienne ?
@OMGItsDerek merci beaucoup pour ta réponse.. c’est un tout nouveau projet. J’essaie en fait de le configurer pour une collègue qui travaille dans la même organisation que moi. J’ai bien vérifié :: je n’ai aucun problème quand j’ajoute un autre client dans ma console Google. Avec elle, je reçois toujours la même notification d’erreur. tu aurais des conseils pour résoudre ça ?
Salut @Benjamin2
En fonction de tes nouvelles informations, voici ce qui a pu se passer
L’erreur que tu vois est un message générique « fourre-tout », ce qui signifie que Google sait que quelque chose ne va pas mais ne te dit pas exactement quoi. Puisque tu peux créer des clients pour toi-même mais pas pour le nouveau compte de ton collègue, le problème n’est pas le processus lui-même, mais probablement un paramètre manquant ou une restriction liée à ce nouveau compte spécifique.
Le coupable le plus courant est l’« Écran de consentement OAuth ». Pense à cela comme le « paillasson » numérique que les utilisateurs voient quand ils se connectent. Chaque nouveau projet exige un écran de consentement entièrement configuré. Si l’un des champs obligatoires est vide ou n’a pas été « Enregistré et poursuivi » jusqu’au bout, Google t’empêchera de créer l’ID client.
Tu dois aussi vérifier les permissions du compte. Même si ton collègue fait partie de ton organisation, elle n’a peut-être pas le rôle « Éditeur » ou « Propriétaire » pour ce projet spécifique. Si elle a accès en tant que « Lecteur » ou avec un accès limité, la console pourrait lui permettre d’ouvrir la page de création, mais une erreur se déclenchera dès qu’elle essaiera d’enregistrer le nouvel ID.
Parce qu’il s’agit d’un tout nouveau compte Gmail, Google applique peut-être un « délai » de sécurité temporaire. Pour prévenir le spam, Google restreint parfois les nouveaux comptes dans la création de credentials de sécurité pendant quelques jours. De plus, assure-toi que l’app est définie sur « Interne » (pour ton entreprise uniquement) plutôt que « Externe », car les apps externes nécessitent un processus de vérification beaucoup plus strict.
Ne néglige pas les simples bugs du navigateur. La Google Cloud Console est très complexe et se laisse souvent dérouter par les anciens cookies ou les données en cache d’autres comptes. Un simple passage à une fenêtre « Incognito » ou « Privée », ou l’essai d’un navigateur complètement différent, efface souvent ces erreurs « fantômes » qui n’ont pas de cause technique claire.
Pour résoudre cela rapidement, commence par essayer une fenêtre Incognito. Si ça ne fonctionne pas, reviens à l’« Écran de consentement OAuth » et assure-toi que chaque page est remplie et enregistrée. Enfin, vérifie que ton collègue est listé en tant « qu’Éditeur » dans les paramètres IAM du projet. Si tout cela échoue, attends 24 à 48 heures pour que le nouveau compte soit pleinement approuvé par le système.
Cela se produit généralement lorsque l’URL du webhook ou l’URL publique n8n est incorrecte ou mal configurée, ce qui entraîne une génération incorrecte de l’URL de redirection OAuth.
Cela se produit sur les nouveaux comptes lorsque l’écran de consentement OAuth n’est pas configuré en premier. Avant de créer l’ID client :
Allez sur APIs & Services > OAuth consent screen et terminez cette configuration
Ensuite, allez sur APIs & Services > Library et activez l’API spécifique dont vous avez besoin (Gmail API, Google Drive, etc.)
Ensuite, créez les identifiants
Si vous avez déjà effectué ces étapes, essayez dans une fenêtre de navigation privée ; Google Cloud Console met parfois en cache un mauvais état qui bloque la création d’identifiants.
Accédez à vos paramètres OAuth Consent Screen dans la Google Cloud Console. Regardez le User Type. S’il est défini sur Internal, il rejettera instantanément quiconque n’a pas exactement le même domaine de messagerie que vous. Changez le User Type en External, enregistrez-le, puis essayez de les ajouter.
Faites-moi savoir si cela fonctionne, ou si vous avez tous les deux le même email.
J’ai le même problème, j’utilise ma callback URL et elle fonctionne, mais je ne sais pas comment surmonter ce problème inutile. J’ai connecté 3 authentifications Gmail à un seul compte, est-ce que ça pourrait être la raison pour laquelle Google me bloque ? Devrais-je héberger une nouvelle instance n8n ou quoi ?
Merci beaucoup @SE-automations mais je l’avais déjà mis sur external. j’obtiens la même erreur
@Oguzhan_Murat ce serait aussi mon 3e compte à connecter. Je n’ai jamais eu de problèmes avant mais avec celui-ci j’en ai. Je ne suis pas sûr que ce soit vraiment le problème
@Asim_Arman merci beaucoup. J’ai activé toutes les APIs dont j’avais besoin avant. malheureusement ça n’a rien changé. Le mode incognito n’a pas aidé non plus. c’est bizarre!
Hé, je suis super nouveau dans tout ça mais j’ai eu exactement les mêmes problèmes lors de la configuration qu’il y avait une erreur voici ma solution que j’ai trouvée avec l’IA j’espère que ça t’aidera 
Google n’autorise plus le domaine standard de Hostinger dans la zone de branding comme domaine de premier niveau. Il faut absolument y ajouter un domaine personnalisé.
La solution est simple : on utilise un domaine personnel, on crée une sous-domaine via un enregistrement CNAME (par exemple avec api. devant) et on l’ajoute dans le panneau Hostinger via l’éditeur .yaml. De cette manière, le domaine Hostinger disparaît et tout fonctionne parfaitement.
Pour vous orienter pour le reste de la liaison Google, cette vidéo vous sera utile :
Voici le résumé rapide des étapes :
1. Créer un enregistrement CNAME chez votre prestataire de domaine
Le site principal n’est pas modifié. Une sous-domaine est simplement créée chez votre fournisseur de domaine :
Type : CNAME
Nom d’hôte/Nom : api (ou une autre abréviation)
Cible/Valeur : L’adresse Hostinger complète avec un point à la fin (par exemple n8n.srvXXXXX.hstgr.cloud.).
Important : Laisser l’option « Sous-domaine ? » désactivée et ne pas oublier le point à la fin de l’URL !
2. Adaptation dans le panneau Hostinger
Pour que n8n utilise la nouvelle adresse, le projet Docker est modifié chez Hostinger :
Dans le menu VPS, aller dans Docker-Manager → Projets et gérer le projet n8n.
En bas dans la section Environnement (Environment), modifier les variables :
DOMAIN_NAME = votre-domaine.fr (Le domaine principal sans www ou https)
SUBDOMAIN = api (L’abréviation CNAME choisie)
Cliquer sur Enregistrer et déployer. Hostinger redémarre n8n et génère le certificat SSL.
3. Finaliser Google Cloud Console
Écran de consentement OAuth : Dans Domaines autorisés, ajouter maintenant votre domaine principal (par exemple votre-domaine.fr). Google accepte cette différence de niveau désormais immédiatement.
Identifiants : Dans l’identifiant client OAuth, sous URI de redirection autorisées, ajouter l’URL de rappel n8n avec le nouveau domaine : https://votre-domaine.fr
Je suis désolé que cela n’ait pas fonctionné, peut-être que cette solution fonctionnera :
Dans Google Cloud, accédez à l’onglet Écran de consentement OAuth. Sous Type d’utilisateur, si vous utilisez un compte @gmail.com standard, vous devez le laisser en tant qu’Externe mais rechercher la section État de publication. Assurez-vous qu’il est défini sur Mode de test (ne cliquez pas sur Publier l’application). Enfin, vous devez ajouter explicitement votre nouvelle adresse Gmail à la liste des utilisateurs de test juste en dessous. Si votre e-mail n’est pas sur la liste de test, Google bloquera la connexion.
Faites-moi savoir si cela fonctionne.
Bienvenue dans la communauté n8n @Benjamin2
Comme ça fonctionne sur votre compte mais échoue sur celui de votre collègue, je vérifierais les permissions/restrictions de Google Workspace ou je créerais le OAuth Client dans le projet en utilisant un compte avec le rôle Owner/Editor. Il suffit de copier l’OAuth Redirect URL de la credential Google et de la coller dans Authorized redirect URIs.
Si l’erreur persiste, veuillez partager votre json sans les données sensibles pour mieux comprendre le cas.
J’ai le même problème. Une identifiant Google Calendar qui fonctionnait jusqu’à il y a environ une semaine a soudainement cessé de fonctionner.
Ma application Google Cloud Console n’accepte plus les URLs Hostinger.
Salut à tous,
Merci beaucoup pour vos réponses. Au final, j’ai réussi à résoudre le problème.
Malheureusement, je ne peux pas dire avec certitude ce qui a exactement résolu le problème. Ma meilleure hypothèse est qu’il y avait quelque chose qui clochait dans la configuration du projet Google Cloud que j’avais créé.
Je n’ai rien changé dans Hostinger, les paramètres de domaine, ou quoi que ce soit de similaire pour le faire fonctionner. J’ai simplement réessayé et j’ai utilisé le projet par défaut initial, « My First Project », sans le renommer.
Tout à coup, tout a fonctionné.
Merci encore pour votre aide !
@albertocv pour le problème d’URL Hostinger - Google a commencé à appliquer une validation de domaine plus stricte pour les origines autorisées OAuth. Le correctif courant : assurez-vous que l’entrée Origines JavaScript autorisées correspond exactement à votre domaine Hostinger, y compris le protocole (par ex. https://yourapp.hostinger.com sans barre oblique finale), et ajoutez l’URL de rappel de votre instance n8n aux URI de redirection autorisés au format https://yourapp.hostinger.com/rest/oauth2-credential/callback. Si vous êtes sur un sous-domaine Hostinger, essayez également d’ajouter le domaine racine comme domaine autorisé dans l’écran de consentement OAuth.
Je vérifierais d’abord cela comme un problème de configuration Google Cloud OAuth, et non comme un problème de workflow n8n.
La checklist habituelle est :
1. Dans Google Cloud Console, confirmez que le type de client OAuth est « Application web » et non « Bureau ».
2. Ajoutez l’URL de redirection n8n exacte affichée dans votre écran de credential Google n8n à Authorized redirect URIs. Elle doit correspondre caractère par caractère, y compris http/https et tout chemin.
3. Si l’écran de consentement OAuth est encore en Testing, ajoutez le compte Gmail que vous utilisez parmi les Test users.
4. Activez les API requises pour la credential, par exemple Gmail API ou Google Sheets API selon le nœud.
5. Après avoir modifié l’URI de redirection ou les paramètres de consentement, créez une nouvelle connexion de credential dans n8n au lieu de réutiliser une ancienne popup échouée.
Pour un n8n auto-hébergé, vérifiez également que votre URL n8n publique est stable et que WEBHOOK_URL / N8N_EDITOR_BASE_URL pointent vers le même domaine public que celui que vous utilisez dans le navigateur. Une incompatibilité crée souvent une URL de callback incorrecte.
Ceci peut être diagnostiqué de manière asynchrone à partir d’une capture d’écran masquée de l’URL de callback de la credential n8n et de la liste des URI de redirection OAuth de Google Cloud. Aucun accès au compte n’est nécessaire.
