Un script Google Ads est du JavaScript qui s’exécute dans votre compte selon un horaire, sans personne pour le surveiller. La documentation de Google le dit sans détour : les scripts « provide a way to programmatically manage and query your Google Ads data using JavaScript in a browser-based IDE » (offrent un moyen de gérer et d’interroger vos données Google Ads de façon programmatique, en JavaScript, dans un environnement de développement intégré au navigateur), et ils s’exécutent « without needing an active user session » (sans avoir besoin d’une session utilisateur active). Vous écrivez le code une seule fois, dans l’éditeur intégré à l’interface, vous lui dites quand s’exécuter, et il continue de tourner, que vous vous reconnectiez ou non. Il peut aussi appeler des services externes — vérifier une URL, publier sur Slack, interroger une API météo — et si vous gérez plus d’un compte, le même script peut s’exécuter sur tous les comptes à la fois, par un compte administrateur.
C’est tout l’attrait en une phrase : de la main-d’œuvre gratuite qui n’a pas besoin de vous. Ce qui compte, c’est le genre de travail pour lequel elle excelle. Un script fait un excellent gardien et un piètre décideur, et la plupart des déceptions liées aux scripts Google Ads viennent du fait qu’on lui confie le deuxième rôle.
Ce pour quoi un script est vraiment bon : monter la garde
Les tâches où un script fait ses preuves partagent toutes la même forme — vérifier quelque chose, comparer à un seuil, avertir un humain. Aucune n’exige de jugement, et toutes sont assez ennuyeuses pour qu’une personne oublie de les faire à la main :
- Le rythme de dépense du budget. Un script vérifie les dépenses par rapport à la date du jour et signale une campagne en voie de dépasser son montant mensuel avant la fin du mois.
- Les URL de page de destination brisées. Il interroge chaque URL finale selon un horaire et signale celles qui renvoient une erreur, au lieu que vous l’appreniez trois semaines plus tard à cause d’un niveau de qualité en chute.
- Les annonces refusées. Il scanne le statut des annonces et envoie un message dès qu’une annonce est rejetée, plutôt qu’une semaine après qu’elle ait cessé de diffuser.
- Une hausse de coût sur un seul mot clé. Il compare le coût du jour à une moyenne mobile et signale l’anomalie avant que la facture ne le fasse.
- Zéro conversion là où il y en avait. Il repère une campagne qui convertissait de façon fiable et qui s’est tue — habituellement un bris de suivi, pas un problème de demande.
Rien de tout cela ne touche à une enchère. Chacun de ces exemples se termine de la même façon : un script envoie une notification, une personne décide quoi en faire. Cette répartition des tâches fait toute la différence entre un script qui vous fait gagner du temps et un autre qui aggrave discrètement les choses en ayant l’air automatisé.
Ce qu’il ne faut pas mettre dans un script : des règles par-dessus les enchères intelligentes
L’autre usage courant des scripts, c’est d’écrire des règles d’enchères — augmenter l’enchère si X, la baisser si Y, selon un horaire. C’est précisément là que les scripts méritent leur mauvaise réputation, et pour une raison mécanique précise : si le compte utilise les enchères intelligentes, une stratégie automatisée recalcule déjà les enchères à chaque enchère individuelle, à partir de signaux — appareil, heure du jour, audience, termes de recherche — qu’un script exécuté une fois par heure ne peut pas voir. Un script qui superpose sa propre logique d’enchères n’assiste pas ce système. Il s’y oppose, sur une horloge beaucoup plus lente, avec beaucoup moins d’information.
Le résultat est rarement spectaculaire. Ce sont simplement deux systèmes qui travaillent discrètement l’un contre l’autre, et le propriétaire du compte qui paie pour les deux. Si une enchère a vraiment besoin d’un ajustement par règle, c’est une raison de regarder du côté des limites d’enchères ou des réglages de stratégie de portefeuille dans l’interface — pas une raison d’écrire du JavaScript qui répète, mal, ce que les enchères intelligentes font déjà en continu. L’argument plus large pour automatiser est développé dans pourquoi l’automatisation compte pour les agences.
La partie qui n’est pas vraiment gratuite
L’argument de vente, c’est « l’automatisation gratuite », et le code lui-même ne coûte effectivement rien. Ce qui n’est pas gratuit, c’est de le garder en vie. Un script s’autorise contre votre compte et doit être réautorisé si cet accès se brise. Google retire des méthodes et change des formats de rapports selon son propre calendrier, pas le vôtre, et un script écrit pour le comportement de l’an dernier peut se mettre à échouer silencieusement. Les limites d’exécution font qu’un script qui dépasse ce pour quoi il a été conçu s’arrête simplement au lieu de terminer. Rien de tout cela ne se voit avant le jour où le script cesse de faire la seule chose sur laquelle vous comptiez — et à ce moment-là, la personne qui l’a écrit n’est peut-être plus là pour expliquer ce qu’il était censé faire.
C’est le vrai coût de possession : quelqu’un doit être responsable du script. Pas une ligne d’abonnement, un nom — celui qui reçoit le message quand ça casse et qui connaît assez de JavaScript pour réparer. Nous écrivons et maintenons de l’automatisation pour nos clients dans le cadre de notre travail en gestion Google Ads, et tout ce que nous construisons vous appartient — le compte, le code, l’accès. C’est exactement pour ça que nous sommes directs là-dessus : un code que personne ne possède ne reste pas fonctionnel, il reste seulement installé.
Les limites, dans les propres chiffres de Google
Avant d’écrire quoi que ce soit, il vaut la peine de connaître le plafond. La documentation des scripts de Google le dit directement : « Google Ads scripts for advertiser accounts can execute for a maximum of 30 minutes » (les scripts Google Ads pour les comptes annonceurs peuvent s’exécuter pendant un maximum de 30 minutes) — jusqu’à 60 minutes avec `executeInParallel` et une fonction de rappel. D’autres plafonds comptent une fois que le script fait du vrai travail : l’itérateur par défaut s’arrête autour de 50 000 résultats, un sélecteur `withIds()` plafonne à 10 000 ID, le journal d’exécution est tronqué à 100 Kb (assez pour cacher l’erreur qu’il vous fallait), et un compte ne peut détenir que 250 scripts autorisés au maximum.
Rien de tout cela n’est une raison d’éviter les scripts. C’est une raison de les garder ciblés — une tâche de surveillance, un script — plutôt qu’un seul script géant qui tente de faire tourner tout le compte.
Une note pratique : Google a réorganisé cette documentation en septembre 2025 et a rassemblé les exemples de code éparpillés dans une seule référence d’exemples, donc un extrait copié d’un vieux message de forum peut ne plus correspondre aux guides actuels.
Les scripts valent-ils encore la peine en 2026?
Google n’a pas publié de position sur la question, alors traitez ce qui suit comme l’avis de gens qui gèrent des comptes, pas comme une déclaration d’entreprise. L’argument voulant que les scripts perdent de leur utilité est réel : l’automatisation native — les enchères intelligentes, les composants créés automatiquement, Performance Max — prend maintenant en charge une bonne partie de l’optimisation qui exigeait autrefois un script surveillant un motif à l’intérieur d’une seule campagne. Ce que l’automatisation native ne fait toujours pas, c’est surveiller le compte d’en haut : est-ce que le rythme de dépense du budget reste sain à travers les campagnes, est-ce qu’une URL s’est brisée quelque part, est-ce que tous les clients d’un même compte administrateur viennent de voir leurs conversions se taire d’un coup. C’est de la surveillance, pas de l’optimisation, et ce n’est jamais vraiment le terrain sur lequel les scripts entraient en concurrence avec les enchères intelligentes.
Quelqu’un doit être celui qui surveille
Un script est une bonne idée avec un responsable, et une mauvaise idée sans. Si ce dont vous avez vraiment besoin, c’est de quelqu’un qui vérifie le rythme de dépense du budget, les URL et les annonces refusées sur tous les comptes chaque jour — et qui agit selon ce qu’il trouve — c’est d’abord une description de tâche pour une personne, avant d’être une ligne de code. Si la question de l’automatisation dépasse le cadre des annonces pour toucher au reste du fonctionnement de l’entreprise, c’est ce qu’examine séparément notre travail en automatisation.
Vous ne savez pas trop ce que votre propre compte signalerait si quelqu’un le surveillait correctement? Commencez par lire les chiffres qui montrent si le compte perd du terrain à cause du budget ou du classement. Ces chiffres, ce sont ceux de la formule du taux d’impressions.
