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

Un jour, j’ai regardé notre architecte système, un homme avec vingt-cinq ans d’ingénierie derrière lui, passer deux journées entières à lire la documentation de la Google Ads API avant qu’une seule requête ne renvoie des données. Deux jours, une requête. C’est le meilleur ingénieur que je connaisse, et il lui a quand même fallu deux jours. C’était tout simplement le droit d’entrée que la plateforme faisait payer à quiconque voulait la vraie puissance.

J’ai passé une vingtaine d’années dans le PPC, dont douze à écrire du code contre cette API. Entre 2015 et 2017, j’ai tenu ppc-scripts.eu, un petit blog sur les Google Ads Scripts, à l’époque où automatiser le PPC n’était pas encore cool. Puis j’ai arrêté d’écrire. Pas parce que les idées s’étaient taries. L’écart entre « c’est possible » et « ça vaut le coup pour un client » est resté obstinément large pendant une décennie, et il n’y a qu’un nombre limité de façons de décrire des outils que personne ne peut se payer.

Ce printemps, j’ai livré une analyse d’expansion de marché, seize produits dont les prix ont été comparés dans cinq pays avec des cartes de chaleur, en environ six heures. À la main, c’est autour de 400 heures de travail. Construite comme un logiciel sur mesure à l’ancienne, c’est deux mois de développement et une facture de 16 000 à 20 000 € qu’aucun client n’a jamais voulu payer. Même livrable, et le prix s’est effondré. L’analyse n’est pas devenue plus intelligente ce printemps. C’est l’économie de sa construction qui a cédé.

Presque tout ce que tu as lu sur l’IA qui tuerait le spécialiste PPC prend ce mécanisme à l’envers. L’IA n’a pas changé ce que tu peux faire en recherche payante. La plupart a toujours été possible, et la plupart existait dès 2019. Ce qu’elle a changé, c’est qui peut se permettre de le faire. Cet article en est la preuve, racontée de l’intérieur des outils avec lesquels je construis vraiment. Deux époques qui rendaient l’automatisation trop chère pour qu’on s’y mette, le moment où le calcul a basculé, et une vraie tâche, le nettoyage des requêtes parasites avec un modèle open source local, décomposée étape par étape.

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

Le plafond n’a jamais été la technologie, et je veux te le montrer 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 », disons mettre en pause les mots clés au-dessus d’un seuil de CPA ou signaler les URL finales cassées, représentait quelques jours d’écriture et de débogage une fois gérés les cas limites, les quotas et les échecs silencieux.

Puis venait la partie que personne ne budgétait. Le faire tourner sur plusieurs comptes signifiait une copie du script par compte, 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.

Même la couche d’automatisation facile était bridée par le coût de maintenance, pas par la capacité. Garde ça en tête. C’est le motif de tout ce qui suit.

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

La Google Ads API, l’AdWords API à l’époque, c’était la vraie puissance et le vrai mur. Les deux jours que mon collègue a passés dans la documentation n’étaient pas une critique de lui. C’était la surface que tout le monde acceptait d’affronter.

On y est quand même allés à 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, et le développement nécessaire pour le maintenir tournait quelque part autour de 100 000 € par an. 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 :

Regarde cette liste et remarque une 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 de deux seniors, et aucun client ne paie ce que ça coûte.

Le plafond n’a jamais été la technologie. C’était le délai de rentabilité.

La première tâche qui s’est libérée : les requêtes parasites

« L’IA a tout changé » est une affirmation que tu devrais refuser d’accepter sur parole. Voici donc deux tâches qui n’étaient pas rentables avant et qui le sont maintenant. Les deux sont des choses que je fais tourner, pas des hypothèses, et pour la première je vais te dérouler tout le flux.

Nettoyer un compte de ses termes de recherche non pertinents a une grande valeur et abrutit, et jusqu’à récemment il n’existait aucune façon honnête de l’automatiser. Des règles peuvent attraper un token exact, mais décider si « histoire nike air max » mérite qu’on paie pour lui demande de la compréhension de lecture. La tâche restait donc une exploration semi-manuelle de milliers de requêtes, à repérer les schémas à l’œil et à ajouter les exclusions à la main. Imagine une boutique de chaussures de running qui 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. Multiplie 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.

Voici ce 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, que presque n’importe quel PC actuel fait tourner. Il lit des milliers de requêtes en quelques minutes. Et quand tu l’ancres dans du contexte sur le client, le sitemap, la structure du site et de la base de données, la taxonomie du fil d’Ariane, le flux de produits, il arrête de deviner et se met à raisonner. Il exclut correctement et nomme les schémas derrière les déchets, plus vite que n’importe quel survol humain. Voici ce flux en cinq étapes concrètes.

Pour voir pourquoi ça marche, regarde ce que l’étape DEMANDER renvoie réellement pour notre boutique de running. Les lignes sont illustratives, la forme est exactement ce qui revient, et le trésor est le bloc du bas :

Requête                        Verdict         Pourquoi
chaussures running gratuites   non pertinente  intention gratuite, pas d'achat
réparation chaussures running  non pertinente  service qu'on ne propose pas
histoire nike air max          non pertinente  informationnel, pas d'achat
chaussures running wikipedia   non pertinente  recherche de référence

→ SCHÉMA : tokens « gratuit », « réparation », « histoire », « wikipedia »
  = modificateurs non commerciaux absents de notre taxonomie.
  Recommandation : exclure via une liste partagée de mots clés à exclure.

Quatre lignes sont devenues une règle. Un humain lit cette seule ligne, convient qu’elle est juste, et la règle continue d’attraper les déchets du genre « chaussures running livraison gratuite retours » que tu n’as même pas encore vus. C’est le moment où une corvée hebdomadaire abrutissante devient une revue de dix minutes.

Le vrai message discret ici, c’est qu’un modèle open source exécuté localement suffit. Tu n’as pas besoin d’une API de pointe pour que ça soit rentable, et tes données ne quittent jamais la maison. C’est l’économie qui bouge, pas la capacité.

La seconde tâche : la recherche de mots clés

Celle-ci constituait autrefois une ligne budgétaire à elle seule. La vraie recherche de mots clés, celle qui cartographie la demande sur tes pages de destination et te dit ce qui manque au site, signifiait 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, de volumes et d’écarts.

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

La partie qui me surprend encore, c’est la cadence. Une recherche comme ça était un projet annuel qu’un client validait une fois. Le même pipeline peut désormais tourner chaque jour et regarder la demande bouger au lieu de la photographier une fois par an.

L’économie, avant et après

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

Lis le tableau de haut en bas et le schéma se répète à chaque ligne. La colonne capacité n’a pas bougé ; on savait tout faire de ça en 2019. La colonne prix s’est effondrée. Et le délai de rentabilité est ce qui décide si une idée intelligente sera un jour construite.

À quoi ça ressemble quand tu t’y engages à fond

Lynt est une agence à forte composante technique depuis le premier jour. On a dans l’équipe un architecte système, un ingénieur sécurité, un analyste data qui construit la BI et un développeur à plein temps, ce qu’une agence normale n’a tout simplement pas. Pendant des années, ce muscle était difficile à pointer vers des problèmes PPC, pour toutes les raisons de rentabilité ci-dessus. Maintenant, il se compose.

Boostera, notre propre outil, a demandé deux ans de développement. Il enrichit les flux Google Merchant Center avec de l’IA, pour que les campagnes Shopping tournent sur de meilleures données produit que le flux brut. Autour, il y a la plomberie que la nouvelle économie justifie enfin. Le scraping des prix concurrents par marché, celui qui a alimenté les tableaux de prix du blueprint d’expansion. Des pipelines de recherche de mots clés qui tournent selon un planning au lieu d’une fois par an. Du reporting business au niveau client dans BigQuery avec des prévisions par-dessus. Des serveurs MCP sur chaque service qu’on touche, pour qu’un agent IA puisse piocher dans n’importe lequel en pleine tâche.

Il y a deux ans, j’aurais dû défendre chacun de ces projets contre la même question, est-ce que ça sera un jour rentable. Aujourd’hui, la question se pose à peine. Quand construire devient bon marché, l’infrastructure cesse d’être un luxe et devient la douve.

Ce que ça signifie réellement pour le secteur

L’avis populaire dit que l’IA met fin au spécialiste PPC. Se tromper de sens là-dessus a de vraies conséquences de carrière pour ceux qui lisent ceci, alors laisse-moi planter un drapeau.

« 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 vaille 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 autrefois non rentables ou tout simplement absurdes à tenter est soudain sur la table.

Ce qui se passe, c’est une scission plus nette à l’intérieur du métier. D’un côté, ceux qui traitent l’interface de la plateforme comme le boulot entier et laissent passer les nouveaux outils. Personne ne les vire demain. Ils se figent sur place pendant que le métier bouge. De l’autre, ceux qui connaissent la Google Ads API jusqu’à l’os, 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é. Douze ans à écrire du code contre cette API m’ont appris où vit vraiment l’avantage du second groupe. Le code est devenu bon marché. Ce qui est resté rare, c’est l’imagination et la connaissance du métier, savoir quelles données croiser et pourquoi.

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

Pourquoi je me remets à écrire

J’ai arrêté de bloguer en 2017 parce que l’écart entre une idée et une exécution économiquement saine était trop large pour être intéressant. Cet écart vient de se refermer. Alors ce blog reprend là où ppc-scripts.eu s’était arrêté, et il reste concret. Des cas d’usage avec de vrais chiffres, les flux exacts, les résultats réels, parties brouillonnes et limites incluses. Les premiers deep dives sont déjà en ligne.

Quelque part dans ton propre backlog se trouve l’automatisation que tu as mise de côté il y a des années parce qu’elle ne serait jamais rentable. Ressors-la et refais les calculs. S’ils ont basculé comme les miens, tu sais quoi construire ensuite. Et si tu veux comparer nos notes, tu sais où me trouver.

FAQ