Historique des versions

Six agents en parallèle ont relu ligne-à-ligne ~50 000 lignes de code (backend Python + frontend SvelteKit + serveur MCP). Verdict initial : 40 P0 bloquants, 92 P1 dégradations UX, 56 P2 dette. Quatorze sprints de correction plus tard, le verdict global passe de RED à GREEN sur les 6 zones.

C'est la release qui ferme la dette accumulée pendant 18 mois de feature delivery. Pas de nouvelle feature visible — mais l'élévation de privilèges silencieuse via auto-heal, les 13+ MCP tools sans rollback de crédits, le webhook Stripe non-atomique, les tasks orphelines au shutdown Cloud Run, les 9 catch silencieux dans /reporting : tout est fermé. La prochaine itération produit redémarre sur des bases saines.

Un audit fonctionnel du reporting a révélé des incohérences entre le billing affiché (FAQ, CLI) et la réalité backend. En parallèle, l'analyse du schéma SOAP GAM a montré que les champs de tracking natifs (thirdPartyImpressionTrackingUrls, thirdPartyClickTrackingUrl, trackingUrls VAST) n'étaient pas exploités — on injectait tout dans le HTML. La v1.8 corrige ces deux axes et ajoute une couche d'audit/QA complète pour le tracking et l'archivage.

C'est la première release où le LLM peut autonomement diagnostiquer un problème de tracking (macros manquantes, cachebuster absent, vendor non détecté), le corriger via update_creative, et re-vérifier — le tout dans une seule conversation. Le contrôle pré-archivage empêche les erreurs irréversibles.

La question revenait en boucle dans les retours bêta : "Comment je consolide mes performances GAM sans quitter l'interface ?" Le Reporting Hub répond à ça directement. En parallèle, on a traité une dette technique sur la pagination — certains réseaux GAM dépassent les 500 line items, et les outils de liste retournaient des résultats tronqués sans avertir. Le paramètre fail_fast sur les batch operations répond lui à un besoin réel d'équipes qui veulent des déploiements partiels sans avoir à tout rollback.

C'est aussi la release où la CLI OrbiAds v1.0 sort officiellement. Deux ans à construire une infrastructure MCP, et finalement les premiers retours concrets nous ont montré qu'une partie des utilisateurs voulait juste un terminal et un cron job.

Le passage de prototype à production MCP a été le tournant de ce cycle. Pendant des mois, l'infrastructure SOAP était là mais le point d'entrée IA restait expérimental. Mettre le serveur MCP en production sur orbiads.com/mcp, avec une authentification OAuth2 propre et sans clé API à gérer, a changé la nature du produit. L'Inventory Explorer est né d'un constat simple : avant de déployer quoi que ce soit, les équipes AdOps ont besoin de comprendre ce qu'elles ont déjà dans GAM. La cartographie de l'inventaire était une étape manquante.

La refacto SOAP vers un package modulaire (pattern mixin) n'est pas visible pour les utilisateurs, mais elle a réduit le temps moyen de diagnostic d'un bug GAM de 45 minutes à moins de 10. C'est le genre de travail invisible qui change la vélocité long terme.

Avant cette release, déployer une campagne native dans GAM impliquait de jongler entre une dizaine d'écrans : créer l'ordre, les line items, uploader les assets, configurer le ciblage, associer les créatifs. Chaque étape était manuelle, chaque erreur nécessitait un rollback partiel. Le pipeline v1.3 automatise l'intégralité de cette séquence depuis un ZIP créatif. Le suivi en temps réel via SSE permet de voir chaque étape s'exécuter — pas juste un spinner qui tourne.

La décision d'utiliser FastAPI BackgroundTasks plutôt qu'un orchestrateur externe (Celery, Cloud Tasks) s'est avérée juste pour la taille actuelle du produit. Moins de moving parts, moins de surface d'attaque, latence réduite. On réévaluera si les volumes l'exigent.

La v1.0 répond à une question précise : peut-on connecter un agent IA à Google Ad Manager de façon sécurisée, sans exposer de clés de service, sans infrastructure à maintenir côté utilisateur ? L'authentification OAuth2 "on behalf of user" avec stockage des refresh tokens dans Cloud KMS était le pré-requis non négociable. Sans ça, tout le reste n'est que démonstration. L'onboarding en 2 étapes (connexion compte + réseau GAM) reflète cette priorité : réduire le chemin vers la première opération réelle.

Scale-to-zero sur Cloud Run dès le premier déploiement — pas parce que c'est la solution la plus simple, mais parce que payer pour des instances idle quand le produit est en phase de validation n'a aucun sens. Cette contrainte nous a forcés à bien architecturer les connexions dès le début.