Voici le verdict d'emblée : dans une intégration AMR–WMS, écrire l'API représente environ 20% du travail. Les 80% restants consistent à décider qui génère les tâches de transport et quelle couche reçoit le statut des véhicules.
J'ai mené plus de 30 mises en production de WMS, dont neuf avec des AMR. Voici une règle de sélection à copier : moins de 10 robots d'un seul fournisseur, laissez le WMS les piloter directement. De 10 à 50 robots, un seul fournisseur, placez le RCS (système de contrôle des robots) du fournisseur au milieu. Plus de 50 robots, ou une flotte multi-fournisseurs, construisez une couche de pool de tâches. Des règles de terrain, pas un standard.
Pourquoi tout se résume-t-il à « qui crée la tâche, qui reçoit le statut » ? Le WMS parle métier — quelle commande, quel emplacement, quelles marchandises. Le RCS parle véhicules — quel robot est libre, quelle allée est bloquée, quelle batterie est en train de mourir. L'intégration est la traduction entre les deux. Mal traduire, et le fret part au mauvais endroit.
Les trois modèles d'intégration AMR–WMS, côte à côte
| Le WMS pilote directement | RCS au milieu | Modèle de pool de tâches | |
|---|---|---|---|
| Qui crée les tâches | Le WMS envoie les tâches directement à chaque robot | Le WMS envoie les tâches métier ; le RCS les décompose en mouvements de véhicules | Un service d'orchestration indépendant répartit tout |
| Qui gère la logique de flotte | Le WMS, avec des règles simples | Le RCS en est propriétaire (routage, évitement d'obstacles, charge) | Le pool de tâches + le RCS de chaque fournisseur |
| Retour de statut | Robot → WMS, à gros grain | RCS → WMS sur un jeu de statuts convenu | Le pool de tâches agrège, puis rapporte au WMS |
| Taille de flotte adaptée | Moins de 10 robots | 10–50 robots, un seul fournisseur | 50+ robots, ou multi-fournisseurs |
| Effort d'intégration | Faible | Moyen | Important |
| Plus gros piège | Le WMS ne comprend pas les véhicules — embouteillages | Incohérences du mappage de statuts | Le pool de tâches devient un nouveau point unique de défaillance |
| Délai typique (expérience terrain) | 2–4 semaines | 6–10 semaines | 3–6 mois |
Modèle 1 : le WMS pilote directement — le moins d'interfaces, casse quand la flotte grandit
Comment ça marche : le WMS attribue une tâche de transport (de A à B) directement à chaque robot, qui renvoie « terminé ».
Où ça convient : les pilotes de moins de 10 robots sur des itinéraires fixes — disons, des mouvements de palettes complètes de la réception au stockage sur deux voies.
Où ça casse : le WMS ne sait pas où sont les robots, leurs niveaux de batterie, ni si l'allée devant est bloquée. En 2023, un entrepôt d'accessoires 3C à Suzhou — 12 000 mètres carrés, 18 AMR à levage branchés directement sur leur WMS historique. La deuxième semaine de mise en production, le WMS a déversé plus de 40 tâches d'un coup ; six robots se sont coincés à l'entrée d'une allée, et l'équipe a mis une demi-heure à les dégager à la main. Le bug le plus insidieux : les tâches du WMS n'avaient pas de champ de type de tâche, donc les robots ne pouvaient pas distinguer la réception du réapprovisionnement — une palette de réapprovisionnement est partie au quai d'expédition.
La solution : nous avons inséré un service fin de file d'attente de tâches entre les deux — le WMS y dépose les tâches, le service les attribue selon la disponibilité, la batterie et la position des robots. Coût : la mise en production a glissé de six semaines.
J'ai vu exactement cet échec trois fois. Le pilotage direct n'est pas faux — il n'est simplement sûr que lorsque la flotte est petite, les itinéraires simples et le mix de tâches uniforme.
Modèle 2 : RCS au milieu — le courant dominant actuel de l'intégration AMR–WMS
Comment ça marche : le WMS n'émet que des tâches métier (« déplacer la palette P123 de l'emplacement A-01-02 vers le quai D3 »). Le RCS les décompose en mouvements de véhicules, attribue les robots, planifie les itinéraires et gère la charge. Le statut remonte du RCS vers le WMS selon un contrat convenu.
C'est aujourd'hui le choix le plus stable pour 10–50 robots d'un fournisseur : le WMS n'a jamais besoin de comprendre les véhicules ; le RCS n'a jamais besoin de comprendre le métier.
Mais il y a un piège dans lequel presque tout le monde tombe : le mappage de statuts. En 2024, un entrepôt e-commerce transfrontalier à Nansha, Guangzhou — 32 AMR à fourche de deux fournisseurs, deux instances de RCS, un WMS au-dessus. Le RCS du fournisseur A ne rapportait que trois états de tâche (en cours, terminé, erreur) ; celui du fournisseur B en avait neuf. Le « en pause » du fournisseur A a été traduit par « terminé » — la palette était encore au milieu du bâtiment alors que le WMS l'avait déjà comptabilisée comme reçue. Plus de 60 palettes d'écart, une journée entière d'inventaires tournants pour réconcilier.
La solution : une table unifiée de mappage de statuts. Quels que soient les états produits par le RCS d'un fournisseur, ils doivent se réduire à huit états standard avant d'atteindre le WMS — en file, en cours, en pause, erreur, terminé, annulé, délai dépassé, prise en main manuelle. L'équipe WMS possède la table, les fournisseurs de RCS s'y conforment, et elle entre au contrat en annexe. J'ai vu cet échec trois fois ; à la troisième, je l'ai enfin écrit dans le contrat avant de signer.
Modèle 3 : pool de tâches — la grosse artillerie pour les flottes grandes et mixtes
Comment ça marche : un service d'orchestration de tâches indépendant (le pool de tâches) se place entre le WMS et le RCS de chaque fournisseur. Le WMS y dépose les tâches métier ; le pool les attribue entre fournisseurs pour une répartition globalement optimale ; le statut est agrégé par le pool avant de remonter vers le WMS.
Où ça convient : 50+ robots, ou les entrepôts engagés dans une flotte multi-fournisseurs. La récompense : changer de fournisseur d'AMR plus tard signifie changer le pilote du pool, pas toucher au WMS.
Le prix : le pool de tâches est lui-même un nouveau système que quelqu'un doit maintenir — et un point unique de défaillance. S'il tombe, tout l'atelier s'arrête, donc il faut de la haute disponibilité. Intégration plus tests prennent trois à six mois dans mon expérience.
La vérité contre-intuitive : le développement n'est jamais la partie chère
Voici l'affirmation contre-intuitive : dans les projets d'intégration AMR, le développement de l'API représente typiquement un cinquième de l'effort total. Ce qui brûle le budget, c'est de découvrir pendant les tests d'intégration que la logique métier ne s'aligne pas. Exemple : le WMS définit « tâche terminée » comme « les marchandises sont arrivées », le RCS comme « le robot est arrivé ». Le robot arrive, signale terminé, et les marchandises sont encore sur son dos. Les livres sont faux.
Ces problèmes meurent avec une question de plus pendant les exigences. Découverts au moment des tests d'intégration, ils se transforment en dispute à trois entre l'équipe WMS, le fournisseur de RCS et l'équipe de site qui traîne pendant des semaines. Ma pratique : avant la signature du contrat, la définition de « terminé » entre en annexe, et les deux parties la signent. Une conversation gênante en amont vaut mieux qu'une engueulade la veille de la mise en production.
Une autre chose que les gens oublient : qui émet les tâches de charge ? Le RCS, jamais le WMS — le WMS ne sait pas quels chargeurs sont occupés. Sur un projet, le WMS a envoyé des robots à batterie faible charger selon un horaire — huit robots en file pour quatre chargeurs pendant que leurs tâches expiraient. Laissez le RCS posséder la charge ; le WMS n'a besoin que d'une notification de délai dépassé.
Liste de contrôle la veille de la mise en production : cochez chaque case
Distribution des tâches :
- Chaque tâche porte un ID globalement unique ; renvoyer le même ID doit être idempotent (exécuté exactement une fois).
- Chaque tâche porte un type de tâche (réception / réapprovisionnement / expédition / transfert). Le RCS n'a pas le droit de deviner.
- Les valeurs de délai d'expiration des tâches sont convenues des deux côtés ; au délai dépassé, le WMS peut annuler et le RCS doit s'y conformer.
- Lorsqu'une tâche est annulée pendant que le robot porte des marchandises, il doit y avoir une règle explicite pour les marchandises.
Retour de statut : 5. La table de mappage à huit états est signée par les deux parties et jointe au contrat. 6. Le RCS envoie un battement de cœur au WMS (environ une fois par seconde, ou équivalent) ; si le battement s'arrête plus de ~30 secondes, le WMS doit alerter. 7. Les rapports de statut échoués sont mis en cache localement et réessayés — aucun statut perdu. 8. La « prise en main manuelle » doit être signalée — le WMS doit savoir qu'un humain conduit ce robot.
Exceptions et l'atelier : 9. Les tâches de charge sont émises par le RCS ; le WMS ne commande jamais la charge directement. 10. Les événements d'arrêt d'urgence, de détachement de charge et de chute de marchandises doivent parvenir au WMS (ou au téléphone d'astreinte) dans le délai convenu. 11. Après une intervention manuelle, la reprise ou l'annulation de la tâche est décidée par une règle pré-écrite. 12. Le comportement par défaut du robot en cas de perte réseau (attendre sur place vs. retourner au chargeur) est décidé à l'avance.
Alignement des données : 13. Les codes d'emplacement sont identiques dans le WMS et le RCS — casse, traits d'union, chaque caractère. 14. Les règles de codes-barres de palettes correspondent ; tout code scanné par le RCS doit être reconnu par le WMS. 15. Quais, chargeurs et zones de préparation sont nommés un pour un dans les deux systèmes.
Tests de charge : 16. Faites tourner à 1.5× le volume de tâches de haute saison pendant quatre heures continues ; surveillez la congestion et les taux de délais dépassés. 17. Simulez trois pannes — RCS en panne, WMS en panne, panne d'un seul robot — et parcourez la procédure de reprise pour chacune. 18. Réconciliez les livres avec l'atelier : pendant le test, choisissez au hasard 50 palettes ; l'emplacement comptable du WMS et l'emplacement physique doivent correspondre.
Une liste de contrôle n'est pas de la décoration — la veille de la mise en production, cochez chaque élément et faites signer le responsable. Ajoutez par-dessus les cas particuliers de votre site.
Par Lin Xiao, spécialiste en implémentation WMS
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
