Il y a un étrange rituel que j'ai vu se répéter dans les projets d'entrepôts automatisés ces dernières années. Le fournisseur du WMS et le fournisseur du WES s'assoient autour de la même table de réunion. Ils parlent interfaces, ils parlent matériel, tout est cordial... jusqu'à ce que quelqu'un dise « allocation des tâches ». Alors les deux côtés commencent à se regarder, la pensée lisible dans leurs yeux : c'est ton boulot.
Après la réunion, le client me prend toujours à part. « Lao Mi, qui est vraiment responsable de ça ? » Je réponds généralement par une question de mon cru : « Est-ce dans votre contrat ? » Neuf fois sur dix, la réponse est non. Et ce silence est exactement le problème. Lancement des vagues, picks urgents, gestion des exceptions : trois tâches que personne ne veut revendiquer, et trois terrains où les projets d'automatisation se transforment en disputes.
Lancement des vagues : le WMS écrit la mélodie, le WES contrôle le tempo
La version des manuels est propre. Le WMS regroupe les commandes en vagues selon la priorité et les heures limites des transporteurs, les libère une vague à la fois, et le WES exécute. Un côté définit la stratégie, l'autre fait le travail.
Puis les AMR et les shuttles sont arrivés, et l'histoire s'est compliquée. Le fournisseur du WES vous dira qu'il voit le statut en temps réel de chaque robot et l'encombrement de chaque allée, et qu'il peut donc construire et libérer des vagues de manière dynamique, bien plus efficacement que les libérations rigides et minutées du WMS. La réponse du fournisseur du WMS : les vagues sont une stratégie de commandes, ce sont des engagements de fulfillment, et aucun fournisseur d'équipements ne décide de cela.
J'ai vu ce combat se jouer en 2023 dans un centre de fulfillment e-commerce dans l'Inland Empire, en Californie du Sud : un bâtiment de plus de 200 000 pieds carrés, avec quarante à cinquante AMR au sol. Le WMS libérait une vague toutes les 20 minutes selon les cutoffs des transporteurs. Le WES n'arrivait pas à suivre : les robots étaient encore en train de digérer la vague précédente quand la suivante arrivait. Les préparateurs attendaient dans les allées que les tâches arrivent pendant que les robots roulaient à vide. L'équipe WMS disait que sa logique de vagues était solide ; l'équipe WES disait que la cadence de libération était impossible. Le client, assis entre les deux, entendait des arguments raisonnables des deux côtés.
Mon verdict : la stratégie des vagues appartient au WMS — les règles de regroupement, la logique de priorité, c'est de la gestion des commandes et du fulfillment. Mais le rythme de libération doit être partagé avec le WES, car seule la couche d'exécution sait ce que les équipements peuvent réellement absorber. En pratique, il n'y a pas de propriétaire unique ici, seulement une copropriété, et elle doit être écrite dans les deux contrats : le WMS est propriétaire de la configuration de la stratégie des vagues, le WES est propriétaire du rythme de libération, et le contrat d'interface dit que le WMS publie les vagues tandis que le WES publie sa capacité en temps réel à absorber le travail. Quels champs, quelle logique — sur papier.
Picks urgents : la patate chaude de l'entrepôt
Rien ne se dispute plus âprement que les picks urgents : le service client appelle, un compte clé a une commande d'urgence, elle doit partir dans deux heures. Le WMS la marque priorité maximale et la pousse vers le WES. Le commercial du WES avait promis une priorisation dynamique pendant la démo. Au go-live, insérer une commande dans un plan de tâches déjà séquencé signifie recalculer les itinéraires, et l'efficacité de tout l'entrepôt en pâtit. Le WMS dit : « J'ai marqué la priorité, le reste est pour toi. » Le WES dit : « Tu l'as marquée, mais je ne peux pas l'exécuter. »
En 2024, sur un site 3PL dans l'Ohio, la haute saison a apporté des dizaines de picks urgents par jour, presque un par heure dans les pires moments. En creusant, le WES n'avait aucune voie dédiée pour les tâches accélérées. Chaque pick urgent passait par la file normale de reséquencement, le solveur devenait de plus en plus lent, et les commandes normales étaient entraînées avec. Le client était furieux : « Ce n'est pas ce que vous nous avez vendu. »
J'ai condensé la solution en trois conditions non négociables : l'autorité sur les picks urgents appartient au WMS — qui peut accélérer, et combien de fois par jour, car il faut un quota, et ce qui dépasse le quota passe par une approbation manuelle ; accélérer sans quota est un désastre garanti, le WES sera noyé par des interruptions illimitées, et c'est de la physique, pas un bug logiciel. L'exécution des picks urgents appartient au WES — réserver de la capacité ou construire une voie dédiée pour que les tâches accélérées ne détruisent pas la séquence globale. Et le SLA va dans le contrat — du moment où un pick urgent est émis au moment où son exécution commence, pas plus d'un nombre convenu de minutes. Le chiffre est négociable. Avoir un chiffre ne l'est pas.
Gestion des exceptions : là où les systèmes intelligents font les idiots
Troisième point, les exceptions. Un robot se bloque, une étiquette ne se scanne pas, un contrôle de poids échoue — la tâche meurt à mi-chemin. Qui l'intercepte ? Qui décide : réessayer, ou la passer à un humain ? La ligne du fournisseur du WMS : « Nous sommes le système supérieur ; le WES devrait traiter les exceptions en premier et remonter ce qu'il ne peut pas. » La ligne du fournisseur du WES : « Nous faisons tourner les équipements ; les exceptions métier — comme quelque chose qui cloche dans la commande elle-même — c'est la décision du WMS. »
Les deux sonnent raisonnables. En pratique, les exceptions que personne ne revendique disparaissent simplement dans le système. Sur un projet, pendant les trois premiers mois après le go-live, le WES croyait avoir signalé des exceptions que le WMS croyait n'avoir jamais reçues. Trouver la cause racine a pris plus d'une semaine, et c'était presque embarrassant : les codes d'exception envoyés par le WES n'existaient pas dans le dictionnaire du WMS, donc l'interface les abandonnait silencieusement. Un carton est resté sur un convoyeur pendant deux jours. Personne ne le savait.
Les exceptions doivent donc être divisées en deux couches. Les exceptions de la couche équipements — robots bloqués, connexions perdues, scans échoués — appartiennent au WES, qui doit d'abord tenter de se réparer lui-même : réessayer, rerouter, et seulement ensuite remonter. Les exceptions de la couche métier — commandes annulées, écarts d'inventaire — appartiennent au WMS. Et entre les deux couches, il doit y avoir une unique table de correspondance des codes d'exception, signée par les deux fournisseurs et testée ligne par ligne pendant l'intégration. La plupart des projets n'ont pas cette table. Ils testent que l'interface se connecte et crient victoire. Rappelez-vous : une interface connectée n'est pas la même chose qu'un flux d'exceptions qui fonctionne.
Les vraies causes racines — et comment les écrire hors d'existence
À ce stade, les causes racines sont probablement claires. Mais laissez-moi les nommer, car les nommer est ce qui les rend contractuelles.
Commençons par le fait que personne n'a jamais défini ce qu'est réellement un WES. Il y a dix ans, le WMS faisait tout tourner et les équipements étaient stupides. Puis les AMR et les shuttles ont développé un cerveau, et le WES est né pour les gérer. Mais l'industrie n'a jamais standardisé la frontière du WES — le WES d'un fournisseur est pratiquement un petit WMS, celui d'un autre est à peine un planificateur d'équipements. En sélection, vous pensez acheter la même chose à chaque soumissionnaire. Ce n'est pas le cas. Les démos se ressemblent toutes ; les contrats décrivent deux animaux différents.
Puis il y a le problème plus profond : les deux côtés « optimisent », mais ils n'optimisent pas la même chose. Le WMS optimise le fulfillment — taux de livraisons à temps, respect des cutoffs. Le WES optimise l'efficacité des équipements — taux d'utilisation des robots, débit des allées. Le fulfillment veut de la vitesse ; les équipements veulent de la fluidité. Ils sont en tension par nature, et les vagues, les picks urgents et les exceptions sont exactement là où ces deux objectifs entrent en collision. Les accusations ne sont donc pas un problème d'attitude. Les fonctions objectifs sont réellement en désaccord.
Et le plus dommageable : ce n'est pas dans le contrat. Le cahier des charges (SOW) du WMS dit « Le fournisseur est responsable du module d'allocation des tâches ». Le cahier des charges du WES dit la même phrase. Des frontières qui se chevauchent plus une rédaction vague équivalent à une invitation permanente à se disputer.
Alors, comment l'écrire dans le contrat ? Le modèle que je donne aux clients est un tableau simple à trois colonnes : élément, propriétaire, copropriétaire. Il couvre au moins huit éléments : définition de la stratégie des vagues, rythme de libération des vagues, autorité et quotas des picks urgents, voie d'exécution des picks urgents, autoréparation des exceptions d'équipements, arbitrage des exceptions métier, maintenance du dictionnaire des codes d'exception, et propriété des champs d'interface. Chaque élément a exactement un propriétaire. « Support » ou « assistance » ne compte pas comme attribution.
J'insiste aussi sur quelques clauses dures : des critères d'acceptation détaillés — la table des codes d'exception testée ligne par ligne avec un taux de réussite de 100 %, les picks urgents passant de l'émission au début d'exécution en moins de cinq minutes, où le chiffre est négociable mais pas le fait d'en avoir un. La responsabilité de maintenir le dictionnaire des exceptions confiée à une personne nommée, avec tout nouveau code synchronisé de l'autre côté sous 48 heures. Et une clause d'arbitrage que j'ai ajoutée après m'être brûlé quelques fois et que je n'ai jamais retirée depuis : les litiges de frontière sont tranchés par le client sous 48 heures, et aucun des deux côtés ne peut arrêter le travail pendant la dispute.
Revenons à cette salle de réunion. La prochaine fois que le fournisseur du WMS et le fournisseur du WES s'assoient ensemble et commencent à se regarder au sujet de l'allocation des tâches, je les interromps généralement : arrêtez de vous regarder, ouvrez le contrat, trouvez la page et la ligne. Les frontières ne se règlent pas en se disputant en réunion. Elles se règlent par écrit. Écrivez-les et les deux côtés connaissent leur travail ; laissez-les vagues et chaque exception, chaque pick urgent devient une nouvelle dispute. Et le coût de toutes ces disputes retombe, à chaque fois, sur le client.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
