L’intelligence publicitaire B2B passe par le HTML : concevoir un parseur qui résiste aux refontes

Dans quels pays un concurrent B2B fait-il de la publicité ce trimestre ? Depuis combien de temps ses créations tournent-elles, quel volume d’impressions semblent-elles générer, et quelles audiences vise-t-il ? Ces informations sont disponibles dans les bibliothèques publicitaires publiques que de nombreuses plateformes doivent publier au titre des règles de transparence. Sauf qu’après avoir ouvert DevTools et fouillé un moment, on ne trouve souvent aucune API JSON propre : uniquement une page entière de HTML rendue côté serveur. On écrit alors un parseur, il fonctionne, les données remontent. Puis, trois semaines plus tard, la plateforme refond son interface : plus aucun champ n’est extrait, sans la moindre erreur. Le parseur renvoie tranquillement une collection de valeurs vides, sur laquelle on aurait presque pris une décision.

Voici comment maintenir ce type de parseur après une refonte, et le rôle qu’un modèle peut réellement jouer dans cette maintenance. D’abord, la frontière des données : toutes les données évoquées ici viennent de la bibliothèque publicitaire et du creative center publics de chaque plateforme, consultés en se connectant normalement avec son propre compte. Aucune signature, aucun contournement, aucun endpoint non public. Cette limite est, comme on le verra, intégrée explicitement à la conception du parseur.

Pourquoi l’intelligence publicitaire B2B se récupère en HTML

Même parmi les bibliothèques publicitaires, les modalités d’accès se répartissent en trois catégories : certaines bibliothèques grand public, comme celle de Meta, proposent une recherche structurée et du JSON ; d’autres exigent une session avant même de permettre la recherche ; mais la plupart des bibliothèques des plateformes B2B ne fournissent que du HTML rendu côté serveur, sans endpoint JSON. La raison est simple : ces bibliothèques sont un mécanisme de conformité, pas une API produit.

Elles existent pour répondre aux obligations réglementaires de transparence publicitaire, pas pour être appelées par des développeurs. Pas de numéro de version, pas de changelog, pas de promesse de compatibilité ascendante. La page est pensée pour les humains, le serveur produit du HTML, et la seule « API » disponible est la page web elle-même.

La fragilité est donc inhérente au système : on dépend de détails d’implémentation d’une interface tierce, cette interface peut changer à tout moment, et personne n’est tenu de nous prévenir. La modification d’un champ dans une API JSON reste au moins un « changement » identifiable ; une refonte HTML, elle, n’est pour la plateforme qu’une itération frontend ordinaire. Impossible de l’éviter. Il faut donc concevoir le parseur pour qu’il échoue proprement et se répare facilement après une refonte, au lieu de produire silencieusement des données vides.

Un parseur streaming écrit à la main réduit surtout la charge mentale

Le réflexe consiste à prendre lxml ou BeautifulSoup, à construire le DOM complet, puis à enchaîner les .find(). Cela fonctionne, mais ce n’est pas la bonne approche pour cette cible. Le DOM est un produit intermédiaire du rendu de la page par le navigateur ; MDN définit le DOM comme l’analyse d’un document en arbre de nœuds accessible aux scripts selon sa structure. Or, ici, il suffit d’extraire quelques champs. Inutile de construire cet arbre, et encore moins de lier le parseur à sa structure.

J’ai finalement opté pour une sous-classe de HTMLParser de la bibliothèque standard Python : un peu plus de huit cents lignes, 881 exactement, en streaming intégral. Quelques callbacks starttag / data / endtag pilotent une machine à états. Elle accumule les données au fil du parcours, émet un enregistrement lorsqu’elle atteint la frontière d’une carte, réinitialise son état et continue, sans jamais construire un DOM complet.

Le gain du streaming est très concret. D’abord, la mémoire : le HTML d’une page de détail pèse facilement de quelques dizaines à quelques centaines de KB ; un DOM conserve toute la structure de la page en mémoire, tandis qu’un parseur streaming ne garde que son contexte courant et l’avancement dans la carte. Mais le gain décisif est la charge mentale. Dès qu’on écrit .find('div').find('div')[2], on attache l’extraction à une position hiérarchique du DOM. C’est précisément ce qu’une refonte déplace volontiers : un conteneur supplémentaire, un wrapper scindé, et toutes les positions changent. Une machine à états oblige à poser une question plus robuste : « ce que je parcours correspond-il sémantiquement au début d’une carte, à un nombre d’impressions, à une étiquette de ciblage ? » Les positions bougent ; la sémantique, beaucoup moins.

Trois principes pour encaisser une refonte

Tout se joue sur trois choix de conception, chacun appris à la faveur d’une refonte.

Premier principe : s’ancrer dans la sémantique, jamais dans la position. La machine à états progresse grâce à des signaux sémantiques : le texte d’un libellé de champ, avec des expressions lisibles telles que « total impressions » ou « run dates », des marqueurs porteurs de rôle, une frontière sémantique de bloc. Jamais grâce à « le troisième nœud depuis le haut ». Le test tient en une ligne : si l’élément est déplacé ou entouré d’un niveau supplémentaire, l’extraction tient-elle encore ? Si oui, l’ancre est valide. Les ancres positionnelles cassent à la première refonte ; les ancres sémantiques survivent à la plupart des changements purement visuels.

Deuxième principe : un champ absent ne doit pas provoquer d’exception. Avant de remplir chaque carte, on part d’un modèle où tous les champs ont une valeur vide par défaut : chaîne vide pour le texte, None pour les nombres, tableau vide pour les listes. On renseigne ce qui est disponible et on laisse vide ce qui ne l’est pas. L’échec d’extraction d’un champ ne doit jamais invalider toute la carte, encore moins toute la page. Si une publicité n’a pas de texte de CTA, ses impressions et ses pays ciblés restent précieux. Laisser un champ secondaire manquant détruire l’intelligence que la page pouvait fournir est la pire architecture possible.

Troisième principe : qualifier la complétude des résultats afin de distinguer « vide » de « cassé ». C’est le point le plus facile à négliger et le plus coûteux. « 0 publicité analysée » peut vouloir dire deux choses totalement différentes : l’annonceur n’a réellement diffusé aucune publicité ce trimestre, ou bien la structure de la page a changé et plus aucune ancre ne fonctionne. Ces deux cas doivent être distinguables dans la valeur retournée. Pour cela, on joint des éléments de corroboration : le nombre de cartes capturées, le total annoncé par la page elle-même et l’état de la pagination. Une combinaison telle que « 0 carte capturée, mais les métadonnées de la page annoncent un lot et aucun marqueur de page suivante n’est présent » peut ainsi être identifiée comme une modification de structure plutôt qu’une absence réelle de résultats. Le parseur doit alors lever une erreur explicite au lieu de retourner placidement une liste vide.

La limite d’accès évoquée plus haut se matérialise également ici : le parseur vérifie qu’il n’a pas été redirigé vers une page de connexion. Dès qu’il détecte le titre d’une page de login ou d’inscription, il s’arrête avec une erreur plutôt que de poursuivre l’analyse. Il ne traite que les pages publiques visibles normalement avec son propre compte, s’arrête devant un mur de connexion et ne cherche jamais à le contourner.

La valeur se trouve dans les dimensions de filtrage

À ce stade, on pourrait croire que l’objectif est d’extraire impeccablement chaque champ de chaque publicité. Ce n’est pas le cas. Les champs d’une publicité isolée ne valent pas grand-chose ; l’essentiel est de savoir selon quelles dimensions on peut découper l’ensemble des publicités. Les filtres de recherche de la bibliothèque constituent déjà une liste prête à l’emploi de dimensions d’intelligence. En les structurant en paramètres de requête programmables, on n’obtient pas « une publicité », mais une tranche de lancement d’un concurrent :

Pays : les marchés où l’entreprise fait de la publicité, et ceux qu’elle ne cible pas. Lorsqu’une entreprise B2B commence soudainement à promouvoir ses offres dans un pays, cela peut révéler un mouvement d’expansion avant même que son site ne le laisse paraître.
Période de diffusion : les dates de début et de fin indiquent combien de temps la création est restée active. Une publicité diffusée longtemps est un signal particulièrement fort : personne ne continue à payer pour une création qui ne convertit pas. Sa durée de diffusion est en soi le résultat d’un test A/B validé par de l’argent réel, mené par le concurrent.
Fourchette d’impressions : les bornes min/max offrent un indicateur approximatif de dépense. La valeur absolue n’est pas précise, mais elle suffit pour classer les achats publicitaires prioritaires.
Facettes de ciblage : ce qui est inclus ou exclu dans le ciblage. C’est l’intelligence d’audience la plus directe : les personnes que le concurrent estime susceptibles d’acheter son produit.

L’extraction des champs n’est qu’un moyen ; ces dimensions sont la finalité. Lors de l’écriture du parseur, il faut raisonner à l’envers : pour permettre les requêtes et le tri selon ces dimensions, quel est l’ensemble minimal de champs qu’il faut extraire de manière fiable ? Les champs sophistiqués restants peuvent parfaitement rester de côté sans réduire la valeur de l’intelligence produite.

Après une refonte, demander au modèle de comparer l’ancien et le nouveau HTML

Un parseur de ce type finira nécessairement par casser lors d’une refonte. C’est précisément là qu’un modèle a sa place, mais pas dans l’analyse elle-même. Le parsing est un travail déterministe, assuré par une machine à états codée en dur ; il ne faut pas y injecter des appels à un modèle (ne confiez pas un travail déterministe à un modèle, selon le même principe que pour le reverse engineering). Le rôle du modèle est la maintenance.

Le processus est le suivant : ouvrir la bibliothèque publicitaire avec son propre compte, conserver une copie du HTML avant la refonte et une autre après, puis les transmettre au modèle avec la liste des champs que le parseur extrait aujourd’hui. On lui demande alors d’identifier, à partir du diff ancien-nouveau, quelles ancres sémantiques ont changé, quelle devrait être la nouvelle ancre et quelles quelques lignes modifier au minimum. C’est un cas d’usage typique pour un niveau de raisonnement : le modèle doit déterminer si la sémantique correspondante existe toujours dans la nouvelle structure et proposer un plan applicable, pas se contenter de dire que « la structure a été modifiée ». Les étapes n’exigent pas les mêmes capacités ; employer un seul niveau de modèle partout coûte soit en budget, soit en précision :

Étape	Capacité requise	Choix	model id
Lire une page entière de HTML SSR et aligner l’ancienne structure avec la nouvelle	Contexte long, capable d’absorber d’un coup une page de détail de quelques dizaines à quelques centaines de KB	Kimi K3	`kimi-k3`
Après une refonte, lire le diff ancien-nouveau, déterminer où l’ancre a dérivé et proposer la correction minimale	Raisonnement solide, capable d’expliquer le changement structurel plutôt que de répéter le constat	Claude Opus 5	`claude-opus-5`
Normaliser et annoter en masse les cartes de centaines d’annonceurs pour en faire de l’intelligence	Coût réduit, centaines à milliers d’appels à forte concurrence	Claude Sonnet 5	`claude-sonnet-5`
Attribuer l’origine d’un écart lorsqu’une comparaison de fixtures échoue	Raisonnement intermédiaire, explication basée sur « champ attendu contre extraction réelle »	GPT-5.6 Sol	`gpt-5.6-sol`

Le deuxième niveau est le cœur du dispositif, et la seule étape où changer de modèle modifie visiblement le résultat. Ne me croyez pas sur parole pour savoir si le niveau de raisonnement en vaut la peine : testez-le. Le protocole est court :

Enregistrez le HTML d’une page avant une refonte, puis après celle-ci, en ouvrant la bibliothèque publicitaire avec votre propre compte et en sauvegardant la page.
Transmettez les deux HTML ainsi que la liste des champs du parseur actuel à claude-opus-5 et gpt-5.6-sol.
Regardez un seul point : le correctif identifie-t-il un changement d’ancre sémantique précis — « l’extraction s’appuyait sur le libellé “total impressions”, le rôle du conteneur de ce libellé a changé dans la nouvelle version, utilisez plutôt X » — ou répond-il vaguement que « la structure a été modifiée et qu’il faut la réadapter » ?
Le premier correctif est directement applicable ; le second n’apprend rien. Cette différence est votre critère de sélection et détermine directement le nombre d’itérations à l’aveugle le jour d’une refonte.

Un seul essai suffit à rendre la différence évidente, bien plus clairement que n’importe quel benchmark.

Le vrai frein, c’est le coût du changement de modèle

Ces quatre niveaux impliquent trois fournisseurs, trois SDK et trois mécanismes d’authentification, avec trois formats d’erreur. Face à l’intégration de trois clients pour des étapes différentes, la plupart des équipes concluent que l’effort ne se justifie pas pour « un correctif de parseur occasionnel et du nettoyage de données en volume ». Elles utilisent alors un seul modèle de bout en bout, y compris pour réparer une refonte, avec un niveau qui répond seulement « il est recommandé de réadapter », ce qui fait perdre du temps sans même comprendre pourquoi.

AIReiter aplanit cette couche : une clé, une interface compatible OpenAI, les quatre niveaux disponibles derrière, et un simple changement du champ model dans le corps de la requête pour basculer de l’un à l’autre.

# Redesign fix: the reasoning tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<old-new HTML diff + current field list, ask where the anchor drifted>"}]
  }'

# Bulk intelligence normalization: change the model field, leave the rest
#   "model": "claude-sonnet-5"
# Long context to read the whole page: "model": "kimi-k3"
# Difference attribution:               "model": "gpt-5.6-sol"

Si vous utilisez déjà le SDK OpenAI, pointez base_url vers https://aireiter.com/api/v1 sans rien modifier d’autre. Avec le SDK Anthropic, utilisez POST /api/v1/messages avec la même clé.

Côté tarifs, les modèles Claude bénéficient de 30 % de réduction sur le prix catalogue, les modèles GPT sont à moitié prix, et Kimi K3 est accessible avec la même clé. Dans ce flux, la remise s’applique exactement là où se trouve le coût principal. Ce coût n’est pas la correction après refonte — un appel ponctuel, peu fréquent, mais à forte valeur — mais la normalisation de l’intelligence en masse : on suit vingt annonceurs concurrents, avec quelques dizaines à quelques centaines de cartes chacun, toutes envoyées au modèle pour en extraire promesse, audience et période de diffusion. C’est l’étape la plus dense en appels, exécutée sur Claude Sonnet avec 30 % de réduction. L’entrée long contexte, nécessaire pour lire une page entière et aligner les structures, est la deuxième plus dense. Les deux postes les plus coûteux profitent donc directement de la remise.

Obtenir une clé API
Essayer sans inscription : donnez manuellement une paire de HTML avant-après aux deux modèles et comparez leur capacité à identifier concrètement la dérive de l’ancre, puis décidez si l’intégration en vaut la peine.

Une fois le correctif appliqué et les cartes brutes normalisées en volume, l’étape suivante consiste à injecter cette intelligence dans le pipeline créatif, pour guider les décisions et générer les assets. C’est le rôle de la boucle complète, du mot-clé à la publicité finalisée ; cet article en couvre le segment initial : récupérer de façon fiable les données publiques.

La fixture reste juge final de l’exactitude des champs

La correction proposée par le modèle n’est qu’une hypothèse tant qu’elle n’a pas été validée. Il peut affirmer que « l’ancre doit devenir X » et l’argument peut sembler convaincant, sans garantir que X fonctionne sur toutes les cartes. Les publicités B2B existent en image avec texte, en texte seul, en carrousel, avec ou sans page de destination ; les deux échantillons étudiés par le modèle ne les couvrent peut-être pas tous.

Le garde-fou est le même que celui utilisé contre les hallucinations en reverse engineering : la comparaison sur vecteur fixe. Conservez un lot d’entrées connues — quelques HTML de pages réelles sauvegardées — et leurs sorties correctes connues — des résultats de champs vérifiés manuellement une fois — sous la forme d’une fixture versionnée dans le dépôt. À chaque modification du parseur, qu’elle soit faite à la main ou suggérée par le modèle, relancez cette batterie et comparez les résultats champ par champ. C’est le seul moyen de savoir rapidement, après une refonte amont, si « la suggestion a été mal appliquée » ou si « la page a encore changé ». Si tout passe, la modification est correcte ; si quelques cas échouent, les champs en échec indiquent directement à quel niveau se trouve le problème. Le modèle produit des pistes de correction ; la fixture décide si elles sont justes. Les deux ne doivent jamais être confondus. La méthode complète de comparaison différentielle est présentée dans l’article consacré aux tests différentiels, et le parseur de bibliothèque publicitaire applique le même garde-fou. Sans cette couche, on prend l’assurance du modèle pour de la justesse, avec le risque classique : « appliquer la suggestion, ne voir aucune erreur, déployer, puis découvrir trois jours plus tard que les données d’un pays sont vides depuis le début ».

À retenir

L’intelligence publicitaire B2B passe par le HTML, car la bibliothèque publicitaire est un dispositif de conformité et non une API produit : pas de contrat d’API, et des refontes possibles à tout moment. La résistance à l’usure repose sur trois principes : des ancres sémantiques plutôt que positionnelles, une dégradation propre lorsqu’un champ manque plutôt qu’une exception, et des résultats qualifiés en complétude pour ne pas confondre « vide » et « cassé ». La véritable valeur ne réside pas dans les champs d’une publicité individuelle, mais dans les dimensions pays / période de diffusion / fourchette d’impressions / facettes de ciblage qui permettent de découper le lancement d’un concurrent. La place du modèle est précise : pas dans le parsing, qui relève d’une machine à états déterministe, mais dans la maintenance. Après une refonte, comparer l’ancien et le nouveau HTML pour suggérer une réparation est le terrain du niveau de raisonnement ; transformer les cartes en intelligence à grande échelle relève du niveau économique à forte concurrence. Mais l’exactitude des champs revient toujours à la fixture. En connectant ces niveaux à une interface unifiée, il ne reste comme friction que le changement du champ model, résolu en choisissant votre modèle.