SerpApi vs Google : le scraping de SERP face au DMCA

Google poursuit SerpApi pour violation du DMCA. SerpApi répond que Google ne détient aucun copyright sur des résultats de recherche générés algorithmiquement à partir de contenus tiers. Si le tribunal donne raison à SerpApi, c'est toute l'industrie du SERP scraping — et une bonne partie de l'outillage SEO — qui se retrouve en terrain dégagé.

Ce que SerpApi conteste exactement

SerpApi a déposé une motion to dismiss contre la plainte de Google en arguant que le géant de Mountain View n'a pas le standing (la qualité pour agir) nécessaire pour invoquer le copyright sur ses pages de résultats. L'argument est chirurgical : une page de résultats Google n'est pas une œuvre originale au sens du Copyright Act américain. C'est un assemblage automatisé de snippets, de liens, de données structurées et de metadata issus de sites tiers.

La distinction juridique est cruciale. Pour bénéficier de la protection DMCA, Google doit démontrer qu'il détient un copyright valide sur le contenu scraped. Or, une SERP typique contient :

Des title tags rédigés par les webmasters des sites indexés
Des meta descriptions rédigées par ces mêmes webmasters
Des extraits de contenu tirés des pages crawlées
Des données structurées (prix, avis, FAQ) fournies par les éditeurs via Schema.org
Des URLs appartenant à des tiers

La seule contribution "originale" de Google réside dans l'ordonnancement des résultats (le ranking) et la mise en page. SerpApi argue que cette disposition ne constitue pas une expression créative suffisante pour atteindre le seuil d'originalité requis par la jurisprudence Feist Publications v. Rural Telephone (1991), qui a établi qu'une compilation de faits n'est protégeable que si elle présente un degré minimal de créativité dans la sélection ou l'arrangement.

La zone grise des AI Overviews

L'affaire se complique avec les AI Overviews de Google. Ces résumés générés par IA sont-ils une œuvre originale de Google ? SerpApi n'a pas directement abordé ce point dans sa motion, mais la question plane. Si un tribunal décide que les résultats classiques ne sont pas protégeables, qu'en est-il du texte généré par Gemini dans les AI Overviews ? La réponse dépendra de savoir si un output de LLM constitue une "authorship" au sens du droit américain — un débat encore ouvert au Copyright Office.

Anatomie technique du scraping de SERP

Pour comprendre les enjeux techniques, regardons comment fonctionne concrètement le scraping de SERP tel que le pratique SerpApi, et comment vos propres outils SEO procèdent de manière similaire.

Ce que scrape réellement un outil de SERP tracking

Un scraper de SERP envoie une requête HTTP à Google avec les mêmes paramètres qu'un navigateur classique, puis parse le HTML retourné. Voici une requête type :

curl -s "https://www.google.com/search?q=chaussures+running+homme&gl=fr&hl=fr&num=100" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" \
  -H "Accept-Language: fr-FR,fr;q=0.9" \
  -H "Accept: text/html,application/xhtml+xml" \
  --compressed \
  | htmlq '.g' --text

Le HTML retourné par Google contient une structure DOM que les scrapers parsent pour extraire les éléments de chaque résultat. Voici un extrait simplifié de la structure d'un résultat organique classique :

<div class="g" data-hveid="CAoQAA" data-ved="2ahUKEwj...">
  <div class="yuRUbf">
    <div>
      <span>
        <a href="https://www.decathlon.fr/chaussures-running-homme"
           data-jsarwt="1" data-usg="AOvVaw0..." ping="/url?sa=t&amp;source=web...">
          <br>
          <h3 class="LC20lb MBeuO DKV0Md">
            Chaussures Running Homme - Decathlon
          </h3>
          <div class="notranslate HGLrXd NJjxre">
            <div class="tjvcx GvPZzd cHaqb">
              <cite class="qLRx3b tjvcx">
                https://www.decathlon.fr › chaussures-running-homme
              </cite>
            </div>
          </div>
        </a>
      </span>
    </div>
  </div>
  <div class="VwiC3b yXK7lf lVm3ye r025kc hJNv6b Hdw6tb" style="-webkit-line-clamp:2">
    <span>Découvrez notre sélection de <em>chaussures de running</em> 
    pour <em>homme</em>. Livraison gratuite en magasin...</span>
  </div>
</div>

Regardez attentivement : le titre h3 est le title tag de Decathlon. L'URL est celle de Decathlon. Le snippet est un extrait du contenu de Decathlon. Google a ajouté la mise en page, les classes CSS, les attributs de tracking (data-ved, ping), mais le contenu informationnel appartient entièrement au site tiers.

Le parsing côté scraper

Un scraper comme SerpApi utilise typiquement un parser HTML pour extraire ces éléments de manière structurée. Voici ce que fait concrètement le code de parsing :

import * as cheerio from 'cheerio';

interface OrganicResult {
  position: number;
  title: string;
  url: string;
  snippet: string;
  displayedUrl: string;
}

function parseSERP(html: string): OrganicResult[] {
  const $ = cheerio.load(html);
  const results: OrganicResult[] = [];
  let position = 0;

  $('.g').each((_, element) => {
    const titleEl = $(element).find('h3.LC20lb');
    const linkEl = $(element).find('a[data-jsarwt]');
    const snippetEl = $(element).find('.VwiC3b');
    const citeEl = $(element).find('cite.qLRx3b');

    if (titleEl.length && linkEl.length) {
      position++;
      results.push({
        position,
        title: titleEl.text().trim(),
        url: linkEl.attr('href') || '',
        snippet: snippetEl.text().trim(),
        displayedUrl: citeEl.text().trim(),
      });
    }
  });

  return results;
}

// Chaque champ extrait provient du site source, pas de Google
// Le title = title tag du site, le snippet = contenu du site
// Seul l'ordonnancement (position) est déterminé par Google

C'est exactement ce point que SerpApi exploite dans sa défense juridique. Les données extraites ne sont pas "de Google" — elles transitent par Google.

L'impact concret sur l'écosystème SEO

Presque tous les outils SEO professionnels reposent, directement ou indirectement, sur du scraping de SERP. Semrush, Ahrefs, Moz, SE Ranking, AccuRanker — chacun maintient une infrastructure de scraping massive pour alimenter ses bases de données de positions.

Scénario : un e-commerce de 12 000 pages suivi en position tracking

Prenons le cas de LaMaisonDuSport.fr, un e-commerce de matériel sportif avec 12 000 pages produit et 800 pages catégorie. L'équipe SEO suit 3 500 mots-clés en position tracking quotidien via un outil comme AccuRanker.

Chaque jour, l'outil envoie 3 500 requêtes à Google (ou plus, si le suivi est multi-device et multi-localisation). Sur un mois, c'est 105 000 requêtes de scraping. Multipliez par les dizaines de milliers de clients d'un seul outil de rank tracking, et vous comprenez l'échelle.

Si Google obtient gain de cause et que le DMCA s'applique au scraping de SERP, les conséquences en cascade seraient considérables :

Coût d'accès aux données de position : les outils devraient passer par les API officielles de Google (qui ne fournissent pas de données de position, Search Console ne donnant que la position moyenne et pas le ranking en temps réel).
Disparition du rank tracking indépendant : sans scraping, plus de vérification indépendante des positions. Vous seriez dépendant uniquement de ce que Google Search Console veut bien vous montrer.
Impact sur la R&D SEO : les études de corrélation (backlinks vs position, Core Web Vitals vs ranking) deviendraient juridiquement risquées à produire.

Ce que dit le robots.txt de Google

L'argument technique de Google repose en partie sur les restrictions de son robots.txt. Vérifions :

curl -s "https://www.google.com/robots.txt" | head -40

Le robots.txt de Google interdit explicitement le crawl de /search :

User-agent: *
Disallow: /search
Disallow: /sdch
Disallow: /groups
Disallow: /images?
Disallow: /catalogs
...

Ce Disallow: /search est l'un des piliers de l'argumentation de Google : SerpApi ignore sciemment une directive explicite. Mais du point de vue juridique, un robots.txt n'a aucune force légale contraignante. C'est une convention — le Robots Exclusion Protocol est un standard technique, pas un contrat. Le tribunal devra déterminer si violer un robots.txt constitue un accès non autorisé au sens du Computer Fraud and Abuse Act (CFAA) — une question distincte du DMCA.

Les précédents juridiques qui pèsent dans la balance

hiQ Labs v. LinkedIn (2022)

Le précédent le plus pertinent est l'affaire hiQ Labs v. LinkedIn. La Cour d'appel du 9ème circuit a statué que le scraping de données publiquement accessibles ne constitue pas une violation du CFAA. LinkedIn avait tenté de bloquer hiQ, une société de data analytics RH, qui scrapait les profils publics LinkedIn.

La cour a raisonné que si un contenu est accessible à tout internaute sans authentification, l'accès automatisé ne peut pas être considéré comme "non autorisé" au sens du CFAA. Ce raisonnement s'applique directement aux pages de résultats Google, accessibles sans aucune authentification.

Mais Google contourne cet argument en invoquant le DMCA plutôt que le CFAA — un choix stratégique. Le DMCA ne concerne pas l'accès non autorisé mais la violation de copyright. C'est là que la question de l'originalité des SERP devient décisive.

Feist v. Rural Telephone et la doctrine de la compilation

L'arrêt Feist (1991) de la Cour Suprême a invalidé la "sweat of the brow doctrine" — l'idée que le simple effort de compilation suffit à créer un copyright. Pour qu'une compilation soit protégeable, elle doit démontrer une sélection, une coordination ou un arrangement original.

Google peut argumenter que son algorithme de ranking constitue une "sélection et arrangement" créatif. C'est un argument solide — l'algorithme de Google est indéniablement sophistiqué. Mais SerpApi peut répondre que ce qui est protégeable n'est pas le résultat visible (l'ordre des liens) mais l'algorithme lui-même (qui est un secret commercial, protégé par d'autres mécanismes juridiques).

Les implications techniques pour votre stack de monitoring SEO

Quelle que soit l'issue du procès, il est stratégique de réduire votre dépendance au scraping direct de SERP pour les données critiques.

Diversifier vos sources de données de position

La Search Console reste la source la plus fiable pour les données de position agrégées. Voici comment automatiser l'extraction via l'API :

import { google } from 'googleapis';

const auth = new google.auth.GoogleAuth({
  keyFile: './service-account.json',
  scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
});

const searchconsole = google.searchconsole({ version: 'v1', auth });

async function getPositionData(siteUrl: string, startDate: string, endDate: string) {
  const response = await searchconsole.searchanalytics.query({
    siteUrl,
    requestBody: {
      startDate,
      endDate,
      dimensions: ['query', 'page'],
      rowLimit: 25000,
      dimensionFilterGroups: [{
        filters: [{
          dimension: 'country',
          expression: 'fra',
        }],
      }],
      // Attention : la position retournée est une MOYENNE pondérée
      // par les impressions. Pas un ranking instantané.
      dataState: 'final',
    },
  });

  return response.data.rows?.map(row => ({
    query: row.keys?.[0],
    page: row.keys?.[1],
    clicks: row.clicks,
    impressions: row.impressions,
    ctr: row.ctr,
    position: row.position, // Moyenne, pas position exacte
  })) || [];
}

// Pour LaMaisonDuSport.fr, cette approche couvre 80% des besoins
// de reporting sans aucun scraping de SERP

Le trade-off est connu : la Search Console API fournit des données moyennées avec un décalage de 2-3 jours, pas du rank tracking en temps réel. Pour le suivi quotidien de positions sur des requêtes stratégiques, le scraping reste sans alternative directe.

Monitorer ce que Google voit de votre côté

Plutôt que de scraper les SERP pour vérifier votre présence, surveillez ce que Google voit réellement sur vos pages. Si vos meta tags sont correctement servies, que votre SSR fonctionne et que vos canonicals sont cohérents, vous contrôlez la majeure partie de l'équation.

Un outil de monitoring comme SEOGard détecte en continu les régressions techniques (title tag disparu, meta description manquante, SSR cassé après un déploiement) qui affectent votre apparence dans les SERP — sans avoir besoin de scraper Google pour le constater.

L'approche hybride : CrUX + Search Console + monitoring on-site

La stack la plus résiliente combine trois couches :

Search Console API pour les données de position agrégées et les problèmes d'indexation
Chrome UX Report (CrUX) pour les Core Web Vitals à l'échelle, via l'API BigQuery
Monitoring on-site pour détecter les régressions techniques avant qu'elles n'impactent le ranking

Cette approche élimine le besoin de scraping de SERP pour 90% des cas d'usage de monitoring opérationnel. Le 10% restant — suivi de position en temps réel sur des requêtes concurrentielles — reste dépendant du scraping, et donc directement impacté par l'issue du procès Google v. SerpApi.

Ce que le procès révèle sur le rapport de force Google vs. l'écosystème SEO

Au-delà de l'aspect juridique, cette affaire cristallise une tension fondamentale. Google crawle l'intégralité du web, extrait le contenu de millions de sites, et le réorganise dans ses SERP (y compris dans les AI Overviews qui synthétisent le contenu des éditeurs). Quand un tiers fait la même chose avec les SERP de Google, le géant invoque le DMCA.

L'asymétrie est frappante. Google argue que son crawl est autorisé par les webmasters (via robots.txt et les meta robots), tandis que son propre robots.txt interdit le crawl de /search. Mais cette autorisation est largement théorique : pour un site e-commerce qui dépend de Google pour 60-70% de son trafic, bloquer Googlebot n'est pas une option réaliste. C'est un consentement sous contrainte économique.

SerpApi pousse cette logique : si Google peut compiler et redistribuer le contenu de tiers dans ses SERP sans leur verser de redevance, alors ces compilations ne devraient pas bénéficier d'une protection copyright quand un tiers les re-compile à son tour.

L'argument du "thin copyright"

Même si le tribunal reconnaît un copyright sur les SERP, il pourrait n'accorder qu'un "thin copyright" — une protection limitée à l'arrangement spécifique, pas aux éléments individuels. Dans ce cas, SerpApi pourrait arguer qu'il n'extrait que les éléments non-protégés (URLs, titles, snippets — tous issus de tiers) sans reproduire l'arrangement protégé (la mise en page spécifique de Google).

C'est un argument techniquement défendable. Ce que retourne un scraper comme SerpApi n'est pas une copie visuelle de la page Google — c'est une extraction structurée de données (JSON) qui ne reproduit ni le CSS, ni le layout, ni les éléments d'interface de Google.

Comment préparer votre infrastructure quelle que soit l'issue

Vérifiez votre dépendance au scraping de SERP

Faites l'inventaire de tous les outils de votre stack qui reposent sur du scraping de SERP :

Rank tracking : AccuRanker, SEMonitor, SERPWatcher, Advanced Web Ranking
Analyse de SERP : SerpApi, ValueSERP, ScaleSerp, Zenserp
Outils tout-en-un : les modules de position tracking de Semrush, Ahrefs, SE Ranking

Si Google gagne ce procès et applique sa victoire agressivement, les fournisseurs les plus petits (qui n'ont pas les moyens de négocier un accord de licence) seront les premiers impactés. Les grands acteurs (Semrush, Ahrefs) ont les ressources pour soit négocier, soit contester juridiquement, soit pivoter techniquement.

Renforcez votre monitoring côté serveur

La donnée la plus actionable en SEO technique n'est pas votre position sur un mot-clé — c'est l'état de santé de vos pages tel que Googlebot les perçoit. Un problème de rendering SSR ou un mismatch d'hydration vous coûtera bien plus de trafic qu'un mouvement de 2 positions sur un keyword.

Investissez dans le monitoring des éléments que vous contrôlez : intégrité des meta tags, temps de réponse serveur, cohérence du rendering, validité des données structurées, santé des backlinks. Ce sont des signaux d'alerte précoce qui ne nécessitent aucun scraping de SERP.

Le calendrier et ce qu'il faut surveiller

La motion to dismiss de SerpApi sera examinée par le tribunal dans les prochaines semaines. Trois issues possibles :

Motion accordée : le tribunal considère que Google n'a pas de standing DMCA sur les SERP. Le cas est clos, précédent majeur en faveur du scraping.
Motion rejetée : le tribunal considère que Google a un copyright défendable. Le procès continue au fond, avec potentiellement un procès devant jury.
Motion partiellement accordée : le tribunal rejette le DMCA mais laisse les autres claims (CFAA, breach of contract) suivre leur cours.

L'issue 3 est la plus probable. Les tribunaux américains ont tendance à laisser les affaires complexes aller au fond plutôt que de les trancher sur motion to dismiss. Mais même un rejet partiel des claims DMCA constituerait un signal fort pour l'industrie.

L'affaire Google v. SerpApi dépasse largement le cadre d'un conflit entre deux entreprises. Elle pose la question de la propriété des données de recherche dans un écosystème où Google est à la fois l'infrastructure, le juge et la partie. Pour les équipes SEO, la leçon immédiate est de diversifier les sources de données et de renforcer le monitoring on-site — les régressions techniques que SEOGard détecte automatiquement ont un impact mesurable sur votre visibilité, et cette donnée-là n'a besoin d'aucun scraping de SERP pour être exploitable.