Historique des versions

Une série d'améliorations ciblées au-dessus de la refonte v2.0, centrée sur la prise en main. L'installation d'OrbiAds est désormais documentée pour chaque agent IA majeur — la voie sans terminal (Claude Desktop, claude.ai, Cowork) et la voie par fichiers partagée par Codex, Cursor, Windsurf, Gemini CLI et Antigravity via la convention .agents/skills. Une correction du manifeste fiabilise la synchro du marketplace de plugins Claude.

Aucun changement cassant — c'est une version d'amélioration incrémentale. Si l'ajout du marketplace OrbiAds échouait auparavant, il fonctionne maintenant du premier coup.

Cette version marque la sortie du cycle V1 et la consolidation des fondations pour les prochaines briques produit. Trois chantiers structurants ont été menés en parallèle : (1) l'interface d'administration a été repensée autour d'un menu central qui regroupe par usage plutôt que par technologie, avec des liens contextuels qui suivent le parcours réel d'un AdOps ; (2) le serveur MCP est passé à une architecture parent/enfant qui ramène le catalogue public de 270 outils à 51 dispatchers cohérents ; (3) les traitements longs (génération de blueprint d'inventaire, export d'audit CSV, optimisation d'images) ont été déportés sur un service worker indépendant pour libérer le backend principal.

Le passage en v2.0 reflète l'ampleur du changement plutôt que l'arrivée d'une fonctionnalité spectaculaire — cette refonte rend chaque action quotidienne plus directe et fluide. Les pages d'audit affichent désormais un encart "endpoint en construction" lorsque la donnée n'est pas encore disponible, plutôt que des chiffres factices : nous préférons une honnêteté assumée à une démonstration trompeuse. Conséquence pratique du nettoyage : certaines URL et endpoints anciens ne répondent plus — voir la note de compatibilité en bas de release.

Les régies et agences multi-tenants nous ont remonté un besoin clair : pouvoir auditer la conformité de leur réseau GAM contre des standards reconnus (ISO 27001, IAB, NIST CSF) sans assembler manuellement des dizaines de requêtes. Cette release introduit un Skill d'audit que les agents IA peuvent exécuter en autonomie, plus une couche d'administration GAM complète (équipes, sites, applications, libellés). En parallèle, l'assistant de pricing analyse l'historique de performance pour suggérer les prix planchers optimaux, avec une garantie stricte : aucune donnée tenant n'est jamais stockée — tout est calculé en live.

Le choix de garder l'audit 100% MCP/CLI sans interface dashboard est délibéré : un audit de conformité est avant tout une checklist exécutée par un agent intelligent, pas un tableau de bord à scroller. Le rapport markdown qui en sort se partage par email, se versionne en Git, et tient sur une page A4 quand c'est nécessaire pour un comité de pilotage.

Les éditeurs et régies qui vendent en programmatique avaient besoin de structurer leur offre commerciale comme un véritable catalogue : formats, planchers tarifaires, audiences ciblées, conditions de réservation. Cette release introduit cette couche métier de bout en bout — modélisation backend, API REST, outils MCP et interface dashboard complète. En parallèle, le support natif des deals programmatiques (PMP via REST, PG/PD via SOAP) permet d'orchestrer la négociation et le déploiement de deals directs avec les acheteurs.

Le pont ADCP (AdContext Protocol) est probablement la pièce la plus stratégique de cette release. Il pose les bases pour qu'un agent IA acheteur — chez l'annonceur ou son agence — puisse parcourir le catalogue produits exposé par l'éditeur, puis négocier et déployer un deal sans frottement humain. C'est la couche manquante entre infrastructure ad-tech et automatisation IA véritablement end-to-end.

Le serveur MCP a longtemps été la première porte d'entrée pour les agents IA. La CLI, elle, avait grandi en parallèle pour couvrir les workflows scriptables : cron jobs, intégrations CI/CD, équipes qui préfèrent simplement un terminal. Mais les deux surfaces avaient pris des chemins légèrement différents. Cette release acte leur unification : chaque opération MCP a sa commande CLI miroir, chaque commande CLI a son outil MCP correspondant. La matrice de parité est désormais vérifiée automatiquement à chaque build.

Cette release a aussi été l'occasion de refactoriser trois services backend en couches plus modulaires (billing reports, création de line items, archivage d'inventaire). Travail invisible côté utilisateur, mais qui accélère significativement la livraison des prochaines features. Le repo public open-source est synchronisé automatiquement à chaque push interne.

Les éditeurs qui poussent fort en programmatique voulaient pouvoir simuler l'impact d'une nouvelle campagne sur les line items déjà servis — la fameuse contention mutuelle. Cette release introduit get_prospective_delivery_forecast en mode multi-LI, plus des splits de prévision (par jour, par device, par géo) et la prise en compte du traffic data réel. En parallèle, nous avons lancé deux audits live sur un compte de production : la première vague a remonté quatre bugs invisibles en environnement de test, la seconde quatre de plus. Tous corrigés, tous couverts par des tests anti-régression.

L'audit qualité de la phase 11 (38 corrections systématiques contre le schéma WSDL officiel) part d'un constat simple : il vaut mieux investir dans la rigueur des appels que dans des couches de récupération d'erreur. Quand vous appelez GAM avec exactement les bons paramètres typés, les bugs disparaissent à la racine plutôt que d'être rattrapés en runtime.

Avant chaque cycle d'expansion produit majeur, nous prenons le temps d'auditer en profondeur les couches critiques — authentification, facturation, pipeline de campagnes, reporting, frontend, serveur MCP. Cette release consolide ces fondations en six axes : sécurité durcie au niveau du protocole OAuth, restitution des crédits totalement idempotente, pipeline avec sauvegarde de progression et reprise après incident, et 9 micro-régressions UX corrigées sur l'interface. C'est la dernière étape avant l'arrivée du Catalogue Produits, des Deals Programmatiques et de la suite d'audit IA.

Cette release n'apporte pas de feature spectaculaire — c'est sa raison d'être. Elle ferme proprement la dette accumulée sur dix-huit mois de livraison rapide, pour que les prochaines fonctionnalités majeures s'appuient sur une plateforme dont chaque couche a été inspectée ligne à ligne. Le confort de construire vite vient de la rigueur d'avoir bien construit avant.

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ù un agent IA 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.