Summary
[!note] 📚 Série Pré-lancement Pilotflow
- Le Mythe de l’Extension Gmail à 50 000 $
- Scopes OAuth Gmail Décryptés
- Revue du Code Avant le Développement
- Documents Légaux en 15 Minutes ← vous êtes ici
Dans le billet précédent, le travail de pré-développement était terminé : code examiné, architecture décidée, bugs consignés. Le produit devait maintenant être légalement publiable.
Google exige une URL de Politique de Confidentialité et une URL de Conditions d’Utilisation avant de pouvoir configurer un écran de consentement OAuth. Ces deux liens apparaissent sur l’écran de consentement que les utilisateurs voient lorsqu’ils installent votre extension. Ils ne sont pas optionnels — et ils ne sont pas décoratifs. Les examinateurs de Google les lisent.
La première fois que j’ai fait cela (pour Notiwise), cela m’a pris environ deux heures. Pour Pilotflow, cela m’a pris quinze minutes.
Pourquoi les Documents Légaux Importent Plus que Vous ne le Pensez
Les politiques de confidentialité vagues et génériques sont une raison courante pour laquelle Google rejette les soumissions au Workspace Marketplace. Une politique qui dit « nous pouvons collecter des données pour améliorer nos services » est très différente pour un examinateur de celle qui dit « nous lisons l’objet, l’expéditeur et la date des e-mails dans votre boîte de réception. Nous ne stockons pas le contenu des e-mails. »
La spécificité est importante. La précision est importante. Et pour les extensions demandant des permissions Gmail sensibles, les utilisateurs qui cliquent sur ces liens avant de consentir veulent comprendre exactement ce que l’extension peut et ne peut pas faire avec leur boîte de réception.
Les documents servent deux publics simultanément : les examinateurs de Google et vos utilisateurs. Les modèles génériques échouent pour les deux.
L’Investissement dans le Modèle Notiwise
Lors de la construction de Notiwise, j’ai passé deux heures à produire les documents légaux de zéro :
- Trouver des modèles SaaS appropriés
- Les adapter aux exigences de Google Workspace
- Les rendre précis pour ce que l’extension fait réellement
- Les formater pour le site web d’entreprise Jekyll
- Déployer et vérifier les URLs
Cette session de deux heures a produit plus que des documents — elle a produit des modèles Handlebars réutilisables avec le contenu spécifique au produit remplacé par des espaces réservés ,, ``. Le format, la structure, l’ordre des sections et les modèles de langage spécifiques aux scopes ont tous été capturés.
Pensez-y comme à construire une cuisine la première fois plutôt qu’à la deuxième. La première cuisine nécessite de tout concevoir. Chaque cuisine suivante hérite de la conception — vous n’avez qu’à meubler les pièces.
Le Processus Pilotflow : 4 Étapes, 15 Minutes
Étape 1 : Localiser les Modèles Notiwise (3 minutes)
Les modèles étaient documentés dans le fichier de projet Notiwise. Les trouver a pris moins de temps qu’ouvrir un document vierge.
Étape 2 : Identifier les Substitutions Nécessaires (8 minutes)
Pilotflow nécessitait des changements dans deux catégories seulement :
Identité du produit : Notiwise → Pilotflow by Zippy, URLs et email de support mis à jour en conséquence.
Langage spécifique aux scopes : La Politique de Confidentialité décrivait ce que chaque scope OAuth permet. Les sept scopes de Pilotflow différaient de ceux de Notiwise — donc les descriptions de scopes ont été réécrites pour correspondre.
Parce que l’analyse OAuth de pré-développement (couverte dans le billet 2) avait documenté exactement ce à quoi chaque scope accède, c’était une substitution mécanique — pas un travail de jugement.
Étape 3 : Déployer via l’API GitHub (4 minutes)
Le site web d’entreprise (BrightSoftwares/corporate-website) est un site Jekyll. Déployer du contenu ne nécessite pas de le cloner localement — l’API GitHub Contents crée des fichiers directement :
CONTENT=$(base64 -w 0 pilotflow-privacy-policy.md)
curl -s -X PUT \
-H "Authorization: token ${GITHUB_TOKEN}" \
-H "Content-Type: application/json" \
"https://api.github.com/repos/BrightSoftwares/corporate-website/contents/_pages/pilotflow-by-zippy-privacy-policy.md" \
-d "{\"message\": \"Add Pilotflow privacy policy\", \"content\": \"${CONTENT}\"}"
Les deux fichiers — Politique de Confidentialité et Conditions d’Utilisation — déployés à des URLs prévisibles :
https://bright-softwares.com/pilotflow-by-zippy/privacy/https://bright-softwares.com/pilotflow-by-zippy/terms/
Étape 4 : Vérifier (0 minute supplémentaire, intégré au flux de déploiement)
Après la construction par Jekyll (typiquement 2 à 3 minutes après le push), une vérification HTTP rapide confirme que les deux URLs retournent 200. Ces URLs vont directement dans la configuration de l’écran de consentement OAuth de la Google Cloud Console.
Ce que les Documents Légaux d’une Extension Gmail Doivent Réellement Couvrir
Pour quiconque construit la documentation légale d’une extension Gmail pour la première fois, voici ce que la spécificité requiert :
Politique de Confidentialité — les cinq sections qui comptent :
-
Ce à quoi vous accédez : Listez chaque scope OAuth en langage simple. « Nous pouvons voir et modifier les étiquettes appliquées à vos messages e-mail » (pour
gmail.labels), pas « nous accédons aux données Gmail ». -
Ce que vous stockez : Si vous ne stockez rien au-delà des clés PropertiesService, dites-le explicitement. Les utilisateurs craignent que le contenu des e-mails soit stocké. Si vous ne le stockez pas, affirmez-le directement.
-
Ce que vous en faites : La description fonctionnelle doit correspondre exactement au comportement réel de l’extension.
-
Suppression des données : Que se passe-t-il quand un utilisateur désinstalle ? Pour les extensions Apps Script, les clés PropertiesService sont effacées. Documentez le mécanisme spécifique.
-
Contact : Une adresse e-mail fonctionnelle que vous surveillez réellement. Pas un espace réservé.
Conditions d’Utilisation — la section que la plupart des extensions manquent :
Des clauses de responsabilité spécifiques aux actions de l’extension. Pour Pilotflow, cela incluait des clauses explicites sur l’archivage des e-mails (que se passe-t-il si une action d’archivage déplace un e-mail dont l’utilisateur avait encore besoin) et le transfert (que se passe-t-il si une règle de transfert envoie quelque chose à un destinataire involontaire). Les modèles génériques de Conditions d’Utilisation n’anticipent pas ces scénarios.
Points Clés à Retenir
- Les examinateurs de Google lisent vos documents légaux. Les politiques génériques représentent un risque de rejet.
- La première fois que vous créez des documents légaux pour une extension Gmail, cela coûte environ 2 heures. Chaque extension suivante coûte environ 15 minutes — si vous avez correctement créé des modèles à partir du premier jeu.
- L’API GitHub Contents vous permet de déployer du contenu Jekyll sans cloner le dépôt. Précieux pour tout flux automatisé ou sans interface.
- Le langage spécifique aux scopes dans votre Politique de Confidentialité nécessite de savoir exactement à quoi chaque scope accède — c’est pourquoi l’analyse OAuth en amont de la série est importante.
La Série Pilotflow — Complète
Cette série de quatre billets a couvert la recherche et la configuration complètes de pré-lancement pour une extension Gmail :
- Le Mythe CASA à 50K$ — Corriger le coût de certification et comprendre quand il s’applique
- Scopes OAuth Décryptés — La classification à trois niveaux et la distinction d’un mot qui compte le plus
- Revue du Code Avant le Développement — Lire avant d’écrire, et le bug qui attendait
- Documents Légaux en 15 Minutes ← vous venez de lire ceci
Prochainement : construction du système de génération d’assets qui crée des logos, des images de blog et des cartes sociales pour chaque produit du portefeuille.
← Précédent : Revue du Code Avant le Développement
— Kékéli
