Faites tourner un entrepôt de 50 AMR et votre RCS peut facilement cracher des milliers d'alertes par jour. C'est comme installer 20 applis sur votre téléphone, chacune poussant 10 notifications par heure — en une semaine, l'opérateur de la salle de contrôle apprend à toutes les balayer par réflexe. Et c'est là qu'une vraie panne se noie dans le bruit, invisible à tous.
C'est la fatigue des alertes. Les hôpitaux l'ont comprise il y a dix ans. L'automatisation des entrepôts est la prochaine.
Pourquoi les alertes RCS explosent
Le RCS est l'agent de circulation et le dispatcheur de la flotte — itinéraires, tâches, charge. Voyez-le ainsi : chaque AMR embarque des dizaines de capteurs — LiDAR, pare-chocs de sécurité, encodeurs, le BMS de la batterie, radios WiFi — chacun avec son propre seuil, chacun remontant des événements. Cinquante robots fois des dizaines de capteurs fois 24 heures : voilà votre matière première.
L'inondation vient généralement de trois endroits.
Premièrement, la couche robot. Les événements que l'AMR lui-même génère : fluctuations de température de batterie, ralentissements ponctuels pour obstacle, relocalisation, itinérance WiFi. Fort volume, et l'immense majorité s'auto-répare.
Deuxièmement, la couche flotte. Les événements que le RCS génère : délais de tâches dépassés, impasses de trajectoire, congestion de zones, attentes en file de charge. Faible volume, mais chacun touche directement le débit.
Troisièmement — et je le dis sans détour — l'instinct de couverture de l'intégrateur. Beaucoup de projets sont livrés avec des règles d'alerte configurées pour la responsabilité plutôt que pour l'exploitation : « alerte quand le signal WiFi passe sous -70 dBm ». Cette alerte ne sert à rien sauf à entraîner les opérateurs à devenir insensibles. Je n'ai aucune patience pour les pseudo-exigences : plus d'alertes n'est pas plus de diligence. Mille alertes que personne ne lit, c'est pareil que zéro.
Triage : les alarmes AMR ont trois niveaux. Au-delà, c'est du théâtre
Trois niveaux : P0, P1, P2. Une ligne dure les sépare : si personne ne regarde cette alerte, la ligne s'arrête-t-elle dans les 30 minutes ? Oui, c'est P0. Non, mais le débit en prend un coup, c'est P1. Ni l'un ni l'autre, c'est P2, directement dans le journal. Grossier, mais ça marche.
| Niveau | Alarmes typiques | Distribution | Réponse |
|---|---|---|---|
| P0 — vie ou mort | Arrêt d'urgence enfoncé, pare-chocs de sécurité heurté, LiDAR obstrué, robot hors ligne, surchauffe de batterie, impasse dans l'allée principale | Sirène plus SMS/appel | Quelqu'un répond en quelques minutes |
| P1 — débit en danger | Retour en charge raté, un échec de navigation (auto-réparé), file de chargeurs, ralentissement par congestion de zone | Liste de la salle de contrôle plus synthèse de poste, pas de popups | Traiter dans le poste |
| P2 — journal seul | Itinérance WiFi, réductions de vitesse, gigue de battement de cœur, ralentissements ponctuels pour obstacle, événements auto-réparés | Journal seul | À exhumer lors du dépannage |
Deux histoires du terrain.
Fin 2024, avant le pic du Singles' Day, un entrepôt e-commerce de l'est de la Chine faisait tourner 60 AMR avec la politique d'alertes du RCS en réglages d'usine : tout activé, plus de 4,000 alertes par jour. L'opérateur m'a raconté ensuite qu'il avait appris à « regarder le popup du coin de l'œil et le fermer ». Puis le BMS d'un robot a signalé une surchauffe de batterie — un vrai P0 — enterré sous des milliers d'entrées « itinérance WiFi » et « ralentissement pour obstacle ». Plus de quarante minutes plus tard, une ronde a trouvé le robot mort dans l'allée principale, une demi-ligne de picking à terre. L'autopsie a tenu en une phrase : ce n'est pas qu'il n'y avait pas d'alertes ; il y en avait tellement que c'était pareil que rien.
Le contre-exemple est au sud : un entrepôt 3C de 40 AMR a passé son premier mois à envoyer des popups pour « relocalisation réussie » — des événements auto-réparés. Sept cents de ses 800 alertes quotidiennes étaient de bonnes nouvelles. Nouvelle règle : l'auto-réparé va au journal ; seule la récupération ratée escalade. Les popups sont tombés de 800 à environ 60 par jour, et l'opérateur s'est remis à regarder l'écran. Le problème n'a jamais été « pas assez d'alertes ».
Couper n'est pas supprimer : trois pièges du réglage des alertes
Les niveaux sont fixés. Vient maintenant le travail manuel de coupure des règles et de réglage des seuils — et trois pièges dont j'ai vu chacun avaler au moins un projet.
Piège 1 : couper et oublier. Couper est une décision de risque. Il faut un registre de changements : qui l'a approuvé, pourquoi, et quand ça expire. C'est comme retirer la pile d'un détecteur de fumée sans prévenir la gestion de l'immeuble — quand il y a un incendie, la première question est « qui a retiré la pile ». Ma règle : chaque coupure va dans un registre avec un approbateur et une date de révision ; les coupures expirées se restaurent automatiquement, forçant une réévaluation.
Piège 2 : copier les seuils de l'entrepôt d'un autre. Planéité du sol, couverture WiFi, densité de rayonnages — aucun site ne ressemble à un autre. « Alerter quand les ralentissements pour obstacle dépassent 10 par minute » peut être parfait sur le site A et une machine à fausses alertes sur le site B. La bonne séquence : faites tourner les deux premières semaines avec tout en journalisation mais rien en notification, puis fixez les seuils à partir de vos propres données. Observer d'abord, légiférer ensuite — pas l'inverse.
Piège 3 : déduplication trop agressive. Certaines équipes fusionnent « échec de navigation » et « délai de tâche dépassé » en une seule « anomalie AMR » pour réduire le compte, puis pleurent au dépannage. Ne dédupliquez que les répétitions de la même cause, sur le même robot, à quelques minutes d'intervalle. Ne fusionnez jamais des causes différentes — on déduplique le bruit, pas l'information.
Avant de couper la moindre alerte, faites-la passer par cette matrice de décision :
| Conséquence mineure | Conséquence grave | |
|---|---|---|
| Fréquent | Couper, journal seul | C'est un défaut de conception — réparez le système, pas les alertes |
| Rare | Journal P2 | La garder, envoi P0 |
La case en haut à droite mérite un mot : une alerte à la fois fréquente et grave signifie que votre système lui-même est malade. Régler les alertes là, c'est donner des antidouleurs à un patient critique.
Et une idée contre-intuitive pour clore la partie technique : les gens supposent que « plus on coupe, plus le système est dangereux ». C'est l'inverse. Couper n'est pas dangereux ; ce qui est dangereux, c'est couper des choses dont personne ne sait qu'elles sont coupées. Un système avec tout en P0 et un système sans alertes meurent exactement de la même façon — personne ne regarde.
Alors, l'argent en valait-il la peine ? Un chiffre vous le dit : le temps moyen entre le déclenchement d'une alerte P0 et le moment où un humain commence à la traiter. Faites-le passer de 40 minutes à 5, et votre effort de gouvernance des alertes s'est autofinancé. S'il ne bouge pas, tout ce qui précède — le triage, la coupure, la déduplication — c'était du théâtre.
Par Da Liu, Ingénieur en automatisation
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
