La priorité des tâches du RCS ne posait aucun problème à l'ère des petites flottes. Avec une douzaine de robots, le premier arrivé premier servi fonctionnait assez bien : une batterie faible signifiait aller recharger, et une commande urgente pouvait être insérée à la main sans rien casser. Mais une fois qu'une flotte dépasse un certain seuil, l'ordonnancement cesse d'être du dispatching et devient un véritable arbitrage. Les tâches de vague ont besoin de débit, les commandes urgentes ont besoin de délai, et la recharge a besoin que la flotte reste en ligne — et les trois se disputent les mêmes robots. Le RCS, le système de contrôle des robots situé entre le WMS et la flotte, passe chaque jour à répartir la capacité entre ces trois types de tâches.
Une fois la flotte à l'échelle, la priorité des tâches RCS devient un vrai problème
Commençons par les données. Selon Interact Analysis, les expéditions cumulées de robots mobiles approchaient 2.1 million d'unités fin 2025, soit environ $18 billion de revenus, tandis que le nombre de sites clients déployant des robots mobiles passait d'un peu plus de 9,000 en 2020 à plus de 53,000. L'histoire de l'industrie ces cinq dernières années a été le passage de "quelques dizaines de robots en pilote" à "une flotte comme unité d'exploitation".
Pourtant, le même cabinet a revu ses prévisions à la baisse dans une mise à jour mi-2025 : il a réduit la prévision AMR de l'année de $800 million, ramené le taux de croissance composé à cinq ans de 26% à 21%, et abaissé la projection de revenus 2030 à $15.6 billion, invoquant les perturbations tarifaires et une attitude attentiste dans les dépenses d'investissement des clients. La révision mérite qu'on s'y arrête. Elle ne signifie pas que le problème d'ordonnancement rétrécit — bien au contraire. Dans les années où l'expansion ralentit, les opérateurs tirent plus d'utilisation des flottes qu'ils possèdent déjà, et plus l'utilisation est élevée, plus le conflit entre types de tâches est aigu.
Un second signal vient d'Amazon. En June 2025, l'entreprise a annoncé son millionième déploiement de robot, réparti sur plus de 300 sites, aux côtés de DeepFleet, un modèle d'IA générative conçu pour coordonner les mouvements des robots, qui selon l'entreprise peut améliorer l'efficacité des déplacements des robots de 10%. Ce chiffre est une affirmation du fournisseur, pas une mesure vérifiée de manière indépendante, et la distinction compte. Mais la direction est claire : quand la cible de coordination passe de dizaines de machines à un million, l'ordonnancement ne peut plus être "des règles gravées dans la pierre". Il doit devenir quelque chose que le système apprend.
Un vrai dilemme : quand les commandes urgentes volent les robots de la vague
Avant la haute saison 2024, un entrepôt de fulfillment e-commerce dans le sud-ouest des États-Unis a rencontré le cas d'école. Le soir d'une grande promotion, les commandes urgentes affluaient, et le RCS a activé la priorité préemptive : les tâches urgentes haute priorité pouvaient interrompre les tâches de vague basse priorité en cours et emporter les robots.
La coupure a été sauvée, et les commandes urgentes de ce soir-là ont été expédiées plus ou moins à temps. Le prix s'est manifesté dans la seconde moitié de la nuit. Les tâches de vague interrompues n'arrêtaient pas d'être reportées, les vagues suivantes ont toutes glissé, et à un moment les stations de picking restaient inactives avec des robots attendant des marchandises qui n'étaient pas arrivées — les véhicules attendaient le travail, et non l'inverse.
Le cas illustre un fait facile à manquer : la préemption n'est pas gratuite. Elle n'élimine pas le retard ; elle le déplace, transférant le coût des commandes urgentes vers les tâches de vague sous une autre forme. Une politique de priorité est, au fond, une décision sur qui supporte le coût de la congestion du système.
Trois stratégies de priorité des tâches RCS : un cadre d'arbitrage d'ordonnancement
En pratique, les approches de l'industrie face au conflit à trois se rangent en trois grandes stratégies, chacune avec ses coûts :
| Stratégie | Logique | Convient le mieux à | Coût |
|---|---|---|---|
| Priorité statique | Classement fixe, p. ex. urgente > vague > recharge | Petites flottes, mix de tâches homogène | Les vagues meurent de faim quand les commandes urgentes sont fréquentes ; la recharge est systématiquement négligée |
| Score pondéré | Chaque type de tâche est noté dynamiquement sur le temps d'attente, la pression d'échéance et l'état du véhicule ; le meilleur score passe en premier | Tâches mixtes, charge volatile | Les poids exigent un recalibrage continu ; le réglage est coûteux et la dérive dégrade la performance |
| Préemptif avec garde-fous | Les commandes urgentes peuvent préempter, mais les tâches de vague gardent une part minimale garantie ; la recharge est réservée par fenêtres | Grandes flottes, haute saison | Le plus complexe à mettre en œuvre ; exige de prévoir l'état de la flotte et les arrivées de tâches |
Aucune n'est la réponse standard. Mon observation est que la plupart des flottes matures exécutent une variante de la troisième : la préemption est autorisée, mais le camp préempté reçoit une protection contre la famine — par exemple, une tâche de vague monte automatiquement en priorité après avoir été reportée un nombre déterminé de fois. L'enjeu n'est pas quelle stratégie choisir, mais si l'exploitation accepte le principe que toute règle statique échouera sous une certaine charge, et que la politique elle-même a besoin de rétroaction.
La contre-intuitive : la recharge est la variable cachée du débit
Des trois types de tâches, la recharge est la plus facile à sous-estimer. L'intuition dit que la recharge ne produit aucune commande, donc elle devrait arriver en dernier. Un entrepôt a suivi cette intuition et a fixé la priorité de recharge au minimum, ne laissant que les robots sous un seuil de batterie aller recharger.
Puis, un soir de haute saison, une grande partie de la flotte a atteint le seuil presque en même temps. Une file s'est formée aux stations de recharge, la disponibilité de la flotte s'est effondrée dans les premières heures, et le débit du site a suivi. Le correctif des ingénieurs était contre-intuitif : ils ont relevé la priorité des tâches de recharge et sont passés à la recharge fragmentée d'opportunité — compléter entre les tâches chaque fois qu'un robot passait devant un chargeur — combinée à des fenêtres de recharge concentrée pendant les heures creuses. La courbe de disponibilité s'est aplatie, et le système est devenu plus stable, pas moins.
L'arbitrage mérite d'être décortiqué. Le vrai coût d'une tâche de recharge n'est pas l'électricité. Ce sont des véhicules qui passent hors ligne au mauvais moment, ensemble. Dans une flotte à haute utilisation, la recharge est une condition préalable du débit, pas une réflexion après coup. La traiter comme une tâche basse priorité "quand il y aura du temps" plante une bombe à retardement dans l'ordonnancement.
Pourquoi les trois types de tâches sont en conflit par conception
Le conflit est structurel, pas managérial. Les trois types de tâches vivent sur trois échelles de temps différentes : les tâches de vague sont planifiées à l'heure et hautement prévisibles ; les commandes urgentes arrivent à la minute et sont essentiellement imprévisibles ; la recharge est régie par les courbes de batterie et le nombre physique de chargeurs, ce qui en fait au fond un problème de satisfaction de contraintes.
Un cran plus bas, leurs fonctions objectives n'ont jamais été alignées. Les tâches de vague veulent maximiser le débit, les commandes urgentes veulent minimiser la latence, et la recharge veut maximiser la disponibilité de la flotte. Chaque jour, le RCS effectue un arbitrage en ligne sur les trois objectifs, et toute règle qui n'en optimise qu'un seul — "toujours prioriser les commandes urgentes", par exemple — le paie sur les deux autres dimensions. C'est aussi pourquoi plus la flotte est grande, plus vite les règles écrites à la main arrivent au bout du chemin.
Jugement de tendance : la priorité des tâches RCS passe des moteurs de règles à l'optimisation par apprentissage
En mettant les données et les cas ensemble, mon jugement est que dans les trois à cinq prochaines années, l'ordonnancement RCS grand public passera de "les humains écrivent des règles et règlent des paramètres" à l'optimisation par apprentissage "entraîner en simulation, inférer en ligne". Trois raisons : premièrement, l'échelle des flottes — 2.1 million d'unités cumulées sur 53,000 sites — a déjà rendu le réglage manuel intenable ; deuxièmement, des pratiques comme le DeepFleet d'Amazon montrent que les opérateurs de pointe remplacent les règles par des modèles pour la coordination à l'échelle de la flotte ; troisièmement, la simulation mature de jumeaux numériques permet à une politique de répéter des milliers de hautes saisons dans une flotte virtuelle avant de toucher une flotte réelle.
Le jugement a toutefois une condition préalable. L'ordonnancement par apprentissage a besoin de données opérationnelles de haute qualité comme carburant, et la gouvernance des données de la plupart des entrepôts en est encore au stade "assez bien". L'algorithme n'est pas le goulot d'étranglement. Les données le sont.
Ce qui laisse une question ouverte. Quand la politique d'ordonnancement elle-même devient un système qui apprend, l'équipe d'exploitation de l'entrepôt a-t-elle encore besoin de garder la main sur la surcharge manuelle de priorité ? Et si oui, à quelle granularité — régler quelques paramètres de pondération, ou prendre le contrôle d'un robot individuel en urgence ? Il n'y a pas encore de réponse standard, mais la réponse façonnera probablement à quoi ressemblera la prochaine génération de produits RCS.
Par Dr. Chen, chercheur en chaîne logistique
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
