rudy-io/building-ads-command-centers

Building Ads Command Centers

Objectif

Construire un cockpit publicitaire fiable pour Google Ads et Meta Ads. Préserver la provenance des chiffres, les différences entre plateformes, l'isolation des organisations et la sécurité des actions envoyées aux régies.

Classifier le produit avant de construire

• Reporting : connexion, synchronisation et lecture seule.
• Pilotage assisté : recommandations, prévisualisation, puis validation humaine des budgets, pauses et reprises.
• SaaS libre-service : OAuth multi-utilisateur, sélection des comptes, gestion des droits, facturation, conformité et support.

Ne pas promettre le troisième niveau si seuls une connexion administrateur et des tests simulés existent.

Commencer par le contexte réel

Inspecter le dépôt et l'infrastructure existants avant de choisir une stack. Recueillir les utilisateurs visés, le nombre de comptes, la fréquence de mise à jour, l'historique attendu, la source de vérité des conversions, les devises, les fuseaux horaires, l'hébergement et les contraintes de conformité.

Dimensionner la solution au niveau retenu. Pour un outil interne mono-organisation en lecture seule, une organisation unique, des rôles simples et un monolithe suffisent. Ne pas imposer OAuth libre-service, microservices, facturation ou workflow d'approbation sans besoin correspondant.

Charger les références utiles

• Toujours lire architecture-data-sync.md.
• Pour Google Ads, lire google-ads.md.
• Pour Meta Ads, lire meta-ads.md.
• Avant toute écriture externe ou mise en production, lire production-safety.md.
• Avant de déclarer le système terminé, appliquer les sections pertinentes de acceptance-checklist.md.

Les versions d'API, permissions, procédures d'examen et quotas changent. Vérifier les documentations officielles au moment de l'implémentation.

Workflow

1. Établir une matrice des capacités : plateforme, lecture/écriture, source, statut prouvé et limites.
2. Concevoir organisations, membres, rôles, connexions, comptes publicitaires et journal d'audit.
3. Implémenter d'abord les connecteurs en lecture seule et conserver la provenance brute.
4. Synchroniser par tâches idempotentes vers une base normalisée. Afficher fraîcheur, erreurs, couverture et contexte d'attribution.
5. Réconcilier un échantillon sur une période clôturée avec les interfaces natives Google et Meta.
6. Produire les recommandations par règles et calculs déterministes. Utiliser un LLM seulement pour les expliquer ou les reformuler.
7. Ajouter chaque écriture séparément avec prévisualisation, autorisation, limites, idempotence, audit, relecture distante et procédure de retour arrière.
8. Tester l'isolation entre organisations, l'expiration OAuth, les quotas, les reprises de tâches et les métriques manquantes.

Invariants

• Aucun secret dans le dépôt, le navigateur, les logs, les captures, les exports ou les prompts.
• Ne jamais additionner naïvement les conversions Google et Meta : conserver plateforme, action, fenêtre et modèle d'attribution.
• Une synchronisation planifiée n'est pas du temps réel.
• Ne jamais tester une mutation sur un compte de production sans autorisation explicite et périmètre précis.
• Qualifier chaque capacité : implémentée, testée en sandbox, validée en production ou partielle.

Livrable attendu

Fournir l'architecture et ses hypothèses, le schéma de données, les parcours de connexion Google et Meta, la stratégie de synchronisation, la matrice de permissions, les garde-fous d'écriture, les tests de réconciliation et le runbook d'exploitation. Séparer clairement ce qui est réalisé de ce qui reste à valider.