Conception logicielle pour les Supply Chains

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 les opérations complexes peuvent affecter les systèmes en temps réel.
00:07:13 Systèmes en temps réel encombrés par des opérations non en temps réel.
00:09:13 Importance des choix de conception et de l’échelle de temps dans les logiciels de supply chain.
00:12:31 Différences entre les logiciels à locataire unique et à locataires multiples.
00:14:11 Défis liés aux multiples versions de logiciels dans les applications à locataire unique.
00:15:33 Avantages des logiciels à locataires multiples et le passage aux modèles SaaS.
00:17:56 Importance de comprendre les hypothèses fondamentales de conception logicielle pour les praticiens de la supply chain.
00:19:18 Hypothèses de conception fondamentales de Lokad, y compris le mode de traitement par lots et la multi-tenance.
00:21:35 Réflexions finales sur la compréhension des choix logiciels et leur impact sur les opérations futures.
00:23:36 Réflexions finales.

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 discuté. Les défis découlent souvent de problèmes de conception plutôt que de bugs ou de plantages, ce qui peut rendre le logiciel lent, peu intuitif et difficile à configurer. La gestion des données en temps réel est une fonctionnalité clé qui peut avoir un impact sur 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 les problèmes résultant de divergences entre la conception du logiciel et son utilisation prévue par une entreprise.

Résumé étendu

Dans cette interview, l’animateur Kieran Chandler discute avec Joannes Vermorel, fondateur de Lokad, de l’impact de la conception logicielle sur les opérations des entreprises, 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, les MRP, les WMS, les OMS et les EDI, pour fonctionner efficacement.

Les défis auxquels sont confrontés les clients de Lokad découlent souvent de problèmes de conception de leur logiciel, plutôt que de bugs évidents ou de plantages. Ces problèmes de conception peuvent rendre le logiciel lent, peu intuitif, lent et difficile à configurer. Comme l’explique Vermorel, ces problèmes résultent souvent d’une inadéquation 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 qui peut avoir un impact sur les opérations de la supply chain est sa capacité à traiter les données en temps réel. Vermorel souligne que bien que le traitement 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 logiciels de gestion de la supply chain sont conçus pour approximer le traitement des données en temps réel. Par exemple, lorsque un article est prélevé sur une étagère, le logiciel décrémente immédiatement le niveau de stock. Cependant, cette approche en temps réel peut avoir des conséquences imprévues.

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 des prévisions ou des analyses à l’échelle du réseau. Ces opérations complexes nécessitent un niveau plus sophistiqué de traitement des données, qui peut ne pas être réalisable dans un système optimisé pour des mises à jour en temps réel à 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, en raison d’une inadéquation entre les décisions de conception fondamentales du logiciel et la réalité effective de la supply chain. La capacité à traiter les données en temps réel est l’une des caractéristiques clés de l’architecture logicielle qui peut avoir un impact sur les opérations de la 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 des prévisions ou des analyses à l’échelle du réseau, qui nécessitent un niveau plus sophistiqué de traitement des données.

Vermorel explique que les problèmes auxquels sont confrontés les praticiens de la supply chain utilisant de tels logiciels ne sont pas toujours évidents, car ils se manifestent souvent comme une accumulation lente de problèmes, qu’il qualifie de “mort par mille coupures”.

Un problème clé est la nécessité d’une fonctionnalité en temps réel dans certains scénarios, tels que la numérisation d’articles sur un tapis roulant à grande vitesse. Lorsque des opérations non en temps réel sont introduites dans le système, les performances globales peuvent être impactées négativement, entraînant des ralentissements et des retards. Cela peut entraîner une frustration accrue des utilisateurs et une efficacité réduite.

Vermorel souligne l’importance de faire les bons choix de conception fondamentaux, qui doivent être profondément alignés sur les problèmes que le logiciel cherche à résoudre. Dans le contexte des logiciels de gestion de la 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 de temps sur laquelle le logiciel fonctionne est une considération cruciale. Vermorel décrit les différents types de logiciels nécessaires pour différentes échelles de temps, allant des temps de réponse sub-millisecondes pour la conduite de tapis roulants, à la 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’ordre de grandeur de l’échelle de temps nécessite un type de logiciel différent avec des capacités uniques.

Chez Lokad, l’accent est généralement mis sur des échelles de temps allant d’un jour à un an, ce qui nécessite une approche différente de la conception logicielle. Vermorel aborde également les différences entre les logiciels à locataire unique et à locataires multiples, ce qui est une considération essentielle pour les développeurs de logiciels, bien que moins familière à la plupart des entreprises.

Ils discutent des différences entre les logiciels à locataires multiples et à locataire unique, des avantages du modèle SaaS et des hypothèses fondamentales qui ont guidé la conception logicielle de Lokad.

Vermorel explique que les logiciels à locataires multiples servent plusieurs clients en utilisant la même version du logiciel, tandis que les logiciels à locataire unique impliquent de donner à chaque client leur propre version personnalisée. Lokad est à locataires multiples, avec une base de code mise à jour chaque semaine. Cette approche présente plusieurs avantages, notamment une version simplifiée et moins de problèmes de sécurité. Vermorel oppose cela aux logiciels à locataire unique, qui permettent une personnalisation par client mais nécessitent la gestion de plusieurs versions, ce qui entraîne des défis opérationnels.

Il observe que, au cours de la dernière décennie, de nombreuses entreprises de logiciels sérieuses ont adopté le modèle à locataires multiples. Pour les applications Web comme Lokad, être à locataires multiples est assez simple, mais pour les logiciels qui fonctionnent sur les machines des clients, cela peut être plus compliqué. Une solution à ce problème est la stratégie “evergreen”, comme celle de Google Chrome et de Microsoft Office 365. Ces applications se mettent à jour automatiquement, sans intervention de l’utilisateur, atténuant ainsi les problèmes liés à l’existence de plusieurs versions du même logiciel.

Lorsqu’il discute de la conception logicielle de Lokad, Vermorel insiste sur 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 souligne que la conception implique des compromis, avec 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 la conception de Lokad incluent le mode de traitement par lots, que Vermorel explique être choisi car il permet une meilleure optimisation et gestion des ressources.

Un principe clé est de privilégier les calculs intelligents plutôt que la vitesse. Lokad préfère avoir des calculs précis et détaillés même si cela prend plus de temps, plutôt que des calculs plus rapides et moins précis. Le logiciel est conçu pour le traitement par lots plutôt que pour le temps réel, ce qui permet une plus grande expressivité et puissance 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 de mise à l’échelle 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 s’appuyer sur un seul superordinateur puissant.

Vermorel souligne l’importance pour les praticiens de la supply chain de comprendre les hypothèses fondamentales de la conception de leur logiciel. Cette compréhension permet d’éviter les problèmes découlant d’un désalignement 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é à différentes situations, mais en réalité, certaines limitations de conception peuvent entraver son efficacité dans certaines applications.

Transcription complète

Kieran Chandler: Aujourd’hui, nous allons comprendre comment ces décisions peuvent finir par enfermer une entreprise et comprendre également certaines des hypothèses fondamentales qui les sous-tendent. Alors, Joannes, nous parlons un peu de la façon dont une mauvaise conception logicielle peut avoir un impact sur 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 capitale pour les chaînes d’approvisionnement. Les chaînes d’approvisionnement modernes fonctionnent grâce aux logiciels. Vous avez des camions, des machines, des convoyeurs, mais aussi de grandes quantités de logiciels tels que votre ERP, MRP, WMS, OMS, EDI, et tant d’autres couches. Les chaînes d’approvisionnement modernes ne fonctionnent pas sans logiciel en grande quantité. Lorsque je discute avec les clients de Lokad, ils rencontrent souvent des difficultés liées au paysage applicatif de la chaîne d’approvisionnement. Il y a beaucoup de problèmes liés aux logiciels, mais ils ne sont pas nécessairement des bugs ou des plantages. Les problèmes de conception sont beaucoup plus répandus ; ils rendent les choses lentes, peu intuitives, et il faut une éternité pour configurer le système. Lorsque vous essayez de faire une analyse des causes profondes, vous constatez souvent que les problèmes sont en réalité des problèmes de conception logicielle où des décisions fondamentales ont été prises concernant la conception du logiciel, et cela ne correspond pas du tout à la réalité de la chaîne d’approvisionnement concernée.

Kieran Chandler: Quelles sont donc certaines caractéristiques de l’architecture logicielle qui peuvent être si importantes ? Quels sont certains des défis que vous avez rencontrés avec vos clients ?

Joannes Vermorel: Prenons par exemple le temps réel. De nos jours, de nombreux logiciels de chaîne d’approvisionnement sont orientés vers les opérations en temps réel. Par temps réel, j’entends que si vous décidez de prendre une unité sur l’étagère, cela va immédiatement décrémenter le niveau de stock. Cela semble être une chose très raisonnable. Cependant, dès que vous avez ce genre de logiciel conçu pour le temps réel, tout calcul sophistiqué va être très difficile à effectuer dans le logiciel. La raison en est que si votre logiciel est conçu pour être super rapide pour des opérations très simples, effectuer une opération complexe, comme une prévision ou une analyse à l’échelle du réseau, va être difficile. C’est parce que votre logiciel est conçu pour des opérations très rapides et simples, et lorsque vous avez besoin de traiter une quantité de données modérément complexe, cela va être difficile.

Kieran Chandler: Et si vous avez une version granulaire, cela va ralentir tout le monde, y compris des choses qui devraient être très rapides, comme simplement scanner un code-barres et faire bip. J’ai scanné, vous pouvez passer à l’article suivant. À quel point certains de ces défis sont-ils évidents ? On peut sympathiser avec un praticien de la chaîne d’approvisionnement. Je veux dire, il y a beaucoup de choses en jeu, et avec beaucoup de temps passé sur ce logiciel, il y a énormément de choses qui se passent en coulisses. Alors, à quel point certains de ces défis sont-ils évidents ?

Joannes Vermorel: Ce n’est pas évident car ce n’est généralement pas un bug évident où votre système plante. C’est plutôt une mort par mille coupures. Laissez-moi vous donner un exemple : vous avez ce système qui est censé être en temps réel. Lorsqu’un objet est scanné sur un tapis roulant à grande vitesse, vous devriez pouvoir faire bip pour trois articles par seconde, ou quelque chose du genre. Vous devriez pouvoir être vraiment rapide et avoir un temps de réponse en millisecondes.

Maintenant, que se passe-t-il si, de temps en temps, vous avez un calcul qui prend quelques secondes au lieu de millisecondes ? Si vous avez simplement une 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 super rapides, donc cela ne fait pas trop mal. Sauf si vous n’avez pas de chance, et au même moment, vous avez comme dix opérations différentes qui prennent plusieurs secondes à calculer. Cela absorbe, à ce moment précis, toutes les ressources de calcul.

Donc, ce qui va se passer, c’est que le système qui était censé pouvoir scanner et vous donner un retour en millisecondes prend soudainement une seconde. Ce n’est pas idéal, mais vous pouvez vivre avec. Cependant, de temps en temps, vous avez cette situation où vous vous attendiez à quelque chose de très rapide, mais soudainement il y a deux ou trois secondes de retard. D’ailleurs, vous pouvez voir cela parfois même dans les supermarchés locaux. Vous avez un point de vente et le bip des articles est très fluide, mais à un moment donné, ils bipent quelque chose et il se passe trois secondes, puis bip.

Ici, vous avez un système en temps réel qui a été un peu 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 bizarre qui ralentit la machine. Mais dans un système en temps réel, vous n’êtes pas autorisé à faire quelque chose de intelligent ou de complexe car cela va dégrader les opérations super rapides que vous souhaitez effectuer.

Quand je dis une mort par mille coupures, c’est parce que la première fois que vous faites quelque chose qui n’est pas en temps réel dans un système en temps réel, probablement rien de grave ne se produira vraiment. C’est rare, donc ça va. Mais le problème, c’est que vous accumulez de plus en plus de choses qui ne sont pas en temps réel, et soudainement ces problèmes qui étaient très peu fréquents commencent à devenir plus fréquents et de plus en plus fréquents, jusqu’à devenir super fréquents. Alors les gens deviennent fous et disent : “Pourquoi ce tapis roulant ne fonctionne-t-il pas plus rapidement ? Il pourrait le faire.”

La réponse est que nous avons une machine qui est 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 avoir scanné un code-barres. Il s’agissait d’imprimer quelque chose à mettre sur la boîte, mais le tapis roulant était limité par la vitesse à laquelle le système pouvait transmettre l’ordre à l’imprimante pour imprimer quelque chose sur la boîte. Ils avaient des gens qui attendaient simplement que l’imprimante imprime.

Vous avez de nombreuses options de conception qui doivent être très bien choisies, de manière profondément alignée avec les problèmes que vous essayez de résoudre.

Kieran Chandler: Quelles sont les principales hypothèses de base qui sont faites dans les logiciels de la chaîne d’approvisionnement, et lesquelles avez-vous observées qui ne fonctionnent pas vraiment ?

Joannes Vermorel: Il y a de nombreuses façons d’aborder cela. Tout d’abord, considérez l’échelle de temps dans laquelle vous souhaitez opérer. Nous avons des choses qui doivent fonctionner avec un temps de réponse inférieur à la milliseconde, ce qui est ce dont vous avez besoin pour littéralement piloter un tapis roulant, jusqu’à des décisions où vous devez penser à une décennie à l’avance, comme l’emplacement des usines. Chaque fois que vous ajoutez un ordre de grandeur, vous modifiez fondamentalement le logiciel.

Kieran Chandler: Pouvez-vous donner quelques exemples de différentes échelles de temps et les types de logiciels correspondants ?

Joannes Vermorel: Bien sûr. La milliseconde est un type de logiciel ; de 1 à 10 millisecondes, cela sera un autre type de logiciel ; de 10 à 100 millisecondes, cela sera un autre type, qui est généralement un logiciel ERP avec des temps de réponse de 10 à 100 millisecondes. De 100 millisecondes à 1 seconde, vous obtenez le genre de choses que vous pouvez trouver dans une application web. Ensuite, si vous commencez à réfléchir de 1 minute à 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 minute mais n’a pas besoin d’être en temps réel.

Si vous optimisez un itinéraire pour des livraisons de camions, vous pouvez généralement prendre plusieurs minutes pour obtenir les résultats, car cela n’a pas besoin d’être en temps réel. Chez Lokad, nous nous concentrons généralement sur des périodes allant d’un jour à un an. C’est notre créneau et cela signifie que nous pouvons pratiquement ignorer tout ce qui se passe avant cela. Si nous dépassons un an, nous entrons dans le domaine de la conception de la chaîne d’approvisionnement, qui est plus axée sur la cartographie et qui change le problème.

Kieran Chandler: Parlons davantage de la mise en œuvre des logiciels. Quelles sont les principales différences entre les logiciels à locataire unique et les logiciels à locataires multiples ?

Joannes Vermorel: La différence entre un logiciel à locataire unique et un logiciel à locataires multiples réside dans le nombre de clients que vous servez avec le même logiciel. Si vous êtes à locataires multiples, 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 à tout moment, et nous mettons à jour ce logiciel chaque semaine. L’autre façon, qui était plus courante avant l’avènement du SaaS, est le locataire unique. Cette approche consiste à donner à chaque client sa propre copie du logiciel, ce qui entraîne souvent une personnalisation pour les grands clients.

Produire le logiciel signifie que vous vous retrouvez soudainement avec de nombreuses variantes de votre logiciel qui se trouvent simplement en cours d’exécution en même temps, ce qui pose un gros problème opérationnel car cela signifie que si un bug se produit dans une version, vous devez corriger cette version, mais vous devez vous assurer que le bug est également corrigé dans toutes vos autres versions. En passant, c’est un problème où, pour les entreprises de logiciels, vous avez comme des anti-économies d’échelle. Plus vous êtes gros, plus vous avez de problèmes avec votre versionnage. En passant, ce problème a un impact très important sur Oracle, par exemple, avec la base de données Oracle. Ils ont de nombreuses versions fortement personnalisées qui sont optimisées pour les performances. Je n’ai aucune information privilégiée, mais à partir d’informations publiques, vous pouvez voir que littéralement, dans certaines divisions d’ingénierie multiples chez Oracle, ils ont du mal avec le fait qu’ils ont de nombreuses variantes du logiciel. Évidemment, Oracle dispose de nombreuses capacités d’ingénierie, mais cela reste un grand défi. Donc, le locataire unique vous donne la possibilité de personnalisation par client, mais vous devez ensuite gérer les frais généraux par client. Le locataire multiple vous donne le fait que vous avez une base de code pour tout le monde, pas de personnalisation, mais en échange, vous pouvez évoluer beaucoup plus rapidement et avoir beaucoup moins de problèmes de sécurité.

Kieran Chandler: Lorsque vous dites que le marché se dirige de plus en plus vers ce modèle SaaS, pourquoi ce modèle est-il bien meilleur ? Offre-t-il une plus grande flexibilité pour l’entreprise ?

Joannes Vermorel: Oui, au cours de la dernière décennie, pratiquement tous les éditeurs de logiciels sérieux sont passés à la multi-tenance, même les applications de bureau traditionnelles classiques. Parce que évidemment, si vous êtes une application web comme Lokad, être multi-tenant est assez simple. Vous redéployez les choses sur vos propres systèmes, et c’est fait. Évidemment, 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 des machines de vos clients. Mais devinez ce que les éditeurs de logiciels 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, Google met à jour votre navigateur à distance. Évidemment, la prochaine fois que vous vous connectez à Internet et ainsi de suite, ils ne peuvent pas mettre à jour magiquement votre logiciel si vous n’avez pas de connectivité Internet. Mais en supposant que vous avez une connectivité Internet et que vous n’avez pas fait de manigances particulières avec votre machine pour empêcher la mise à niveau, la mise à niveau se fera, en gros, sans votre intervention. Et lorsque vous regardez ce que Microsoft fait avec Office 365, c’est la même chose. Dans le passé, vous aviez une série de versions de Microsoft Office lorsque vous passiez d’une version d’Excel à la suivante. De nos jours, c’est à la demande, et Microsoft se charge de la mise à niveau. Vous avez un abonnement, le logiciel est installé sur votre machine, mais il peut simplement se mettre à niveau vers la prochaine version. Et si vous le laissez faire, sauf si vous désactivez vos options de mise à niveau, Microsoft met simplement à niveau toutes les applications de bureau pour atténuer le problème d’avoir de nombreuses versions du même logiciel.

Kieran Chandler: Parlons un peu de Lokad alors. Vous avez dit qu’il y avait certaines hypothèses fondamentales qui doivent être faites dans la conception de logiciels et qui peuvent vraiment avoir un impact sur les opérations futures. Alors, quelles sont les hypothèses fondamentales que vous avez faites ici chez Lokad ?

Joannes Vermorel: Il y en a des tonnes, mais avant d’entrer dans les hypothèses fondamentales, j’aimerais faire une remarque. Si vous rencontrez un éditeur de logiciels qui

Kieran Chandler: Qui vous dit que tous mes logiciels, vous savez. Nous sommes capables de tout ce que nous n’avons pas fait. Vous savez, donc hypothèse logicielle. Si on ne vous donne que ça, je peux vous suggérer, vous savez, lorsque vous rencontrez un éditeur de logiciels pour votre supply chain, demandez-leur quelles sont les hypothèses fondamentales ? Et s’ils vous disent quelque chose de vague comme “nous sommes conçus pour la sécurité”, super. “Nous sommes conçus pour la rapidité”, ouais, moi aussi. “Nous sommes conçus pour l’efficacité des coûts”, ouais. Vous savez, ce sont des choses super vagues, absolument positives. Mais lorsque nous discutons de la conception, un point de vue de conception est un compromis. C’est quelque chose qui a des aspects positifs et des aspects négatifs. Donc, si vous pouvez discuter avec l’éditeur de logiciels et que tout ce qu’ils peuvent vous donner ce sont les aspects positifs, c’est probablement qu’ils ne comprennent même pas la nature de la conception de logiciels en premier lieu. Alors, Joannes, quelles sont les hypothèses de conception fondamentales que vous avez intégrées à Lokad ?

Joannes Vermorel: La première était un mode de traitement par lots. Alors, qu’est-ce que cela signifie ? Cela signifie que ce que nous voulons, c’est être capable de traiter des tonnes de données volumineuses et de faire des calculs très intelligents. Évidemment, parce que nous voulons, nous préférons être très intelligents plutôt que très, très rapides, ce qui signifie que, pour nous, avoir des calculs qui sont généralement exécutés en quelques minutes, mais le fait qu’ils puissent être exécutés en quelques secondes est un bonus. Mais si nous ne pouvons pas, ce n’est pas si grave. Nous préférons avoir de meilleurs chiffres même si cela prend un peu de temps. Au fait, ce n’est pas parce qu’il y a nos pièces qui regardent cela que notre temps de rotation est important, c’est juste une présentation des résultats. Donc, peut-être que vous aurez besoin d’environ une demi-heure pour effectuer un calcul massif, mais lorsque vous voudrez accéder à ces résultats, cela doit être en temps réel, mais c’est précalculé. Donc, vous voyez que c’était une hypothèse de conception fondamentale. Pas de temps réel, ou c’est par lots. Et la raison est que nous voulons être capables d’être très expressifs et très puissants et donc d’être aussi intelligents que possible pour, je dirais, une analyse mondiale nette. Donc, c’est une hypothèse fondamentale. Une autre était que nous voulions avoir une multi-tenance. Évidemment, de nos jours, la plupart des gens le font, mais il y a encore des entreprises, en particulier dans l’espace des entreprises, qui sont à la traîne. Et je dirais que la multi-tenance est faite avec tout.

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 voulons avoir des capacités de scale out plutôt que de scale up. La question est, si vous voulez traiter des téraoctets de données, pouvez-vous le faire en empilant des tonnes de petites machines ou avez-vous besoin d’un superordinateur pour le faire ?

Kieran Chandler: Alors, quelle est notre principale conclusion ici aujourd’hui ?

Joannes Vermorel: Notre principale conclusion est qu’en termes de données que nous avons là-bas et en termes de choix de logiciels, cela peut très bien vous enfermer dans ce que vous faites à l’avenir. Vous devez donc bien comprendre les choix que vous faites.

Kieran Chandler: Pouvez-vous développer ?

Joannes Vermorel: Ma suggestion serait que les praticiens de la supply chain soient plus conscients des hypothèses de conception fondamentales qui caractérisent leur propre paysage applicatif. Ils ont de nombreuses applications, et peuvent-ils me donner une demi-douzaine d’hypothèses de code critiques qui expliquent les tenants et les 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 réaliserez que vous essayez de faire quelque chose pour lequel, par conception, ce ne sera pas un bon produit. J’ai souvent vu de nombreuses entreprises où littéralement leurs problèmes émergent d’un désaccord entre la conception du logiciel et ce qu’ils essaient d’en faire.

Kieran Chandler: Pouvez-vous donner un exemple ?

Joannes Vermorel: Les fournisseurs essaient d’être très confiants, vous savez, en tant que fournisseur, vous essayez de vendre votre logiciel. Vous voulez agir avec confiance et dire au client que votre logiciel de supply chain sera agréable dans toutes les situations, et que nous avons tout prévu. Mais la réalité est que si un client utilise votre logiciel pour quelque chose qui dépasse ses capacités de conception, vous ne pouvez pas simplement le bricoler. Vous ne pouvez pas simplement ajouter une fonctionnalité. Les ingénieurs logiciels en coulisses vont vous dire : “Patron, désolé, nous ne pouvons pas le faire. Ça va être l’enfer.”

Kieran Chandler: Très bien, concluons. Merci, Joannes. C’est tout pour cette semaine. Merci beaucoup de nous avoir suivi, et nous vous reverrons la prochaine fois. Au revoir pour le moment.