Méthodologie

De quoi il s'agit

Il s'agit d'une agrégation indépendante et non officielle de données publiques de rapports de transparence, sans aucune affiliation à une plateforme, une entreprise ou un gouvernement. Elle réunit deux ensembles de rapports dans un seul schéma interrogeable :

• Rapports de transparence DSA de l'UE
  Statistiques périodiques de modération de contenu que les fournisseurs publient au titre du règlement européen sur les services numériques (DSA) — les rapports de transparence récurrents exigés par les articles 15, 24 et 42 du DSA (les obligations de déclaration applicables respectivement aux services intermédiaires, aux plateformes en ligne et aux très grandes plateformes), à ne pas confondre avec la base de données de transparence DSA distincte, en temps réel, des exposés des motifs individuels. Les déclarants utilisent un modèle européen commun et à plusieurs niveaux : chaque fournisseur ne remplit que les sections de déclaration que son niveau requiert (ce jeu de données indexe ces sections en interne sous t3–t11). Il couvre les très grandes plateformes en ligne et moteurs de recherche en ligne (VLOPs / VLOSEs) — ceux que la Commission européenne a formellement désignés en raison de leur portée dans l'UE — qui déclarent plus fréquemment et plus en détail, aux côtés de dizaines de plateformes plus modestes. Consultez le tableau de bord des Rapports DSA pour les décomptes en direct et la période couverte.
• Demandes de retrait gouvernementales de Google
  Les comptages déclarés par Google des demandes gouvernementales de retrait de contenu, par pays, produit, motif et période de déclaration — le rapport de transparence volontaire de longue date propre à Google, et non un dépôt au titre du DSA. Explorez-les sur le tableau de bord des Retraits Google.

L'endroit où chaque plateforme publie son rapport sous-jacent est répertorié sur la page Emplacements des rapports, avec des liens vers des copies archivées des fichiers sources.

D'où proviennent les données

Chaque chiffre provient de la plateforme ou de l'entreprise qui l'a publié — ce sont leurs chiffres déclarés, reproduits sans en modifier les valeurs déclarées, et non des estimations produites par ce projet. La contribution apportée ici est l'agrégation et la structuration : collecter les rapports publiés individuellement, en extraire les tableaux, et les normaliser dans un schéma unique afin qu'ils puissent être comparés et interrogés. Les valeurs déclarées elles-mêmes ne sont jamais modifiées ; les transformations sont structurelles — extraction, signalement des lignes de total agrégé, normalisation des libellés d'une langue à l'autre, et suppression des lignes qui ne peuvent être analysées — et sont décrites ci-dessous.

Comment un rapport devient interrogeable

Les tableaux de chaque rapport source sont extraits et chargés dans une base de données que l'API ouvre en lecture seule (défense en profondeur) et qu'elle n'atteint qu'à travers une interface capable de lire mais jamais d'écrire — organisée en schéma en étoile : une table de chiffres par table de rapport DSA (indexée en interne sous t3–t11), entourée de tables de correspondance partagées (services, catégories, sections, indicateurs, portées, surfaces, périodes de déclaration). Les libellés répétés sont stockés une seule fois et référencés par numéro, de sorte que le même nom de catégorie ou de plateforme n'existe qu'à un seul endroit. Parcourez les tables ainsi obtenues et chaque champ interrogeable sur la page Schéma.

Les neuf tables de rapport se décodent ainsi : t3 injonctions des États membres · t4 signalements (y compris signaleurs de confiance) · t5 / t6 actions de propre initiative (contenu illicite / conditions de service) · t7 recours & récidive · t8 recours aux moyens automatisés · t9 ressources humaines · t10 moyenne mensuelle des destinataires actifs · t11 descriptions qualitatives.

Quand un rapport ne correspond pas au modèle

La plupart des plateformes fournissent le classeur fixe à 11 sections, et le chargeur place chaque feuille selon le numéro de section indiqué dans son nom. Quelques-unes déposent une variante de format : le même contenu de modèle sous-jacent, mais avec des feuilles renommées ou renumérotées. Celles-ci sont mises en correspondance au moyen d'une table explicite, propre à chaque plateforme, reliant chaque feuille à sa section canonique, de sorte que les chiffres aboutissent toujours dans la bonne table de rapport : LINE condense le modèle en cinq feuilles non numérotées (rattachées aux sections 1, 3, 4, 5 et 11), tandis que Discord omet les sections sur l'initiative propre relative aux contenus illicites, sur les ressources humaines et sur les destinataires actifs, puis renumérote le reste — ses feuilles sont donc identifiées par leur nom (son « Own Initiative TC », par exemple, est la table d'initiative propre relative aux conditions du service, la section 6, et non la section 5). Un document qui n'est pas du tout le modèle harmonisé n'est pas forcé à y entrer, car le faire correspondre inventerait une structure que la source ne possède pas : le rapport du forum de heise est un bref résumé en format libre au titre de l'article 15, avec des catégories en texte libre en allemand, et WordPress.com publie un rapport différent (demandes DMCA, gouvernementales et IRU). Ceux-ci sont conservés comme fichiers sources archivés plutôt que chargés dans t3–t11.

Éviter le double comptage

Le modèle DSA place une ligne de total agrégé juste à côté des lignes de ventilation qu'elle additionne (par exemple une catégorie de total général « All the entries » à côté des décomptes par catégorie, une portée « Total number » à côté des décisions confirmées/annulées, ou une surface « All » qui additionne les lignes par surface telles que Core et Ads). Un SUM naïf sur une telle colonne compte les parties et leur propre total, gonflant ainsi le chiffre. Le chargeur marque chaque ligne agrégée avec un indicateur is_total et l'expose comme une dimension filtrable, de sorte qu'une requête peut délibérément choisir une seule granularité — totaux uniquement, ou ventilation uniquement — et ne jamais additionner un total avec ses composantes. Les chiffres phares du tableau de bord utilisent les totaux déclarés ; ses graphiques de ventilation utilisent les lignes de composantes. Lorsqu'un chiffre comporte encore une réserve, l'API renvoie une note warnings que le tableau de bord affiche à côté du résultat.

Lire d'une langue à l'autre

Les plateformes non-VLOP peuvent déposer le modèle harmonisé dans n'importe quelle langue officielle de l'UE, de sorte qu'une même ligne du modèle peut se présenter sous des textes différents (Decisions upheld / Décisions confirmées / Bestätigte Entscheidungen). Chaque ligne conserve son libellé en langue d'origine pour l'affichage, mais reçoit aussi un libellé standard neutre du point de vue de la langue — une clé canonique — établie au moyen d'une table de correspondance (un « crosswalk ») qui aligne les rapports de même structure sur une référence anglaise et écarte tout élément ambigu. Les requêtes peuvent regrouper ou filtrer sur la clé canonique afin de comparer ce qui est comparable d'une langue à l'autre, tout en affichant le texte d'origine — même si la couverture n'est pas encore uniforme pour chaque langue (voir Limites connues).

Comment l'interroger

Il n'y a pas d'interface SQL. Une requête est une demande structurée : elle nomme une table, un filtre booléen de conditions champ/opération/valeur, et, en option, un regroupement, des agrégats, un tri et des limites. Le serveur valide chaque champ et chaque opération par rapport au registre figé de cette table, puis les compile en une seule recherche dans la base de données vérifiée au préalable (un SELECT paramétré), où ce que vous saisissez est toujours traité comme des données et jamais exécuté comme une commande. Les requêtes sont également bornées —une taille de résultat plafonnée, des limites de taille et de complexité de la demande, et une limite de débit par clé—, de sorte qu'une seule demande ne puisse épuiser le service. Les requêtes « composites » inter-tables joignent deux tables ou plus sur des dimensions partagées en passant par cette même frontière validée. La boîte « Demander » en langage naturel, là où elle est activée, envoie votre question saisie (avec le schéma en étoile du jeu de données) à un LLM tiers (Claude, d'Anthropic) afin qu'il rédige une requête structurée, ensuite validée comme n'importe quelle autre avant son exécution ; cet appel au LLM est la seule fois où le service transmet de lui-même ce que vous saisissez à un tiers. La seule autre voie sortante est facultative et vous appartient : une callback_url facultative que vous joignez à une requête et qui livre votre propre résultat à une URL de votre choix. Essayez-le sur le tableau de bord Rapports DSA, ou consultez la référence de l'API et notre note sur la Confidentialité.

Reproductibilité & citation

La base de données est un instantané statique et en lecture seule. Chaque instantané porte une version du jeu de données immuable —une empreinte de son contenu, qui change donc dès que les données changent—, envoyée sous forme d'en-tête ETag et X-Dataset-Version, et chaque ligne de fait expose le report_id du rapport qui en est la source. Un chiffre est fixé par trois éléments réunis —la version du jeu de données, la requête exacte et le ou les report_id dont il est tiré—, alors citez les trois et les lignes pourront être récupérées de nouveau (la version et le report_id à eux seuls identifient un rapport source, pas un nombre particulier). Les résultats reviennent dans un ordre entièrement déterministe dès que vous triez ou paginez, de sorte qu'une extraction enregistrée est reproductible octet pour octet. La date de création de l'instantané et la période couverte figurent dans la ligne « Citer comme » de chaque tableau de bord et dans les en-têtes de chaque export, et le report_id d'une ligne identifie son rapport source (plateforme, période et palier) ; pour les plateformes non VLOP, le lieu de publication de ce rapport est répertorié par plateforme dans le catalogue des Emplacements des rapports.

Attribution : attribuez le chiffre à la plateforme qui l'a déclaré ; ne citez ce site qu'en tant qu'outil d'accès.

Exemple : YouTube, EU DSA transparency report (H2 2025), accessed via the Transparency Report API — dataset version 7f3c1a2b9d04, report_id 42, retrieved 2026-06-26. La version exacte du jeu de données et la période couverte pour l'instantané en direct figurent dans la ligne « Cite as » des tableaux de bord Rapports DSA et Retraits Google.

Limites connues

• Instantané, et non en direct
  Les chiffres reflètent les rapports disponibles au moment de la construction de l'instantané ; les corrections ultérieures ou les rapports nouvellement déposés n'apparaissent que dans un instantané suivant (avec une nouvelle version du jeu de données).
• La qualité des sources varie
  Les plateformes déposent leurs rapports avec une rigueur et une mise en forme variables. Les lignes parasites mal analysées (cellules d'en-tête, valeurs vides, valeurs aberrantes laissées par certaines extractions) sont écartées au chargement plutôt que devinées — tout comme les lignes du modèle que la table de correspondance interlangue ne peut pas mapper sans ambiguïté. Les décomptes exacts des lignes écartées et la couverture de la table de correspondance ne sont pas encore publiés, de sorte que l'exhaustivité globale n'est pas quantifiée.
• Certains libellés restent non normalisés
  Les extractions grecques présentent un décalage de colonne dans les données sources, c'est pourquoi la plupart des libellés grecs d'indicateurs/portées sont laissés corrects-mais-non-mappés plutôt que de risquer un mappage erroné ; les libellés de catégories ne sont pas encore mis en correspondance d'une langue à l'autre.
• Service de démonstration
  Il s'agit d'un projet de portfolio/démonstration. Il est fidèle à ses sources, mais ce n'est pas un registre officiel — pour toute décision importante, vérifiez toujours par rapport au rapport publié par la plateforme elle-même (lié depuis Emplacements des rapports).

Sources & code

Construit entièrement à partir de rapports publics. L'ensemble du pipeline — extraction, normalisation, table de correspondance et couche de requête — est open source à l'adresse github.com/krMaynard/transparency-report-api. Commencez à explorer : Rapports DSA · Retraits Google · Schéma.