Référence

Ce que nous conservons sur un domaine

Écrit pour les avocats et les délégués à la protection des données. Chaque terme technique est expliqué là où il apparaît pour la première fois.

Cette page répond en entier à une seule question : si MachineWitness observe un domaine, que contient exactement l'archive ? Non pas un résumé, mais les champs eux-mêmes. Nous déroulons un exemple traité, beispielfirma.example, depuis l'instant où notre observateur se connecte jusqu'au point où un tribunal pourrait vérifier l'enregistrement des années plus tard.

Avant de récupérer le moindre des fichiers ci-dessous, nous lisons le robots.txt du domaine et nous le respectons. Lorsqu'il nous demande de ne pas récupérer un fichier, nous ne le récupérons pas, et l'enregistrement le dit : l'observation de ce jour-là est consignée comme disallowed_by_robots, avec la provenance policy: robots_respected, à la place d'une réponse. C'est une affirmation différente de celle d'un serveur qui n'a pas répondu, et l'archive tient les deux cas séparés. Le 10 août 2026, cela concernait environ 14 000 des 128 347 domaines de l'anneau, pour les trois fichiers autres que le robots.txt lui-même. Nous pourrions les récupérer quand même (ces fichiers sont publics), et nous ne le faisons pas. La manière dont un robots.txt est lu est elle-même datée : jusqu'au 8 septembre 2026, les deux témoins l'interprétaient avec urllib.robotparser de Python, antérieur à la RFC 9309 ; le témoin 2 le lit selon la RFC 9309 (protego) depuis le 9 septembre 2026, le témoin 1 depuis le 11 septembre 2026. Les deux analyseurs ne divergent que dans des cas limites (jokers, priorité de la correspondance la plus longue) ; le fichier consigné est le même dans les deux cas, seule la décision de récupérer ou non les autres fichiers peut différer ces jours-là.

Deux précisions méritent d'être faites avant le détail. D'abord, nous ne récupérons que ce que n'importe quel navigateur peut récupérer sans s'authentifier : une poignée de petits fichiers de politique qu'un site publie à l'intention des machines. Nous n'explorons pas le contenu des pages, ne suivons pas de liens vers des applications et n'enregistrons rien sur les personnes qui visitent un site. Ensuite, rien de tout cela n'est secret. La valeur de cette archive ne tient pas à ce qu'elle détient, que chacun pourrait récupérer lui-même aujourd'hui ; elle tient à ce que nous l'avons détenu à une date passée déterminée et que nous pouvons prouver que l'enregistrement n'a pas été modifié depuis.

1. Ce que nous récupérons, par domaine

Cinq requêtes. Rien d'autre, jamais, pour un domaine de notre anneau large.

Ressource	Ce que c'est, et pourquoi cela compte juridiquement
/robots.txt	Le plus ancien fichier d'instructions lisible par machine du web. Il indique aux robots nommément désignés quelles parties d'un site ils peuvent récupérer. Comme les entreprises d'IA publient le nom de leurs robots (GPTBot, ClaudeBot, Google-Extended et d'autres), c'est dans ce fichier que la plupart des sites expriment, ou omettent d'exprimer, un refus de l'entraînement des modèles d'IA.
/ai.txt	Une convention plus récente, propre à l'IA, poursuivant le même but. Elle n'est pas encore normalisée, et c'est précisément pourquoi sa présence ou son absence à une date donnée peut être contestée par la suite.
/.well-known/tdmrep.json	La réserve formelle et lisible par machine des droits de fouille de textes et de données (TDM Reservation Protocol, W3C). Aux termes de l'article 4, paragraphe 3, de la directive européenne sur le droit d'auteur dans le marché unique numérique, la réserve d'un titulaire de droits n'est effective que si elle est lisible par machine ; l'Oberlandesgericht de Hambourg a confirmé en décembre 2025 que des conditions rédigées en langage naturel ne suffisent pas à elles seules. Ce fichier est le moyen le plus net de formuler cette réserve.
/llms.txt	Une convention émergente qui s'adresse directement aux grands modèles de langage.
/ (page d'accueil)	Récupérée uniquement pour ses en-têtes de réponse et ses premiers kilo-octets, jamais la page entière. Certains sites expriment leur réserve de fouille dans un en-tête HTTP ou une balise meta plutôt que dans un fichier.

Chaque réponse est plafonnée à une limite stricte d'octets. Ces fichiers font normalement quelques kilo-octets ; le plafond existe pour qu'un serveur mal configuré ne puisse pas nous faire télécharger quelque chose de volumineux.

Changement de méthode, applicable au 3 août 2026

À compter de cette date, l'archive applique les règles ci-dessous. Elles sont énoncées ici plutôt que laissées implicites, parce qu'un changement de méthode change ce qu'un enregistrement daté permet de prouver. Rien de ce qui précède le 3 août 2026 n'a été modifié ; les journées antérieures conservent la méthode en vigueur au moment de leur scellement.

Deux anneaux. Les règles diffèrent entre un petit noyau et un vaste anneau large. L'anneau large est défini par un critère énoncé, non par une sélection : tous les domaines de l'Union figurant dans la liste Tranco du premier million, telle que récupérée le 2 août 2026. Le noyau est un ensemble bien plus restreint de domaines observés de plus près. Il est constitué à la main et nous n'en publions pas encore les critères ; il doit donc se lire comme une sélection de travail, et non comme un registre établi.

Les quatre fichiers de réserve restent récupérés chaque jour, pour chaque domaine. C'est la partie qui porte la valeur juridique, et elle est inchangée.
La page d'accueil est récupérée chaque semaine, et non chaque jour, pour les domaines de l'anneau large. La conséquence, dite franchement : lorsqu'un site n'exprime sa réserve que dans une balise meta ou un en-tête HTTP de sa page d'accueil, notre relevé de cette réserve dans l'anneau large est précis à la semaine, non au jour. Pour le noyau, rien ne change : la page d'accueil y est toujours récupérée quotidiennement.
Les plafonds d'octets diffèrent selon l'anneau. Noyau : sans plafond. Anneau large : 256 Ko, tout ce qui dépasse étant marqué truncated. Ce qui est conservé est toujours le début de la réponse, là où se trouvent ces signaux.
Les réponses d'erreur sont consignées sans leur corps. Le code de statut, l'ensemble des en-têtes, la taille et l'empreinte du contenu sont conservés, de sorte que la réalité et la forme de l'erreur restent prouvables ; la page d'erreur elle-même n'est pas stockée. Une exception : les corps de réponse 403 Forbidden sont conservés jusqu'à 32 Ko, parce qu'un refus visant les robots y est parfois formulé.

Changement de méthode, applicable au 17 septembre 2026

À compter de cette date, le relevé s'étend en trois points. Comme auparavant, rien d'antérieur n'a été modifié : les journées précédant le 17 septembre 2026 conservent la méthode en vigueur au moment de leur scellement. Le premier passage sous le nouveau périmètre a commencé le 17 septembre 2026 à 03:00 UTC.

Le noyau repose désormais sur un critère énoncé. Jusqu'au 16 septembre 2026, il était une sélection de travail de 115 domaines, constituée à la main. Depuis le 17 septembre, il compte 1 133 domaines, composés ainsi : 1 057 domaines d'organisations de l'Union qui publient, recensées dans Wikidata avec un site actif, qu'il s'agisse de journaux et de sites d'information, de radiodiffuseurs, d'éditeurs de livres, d'agences de presse et d'agences photographiques ou de sociétés de gestion collective, et dont le site portait en même temps un signal adressé aux robots d'exploration IA que nous avions déjà relevé : une règle visant un robot IA nommé dans le robots.txt ou un en-tête Content-Signal. Ils se répartissent dans 26 États membres. S'y ajoutent 43 autres éditeurs recensés dans Wikidata qui figuraient déjà dans l'anneau et ne portent pas un tel signal ; 14 domaines conservés de la sélection antérieure pour un motif énoncé ; 4 domaines qui portent un tel signal mais n'ont pas d'entrée dans Wikidata ; et les 15 domaines de la propre société de l'exploitant, tenus comme série de contrôle plutôt que dissimulés. Pour chaque domaine du noyau, le relevé nomme désormais l'organisation, son pays et son identifiant Wikidata. Lorsque Wikidata attribue un domaine à plus d'une organisation, le libellé le plus court a été retenu et l'entrée est marquée comme non arrêtée (61 domaines), à corriger au fil de la curation ; le domaine lui-même n'en est pas affecté. Les règles du noyau du 3 août 2026, page d'accueil quotidienne et absence de plafond d'octets, s'appliquent à tous depuis le 17 septembre. L'anneau large est inchangé. Un domaine de la propre société de l'exploitant, qui ne se résout plus dans le DNS, a été retiré de l'anneau le même jour, et trois autres y ont été ajoutés ; le manifeste de l'anneau à cette date énumère chaque domaine avec son anneau.

Déclarations des opérateurs. Pour chacun de 13 opérateurs de robots (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Microsoft, Mistral, OpenAI, Perplexity), les déclarations que l'opérateur publie lui-même sur ses robots, la page de documentation et les plages d'adresses IP publiées (JSON), sont récupérées chaque jour, sans plafond d'octets, puis hachées, scellées et ancrées comme tout autre artefact : 26 adresses. Nous ne vérifions pas si un accès a réellement eu lieu depuis ces plages ; seul est attesté ce que l'opérateur a déclaré au jour T. Là où une redirection existait, c'est la cible qui est consignée, afin que la provenance porte le document et non la redirection. Écartées, motif énoncé : les pages qui ne livrent rien à un client sans navigateur (la documentation des robots de Meta), parce qu'une coquille vide ne prouve rien.

Déclarations des fournisseurs. Par le même mécanisme, les politiques d'utilisation, conditions et politiques de robots publiées par 12 de ces opérateurs (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Meta, Microsoft, Mistral) : 32 adresses, chaque jour, sans plafond d'octets. Deux opérateurs, OpenAI et Perplexity, ne livrent pas ces pages à un client qui n'est pas un navigateur ; leurs conditions ne figurent donc pas dans le relevé, et nous le disons ici plutôt que de combler la lacune par d'autres moyens. Ensemble, elles forment le pendant des fichiers de réserve : ce qu'un site avait réservé au jour T, et ce que l'opérateur avait déclaré le même jour sur sa propre conduite. Rien n'est évalué : le relevé conserve le texte, non un jugement à son sujet.

2. Ce que contient une observation

Une observation est l'enregistrement d'une ressource à un instant donné. En voici une complète, pour notre domaine d'exemple, dans la forme sous laquelle l'archive la conserve.

Le contenu lui-même

GET https://beispielfirma.example/robots.txt
→ HTTP 200, 412 octets

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Les octets exacts que le serveur a délivrés, conservés sans modification et compressés. Non pas notre résumé, ni un rendu : les octets. Dans un litige, la question n'est jamais « que dit le fichier » mais « que disait-il le 14 août 2027 ».

L'empreinte

payload_sha256 = 9f2a41d7c8e05b3a…7d1e6084bb93c2f5
payload_size   = 412 octets

Une empreinte SHA-256 (hash) est un code court, de longueur fixe, calculé à partir des octets exacts d'un fichier. Changez un seul caractère et le code change entièrement, et il est impossible en pratique de fabriquer un fichier différent portant le même code. Elle fonctionne comme l'empreinte d'une version déterminée d'un document. C'est aussi le numéro de classement : le contenu est stocké sous sa propre empreinte, de sorte que rien ne peut être substitué sans que l'étiquette cesse de correspondre.

Les circonstances de la délivrance

observed_at   = 2027-08-14 03:00:11 UTC
observer_id   = witness-1
status_code   = 200
final_url     = https://www.beispielfirma.example/robots.txt   (après redirection)
http_version  = HTTP/1.1
headers       = content-type: text/plain; charset=UTF-8
                cache-control: max-age=600
                x-served-by: cache-fra-…
                (en-têtes de réponse complets, mot pour mot)
tls_version   = TLSv1.3
peer_cert     = subject:  *.beispielfirma.example
                issuer:   GlobalSign Atlas R3 DV TLS CA
                valid:    2027-06-01 → 2028-06-01
                sha256:   3b8c07f2ad91…e5240ac71f6b88
                (empreinte du certificat du serveur,
                 plus les cinq champs analysés ci-dessus)
peer_cert_chain = 3b8c07f2ad91…e5240ac71f6b88   (certificat du serveur)
                6f1d0ba47c33…9a7e1c40db2f51   (intermédiaire)
                c04e83fa1d67…2b95e7708aa361   (intermédiaire)
                (la chaîne telle que le serveur l'a délivrée, dans
                 cet ordre ; chaque certificat conservé en entier)
observer_addr = l'adresse IP depuis laquelle notre observateur s'est connecté
peer_addr     = l'adresse IP qui a répondu

C'est ce que les juristes appellent la chaîne de conservation de la preuve : non pas simplement « ce fichier existait », mais « ce serveur, présentant ce certificat TLS, a délivré ces octets à cet observateur à cet instant ». Le certificat TLS importe parce qu'il rattache la délivrance à une partie capable d'obtenir un certificat pour ce domaine. L'ensemble est scellé avec le contenu, de sorte qu'aucun élément ne peut être échangé ensuite.

Ce qui est exactement consigné ici, et ce qui ne l'est pas. Depuis le 15 septembre 2026, nous conservons la chaîne de certificats complète telle que le serveur la délivre : le certificat du serveur et les intermédiaires transmis avec lui, chacun conservé en entier, les empreintes étant consignées dans l'ordre d'arrivée. Il ne s'agit pas d'une chaîne reconstruite au regard de notre propre magasin de confiance : un témoin consigne ce qui a été délivré, et la question de savoir si cette chaîne est valide appartient à l'expert, non à nous. Nous continuons à consigner à côté l'empreinte SHA-256 du certificat du serveur ainsi que les cinq champs analysés ci-dessus.

Ce changement ne rétroagit pas. Pour les observations antérieures au 15 septembre 2026, seule l'empreinte existe, non le certificat ; lorsque ce certificat est nécessaire, il peut en général être obtenu de manière indépendante auprès des registres publics de transparence des certificats (RFC 6962), l'infrastructure d'audit sur laquelle s'appuient les navigateurs. Les enregistrements plus anciens conservent l'état qui était le leur à l'époque, et rien n'est complété après coup. Cela honore l'engagement que cette page portait depuis le 1^er août 2026.

L'indicateur de changement

changed = true   (l'empreinte diffère de l'observation précédente)

Positionné lorsque l'empreinte du jour diffère de celle de la veille pour la même ressource. C'est la raison d'être de cette archive : ces fichiers changent en silence, sans historique public, et le changement lui-même est souvent le fait contesté.

3. À quoi ressemble un fichier absent

Consigner que « rien ne s'y trouvait » est aussi une preuve, et cela se consigne avec le même soin qu'un contenu. Si notre domaine d'exemple ne sert aucun ai.txt :

GET https://beispielfirma.example/ai.txt
→ HTTP 404, aucun contenu stocké
   statut, en-têtes complets, empreinte du contenu et
   détails TLS consignés comme ci-dessus

Cette distinction pèse réellement. « Le site n'avait publié aucune réserve d'IA lisible par machine à cette date » est fréquemment le fait décisif d'un litige de fouille de textes et de données, et cela ne peut être établi que par quelqu'un qui a regardé et a noté n'avoir rien trouvé. Deux autres cas sont consignés tout aussi explicitement : un serveur qui refuse notre observateur (HTTP 403) produit l'enregistrement du refus, non d'un contenu ; et une ressource que le robots.txt du site nous demande de ne pas récupérer est consignée comme délibérément non récupérée. Nous respectons cette instruction et nous consignons que nous l'avons fait.

4. Comment l'enregistrement est scellé

Une archive tenue par une partie intéressée ne prouve pas grand-chose à elle seule : nous pourrions, en principe, réécrire notre propre base de données. Quatre étapes répondent à cette objection, chacune indépendante des autres.

Étape 1 · le jour même

Toutes les observations du jour sont liées en un seul nombre

Toutes les empreintes consignées ce jour-là sont combinées deux à deux, niveau après niveau, jusqu'à ce qu'il ne reste qu'une racine quotidienne unique, qui dépend de chacun des enregistrements situés en dessous. Modifiez ensuite une seule observation et la racine ne correspond plus. C'est la construction utilisée par les registres publics sur lesquels les navigateurs s'appuient pour auditer les certificats TLS (RFC 6962).

Étape 2 · déposée le jour même

Ce nombre est déposé hors de notre portée

La racine quotidienne est soumise le jour même à OpenTimestamps, qui l'agrège vers la chaîne de blocs Bitcoin, et séparément à une autorité d'horodatage RFC 3161 indépendante, qui renvoie immédiatement un jeton signé. Depuis le 31 juillet 2026, un horodatage électronique qualifié au sens d'eIDAS est également obtenu. Nous ne pouvons en réécrire aucun. C'est ce qui fait passer le scellement d'une affirmation interne à une preuve externe : il établit que l'enregistrement existait au plus tard ce jour-là.

État de l'ancrage Bitcoin : achevé le 7 août 2026. Les deux autorités d'horodatage renvoient leur preuve immédiatement, et ces jetons sont conservés ici. OpenTimestamps fonctionne en deux temps : la racine est soumise aussitôt, mais le reçu obtenu ne devient autonome qu'une fois la confirmation Bitcoin réintégrée dedans. Jusqu'au 7 août 2026, nous n'avions pas accompli cette seconde étape, et une version antérieure de ce passage le disait. Elle a désormais été effectuée pour chaque jour scellé, sur les deux témoins, et une tâche quotidienne s'en charge à partir de maintenant, de sorte que les reçus conservés ici renvoient à des en-têtes de blocs Bitcoin plutôt qu'à des serveurs calendaires. Cette étape a modifié les reçus, mais non ce qu'ils attestent : l'empreinte dont chaque reçu témoigne a été relevée avant et après et reste inchangée pour chaque jour. Le chemin Bitcoin ne dépend plus de la disponibilité de ces serveurs calendaires. Les ancrages RFC 3161 et eIDAS qualifié n'ont pas été affectés et valent par eux-mêmes.

Étape 3 · le jour même

La racine est publiée

Chaque racine quotidienne paraît dans notre registre public des racines, sous des adresses stables et sous une forme lisible par machine. Chacun peut en conserver sa propre copie le jour de sa parution ; plusieurs systèmes tiers la captent automatiquement.

Étape 4 · en service depuis le 2026-08-04

Un second témoin indépendant observe les mêmes cibles

Un système distinct, sur une infrastructure différente, dans un autre pays et avec une clé d'exploitant différente, relève de manière indépendante et publie sa propre racine quotidienne. Aucune des deux machines ne détient d'accès à l'autre et aucune ne peut écrire dans la base de l'autre. Deux récits tenus indépendamment sont plus difficiles à écarter qu'un témoin qui se répète.

Deux limites, énoncées franchement. D'abord, cela a commencé le 4 août 2026 : chaque journée scellée du 22 juillet au 3 août 2026 repose sur le premier témoin seul, et le registre public montre cet écart plutôt que de le masquer. Ensuite, les deux racines quotidiennes ne sont jamais identiques, par construction : chaque témoin explore selon son propre calendrier, si bien que l'ensemble des observations derrière chaque racine diffère. La comparaison se fait donc observation par observation, et non en vérifiant si deux racines coïncident ; des racines identiques indiqueraient au contraire que les deux systèmes ne sont pas indépendants.

5. Ce que contient un extrait probatoire

L'archive n'est pas consultable librement, à dessein. Ce que nous produisons sur demande, pour un domaine et une période déterminés, est un extrait probatoire : un ensemble contenant

le contenu stocké de chaque observation de la période, octet pour octet ;
l'intégralité des circonstances de délivrance scellées, telles qu'exposées à la section 2 ;
l'empreinte de chaque observation ;
une preuve d'inclusion : un court reçu mathématique établissant que cette observation précise est contenue dans la racine de ce jour-là, vérifiable sans nous faire confiance et sans accès au reste de l'archive ;
la racine quotidienne et les reçus d'horodatage externes ;
des instructions de vérification pas à pas, que tout expert technique compétent peut suivre avec des outils courants.

L'intérêt du dernier point mérite d'être dit clairement : l'extrait est conçu pour que l'expert de la partie adverse puisse le vérifier. Un enregistrement qu'une seule partie peut contrôler n'est pas une preuve.

La manière d'en demander un, les conditions de sa délivrance et son coût sont exposés sur la page extrait probatoire. Savoir si cette archive observe un domaine donné peut être vérifié au préalable, gratuitement, avec la vérification de couverture.

6. Si quelqu'un nous demande d'effacer

L'essentiel de ce que nous détenons ne contient pas de données à caractère personnel : ce sont des fichiers de politique technique publiés par des organisations. Lorsqu'une demande d'effacement légitime au titre de l'article 17 du RGPD porte effectivement sur un contenu archivé, nous procédons à ce que nous appelons un marqueur de suppression : le contenu stocké est effacé et remplacé par un marqueur. Effacé veut dire effacé, et aucune sauvegarde ne le restaure.

Ce qui subsiste, c'est l'empreinte, le scellement et les preuves. La conséquence mérite d'être comprise avec précision : ensuite, plus personne ne peut savoir ce que disait le fichier, mais il reste prouvable qu'un fichier portant exactement cette empreinte se trouvait à cette adresse à cette date, et que les enregistrements voisins de cette journée sont intacts. La conservation de l'empreinte repose sur l'article 17, paragraphe 3, point e), du RGPD, car l'effacer romprait la chaîne de preuve de toutes les autres observations scellées ce jour-là, y compris celles de tiers étrangers à la demande.

Sur demande, nous excluons également un domaine de toute observation future, avec ou sans effacement. Les deux sont gratuits et aucun n'a besoin d'être motivé. Pour une exclusion, nous vous demandons en revanche de démontrer que vous avez la maîtrise du domaine : un enregistrement DNS TXT, ou un fichier à une adresse que nous indiquons, au choix. Non parce que la demande devrait se justifier, mais parce qu'une exclusion demandée par un tiers retirerait un domaine du relevé sans que son exploitant l'apprenne jamais. Un effacement au titre de l'article 17 du RGPD ne comporte pas cette étape : nous n'y demandons une identification qu'en cas de doute réel. Voir Confidentialité et Robot & contact.

7. Ce que cet enregistrement ne prouve pas

Énoncer les limites avec précision fait partie du métier de témoin crédible.

Il établit ce qu'un serveur a délivré à notre observateur, aux instants consignés. Il ne dit rien des intervalles entre les observations, ni de ce que d'autres visiteurs ont vu.
Il établit un contenu et des circonstances de délivrance, non une paternité, une intention ou une licéité. Savoir si une réserve était effective, si un robot l'a respectée, et ce qui en découle juridiquement, sont des questions pour le conseil et pour le juge.
L'ancrage externe prouve qu'un enregistrement existait au plus tard à la date de son ancrage. Il ne prouve rien quant à une date antérieure.
Un fichier manquant prouve que la ressource était absente de cette adresse à cet instant, non que l'exploitant n'a jamais réservé ses droits par un autre moyen.
Nous relevons des déclarations publiques et lisibles par machine émanant d'organisations. Nous n'observons aucune donnée privée, aucun comportement d'utilisateur et aucune personne physique.

Nous sommes la boîte noire, pas l'enquêteur. Ce que l'enregistrement signifie, il revient à d'autres d'en débattre.

L'exemple ci-dessus est construit à titre d'illustration. Un extrait traité portant sur un domaine réel, vérifiable au regard du registre public des racines, sera ajouté lorsque ce domaine aura accumulé un historique d'observations significatif.