Summary
[!note] 📚 Série Pré-Lancement Pilotflow
- Le Mythe des 50 000 $ sur CASA
- Gmail OAuth Scopes Décodés
- Revue de Codebase Pré-Développement
- Documents Légaux en 15 Minutes ← vous êtes ici
Dans l’article précédent, le travail pré-développement était terminé : codebase revu, architecture décidée, bugs enregistrés. Il restait à rendre le produit légalement publiable.
Google exige une URL de Politique de Confidentialité et une URL de Conditions Générales d’Utilisation avant de pouvoir configurer l’écran de consentement OAuth. Ces deux liens apparaissent sur l’écran de consentement que les utilisateurs voient lors de l’installation de votre add-on. Ils ne sont pas optionnels — et ils ne sont pas décoratifs. Les examinateurs Google les lisent.
La première fois que j’ai fait ça (pour Notiwise), cela a pris environ deux heures. Pour Pilotflow, cela a pris quinze minutes.
Pourquoi les Documents Légaux Comptent Plus que Vous ne le Pensez
Les politiques de confidentialité vagues et génériques sont une raison courante de rejet des soumissions au Google Workspace Marketplace. Une politique qui dit « nous pouvons collecter des données pour améliorer nos services » se lit très différemment pour un examinateur qu’une politique 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 du corps des e-mails. »
La spécificité compte. La précision compte. Et pour les add-ons demandant des permissions Gmail sensibles, les utilisateurs qui cliquent sur ces liens avant de consentir veulent comprendre exactement ce que l’add-on peut et ne peut pas faire avec leur boîte de réception.
Les documents servent simultanément deux audiences : les examinateurs de Google et vos utilisateurs. Les templates génériques échouent pour les deux.
L’Investissement dans les Templates de Notiwise
En construisant Notiwise, j’ai passé deux heures à produire les documents légaux de zéro :
- Trouver des templates SaaS appropriés
- Les adapter aux exigences Google Workspace
- Les rendre précis par rapport à ce que l’add-on fait réellement
- Les formater pour le site corporatif Jekyll
- Les déployer et vérifier les URLs
Cette session de deux heures a produit plus que des documents — elle a produit des templates Handlebars réutilisables avec le contenu spécifique au produit remplacé par des placeholders ,, ``. Le format, la structure, l’ordre des sections et les patterns de langage spécifiques aux scopes ont tous été capturés.
Imaginez construire une cuisine la première fois versus la deuxième. La première cuisine nécessite de tout concevoir. Chaque cuisine suivante hérite de la conception — vous n’avez plus qu’à meubler les pièces.
Le Processus Pilotflow : 4 Étapes, 15 Minutes
Étape 1 : Localiser les templates Notiwise (3 minutes)
Les templates étaient documentés dans le fichier 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’avait besoin de modifications que dans deux catégories :
Identité produit : Notiwise → Pilotflow by Zippy, URLs et e-mail 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 — les descriptions de scope ont donc été réécrites pour correspondre.
Parce que l’analyse OAuth pré-développement (couverte dans l’article 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 corporatif (BrightSoftwares/corporate-website) est un site Jekyll. Déployer du contenu ne nécessite pas de le cloner localement — l’API Contents de GitHub 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 Générales — déployés vers 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 compilation Jekyll (généralement 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 dans Google Cloud Console.
Ce que les Documents Légaux d’un Add-on Gmail Doivent Vraiment Couvrir
Pour quiconque construit les documents légaux d’un add-on 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 courant. « Nous pouvons voir et modifier les libellés appliqués à 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, indiquez-le directement.
-
Ce que vous en faites : La description fonctionnelle doit correspondre exactement au comportement réel de l’add-on.
-
Suppression des données : Que se passe-t-il quand un utilisateur désinstalle ? Pour les add-ons 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 placeholder.
Conditions Générales — la section que la plupart des add-ons omettent :
Les clauses de responsabilité spécifiques aux actions de l’add-on. 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 non prévu). Les templates génériques de CGU n’anticipent pas ces scénarios.
Points Clés
- Les examinateurs Google lisent vos documents légaux. Les politiques génériques sont un risque de rejet.
- La première fois que vous créez des docs légaux pour un add-on Gmail, cela coûte ~2 heures. Chaque add-on suivant coûte ~15 minutes — si vous avez bien templarisé le premier jeu.
- L’API Contents de GitHub vous permet de déployer du contenu Jekyll sans cloner le dépôt. Utile pour toute automatisation ou workflow sans interface.
- Le langage spécifique aux scopes dans votre Politique de Confidentialité nécessite de savoir exactement ce à quoi chaque scope accède — c’est pourquoi l’analyse OAuth en amont de la série compte.
La Série Pilotflow — Complète
Cette série de quatre articles a couvert toute la recherche pré-lancement et la mise en place pour un add-on Gmail :
- Le Mythe des 50K sur CASA — Corriger le coût de certification et comprendre quand il s’applique
- OAuth Scopes Décodés — La classification en trois niveaux et la distinction d’un mot qui compte le plus
- Revue de Codebase Pré-Développement — Lire avant d’écrire, et le bug qui attendait
- Documents Légaux en 15 Minutes ← vous venez de lire ceci
Prochaine étape : construire le système de génération d’assets qui crée des logos, des images de blog et des visuels sociaux pour chaque produit du portfolio.
← Précédent : Revue de Codebase Pré-Développement
— Kékéli
