Deep Research : ce qu'on a trouve, ce qu'on attend de vous
3 sujets etudies par 3 devs, chacun avec un Deep Research multi-provider (3 IA independantes), puis confrontation au terrain (code, donnees reelles, Grafana).
Aujourd'hui : les conclusions et les decisions qui dependent du metier.
Notre approche
Chaque dev a pris un sujet de la roadmap et suivi un processus structure en 4 etapes.
Cadrage
Formuler les bonnes questions avec le dev. Iterer via Q&A interactif pour affiner les axes.
Deep Research
3 IA independantes (OpenAI o3, o4-mini, Gemini) cherchent en parallele. Rapports de 5-15 pages chacun.
Confrontation terrain
Le dev confronte les resultats au code, aux donnees reelles, a Grafana. C'est la que les biais tombent.
Decision
Identifier les gates, les next steps, et ce qui depend du metier.
La recherche IA : un accelerateur, pas un oracle
Le DR produit de la matiere riche en quelques heures. Mais il se trompe regulierement sur notre contexte. C'est en le confrontant au terrain qu'on trouve les vraies conclusions.
Ce que ca fait bien
- Balayer un sujet large en quelques heures
- Identifier des options qu'on n'aurait pas vues
- Challenger nos intuitions (Red Team)
- Structurer un plan d'action par phases
Ou ca se trompe
- Suppose des choses fausses sur notre architecture
- Formule les questions avec un biais "il faut le faire"
- Les chiffres d'uplift viennent du marketing des providers
- Ne connait pas notre contexte terrain
Exemple concret : ID Externes
- Pluguer 2-3 nouveaux providers S2S en urgence
- Investir 60-90 jours de dev
- Devenir operateur UID2
- On forward deja 200+ sources EU, 500+ US
- Probablement pas besoin de pluguer quoi que ce soit
- Le gain marginal de UID2 est faible vu ce qu'on a
Le DR estimait l'etat des lieux a 2-3 jours. Yann l'a fait en 5 minutes. Sans cette verification, on serait parti dans du dev inutile.
Les 3 sujets etudies
Attention KPI — Un sujet reel mais premature
L'attention est une metrique emergente demandee par le marche. Mais on n'a pas les informations pour decider.
Pas de standard marche
Chaque provider (IAS, Adelaide, Lumen) a sa propre definition. Pas de spec commune. Si on developpe un score maison, rien ne garantit qu'il sera reconnu.
L'objectif n'est pas de vendre aux DSP
C'est de conditionner nos offer templates en interne. On ne met pas un score attention dans la bid request. On veut mieux placer nos offres sur l'inventaire qui capte l'attention.
On n'a pas les infos pour decider
Personne n'a fait de devis chez les providers. Personne n'a demande aux DSP s'ils paieraient plus cher. Le DR dit "trop cher" mais on n'a aucun chiffre.
Risques identifies (Red Team)
- Fraude — Un editeur malveillant peut simuler des signaux d'attention (jeu du chat et de la souris)
- Reputation — Si on vend du "premium attention" et qu'on se fait avoir : impact reputationnel
- Ressources — Pas de personne dediee = timeline qui s'etire (18-24 mois estimes)
- Technique — Le heartbeat 15s du DR est incompatible avec notre refresh 7-10s
Bouton Tests Extremes — Un POC de 3 jours avant tout
Un bouton "derniere chance" pour tenter de ressusciter un editeur blackliste — on bypass les blacklists internes, on boost le CPM, et on observe pendant 7 jours.
Ce qu'on fait
- Bypass blacklists internes SW uniquement
- Boost CPM pour attirer les reponses
- Rollback automatique si non concluant
- Pre-qualification obligatoire (ads.txt, volume, score qualite)
Ce qu'on ne fait PAS
- Toucher a la blacklist DSP — "un coup a se pourrir le bidder"
- Laisser ouvert apres un test non concluant
- Plus de 3 tests en parallele
- Tester un editeur sans ads.txt valide
Decouverte en live
Un editeur montre en exemple pendant la prez avait sa ligne ads.txt mal formatee (espaces au lieu de virgules). Le bouton ne l'aurait jamais sauve — c'est un probleme de setup basique, pas d'algo.
Vision long terme : le bouton est un patch temporaire. La vraie solution est le Thompson Sampling (exploration automatique), prevu H1 2027.
ID Externes — On a deja ce qu'il faut
5 minutes de log reseau sur un front EU et un front US ont change toutes les conclusions.
On fait deja passe-plat integral
Tous les external IDs recus sont forwardes aux partenaires. Les gains annonces par les providers (+20% CPM) partent d'un scenario ou on n'a rien — ce n'est pas notre cas.
Biais corrige : on n'est pas en direct avec les DSP
Le DR supposait des connexions directes (Trade Desk, DV360...). En realite, on passe par des exchanges intermediaires. Seuls Criteo et LoopMe sont en direct. Ca invalide le "routage selectif par DSP".
ID5 couvre deja les cas critiques
ID5 (deja integre) enrichit les adcalls quand il n'y a rien d'autre. Pluguer UID2 en plus apporterait un gain marginal.
Ce qu'on ne fait PAS
Le fil rouge : mesurer l'incremental
Le meme probleme revient dans les 3 sujets. On empile des fonctionnalites sans jamais mesurer leur impact individuel.
"Est-ce que l'offer template rapporte quelque chose ?"
"Est-ce que le bouton a vraiment sauve l'editeur ?"
"Est-ce que forwarder 200 sources rapporte vs 5 ?"
On a besoin d'un systeme d'A/B testing capable d'isoler une variable (un provider, une offer template, un floor) et de mesurer l'impact sur le revenu avec significativite statistique.
C'est le sujet roadmap #7 — Feature A/B Testing (SP-3628) qui conditionne la capacite de decision sur tous les autres.
Toutes les actions metier
Vue consolidee de ce qu'on attend de vous.
| Sujet | Action | Responsable | Priorite |
|---|---|---|---|
| Attention | Devis Adelaide, Lumen, IAS | Bruno / Commercial | Haute |
| Attention | Sonder 5 partenaires sur l'appetit attention | Bruno / Commercial | Haute |
| Attention | Confirmer usage = interne (offer templates) | Bruno | Moyenne |
| Tests Extremes | Evaluer le nombre d'editeurs sauvables + revenue | Adel / BU Publisher | Haute |
| Tests Extremes | Decider qui a acces au bouton | Adel / Max | Moyenne |
| ID Externes | Demander aux partenaires leur politique external IDs | Bruno / Commercial | Haute |
| ID Externes | Identifier si un DSP conditionne son spend sur un ID | Bruno | Moyenne |
| ID Externes | Relancer test Evron (plusieurs jours) | Bruno + Yann | Basse |
Et apres ?
- Actions metier ci-dessus
- POC Tests Extremes (3j)
- Monitoring external IDs
- Go/no-go par sujet
- Arbitrage budget attention
- Decision Evron
- Dev des sujets valides
- Thompson Sampling (planif)
- A/B Testing (sujet #7)
On ne lance aucun dev tant qu'on n'a pas les reponses a ces questions.
C'est le principe de la Phase 0 : valider avant de construire.