Trois façons d'identifier un document de veille, une seule qui survit à sa republication

Pourquoi un document a besoin d'une clé

Un dispositif de veille qui collecte des documents dans la durée a besoin de pouvoir dire, à n'importe quel moment, si un document déjà vu est le même document ou un document différent, et de pouvoir retrouver un document précis référencé dans une analyse antérieure alors même que sa forme a pu changer entre temps. Cette capacité repose entièrement sur l'existence d'un identifiant attribué au document, une clé qui doit rester stable indépendamment des transformations que le document subit après sa première collecte.

Le choix de cette clé est rarement discuté explicitement dans les dispositifs de veille, alors qu'il conditionne directement la fiabilité de tout ce qui en dépend : historique d'un dossier, traçabilité d'une analyse, alimentation d'un tableau de bord. Trois stratégies distinctes sont couramment utilisées, avec des propriétés très différentes face aux trois transformations les plus fréquentes qu'un document subit dans le temps, un changement d'adresse, une modification mineure de contenu, et un changement d'outil de collecte.

L'adresse normalisée comme identifiant

La première stratégie consiste à utiliser l'adresse du document, normalisée selon des règles fixes, comme identifiant. Cette approche a l'avantage de la simplicité et de la lisibilité immédiate : l'identifiant est directement compréhensible et vérifiable par un humain. Elle échoue cependant dès que l'adresse change, ce qui survient fréquemment : republication sur un nouveau chemin, migration d'une plateforme éditoriale, changement de nom de domaine, ou simple ajout d'un paramètre de suivi qui modifie l'adresse sans modifier le contenu.

Dans tous ces cas, un document identique au précédent reçoit une nouvelle identité aux yeux du dispositif de veille, ce qui casse la continuité de l'historique et peut faire réapparaître comme nouveau un document déjà traité, avec les doublons d'analyse que cela entraîne. L'adresse normalisée reste utile comme métadonnée de localisation, mais elle est fragile comme identifiant de référence dès que l'horizon de suivi dépasse quelques semaines.

L'empreinte de contenu comme identifiant

La deuxième stratégie consiste à calculer une empreinte à partir du contenu du document, une valeur dérivée du texte qui reste identique tant que le contenu ne change pas, quelle que soit l'adresse à laquelle le document se trouve. Cette approche résiste bien au changement d'adresse : un document republié à l'identique ailleurs conserve la même empreinte et donc la même identité.

Elle échoue en revanche dès que le contenu est modifié, même légèrement : une correction typographique, un ajout de paragraphe, un changement de mise en forme lors d'une republication suffisent à modifier l'empreinte et donc à faire apparaître le document comme nouveau, alors qu'il s'agit d'une version révisée du même document. Cette sensibilité excessive à la modification mineure est le principal défaut de l'empreinte de contenu utilisée seule comme identifiant : elle confond stabilité d'identité et stabilité de contenu, deux notions que la vie réelle d'un document dissocie fréquemment.

L'identifiant interne attribué à l'ingestion

La troisième stratégie consiste à attribuer, au moment où le document entre pour la première fois dans le dispositif de veille, un identifiant interne propre au système de collecte, indépendant de l'adresse et du contenu, et à ne plus jamais le recalculer par la suite. Cet identifiant devient la clé de référence du document pour toute la durée de son cycle de vie dans le dispositif, quelles que soient les transformations ultérieures de son adresse ou de son contenu.

Cette approche a un coût : elle exige de conserver, en plus de l'identifiant lui-même, une table de correspondance qui relie cet identifiant aux versions successives de l'adresse et du contenu observées au fil du temps, faute de quoi l'identifiant stable ne sert à rien de plus qu'un numéro arbitraire. Ce coût est cependant le prix nécessaire d'une propriété qu'aucune des deux autres stratégies n'offre seule : la stabilité face aux trois transformations à la fois, changement d'adresse, modification mineure de contenu, et migration d'un outil de collecte vers un autre, tant que la table de correspondance est portée avec le document lors de la migration.

Ce que chaque stratégie tient, ce qu'elle ne tient pas

Le tableau suivant résume, pour chacune des trois stratégies, sa tenue face aux trois circonstances de changement les plus fréquentes rencontrées par un document de veille.

Cette comparaison montre qu'aucune des deux premières stratégies ne tient seule dans la durée : l'adresse normalisée et l'empreinte de contenu couvrent chacune une partie des circonstances de changement, mais aucune ne couvre les trois à la fois. Seul l'identifiant interne attribué à l'ingestion, associé à sa table de correspondance, offre une stabilité complète, ce qui en fait la clé de référence à privilégier chaque fois que la durée de suivi d'un document dépasse le très court terme.

Une clé, pas une décision de dédoublonnage

Il est important de ne pas confondre l'identifiant stable, objet de cette note, avec la décision de dédoublonnage, qui consiste à déterminer si deux documents distincts, chacun porteur de sa propre clé, constituent en réalité une seule et même information rapportée deux fois. L'identifiant stable pose la question de la continuité d'un même document dans le temps et à travers ses transformations. Le dédoublonnage pose la question distincte de l'équivalence entre deux documents par ailleurs correctement identifiés chacun de son côté.

Ces deux questions sont complémentaires plutôt que substituables : un identifiant stable et bien tenu rend la décision de dédoublonnage consignable et rejouable, puisqu'elle peut s'appliquer sur des clés fixes plutôt que sur des adresses ou des contenus changeants, mais il ne remplace pas cette décision. Un dispositif de veille a besoin des deux, posées dans cet ordre, l'identifiant d'abord, le dédoublonnage ensuite, et non l'inverse.

Mettre en œuvre l'identifiant interne dans la durée

La mise en œuvre pratique d'un identifiant interne attribué à l'ingestion suppose de décider, dès la conception du dispositif de collecte, du moment précis où cet identifiant est créé et de la règle qui garantit qu'il n'est jamais recréé par erreur pour un document déjà connu. Cette garantie repose elle-même sur une vérification préalable, au moment de la collecte, qui compare le document entrant aux documents déjà identifiés avant de décider s'il faut lui attribuer un nouvel identifiant ou rattacher la nouvelle occurrence à un identifiant existant. Cette vérification préalable est distincte de la décision de dédoublonnage évoquée plus haut, elle porte sur la question plus étroite de savoir si le document entrant est une simple republication déjà repérée, avant même d'entrer dans une analyse plus fine d'équivalence de contenu.

La table de correspondance qui relie l'identifiant interne aux versions successives d'adresse et de contenu mérite d'être traitée comme un actif à part entière du dispositif de veille, sauvegardé et migré avec la même rigueur que les documents eux-mêmes. Un changement d'outil de collecte qui ne prend pas soin de transférer cette table produit, en apparence, une migration réussie, alors qu'elle a en réalité rompu silencieusement la continuité de l'historique pour l'ensemble des documents déjà suivis, un défaut qui ne se révèle souvent qu'au moment où quelqu'un cherche à retrouver un document ancien à partir de son identifiant.

NewsCore, sur www.newscore.fr, attribue à chaque document un identifiant interne conservé à travers ses republications et ses changements de forme, ce qui rend l'historique d'un dossier de veille consultable dans la durée.

Questions fréquentes

Peut on combiner les trois stratégies plutôt que choisir une seule clé ? Oui, et c'est même une pratique courante : l'identifiant interne sert de clé de référence, tandis que l'adresse normalisée et l'empreinte de contenu sont conservées comme métadonnées associées, utiles pour retrouver un document ou détecter une modification, sans jamais servir elles-mêmes de clé principale.

Que se passe t il si la table de correspondance de l'identifiant interne est perdue lors d'une migration d'outil ? L'identifiant perd alors sa fonction : il devient un numéro arbitraire déconnecté des versions successives du document, et la continuité de l'historique est rompue de la même façon que si l'adresse avait été utilisée seule. La table de correspondance doit être traitée comme une donnée aussi critique que l'identifiant lui-même.

Un document légèrement modifié doit il recevoir un nouvel identifiant interne ou conserver le même ? Il doit conserver le même identifiant interne, précisément parce que cette stabilité face à la modification mineure du contenu est la propriété recherchée. La modification elle-même peut être consignée comme une nouvelle version rattachée au même identifiant, plutôt que comme un nouveau document.

Cette note remplace t elle la méthode de dédoublonnage déjà publiée ? Non, elle la précède et la complète. Le dédoublonnage décide si deux documents identifiés sont le même. Cette note pose la clé qui rend chaque document identifiable de façon stable avant même de poser cette question d'équivalence.