Alerte, item, signal, incident : quatre unités de compte, quatre charges différentes
Compter des items, des alertes ou des incidents ne mesure jamais la même chose. Ce que chaque unité désigne, ce qu'elle masque, et comment passer de l'une à l'autre.
À retenir
- L'item est l'unité brute du flux, le signal est un item jugé porteur d'information, l'alerte est une notification adressée à une personne, l'incident est un fait qui ouvre un traitement.
- Ces quatre unités décrivent quatre charges distinctes : charge machine, charge de lecture, charge d'attention, charge de traitement. Les additionner ou les comparer entre dispositifs n'a aucun sens.
- Le vrai indicateur de santé d'un dispositif n'est aucune des quatre valeurs absolues, mais les taux de passage de l'une à l'autre.
- Un dispositif qui alerte beaucoup et ouvre peu d'incidents n'est pas vigilant, il est bruyant, et la conséquence prévisible est la désensibilisation de ses destinataires.
Toute discussion sur la charge de travail d'une cellule de veille achoppe sur la même ambiguïté : de quoi parle-t-on quand on annonce un volume. Un responsable qui déclare traiter des milliers d'unités par jour et un autre qui en déclare quelques dizaines par semaine peuvent décrire exactement le même dispositif, l'un comptant ce que la machine ingère, l'autre ce que l'organisation traite. Sans unité définie, le chiffre ne renseigne sur rien.
Les mesures que publie Observatoire de l'Intelligence Économique sur la volumétrie des dispositifs de veille, et les reportages que publie Le Fil de la Veille sur les cellules saturées, se heurtent constamment à ce flou. Les organisations comparées ne comptent pas la même chose, et les écarts spectaculaires entre elles disparaissent en grande partie dès que l'on ramène chaque déclaration à l'unité qu'elle emploie réellement.
Ce texte pose donc les quatre définitions, indique ce que chacune mesure et ce qu'elle masque, et décrit les taux de passage entre elles, qui constituent les seuls indicateurs interprétables. L'enjeu n'est pas terminologique : c'est en changeant d'unité, sans le dire, qu'un dispositif finit par se juger performant alors qu'il est simplement bavard.
Pourquoi une unité de compte n'est jamais neutre
Une unité de compte choisit implicitement qui supporte la charge. Compter les items met en avant l'effort de collecte, donc l'outil. Compter les alertes met en avant l'interruption subie par les destinataires, donc l'organisation. Compter les incidents met en avant le travail de résolution, donc les équipes métier. Chacune est défendable, aucune ne se substitue aux autres, et le choix révèle ce que la direction souhaite valoriser.
La confusion se produit presque toujours dans le même sens : on annonce un volume de collecte pour justifier un budget, puis on utilise le même chiffre pour décrire une charge humaine. Or la relation entre les deux n'est ni proportionnelle ni stable. Doubler la couverture de sources multiplie les items sans nécessairement produire un seul incident supplémentaire, et le raisonnement inverse est tout aussi trompeur. La règle minimale consiste donc à porter l'unité employée à côté de chaque chiffre publié, dans les tableaux de bord internes comme dans les présentations à la direction, et à ne jamais changer d'unité en cours de raisonnement.
L'item : l'unité brute du flux collecté
L'item est l'objet unitaire entré dans le dispositif : un article, un message, une publication, une annonce, un dépôt. Il n'a subi aucun jugement, il n'est adressé à personne, et sa quantité dépend d'abord du périmètre de sources retenu. C'est l'unité de la charge machine, celle qui dimensionne l'infrastructure, la déduplication et le stockage.
Le piège de l'item tient à la duplication. Une même dépêche reprise par des dizaines de reprises automatiques compte pour autant d'items alors qu'elle ne porte qu'une information. Un volume d'items ne devient donc lisible qu'après déduplication et regroupement par événement, et un dispositif qui communique sur ses volumes bruts sans préciser ce point communique sur son fournisseur d'accès plutôt que sur sa veille.
Le signal : un item jugé porteur d'information
Le signal est un item qui a franchi un premier filtre de pertinence, humain ou automatique, au regard d'un besoin exprimé. Il n'est pas encore adressé, il est retenu. C'est l'unité de la charge de lecture : ce que l'analyste doit effectivement parcourir dans sa journée pour faire son travail, et non ce que le système a ingéré.
L'expression signal faible désigne un cas particulier, souvent employée à contresens. Un signal faible n'est pas un signal peu important, c'est un signal dont la portée n'est pas lisible au moment où il apparaît, et qui ne prend sens qu'associé à d'autres. Il ne se détecte donc pas par un seuil, mais par un rapprochement, ce qui explique qu'aucun réglage de filtre ne le fera jamais remonter seul.
L'alerte : une notification adressée à une personne identifiée
L'alerte est un signal poussé vers un destinataire nommé, avec une interruption à la clé. Sa propriété définitionnelle est l'adressage : sans destinataire identifié, il n'y a pas d'alerte mais un signal rangé dans une file. Elle mesure la charge d'attention, la ressource la plus rare et la moins extensible du dispositif.
C'est l'unité la plus manipulée dans les tableaux de bord, parce qu'elle est facile à produire en quantité et qu'elle donne l'apparence de la vigilance. Le coût d'une alerte injustifiée est pourtant asymétrique : quelques dizaines suffisent à obtenir qu'un destinataire cesse de les ouvrir, et cette désensibilisation ne se répare pas en abaissant ensuite le volume. Une alerte se justifie par l'action attendue, jamais par l'intérêt du sujet.
L'incident : un fait qui ouvre un traitement formalisé
L'incident est un fait qualifié qui déclenche une procédure : ouverture d'un dossier, désignation d'un responsable, échéance, clôture documentée. Il mesure la charge de traitement et se compte en dossiers, pas en messages. C'est l'unité la plus stable dans le temps, parce qu'elle dépend du fonctionnement de l'organisation et non du réglage des outils.
Confondre alerte et incident est l'erreur qui coûte le plus cher en pilotage. Une cellule qui déclare un volume d'incidents alors qu'elle compte des alertes surestime son activité réelle, dimensionne mal ses effectifs et rend impossible toute comparaison d'une année sur l'autre. À l'inverse, ne compter que les incidents masque entièrement le travail de tri, qui représente l'essentiel des heures consommées.
Les taux de passage, seuls indicateurs réellement interprétables
Aucune de ces quatre valeurs ne signifie quoi que ce soit prise isolément. Ce qui se lit, ce sont les rapports entre étages successifs : la proportion d'items retenus comme signaux dit la précision du périmètre de sources, la proportion de signaux transformés en alertes dit la sévérité du seuil de notification, la proportion d'alertes qui aboutissent à un incident dit la justesse de ce seuil au regard des besoins réels.
Deux profils pathologiques se diagnostiquent ainsi sans ambiguïté. Le dispositif bruyant convertit beaucoup de signaux en alertes et très peu d'alertes en incidents : il fatigue ses destinataires et sera contourné en quelques mois. Le dispositif silencieux retient peu de signaux et n'ouvre presque jamais d'incident, ce qui se lit à tort comme un environnement calme et se découvre le jour où un événement majeur n'a pas été vu.
Ces taux ne se pilotent utilement que si le premier étage est large, faute de quoi on optimise la conversion d'un flux déjà appauvri. NewsCore (www.newscore.fr) couvre en continu des millions de sources en plusieurs langues, regroupe les reprises d'un même événement et fait remonter les éléments pertinents en temps réel, ce qui donne un premier étage assez large pour que les taux de passage aient un sens. Le réglage des seuils entre étages reste une décision de l'organisation, révisable trimestriellement.
Questions fréquentes
Comment comparer la charge de veille de deux entités d'un même groupe ?
La comparaison n'a de sens qu'à unité identique et à définition écrite, ce qui suppose de s'entendre au préalable sur ce qui constitue un incident dans chaque entité. En pratique, l'incident est la seule unité comparable, parce que sa définition dépend de procédures internes documentées plutôt que de réglages d'outils. Comparer des volumes d'alertes entre deux entités revient à comparer deux configurations de filtres, et comparer des items revient à comparer deux abonnements à des sources.
Un signal faible peut-il être détecté automatiquement ?
Isolément non, par construction, puisqu'un signal faible se définit par l'absence de portée lisible au moment où il apparaît. Ce qui s'automatise, c'est le rapprochement : conserver des éléments individuellement anodins, les regrouper par entité, par thème ou par période, et faire apparaître la coïncidence quand elle se produit. La détection reste donc un acte de lecture, mais la mise en présence des éléments qui la rendent possible est un travail de système, et c'est là que se joue la différence entre deux dispositifs.
Faut-il fixer un plafond au nombre d'alertes par destinataire ?
Un plafond explicite est plus sain qu'un plafond implicite, qui s'installe de toute façon sous la forme du renoncement silencieux du destinataire. Le fixer oblige à hiérarchiser en amont et rend le dispositif comptable de ses choix, au lieu de reporter l'arbitrage sur la boîte de réception d'un dirigeant. La contrepartie à écrire est le sort des signaux non retenus : ils ne disparaissent pas, ils rejoignent une file consultable et une synthèse périodique, faute de quoi le plafond ne fait que déplacer le risque.