00:00:03 Introduction à la modularisation en IT et supply chains.
00:00:26 Modularité de la supply chain physique.
00:02:31 Structures monolithiques des premiers systèmes informatiques.
00:04:08 Contexte informatique des systèmes monolithiques.
00:05:31 Impact d’Internet sur la conception modulaire des logiciels.
00:08:02 Problèmes dans les systèmes logiciels monolithiques.
00:08:48 Inefficacités des systèmes monolithiques.
00:11:16 Transition vers des systèmes modulaires : exemples.
00:13:34 Défaillances système dans des applications modulaires.
00:14:34 Redondance, disponibilité dans les systèmes modulaires.
00:16:00 Fiabilité des grands systèmes, échecs de projets logiciels.
00:16:50 Exemple de la transition logicielle ratée de Lidl.
00:18:09 Concept de “fail fast” dans les projets logiciels.
00:19:30 Gestion des chevauchements, importance du logiciel “colle”.
00:22:46 Éviter les catastrophes logicielles.
Résumé
Dans l’épisode de Lokad TV, Joannes Vermorel, le fondateur de Lokad, discute de l’importance de la modularisation dans l’infrastructure informatique des entreprises, en établissant un parallèle avec l’adaptabilité des supply chains. Il fait référence aux systèmes informatiques monolithiques des années 70 et 80, caractérisés par leur inflexibilité due aux limitations technologiques. Même avec la transition vers des systèmes en réseau à la suite de l’émergence d’Internet, il souligne le défi permanent pour les entreprises de modulariser leurs systèmes informatiques. Vermorel propose l’architecture orientée services (SOA) comme solution potentielle, insistant sur la nécessité de services plus petits et bien définis. Il met en garde contre l’entrepreneuriat de projets à grande échelle et préconise une approche “fail fast”, soulignant l’importance cruciale de la gestion des risques et de la récupération rapide en cas d’échecs.
Résumé Étendu
Dans l’épisode actuel de Lokad TV, l’animateur Kieran Chandler engage la conversation avec Joannes Vermorel, le fondateur de Lokad, au sujet de la modularisation dans l’infrastructure informatique des entreprises. Vermorel décrit le concept de modularisation, établissant des parallèles principalement avec les supply chains dans le monde physique, qu’il considère comme les créations les plus modulaires de l’humanité.
Il utilise les exemples de camions, palettes, et conteneurs pour clarifier ses propos sur la modularité. Vermorel souligne la modularité inhérente des supply chains physiques en notant l’applicabilité universelle des codes-barres, qui peuvent être apposés sur pratiquement n’importe quoi.
Bien que les supply chains physiques présentent une modularité évidente, Vermorel observe que les infrastructures informatiques des entreprises manquent souvent de flexibilité semblable. Il remet en cause ce manque de modularité en le ramenant aux premières étapes du développement informatique au sein des entreprises dans les années 1970 et 1980, lorsque les premières implémentations informatiques et les systèmes ERP étaient conçus comme des structures autonomes et monolithiques en raison des limitations technologiques de l’époque.
Vermorel identifie un “monolithe” en termes informatiques comme une application unifiée qui ne peut pas être décomposée en parties plus petites. Il explique comment cette approche monolithique contraste avec la modularité observée dans les supply chains physiques, où divers composants peuvent être combinés ou séparés selon les besoins.
Malgré leur complexité, Vermorel explique que les premiers mainframes étaient intrinsèquement cohérents car ils fonctionnaient comme une unité unique avec toutes les opérations centralisées. Il note que cette forme de conception des systèmes semble démodée pour la génération actuelle, habituée aux systèmes distribués et aux applications basées sur le réseau, marquant un changement significatif dans le développement de l’infrastructure informatique au fil des ans.
Vermorel souligne que le paysage a commencé à changer avec l’avènement d’Internet à la fin des années 90, conduisant à la conception de logiciels avec des parties isolées reliées par un réseau. Cependant, il remarque que de nombreuses entreprises éprouvent encore des difficultés à modulariser, malgré que la valeur des systèmes informatiques extrêmement modulaires soit bien comprise en théorie.
Il explique comment de nombreux fournisseurs ont adapté ces anciennes architectures monolithiques au cloud et aux modèles Software as a Service (SaaS), aboutissant à des systèmes qui offrent une maintenance améliorée mais qui n’améliorent pas la modularité. Il affirme que ce manque de modularité empêche les entreprises d’isoler et de modifier des fonctionnalités spécifiques.
Pour remédier à ce problème, Vermorel propose une architecture orientée services (SOA), une approche qui décompose les capacités en petits “chunks” bien définis. Il cite Amazon comme exemple d’une entreprise ayant adopté avec succès cette approche modulaire dès le début.
Il préconise une architecture orientée services avec des APIs qui permettent d’exporter et d’exploiter les données à travers les différentes divisions d’une entreprise. Malgré la reconnaissance qu’une approche décentralisée présente potentiellement plus de points de défaillance comparée à un système monolithique, Vermorel soutient que ces défis peuvent être atténués grâce à la redondance et à une ingénierie de haute qualité.
Vermorel estime qu’entre un tiers et la moitié de tous les projets informatiques supply chain échouent. Il se réfère au cas de Lidl en Allemagne, qui a perdu un demi-milliard d’euros lors d’une transition SAP ratée. Il affirme que la transition de petits fournisseurs à de grands fournisseurs ne réduit que légèrement les taux d’échec, sans les éliminer.
En ce qui concerne la gestion de plusieurs applications, Vermorel suggère de choisir des applications à périmètre restreint afin de minimiser les chevauchements et déconseille l’achat de grands frameworks auprès des fournisseurs. Pour gérer efficacement plusieurs applications, il conseille aux entreprises de développer leur propre “colle” interne qui lie ces applications entre elles, facilitée par une architecture orientée services.
Enfin, Vermorel partage des conseils sur la manière de prévenir des catastrophes telles que la transition SAP ratée de Lidl. Il insiste sur la nécessité de penser en termes de gestion des risques et d’adopter une approche “fail fast”. Il déconseille l’optimisme irréaliste en gestion de projets et souligne l’importance de prévoir d’éventuelles défaillances et de trouver des moyens de récupérer rapidement.
Transcription Complète
Kieran Chandler : Bonjour et bienvenue dans un nouvel épisode de Lokad TV. Cette semaine, nous allons discuter de la modularisation, le processus consistant à subdiviser les processus informatiques de notre entreprise, passant d’un système autonome à plusieurs sous-programmes voire applications. Comme toujours, je suis accompagné de Joannes Vermorel. Alors, Joannes, de quelle partie des processus de l’entreprise parlons-nous de rendre plus modulaires aujourd’hui ?
Joannes Vermorel : Aujourd’hui, nous nous concentrons particulièrement sur l’infrastructure IT et le paysage applicatif de votre entreprise. La modularisation est intéressante. Quand on pense au monde physique, il est évident que les supply chains sont incroyablement modulaires. Ce sont probablement les choses les plus modulaires jamais inventées par l’humanité. Par modular, j’entends que si vous voulez transporter des marchandises par la route, vous pouvez utiliser des camions. Les camions sont incroyablement modulaires car vous pouvez y mettre pratiquement n’importe quoi qui ne dépasse pas la capacité d’un camion, et un camion peut circuler sur n’importe quelle route, allant de n’importe où à n’importe où. Si vous avez besoin de camions supplémentaires, vous pouvez pratiquement utiliser n’importe quel type de camion, presque, et ils peuvent ajouter une capacité de transport à votre supply chain.
La même chose s’applique aux palettes et aux conteneurs. Vous pouvez mettre presque n’importe quoi sur une palette ou dans un conteneur tant que cela ne dépasse pas la capacité. Un conteneur est extrêmement modulaire. Vous pouvez le transférer d’un cargo à un camion. Tous ces éléments sont incroyablement modulaires. Vous pouvez apposer un code-barres sur pratiquement n’importe quoi qui n’est pas trop petit. C’est une invention incroyablement moderne. Si vous avez quelque chose comme un diamant, vous le mettriez probablement dans une boîte, puis vous apposeriez le code-barres sur le dessus de la boîte. Vous pouvez combiner tous ces éléments simples à volonté, presque à l’infini. C’est très semblable à des Lego ; des pièces simples que vous pouvez combiner de manières incroyablement variées. Voilà la supply chain physique, qui est incroyablement modulaire.
Cependant, l’intérêt est que lorsque vous passez au domaine informatique, nous entrons dans une perspective complètement différente et où la modularisation est fréquemment perdue. Je pense que l’origine de cela remonte aux débuts des années 70 ou 80, lorsque les entreprises ont commencé à disposer de leurs premiers systèmes informatiques et de leurs premières implémentations ERP.
Kieran Chandler : Donc, ce que tu dis, c’est que ces premières implémentations, ces premiers systèmes informatiques, parce qu’ils étaient en quelque sorte conçus de manière unique, c’est toujours ce que nous utilisons aujourd’hui. C’est bien ce que tu dis ?
Joannes Vermorel : Oui, en effet. Quand on repense à l’informatique ou aux logiciels des années 70, 80 ou même du début des années 90, faire quoi que ce soit via le réseau était de la science-fusée. C’était possible, mais c’était un cauchemar d’ingénierie. Il était beaucoup plus simple de dire : nous prenons une grosse machine, idéalement un mainframe IBM de l’époque, et nous mettons toute votre logique sur cette machine. Ensuite, tout le monde utilise un terminal connecté à cette machine, et toute la logique s’exécute dans un monolithe sur cette machine.
Kieran Chandler : Que veux-tu dire par monolithe ?
Joannes Vermorel : Par monolithe, j’entends qu’il s’agit d’une application qui est un tout. Elle ne peut pas être démontée. Elle doit rester unie, sinon ce n’est rien.
Kieran Chandler : Je crains d’être un peu millennial, donc ce genre d’idée me précède peut-être un peu. Mais en gros, ce que tu dis, c’est que tout est connecté à une seule machine, n’est-ce pas ? Et ensuite, nous nous connectons tous et travaillons tous à partir de là ?
Joannes Vermorel : Exactement. Les mainframes étaient des appareils matérielles relativement complexes, donc même si c’était une seule machine.
Kieran Chandler : Nous parlons principalement d’ERPs, c’est-à-dire des systèmes de gestion des ressources d’entreprise. Ces systèmes sont généralement conçus pour être extensibles, permettant l’ajout de capacités et de fonctionnalités supplémentaires. Cependant, ils ne sont pas modulaires, ce qui signifie que vous ne pouvez pas séparer ces capacités pour les garder entièrement isolées.
Joannes Vermorel : Le point intéressant est que ce qui a vraiment changé, c’est probablement Internet. Je ne fais pas référence à l’invention même d’Internet, mais au fait qu’à la fin des années 90, avec la popularisation d’Internet, les gens ont commencé à penser à la manière de concevoir des logiciels afin de prendre les parties isolées, avec le réseau au milieu. De cette manière, le flux de travail n’est plus un cauchemar d’ingénierie. Avant cela, si vous ne saviez pas comment construire un système logiciel complexe composé de nombreuses parties, avoir un réseau au milieu était un cauchemar d’ingénierie. Ce savoir-faire, cette culture et ces outils ont principalement émergé comme sous-produit de l’adoption d’Internet par le grand public.
Kieran Chandler : Internet existe depuis longtemps maintenant, alors pourquoi parlons-nous encore de modularisation ? Pourquoi ces logiciels continuent-ils d’agir de manière aussi unique ?
Joannes Vermorel : En ce moment, mon diagnostic est que lorsqu’on prend l’entreprise moyenne qui exploite une supply chain complexe ou une multinationale avec de nombreux sites, tout ce qui est physique est incroyablement modulaire. Cependant, quand il s’agit de l’IT, c’est complètement monolithique. Je crois que les entreprises et le marché en général ont encore du mal à apprécier la valeur d’avoir quelque chose d’extrêmement modulaire en termes d’informatique. Physiquement, c’est assez évident, et les supply chains continuent d’améliorer leur modularité. Cependant, en termes de paysage applicatif, c’est plus abstrait, il est plus difficile de percevoir la modularité en tant que telle. De nombreux fournisseurs ont repris d’anciennes architectures monolithiques, les ont légèrement mises à jour vers le SaaS et le cloud, mais se sont contentés de copier-coller. C’est fondamentalement le même type d’architecture que l’on trouvait dans un mainframe IBM des années 90, où l’on décidait qu’au lieu de disposer d’une machine au siège de l’entreprise qui exécute le système, vous la déléguez à un fournisseur de logiciels qui fonctionne en tant que SaaS. Mais si le fournisseur SaaS ne dispose que d’un monolithe qu’il exécute sur une machine éloignée du siège de votre entreprise, avec juste un peu de réseau et une interface utilisateur web au milieu, cela n’apporte rien en termes de modernisation. Cela rend simplement la maintenance plus facile. Mais lorsque vous voulez dissocier les fonctionnalités, vous vous retrouvez toujours face à un monolithe où ce type de capacité ne peut pas se produire.
Kieran Chandler : Quel est le problème avec cette approche monolithique ? Comment cela affecte-t-il les entreprises dans le monde réel ?
Joannes Vermorel : Imaginez simplement l’équivalent physique d’un manque de modularisation. Imaginez que dans votre supply chain, chaque fois que vous souhaitez changer un camion, vous devez tous les changer. Par exemple, si vous passez d’un camion à un autre, vous avez besoin d’un type d’essence différent. Ainsi, toutes vos stations-service devraient être modifiées, ce qui signifie que vous auriez des réservoirs contenant du gaz nécessitant un second type d’essence. Ce serait immense. La douleur, voyez-vous, est comparable à la situation dans les logiciels. Quand on manque de modernisation, c’est comme si l’on changeait une partie, il faut changer toutes les autres. Si vous changez un camion, vous devez changer toute votre flotte. Imaginez si vous modifiez les étagères d’un entrepôt et que vous devez modifier toutes les étagères de tous les autres entrepôts, sinon, elles ne seraient pas compatibles. Puis vous réalisez, d’accord, peut-être puis-je décider de moderniser ma flotte de camions vers des camions électriques, mais ce serait un mouvement stratégique massif et très compliqué. Vous préféreriez tout de même avoir quelque chose de relativement modulaire où vous pouvez faire coexister harmonieusement des camions électriques et des camions à combustion pendant une longue période. Quand on manque de modernisation, cela signifie que vous ne pouvez pas changer certaines parties de votre supply chain sans tout changer.
L’évidence anecdotique la plus fréquente de ce manque de modernisation est que, pour qu’une entreprise passe d’un entrepôt à un autre physiquement, cela pourrait se faire en une journée en déplaçant simplement les marchandises qui se trouvent dans l’entrepôt A vers les étagères de l’entrepôt B. Mais migrer le logiciel qui était connecté à l’entrepôt A pour que tout sache que toutes les marchandises se trouvent dans le système qui gère l’entrepôt B, cela prendrait environ six mois.
Kieran Chandler: C’est intéressant. Comment les grandes entreprises font-elles cela si elles existent sur ce type de système monolithique ? Comment migrent-elles vers un système plus modulaire ?
Joannes Vermorel: Je pense que nous allons revenir sur l’une des entreprises que nous avons mentionnées dans quasiment chaque épisode, comme Amazon. Ce n’est pas la seule à avoir adopté une approche extrêmement modulaire. En Allemagne, Zalando, que vous pouvez suivre sur les blogs, a également complètement adopté une approche très modulaire, et le mot-clé en informatique pour cela, lorsque vous souhaitez avoir cette modularité, est probablement l’architecture orientée services, SOA.
Une architecture orientée services signifie essentiellement que vous souhaitez isoler des capacités en blocs qui sont, elles-mêmes, comme de petits monolithes, mais bien plus petits, et qui sont très bien définis pour faire une chose et la faire bien. Et vous branchez toutes ces choses ensemble via votre architecture orientée services, ce qui signifie que chaque service, dans le sens où c’est une application qui fait une seule chose et la fait bien, expose des API afin qu’il puisse être intégré très facilement dans votre paysage applicatif. Il est conçu pour être facilement intégrable, de manière programmatique, dans n’importe quel paysage applicatif arbitraire, sans faire presque aucune hypothèse sur ce que sont les autres parties du paysage applicatif.
Jeff Bezos d’Amazon a publié une note très célèbre, je crois en 2002, dans laquelle il déclarait à toutes ses équipes que chaque division devait avoir une architecture orientée services avec des API, afin que les données que vous avez dans votre silo puissent être exportées pour être exploitées dans n’importe quelle autre division de l’entreprise et que nous puissions interagir de manière programmatique avec ce que vous construisez.
Kieran Chandler: Le problème que je vois avec cela, c’est que vous devenez dépendant de beaucoup de petites applications, de petits programmes, et finalement de petites entreprises. N’introduit-il pas beaucoup plus de points de défaillance uniques ? Alors que si vous adoptez une approche plus monolithique, vous avez une grande entreprise solide, un grand système ERP qui fonctionnera toujours et vous avez plus de confiance en lui.
Joannes Vermorel: C’est vrai, et dans une certaine mesure, c’est l’un des défis d’un système distribué. Si votre matériel tombe en panne 1 % du temps, cela signifie que si vous avez un mainframe.
Kieran Chandler: Vous avez mentionné que le logiciel peut tomber en panne trois fois par an. Si vous avez 10 applications, chacune ayant 1 % de risque d’être en panne un jour donné, cela signifie qu’environ tous les 10 jours, quelque chose est en panne dans votre réseau. C’est effectivement un défi. Quelles solutions suggéreriez-vous pour cette situation ?
Joannes Vermorel: La redondance est la première chose qui me vient à l’esprit, mais j’aimerais discuter des implications en termes d’informatique distribuée, et peut-être ensuite nous pourrons parler des petites entreprises contre les grandes et de la disparité chez les fournisseurs. Du point de vue de l’informatique distribuée, l’objectif est de veiller à ce que chaque bloc soit fortement redondant. C’est l’essence du cloud computing. Vous voulez avoir un logiciel hautement redondant afin que votre temps de disponibilité soit très élevé.
La bonne nouvelle, c’est que, parce que vos applications sont plus petites et plus simples, il est bien plus facile d’atteindre un très haut temps de disponibilité avec une petite application simple qu’avec une application très complexe. Il existe de nombreux services composants sur Internet qui sont littéralement toujours en fonctionnement. Par exemple, Google Mail est littéralement toujours disponible. Le site web de Yahoo est essentiellement toujours en ligne. Facebook est également toujours en ligne. Il est donc possible de concevoir ces propriétés « always-on » pour vos applications, ce qui garantit la fiabilité de l’ensemble de votre système.
Kieran Chandler: Qu’en est-il de la transition d’un grand fournisseur vers de nombreux petits fournisseurs ?
Joannes Vermorel: La réalité, c’est que les taux d’échec dans les logiciels sont élevés. Les gens ne réalisent pas que, peut-être, la moitié du temps, les initiatives logicielles échouent. Mon estimation serait qu’entre un tiers et la moitié de tous les projets IT de supply chain échouent pour des entreprises de pratiquement toutes tailles. Il y a quelques semaines, Lidl en Allemagne a dépensé environ un demi-milliard d’euros pour une transition SAP échouée. Ce fut un projet de sept ans qui s’est terminé par un échec, et ils ont finalement abandonné. Mais ce n’est pas le seul exemple ; cela se produit assez fréquemment.
Les grands fournisseurs ont probablement un meilleur taux de réussite, mais si nous parlons en termes d’estimations approximatives, nous passons d’un petit fournisseur avec un taux d’échec de 50 %, ce qui est assez mauvais, à un grand fournisseur avec un taux d’échec de 30 %. Ainsi, lorsque vous passez d’une petite à une grande entreprise, votre risque diminue légèrement, mais seulement un peu.
Si vous optez pour une approche très modulaire, oui, vous aurez de nombreux éléments qui échoueront, mais vous aurez l’opportunité d’essayer à nouveau et de répéter jusqu’à obtenir le succès. Chaque composant a une chance d’échouer, mais parce que le périmètre est plus simple et l’application elle-même plus petite, vous pouvez échouer rapidement et réessayer.
Le problème avec l’approche de Lidl, c’est que je suis à peu près sûr qu’ils n’avaient initialement pas prévu une migration de sept ans. C’était probablement une migration de deux ans qui s’est transformée en trois, puis en quatre, et ainsi de suite, parce qu’ils échouaient, recommençaient et rééchouaient. Sept ans plus tard, ils ont finalement décidé d’abandonner, probablement parce que tout le monde avait perdu tout espoir de voir le projet réussir.
Kieran Chandler: Donc, si nous convenons que ces applications, une fois que vous trouvez la bonne et peut-être que vous itérez un peu, peuvent être fiables… Elles semblent fonctionner et paraissent réaliser la même fonction qu’un système plus large. Qu’en est-il de l’interconnexion entre ces applications ? Car souvent, une application excelle dans autre chose et il peut y avoir un peu de recoupement et de conflit au sein de ce système. Comment gérez-vous cela ?
Joannes Vermorel: Tout d’abord, lorsque vous choisissez la composition de votre paysage applicatif, vous devez vraiment opter pour des applications qui ont une portée étroite. Cette approche va complètement à l’encontre de ce que font la plupart des Request for Proposals (RFP). Lorsque les entreprises cherchent à acquérir un logiciel, elles optent souvent pour un RFP et veulent tout – toutes les fonctionnalités, tous les gadgets. Mais c’est le contraire de ce que vous devriez rechercher. Vous voulez quelque chose d’extrêmement ciblé, de sorte qu’en concevant ainsi vous minimisez les chevauchements.
Si vous achetez de grands frameworks, c’est une recette pour avoir des chevauchements. Les fournisseurs d’entreprise sont intéressés à vous vendre de grands frameworks parce qu’ils peuvent les étendre avec de nombreuses fonctionnalités. Ils vous vendent quelque chose, puis ils vous vendront les modules complémentaires qui s’y ajoutent. Donc, je dirais aux personnes qui gèrent de grandes supply chains, soyez très prudents lorsque l’on vous propose une plateforme.
Une plateforme est bonne, mais deux plateformes peuvent être cauchemardesques. Dès que vous avez plusieurs fournisseurs qui vous vendent des plateformes, vous vous retrouvez avec une mer de chevauchements. La solution consiste à choisir soigneusement la composition de vos ingrédients.
En ce qui concerne la « colle », l’approche est que c’est généralement quelque chose que vous souhaitez développer en interne. Cela va peut-être à l’encontre de l’intuition de vouloir développer un quelconque logiciel en interne. La réponse est que, si vous êtes une entreprise d’une certaine taille, votre paysage applicatif est complètement unique pour vous.
Même si vous utilisez toutes les applications standards, vous aurez besoin de plusieurs applications. Il n’existe aucun ERP de nos jours qui puisse gérer les emails, la visioconférence et autres. Vous ne pouvez pas intégrer toutes les fonctionnalités logicielles dont vous avez besoin dans une seule application. Vous utiliserez probablement Microsoft Excel comme tout le monde, donc vous aurez besoin d’un endroit pour stocker des fichiers, etc.
Il n’est pas réaliste de dire que nous disposons d’un seul logiciel. Toute entreprise de taille significative sera, de toute façon, un ensemble de logiciels. La recette exacte, c’est-à-dire la liste des logiciels qui fait littéralement fonctionner votre entreprise, sera de toute façon complètement unique pour vous. Aucune autre entreprise n’est organisée exactement comme la vôtre.
Kieran Chandler: C’est complètement unique, c’est votre ADN. Vous pouvez avoir cette colle que vous implémentez en interne. C’est tout l’intérêt de l’architecture orientée services, qui vise à rendre cette colle aussi simple et légère à mettre en œuvre, afin que vous puissiez disposer d’une équipe IT très légère avec des efforts minimaux pour concevoir ce logiciel sur mesure qui ne fait que coller les choses ensemble. Donc, pour conclure, si je suis PDG, comment puis-je éviter une autre catastrophe de type Lidl ?
Joannes Vermorel: Tout d’abord, je pense qu’il est essentiel de penser au risque plutôt que de chercher à le minimiser. La catastrophe de type Lidl était due au fait que les gens disaient, “Nous ne voulons prendre aucun risque”, et donc ils optaient pour le plus grand fournisseur possible et essayaient d’obtenir le produit qui faisait tout. Essentiellement, c’est l’approche où l’on veut quelque chose qui soit correct dès sa conception, et l’on veut déployer quelque chose qui rehausse l’ensemble de l’entreprise d’un seul coup. C’est le pire type d’approche en termes de gestion des risques.
Vous devez penser exactement le contraire, c’est-à-dire : “Comment puis-je avoir quelque chose qui échouera rapidement s’il doit échouer ?” Voyez, le problème avec le risque, c’est que lorsque vous avez ce projet massif, vous ne savez pas pendant longtemps si vous avez échoué ou non. Ce que vous voulez, c’est quelque chose de plus “fail fast”, où vous constatez rapidement l’échec, et cet échec se produit à petite échelle. Et si vous avez besoin d’un remplacement, vous disposez d’un périmètre gérable, et vous procédez ainsi par de nombreux petits morceaux.
Donc, considérez cela comme l’opposé de la prévention du risque. Je dis que passer d’un grand fournisseur à un petit fournisseur pourrait augmenter le risque d’une chance d’échec de 50 % à 50 %. Au final, si un taux d’échec de 30 % signifie que votre entreprise fait faillite ou que la supply chain s’arrête, ce n’est pas un risque que vous pouvez prendre. Il faut donc prévoir l’échec de toute manière.
Mon point de vue est que, parce qu’un degré élevé de risque est inévitable, optez directement pour un plan d’échec. Essayez d’avoir des échecs petits, rapides et bien délimités afin de pouvoir itérer, plutôt que de dire que nous allons tout faire correctement du premier coup, ce qui relève d’un vœu pieux. Ensuite, embarquez dans un voyage qui peut probablement durer sept ans, pour finalement perdre un demi-milliard d’euros dans le processus. C’est le genre de vœu pieux en gestion de projet.
Kieran Chandler: Super, ça me plaît. Le conseil Lokad du jour : If you’re going to fail, fail fast. Brilliant. Donc, c’est tout pour cette semaine. Nous serons de retour la semaine prochaine avec un nouvel épisode. D’ici là, merci de nous avoir regardés.
