En bref: L’automatisation PPC n’est pas devenue possible du jour au lendemain. Elle est devenue abordable. L’IA n’a pas ajouté de capacités ; elle a fait s’effondrer le délai de rentabilité de celles qu’on a depuis 2019, transformant des chantiers de six mois en chantiers de deux semaines. Les gagnants sont les super-seniors qui construisent enfin les workflows qui n’étaient jamais rentables, comme nettoyer des milliers de requêtes parasites avec un modèle qu’un PC ordinaire fait tourner.
Un jour, j’ai regardé notre architecte système, un homme fort de vingt-cinq ans d’expérience en ingénierie, 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 à travailler avec 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, cette analyse représente environ 400 heures de travail. Construite comme un logiciel sur mesure à l’ancienne, elle représente 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. Ce qui a changé, c’est que la construire est soudain devenu économiquement viable.
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. L’essentiel a toujours été possible, et l’essentiel existait dès 2019. Ce qu’elle a changé, c’est qui peut se permettre de le faire. Cet article en apporte la preuve, vue de l’intérieur des outils que j’utilise vraiment pour construire. J’y retrace les deux époques où l’automatisation était trop chère pour qu’on s’y mette, le moment où le calcul a basculé et une tâche concrète, le nettoyage des requêtes parasites avec un modèle open source local, décomposée étape par étape.
- L’IA n’a presque ajouté aucune nouvelle capacité PPC. Elle a fait s’effondrer le délai de rentabilité de celles qu’on a depuis 2019, et cela seul réécrit ce qui vaut la peine d’être construit.
- La monnaie décisive n’est plus la ligne de code. Ce qui est rare désormais, ce sont les idées plus la connaissance du métier, savoir quoi construire et quelles données croiser.
- Le métier se scinde en deux. Ceux qui ignorent les outils font du surplace ; ceux qui connaissent la Google Ads API sur le bout des doigts et marient données et imagination creusent l’écart.
- L’exemple détaillé à l’intérieur montre un modèle open source local nettoyer des milliers de requêtes parasites en quelques minutes, une tâche autrefois strictement manuelle.
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 auquel 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, des copies qui se désynchronisaient et cassaient 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 à son encontre. C’était la complexité que devait accepter quiconque s’y attaquait.
On y est quand même allés à fond et on a construit PPC Robot, un outil de reporting et d’opérations hautement personnalisable. Techniquement magnifique, réellement puissant. Il a aussi mobilisé deux développeurs à plein temps pendant deux ans, et le maintenir en vie coûtait ensuite environ 100 000 € de développement 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 cantonner à un usage interne limité. Pas parce qu’il était mauvais. Parce que le compte n’y était tout simplement pas.
Et on a quand même livré de vraies choses par-dessus cette API, il y a quatre et cinq ans :
Ce que ce moteur a réellement produit
- Vérificateur d’erreurs 404 / d’URL finales cassées multi-comptes livré
- Générateur de campagne Shopping à partir du flux livré
- Segmentation Shopping / Performance Max livré
- Pipeline BigQuery + reporting vers Sheets / Excel livré
- Vérifications du statut de compte Merchant Center livré
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 comptait en mois de travail de deux seniors, et aucun client n’aurait payé ce que ça coûtait.
Le plafond n’a jamais été la technologie. C’était le délai de rentabilité.
La première tâche enfin automatisable : nettoyer 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. Je fais tourner les deux pour de vrai, ce ne sont pas des hypothèses, et pour la première je vais te dérouler tout le flux.
Nettoyer un compte de ses requêtes non pertinentes est à haute valeur ajoutée et abrutissant, et jusqu’à récemment il n’existait aucun moyen fiable de l’automatiser. Des règles peuvent attraper un token exact, mais décider si « histoire nike air max » mérite qu’on paie le clic demande de la compréhension de lecture. La tâche consistait donc toujours à explorer semi-manuellement des 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 » : elle ne répare rien, elle ne donne rien, et une recherche sur l’histoire d’un produit ne débouche sur aucun achat. Multiplie ç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.
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 les requêtes non pertinentes et dégage les schémas qui les sous-tendent, plus vite qu’un humain ne pourrait le faire en les parcourant. Voici ce flux en cinq étapes concrètes.
EXTRAIRE · récupérer les requêtes brutes
Tire le rapport sur les termes de recherche depuis la Google Ads API. Requête, clics, coût, conversions. Pourquoi en premier : c’est la preuve, l’argent déjà dépensé sur chaque terme. Tu veux le coût rattaché à chaque ligne pour que le modèle distingue les requêtes parasites coûteuses des inoffensives. Tu obtiens : un tableau à plat de chaque terme pour lequel le compte a payé sur la période.
ANCRER · constituer un dossier de contexte sur le site
Rassemble ce que le site est réellement, sous une forme lisible par le modèle. Le sitemap XML, la taxonomie du fil d’Ariane, le flux de produits (id, titre, catégorie) et la structure de la base de données et des catégories. Pourquoi c’est tout l’enjeu : un modèle sans contexte devine ; un modèle qui sait que tu n’as pas de catégorie « réparation » ou « location » raisonne. Tu obtiens : un dossier de contexte qui fait passer le modèle de la devinette à la connaissance de ton catalogue.
DEMANDER · classifier les requêtes et nommer les schémas
Donne à Gemma 4 les termes et le dossier de contexte. Classe chaque requête comme pertinente ou non par rapport à ce qu’on vend et, surtout, fais-lui renvoyer les schémas derrière les non pertinentes (un token, une intention, une incohérence de catégorie). Pourquoi les schémas, pas les lignes : signaler 200 requêtes parasites te fait gagner un après-midi ; nommer la catégorie de parasites exclut les mille suivantes que tu n’as même pas encore vues. Tu obtiens : une liste de requêtes non pertinentes et, au-dessus, la poignée de règles qui l’a générée.
VÉRIFIER · valider les règles, pas les lignes
Un humain lit les schémas, cinq à dix, pas 5 000 lignes individuelles. Pourquoi c’est là le gain de temps : le jugement s’applique une fois par règle au lieu d’une fois par requête, et une mauvaise règle saute aux yeux, alors qu’une seule ligne mal étiquetée passe inaperçue. Tu obtiens : une liste courte et fiable de schémas d’exclusion qu’un humain a réellement validés.
POUSSER · ajouter les exclusions au bon niveau
Renvoie les exclusions approuvées via l’API au bon niveau, groupe d’annonces, campagne ou liste partagée, selon l’ampleur du schéma. Pourquoi le niveau compte : un token parasite commun à tout le site (« gratuit », « wikipedia ») a sa place sur une liste partagée, pas enfoui dans un seul groupe d’annonces. Tu obtiens : un compte propre et une liste d’exclusions réutilisable qui continue de fonctionner la semaine suivante.
Pour voir pourquoi ça marche, regarde ce que l’étape DEMANDER renvoie réellement pour notre boutique de running. Les lignes sont données à titre d’illustration, mais le format reproduit exactement ce que renvoie le modèle, et l’essentiel se trouve dans 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 : les passer en liste d’exclusion partagée.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 requêtes parasites du genre « chaussures running gratuites à gagner » que tu n’as même pas encore vues. C’est le moment où une corvée hebdomadaire abrutissante devient une revue de dix minutes.
Ce qui saute le moins aux yeux 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 sortent jamais de chez toi. C’est l’économie qui bascule, 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 met en correspondance la demande avec tes pages de destination et te dit ce qui manque au site, coûtait des dizaines d’heures. Extraction des données (AdWords API, boîtes de suggestion, OpenRefine), nettoyage semi-manuel, classification par page de destination, et par-dessus tout ça, le reporting des tendances, des volumes et des écarts.
Un projet de recherche de mots clés, avant vs. maintenant
- L’ancienne méthode (extraction, nettoyage, classification, reporting) 50–100 h
- Ce que le client payait pour ça ≈ 2 000–4 000 €
- Le même projet aujourd’hui, avec une bonne skill IA quelques heures
- Et le résultat est plus précis
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, tous 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é. Des chiffres documentés quand j’en ai, un ordre de grandeur tiré de vingt ans d’agence pour le reste.
| La tâche | L’ancienne méthode | Aujourd’hui |
|---|---|---|
| Analyse d’expansion de marché (prix multi-marchés) | ~400 h à la main · ou 2 mois de dev, 16 000–20 000 € | 6 h |
| Recherche de mots clés (un projet) | 50–100 h · 2 000–4 000 € facturés | quelques heures · plus précis |
| Tri des requêtes à exclure | exploration semi-manuelle, des milliers de lignes à la main | script + modèle local qui nomme les schémas |
| Livrer une nouvelle fonctionnalité d’automatisation | des mois (2 devs × 2 ans pour un outil complet) | des semaines |
| Maintenir un moteur de reporting en vie | ~100 000 € / an, jamais rentable | quasi nul avec un modèle local |
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 déjà faire tout ç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.
L’IA n’a pas tant débloqué de nouvelles capacités PPC qu’elle a fait s’effondrer le délai de rentabilité des anciennes. Quand un chantier de six mois devient un chantier de deux semaines, tout le backlog des « on adorerait, mais ça ne serait jamais rentable » se vide d’un coup.
À 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 à mettre au service des problèmes PPC, à cause des longs délais de rentabilité décrits plus haut. Maintenant, l’avantage fait boule de neige.
Boostora, 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 branchés sur chaque service qu’on utilise, pour qu’un agent IA puisse en tirer des données au milieu d’une tâche.
Il y a deux ans, j’aurais dû défendre chacun de ces projets en répondant à la même question : serait-il un jour rentable ? Aujourd’hui, la question se pose à peine. Quand construire devient bon marché, l’infrastructure cesse d’être un luxe et devient l’avantage que personne ne peut copier.
Ce que ça signifie réellement pour le secteur
Le discours dominant veut que l’IA signe la fin du spécialiste PPC. Se méprendre sur le sens de cette évolution a de vraies conséquences professionnelles pour ceux qui lisent ceci, alors autant le dire sans détour.
« 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 à ronger leur frein : l’idée intelligente, celle qu’ils voyaient parfaitement, ne valait pas le coup d’être construite. Maintenant, ils peuvent la construire. Automatiquement, de façon rentable et à grande échelle. Tout un éventail de stratégies PPC autrefois non rentables ou tout simplement absurdes à tenter devient soudain envisageable.
Ce qui se passe, c’est une scission plus nette à l’intérieur du métier. D’un côté, ceux qui considèrent l’interface de la plateforme comme tout le boulot et passent à côté des nouveaux outils. Personne ne les vire demain. Ils font du surplace pendant que le métier avance. De l’autre, ceux qui connaissent la Google Ads API sur le bout des doigts, 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 à travailler avec cette API m’ont appris où réside 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 couper court au contresens évident : il ne s’agit pas ici d’un service moins cher. Les outils, le calcul et le développement coûtent toujours de l’argent. L’important, c’est qu’un projet qui mobilisait deux développeurs seniors pendant quatre à six mois 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 en discuter, tu sais où me trouver.
FAQ
Es-tu en train de dire que les agences devraient virer leurs spécialistes PPC ?
Tout le contraire. Les spécialistes qui maîtrisent la stratégie et les outils ont désormais plus de valeur, parce qu’ils peuvent enfin exécuter les idées qui n’étaient pas rentables avant. Ce qui rétrécit, c’est la valeur du simple clic sur des boutons dans l’interface de la plateforme.
Les chiffres de 100 000 €/an et de deux devs pendant deux ans sont-ils exacts ?
Non, prends-les comme un ordre de grandeur. Ce n’est pas le montant précis en euros qui compte. Un seul moteur de reporting interne nous coûtait chaque année un montant à six chiffres et n’a malgré tout jamais été rentable. C’est de cette économie que parle tout l’article.
Faut-il un modèle de pointe coûteux pour faire ça ?
Pas pour des tâches comme le tri des requêtes à exclure. Un modèle open source compétent comme Gemma 4, exécuté localement avec un bon contexte du site, fait le travail. Tes données et tes coûts restent ainsi sous ton contrôle.
C’est seulement une histoire de requêtes ?
Non, c’est juste la tâche la plus facile à regarder tourner. Le même basculement économique s’est produit pour l’analyse d’expansion de marché (six heures au lieu d’environ 400), le scraping des prix concurrents par marché, la recherche de mots clés qui tourne chaque jour au lieu d’une fois par an, et l’enrichissement de flux avec Boostora. Prends n’importe quelle corvée que tu as mise de côté et refais le calcul de sa rentabilité.
Donc ce n’est que du battage médiatique avec une couche de peinture fraîche ?
Si c’était le cas, je n’aurais pas recommencé à écrire. Le changement est circonscrit et bien réel : le délai de rentabilité de capacités qu’on avait déjà s’est effondré. C’est un changement d’ordre économique, pas magique, et c’est pourquoi le backlog se vide soudainement.
Qu’y aura-t-il concrètement sur ce blog ?
Des cas d’usage concrets avec des chiffres, les flux qui les sous-tendent et les résultats, limites et modes de défaillance inclus. Moins de manifeste, plus de « voici exactement ce qu’on a lancé et ce que ça a renvoyé ».
