Faire circuler un signal de veille sans perdre sa source ni sa date

Un dispositif de veille repose rarement sur un seul outil : une source alimente un premier système de collecte, dont les résultats sont ensuite repris dans un second outil pour l'analyse ou le partage avec une équipe. À chaque passage d'un outil à l'autre, un signal de veille traverse une frontière technique où plusieurs éléments qui semblaient acquis peuvent se perdre sans que cela saute immédiatement aux yeux : son identifiant d'origine, sa date exacte de première apparition, les pièces jointes qui l'accompagnaient, ou son statut de traitement au sein de l'équipe qui le suit.

L'identifiant qui disparaît en cours de route

Le premier élément qui se perd souvent est l'identifiant d'origine du signal, celui qui permettait de le retrouver dans le système où il a été collecté initialement. Quand un second outil réimporte ce signal, il lui attribue fréquemment son propre identifiant interne, sans conserver de référence vers l'identifiant d'origine, ce qui rend impossible, plus tard, de revenir à la source exacte pour vérifier un détail ou retrouver le contexte complet dans lequel le signal était apparu la première fois.

Cette perte semble anodine tant que tout va bien, mais elle devient un problème concret dès qu'une question se pose sur la fiabilité d'un signal repris dans une analyse : sans l'identifiant d'origine, remonter jusqu'à la source demande une recherche manuelle fastidieuse, parfois infructueuse, alors qu'un identifiant conservé d'un bout à l'autre de la chaîne aurait permis d'y accéder en un instant. Conserver cet identifiant, même sous forme d'un simple champ de référence ajouté lors de chaque transfert, coûte peu et évite cette impasse.

L'horodatage, la perte la plus coûteuse

L'horodatage d'un signal, c'est-à-dire la date et l'heure auxquelles il est réellement apparu, subit un risque particulier : de nombreux outils, lors d'une importation, attribuent au signal la date de son importation plutôt que de conserver sa date d'origine. Cette substitution, souvent silencieuse, fausse la chronologie complète d'un dossier suivi dans la durée, car un signal apparu plusieurs jours avant son importation dans le second outil se retrouve daté comme s'il venait d'apparaître, ce qui peut inverser l'ordre réel des événements dans une reconstitution ultérieure.

Cette perte pèse plus lourd qu'il n'y paraît sur l'analyse : une équipe qui reconstitue la chronologie d'un dossier à partir de dates d'importation plutôt que de dates d'origine peut tirer des conclusions erronées sur l'enchaînement des événements, en particulier quand plusieurs signaux liés entre eux ont été importés dans un ordre différent de celui de leur apparition réelle. Vérifier systématiquement que la date conservée par le second outil correspond à la date d'origine, et non à la date de transfert, devrait faire partie de toute procédure d'intégration entre deux outils de veille.

Les pièces jointes qui restent en chemin

Les pièces jointes associées à un signal, une capture, un document source, une image, subissent un risque différent mais tout aussi fréquent : certains transferts entre outils ne transportent que le texte du signal, en laissant de côté les fichiers associés, soit parce que le format d'échange utilisé ne prévoit pas ce cas, soit parce que la taille des pièces jointes dépasse une limite technique du second outil. Le signal arrive alors incomplet, sans que son destinataire sache toujours qu'il lui manque quelque chose.

Ce type de perte est particulièrement insidieux car il ne se manifeste pas par une erreur visible : le signal apparaît normalement dans le second outil, avec son texte intact, et rien n'indique explicitement qu'une pièce jointe a été laissée de côté en chemin. Une convention simple, consistant à indiquer dans le signal lui-même le nombre de pièces jointes attendues à l'origine, permet à son destinataire de repérer immédiatement un transfert incomplet, plutôt que de découvrir l'absence d'une pièce jointe au moment où elle devient nécessaire à l'analyse.

Le statut de traitement, source de versions contradictoires

Le statut de traitement d'un signal, qu'il soit nouveau, en cours d'analyse ou déjà traité, constitue une information de gestion qui voyage moins naturellement que le contenu même du signal lors d'un transfert entre outils. Quand ce statut ne suit pas le signal, les deux outils finissent par en afficher chacun une version différente : le premier outil peut continuer d'indiquer un signal comme non traité alors que le second, où l'analyse a réellement eu lieu, le marque comme clos, sans qu'aucun des deux systèmes ne reflète la réalité complète de son parcours.

Cette divergence de statut crée un risque concret de double traitement : un membre de l'équipe qui consulte le premier outil peut reprendre un signal déjà traité ailleurs, en pensant qu'il reste à analyser, ce qui gaspille du temps et peut produire une analyse redondante voire contradictoire avec celle déjà réalisée. Faire circuler le statut avec le signal, à chaque transfert, plutôt que de le laisser propre à chaque outil pris isolément, élimine cette source d'erreur récurrente.

Qui doit porter la convention entre deux équipes

Quand deux outils de veille appartiennent à deux équipes différentes, la question des conventions à adopter dépasse le seul choix technique : elle demande un accord explicite entre les deux parties sur ce que chaque champ transporté doit signifier, plutôt qu'une interprétation laissée à l'appréciation de chaque outil pris séparément. Une équipe qui décide seule d'une convention, sans la faire valider par l'équipe destinataire du signal, s'expose à ce que celle ci interprète différemment un champ censé porter la même information des deux côtés.

Cet accord se documente idéalement dans un court texte de référence, accessible aux deux équipes, qui précise le format exact attendu pour chaque élément transporté : la forme de l'identifiant, le format de la date, la façon de signaler le nombre de pièces jointes, les valeurs possibles du statut de traitement. Sans ce texte de référence partagé, chaque évolution d'un des deux outils risque de rompre silencieusement une convention qui n'était connue que d'une personne, partie depuis ou ayant simplement oublié le détail exact de l'accord initial.

Des conventions simples plutôt qu'un système complexe

Face à ces quatre types de pertes, la tentation existe de construire un système d'échange sophistiqué, capable de tout transporter automatiquement sans intervention humaine. Cette ambition dépasse souvent ce dont une équipe de veille a réellement besoin : des conventions simples, appliquées avec constance, suffisent à éviter l'essentiel des pertes décrites plus haut, sans exiger l'investissement technique d'un système d'intégration complet entre les outils utilisés.

Ces conventions tiennent en quelques principes : conserver systématiquement l'identifiant d'origine dans un champ dédié, préserver la date d'origine plutôt que la date de transfert, indiquer le nombre de pièces jointes attendues pour permettre de détecter un transfert incomplet, et faire voyager le statut de traitement avec le signal plutôt que de le laisser propre à chaque outil. Une équipe qui adopte ces quatre principes, même sans outillage sophistiqué pour les appliquer automatiquement, réduit très largement le risque de perte d'information à chaque point de passage entre ses outils de veille.

L'Observatoire de l'Intelligence Économique a constaté, en examinant des dossiers de veille reconstitués après coup, que la majorité des incohérences relevées provenaient non d'une erreur d'analyse mais d'une perte d'information silencieuse survenue lors d'un transfert entre deux outils, bien en amont de l'étape où l'incohérence avait fini par se remarquer.

NewsCore (www.newscore.fr) relie les signaux collectés à travers les sources suivies et conserve leur origine et leur horodatage tout au long de leur parcours, ce qui évite à une équipe de veille de reconstituer manuellement ces informations à chaque fois qu'un signal passe d'une étape à l'autre de son traitement.

Questions fréquentes

Pourquoi la date d'un signal change-t-elle parfois entre deux outils de veille ? Beaucoup d'outils attribuent par défaut la date d'importation à un signal transféré, plutôt que de conserver sa date d'origine, ce qui fausse la chronologie si cette substitution n'est pas corrigée explicitement lors du transfert.

Comment détecter qu'une pièce jointe s'est perdue lors d'un transfert entre outils ? Indiquer, dans le signal lui-même, le nombre de pièces jointes attendues à l'origine permet à son destinataire de repérer immédiatement un écart avec ce qui est effectivement arrivé dans le second outil.

Faut-il un système d'intégration complexe pour éviter ces pertes d'information ? Non, des conventions simples appliquées avec constance, portant sur l'identifiant, la date, le nombre de pièces jointes et le statut de traitement, suffisent à éviter l'essentiel des pertes sans nécessiter un système d'échange sophistiqué.

Que risque une équipe qui ne fait pas voyager le statut de traitement d'un signal entre ses outils ? Elle risque un double traitement, un même signal étant repris comme non traité par une personne alors qu'il a déjà été analysé ailleurs, ce qui gaspille du temps et peut produire des analyses redondantes ou contradictoires.