Le monitoring et la signalisation évoquent un tableau de bord. Il s'agit en général d'autre chose : un système qui reçoit continuellement des données, les compare à une attente ou à une valeur seuil, et émet un signal dès qu'un écart survient. Il peut s'agir d'une machine qui vibre différemment de la normale, d'un stock qui diminue plus vite que prévu, d'un réseau où passe un trafic inhabituel, ou d'un processus client dont le délai s'allonge. La composante IA réside dans la reconnaissance de schémas qu'il n'est pas possible de capter avec des règles fixes — pas dans le remplacement de la personne qui réagit au signal.
Un système de monitoring fournit trois choses : une mesure continue, une norme à laquelle cette mesure est comparée, et un signal lorsque l'écart dépasse une certaine limite. Ce qui se passe ensuite dépend de la configuration. Dans sa forme la plus simple, une notification part vers une personne, qui évalue et agit. Dans une forme plus poussée, le signal déclenche automatiquement une étape suivante — une notification à un fournisseur, un ajustement dans une planification, un blocage d'une transaction. Cette seconde forme touche au domaine des chaînes où les étapes se succèdent : le monitoring devient alors le point de départ d'un processus qui se poursuit sans intervention, ce qui exige un tout autre type de confiance qu'une notification qu'une personne peut encore écarter.
La différence entre ces deux formes n'est pas anodine. Un signal qui part vers une personne peut être erroné sans causer immédiatement de dommage — la personne filtre. Un signal qui déclenche une action doit être correct, ou l'organisation doit disposer d'un moyen d'annuler l'action. De nombreuses organisations commencent donc par la première forme et ne passent à la seconde que lorsque le signal a fait ses preuves.
Le monitoring et la signalisation exigent avant tout des données continues et fiables. Un système qui reçoit chaque semaine un export d'un autre système ne peut pas émettre de signal — il ne peut que faire un rapport après coup. Il doit y avoir un flux : des capteurs, des journaux, des transactions, des événements, qui arrivent en continu et dont la qualité ne varie pas selon qui effectue la saisie.
Cela exige par ailleurs une norme. Un écart n'est un écart que par rapport à quelque chose. Pour les machines, il s'agit souvent d'une spécification technique ; pour les processus, il s'agit plus souvent d'une moyenne historique ou d'une valeur cible fixée par quelqu'un. Là où cette norme fait défaut ou est instable — un processus en constante évolution, un marché qui fluctue — le système donne soit trop de signaux, soit trop peu. Les deux minent la confiance qu'on lui accorde.
Troisièmement, cela exige un parcours établi pour ce qu'il advient d'un signal. Qui reçoit la notification, dans quel délai celle-ci est-elle évaluée, quelle est l'escalade en l'absence de réaction. Sans ce parcours, un signal finit dans une boîte que personne ne consulte, et le système perd sa fonction. Ceci touche à la même question que celle des conversations enregistrées et suivies : enregistrer sans suivi ne produit qu'une archive, pas une amélioration.
Le défaut le plus fréquent est un système de monitoring qui émet trop de signaux. Si chaque petit écart déclenche une notification, les personnes apprennent à les ignorer — l'effet inverse de celui recherché. Le réglage de la valeur seuil est donc un arbitrage permanent entre trop de bruit et une alerte trop tardive, et cet arbitrage évolue au fur et à mesure que davantage de données arrivent.
Un deuxième défaut est que le signal se déclenche bien, mais que personne n'est responsable du suivi. Cela se produit souvent lorsque le monitoring est conçu comme un projet informatique sans que le service qui doit travailler avec les signaux soit impliqué. La technique fonctionne, l'organisation non.
Un troisième défaut apparaît lorsque le signal exige une décision qui relève en réalité du travail humain — cet écart est-il acceptable, faut-il appeler le client, ce risque justifie-t-il un arrêt. Là où cet arbitrage devient trop complexe pour une règle fixe, le monitoring glisse vers l'aide à la décision, et d'autres exigences s'appliquent en matière de justification et d'explicabilité que pour un simple signal de seuil.
La plupart des projets de monitoring qui ne décollent pas s'enlisent sur le flux de données, pas sur le modèle. Des capteurs qui tombent en panne, des journaux incohérents, des systèmes qui ne communiquent pas entre eux — ce ne sont pas des problèmes d'IA, ce sont des problèmes d'infrastructure qui doivent d'abord être résolus. La coordination joue également un rôle : un signal qui naît dans un service doit souvent aboutir dans un autre service pour avoir un sens, ce qui touche à la question de la manière dont la coordination entre services est organisée.
Cette page décrit ce que le monitoring et la signalisation peuvent apporter, et ce que l'organisation doit avoir en ordre avant que cela fonctionne. Une autre question est de savoir quelle partie du travail autour de ces signaux — l'évaluation, le suivi, l'escalade — peut effectivement être reprise par l'IA. C'est une question de niveau de tâche, et c'est le scan de travail de FTE TO AI qui y répond : il calcule, tâche par tâche, quelle part du travail peut être reprise, plutôt qu'au niveau d'un processus entier ou d'une fonction entière.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.