Eiger Vault pour les éditeurs: vue d'ensemble

Page destinée à la rédaction en chef et à la direction.

Eiger Vault reçoit les contenus des éditeurs de presse, les conserve et les scelle, puis répond aux questions d'agents d'intelligence artificielle par des réponses ancrées: chaque phrase s'appuie sur des articles identifiés, et chaque appui est attribué, puis payé, à l'éditeur dont il vient. Cette page explique comment un article arrive chez nous, ce que nous en gardons, et ce que nous en faisons ou n'en faisons jamais. Les trois pages suivantes entrent dans le détail technique.

1. Comment un article arrive chez nous

Il y a deux voies, qui peuvent coexister.

La poussée. Le système éditorial (CMS) de l'éditeur envoie lui-même l'article à Eiger Vault, chaque fois que l'article est publié ou qu'une modification visible est apportée. L'éditeur choisit qui écrit le code qui pousse: un petit module (un plugin) que nous écrivons et que l'éditeur installe dans son CMS, ou du code que l'éditeur écrit lui-même, à partir de notre contrat de dépôt. Dans les deux cas, l'éditeur n'obtient son accusé de réception qu'une fois l'article durablement enregistré chez nous.

La relève. C'est Eiger Vault qui va lire l'article à la source que l'éditeur choisit: son site web, où un flux annonce les nouveaux articles et où chacun est lu à sa propre adresse, ou l'API de son CMS, qui rend des données déjà structurées. L'éditeur n'a rien à installer. Nous ne lisons que ce que l'éditeur a admis, nous respectons son fichier robots.txt et nous nous annonçons par un nom et une adresse de contact.

La poussée et la relève ne sont pas équivalentes pour la confiance qu'on peut leur accorder. Ce que l'éditeur pousse avec sa clé est attesté par sa clé; ce que nous relevons est attesté par le serveur de l'éditeur, dont nous conservons la preuve de connexion (voir plus bas).

Quelle que soit la voie, un article, ses images, la page en PDF si l'éditeur l'envoie, forment un seul document à plusieurs pièces. Le texte structuré de l'article (titre, chapeau, intertitres, paragraphes, encadrés, légendes) est la pièce que nous lisons; les autres pièces sont conservées telles quelles.

2. La clé qui identifie chaque dépôt

Chaque dépôt est accompagné d'une clé. C'est elle, et elle seule, qui dit qui dépose: ce que le dépôt affirme de lui-même ne compte pas.

• La clé éditeur est détenue par l'éditeur. Nous la lui remettons une seule fois, au moment de l'émission, et nous ne gardons ensuite que son empreinte et un court préfixe visible. Un dépôt fait avec cette clé est dit authentifié.
• La clé de connecteur est détenue par Eiger Vault, pour le connecteur qui lit votre site. Un dépôt fait avec elle est dit attesté, et n'est accepté qu'avec la preuve de la lecture (voir plus bas).
• Une clé d'import sert une seule fois, pour déposer une archive que l'éditeur nous a remise et qu'un opérateur d'Eiger Vault a confirmée. Un tel dépôt est dit remis.

Une clé est liée à un seul déposant, et à ses sources: elle ne permet de déposer que pour les sources qu'Eiger Vault lui a autorisées. Une clé peut être révoquée à tout instant; un dépôt commencé avant la révocation va jusqu'au bout, et tout dépôt suivant est refusé. La clé ne se met jamais dans une adresse: elle ne voyage que dans un en-tête de la requête.

Une source est l'entité à qui un contenu est attribué: elle peut réunir plusieurs sites web d'un même éditeur. Chaque source peut avoir plusieurs collections, qui portent le régime (éditeur rémunéré, source au fonds, source franche) et les droits par défaut.

3. Le scellement, les versions, le retrait

Le sceau. À chaque dépôt, nous calculons l'empreinte du contenu, chacune par deux algorithmes indépendants (SHA-256 et SHA3-512), et nous posons un sceau qui dit trois choses: quoi (l'empreinte du contenu déclaré), qui (le déposant et le niveau d'identité décrit plus haut), quand (l'instant de réception, lu sur l'horloge de notre base de données). Le sceau est rendu à l'éditeur dans la réponse au dépôt. Une version, son sceau et son inscription au registre naissent ensemble, dans une seule transaction: il n'existe ni version sans sceau, ni sceau sans inscription.

Les versions. Un document est identifié par le couple (source, référence à la source), la référence étant l'identifiant que le CMS donne à l'article. Chaque version d'un document est immuable et numérotée 1, 2, 3… Une nouvelle version n'est créée que si ce que le lecteur voit a changé: texte, titre, chapeau, auteurs, catégorie, dates affichées, images et légendes, adresse canonique. Envoyer deux fois le même contenu ne crée rien: la réponse rend le sceau de la version existante et le dit. Les versions précédentes restent conservées pour l'audit; la plus récente qui n'est pas retirée sert les réponses.

Le retrait. Eiger Vault peut retirer un contenu du service à deux degrés. L'interdiction masque le contenu à tous les lecteurs sans rien détruire, et se lève; l'effacement détruit les clés de chiffrement du contenu et son descriptif, et ne se défait pas. Dans les deux cas, restent les identifiants, les empreintes et le sceau, pour que la preuve du dépôt demeure. Ces décisions sont prises par des opérateurs d'Eiger Vault, jamais par un dépôt: un éditeur qui veut retirer un article nous en fait la demande, il ne l'obtient pas en le supprimant dans son CMS. Cette procédure sera détaillée avant la mise en service.

4. La reprise après une coupure

Un dépôt est idempotent: le renvoyer est inoffensif. Si l'éditeur n'a pas reçu l'accusé, il renvoie la même requête, et il reçoit le sceau du premier dépôt, sans qu'une version supplémentaire soit créée. Il n'y a pas de file d'attente chez nous: nous n'accusons réception que de ce que nous avons durablement enregistré, dans au moins deux zones de notre site d'hébergement.

Deux filets rattrapent ce qu'une panne aurait fait manquer. Le premier est un redépôt périodique de ce que l'éditeur a publié récemment (au départ, les 48 heures écoulées, toutes les heures), en s'appuyant sur une vérification groupée: le connecteur demande à Eiger Vault quelles références il connaît déjà, et n'envoie que celles qui manquent. Le second est notre surveillance des volumes reçus par source. Un article n'est jamais perdu en silence, mais un article jamais reçu est la seule perte qu'on ne rattrape pas, c'est pourquoi le redépôt est obligatoire pour tout connecteur dont le CMS peut lister ses contenus récents.

5. Ce que nous faisons du contenu, et ce que nous n'en faisons jamais

Ce que nous en faisons.

• Nous le conservons et le scellons: les pièces sont conservées octet pour octet, chiffrées, chacune avec sa propre clé.
• Nous le rendons cherchable: le texte de l'article est mis en index pour retrouver les passages qui répondent à une question.
• Nous le citons avec attribution: une réponse ancrée appuie chacune de ses phrases sur des articles identifiés, avec leurs références, et rend à chaque éditeur ce qui lui revient.
• Nous le payons: chaque appui est attribué à l'éditeur dont il vient, et rémunéré selon les prix et les droits que l'éditeur a posés. Un éditeur voit chaque appui pour lequel il est payé: quel article, quelle version, quels passages, à quelle heure. Il ne voit jamais qui a posé la question.

Ce que nous n'en faisons jamais.

• Nous n'entraînons pas de modèle génératif sur le contenu des éditeurs.
• Nous ne servons aucune pièce – photo, vidéo, PDF – par défaut: la servir est une décision prise au vu des droits de cette pièce.
• Nous n'envoyons pas le texte intégral d'un article à qui n'a pas la licence de le lire: les droits (embargo, fenêtre qui suit la publication, licences individuelle et d'organisation, prix) sont posés par l'éditeur, et seuls les prix que l'éditeur a fixés sont appliqués.
• Nous ne lisons pas un site dont l'éditeur nous a dit non, ni ce que son robots.txt nous interdit.
• Nous ne mettons dans une trace technique ni le texte d'un article, ni sa référence, ni son titre.

6. Où lire la suite

• Pour une lecture par Eiger Vault (relève): voir la page technique La relève: ce qu'Eiger Vault lit chez l'éditeur.
• Pour un éditeur qui écrit son propre plugin (poussée): voir la page technique La poussée: le contrat de dépôt, version 1, avec le contrat de dépôt, ses exemples et ses codes d'erreur.
• Pour savoir ce que le plugin transmet, quand, et ce qu'il ne lit jamais: voir la page simplifiée Qu'est-ce qui est transmis?.