Plus rapide que “One‑Click”: Pourquoi les supply chain programmables gagnent en vitesse

Joannes Vermorel

Dans la supply chain, on parle beaucoup de vitesse. Vitesse de réapprovisionnement. Vitesse de réponse. Vitesse de récupération lorsque quelque chose ne va pas. Pourtant, lorsqu’il s’agit des systèmes destinés à soutenir ces décisions, la conversation sur la vitesse se résume rapidement à une seule mesure : combien de semaines faut-il pour être opérationnel après avoir signé un contrat logiciel?

La plupart des grands fournisseurs de logiciels pour la supply chain ont une réponse très claire à cette question. Ils promettent une mise en valeur rapide grâce à du contenu préconfiguré, des modèles de données standard et des “industry best practices”. Si vous regardez le marketing des suites de planification intégrée d’entreprise et des systèmes de planification avancée, le récit est remarquablement cohérent : partir de leur modèle de référence, appliquer une série de modèles, et vous pouvez être en production en “quelques semaines” ou “aussi peu que 12 semaines”, parfois explicitement “d’Excel à la planification avancée en quelques semaines.”

Récemment, j’ai essayé de prendre du recul par rapport à ce récit dans mon livre Introduction to Supply Chain, où je conçois la supply chain comme l’art de prendre des décisions rentables dans un contexte d’incertitude, jour après jour. Si nous prenons ce point de vue au sérieux, la question “à quelle vitesse pouvons-nous déployer un logiciel?” devient “à quelle vitesse pouvons-nous mettre en production des décisions automatisées de haute qualité — et les garder alignées avec l’évolution de l’entreprise?” C’est une question tout à fait différente.

À partir de là, j’en arrive à une conclusion qui va à contre-courant : pour des initiatives supply chain sérieuses, une approche programmable n’est pas seulement plus puissante que le logiciel packagé traditionnel ; elle permet en réalité d’amener des résultats significatifs en production plus rapidement.

Permettez-moi d’expliquer pourquoi.

La promesse rassurante des logiciels supply chain préconfigurés

Les fournisseurs traditionnels de planification d’entreprise offrent un récit rassurant.

Ils partent d’un modèle de données canonique pour la supply chain : sites, produits, hiérarchies, nomenclatures, calendriers, délais, contraintes. Au-dessus de ce modèle, ils fournissent des processus préconfigurés (“best practices”), des ensembles de données d’exemple, des tableaux de bord modèles, des alertes, des algorithmes standards, et des guides de configuration. L’ensemble de ce matériel est explicitement conçu pour accélérer la mise en œuvre et réduire le risque de projet.

La logique est parfaitement cohérente. Si les données et processus de chaque client peuvent être décrits comme une variation modeste d’un modèle commun, alors la majeure partie du travail devrait être réutilisable. Le projet de mise en œuvre se résume à mapper les champs de l’ERP dans le modèle de planification, activer les fonctionnalités pertinentes, ajuster les paramètres, et apprendre aux utilisateurs à utiliser les écrans.

Dans ce monde, la personnalisation est un mal nécessaire. Elle est acceptée pour des cas “spéciaux”, mais elle est aussi reconnue comme la principale source de retards, de dépassements de budget, et de complexité à long terme. D’où l’orientation vers la “configuration, et non la personnalisation” — et plus récemment, vers des outils low‑code et no‑code — afin de rester dans le cadre sécurisé de ce que le logiciel sait déjà faire.

Dans ces hypothèses, l’idée que le logiciel packagé se déploie plus rapidement est tout à fait raisonnable.

La difficulté est que les supply chain réelles correspondent rarement à ces hypothèses.

Là où les projets ralentissent vraiment : la sémantique, pas les écrans

Lorsque l’on examine de près où le temps est réellement consacré lors des déploiements de grands systèmes supply chain, ce n’est pas à l’installation du logiciel, ni même à la formation des utilisateurs. C’est à comprendre ce que signifient les données.

La plupart des grandes entreprises possèdent un ou plusieurs ERP, plus un éventail d’autres systèmes — CRM, WMS, TMS, PIM, le e‑commerce, etc. Ensemble, ils contiennent des milliers de tables. Officiellement, ces entités ont des significations documentées ; en pratique, leur vraie sémantique résulte d’années de solutions de contournement, de conventions locales, de compromis et de nettoyages partiels. Le véritable comportement du système est encodé dans la manière dont les utilisateurs s’en servent, et non dans la façon dont le fournisseur original avait prévu son utilisation.

Quand une suite de planification arrive, elle apporte son propre modèle de données et ses propres attentes. Même lorsqu’elle provient du même fournisseur que l’ERP, la sémantique ne s’aligne pas de manière cohérente. Un champ appelé “type de site” ou “safety stock” ne signifie pas la même chose en configuration, dans les opérations quotidiennes, dans les rapports, et dans le moteur de planification.

Quelqu’un doit concilier tout cela.

Ce quelqu’un est généralement une équipe mixte d’IT, de consultants, et de parties prenantes de l’entreprise. Ils doivent décider quelles tables font autorité, quels champs sont fiables, comment gérer les exceptions, et comment mapper la réalité désordonnée de l’entreprise dans les structures épurées attendues par le logiciel de planification. Ils rédigent des tâches d’extraction et de transformation ; ils ajoutent des indicateurs et attributs personnalisés ; ils inventent des conventions pour encoder des contraintes que le modèle standard ne peut exprimer.

C’est à ce moment que le déploiement supposé “one‑click” se transforme souvent en un vaste effort d’intégration. Le logiciel lui-même peut être opérationnel dès le premier jour, mais les données dont il a besoin — les données précises, fiables et quotidiennes qu’exige un moteur d’optimisation sérieux — mettent des mois, voire des années, à se stabiliser véritablement.

Ce n’est pas un échec de mise en œuvre. C’est le symptôme d’un fait plus profond : la sémantique est locale, et il n’existe pas de représentation universelle et prête à l’emploi de la supply chain d’une entreprise donnée.

La supply chain en tant que logiciel, et non configuration

Si nous admettons que la sémantique est locale, et qu’elle ne cesse d’évoluer à mesure que l’entreprise change, alors la distinction habituelle entre “configuration” et “personnalisation” devient trompeuse.

En substance, une initiative supply chain ambitieuse est toujours un exercice logiciel. C’est l’acte de spécifier, de manière précise et exécutable, comment l’entreprise souhaite prendre des décisions concernant les achats, la production, les stocks, la tarification, l’allocation, etc., compte tenu des données et contraintes disponibles.

Dans le modèle packagé traditionnel, ce logiciel est constitué de tables de configuration, de paramètres, de diagrammes de workflow, de connecteurs personnalisés, et d’éventuelles “user exits” écrites dans un langage de programmation généraliste. L’espoir est que la majeure partie de la logique puisse être exprimée via la configuration, et que seules les marges nécessitent du code.

Selon mon expérience, surtout dans des environnements complexes, c’est le contraire qui se produit. La logique la plus critique et différenciante finit par être implémentée de manière fragile : en surchargeant les champs, en superposant des feuilles Excel et des notebooks Python aux côtés du système officiel, en apprenant aux planificateurs à interpréter les tableaux de bord d’une manière spécifique qui n’est en réalité encodée nulle part.

Le résultat net est que le “système” se trouve en partie dans le logiciel et en partie dans la tête des gens.

Chez Lokad, nous avons décidé, il y a plus d’une décennie, d’embrasser la nature logicielle du problème plutôt que de la combattre. Nous avons développé notre propre langage spécifique au domaine, Envision, destiné aux praticiens de la supply chain plutôt qu’aux ingénieurs logiciels professionnels. L’idée est simple : représenter toutes les transformations de données, toutes les prévisions, toutes les contraintes, et toutes les décisions sous forme de scripts pouvant être lus, versionnés, testés, et modifiés de manière contrôlée.

De l’extérieur, cela ressemble à un environnement de programmation. En interne, c’est notre réponse au problème sémantique : au lieu de forcer une réalité complexe dans un modèle prêt à l’emploi, nous nous donnons un langage flexible pour décrire cette réalité telle qu’elle est réellement.

Cela nous ramène à la vitesse.

Qu’est-ce que cela signifie d’être « rapide » dans la supply chain?

Si la vitesse est définie comme « délai jusqu’à ce que le fournisseur de logiciels puisse déclarer une mise en production conformément à leur liste de vérification », alors les suites préconfigurées sembleront souvent plus rapides. Le plan de projet est optimisé pour cet échéance. Le modèle canonique est conçu pour être alimenté rapidement. Le matériel de formation et les meilleures pratiques sont alignés sur cet objectif spécifique.

Cependant, si la vitesse est définie comme « délai jusqu’à ce que nous ayons un flux de décision automatisé et opérationnel auquel nous confions de l’argent réel », le tableau change.

Dans une approche programmable, la séquence du projet ressemble typiquement à ceci :

Tout d’abord, mettez en place des extractions quotidiennes fiables à partir des systèmes existants, sans essayer de les forcer dans un nouveau modèle canonique. Cela reste un travail ardu, mais il s’agit surtout de plomberie : extraire les données brutes, telles qu’elles sont, avec toute leur laideur.

Ensuite, dans l’environnement programmable, exprimez la logique métier étape par étape : nettoyer et concilier les données ; exprimer les contraintes et les priorités ; modéliser l’incertitude ; et enfin, calculer des décisions concrètes telles que les quantités de commandes, les plans de production ou les choix d’allocation. Parce que cette logique est écrite dans un langage sur mesure, le cycle de changement est court : un Supply Chain Scientist peut l’affiner quotidiennement ou hebdomadairement au fur et à mesure que des cas limites et de nouvelles exigences apparaissent.

Enfin, mettez ces décisions en dual‑run : comparez ce que proposent les scripts et ce que font réellement les planificateurs, mesurez l’impact financier, et ajustez en conséquence. Lorsque la confiance est suffisamment élevée, laissez les scripts prendre le contrôle de parties bien sélectionnées du portefeuille.

Le point crucial est que cette séquence est itérative. À aucun moment nous ne nous attendons à ce que la première version de la logique soit parfaite. Nous ne nous attendons pas non plus à ce que l’environnement reste immobile. Au contraire, nous supposons que les règles de décision devront être réécrites de manière substantielle tous les un ou deux ans au fur et à mesure que l’assortiment, le réseau, les promesses de service et le paysage concurrentiel évoluent.

Dans un tel contexte, le principal déterminant de la « vitesse » n’est pas la date de la première mise en production. C’est le temps moyen de changement : le temps nécessaire pour ajuster le système lorsque l’entreprise décide de modifier son mode de fonctionnement.

Si une politique de prix met six mois à être encodée dans une suite de planification monolithique, peu importe que l’implémentation originale ait été terminée dans les délais il y a trois ans.

Pourquoi la programmabilité devient plus rapide sur l’ensemble de la vie du système

Vu de l’extérieur, la programmabilité ressemble à un fardeau. Il se pourrait bien que la rédaction de code soit plus lente que la configuration d’un écran existant ?

Dans des cas simples, cela peut être le cas. Si la supply chain est relativement petite, stable et proche du modèle de référence du fournisseur, alors une solution préconfigurée pourrait en effet atteindre rapidement un état stable acceptable. De nombreuses entreprises ne poussent pas leurs outils de planification à l’extrême ; elles les utilisent comme des tableurs structurés avec des interfaces utilisateur plus agréables et quelques alertes. Dans ce contexte, l’approche packagée peut être adéquate et, dans un sens étroit, plus rapide.

Le tableau change de manière spectaculaire dès que nous passons à des environnements qui sont:

• large et hétérogène (plusieurs ERP, différentes unités commerciales, plusieurs types de produits et canaux),
• volatile (des assortiments, des délais de livraison, et des promesses de service changeantes fréquemment),
• et ambitieux (visant des niveaux élevés d’automatisation, et non simplement de support à la décision).

Dans ces cas, les solutions préconfigurées sont confrontées à trois défis structurels.

Premièrement, l’écart sémantique est trop grand. Plus il existe d’exceptions et de conventions locales, plus le modèle canonique doit être ajusté pour les intégrer. Chaque ajustement devient une astuce de configuration, une extension personnalisée ou un processus annexe. Avec le temps, le système accumule des couches de cas particuliers difficiles à comprendre et encore plus difficiles à éliminer.

Deuxièmement, le coût du changement est contrôlé de l’extérieur. Modifier la logique d’une suite de planification majeure implique habituellement plusieurs niveaux : l’informatique interne, des consultants externes, et parfois le fournisseur lui-même. Il existe des cycles de déploiement, des protocoles de test et des processus de gouvernance conçus pour la sécurité, pas pour l’agilité. Cela se comprend, mais cela signifie que même des changements raisonnables et modérés peuvent prendre des mois.

Troisièmement, la logique elle-même vieillit rapidement. Les règles de supply chain qui avaient du sens il y a trois ans sont rarement optimales aujourd’hui. Lorsque le coût de les réviser est élevé, les organisations ont tendance à reporter cet effort. Elles patchent en périphérie avec des tableurs, des contournements et de la gestion de crise.

En revanche, une approche programmable engage la plupart de ses coûts dès le départ : vous devez accepter que vous écrivez essentiellement un logiciel. Mais une fois que vous disposez d’un environnement dédié pour ce logiciel—un environnement suffisamment spécialisé pour être accessible aux experts de la supply chain, et pourtant suffisamment expressif pour décrire la réalité de l’entreprise—l’économie du changement s’inverse.

Ajouter une nouvelle contrainte, intégrer une nouvelle source de données, ou revoir la manière dont vous gérez les promotions devient une question de modification de scripts plutôt que de négociation d’une nouvelle phase d’implémentation. Parce que la logique de décision est explicite, vous pouvez la versionner, la tester et la rétablir. Parce qu’elle est centralisée plutôt que dispersée dans des tables de configuration et des fichiers annexes, vous pouvez la considérer dans son ensemble.

Sur la durée de vie du système, cette capacité à changer rapidement tend à dominer le bénéfice unique d’une mise en service rapide.

Ceci n’est pas un rejet des logiciels grand public

Il serait erroné d’interpréter ceci comme un argument contre tous les logiciels packagés de supply chain. Ces systèmes résolvent de nombreux problèmes de manière efficace. Ils fournissent un traitement robuste des transactions; ils s’intègrent dans un vaste écosystème; ils offrent des interfaces utilisateur, des modèles de sécurité, une auditabilité et des fonctionnalités de conformité qui seraient coûteuses à reproduire à partir de zéro.

Ce n’est pas non plus un appel à chaque entreprise pour tout développer en interne en utilisant des langages de programmation à usage général. Cette voie conduit rapidement à son propre type de fragilité, avec la prolifération de scripts sur mesure sans discipline.

Ce que je préconise est différent: un noyau programmatique pour la logique de décision, entouré par le meilleur des systèmes packagés pour tout le reste.

Autrement dit, utilisez votre ERP, WMS et TMS pour ce en quoi ils excellent: enregistrer ce qui s’est réellement passé, appliquer des règles métiers simples, et orchestrer des workflows. Utilisez des suites de planification spécialisées là où leurs fonctionnalités standards correspondent réellement à vos besoins. Mais n’attendez pas de ces outils packagés qu’ils soient l’endroit où réside votre logique de décision la plus importante, la plus dynamique et la plus différenciante.

Pour cela, vous avez besoin de quelque chose qui accepte dès le départ que votre supply chain est unique, qu’elle évoluera, et que chaque initiative sérieuse finira par rencontrer des détails sémantiques qu’aucun modèle n’avait anticipé.

Un langage spécifique au domaine tel qu’Envision est une réponse possible. Il est celui que nous avons développé et affiné chez Lokad au fil des années, précisément pour donner aux experts supply chain la capacité d’exprimer et de maintenir leur propre logique directement, sans passer par des couches d’intermédiaires.

D’autres fournisseurs ont poursuivi des idées similaires sous des formes différentes ; ce qui importe, ce n’est pas l’étiquette « DSL », mais le principe sous-jacent : la logique décisionnelle doit être de premier ordre, programmable, et appartenir aux personnes qui comprennent l’économie de l’entreprise.

Repenser la vitesse

Si nous redéfinissons la vitesse comme « à quelle rapidité pouvons-nous mettre en production des décisions robustes et automatisées, et à quelle rapidité pouvons-nous les réviser dès que nécessaire ? », la conclusion est inévitable.

À court terme, les suites préconfigurées semblent souvent plus rapides car elles minimisent le travail visible dès le départ et optimisent pour un lancement cérémonial. À moyen et long terme, leur rigidité et le coût du changement les ralentissent précisément là où la vitesse est la plus nécessaire : lorsque l’environnement commercial évolue.

Une approche programmatique accepte davantage de travail dès le départ, mais elle rapporte à chaque fois que la réalité s’écarte des hypothèses initiales — c’est-à-dire tout le temps. Dans un monde où l’incertitude est la norme plutôt que l’exception, ce type de rapidité importe plus que le nombre de semaines sur une slide d’implémentation.

La question n’est donc pas de savoir si vous voulez écrire un logiciel pour votre supply chain. Si votre entreprise est suffisamment grande et complexe, vous le faites déjà — par configuration, par des tableurs, par des scripts locaux et des conventions manuelles. La seule véritable question est de savoir si vous voulez que ce logiciel soit explicite, cohérent et sous votre contrôle.

Ma réponse est claire : si nous nous soucions de la vitesse dans un sens véritable, la supply chain doit être programmable.