Ce troisième palier ne remplace pas les fondamentaux du suivi des conversions Google Ads : il industrialise ce que la chaîne de mesure a déjà posé en amont, pas l’inverse.
Faut-il l’API, les scripts ou l’interface ?
Trois paliers d’automatisation existent ; le critère pour choisir n’est pas la taille du compte, c’est l’inventaire des tâches refaites à la main chaque semaine.
Comment savoir si vous avez besoin de l’API Google Ads ?
La question « faut-il utiliser ce palier ? » est mal posée : elle commence par la solution. Commencez par l’inventaire : qu’est-ce qui, chez vous, se refait à la main chaque semaine à l’identique ?
L’export des coûts croisé avec le CRM. La vérification que le suivi reste en place. Le rapport mensuel assemblé colonne par colonne. La chasse aux campagnes qui dépensent sans convertir.
Chaque ligne de cet inventaire est une candidate à l’automatisation, et chacune a un palier approprié. L’accès programmatique n’est que le dernier.
Ce dernier niveau ne fait rien de nouveau. Il fait sans vous ce que vous refaites chaque semaine. La compétence rare n’est pas de savoir l’appeler : c’est de savoir quand un palier plus bas suffit.
API, scripts ou interface : quel palier choisir pour automatiser ?
Trois paliers, du plus léger au plus lourd. Chaque répétition de votre inventaire en vise un : le plus bas qui la couvre.
- Palier un : l’écran natif. Rapports planifiés, envois automatiques, règles simples : déjà là, déjà gratuits, étonnamment ignorés. La vérification hebdomadaire qui consiste à « regarder si tout va bien » se remplace souvent par un rapport qui arrive tout seul.
- Palier deux : les scripts Google Ads. Du JavaScript exécuté dans le compte, planifiable, sans serveur à maintenir ni jeton développeur. C’est le palier le plus sous-coté du marché : alertes de dépense, détection d’anomalies, par exemple une chute silencieuse des conversions importées, contrôles de cohérence, petits ajustements en masse. Un script de cinquante lignes, copié-adapté, peut remplacer des heures mensuelles, et beaucoup de besoins d’un compte unique s’arrêtent à ce palier.
- Palier trois : l’interface de programmation. Jeton, OAuth, code hébergé et maintenu, quotas et niveaux d’accès : quatre niveaux, du compte de test à l’accès standard, détaillés plus bas. Son territoire propre commence par la production de rapports à l’échelle : plusieurs clients, croisements lourds, alimentation d’un entrepôt de données et du tableau de bord LTV/CAC associé. Il inclut aussi l’extraction détaillée des données publicitaires lorsque le volume dépasse ce que l’écran permet, les applications qui interagissent avec Google Ads dans les deux sens et les opérations en masse que les scripts ne couvrent pas suffisamment.
Précision de périmètre : le flux de conversions relève d’une logique d’ingestion distincte. Depuis le 15 juin 2026, Google oriente les nouveaux téléversements de conversions hors ligne et de suivi avancé des conversions pour les prospects vers l’API Data Manager ; seuls certains jetons conservent un accès hérité à ces méthodes dans l’API Google Ads. L’envoi des conversions a sa page dédiée, avec ses identifiants, ses diagnostics et ses règles de déduplication.
| Palier | Infrastructure | Couvre |
|---|---|---|
| Interface | Aucune, déjà en place | Rapports planifiés, envois auto, règles simples |
| Scripts Google Ads | JavaScript dans le compte, sans serveur ni jeton développeur | Alertes, détection d’anomalies, contrôles, ajustements en masse |
| Interface de programmation | Jeton d’accès, OAuth, hébergement à maintenir | Rapports à l’échelle, intégrations, opérations de masse |
Monter au dernier palier sans avoir épuisé les scripts, c’est souvent de la sur-ingénierie. Le choix se fait sur un plafond constaté (« le script ne peut pas faire X »), pas sur une ambition.
Quelles sont les limites concrètes des scripts Google Ads que l’API dépasse ?
Les scripts couvrent l’essentiel, mais ils ont des plafonds précis. C’est sur ces limites, constatées en production, que le passage à l’accès programmatique se justifie.
La documentation officielle des limites fixe notamment 250 scripts par compte utilisateur Google ayant donné l’autorisation OAuth 2.0 et un temps d’exécution généralement limité à 30 minutes. Pour un script de compte administrateur utilisant executeInParallel avec une fonction de rappel, ce délai peut atteindre 60 minutes. L’autre plafond qui compte est fonctionnel : la couverture des objets et méthodes peut être plus restreinte, notamment lorsque les campagnes ou composants évoluent. Un script peut appeler des services externes, mais une application dédiée reste plus adaptée à un flux bidirectionnel maintenu avec un CRM, un ERP ou un entrepôt de données.
| Contrainte | Scripts Google Ads | Interface de programmation |
|---|---|---|
| Nombre de scripts | 250 scripts par compte utilisateur Google ayant donné l’autorisation OAuth 2.0 | Selon niveau d’accès et quotas |
| Durée d’exécution | 30 min max par script | Selon votre infrastructure |
| Objets récents / Performance Max | Couverture variable selon les objets disponibles | Couverture plus large, à vérifier dans la version active |
| Intégration CRM/ERP | Possible ponctuellement, moins robuste | Adapté aux appels bidirectionnels maintenus |
| Infrastructure requise | Aucune (dans le compte) | Jeton + OAuth + hébergement dédié |
Ces limites ne sont pas des bugs : les scripts ont été conçus pour la simplicité, l’interface de programmation pour la puissance. Le problème n’est pas le choix technique, c’est de monter jusque-là avant d’avoir atteint l’une de ces lignes.
Obtenir et calibrer son accès développeur
Cet accès et les niveaux qui vont avec sont deux problèmes distincts ; voici les deux étapes dans l’ordre.
Comment obtenir concrètement le jeton développeur Google Ads ?
La demande de jeton passe par le Centre d’API d’un compte administrateur Google Ads. Même si vous n’exploitez qu’un seul compte en production, c’est ce compte administrateur qui porte la demande et le jeton développeur.
- Créer ou vérifier le compte administrateur. La demande ne s’effectue pas depuis un compte publicitaire client ni depuis un compte administrateur de test.
- Ouvrir le Centre d’API. Accédez directement à ads.google.com/aw/apicenter avec le compte administrateur concerné.
- Décrire le cas d’usage. Renseignez l’application, les services prévus, l’adresse de contact suivie et les comptes liés, puis acceptez les conditions.
- Vérifier le niveau attribué. La demande peut aboutir directement à un accès Explorateur approuvé ou à un accès Compte de test en attente. Le premier ouvre un accès limité aux comptes de production ; le second reste limité aux comptes de test.
- Demander un niveau supérieur si nécessaire. L’accès de base porte le quota de production à 15 000 opérations par jour. L’accès standard lève ce plafond quotidien pour la plupart des services, sans supprimer les limites de débit et les quotas propres à certains services.
L’authentification s’installe en parallèle avec les identifiants OAuth 2.0 adaptés à l’application et les accès Google Ads correspondants. Elle reste distincte du niveau attribué au jeton développeur.
Quels sont les niveaux d’accès au jeton développeur et leurs quotas réels ?
Les niveaux d’accès documentés par Google structurent l’usage. Compte de test sert au développement, Explorateur ouvre un accès limité à la production, l’accès de base couvre la plupart des usages courants et l’accès standard répond aux volumes élevés. Pour demander l’accès standard, il faut déjà disposer de l’accès de base et justifier le besoin d’opérations quotidiennes illimitées.
| Niveau | Périmètre comptes | Quota d’opérations par jour | Délai d’examen généralement annoncé | Cas d’usage type |
|---|---|---|---|---|
| Compte de test | Comptes test uniquement | 15 000 | Automatique | Développement, validation d’intégration |
| Explorateur | Test + production | 2 880 (production) | Peut être automatique | Démarrage, tests sur compte de production, faible volume |
| Accès de base | Test + production | 15 000 | 5 jours ouvrés | Production stabilisée, compte unique ou portefeuille restreint |
| Accès standard | Test + production | Opérations quotidiennes illimitées pour la plupart des services | 10 jours ouvrés | Grande agence, outil multi-utilisateurs, chaîne de données décisionnelle |
L’accès Explorateur permet de commencer en production avec 2 880 opérations par jour, calculées sur 24 heures glissantes. Il restreint toutefois plusieurs services, notamment la création de comptes, la gestion des utilisateurs, la planification, la facturation et certains outils d’insights. Le choix du niveau dépend donc du quota et des fonctionnalités nécessaires, pas seulement du nombre de comptes.
Qu’est-ce que le GAQL et à quoi sert-il dans l’API ?
Le GAQL, un SQL propre à l’API
Le GAQL (Google Ads Query Language), fonctionnalité avancée propre à l’écosystème SEA, est le langage qui gouverne toute extraction personnalisée via cet accès. Sa syntaxe est proche de SQL : clauses SELECT, FROM, WHERE, ORDER BY, LIMIT. La différence avec un SQL générique est que les ressources interrogeables (campaign, ad_group, ad_group_ad, keyword_view…) sont définies par le modèle de données Google Ads, pas par vous. Ce que le GAQL aide à extraire est précis et documenté : si une dimension n’existe pas dans le schéma, elle ne s’extrait pas.
La console de prototypage officielle, Interactive Query Builder, aide à construire et valider une requête GAQL sans écrire une ligne. C’est le point d’entrée recommandé avant de monter une infrastructure.
SearchStream : pourquoi l’extraction en flux change l’échelle
Deux méthodes officielles exécutent une requête GAQL : Search (résultats paginés, jusqu’à 10 000 lignes par page) et SearchStream (flux continu, sans pagination côté client). Pour alimenter un entrepôt de données, BigQuery, Snowflake, Redshift, SearchStream est souvent la méthode à privilégier : elle évite de gérer la pagination et se prête mieux aux extractions volumineuses. Le choix entre l’accès de base et l’accès standard dépend ensuite surtout du volume d’opérations et du nombre de clients à traiter.
Quelles bibliothèques clientes choisir pour appeler l’API ?
Google publie des bibliothèques officielles pour six langages : Python, Java, PHP, Ruby, .NET et Perl. Des bibliothèques communautaires existent pour Node.js et Go. Par rapport aux appels HTTP bruts, les bibliothèques officielles encapsulent l’authentification OAuth et la sérialisation Protobuf. Elles implémentent aussi la pagination de Search et exposent, selon la bibliothèque et la méthode, des réglages de délai et de nouvelle tentative.
Python dispose d’une bibliothèque officielle et de nombreux exemples, mais ce n’est pas une exigence. Choisissez le langage selon la pile existante, les compétences de l’équipe, la maintenance prévue et la version de bibliothèque officiellement compatible avec la version de l’API.
Point de vigilance souvent raté : les bibliothèques clientes ont leur propre cycle, distinct du versionnement du service lui-même. Une bibliothèque trop ancienne peut ne pas supporter les ressources d’une version récente. Vérifiez la matrice de compatibilité avant toute montée de version.
Comment l’API s’intègre-t-elle avec un entrepôt de données ?
Un schéma fréquent relie Google Ads à un entrepôt de données, puis à un outil de visualisation : par exemple Google Ads → BigQuery → Looker Studio. Ce choix d’outils ne détermine pas, à lui seul, le niveau d’accès API.
SearchStream peut extraire les impressions, clics, coûts et conversions avec les dimensions nécessaires. BigQuery est une option de stockage et d’interrogation en SQL ; Looker Studio, Looker, Metabase ou Power BI peuvent ensuite restituer les résultats. Les coûts, la fréquence d’actualisation et la maintenance dépendent du volume et de l’architecture retenue.
L’export GA4 vers BigQuery peut compléter l’extraction publicitaire : l’un apporte les sessions et événements Analytics, l’autre les dépenses, impressions, clics et conversions Google Ads. Leur rapprochement exige des définitions, des clés et des périmètres temporels cohérents ; la simple présence des deux sources ne produit pas automatiquement une vue fiable.
Le critère d’accès reste le besoin réel. L’accès de base autorise jusqu’à 15 000 opérations par jour ; l’accès standard se justifie lorsque le volume prévu dépasse ce plafond ou que le service rendu à de nombreux utilisateurs exige des opérations quotidiennes illimitées. Un entrepôt de données ne suffit pas, à lui seul, à justifier ce niveau.
L’automatisation amplifie la qualité de la mesure, dans les deux sens
Toute automatisation exécute sa consigne, y compris lorsqu’elle est fausse. Un script d’alerte mal calibré crie chaque matin, puis on ne l’écoute plus ; une extraction automatisée sur une mesure cassée industrialise du faux.
L’automatisation amplifie la qualité de ce qu’elle touche, dans les deux sens. Tout ce qu’elle peut extraire, surveiller ou pousser vaut ce que valent le vocabulaire, la collecte via GTM, le consentement, la déduplication et les résultats commerciaux transmis en aval.
L’industrialisation est le toit. La mesure et le suivi restent les fondations, et c’est là que le pilier ramène.
- Le critère d’entrée à l’automatisation, c’est l’inventaire des tâches refaites chaque semaine, pas la taille du compte.
- Trois paliers : l’écran natif (rapports planifiés, règles), scripts Google Ads (JavaScript dans le compte, sans infrastructure), accès programmatique (jeton développeur, OAuth, hébergement à maintenir).
- Les besoins d’un compte unique s’arrêtent souvent aux scripts ; on ne monte au dernier palier que sur un plafond constaté.
- Le flux de conversions ne se traite pas comme le reste de ce canal ; et une mesure cassée, automatisée, industrialise du faux.
Par où commencer ce soir
L’inventaire, ce soir : vos répétitions hebdomadaires, listées. En face de chacune, choisissez le palier le plus bas qui la couvre et commencez par un script : l’alerte « conversions à zéro hier » est un premier investissement utile, parce qu’elle surveille directement le suivi des conversions.
Le dernier palier attendra son plafond constaté. La répétition, elle, n’attendra pas.
