Hommes, Machines et le Vrai Travail de la Supply Chain
Lorsque je m’assieds avec des cadres pour parler de supply chain, ils commencent presque toujours par évoquer les entrepôts, les camions, le personnel, et parfois les fournisseurs. Les ordinateurs apparaissent en arrière-plan : un système de planification ici, une feuille de calcul là, et bien sûr l’ERP “sur lequel tout fonctionne”. L’image implicite est toujours la même : les personnes sont au centre, les machines sont là pour aider.
J’ai exploré une vision tout à fait différente dans mon livre Introduction to Supply Chain, dans lequel j’affirmais que la majeure partie de ce que nous appelons la “pratique de la supply chain” est, en réalité, un problème de logiciel déguisé. Dans cet essai, je souhaite reformuler cette idée de manière plus simple et la confronter directement à la vision dominante qui règne tant dans les manuels que dans les salles de direction.
Comment nous avons discrètement rétrogradé les ordinateurs
Dans une grande partie de la littérature et dans la plupart des entreprises, les ordinateurs sont traités comme des pelles sophistiquées.
Vous êtes censé les avoir, bien sûr. Personne ne gérerait plus un réseau mondial en utilisant du papier et un fax. Les systèmes capturent les transactions, stockent les données de référence, génèrent des rapports et produisent des prévisions. Les planificateurs se connectent chaque matin, consultent des tableaux de bord, associent ce que le système indique à leur “sens des affaires” et décident de la marche à suivre.
Le ton est toujours similaire : la technologie fournit un soutien. Elle collecte des données, effectue des calculs, affiche des indicateurs rouges et verts, et propose peut-être une quantité de commande recommandée. Mais il est attendu que l’humain “prenne en charge” la décision. Le logiciel est l’analyste ; le planificateur est le décideur.
Sur le papier, cela semble rassurant. Cela respecte l’expérience, l’intuition et la responsabilité. Cela évite la crainte que “le système dirige l’entreprise”. Cela correspond à notre intuition selon laquelle les décisions importantes devraient être prises par des personnes sérieuses.
Le problème, c’est que cette vision ne correspond plus à l’ampleur et à la complexité des supply chains modernes.
La supply chain comme un tissu de petits paris
Chaque jour, votre entreprise prend un nombre incroyable de petits engagements.
Vous décidez du nombre d’unités de chaque article à acheter auprès de chaque fournisseur. Vous choisissez quel entrepôt doit recevoir quelles quantités. Vous allouez le stock rare entre les canaux et les clients. Vous acceptez ou rejetez les commandes urgentes. Vous décidez quels articles méritent une place sur les étagères, et à quel prix. Vous acceptez certains délais proposés par les transporteurs et en rejetez d’autres.
Chacun de ces engagements est un petit pari sur un avenir incertain : un pari que cette commande arrivera à temps, que cette promotion stimulera le volume, que ce stock de sécurité sera suffisant sans être excessif. Aucun de ces paris n’est particulièrement héroïque en soi, mais pris ensemble, ils font ou défont le compte de résultat.
La particularité des supply chains modernes ne réside pas dans leur caractère global ou rapide ; cela fait déjà partie du connu. C’est que le nombre de ces paris a explosé. Les gammes de produits s’élargissent. Les canaux se multiplient. Les délais varient. Les attentes des clients augmentent. La “surface de décision” devient trop vaste pour qu’une équipe humaine puisse la surveiller, encore moins l’optimiser manuellement.
Dans cet environnement, le modèle dominant — des humains au centre, des machines fournissant un support à la décision — ne peut tout simplement pas s’adapter. Les personnes deviennent des goulets d’étranglement au mauvais endroit : pas au port ou dans l’entrepôt, mais devant les écrans.
Pourquoi les ordinateurs doivent être au centre
Les ordinateurs possèdent un superpouvoir : ils excellent dans l’exécution d’un grand nombre de petits calculs structurés, encore et encore, sans jamais se fatiguer ni s’ennuyer.
La supply chain est précisément ce type de problème. La plupart des décisions opérationnelles qui accaparent le temps des équipes de planification sont répétitives. Elles se répètent jour après jour, avec des variations de données mais une structure similaire. Elles ont des entrées claires : prévisions, coûts, capacités, contraintes, règles métier. Elles ont des sorties claires : quantités, dates, emplacements, prix. Elles ne sont pas triviales, mais elles sont structurées.
Lorsque vous acceptez cela, une architecture différente s’impose.
Au lieu de considérer les ordinateurs comme des outils servant à préparer des informations pour les humains, vous commencez à les voir comme des machines qui prennent réellement les décisions routinières. Pas des machines “assistant”, mais des machines “décision”.
Cela ne signifie pas construire un gigantesque cerveau monolithique qui contrôle tout. Cela signifie concevoir délibérément un logiciel qui, dans des circonstances normales, peut:
- lire les données pertinentes,
- évaluer de nombreuses options possibles,
- en choisir une selon un objectif économique explicite,
- et émettre une instruction concrète : une ligne de bon de commande, un transfert de stocks, une allocation, un prix.
Les humains existent toujours dans ce monde, mais ils ne passent plus leurs journées à pousser individuellement chaque commande. Ils travaillent autour de la machinerie décisionnelle plutôt que à travers elle.
C’est le changement fondamental : passer des ordinateurs qui supportent les décisions à des ordinateurs qui prennent des décisions dans tous les domaines où les décisions sont petites, nombreuses et répétitives.
À quoi servent réellement les gens
Mettre les machines au centre ne rend pas les gens moins importants ; cela les rend responsables de choses différentes.
Tout d’abord, les gens doivent décider de ce que le logiciel est autorisé à faire. Cela signifie définir l’espace des options admissibles. Le cross-docking est-il autorisé entre ces sites ? Les substitutions sont-elles permises entre ces deux SKUs ? Pouvons-nous expédier des commandes partielles à ce client ? Pouvons-nous utiliser le fret aérien pour ce produit dans cette région ? Les ordinateurs n’inventent pas les options ; ils sélectionnent parmi celles que nous mettons à disposition.
Ensuite, les gens doivent décider ce que signifie “bien”. Il ne s’agit pas d’aspirations vagues comme “excellence de service” ou “lean stocks”, mais d’arbitrages explicites. Quelle est la douleur financière d’une rupture de stock pour différents produits et clients ? Combien coûte l’obsolescence ? Quelle valeur accordons-nous réellement aux délais par rapport aux coûts sur une base de voie par voie ? Comment devrions-nous arbitrer entre deux unités commerciales en concurrence pour la même capacité limitée ?
Lorsque nous répondons précisément à ces questions, nous fournissons au logiciel une fonction objective. Nous lui indiquons ce que nous voulons, dans un langage qu’il peut appliquer à chaque décision.
Troisièmement, les gens doivent préserver le sens des données. Au fil du temps, les champs d’un système sont réutilisés, réinterprétés et détournés. Une colonne qui signifiait autrefois “date de livraison promise” signifie parfois désormais “date demandée”. Un indicateur qui signalait une famille de produits est discrètement réaffecté pour indiquer une promotion interne. Si personne ne fait attention, le logiciel continuera à calculer des absurdités très précises.
Enfin, les gens doivent intervenir lorsque le monde évolue plus rapidement que les modèles ou les règles. Ils doivent être capables de dire : cette contrainte n’est plus valable ; cette pénalité est trop élevée ; cette option de sourcing est désormais politiquement inacceptable ; ce délai n’est plus fiable. Ils n’interviennent pas en modifiant manuellement des milliers de commandes, mais en changeant les hypothèses qui génèrent ces commandes.
Ainsi, dans cette optique, les humains ne sont pas des commis qui peaufinent des tableurs. Ce sont des concepteurs, économistes et gardiens de la machinerie décisionnelle. Leur rôle est de concevoir le jeu, de fixer le score et de veiller à ce que le jeu ne reflète plus la réalité.
La vision dominante, exposée clairement
Permettez-moi maintenant d’exposer la vision dominante d’une manière que la plupart des praticiens reconnaîtront.
Dans une entreprise typique, le paysage logiciel comporte trois couches.
En bas, des systèmes de transaction enregistrent ce qui se passe : commandes, réceptions, expéditions, factures. Au-dessus d’eux, des outils de reporting et des tableaux de bord résument cette histoire selon de multiples tranches : par produit, client, région, période. Au-dessus, on trouve des systèmes de planification qui récupèrent les données d’en bas, analysent des prévisions, exécutent des heuristiques ou des optimisations, et produisent des “propositions.”
Ces propositions sont ensuite examinées par des planificateurs. Ils les comparent à leur connaissance du marché, aux particularités des fournisseurs, à la politique des clients, et à la réalité des entrepôts. Ils en acceptent certaines, ajustent d’autres, et passent outre pour le reste. Dans de nombreuses organisations, une grande partie de cette dernière étape se déroule dans des classeurs, en dehors de tout système formel.
La philosophie implicite est claire : les systèmes sont là pour informer et assister. Les humains, en particulier les planificateurs, sont là pour décider. Si quelque chose tourne mal, l’explication est souvent que “le système n’est pas assez flexible”, ou “les données étaient erronées”, ou “l’algorithme n’a pas compris ce cas particulier”, donc il nous fallait “un planificateur pour le corriger.”
Les manuels scolaires renforcent ce schéma. La technologie de l’information est décrite comme un “moteur” ou un “facilitateur” de la performance de supply chain. Elle offre visibilité, intégration, rapidité et sophistication analytique. Mais il y a toujours une étape où le décideur humain réapparaît au sommet de la pyramide, à qui le système rend compte.
Cette vision n’est pas entièrement erronée. Elle a capturé la réalité de ce qui était réalisable pendant longtemps. Les systèmes étaient rigides. L’optimisation à grande échelle était coûteuse. La qualité des données était médiocre. Intégrer un humain dans le processus était une décision sûre et pragmatique.
Mais nous nous sommes accrochés à ce modèle plus longtemps qu’il ne le mérite.
Là où je diverge de la vision dominante
Mon désaccord avec la vision dominante peut s’exprimer en une simple phrase :
Pour la plupart des décisions opérationnelles, nous ne devrions plus viser le support à la décision ; nous devrions viser l’automatisation de la décision.
Cela ne signifie pas une automatisation aveugle. Cela signifie que lorsqu’une décision est petite, fréquente et structurellement similaire à travers de nombreux cas, nous devrions concevoir un logiciel qui la gère de bout en bout, en laissant aux humains le soin de se concentrer sur la conception et la surveillance du mécanisme plutôt que sur son exécution quotidienne.
De cette simple affirmation découlent plusieurs désaccords.
La vision dominante investit massivement dans l’ajout de plus de tableaux de bord et de plus de planificateurs. Je préfèrerais investir dans moins de planificateurs qui se comportent davantage comme des responsables produit quantitatifs et dans davantage d’ingénieurs capables d’encoder la logique métier en code plutôt qu’en configuration.
La vision dominante cherche à acheter des systèmes suffisamment “configurables” pour gérer la plupart des situations dès leur sortie de la boîte. Je m’attends à ce que toute supply chain sérieuse recèle de nombreuses particularités et contraintes spécifiques à l’entreprise qui ne peuvent être saisies de manière significative par de simples cases à cocher et des tableaux de paramètres. À un moment donné, il faut que quelqu’un écrive du code.
La vision dominante traite la combinaison d’ERP, de modules de planification, et de BI comme une pile complète : les données en bas, l’insight au milieu, et les décisions au sommet. Je considère cette pile comme étant seulement à moitié construite. La couche manquante est celle qui prend en charge la majorité des engagements réels de l’entreprise.
Par-dessus tout, la vision dominante insiste pour que les humains demeurent ceux qui “prennent” les décisions. J’insiste sur le fait que, pour la grande majorité des décisions routinières, il est préférable d’affecter les humains à décider comment les décisions doivent être prises, plutôt que de les prendre une par une.
“Mais et si le système se trompe ?”
Une objection courante est immédiate et légitime : que se passe-t-il lorsque le système se trompe ?
Si nous laissons le logiciel passer des commandes, allouer des stocks, et fixer les prix, et que le logiciel commet une erreur, les conséquences peuvent être graves. Avec un humain dans le processus, au moins quelqu’un aurait pu la détecter.
Je crois que cette objection est importante, mais elle va dans les deux sens.
Lorsque vous comptez sur les humains pour corriger la production de systèmes fondamentalement mal spécifiés, vous échangez un type d’erreur contre un autre. Des erreurs individuelles peuvent être détectées, mais les erreurs structurelles persistent. Personne n’a le temps ni la capacité cognitive pour constater que toute la logique du système est légèrement décalée, qu’une pénalité est mal calibrée, ou qu’une contrainte a dérivé. Les gens éteignent les incendies ; ils repensent rarement la conception.
Dans un système automatisé, vous êtes obligé de traiter ce risque de manière explicite.
Vous avez besoin d’une surveillance qui ne se contente pas d’examiner les taux de service et la rotation des stocks, mais qui peut attribuer les défaillances à des hypothèses spécifiques. Il vous faut la capacité de suspendre l’automatisation pour un sous-ensemble de produits ou de régions lorsqu’une anomalie est détectée. Il vous faut des pistes d’audit : des enregistrements clairs expliquant pourquoi le système a choisi une décision particulière, avec quels paramètres d’entrée et quelle logique interne.
Plus important encore, vous avez besoin d’une culture qui accepte que le logiciel soit un actif de premier ordre. Il mérite d’être conçu, testé, refactorisé et soumis à une gouvernance. Il ne peut pas s’agir d’une boîte noire opaque que “le fournisseur gère” ou “dont s’occupe l’IT”. Si le logiciel gère les opérations quotidiennes, alors enrichir et corriger son comportement est l’une des responsabilités fondamentales de l’organisation de supply chain.
Cela peut sembler plus risqué que de demander aux planificateurs de “surveiller les propositions”, mais en pratique, cela réduit souvent le risque plutôt que de l’accroître. Les défaillances sont plus traçables. Les corrections sont systémiques plutôt que locales. L’apprentissage s’accumule dans le code au lieu de disparaître lorsqu’un planificateur expérimenté part.
Là où je suis encore d’accord avec la vision dominante
Malgré ces désaccords, il existe des domaines dans lesquels je suis entièrement aligné avec la vision dominante.
Je suis d’accord sur le fait que l’information est centrale. Sans des données opportunes et fiables, toute ambition d’automatisation relève du fantasme.
Je suis d’accord pour dire que les silos organisationnels constituent un obstacle majeur. Si les achats, la logistique, les ventes et la finance ne parviennent pas à s’accorder sur des définitions de base et des objectifs partagés, aucun système ne pourra les sauver.
Je suis d’accord que la supply chain ne se résume pas aux mathématiques et aux machines. Les relations avec les fournisseurs, la confiance entre partenaires, les contraintes réglementaires et les chocs géopolitiques comptent énormément. Un bel moteur de décision ne peut pas faire apparaître un navire dans un canal bloqué.
Mon propos est plus précis : lorsqu’il s’agit du travail quotidien de décider des quantités, des timings et des allocations à travers de vastes réseaux, nous sous-utilisons de manière spectaculaire les machines que nous possédons déjà. Nous enfermons des personnes talentueuses dans des boucles administratives où elles apportent très peu de valeur marginale, tout en absorbant une énorme énergie organisationnelle.
Une destination différente
Si vous prenez mon point de vue au sérieux, la destination ressemble à ceci.
La plupart des décisions opérationnelles quotidiennes — quoi commander, où allouer, combien expédier, quand réapprovisionner — sont prises automatiquement par le logiciel, dans des circonstances normales. Le logiciel fonctionne selon des règles claires et explicites ainsi que des objectifs économiques, et son comportement est visible et vérifiable.
Les planificateurs ne commencent pas leur journée en faisant défiler des listes d’exceptions. Ils débutent leur journée en examinant le comportement même de la machine décisionnelle : là où elle performe bien, là où elle est erratique, là où les hypothèses ont peut-être perdu de leur fraîcheur. Ils collaborent avec des ingénieurs pour affiner la logique, améliorer les données, ajuster les compromis économiques.
Lorsque des perturbations surviennent, les humains interviennent, non pas en microgérant des commandes individuelles, mais en modifiant les paramètres du jeu : interdire certains modes de transport, ouvrir des options de sourcing temporaires, revoir les pénalités et les priorités. Le système recalcule alors la myriade de petits paris impliqués par ces nouvelles conditions.
Les carrières en supply chain évoluent en conséquence. On consacre moins de temps à “se battre contre le système” et à “corriger le plan”. On consacre davantage de temps à comprendre l’économie de l’entreprise, à coder cette compréhension dans des logiciels et à concevoir des ensembles d’options résilients pour un monde incertain.
Dans une telle organisation, les ordinateurs ne sont plus des pelles. Ils constituent la machinerie de la supply chain. Les gens sont les architectes, les économistes et les intendants de cette machinerie.
C’est la perspective que je voulais clarifier ici. Elle diffère fortement du récit dominant de l’informatique en tant que support et des humains en tant que décideurs principaux. Mais je crois qu’elle se rapproche de la réalité de l’évolution future des supply chains.
