- Accueil
- Études de cas
- Un agent analyse Google Ads chaque jour et soumet ses recommandations à validation
Un agent analyse Google Ads chaque jour et soumet ses recommandations à validation
Une analyse quotidienne du compte, contextualisée pour le B2B, plutôt que des conseils génériques. L’agent lit et propose ; une personne valide chaque modification.
4 min de lecture
- Client
- Entreprise B2B (compte publicitaire interne)
- Secteur
- Publicité / Google Ads / Analytique
- Périmètre
- Analytique et données
Le client et son problème
Une entreprise B2B gérait elle-même son compte Google Ads. Le compte n’était pas immense, mais demandait une surveillance quotidienne. Les mots-clés commençaient à déraper d’un jour à l’autre, le budget partait sur des requêtes qui ne mèneraient jamais à un client, et une semaine sans vérification suffisait à rendre la perte mesurable.
Le réflexe naturel est d’utiliser un outil d’audit prêt à l’emploi. Le problème, c’est que ces outils évaluent tous les comptes avec la même référence : celle d’une boutique où un prospect coûte dix zlotys. En B2B, un seul prospect peut valoir autant que cent commandes dans une boutique. Une recommandation du type « baissez l’enchère, le clic coûte cher » peut donc être tout simplement nuisible.
Deuxième problème : les conseils se répètent. Les outils proposent volontiers la même chose chaque semaine parce qu’ils ne se souviennent pas des actions déjà effectuées. Si la liste des mots-clés à exclure est construite depuis deux ans, recevoir une proposition d’ajout d’un mot qui y figure déjà n’est que du bruit ; à force, on cesse de lire toute la liste.
Enfin, une règle a été posée dès le départ : aucune modification automatique du compte. L’agent peut tout lire et tout proposer, mais il ne touche pas aux paramètres. La décision appartient à une personne.
Ce que nous avons fait
Nous avons créé un agent qui récupère chaque jour les données du compte et prépare une liste de recommandations à valider. La collecte repose sur Python et l’API Google Ads, en accès strictement limité à la lecture. Ce n’est pas une question de discipline : les autorisations empêchent physiquement l’agent de modifier quoi que ce soit.
Chaque jour, il lit les campagnes, les mots-clés et les requêtes ayant déclenché les annonces. Ces données sont transmises au modèle analytique avec le contexte métier : modèle de vente, valeur réelle d’un prospect et profil du client cible. L’évaluation ne se réduit donc pas à une opération sur le coût par clic ; elle examine si une requête donnée peut réellement apporter un client.
Avant toute proposition, l’agent vérifie ce qui a déjà été fait. Il lit les listes existantes de mots-clés à exclure et retire de ses recommandations les mots déjà ajoutés. Le mécanisme est simple, mais c’est lui qui rend le rapport lisible.
Les recommandations finalisées apparaissent dans un tableau de bord, avec leur niveau de priorité et leur justification. L’historique, les statuts et les données associées sont stockés dans Supabase, et le processus s’exécute automatiquement une fois par jour. Une personne parcourt la liste et marque chaque élément comme appliqué ou rejeté.
Le fonctionnement aujourd’hui
L’agent fonctionne en continu, une fois par jour. Le matin, une liste de propositions classées par importance attend dans le tableau de bord. Chacune explique brièvement son origine et la partie du compte concernée. Rien n’est appliqué automatiquement.
Marquer une proposition comme appliquée ou rejetée ne sert pas seulement à garder l’interface en ordre. C’est un retour qui évite à l’agent de revenir sur des sujets déjà clos. La liste raccourcit donc de semaine en semaine au lieu de s’allonger.
Résultats
Le compte est analysé chaque jour, et non uniquement quand quelqu’un trouve le temps de le faire. L’agent est en lecture seule : aucune modification n’est appliquée sans accord humain. Le coût d’un prospect dans le modèle B2B fait partie de l’évaluation, plutôt que d’être ajouté à la fin du rapport. La vérification des mots-clés négatifs existants est automatique, ce qui évite de répéter les mêmes conseils.
Ce que nous ferions autrement
Le principal point de blocage n’était ni l’API ni le modèle, mais la description du contexte métier. La première version en contenait trop peu et l’agent, malgré l’accès à toutes les données, formulait des recommandations comme dans un manuel pour boutiques en ligne. Ajouter quelques paragraphes sur la valeur réelle d’un prospect et le profil du client a davantage amélioré les résultats qu’un changement technique. La prochaine fois, nous commencerons par là, avant l’intégration.
Nous avons également sous-estimé la vérification des actions déjà réalisées. Nous l’avons traitée comme un petit ajout, alors qu’elle était indispensable pour que quiconque lise le rapport quotidien. Pour le prochain agent de surveillance, la mémoire des actions effectuées fera partie de la première version, et non de la deuxième.
Projets similaires
Mesure des conversions en e-commerce : d’une couverture des événements de 35 % à un niveau presque complet
Une boutique beauté ne transmettait à Meta qu’un tiers de ses achats. Nous avons corrigé la mesure côté serveur dans le respect du consentement et porté la couverture à un niveau presque complet.
Les données de Search Console et du planificateur de mots-clés accessibles directement dans le chat
Une agence comptant plus de vingt clients a cessé d’exporter les fichiers des interfaces Google. Deux serveurs MCP donnent accès aux données SEO et aux mots-clés directement dans le chat.