Holimization: Pourquoi l'optimisation ne suffit pas

Joannes Vermorel

Durant la majeure partie de ma carrière, on m’a dit que “optimisation” était la solution. Si seulement nous pouvions formuler le bon modèle, l’alimenter avec suffisamment de données, et laisser agir un solveur puissant, la machine produirait calmement les meilleures décisions possibles.

Pourtant, dans les supply chains réelles, cette promesse se concrétise rarement. Les entreprises déploient des logiciels sophistiqués, ajustent d’innombrables paramètres, et se retrouvent néanmoins à lutter contre des ruptures de stocks, un excès de stocks, et des planificateurs nerveux qui ne font plus confiance au système. Les mathématiques à l’intérieur de la boîte noire peuvent être magnifiques; les décisions sur le plancher de l’entrepôt ne le sont souvent pas.

Dans Introduction to Supply Chain, en particulier dans les chapitres consacrés aux décisions et aux recettes numériques, j’ai soutenu que le véritable goulot d’étranglement n’était pas le manque de solveurs mais celui d’un cadre adéquat autour de l’optimisation elle-même. Dans cet essai, je souhaite pousser cette idée un peu plus loin et lui donner un nom: holimization, et son verbe, to holimize, formé par la contraction de “holistic optimization”.

Quand l’optimisation est cadrée autour de la mauvaise question

L’optimisation classique, dans sa forme la plus simple, part d’une posture très tentante:

“Dites-moi ce que vous souhaitez maximiser ou minimiser, énumérez les contraintes, et je trouverai la meilleure décision possible.”

Sur un tableau blanc, cela semble parfaitement raisonnable. Mais dans une supply chain, cela masque presque tout ce qui a réellement de l’importance.

Que sommes-nous exactement en train de “maximiser”? Le profit ce mois-ci? Sur un an? La croissance sur plusieurs années? La satisfaction client dans un sens difficilement mesurable? La résilience face aux perturbations? Un mélange de tout cela?

Quelles sont exactement les contraintes? Celles qui sont formelles, telles que la capacité et les délais, ou aussi celles non documentées, comme “cette équipe d’entrepôt ne peut réalistement gérer plus de 5,000 cartons entrants par jour” ou “cette machine ne peut être réinitialisée deux fois dans la même semaine”?

Et comment devrions-nous mesurer le préjudice? Une rupture de stock est-elle pire qu’une opération de déstockage? À quel point, en termes monétaires, et pour quels produits?

Lorsque nous déployons un moteur d’optimisation classique au sein d’une supply chain, nous sommes obligés de répondre à ces questions en les encodant—explicitement ou implicitement—dans une fonction objectif et un ensemble de contraintes. Une fois cela fait, le solveur trouvera effectivement des décisions “optimales” par rapport à cet encodage. Malheureusement, si l’encodage est même légèrement désaligné avec la réalité, nous obtenons simplement de mauvaises décisions, et ce, plus rapidement.

J’ai vu de nombreuses variantes de cette histoire. Un détaillant déploie un nouveau système de réapprovisionnement qui maximise fièrement le “taux de service” sous réserve des coûts de stocks et de logistique. Les ruptures de stocks diminuent sur le papier, mais les magasins se retrouvent avec trop de tailles et de couleurs lentes à tourner que les clients ne veulent pas. Un fabricant installe un système de planification avancé qui optimise les plannings de production selon un modèle simplifié de capacité; le plan résultant semble élégant dans l’interface, mais l’usine passe son temps à improviser des solutions de contournement parce que le modèle n’a jamais capturé les goulots d’étranglement critiques sur le plancher.

Dans chacun de ces cas, l’optimisation elle-même fonctionne. L’ordinateur fait exactement ce que nous lui avons demandé de faire. Le problème, c’est que nous avons posé la mauvaise question.

Nommer la discipline manquante

La notion que je souhaite introduire est la suivante:

Holimization (n.) – La discipline de l’optimisation holistique pour des systèmes complexes et évolutifs, où l’objet principal de conception est le cadre d’optimisation lui-même: les objectifs, les contraintes, la sémantique des données et la grammaire décisionnelle. Holimization traite l’optimisation comme un processus itératif et expérimental dans lequel la fonction objectif, le modèle et l’instrumentation co-évoluent sous l’effet de retours du monde réel.

To holimize (v.) – Orchestrer un tel processus: encadrer, doter d’instrumentation, optimiser, et refondre le système décisionnel de manière répétée afin qu’il reste aligné avec la réalité économique et l’intention organisationnelle.

L’optimisation, au sens strict, se concentre sur la boucle interne: étant donné un objectif fixe et une représentation figée du monde, trouver des décisions qui donnent une valeur extrême à cet objectif. Holimization se concentre sur la boucle externe: comment nous concevons cet objectif, comment nous représentons le monde, comment nous instrumentons le système, et comment tout cela évolue au fil du temps.

En d’autres termes, l’optimisation répond: “Qu’est-ce qui est optimal, en supposant que le monde soit ainsi?” Holimization demande: “Regardons-nous le monde de manière à ce que le ‘meilleur’ ait un sens?”

Ce n’est pas un point philosophique abstrait. Dans un environnement désordonné et en constante évolution, comme une supply chain, la question que nous optimisons change constamment sous nos pieds. Les marchés évoluent, les assortiments se modifient, les canaux apparaissent et disparaissent, les réglementations évoluent, et les priorités internes changent. Si notre cadre d’optimisation reste fixe alors que le monde évolue autour de lui, l’écart entre ce qui est “optimal” à l’écran et ce qui est sensé dans la réalité ne cesse de croître au fil du temps.

Holimization est le nom que je propose pour désigner la discipline consistant à traiter le cadre lui-même comme un objet de travail à part entière.

Ce que signifie to holimize une supply chain

Permettez-moi de rendre cela concret avec des exemples issus de la supply chain, car c’est là que j’ai passé la majeure partie de mon temps.

Imaginez un détaillant de mode qui souhaite “améliorer le service” dans ses magasins. Si nous prenons l’optimisation au sens étroit, nous pourrions commencer par définir le service comme la probabilité de ne pas être en rupture de stock lorsqu’un client entre, et nous pourrions fixer un objectif tel que “95% de taux de service”. Nous encoderions alors les ruptures de stocks comme un coût, les excès de stocks comme un autre coût, et laisserions un moteur d’optimisation équilibrer les deux.

Cela conduit à des décisions numériquement impeccables, mais esthétiquement étranges. Les magasins se retrouvent avec un nombre techniquement suffisant d’unités, pourtant la plupart se trouvent dans les mauvaises tailles ou toutes dans les mêmes couleurs sûres. Du point de vue du modèle, tout est en ordre: l’objectif de taux de service est atteint et les coûts restent dans les limites. Du point de vue du client qui entre dans le magasin, l’assortiment paraît sans vie.

Si nous to holimize plutôt, nous acceptons que le “service” n’est pas encore correctement formulé. Nous transformons le déploiement du système décisionnel en une expérience sur nos propres hypothèses.

Nous commençons par mettre en place une véritable recette de décision, alimentée par des données et l’optimisation, mais nous l’entourons d’une instrumentation conçue pour faire émerger des décisions “insensées”: des assortiments qu’aucun acheteur humain n’hésiterait à juger comme dommageables, même si le système n’est pas encore capable d’expliquer pourquoi. Nous surveillons les magasins où le modèle insiste pour envoyer un mélange invraisemblable de tailles et de gemmes d’articles en déstockage. Nous écoutons attentivement les planificateurs qui se plaignent que le système prive certains magasins de variété.

Chaque fois que nous rencontrons une telle absurdité, nous en remontons la cause. Peut-être que notre fonction objectif n’a aucun moyen de récompenser la diversité de l’assortiment, se concentrant uniquement sur la disponibilité des unités. Peut-être n’avons-nous jamais capturé la limite pratique concernant la fréquence à laquelle un magasin peut être réapprovisionné. Peut-être que nos données historiques cachent des effets de substitution qui rendent certaines ruptures de stock beaucoup moins préjudiciables que d’autres.

Nous modifions alors le cadre. Nous introduisons une notion quantifiée de diversité dans l’objectif, avec une valeur financière qui y est associée. Nous remplaçons une contrainte stricte par un coût, ou inversement. Nous ajoutons une nouvelle catégorie de décisions à la recette, par exemple pour déterminer quand rafraîchir une vitrine ou comment échelonner les livraisons pour des magasins fragiles. Nous étendons l’instrumentation afin de visualiser ces nouveaux aspects, de sorte que la prochaine vague d’absurdité, si elle survient, soit plus facile à diagnostiquer.

Nous avons holimizé la situation: au lieu de blâmer le solveur ou d’ignorer le système, nous avons utilisé les échecs mêmes des décisions comme des signaux indiquant que notre cadre était incomplet et devait évoluer.

Une histoire similaire se déroule dans les opérations de maintenance et de réparation. Supposons que vous gériez des pièces de rechange pour moteurs d’avion. L’approche d’optimisation naïve consiste à traiter chaque pièce indépendamment: estimer la fréquence à laquelle elle sera nécessaire, attribuer un coût aux ruptures de stocks et un coût au maintien des stocks, et laisser la machine déterminer le meilleur seuil de réapprovisionnement.

En pratique, ce n’est pas ainsi que les moteurs sont réparés. Le véritable préjudice survient lorsqu’une réparation est retardée parce qu’une pièce critique manque, même si vous êtes submergé par un excès de stocks de dizaines d’autres pièces. Le coût n’est pas simplement une rupture de stock dans un tableau; ce sont des jours d’immobilisation pour un avion.

Holimization nous oblige à reformuler l’objectif autour de quelque chose de plus proche de la réalité: par exemple, la réduction du nombre de jours de retard attendus par moteur et par unité de budget. Cela nous pousse à doter le processus d’une instrumentation permettant de visualiser clairement quelles pièces sont, de façon répétée, responsables du blocage des réparations. Lorsque le système suggère de stocker une grande quantité d’une pièce qui n’entrave jamais réellement les réparations, c’est un signal d’absurdité. Lorsqu’il prive une pièce qui retarde systématiquement les moteurs, c’est un autre signal.

Nous ne considérons pas ces échecs comme des bogues embarrassants à dissimuler. Nous les considérons comme notre meilleure source d’information sur les lacunes de notre cadre. Puis nous ajustons notre méthode de mesure du préjudice, les liens entre les événements et les coûts, ainsi que la manière dont nous structurons les décisions, afin que les optimisations futures soient menées dans un espace plus fidèle à la réalité.

Holimization, donc, ne consiste pas à se débarrasser de l’optimisation. Il s’agit d’entourer l’optimisation d’une pratique disciplinée d’apprentissage à partir de ses erreurs.

Le travail caché autour du moteur d’optimisation

Si vous entrez dans une grande entreprise qui “fait de l’optimisation”, la majeure partie des efforts que vous constaterez ne concerne pas la conception d’algorithmes. Il s’agit de donner du sens aux données, de gérer les exceptions, et de réconcilier ce que le système dit avec ce que la réalité permet.

Holimization rend ce travail caché explicite et structuré.

Une grande partie de la difficulté réside dans la sémantique des données. Les systèmes opérationnels contiennent un nombre déconcertant de champs, de codes et de bizarreries historiques. Lorsqu’un moteur de décision prend ces données pour argent comptant, il finit inévitablement par en interpréter certaines de manière incorrecte. Une limite qui avait autrefois du sens pourrait être devenue obsolète. Un champ qui semble représenter le “lead time” peut en réalité être un mélange de délais de transit et de délais administratifs. Un indicateur qui ressemble à “on promotion” peut être utilisé de manière incohérente selon les régions.

Sans une mentalité holimization, ces problèmes sont découverts par accident, souvent après que des dégâts ont été causés. Avec holimization, nous partons du principe dès le départ que notre interprétation des données est provisoire. Nous construisons des tests, des comparaisons et des vérifications de cohérence qui tentent de réfuter notre lecture des données. Lorsque le système propose une décision qui surchargerait un quai, nous ne la considérons pas comme de la “malchance”; nous y voyons la preuve qu’une contrainte manque dans notre vision du monde.

Un autre composant important est l’instrumentation. Un moteur d’optimisation, à lui seul, est aveugle: il prend des données, émet des décisions, et n’a aucune opinion sur le fait que ces décisions soient sensées ou non. Holimization requiert une couche de visibilité conçue non seulement pour suivre les indicateurs de performance clés, mais aussi pour mettre en évidence les endroits où le système se comporte de manière absurde aux yeux des humains.

Cela peut prendre de nombreuses formes: des vues de retour dans le temps qui nous permettent de rejouer des décisions avec les données passées; des microscopes sur un produit ou un site particulier, montrant comment la décision a évolué au fil du temps; des tableaux de bord qui mettent en évidence les valeurs aberrantes plutôt que les moyennes. Le but est toujours le même: transformer les variables “insensées” en un canal de rétroaction structuré, et non en une source de frustration.

Enfin, il y a la rapidité et la sûreté de l’itération. Holimization est par nature expérimental. Nous devons essayer de nouveaux cadres et objectifs révisés sans mettre l’ensemble de l’entreprise en danger à chaque fois. Cela implique des capacités techniques—gestion des versions des recettes de décision, déploiements contrôlés, modes d’ombre—mais aussi des capacités organisationnelles: des responsabilités claires, une culture qui accepte les expériences comme nécessaires, et une direction qui comprend la différence entre une règle de production stable et un test exploratoire.

Tout cela représente du travail. C’est, cependant, un travail que nous effectuons déjà de manière informelle chaque fois que nous nous plaignons que “le système ne comprend pas”. Holimization est une tentative de donner à ce travail un nom et une méthode appropriés.

Pourquoi un nouveau mot est important

On pourrait légitimement se demander: pourquoi inventer un nouveau terme? Pourquoi ne pas simplement parler de “bonne pratique d’optimisation” ou de “modélisation expérimentale”?

Mon expérience montre que, sans un nom distinct, la boucle externe se fait engloutir par la boucle interne. Une fois le mot “optimisation” évoqué, l’attention se porte sur les algorithmes, les solveurs, et les indicateurs de performance. La conversation se déplace vers la question de savoir si une méthode particulière converge plus rapidement ou s’adapte mieux, et s’éloigne de la question plus inconfortable de savoir si nous optimisons réellement la bonne chose.

En revanche, “holimization” porte en elle-même le rappel que l’optimisation n’est qu’un ingrédient d’une discipline plus large. Cela signifie que nous nous soucions de l’ensemble du parcours, de la réalité aux données, à la décision, et retour à la réalité. Cela suggère que notre artefact principal n’est pas le solveur, mais le cadre évolutif dans lequel celui-ci opère.

Pour ma propre entreprise, Lokad, ce nom clarifie également ce que nous essayons de construire. Nous ne sommes pas, fondamentalement, un fournisseur d’un moteur d’optimisation de plus. Nous cherchons à fournir une plateforme où les entreprises peuvent holimize leurs supply chains: un lieu où les données peuvent être remaniées, où les objectifs peuvent être exprimés en termes financiers, où les décisions peuvent être automatisées tout en restant intelligibles, et où chaque échec du système est traité comme une opportunité d’apprentissage précieuse sur la manière dont le cadre devrait évoluer.

Le mot est nouveau, mais le besoin qu’il exprime ne l’est pas. Les supply chains, ainsi que de nombreux autres systèmes complexes, se holimisent silencieusement depuis des années à travers l’expérimentation, des correctifs sur tableurs et des réunions interminables. J’espère qu’en donnant à ce processus un nom et une forme plus claire, nous pourrons le rendre plus délibéré, plus rigoureux, et en fin de compte, plus efficace.

L’optimisation, tout comme les mathématiques, ne va pas disparaître ; au contraire, elle continuera de s’améliorer. La holimization est l’invitation à monter d’un cran, à traiter nos modèles, objectifs et contraintes non pas comme sacrés, mais comme des hypothèses à tester face au monde. Ce n’est qu’alors que « optimal » cessera d’être une étiquette formelle dans un rapport et commencera à ressembler aux décisions que nous souhaitons réellement sur le terrain.