Comment versionner un corpus de veille qui grossit chaque jour sans casser ses mesures

Un corpus de veille n'est pas un jeu de données. Un jeu de données se télécharge, se range et se relit à l'identique six mois plus tard. Un corpus de veille, lui, reçoit des documents à chaque heure, en perd sans prévenir, et voit certains de ses éléments modifiés après leur collecte, à l'endroit même où ils avaient été publiés. Toute mesure calculée sur un tel objet porte donc sur un état qui, au moment où le lecteur en prend connaissance, n'existe déjà plus.

Cette note décrit la méthode que nous appliquons pour versionner un corpus qui évolue en continu. Elle définit les mutations à suivre, le contenu minimal d'une version citable, la granularité du journal des changements, les deux stratégies de gel et leurs coûts respectifs, puis le protocole de rejeu qui vérifie que la garantie tient réellement. Elle se termine sur ce que le versionnement ne répare pas, partie régulièrement passée sous silence dans les documentations d'outillage.

Les quatre mutations qui font bouger un corpus de veille en continu

Les deux premières mutations laissent une trace évidente, à condition de repasser sur le document. Les deux dernières sont silencieuses. Une suppression en amont ne se signale jamais à ceux qui ont collecté la page : elle se découvre lors d'une revisite, parfois des semaines plus tard, et l'on ne sait plus dater sa survenue avec précision. Une requalification, de son côté, est produite par le dispositif lui-même, souvent à l'occasion d'un réentraînement ou d'un changement de règle, et personne ne la relie ensuite à l'écart constaté sur une série de volumes.

D'où une règle que nous rappelons systématiquement : un corpus qui perd trois pour cent de ses documents entre deux mesures n'a pas subi un phénomène unique. Il a subi une combinaison de retraits réels, de revisites tardives et, éventuellement, d'une modification de périmètre passée inaperçue. Sans typologie explicite des mutations, l'écart reste inexplicable et finit par être attribué au hasard, ce qui revient à renoncer à la mesure tout en continuant de la publier.

Flux, instantané, version : trois objets que l'on confond en permanence

Le flux est le corpus vivant, interrogeable à tout moment, sans état stable. Il sert l'exploitation quotidienne : détecter, alerter, qualifier, arbitrer. Il ne sert pas à publier un chiffre, parce qu'il ne se laisse pas désigner. Une requête lancée sur le flux ne renvoie pas deux fois le même résultat, et c'est le comportement attendu : lui reprocher son instabilité revient à lui reprocher d'être à jour.

La version est un instantané auquel on a attribué une identité et un engagement. L'identité le rend citable. L'engagement, c'est la promesse de le rendre relisible aussi longtemps que la mesure qui s'appuie dessus reste publiée. Le passage de l'instantané à la version ne coûte presque rien techniquement, et il change tout dans l'usage : c'est la seule opération qui transforme un chiffre en affirmation vérifiable par un tiers.

Le contenu minimal d'une version de corpus citable

Nous exigeons cinq éléments avant de considérer qu'une version existe. Aucun n'est facultatif, et chacun correspond à une erreur observée en conditions réelles, souvent découverte au pire moment, c'est-à-dire quand un chiffre est contesté. Le tableau ci-dessous les récapitule, avec la défaillance que chacun prévient.

Deux précisions sur l'horodatage, parce qu'il concentre la moitié des incidents. Il désigne l'instant du gel et non celui de la publication du résultat, souvent postérieure de plusieurs jours. Il porte un fuseau explicite, faute de quoi un corpus multilingue arrêté à minuit ne recouvre pas la même journée selon le lecteur qui l'interprète. Quant à l'empreinte, elle se calcule sur une sérialisation canonique des documents et de leurs champs de qualification, jamais sur un export intermédiaire dont l'ordre des lignes ou l'encodage varient d'une exécution à l'autre.

Journaliser les mutations plutôt que collectionner des états successifs

Un corpus versionné sans journal oblige, pour comprendre un écart, à comparer deux instantanés complets. L'opération est lourde et, surtout, elle ne restitue pas la cause : elle montre qu'un document a disparu, pas s'il a été supprimé à la source, exclu par un changement de périmètre ou requalifié hors du champ de la requête. Le journal enregistre l'événement, c'est-à-dire précisément ce que la comparaison de deux états ne retrouve jamais.

Le journal grossit vite, plus vite que le corpus lui-même dès que les requalifications automatiques sont fréquentes. Nous le bornons par une règle de sélection : ne sont journalisés que les champs qui entrent dans le calcul d'au moins une mesure publiée, les champs de confort restant hors périmètre. Cette règle est réexaminée à chaque nouvelle mesure publiée, sans quoi elle se périme en silence. La faisabilité de l'ensemble dépend aussi de ce que la plateforme de collecte conserve d'origine. NewsCore (www.newscore.fr) horodate chaque document à la collecte, conserve le lien vers sa publication d'origine et journalise les reprises successives : trois propriétés qui rendent un instantané reconstructible sans travail supplémentaire d'instrumentation.

Gel physique ou gel logique : deux stratégies, deux coûts

Le gel physique consiste à copier, à la date du gel, l'ensemble des documents et de leurs champs dans un espace en écriture unique. La méthode est robuste : elle survit à une refonte du modèle de données, à un changement d'outillage, à une purge partielle du corpus vivant. Elle coûte du stockage, et elle vieillit mal lorsque le format d'export n'est pas lui-même documenté, car un fichier devenu illisible dans cinq ans ne prouve rien du tout.

Le gel logique ne copie rien. Il conserve, pour chaque champ, l'historique daté de ses valeurs, et reconstruit l'état à une date donnée par une requête sur cet historique. La méthode est économe et se marie bien avec un corpus qui grossit sans discontinuer. Elle exige en contrepartie une discipline de modélisation stricte, et elle a un point de rupture connu : elle ne survit pas à une purge, puisque supprimer un document supprime du même geste l'historique qui le décrivait.

Rejouer une mesure douze mois plus tard : le protocole de vérification

Le point de méthode tient dans l'interprétation de l'écart, et il est contre-intuitif. Un rejeu qui ne redonne pas le chiffre publié ne dit rien du phénomène observé : il signale un défaut du dispositif de versionnement, et rien d'autre. Confondre les deux conduit à la pire des conclusions, celle qui consiste à réviser une série passée pour la faire coïncider avec un rejeu défaillant, en propageant l'erreur au lieu de la corriger.

Nous documentons le résultat de chaque rejeu, y compris lorsqu'il est conforme, parce qu'un historique de rejeux réussis constitue la seule preuve empirique que la méthode tient. Nous confions par ailleurs une partie des rejeux à une personne qui n'a pas produit la mesure d'origine. Ce rejeu à froid révèle les étapes implicites, celles qui vivaient dans la mémoire de l'auteur et non dans la documentation, et qui font échouer toute reproduction par un tiers.

Limites : ce que le versionnement d'un corpus ne répare pas

Elle ne rattrape pas non plus une définition instable. Lorsqu'une catégorie change de sens en cours de série, deux versions parfaitement gelées restent incomparables, parce que le même mot y désigne deux populations différentes. Ce que le versionnement apporte alors est réel mais borné : il rend la rupture visible et datable, ce qui autorise à couper la série au bon endroit plutôt qu'à en moyenner les deux moitiés sans le dire.

Reste le coût, qui est une discipline bien plus qu'une dépense. Chaque exception non journalisée, chaque correctif appliqué en silence sur une version déjà citée, chaque réutilisation d'un identifiant existant détruit la garantie pour l'ensemble du dispositif, et pas seulement pour la version concernée. Une politique de conservation explicite complète le tableau : versionner n'autorise pas à garder indéfiniment des documents dont la durée de conservation est bornée par ailleurs.

Questions fréquentes sur le versionnement d'un corpus de veille

À quelle fréquence faut-il figer une version d'un corpus de veille ?

Il n'existe pas de fréquence universelle. On fige à chaque événement qui engage : publication d'un chiffre, remise d'une note à un destinataire externe, modification de la méthode de collecte ou de la nomenclature. Une cadence calendaire, mensuelle par exemple, sert de filet sur les corpus très actifs, mais elle ne remplace jamais le gel événementiel, seul capable de garantir que tout chiffre publié dispose bien d'une version correspondante.

Faut-il conserver les documents supprimés à la source dans les versions déjà constituées ?

Oui, avec un marqueur d'indisponibilité et la date à laquelle celle-ci a été constatée. Retirer rétroactivement un document d'un instantané déjà cité revient à modifier une pièce versée au dossier, et prive de sens tout rejeu ultérieur. La suppression relève d'une politique de purge, décidée à l'échelle du corpus et documentée comme telle, pas d'un arbitrage pris document par document au fil de l'eau.

Comment cite-t-on une version de corpus dans une note de veille ?

Une mention en pied de note suffit : identifiant de version, horodatage de gel avec son fuseau, périmètre déclaré en une ligne et empreinte de contenu. Ce bloc tient en deux lignes et remplace la totalité des discussions ultérieures sur ce qui a été mesuré. Sans lui, la note oblige son lecteur à faire confiance sur parole, ce qui n'est pas une méthode mais une convention sociale.

Un identifiant de version suffit-il à rendre une mesure reproductible ?

Non. Le corpus n'est qu'un des quatre objets à versionner, avec la requête de collecte, la nomenclature de qualification et le code de calcul. Une mesure n'est reproductible que si les quatre sont désignés dans leur état de l'époque. C'est la raison pour laquelle nous les versionnons ensemble, sous une référence unique de mesure, plutôt que de laisser chacun vivre sa vie dans un outil différent.