Pensez à la planification des tâches RCS comme au bureau de triage des urgences d'un hôpital. Les patients (tâches) ne cessent d'arriver ; l'infirmière de triage (le planificateur) décide selon la gravité (priorité) qui entre le premier dans la salle de traumatologie (un robot). La voie d'urgence existe pour les vraies urgences, mais si chaque famille crie « la nôtre est urgente », le triage s'effondre. La configuration des priorités de tâches RCS fait exactement ce travail : elle décide qui embarque le premier et qui attend.
Comment ça marche : files d'attente, pondérations et cycle de répartition
Le RCS est le cerveau de la flotte de robots. Toutes les 100 ms à environ une seconde, il exécute un cycle de répartition : noter chaque tâche en attente, les trier et affecter les mieux notées aux robots libres. La note d'une tâche ressemble à peu près à ceci :
task score = priority weight × f(wait time, distance, battery, task type)
La préemption des commandes urgentes signifie littéralement s'emparer. Notez bien de quoi l'on s'empare : non pas d'une place dans la file, mais de capacité. Le temps de robot est fixe : chaque minute prise par une commande urgente est une minute d'attente pour une tâche normale.
On peut y voir un péage d'autoroute : la voie ETC (haute priorité) avance la première tandis que la voie de paiement en espèces (tâches normales) fait la queue. Mais on ne peut pas continuer à ajouter des voies ETC : si chaque voie devient ETC, personne ne double plus personne ; le péage reste embouteillé. La priorité ne veut dire quelque chose que lorsqu'elle est rare.
Le f() de la formule mérite un examen plus attentif : le temps d'attente protège contre « attendre éternellement », la distance choisit le robot le plus proche, la batterie écarte les unités peu chargées et le type de tâche distingue les travaux de transport, de levage et de charge. Une tâche P2 qui attend depuis 10 minutes peut dépasser en note une P1 tout juste arrivée une fois le vieillissement (aging) enclenché : c'est tout l'intérêt du vieillissement, et aussi le réglage que la plupart des gens désactivent sans réfléchir et regrettent le plus ensuite.
Trois façons de configurer la préemption, et ce que coûte chacune
Configuration A : pondération par priorité. Montez le poids de priorité de la commande urgente : par exemple, tâches normales à 5, commandes urgentes à 50. Un seul paramètre, d'une simplicité totale. Le coût : si vous le montez trop fort (par exemple 100), les tâches de faible priorité ne sont jamais servies. C'est la famine (starvation), et elle entraînera une vague normale vers sa perte.
Configuration B : réaffectation préemptive. Quand une commande urgente arrive, réquisitionnez un robot qui travaille sur une tâche de faible priorité ; la tâche interrompue recule et retourne dans la file. La réponse la plus rapide. Le coût, ce sont les trajets à vide (deadhead) : le trajet interrompu était du kilométrage gaspillé, et il faut maintenant le refaire.
Configuration C : capacité réservée. Gardez 10–20% de la flotte hors des vagues normales, dédiés aux commandes urgentes. L'option la plus stable. Le coût, c'est la capacité inutilisée les jours calmes : des soldats que l'on nourrit mille jours pour un jour de bataille.
| Configuration | Réponse aux urgences | Impact sur les vagues normales | Complexité | Convient à |
|---|---|---|---|---|
| A Pondération | Rapide | Tue la vague si on exagère | Faible | Part des urgences stable sous 5% |
| B Préemption | La plus rapide | Plus de trajets à vide, retours de tâches | Faible | Urgences rares exigeant une réponse de second niveau |
| C Capacité réservée | Toujours rapide | Presque aucun | Faible | Part des urgences volatile avec des pics nets |
Un projet que j'ai réglé en 2025 : un entrepôt de commerce électronique dans l'est de la Chine, 180 AMR. Poids des urgences fixé à 50. Avec une part normale d'urgences de 3%, tout allait bien ; le jour du festival d'achats 618, les commandes urgentes ont bondi à 15%, l'attente moyenne des tâches normales est passée de 50 secondes à 4 minutes et le taux de respect des délais des vagues a chuté de 12 points. Les journaux montraient une tâche de faible priorité attendant depuis 47 minutes : un cas d'école de famine. La cause racine tenait à une seule pièce manquante : pondération configurée, aucun mécanisme de vieillissement.
Comment choisir entre les trois ? Regardez la part des urgences : stable sous 5%, utilisez A : bon marché et suffisant. Rare mais nécessitant une réponse de second niveau (une ligne de production sur le point de s'arrêter), utilisez B. Volatile avec des pics nets (grands événements de vente, fin de trimestre), utilisez C. La plupart des entrepôts finissent avec un hybride A+C : pondération les jours normaux, capacité réservée activée deux semaines avant le pic. La ligne de partage n'est pas technique, c'est le rythme de l'activité, et c'est pourquoi neuf personnes sur dix qui copient les paramètres d'un autre entrepôt finissent par revenir en arrière.
La configuration de priorité des tâches RCS éprouvée sur le terrain : niveaux, vieillissement, capacité réservée
Niveaux. P0 vraie urgence (maintenir sous 5% du volume) / P1 vagues prioritaires / P2 normal / P3 reportable (réapprovisionnement, inventaires tournants). La règle d'airain pour ce qui compte comme « urgent » : non pas que les ventes disent que c'est urgent, mais que l'échéance du SLA soit à moins de X heures. Quand les ventes disent « ce lot est urgent », posez d'abord deux questions : « quelle est la pénalité du SLA, et perdons-nous le client ? » Impossible de répondre ? Ça va en P2. C'est là que naissent les fausses exigences, et je ne me retiens jamais de les dénoncer.
Vieillissement. Les tâches qui attendent trop longtemps sont automatiquement promues : le plancher qui empêche la famine :
effective priority = base weight + factor × wait time / threshold
Sans vieillissement, même des pondérations magnifiquement réglées sont une bombe à retardement : calmes les jours normaux, explosion garantie au pic.
Capacité réservée. 15–20% en haute saison, 5–10% hors saison, ajustée dynamiquement avec la part des urgences, jamais codée en dur. Rappelez-vous : les pondérations réordonnent la file ; elles ne créent pas de capacité. Si la part des urgences dépasse 10% et que vous ne faites que régler les pondérations, vous utilisez le mauvais outil.
Les pièges de maintenance : configurer une fois, souffrir pour toujours
Piège 1 : régler une fois, fonctionner un an. La haute saison change le mix de SKU et le rythme des vagues, mais les pondérations sont toujours celles de l'année dernière. La configuration des priorités doit suivre le plan de vagues : révision au moins trimestrielle, et toujours un nouveau réglage avant le pic.
Piège 2 : tester sans charge, donc la famine ne se voit jamais. Les tests ne regardent que le temps d'attente moyen, et les moyennes sont la métrique la plus malhonnête qui soit. Le chiffre qui compte, c'est le temps d'attente maximal des tâches de faible priorité. Quand il grimpe, la famine arrive.
Piège 3 : se barricader contre une part d'urgences au-dessus de la limite. Si les commandes urgentes restent au-dessus de 10% du volume sur le long terme, ce n'est pas un problème de planification, c'est un problème de capacité : ajoutez des robots, ou rétrogradez certaines commandes « urgentes » en P2. On ne colmate pas un manque de capacité avec des paramètres de planificateur.
Piège 4 : laisser n'importe qui marquer P0. Le plus grand ennemi de la priorité, ce ne sont pas les paramètres, c'est les gens. Les droits de marquage P0 doivent être restreints : qui peut marquer, si cela exige une approbation, et un audit mensuel de la vraie part de P0. Laissez le marquage ouvert et P0 dépassera 20% en trois mois ; aucun réglage ne vous sauvera après cela.
La configuration des priorités vaut-elle donc le coup ? Surveillez une paire de chiffres : le taux de respect des délais des commandes urgentes atteignant son objectif tandis que le temps d'attente moyen des tâches normales reste stable. Les deux vrais, et la configuration est bonne. Un seul vrai, et vous vous trompez vous-même.
Par Da Liu, Ingénieur en automatisation
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
