Summary
[!note] 📚 Série Pilotflow : Construire une extension Gmail
- Le Mensonge à 50 000 $ qui a Failli Tuer Mon Extension Gmail — juin 2026
- Niveaux OAuth Gmail Décryptés ← vous êtes ici
- Analyse du Code Avant le Développement — juin 2026
- Documents Légaux pour les Extensions Gmail — juin 2026
Dans le billet précédent, j’ai raconté comment le mythe de la certification CASA avait failli tuer Pilotflow avant que j’écrive la moindre ligne de code. En résumé : le chiffre de 50 000 $ qui circule dans les forums de développeurs décrit l’option d’évaluation la plus coûteuse, pas la norme. Et surtout, une bonne conception des scopes permet souvent de contourner entièrement la restriction.
Mais comment savoir quel scope utiliser ? Cela nécessite de comprendre la classification en trois niveaux de Google — un système que la plupart des documentations d’extensions survolent à peine, laissant les développeurs le reconstituer à partir de messages d’erreur lors de la vérification OAuth.
Ce billet est l’explication claire que j’aurais voulu trouver en page un.
Trois Niveaux, Trois Conversations Différentes
Quand votre extension Google Workspace demande des scopes OAuth, Google les classe dans l’un de trois niveaux. Le niveau ne détermine pas seulement les données auxquelles votre application peut accéder — il détermine la conversation que Google a avec votre utilisateur lors de l’autorisation.
Niveau 1 : Scopes publics
→ Écran de consentement OAuth standard
→ Aucune vérification supplémentaire requise
→ Icône de bouclier bleu dans la boîte de dialogue de consentement
Niveau 2 : Scopes sensibles
→ Vérification OAuth requise (gratuit, 4-6 semaines)
→ Avertissement jaune/orange dans la boîte de dialogue de consentement
→ L'utilisateur doit accepter explicitement l'accès étendu
Niveau 3 : Scopes restreints
→ Certification CASA Niveau 2 requise (540 $–75 000 $+)
→ Avertissement rouge dans la boîte de dialogue de consentement
→ Les administrateurs d'entreprise peuvent bloquer l'installation
La différence d’écran de consentement a plus d’importance que la plupart des développeurs ne le prévoient. Un utilisateur qui voit un avertissement rouge lors de l’installation a une première impression fondamentalement différente de votre extension de celui qui voit un bouclier bleu. Avant de choisir un scope, il vaut la peine de se demander : à quoi ce scope ressemble-t-il pour mon utilisateur ?
À retenir : Le niveau de scope affecte les exigences de sécurité ET les signaux de confiance lors de l’installation. La couleur de l’écran de consentement est la première impression que l’utilisateur a de votre posture de sécurité.
Le Tableau des Scopes Gmail
Voici la classification des scopes Gmail que rencontrent le plus souvent les développeurs d’extensions :
| Scope | Niveau | Accès | Certification |
|---|---|---|---|
gmail.addons.current.message.readonly |
Sensible | Message actuellement ouvert uniquement | Vérification OAuth (gratuit) |
gmail.addons.current.message.action |
Sensible | Action sur le message actuel | Vérification OAuth (gratuit) |
calendar.addons.current.event.read |
Public | Événement de calendrier actuel | Aucune |
gmail.readonly |
Restreint | Boîte de réception entière (lecture) | CASA + OAuth |
gmail.modify |
Restreint | Boîte de réception entière (lecture + modification) | CASA + OAuth |
gmail.send |
Restreint | Envoyer en tant qu’utilisateur | CASA + OAuth |
Le schéma est clair : les scopes qui opèrent sur le contexte actuel (ce que l’utilisateur est en train de regarder) sont sensibles ou publics. Les scopes qui opèrent sur l’ensemble de la boîte de réception en arrière-plan sont restreints.
Cette distinction reflète une vraie différence de risque. Une extension qui peut lire l’e-mail actuellement ouvert est sous la supervision de l’utilisateur — l’utilisateur a choisi d’ouvrir cet e-mail, voit l’extension fonctionner dans la barre latérale et peut fermer les deux. Une extension avec accès complet en lecture à la boîte de réception peut exfiltrer l’historique des e-mails silencieusement, en arrière-plan, sans qu’aucune action de l’utilisateur ne la déclenche.
La Décision de Scope pour Pilotflow
Pour Pilotflow, le flux de travail principal de l’utilisateur est : ouvrir un fil de discussion → voir les informations dans la barre latérale → décider quoi faire. Ce flux correspond exactement à gmail.addons.current.message.readonly.
Ce qu’il ne correspond pas, c’est le traitement par lots en arrière-plan — lire les six derniers mois d’e-mails pendant que l’utilisateur fait autre chose. Ce n’est pas ce que Pilotflow doit faire pour l’utilisateur ; c’est ce que j’imaginais avoir initialement, parce qu’un accès plus large me semblait synonyme de plus de capacités.
Séparer « l’accès que j’imaginais avoir » de « l’accès que le flux de l’utilisateur nécessite réellement » est l’un des exercices de conception de scopes les plus précieux. La question à se poser est : que fait l’utilisateur au moment où mon extension s’exécute ? Si l’utilisateur lit un e-mail, le scope de message actuel est suffisant. Si l’utilisateur doit déclencher une action en arrière-plan, vous pouvez demander cette permission spécifique au moment du déclenchement — pas à l’avance.
[!note] Le piège du « au cas où » Demander des scopes larges « au cas où » vous en auriez besoin plus tard est l’erreur la plus courante dans la conception de scopes OAuth. Les autorisations inutilisées sont une responsabilité en termes de confiance, pas un filet de sécurité. Demandez ce dont vous avez besoin maintenant ; élargissez plus tard si un flux utilisateur spécifique le requiert véritablement.
La Stratégie du Statut de Test
Un défi pratique pendant le développement : les API à scope restreint peuvent se comporter différemment en test qu’en production, car votre application n’est pas encore certifiée. Google fournit un statut « Test » qui vous permet de tester avec des scopes restreints en utilisant un ensemble limité de comptes de test approuvés (jusqu’à 100 utilisateurs).
Pour Pilotflow, j’ai utilisé cette approche :
- Pendant le développement : Utiliser l’extension avec un compte Gmail de test ajouté à la liste approuvée
- Avant le lancement MVP : Compléter la vérification OAuth pour les scopes sensibles utilisés
- Après le lancement : Surveiller si des fonctionnalités à scope restreint sont demandées par de vrais utilisateurs avant d’investir dans une évaluation CASA
La stratégie du statut de test signifie que vous pouvez construire et valider le produit avec de vraies données e-mail avant de vous engager dans une voie de certification. Si les utilisateurs ne demandent jamais la fonctionnalité à scope restreint, vous ne payez jamais pour la certification.
Ce Qui Se Passe Si Vous Vous Trompez
J’ai vu deux modes d’échec :
Demander des scopes restreints avant la certification. Votre application échouera à l’examen de soumission du Workspace Marketplace. L’équipe de révision de Google vérifie les classifications de scopes par rapport au statut de certification. Si vous demandez gmail.readonly sans certification CASA, la soumission est rejetée — pas signalée, rejetée.
Demander des scopes sensibles sans vérification OAuth. Votre application entre dans un flux de consentement chargé d’avertissements. Les utilisateurs voient « Cette application n’a pas été vérifiée par Google » avec une option pour revenir en arrière. Certains utilisateurs continuent. Beaucoup ne le font pas. Le taux d’abandon sur les écrans de consentement non vérifiés est significatif — j’ai vu des estimations de 30 à 50 % d’abandon. Pour un outil B2B ciblant les utilisateurs en entreprise, le statut non vérifié peut également déclencher des blocages au niveau administrateur pour toute l’organisation.
[!info] Le calendrier de vérification à planifier La vérification OAuth prend 4 à 6 semaines. L’évaluation CASA prend 4 à 12 semaines selon le TAP et le type d’évaluation. Intégrez ce calendrier dans votre planification de lancement — pas comme une réflexion après coup une fois le code terminé.
Appliquer Ceci à Votre Propre Extension
Lors de la conception des scopes pour une extension Gmail Workspace, travaillez ces questions dans l’ordre :
- Que fait l’utilisateur quand votre extension s’exécute ? S’il lit un e-mail spécifique, commencez par les scopes de message actuel.
- Votre fonctionnalité nécessite-t-elle un accès en arrière-plan ? Si oui, cette exigence est-elle technique ou architecturale ? La conception peut-elle être ajustée ?
- Pour chaque scope que vous envisagez : Recherchez-le dans la documentation des Scopes OAuth 2.0 pour les API Google. Trouvez sa classification.
- Calculez le coût et le calendrier de certification pour les scopes restreints. Incluez cela dans le coût de votre MVP.
- Demandez-vous : le même résultat utilisateur peut-il être obtenu avec un scope moins invasif ? Souvent la réponse est oui — et le scope moins invasif offre également une meilleure expérience utilisateur sur l’écran de consentement.
Le prochain billet couvre l’analyse du code avant le développement — spécifiquement, ce que j’ai trouvé en analysant le code existant avant d’écrire une ligne de nouveau code, y compris un bug de concurrence qui aurait causé une perte de données silencieuse.
