La Supply Chain a besoin de systèmes programmables, pas de produits configurables

Joannes Vermorel

J’ai récemment publié Introduction à la Supply Chain sous forme de livre gratuit en ligne. J’y soutiens que les décisions de supply chain doivent être produites par des systèmes programmatiques plutôt que par des produits logiciels « configurables ». Puisque le livre est intentionnellement vaste, je souhaite utiliser cet article pour me concentrer sur une idée précise : pourquoi Lokad a adopté une approche profondément programmatique, et comment cela nous oppose à la vision grand public des logiciels de supply chain.

Je ne discuterai pas de fournisseurs spécifiques. Ce qui m’intéresse, c’est la philosophie sous-jacente : quel type de logiciel est réellement appropriate pour la supply chain ?

Pourquoi les logiciels génériques peinent avec des supply chains concrètes

La plupart des logiciels vendus dans la supply chain aujourd’hui suivent une trame similaire.

D’abord, on part d’une base transactionnelle : quelque chose qui enregistre les commandes, les réceptions, les mouvements de stocks, les factures, les expéditions. Cette couche est relativement standardisée. Elle fonctionne avec des entités familières : clients, bons de commande, SKUs, emplacements. Elle est censée être générique et réutilisable dans de nombreux secteurs, ce qu’elle est en grande partie.

Au-dessus de cette base, vous ajoutez des modules de « planification » ou « optimisation ». Ces modules promettent de transformer les données passées et présentes en de meilleures décisions : bons de commande, transferts, plans de production, allocations, prix, etc. Les fournisseurs présentent généralement ces capacités sous forme d’applications configurables. Vous n’écrivez pas la logique ; vous la configurez. Vous définissez des règles. Vous réglez des paramètres. Vous ajustez des modèles. Vous adoptez des processus de « best-practice ».

À première vue, cette approche semble tout à fait raisonnable. Après tout, nous constatons des problèmes globalement similaires partout : combien acheter, où stocker, quand déplacer, quoi promettre, quoi escompter. Sûrement qu’une plateforme générique peut répondre à ces problèmes de manière réutilisable.

Pourtant, lorsqu’on examine de près les supply chains réelles, quelque chose d’obstiné se met en travers du chemin : les idiosyncrasies.

Un distributeur de câbles découvre que dix mille mètres de câble ne constituent pas « un nombre » ; cela dépend de la manière dont ces mètres sont répartis entre les bobines, des longueurs réellement commandées par les clients, des pertes de coupe acceptables, et des coupes pouvant être promises sans compromettre les marges.

Une entreprise aérospatiale constate qu’« une pièce en stock » peut dissimuler un composant sérialisé ayant son propre historique de maintenance, des contraintes de certification, et des règles complexes de substitution.

Un détaillant de mode apprend que la demande ne concerne pas uniquement les SKUs mais les assortiments : certaines combinaisons taille–couleur doivent être présentes ensemble, sinon toute la catégorie sous-performe, peu importe le nombre de pièces individuelles en stock.

Lorsque nous essayons d’enfermer ces situations dans un moteur de décision générique, elles ne se comportent pas comme des cas marginaux. Elles constituent le cœur de l’activité. Chaque entreprise a sa propre version de ces « câbles » : des contraintes et une économie qui ne rentrent pas dans un modèle préétabli, et qui déterminent pourtant la rentabilité de l’ensemble de l’opération.

Le résultat, en pratique, est familier : des modules de planification configurables au centre, des tableurs sur les bords, et des planificateurs humains comblant constamment les lacunes.

Pourquoi la configuration ne suffit pas

L’ambition des logiciels de planification configurables est que la complexité peut être maîtrisée par des options : plus de paramètres, plus d’interrupteurs, plus de types de règles, plus de modèles. Vous ne devriez pas avoir à programmer ; vous devriez être capable d’« apprendre » au logiciel ce qu’il doit faire par la configuration.

Malheureusement, la configuration a des limites strictes.

La configuration fonctionne lorsque vous connaissez déjà la structure du problème. Si chaque entreprise partageait la même structure de contraintes et d’économie, le même modèle conceptuel du comportement de la demande et de la réaction des stocks, alors choisir des valeurs pour un ensemble prédéfini de règles serait suffisant.

Mais une supply chain réelle n’est pas un puzzle fixe attendant les bons paramètres. C’est une cible mouvante, façonnée par la concurrence, les réglementations, les réseaux logistiques et les habitudes des clients qui évoluent constamment. De plus, les contraintes les plus impactantes sont souvent précisément celles qui ne correspondent pas au modèle standard de quiconque.

Lorsque le modèle du monde intégré dans le logiciel ne correspond pas au monde dans lequel vous évoluez, vous n’avez que deux options.

Soit vous changez votre entreprise pour vous conformer au logiciel. Cela est parfois sensé pour des processus purement administratifs, mais périlleux lorsqu’il s’agit de votre avantage compétitif.

Ou vous compensez en dehors du système : tableurs auxiliaires, ajustements manuels, gestion des exceptions, surcharges de dernière minute. Le logiciel central devient une sorte de moteur de suggestions élaboré, tandis que le contrôle réel retourne aux cerveaux humains et aux fichiers Excel.

Plus vous essayez d’étendre un produit de planification générique pour accueillir vos spécificités, plus vous finissez avec une configuration embrouillée que personne ne comprend complètement, et qui est difficile à faire évoluer. Vous n’avez pas échappé à la complexité ; vous l’avez enfouie dans les métadonnées.

Pourquoi la programmabilité est inévitable

Si la configuration ne suffit pas, il ne reste que la programmation.

Le terme « programming » est souvent mal compris ici. Je ne préconise pas que chaque planificateur devienne un ingénieur logiciel, ni que chaque entreprise construise une pile complète à partir de zéro. J’expose simplement quelque chose que je considère inévitable :

Si vous voulez qu’un système prenne en charge vos décisions de supply chain, vous devez être capable d’exprimer, de manière précise, la logique selon laquelle ces décisions sont prises.

Cette logique inclut :

• La manière dont l’incertitude est traitée : la demande, les délais de livraison, la fiabilité des fournisseurs, les promotions, les perturbations.
• La manière dont l’économie est encodée : le coût des ruptures de stocks, le coût de l’excès, le coût de détention, les contraintes en capital, les engagements de service, les pénalités.
• La manière dont les contraintes sont appliquées : l’emballage, les quantités minimales de commande, les capacités des camions et des conteneurs, la durée de conservation, les règles de substitution, les restrictions réglementaires.
• La manière dont les compromis sont réalisés entre des objectifs conflictuels.

Chacun de ces éléments est spécifique à votre entreprise. Chacun évolue au fil du temps. Et chacun interagit avec les autres de manière que aucun catalogue d’options de configuration ne peut anticiper.

C’est pourquoi je dis que la programmabilité n’est pas une préférence stylistique. C’est une reconnaissance de la réalité. La question n’est pas “Faut-il programmer ?” mais “Où, et avec quel type d’outils ?”

Les tableurs sont une forme de programmation. Ils sont extrêmement populaires en supply chain précisément parce qu’ils permettent aux praticiens d’exprimer une logique qui ne rentre pas dans une application standard. Malheureusement, ils ne se scalent pas bien, ils encouragent la duplication de logique, et ils ne se prêtent pas à une automatisation robuste.

Les langages de programmation à usage général peuvent exprimer n’importe quoi, mais ils comportent un autre problème : si vous essayez de construire l’ensemble de l’intelligence de votre supply chain dans une pile générique, vous vous retrouvez rapidement à diriger en sous-main une entreprise de produits logiciels. Vous devez assembler et maintenir des bases de données, des calculs distribués, des interfaces, la sécurité et des pipelines de déploiement qui ont peu à voir avec votre véritable activité.

Le défi, donc, est d’adopter la programmation tout en évitant à la fois la fragilité des tableurs et les frais généraux liés à la construction d’une plateforme générique à partir de zéro.

Comment cela façonne les choix technologiques de Lokad

En 2012, nous avons fait le choix délibéré de ne pas essayer de produire un “produit de planification” universel qui prétend fonctionner immédiatement grâce à la seule configuration.

Au lieu de cela, nous nous sommes engagés à construire un environnement où la logique de décision de supply chain peut être exprimée sous forme de code, de manière à être :

• Assez puissant pour encoder la véritable complexité d’une entreprise.
• Assez compact pour être compréhensible et auditable.
• Assez opérationnel pour fonctionner tous les jours, à grande échelle, par-dessus les systèmes transactionnels existants.

Concrètement, cela nous a conduits à quelques principes.

Premièrement, nous considérons les données provenant des ERPs et d’autres systèmes transactionnels comme une matière première, et non comme quelque chose à simplement reporter. Nous supposons que la véritable valeur vient du fait de transformer ces données en décisions concrètes : bons de commande, transferts de stocks, plannings de production, politiques de tarification et de remise, décisions d’assortiment.

Deuxièmement, nous exprimons cette transformation sous forme d’une collection de scripts, écrits dans un langage spécifique au domaine conçu spécialement pour la supply chain : de grands ensembles de données tabulaires, une demande probabiliste, de l’optimisation économique, etc. Ce langage n’est pas un langage de programmation d’entreprise générique ; c’est un environnement spécialisé visant à rendre les recettes de décision numérique concises et lisibles.

Troisièmement, nous insistons sur le fait que le résultat de nos calculs n’est pas un tableau de bord, mais un ensemble d’actions proposées qui peuvent être appliquées aux systèmes transactionnels. Si notre travail ne se traduit pas par des commandes modifiées, des stocks modifiés, des prix modifiés, alors il n’a aucune raison d’exister en production.

Enfin, nous organisons le tout de manière à pouvoir le réécrire. Si le monde change, si une pandémie redessine la demande, si une nouvelle catégorie de produit se comporte de manière inattendue, nous visons à modifier le code rapidement et en toute sécurité, plutôt que d’attendre des années pour une nouvelle version d’un produit.

C’est une mentalité bien différente de celle qui consiste à accumuler de plus en plus de “fonctionnalités” génériques dans un produit logiciel. Nous n’essayons pas d’être tout pour tout le monde. Nous cherchons à fournir un instrument précis qui peut être utilisé pour exprimer la logique qui compte vraiment pour une entreprise donnée.

La vision grand public et là où nous divergeons

L’approche grand public de la technologie supply chain repose sur une aspiration raisonnable : standardiser et industrialiser les processus de planification. Elle met l’accent sur des suites intégrées, des meilleures pratiques prédéfinies, et une configuration conviviale. Elle promet un déploiement plus rapide et une dépendance réduite aux compétences techniques rares.

Il existe des situations où cette approche apporte de la valeur, notamment lorsque l’entreprise est relativement proche des modèles standards supposés par le logiciel, et lorsque les objectifs principaux sont la visibilité, la gouvernance et une coordination de base.

La divergence se trouve dans la réponse à une question spécifique :

Où une entreprise devrait-elle placer l’intelligence qui décide réellement de ce qu’il faut faire ?

La réponse grand public est la suivante : à l’intérieur d’un produit configurable, maintenu par le fournisseur, adapté par des paramètres, des workflows et des extensions.

Notre réponse chez Lokad est : à l’intérieur d’une couche compacte et programmable, gérée par une petite équipe qui possède la logique décisionnelle et peut la modifier au gré des évolutions de la réalité.

De cette différence découlent de nombreuses conséquences pratiques.

Dans une vision centrée sur le produit, la difficulté centrale consiste à choisir et mettre en œuvre le bon produit, puis à aligner l’organisation avec ses processus et ses fonctionnalités. Une fois le produit en place, l’attention se porte sur son utilisation correcte : s’assurer que les gens consultent les tableaux de bord, suivent les workflows, et remplissent les inputs.

Dans une vision programmatique, la difficulté centrale consiste à construire et maintenir une bonne recette numérique : une recette qui reflète la véritable économie de l’entreprise, qui prend en compte l’incertitude de manière significative, et qui peut être révisée rapidement si nécessaire. La plateforme logicielle est jugée selon la qualité de son support à cet effort : pouvons-nous exprimer des contraintes complexes sans transformer la logique en spaghetti ? Pouvons-nous rejouer les décisions d’hier pour comprendre ce qui s’est passé ? Pouvons-nous expérimenter en toute sécurité de nouvelles idées ?

Les deux approches comportent des algorithmes, des prévisions, de l’optimisation et des interfaces attrayantes. La différence réside dans celui qui contrôle en fin de compte la logique et dans la capacité d’adaptation de cette logique.

Un chemin étroit, mais nécessaire

Le chemin programmatique n’est pas le plus facile à expliquer. “Vous aurez du code qui exprime vos décisions supply chain” sonne moins glamour que “Vous aurez un système intelligent avec des meilleures pratiques configurables.” Il nécessite également une certaine discipline : une attribution claire, une gestion rigoureuse des versions, une instrumentation appropriée, et un déploiement soigné.

Cependant, après près de deux décennies passées à observer les logiciels supply chain en pratique, je ne vois aucune alternative viable si nous prenons l’automatisation au sérieux.

Si nous voulons des systèmes qui font plus que suggérer et visualiser ; si nous voulons qu’ils prennent la responsabilité de décisions qui déplacent des biens d’une valeur de plusieurs milliards de dollars ; si nous voulons qu’ils survivent aux chocs et s’adaptent aux contraintes nouvellement découvertes, alors nous devons nous doter des moyens d’exprimer la logique avec précision et de la réviser sans crainte.

C’est ce que propose la programmabilité.

Lokad existe parce que je crois que la supply chain est trop importante pour être confiée à des configurations opaques et des produits rigides. Elle mérite des logiciels qui reconnaissent la réalité désordonnée et particulière de chaque entreprise, et qui offrent à ceux qui gèrent la supply chain les outils nécessaires pour traduire leur compréhension en une forme réellement opérationnelle.

Cette perspective explique à la fois les choix technologiques que nous avons faits et notre manière de travailler avec nos clients. Nous ne vendons pas une boîte qui prétend contenir de l’intelligence. Nous offrons un moyen de la construire, de la peaufiner et de la maintenir vivante.