L'automatisation PPC a toujours été possible. Elle n'était simplement jamais rentable — jusqu'à maintenant.

Tout l’argument en une phrase

Bien automatiser le PPC a toujours été possible — ce n’était simplement jamais rentable, donc presque personne ne le faisait. L’IA ne nous a pas donné de nouveaux pouvoirs ; elle a fait s’effondrer le coût d’utilisation des anciens, et ce seul basculement économique remet sur la table une décennie de « on adorerait, mais ça ne serait jamais rentable ». Tout ce qui suit en est la preuve, racontée de l’intérieur des outils avec lesquels je construis vraiment — pas depuis une keynote d’éditeur.

Voici ce que vous retirerez concrètement de cet article : les trois époques qui ont rendu l’automatisation PPC trop chère pour qu’on s’y mette, le moment exact où le calcul a basculé cette année, et une vraie tâche — nettoyer les requêtes parasites avec un modèle open source local — décomposée étape par étape, avec le résultat intermédiaire que vous auriez sous les yeux montré à chaque stade. À la fin, vous saurez faire la différence entre « l’IA nous a donné de nouvelles capacités » (majoritairement faux) et « l’IA a changé qui peut s’offrir les anciennes » (la chose qui compte vraiment), et vous aurez un flux que vous pourrez copier.

J’ai tenu un petit blog sur les Google Ads scripts entre 2015 et 2017, puis j’ai arrêté d’écrire. Pas parce que les idées s’étaient taries — parce que l’écart entre « c’est possible » et « ça vaut le coup pour un client » est resté obstinément large pendant une décennie. Presque tout ce que vous avez lu sur l’IA qui tuerait le spécialiste PPC se trompe de mécanisme. L’IA n’a pas changé ce que vous pouvez faire en recherche payante. La plupart était déjà possible. Ce qu’elle a changé, c’est qui peut le faire, et à quel coût — et c’est bien plus important qu’un énième bouton d’enchères automatiques. Laissez-moi vous expliquer comment je le sais.

L’époque des Scripts : quelques jours pour un script « simple »

Pourquoi je commence ici : pour vous montrer que le plafond n’a jamais été la technologie. C’était le travail, dès le tout premier outil que j’ai touché.

Les Google Ads Scripts semblaient magiques à leur arrivée. Du JavaScript, directement dans le compte, bouclant sur les campagnes. En pratique, un script « simple » — mettre en pause les mots clés au-dessus d’un seuil de CPA, signaler les URL finales cassées — représentait quelques jours d’écriture et de débogage une fois qu’on gérait les cas limites, les quotas, les échecs silencieux.

Puis venait la partie que personne ne budgétait : le faire tourner sur plusieurs comptes. Un script par compte, copié-collé, dérivant hors synchro, cassant en silence dès que la convention de nommage d’un client ne collait pas aux autres. Le passage à l’échelle et la distribution étaient un boulot à part entière. Du coup, la plupart des scripts dans la nature n’allaient jamais au-delà du reporting — sortir quelques chiffres dans un Sheet à intervalles réguliers. Tout ce qui modifiait réellement le compte était trop fragile, et trop cher à maintenir, pour que ça vaille le coup pour la plupart des agences.

L’enseignement à retenir : même la couche d’automatisation « facile » était bridée par le coût de maintenance, pas par la capacité.

L’époque de l’API : deux jours pour la première requête, deux ans pour un outil

Pourquoi celle-ci compte : c’est là que l’écart de rentabilité est devenu si large qu’il est devenu une décision business, pas d’ingénierie.

La Google Ads API — l’AdWords API à l’époque — c’était la vraie puissance, et le vrai mur. J’ai vu notre architecte système, un homme avec plus de 25 ans d’ingénierie derrière lui, passer deux journées entières à lire la documentation avant d’obtenir qu’une seule requête renvoie des données. Ce n’est pas une critique de lui. C’est l’ampleur du terrain sur lequel vous vous engagiez.

On y est quand même allé à fond et on a construit PPC Robot : un outil de reporting et d’opérations profondément personnalisable, techniquement magnifique, réellement puissant. Il a aussi demandé deux développeurs, à plein temps, pendant deux ans. Le développement nécessaire pour le maintenir tournait quelque part autour de 100 000 € par an — à peu près, ordre de grandeur — et il n’a jamais été rentable. Il couvrait une fraction de ce dont nos spécialistes PPC avaient réellement besoin, alors on a fini par le ranger dans un mode interne restreint. Pas parce qu’il était mauvais. Parce que le calcul n’a jamais bouclé.

Et on a quand même livré de vraies choses par-dessus cette API, il y a quatre et cinq ans :

Regardez cette liste et remarquez quelque chose : rien là-dedans n’est exotique selon les standards d’aujourd’hui. Tout était possible. Ça coûtait simplement une fortune à construire et une fortune à maintenir en vie. Chaque fonctionnalité significative — un outil de recherche de mots clés, un outil d’expansion, la traduction d’annonces, un générateur Shopping — se mesurait en mois. C’est toute la leçon de l’époque en une phrase : le plafond n’a jamais été la technologie. C’était le délai de rentabilité.

Deux choses qui ont cédé cette année

Pourquoi je deviens précis maintenant : « l’IA a tout changé » est une affirmation que vous devriez refuser d’accepter sur parole. Voici donc deux tâches qui étaient autrefois non rentables et qui ne le sont plus — toutes deux des choses que je fais tourner, pas des hypothèses — et pour la première, je vais vous montrer exactement ce que produit chaque étape.

1. Exclure les mauvaises requêtes

Nettoyer un compte de ses requêtes non pertinentes a une grande valeur et est abrutissant. L’ancienne méthode était une exploration semi-manuelle de milliers de requêtes, à repérer les schémas à l’œil et à ajouter les mots clés à exclure à la main. Imaginez la situation : une boutique de chaussures de running paie des clics sur « réparation chaussures running », « histoire nike air max » et « chaussures running gratuites » — alors qu’elle ne vend ni n’entretient rien de tout ça. Multipliez ça par des milliers de lignes, chaque semaine, sur chaque compte. C’est la tâche que personne ne veut et dont tout le monde a besoin.

L’action qui a changé : un script Python tire les requêtes depuis la Google Ads API et les confie à un modèle open source — le Gemma 4 de Google — avec des instructions adéquates et, c’est crucial, du contexte sur le site : le sitemap, la structure du site/de la base de données, la taxonomie de fil d’Ariane, le flux de produits. Résultat : le modèle ne se contente pas de signaler des requêtes parasites individuelles ; il fait remonter les schémas qui les sous-tendent, plus vite et moins cher qu’un survol humain. Voici ce flux en cinq étapes concrètes.

Le vrai message, ici, ce n’est pas « l’IA est intelligente ». C’est qu’un modèle open source exécuté localement suffit — vous n’avez même pas besoin d’une API de pointe pour que ça soit rentable. C’est l’économie qui bouge, pas la capacité.

Regardez-le tourner : ce que crache réellement chaque étape

Les cinq étapes sont la recette ; ceci est le plat. Voici ci-dessous l’artéfact concret que chaque étape vous remet pour notre boutique de chaussures de running — ce que vous regardez littéralement avant de passer à la suite. Les formes sont exactement ce que renvoient les outils ; les lignes sont illustratives, pas un vrai client. (Exemples illustratifs partout.)

EXTRAIRE → les requêtes brutes, avec l’argent rattaché. Chaque terme payé par le compte, trié pour que le gaspillage soit visible :

Search term                Clicks  Cost   Conv
running shoes                420    €310    12
free running shoes            88    €61      0
running shoes repair          54    €40      0
nike air max history          31    €24      0
running shoes wikipedia       19    €14      0

Quatre de ces cinq lignes sont de la dépense pure avec zéro conversion — 139 € que le compte n’aurait jamais dû payer. Le problème est évident sur cinq lignes et invisible sur cinq mille.

ANCRER → le dossier de contexte contre lequel le modèle raisonne. Pas de la prose — une carte compacte de ce que le site est vraiment :

sitemap.xml      → 1,010 URLs (categories, products, blog)
breadcrumb tax.  → Footwear > Running > Road / Trail
product feed     → 1,205 SKUs (id, title, category, price)
DB structure     → no "repair", "rental" or "history" nodes exist

C’est cette dernière ligne qui fait le travail : le modèle sait désormais que la « réparation » n’est pas un service que cette boutique propose, au lieu de deviner.

DEMANDER → les verdicts, et les schémas au-dessus. Le modèle renvoie un verdict par requête — mais le trésor, c’est le bloc en bas :

Query                     Verdict      Why
free running shoes        irrelevant   freebie intent, no purchase
running shoes repair      irrelevant   service we don't offer
nike air max history      irrelevant   informational, no buy intent
running shoes wikipedia   irrelevant   reference-seeker

→ PATTERN: tokens "free", "repair", "history", "wikipedia"
  = non-commercial modifiers absent from our taxonomy.
  Recommend excluding as a shared negative list.

Quatre lignes sont devenues une règle. Cette règle attrapera les déchets du genre « chaussures running livraison gratuite retours » que vous n’avez pas encore vus — ce qui est tout l’intérêt.

VÉRIFIER → un humain valide la règle. Vous lisez une ligne — « modificateurs non commerciaux absents de notre taxonomie » — vous convenez que c’est juste, et vous avez terminé. Pas de défilement de 5 000 lignes. Le jugement se fait une seule fois.

POUSSER → les exclusions atterrissent au bon niveau. Comme le schéma vaut pour tout le site, il va sur une liste de mots clés à exclure partagée, pas sur un seul groupe d’annonces :

Shared negative list: "non-commercial modifiers"
  free · repair · history · wikipedia · manual · pdf
Applied to: all Search campaigns

Un schéma, une liste, chaque campagne protégée — et ça continue de mériter sa place la semaine suivante sans nouvelle passe humaine. Voilà le moment où une corvée hebdomadaire abrutissante devient une revue de dix minutes.

2. La recherche de mots clés

La seconde tâche est celle qui constituait jadis une ligne budgétaire à elle seule. La vraie recherche de mots clés — celle qui cartographie la demande sur vos pages de destination et vous dit ce qui manque au site — signifiait autrefois des dizaines d’heures à tirer des données (AdWords API, boîtes de suggestion, OpenRefine), du nettoyage semi-manuel, la classification par page de destination, et par-dessus le reporting de tendances / volume de recherche / écarts.

Ce n’est pas seulement moins cher. C’est meilleur — plus précis, avec des heures passées sur la validation et le jugement plutôt que sur la plomberie. Cette combinaison, moins cher et meilleur, c’est exactement ce qui était censé être impossible. J’ai décomposé la version moderne de bout en bout dans le blueprint d’analyse d’expansion de marché et l’analyse des écarts de contenu — les deux avec le vrai résultat intermédiaire montré à chaque étape.

L’économie, avant et après

C’est toute la thèse en un tableau. Mêmes tâches, même niveau d’exigence de qualité — seul le coût de leur exécution a bougé. Chiffres documentés là où je les ai ; le reste est un ordre de grandeur tiré de deux décennies d’une agence à faire ça.

Lisez le tableau de haut en bas et le schéma est le même à chaque ligne : la colonne capacité n’a pas changé — on pouvait tout faire de ça en 2019. La colonne prix s’est effondrée. Ce n’est pas une histoire de technologie. C’est une histoire de délai de rentabilité, et le délai de rentabilité est ce qui décide si une idée intelligente est un jour construite.

Ce que ça signifie réellement pour le secteur

Pourquoi je vais planter un drapeau ici : l’avis populaire — « l’IA met fin au spécialiste PPC » — est paresseux, et se tromper là-dessus a de vraies conséquences de carrière pour les gens qui lisent ceci.

« L’ère des spécialistes PPC touche à sa fin » est une absurdité. C’est le contraire qui se passe. Les bons spécialistes ont passé des années frustrés que la chose intelligente — celle qu’ils voyaient clairement — « ne valait pas le coup d’être construite ». Maintenant, ils peuvent la construire. Automatiquement, de façon rentable, à grande échelle. Toute une étagère de stratégies PPC qui étaient autrefois non rentables ou tout simplement absurdes à tenter est soudain sur la table.

Ce qui se passe réellement, c’est une scission plus nette à l’intérieur du métier. D’un côté, des juniors sans imagination, sans vision, ni aisance avec les outils — des gens qui traitent l’interface de la plateforme comme étant tout le boulot. De l’autre, des super-seniors qui manient les outils, inventent les workflows, pensent hors du cadre que la plateforme impose, croisent des sources de données que personne d’autre ne croise, et se construisent des dashboards spécialisés au lieu d’attendre qu’un éditeur livre une fonctionnalité.

Et pour tuer la mauvaise lecture évidente : ce n’est pas une histoire de service moins cher. Les outils, la puissance de calcul et le développement coûtent toujours de l’argent. Le point, c’est qu’un projet qui demandait autrefois six mois de développement en demande maintenant deux semaines — alors l’investissement a enfin du sens. Le client obtient un service nettement meilleur pour un prix similaire, pas un service pire pour moins cher.

Pourquoi je me remets à écrire

J’ai arrêté de bloguer il y a des années parce que l’écart entre l’idée et son exécution économiquement saine était trop large pour être intéressant. Cet écart vient de se refermer. Alors ce blog est de retour, et il va être concret : des cas d’usage avec de vrais chiffres, les flux exacts, les résultats réels — y compris les parties brouillonnes et les limites. Les premiers deep dives sont déjà en ligne ; d’autres arrivent.

Si votre réaction à tout ça est « on pourrait enfin faire cette chose qu’on a toujours voulue » — tant mieux. C’est tout l’intérêt de cette époque. Construisons-la.

1. PULL   Google Ads API → search-terms report (query, clicks, cost, conv)
2. GROUND Build a context pack the model can reason against:
            - sitemap.xml (what the site actually sells)
            - site / DB structure + breadcrumb taxonomy
            - product feed (id, title, category)
3. ASK    Prompt Gemma 4: "Given this site context, classify each query as
            relevant / irrelevant to what we sell. Return the irrelevant ones
            AND the PATTERNS behind them (token, intent, category mismatch)."
4. REVIEW Human validates the ~10 patterns, not 5,000 rows one by one.
5. PUSH   Add negatives back via the API at the right level (shared list for
            site-wide junk tokens; ad group for local noise).

FAQ