00:00:07 Importance de la conception logicielle dans les supply chains modernes.
00:01:22 Problèmes courants de conception logicielle dans la gestion de la supply chain.
00:02:37 Défis des systèmes logiciels en temps réel dans les supply chains.
00:04:55 Comment des opérations complexes peuvent impacter les systèmes en temps réel.
00:07:13 Les systèmes en temps réel obstrués par des opérations non en temps réel.
00:09:13 Importance des choix de conception et de l’échelle temporelle dans les logiciels de supply chain.
00:12:31 Différences entre les logiciels single-tenant et multi-tenant.
00:14:11 Défis liés aux multiples versions de logiciels dans des applications single-tenant.
00:15:33 Avantages des logiciels multi-tenant et la transition vers les modèles SaaS.
00:17:56 Importance de comprendre les hypothèses fondamentales dans la conception logicielle pour les praticiens de la supply chain.
00:19:18 Hypothèses fondamentales de conception de Lokad, incluant le mode de traitement par lots et la multi-tenance.
00:21:35 Réflexions finales sur la compréhension des choix en matière de logiciels et leur impact sur les opérations futures.
00:23:36 Pensées de clôture.
Résumé
Dans une interview avec Joannes Vermorel, fondateur de Lokad, l’impact de la conception logicielle sur l’optimisation de la supply chain est abordé. Les défis proviennent souvent de problèmes de conception plutôt que de bugs ou de crashs, ce qui peut rendre le logiciel lent, peu intuitif et difficile à configurer. La gestion des données en temps réel est une caractéristique clé pouvant impacter les opérations. Cependant, se concentrer sur des opérations rapides et simples peut entraver des processus complexes tels que la prévision ou les analyses à l’échelle du réseau. Il est crucial de comprendre les hypothèses de conception logicielle pour éviter que des problèmes n’apparaissent en raison d’un décalage entre la conception du logiciel et l’utilisation prévue par l’entreprise.
Résumé Étendu
Dans cette interview, l’animateur Kieran Chandler discute avec Joannes Vermorel, le fondateur de Lokad, de l’impact de la conception logicielle sur les opérations de l’entreprise, en particulier dans le contexte de l’optimisation de la supply chain. Vermorel souligne l’importance de la conception logicielle dans les supply chains modernes, qui reposent sur plusieurs couches de logiciels, tels que les ERP, MRP, WMS, OMS, et EDI, pour fonctionner efficacement.
Les défis auxquels sont confrontés les clients de Lokad proviennent souvent de problèmes liés à la conception de leur logiciel, plutôt que de bugs ou de crashs évidents. Ces problèmes de conception peuvent rendre le logiciel lent, peu intuitif et difficile à configurer. Comme l’explique Vermorel, ces problèmes résultent souvent d’un décalage entre les décisions de conception fondamentales prises pour le logiciel et la réalité effective de la supply chain qu’il est censé servir.
L’une des caractéristiques clés de l’architecture logicielle pouvant impacter les opérations de supply chain est sa capacité à gérer les données en temps réel. Vermorel souligne que, bien que le traitement véritable des données en temps réel ne soit pas possible en raison de la vitesse finie de la lumière, de nombreux systèmes de supply chain sont conçus pour se rapprocher du traitement en temps réel. Par exemple, lorsqu’un article est prélevé d’une étagère, le logiciel décrémente immédiatement le niveau de stock. Cette approche en temps réel peut toutefois avoir des conséquences inattendues.
Lorsque le logiciel est conçu pour des opérations rapides et simples, il devient difficile d’exécuter des opérations plus complexes, telles que la prévision ou les analyses à l’échelle du réseau. Ces opérations complexes nécessitent un niveau de traitement des données plus sophistiqué, qui peut ne pas être réalisable au sein d’un système optimisé pour des mises à jour en temps réel et à petite échelle.
Joannes Vermorel souligne l’importance cruciale de la conception logicielle dans l’optimisation de la supply chain. Les défis auxquels sont confrontés les clients de Lokad découlent souvent de problèmes de conception qui rendent le logiciel lent, peu intuitif et difficile à configurer, résultant d’un décalage entre les décisions de conception fondamentales du logiciel et la réalité effective de la supply chain. La capacité à gérer les données en temps réel est l’une des caractéristiques clés de l’architecture logicielle pouvant impacter les opérations de supply chain. Cependant, lorsque le logiciel est conçu pour des opérations rapides et simples, il devient difficile d’exécuter des opérations plus complexes, telles que la prévision ou les analyses à l’échelle du réseau, qui nécessitent un niveau de traitement des données plus sophistiqué.
Vermorel explique que les problèmes rencontrés par les praticiens de la supply chain utilisant de tels logiciels ne sont pas toujours évidents, car ils se manifestent souvent par une accumulation lente de problèmes, qu’il qualifie de « mort par mille coupures ».
Un problème clé est le besoin d’une fonctionnalité en temps réel dans certains scénarios, tels que le scan d’articles sur un tapis roulant à grande vitesse. Lorsque des opérations non en temps réel sont introduites dans le système, la performance globale peut être affectée négativement, entraînant des ralentissements et des retards. Cela peut accroître la frustration des utilisateurs et réduire l’efficacité.
Vermorel souligne l’importance de faire les bons choix de conception fondamentaux, qui doivent être étroitement alignés avec les problèmes que le logiciel essaie de résoudre. Dans le contexte des logiciels de supply chain, diverses hypothèses fondamentales sont faites, et si elles ne sont pas respectées, des problèmes peuvent survenir par la suite.
L’échelle temporelle sur laquelle le logiciel opère est une considération cruciale. Vermorel décrit les différents types de logiciels nécessaires pour diverses échelles temporelles, allant de temps de réponse sub-millisecondes pour entraîner des tapis roulants, à une planification à plus long terme impliquant des décisions de placement d’usine s’étalant sur des années, voire des décennies. Chaque augmentation d’un ordre de grandeur dans l’échelle temporelle nécessite un type de logiciel différent avec des capacités uniques.
Chez Lokad, l’accent est typiquement mis sur des échelles temporelles allant d’un jour à un an, ce qui requiert une approche différente de la conception logicielle. Vermorel évoque également les différences entre les logiciels single-tenant et multi-tenant, une considération cruciale pour les développeurs logiciels, bien que moins connue de la plupart des entreprises.
Ils discutent des différences entre les logiciels multi-tenant et single-tenant, des avantages du modèle SaaS, et des hypothèses fondamentales qui ont guidé la conception logicielle de Lokad.
Vermorel explique que les logiciels multi-tenant servent plusieurs clients en utilisant le même logiciel, tandis que les logiciels single-tenant impliquent de fournir à chaque client leur propre version personnalisée. Lokad est multi-tenant, avec une base de code mise à jour chaque semaine. Cette approche présente plusieurs avantages, notamment un versionnage simplifié et moins de problèmes de sécurité. Vermorel établit un contraste avec les logiciels single-tenant, qui permettent une personnalisation par client mais nécessitent la gestion de multiples versions, ce qui engendre des défis opérationnels.
Il observe que, au cours de la dernière décennie, de nombreuses entreprises de logiciels sérieuses se sont orientées vers la multi-tenance. Pour les applications web comme Lokad, être multi-tenant est relativement simple, mais pour les logiciels qui fonctionnent sur des machines clientes, cela peut être plus compliqué. Une solution à ce problème est la stratégie “evergreen”, illustrée par Google Chrome et Microsoft Office 365. Ces applications se mettent à jour automatiquement, sans intervention de l’utilisateur, ce qui atténue les problèmes liés à la présence de multiples versions du même logiciel.
Lorsqu’il aborde la conception logicielle de Lokad, Vermorel souligne l’importance de comprendre les hypothèses fondamentales d’un fournisseur. Il met en garde contre les fournisseurs qui prétendent que leur logiciel peut tout faire et insiste sur le fait que la conception repose sur des compromis, comportant à la fois des aspects positifs et négatifs. Il encourage les clients potentiels à interroger les fournisseurs de logiciels sur leurs hypothèses fondamentales, et à se méfier de ceux qui ne fournissent que des réponses vagues et positives.
Les hypothèses fondamentales de conception de Lokad incluent le mode de traitement par lots, que Vermorel explique être choisi parce qu’il permet une meilleure optimisation et une gestion des ressources.
Un principe clé est de privilégier des calculs intelligents plutôt que la vitesse. Lokad préfère disposer de calculs précis et détaillés même si cela prend plus de temps, par opposition à des calculs rapides mais moins précis. Le logiciel est conçu pour le traitement par lots plutôt qu’en temps réel, permettant une plus grande expressivité et une puissance accrue dans l’analyse.
Une autre hypothèse fondamentale est l’importance de la multi-tenance et l’adoption des capacités offertes par le cloud computing. Lokad vise à utiliser des capacités d’expansion horizontale plutôt que verticale, ce qui signifie qu’ils utilisent plusieurs machines plus petites pour traiter de grandes quantités de données plutôt que de se reposer sur un superordinateur unique et puissant.
Vermorel souligne l’importance pour les praticiens de la supply chain de comprendre les hypothèses fondamentales de conception de leur logiciel. Cette compréhension aide à prévenir des problèmes résultant d’un décalage entre la conception du logiciel et l’utilisation prévue par l’entreprise. Les fournisseurs peuvent prétendre que leur logiciel est polyvalent et adapté à diverses situations, mais en réalité, certaines limites de conception peuvent en freiner l’efficacité dans certaines applications.
Transcription complète
Kieran Chandler: Aujourd’hui, nous allons comprendre comment ces décisions peuvent en réalité enfermer une entreprise dans un moule et aussi saisir certaines des hypothèses fondamentales qui les sous-tendent. Alors, Joannes, nous parlons un peu de la manière dont une mauvaise conception logicielle peut réellement impacter une entreprise. Quels sont certains des défis que vous observez ?
Joannes Vermorel: Le premier défi est que la conception logicielle est d’une importance cruciale pour les supply chains. Les supply chains modernes fonctionnent grâce aux logiciels. Vous avez des camions, des machines, des tapis roulants, mais aussi de larges segments de logiciels tels que votre ERP, MRP, WMS, OMS, EDI, et tant d’autres couches. Les supply chains modernes ne fonctionnent pas sans une grande quantité de logiciels. Lorsque je discute avec les clients de Lokad, ils rencontrent fréquemment des difficultés avec le paysage applicatif de la supply chain. Il y a beaucoup de problèmes liés aux logiciels, mais ce ne sont pas nécessairement des bugs ou des crashs. Les problèmes de conception sont beaucoup plus répandus ; ils rendent les choses lentes, peu intuitives, et la configuration du système prend une éternité. Lorsque vous essayez de faire une analyse des causes profondes, vous constatez fréquemment que les problèmes sont en réalité des problèmes de conception logicielle dans lesquels les décisions fondamentales concernant la conception du logiciel ont été prises, et qui se sont complètement décalées par rapport à la réalité effective de la supply chain concernée.
Kieran Chandler: Alors, quelles sont certaines des caractéristiques de l’architecture logicielle qui peuvent être si importantes ? Quels sont certains des défis que vous avez observés chez vos clients ?
Joannes Vermorel: Prenons, par exemple, le cas du temps réel. De nombreux logiciels de supply chain de nos jours sont orientés vers des opérations en temps réel. Par temps réel, je veux dire que si vous décidez de prélever une unité sur l’étagère, le niveau de stock sera décrémenté immédiatement. Cela semble très raisonnable. Cependant, dès que vous disposez d’un logiciel conçu pour le temps réel, toute opération sophistiquée deviendra un véritable casse-tête à faire fonctionner dans le logiciel. La raison est que si votre logiciel est conçu pour être ultra-rapide pour des opérations très simples, réaliser une opération complexe, comme une prévision ou une analyse à l’échelle du réseau, sera un défi. Cela s’explique par le fait que votre logiciel est conçu pour des opérations très rapides et de petite envergure, et lorsque vous devez traiter une quantité de données modérément complexe, cela devient difficile.
Kieran Chandler: Et si vous avez une version très granulaire, cela va ralentir tout le monde, y compris des opérations qui devraient être ultra-rapides, comme simplement scanner un code-barres et émettre un bip. J’ai scanné, vous pouvez passer à l’article suivant. À quel point pensez-vous que certains de ces défis sont évidents ? Il faut compatir avec un praticien de la supply chain. Je veux dire, il se passe énormément de choses, et avec beaucoup d’utilisation de ce logiciel, il se passe un sacré paquet de choses en coulisses. Alors, à quel point est-il évident que certains de ces défis existent ?
Joannes Vermorel: Ce n’est pas évident parce que, généralement, il ne s’agit pas d’un bug évident qui fait planter votre système. C’est plus comme une mort par mille coupures. Laissez-moi illustrer : vous avez ce système censé être en temps réel. Lorsqu’un article est scanné sur un tapis roulant haute vitesse, vous devriez être capable de faire biper les articles, par exemple trois articles par seconde. Vous devriez être vraiment rapide et disposer d’un temps de réponse en millisecondes.
Maintenant, que se passe-t-il si, de temps à autre, vous avez un calcul qui prend quelques secondes au lieu de millisecondes ? Si vous n’avez qu’une seule opération, de temps en temps, qui prend quelques secondes, et que votre système en temps réel est bien conçu, probablement la plupart des autres opérations resteront ultra-rapides, il n’y aura donc pas trop de problème. Sauf, si vous n’êtes pas chanceux, et qu’au même moment, vous avez comme dix opérations différentes prenant plusieurs secondes à calculer. Cela absorbe alors, à ce moment précis, toutes les ressources informatiques.
Ainsi, ce qui se passera, c’est que le système qui était censé pouvoir scanner et vous fournir un retour en millisecondes prendra soudainement une seconde. Ce n’est pas idéal, mais on peut s’en accommoder. Cependant, de temps en temps, il arrive que vous vous attendiez à quelque chose d’une rapidité fulgurante, mais qu’ensuite le délai soit de deux ou trois secondes. D’ailleurs, vous pouvez constater que parfois même dans les supermarchés locaux, le point de vente affiche un bip fluide lors du scan des articles, mais qu’à un moment donné, ils scannent quelque chose, et trois secondes s’écoulent, puis un bip apparaît.
Ici, vous avez un système en temps réel qui a été en quelque sorte encombré par une opération non en temps réel. Je ne sais pas ce que c’était, peut-être une mise à jour de Windows ou une sorte de truc étrange qui ralentit la machine. Mais dans un système en temps réel, vous n’êtes pas autorisé à exécuter quoi que ce soit de complexe ou d’intelligent, car cela dégradera les opérations ultra-rapides que vous souhaitez réaliser.
Quand je dis mort par mille coupures, c’est parce que la première fois que vous effectuez une opération non temps réel dans un système temps réel, il se peut que rien de grave ne se passe. C’est rare, donc ça va d’une certaine manière. Mais le problème, c’est que vous accumulez de plus en plus d’opérations non temps réel et, soudainement, ces problèmes qui étaient très rares commencent à devenir de plus en plus fréquents, jusqu’à devenir hyper fréquents. Alors les gens deviennent fous et se demandent : “Pourquoi ce convoyeur ne fonctionne-t-il pas plus vite ? Il pourrait.”
La réponse est qu’il y a une machine censée scanner le code-barres, et nous devons attendre que le système réponde. J’ai vu des situations où il fallait une demi-minute pour que le système réponde après le scan d’un code-barres. Il s’agissait d’imprimer quelque chose à coller sur la boîte, mais le convoyeur était limité par la vitesse à laquelle le système pouvait transmettre l’ordre à l’imprimante pour imprimer sur la boîte. Ils avaient des personnes qui attendaient simplement que l’imprimante imprime.
Vous disposez de nombreux choix de conception qui doivent être parfaitement optimisés dès le départ, de manière étroitement alignée avec les problèmes que vous essayez de résoudre.
Kieran Chandler : Quelles sont les hypothèses de base clés qui sont prises dans le logiciel supply chain, et lesquelles avez-vous observé qui ne fonctionnent pas vraiment ?
Joannes Vermorel : Il existe de nombreuses façons d’aborder cela. Tout d’abord, considérez l’échelle temporelle dans laquelle vous souhaitez opérer. Nous avons des systèmes qui doivent fonctionner avec un temps de réponse inférieur à la milliseconde, ce qui est nécessaire pour faire fonctionner littéralement un convoyeur, et d’autres pour prendre des décisions qui nécessitent de penser une décennie à l’avance, comme l’implantation d’usines. Chaque fois que vous ajoutez un ordre de grandeur, vous modifiez fondamentalement le logiciel.
Kieran Chandler : Pouvez-vous donner quelques exemples d’échelles temporelles différentes et des types de logiciels correspondants ?
Joannes Vermorel : Bien sûr. Moins d’une milliseconde est un type de logiciel ; de 1 à 10 millisecondes, c’est un autre type ; de 10 à 100 millisecondes, c’est encore un autre type, qui correspond généralement aux logiciels ERP avec des temps de réponse de 10 à 100 millisecondes. De 100 millisecondes à 1 seconde, vous obtenez le genre de choses que l’on trouve dans une application web. Ensuite, si vous commencez à penser de 1 à 10 minutes à l’avance, vous n’êtes plus en temps réel, mais vous pouvez commencer à faire des calculs sophistiqués. Par exemple, une application de navigation comme Waze doit fournir un itinéraire en moins d’une demi-minute, sans pour autant être en temps réel.
Si vous optimisez un itinéraire pour des livraisons en camion, il peut typiquement falloir plusieurs minutes pour obtenir les résultats, car il n’est pas nécessaire que ce soit en temps réel. Chez Lokad, nous nous concentrons généralement sur des périodes allant de 1 jour à 1 an. C’est le créneau idéal pour nous, ce qui signifie que nous pouvons pratiquement ignorer tout ce qui se situe avant. Si nous dépassons un an, nous entrons dans le domaine du design de la supply chain, qui est plus centré sur la cartographie et modifie la problématique.
Kieran Chandler : Parlons davantage de la mise en œuvre du logiciel. Quelles sont les principales différences entre les logiciels à client unique et multi-tenant ?
Joannes Vermorel : La différence entre le mode à client unique et le mode multi-tenant réside dans le nombre de clients que vous servez avec la même application logicielle. Si vous êtes multi-tenant, comme Lokad, c’est le même logiciel qui sert tous nos clients. Nous n’avons qu’une seule version déployée en ligne à un moment donné, et nous mettons à jour ce logiciel sur une base hebdomadaire. L’autre approche, qui était plus courante avant l’avènement du SaaS, est le mode à client unique. Cette approche consiste à fournir à chaque client sa propre copie du logiciel, ce qui conduit souvent à une personnalisation pour les grands clients.
La production du logiciel signifie que, soudainement, vous vous retrouvez avec de nombreuses variantes de votre logiciel qui tournent simultanément, ce qui est un gros problème opérationnel car cela signifie que s’il y a un bug dans une version, vous devez la corriger tout en vous assurant que le bug soit également corrigé dans toutes les autres versions. D’ailleurs, c’est un problème qui, pour les entreprises de logiciels, constitue une sorte d’anti-économie d’échelle. Plus vous êtes grand, plus vous avez de problèmes avec votre gestion des versions. Par ailleurs, ce problème affecte très sévèrement Oracle, par exemple, avec sa base de données Oracle. Ils ont de nombreuses versions fortement personnalisées, optimisées pour la performance. Je n’ai aucune information privilégiée, mais d’après des informations publiques, on peut constater que dans plusieurs divisions d’ingénierie chez Oracle, ils peinent face au nombre de variantes de leur logiciel. Évidemment, Oracle dispose d’énormes capacités d’ingénierie, mais cela reste néanmoins un grand défi. Ainsi, le mode single-tenant vous offre la possibilité d’une personnalisation par client, mais vous devez ensuite gérer une surcharge spécifique à chaque client. Le mode multi-tenant, quant à lui, vous permet d’avoir une base de code unique pour tout le monde, sans personnalisation, mais en échange, vous pouvez évoluer beaucoup plus rapidement et rencontrer beaucoup moins de problèmes de sécurité.
Kieran Chandler : Lorsque vous dites que le marché se dirige largement vers ce type de modèle SaaS, pourquoi ce modèle est-il si bien meilleur ? Offre-t-il un degré de flexibilité supérieur pour l’entreprise ?
Joannes Vermorel : Oui, au cours de la dernière décennie, pratiquement tous les éditeurs de logiciels sérieux se sont orientés vers la multi-tenancy, même les applications de bureau traditionnelles. Évidemment, si vous êtes une application web comme Lokad, être multi-tenant est assez simple. Vous redéployez les éléments sur vos propres systèmes, et le tour est joué. Bien sûr, lorsque vous avez un logiciel qui fonctionne sur les machines des clients, comme par exemple votre navigateur — Internet Explorer ou Google Chrome — c’est plus compliqué car vous n’avez pas le contrôle de ces machines. Mais devinez ce que les éditeurs ont fait ? Ils sont passés à la stratégie evergreen. Par exemple, Google Chrome ne vous demande plus de mettre à jour le navigateur. Lorsque Google décide que votre version de Chrome est obsolète et doit être remplacée, il met à jour votre navigateur à distance. Bien entendu, la prochaine fois que vous vous connecterez à Internet, ils ne pourront pas mettre à jour votre logiciel magiquement si vous n’êtes pas connecté. Mais à condition que vous le soyez et que vous n’ayez pas entrepris de manipulations spécifiques pour empêcher la mise à niveau, celle-ci se fera pratiquement sans intervention de votre part. Et quand on regarde ce que Microsoft fait avec Office 365, c’est la même chose. Autrefois, vous passiez d’une version d’Office à une autre, par exemple d’une version d’Excel à la suivante. De nos jours, c’est à la demande, et Microsoft s’occupe de la mise à jour. Vous avez un abonnement, le logiciel est installé sur votre machine, mais il peut se mettre à jour automatiquement vers la version suivante. Et si vous le laissez faire — à moins de désactiver les options de mise à niveau — Microsoft met à jour toutes les applications de bureau afin de pallier le problème d’avoir plusieurs versions du même logiciel.
Kieran Chandler : Parlons un peu de Lokad alors. Vous avez dit qu’il y avait certaines hypothèses de base devant être intégrées dans la conception logicielle, pouvant réellement impacter les opérations futures. Quelles sont donc les hypothèses de base que vous avez adoptées ici chez Lokad ?
Joannes Vermorel : Il y en a une multitude, mais avant d’entrer dans le vif du sujet, j’aimerais faire une remarque. Si vous rencontrez un éditeur de logiciels qui
Kieran Chandler : Qui vous dirait que tout est dans mon logiciel, vous savez. Nous sommes capables de tout, sauf de ce que nous n’avons pas créé. Vous savez, donc, il y a une hypothèse logicielle. Lorsqu’on rencontre un éditeur de logiciels pour votre supply chain, demandez-lui quelles sont les hypothèses de base. Et s’il vous répond quelque chose de vague comme “nous sommes conçus pour la sécurité”, super. “Nous sommes conçus pour la rapidité”, moi aussi. “Nous sommes conçus pour l’efficacité des coûts”, d’accord. Vous savez, ce sont des affirmations vagues et absolument positives. Mais quand nous parlons de conception, il y a toujours un compromis : des aspects positifs et négatifs sont en jeu. Donc, si vous discutez avec l’éditeur et qu’il ne vous présente que les aspects positifs, c’est probablement qu’il ne comprend même pas la nature de la conception logicielle en premier lieu. Alors, Joannes, quelles sont les hypothèses de conception de base que vous avez intégrées chez Lokad ?
Joannes Vermorel : La première était un mode de traitement par lots. Qu’est-ce que cela signifie ? Cela signifie que nous voulons être capables de traiter une énorme quantité de big data et d’effectuer des calculs très intelligents. Évidemment, nous préférons être très intelligents plutôt que très, très rapides, ce qui signifie que, pour nous, il est acceptable que les calculs s’exécutent typiquement en quelques minutes, même si le fait qu’ils puissent s’exécuter en quelques secondes est un bonus. Mais si cela n’est pas possible, ce n’est pas bien grave. Nous préférons obtenir de meilleurs résultats, même si cela prend un peu de temps. D’ailleurs, ce n’est pas parce que certaines parties de notre système observent ce que l’on pourrait appeler le temps d’horloge, c’est simplement une présentation des résultats. Il se peut donc que vous ayez besoin d’une demi-heure pour effectuer un calcul massif, mais lorsque vous voulez accéder aux résultats, ils doivent être en temps réel, bien qu’ils soient pré-calculés. Vous voyez, c’était une hypothèse de conception de base : pas de temps réel, c’est du traitement par lots. Et la raison en est que nous voulons être aussi expressifs et puissants que possible et, par conséquent, aussi intelligents que nous pouvons l’être pour, je dirais, une analyse mondiale globale. Une autre hypothèse était que nous voulions mettre en place une multi-tenancy. Évidemment, de nos jours, la plupart des gens le font, mais il y a encore des entreprises, surtout dans le secteur enterprise, qui accusent un retard.
Kieran Chandler : Pouvez-vous expliquer la différence entre scalable et scale out ?
Joannes Vermorel : Les capacités offertes par le cloud signifient que nous privilégions des capacités de scale out plutôt que de scale up. La question est la suivante : si vous souhaitez traiter des téraoctets de données, pouvez-vous le faire en empilant une multitude de petites machines, ou avez-vous besoin d’un superordinateur ?
Kieran Chandler : Alors, quelle est notre conclusion principale aujourd’hui ?
Joannes Vermorel : Notre conclusion principale est qu’en ce qui concerne les données dont nous disposons et les choix en matière de logiciels, cela peut fortement limiter ce que vous ferez à l’avenir. Il est donc crucial de bien comprendre les choix que vous effectuez.
Kieran Chandler : Pouvez-vous développer ce point ?
Joannes Vermorel : Ma suggestion serait que les praticiens supply chain soient davantage conscients des hypothèses de conception de base qui caractérisent leur propre écosystème applicatif. Ils disposent de nombreuses applications, et peuvent-ils me donner une demi-douzaine d’hypothèses critiques sur le code qui expliquent les tenants et aboutissants du produit. Cela peut sembler très technique, mais si vous ne comprenez pas ces hypothèses de conception fondamentales, vous allez beaucoup souffrir lorsque vous vous rendrez compte que vous essayez d’utiliser un produit qui, de par sa conception, ne conviendra pas à cet usage. J’ai souvent vu des entreprises dont les problèmes émergent littéralement d’un décalage entre la conception du logiciel et ce qu’elles tentent d’en faire.
Kieran Chandler : Pouvez-vous donner un exemple ?
Joannes Vermorel : Les fournisseurs essaient de faire preuve d’une grande assurance, vous savez. En tant que fournisseur, vous tentez de vendre votre logiciel. Vous voulez afficher de la confiance et dire au client que votre application de supply chain sera performante dans toutes les situations, et que nous avons tout prévu pour lui. Mais la réalité, c’est que si un client utilise votre logiciel pour quelque chose qui dépasse vos capacités de conception, vous ne pouvez pas simplement bricoler la solution. Vous ne pouvez pas juste ajouter une fonctionnalité. Les ingénieurs du back-end vont vous dire : “Patron, désolé, nous ne pouvons pas le faire. Ce sera un véritable enfer.”
Kieran Chandler : Très bien, concluons. Merci, Joannes. C’est tout pour cette semaine. Merci beaucoup de nous avoir suivis, et nous nous reverrons la prochaine fois. Au revoir pour l’instant.
