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 ← vous êtes ici
- Documents Légaux pour Add-ons Gmail en 15 Minutes — 20 mars
Dans l’article précédent, j’ai cartographié les scopes OAuth de Pilotflow et établi la stratégie de lancement en Testing Status. La décision sur les scopes était prise. Maintenant : écrire le code.
Sauf que — je n’ai pas commencé à écrire du code. J’ai commencé à le lire.
Pourquoi Lire Avant d’Écrire
Le dépôt Pilotflow avait été démarré précédemment par un autre membre de l’équipe et existait dans un état partiellement construit. Avant d’ajouter quoi que ce soit de nouveau, la bonne décision était de comprendre ce qui était déjà là.
Cela semblait plus lent. C’était en fait plus rapide.
La revue systématique du codebase existant — avant d’écrire une seule ligne de nouveau code de production — a mis en lumière trois découvertes qui auraient été bien plus douloureuses à trouver après avoir construit par-dessus.
Ce que la Revue a Couvert
L’analyse comportait trois parties :
-
Comparaison des branches — La branche principale et une branche de développement secondaire (
backup-code-20260202) avaient significativement divergé. Comprendre ce qui existait dans chacune était essentiel avant de décider où construire. -
Inventaire des fonctionnalités — Quelles fonctionnalités existaient déjà ? Lesquelles étaient complètes ? Lesquelles à moitié construites ?
-
Traçage des flux — Pour chaque workflow principal, tracer le chemin d’exécution de bout en bout et identifier les points où des hypothèses pourraient se révéler fausses.
Découverte 1 : Les Branches Avaient Divergé
La branche principale contenait un scope OAuth et des fonctionnalités basiques d’étiquetage des e-mails.
La branche de développement contenait 4 146 lignes supplémentaires : un processeur d’e-mails avec transfert et actions par lot, un module d’utilitaires serveur, une interface dashboard complète, et un framework de tests end-to-end. Elle utilisait aussi sept scopes OAuth contre un sur la branche principale.
Aucune branche n’était « la bonne ». Mais elles devaient être comprises avant de décider la stratégie de fusion — parce que fusionner aveuglément aurait introduit soit une régression (perdre les fonctionnalités de la branche de développement), soit un gonflement des scopes (demander des permissions pour des fonctionnalités pas encore utilisées).
Leçon : Avant que tout développement non trivial commence, connaître l’état de chaque branche active. Ne pas supposer que main reflète l’intégralité du projet.
Découverte 2 : Un Bug de Retraitement Caché
Le cœur de Pilotflow est son moteur de traitement : scanner la boîte de réception, appliquer des règles aux e-mails correspondants, étiqueter les messages traités pour éviter de les retraiter.
Le libellé utilisé était pilotflow-processed. La logique vérifiait si ce libellé était présent avant de traiter un e-mail.
Le bug : les réponses créent de nouveaux messages dans le même fil. Quand quelqu’un répond à un e-mail traité par Pilotflow, la réponse arrive comme un nouveau message — sans le libellé pilotflow-processed. Pilotflow scanne alors à nouveau le fil, rencontre la réponse sans libellé, et traite le fil entier — y compris le message original qu’il avait déjà géré.
Cela n’était pas évident en lisant le code de la fonctionnalité. Ce n’était visible qu’en traçant le cycle de vie complet : e-mail arrive → traité et étiqueté → réponse arrive → fil ré-examiné.
La correction est architecturale : suivre les IDs de fil traités, pas seulement les IDs de message. Une fois qu’un fil a été traité, le passer entièrement lors des scans suivants indépendamment des nouveaux messages qui arrivent.
Trouver ceci avant de construire les fonctionnalités d’actions par lot a économisé un temps de débogage considérable. Le code d’actions par lot aurait hérité du même défaut — et l’aurait rendu bien plus difficile à isoler.
Découverte 3 : Le Framework Notiwise Était Réutilisable
C’était la découverte positive. Un projet précédent (Notiwise, un add-on de calendrier Google Workspace) avait produit un framework de lancement en 12 phases : une checklist standardisée couvrant la sélection des scopes OAuth, les templates de documents légaux, la configuration de l’écran de consentement OAuth, la structure de la vidéo de démonstration, et la soumission au marketplace.
Le chemin de lancement de Pilotflow était structurellement identique à celui de Notiwise. La recherche, les décisions, les documents — tout avait été fait une fois et soigneusement documenté. Utiliser ce framework pour la planification du lancement de Pilotflow a économisé environ 8–12 heures de réflexion sur les mêmes questions à partir de zéro.
C’est à quoi ressemble l’intérêt composé en développement logiciel : un investissement approfondi dans la documentation du processus la première fois rapporte des dividendes sur chaque projet suivant qui suit la même forme.
La Décision d’Architecture
Avec la revue du codebase terminée, la décision d’architecture était claire :
- Fusionner la branche de développement — les fonctionnalités valaient la peine d’être incluses, les ajouts de scopes étaient justifiés
- Corriger le bug de retraitement — suivre les IDs de fil, pas seulement les IDs de message, pour éviter le traitement dupliqué
- Utiliser les 7 scopes avec Testing Status — pas de réduction de scopes, pas encore CASA-ready ; validé et livré d’abord
La phase pré-développement a coûté une journée de travail concentrée. Elle a évité qu’au moins trois problèmes composés soient intégrés dans les fondations.
Une Simple Checklist Pré-Développement
Pour tout projet où vous construisez sur du code existant :
- Lire chaque branche active — ne pas supposer que main est complète
- Inventorier les fonctionnalités existantes (complètes vs. partielles vs. abandonnées)
- Tracer les workflows principaux de bout en bout avant de les étendre
- Chercher ce qui manque dans la fonctionnalité, pas seulement ce qui est présent
- Rechercher des frameworks réutilisables de projets passés similaires
Points Clés
- L’analyse pré-développement du codebase trouve les bugs que les nouvelles fonctionnalités hériteront — à une fraction du coût de les trouver après l’implémentation.
- La divergence des branches est un risque silencieux. Connaître l’état de chaque branche avant de choisir où construire.
- La documentation de processus des projets précédents est un actif. La réutiliser explicitement, pas accidentellement.
La Suite
Avec le codebase compris et l’architecture décidée, l’étape suivante était de rendre le projet légalement publiable : Politique de Confidentialité et Conditions Générales d’Utilisation. Toutes deux requises par Google avant que l’écran de consentement OAuth puisse être configuré. Toutes deux complétées en 15 minutes en utilisant les templates de Notiwise.
→ Suivant : Documents Légaux pour Add-ons Gmail en 15 Minutes
← Précédent : Gmail OAuth Scopes Décodés
— Kékéli
