Mots de passe d'application Gmail, IMAP et API : trois méthodes d'accès, et quand chacune fonctionne

Le problème Gmail le plus courant n’est pas un problème Gmail. Un client ou un script reçoit le mot de passe du compte, la connexion est refusée, et la conclusion évidente est que le mot de passe est faux. Il ne l’est pas. Google a cessé d’accepter les mots de passe de compte depuis les clients mail, et ce qu’il veut à la place, c’est un mot de passe d’application.

Les mots de passe d’application, et le prérequis dont personne ne parle

Un mot de passe d’application est un identifiant séparé, généré dans le compte, qu’un seul client utilise à la place du mot de passe de connexion. Trois choses à son sujet expliquent presque toutes les recherches « ne fonctionne pas » :

• Vous ne pouvez pas en créer tant que la validation en deux étapes n’est pas activée. C’est la réponse à la plupart d’entre elles. L’option pour générer un mot de passe d’application est tout simplement absente d’un compte sans second facteur, alors les gens cherchent une page qui n’existe pas encore. Activez d’abord la validation en deux étapes et l’option apparaît.
• Il n’est affiché qu’une fois. Généré, affiché, et plus récupérable ensuite. Le perdre signifie en générer un autre plutôt que de le retrouver.
• Il est affiché avec des espaces et saisi sans eux. Seize caractères en quatre groupes. Certains clients gèrent les espaces, d’autres non, et cela explique à lui seul une bonne part des échecs sur un mot de passe par ailleurs correct.

Ils sont générés dans la section sécurité du compte Google, pas dans les paramètres de Gmail lui-même, ce qui est l’autre raison pour laquelle les gens ne trouvent pas la page.

Si vous avez acheté un compte et que l’annonce mentionne un mot de passe d’application, c’est cette chaîne qui va dans le client. Le mot de passe de connexion du compte ne fonctionnera pas là-bas, et l’essayer à répétition, c’est ainsi qu’on attire une vérification supplémentaire dont vous ne vouliez pas.

Les trois façons d’entrer

Connexion web

Un navigateur, un mot de passe, un second facteur si configuré. Parfait pour une personne, mauvais pour un script. La connexion automatisée via le flux web se heurte à des défis, des invites d’appareil inconnu et parfois une vérification par téléphone, car ce flux est surveillé précisément pour ce schéma. Quand un script « ne peut pas se connecter » mais que les identifiants sont corrects, c’est généralement ce décalage qui est en cause.

IMAP et SMTP

Les protocoles mail, parlés par tous les clients mail et toutes les bibliothèques mail. Nécessite le mot de passe d’application décrit ci-dessus. Idéal pour lire une boîte mail, attendre un message ou envoyer, sans rien construire.

Réglages pratiques : IMAP sur 993 avec SSL, SMTP sur 587 avec STARTTLS, et l’adresse complète comme nom d’utilisateur. Notez que l’accès IMAP peut être désactivé par défaut sur certains comptes et activé dans les paramètres de Gmail lui-même, ce qui est un interrupteur séparé du mot de passe d’application et vaut la peine d’être vérifié quand l’identifiant est certainement correct.

L’API Gmail

Une interface programmatique propre, accessible via OAuth2. Vous enregistrez un projet, configurez un client OAuth, complétez un flux de consentement une fois, et recevez des jetons que votre programme utilise ensuite.

Deux vrais avantages sur IMAP : les permissions sont limitées, donc un programme peut recevoir un accès en lecture seule plutôt qu’un contrôle total, et vous obtenez des données de message structurées au lieu d’analyser du mail brut. Deux vrais coûts : la configuration est réellement plus lourde, et les écrans de consentement ont leurs propres règles de validation selon ce que vous demandez.

Utilisez-le pour quelque chose que vous construisez et maintenez. Pour lire un code dans une boîte mail, IMAP est la réponse proportionnée.

Choisir, en une ligne chacun

• Une personne qui consulte ses mails : le web, ou n’importe quel client via IMAP.
• Un script qui lit des messages : IMAP avec un mot de passe d’application. Configuration minimale, fonctionne partout.
• Un logiciel que vous construisez : l’API, pour des permissions limitées et des données structurées.
• Un script qui pilote l’interface web : à éviter. La friction que vous rencontrez est délibérée et ne disparaîtra pas.

Ce que cela signifie quand on achète une boîte mail

Deux champs sur une annonce correspondent à ce qui précède, et ce ne sont pas la même chose.

Un mot de passe d’application inclus signifie que le travail de validation en deux étapes et de génération est déjà fait et que vous pouvez connecter un client immédiatement. Une livraison OAuth2 est la voie API, et là, c’est la complétude qui compte : un jeton d’actualisation sans l’identifiant client et le secret contre lesquels il a été émis fonctionnera jusqu’à ce que le jeton d’accès actuel expire, puis s’arrêtera définitivement. Cet échec arrive bien après la fermeture de toute fenêtre de garantie, donc la vérification n’est pas « est-ce que ça se connecte maintenant » mais « est-ce que je peux effectuer une actualisation ».

Bon à savoir sur le prix : dans tout le catalogue email, l’accès par protocole est parmi les attributs les moins chers mesurés, tandis que les attributs de vérification comme la validation en deux étapes et la vérification SMS sont les plus chers, à environ trois fois le prix médian et près de trois fois respectivement. L’accès est bon marché ; être vérifié ne l’est pas.

Les annonces Gmail, avec les balises mot de passe d’application et OAuth2 filtrables, sont sur l’étagère Gmail.