00:00:08 Les data lakes et leur importance.
00:00:39 Les data lakes définis et leur objectif en entreprise.
00:02:13 L’évolution des data lakes par rapport aux data warehouses.
00:04:15 Un changement de mentalité et de philosophie autour des data lakes.
00:07:43 Garantir l’exactitude des données dans les data lakes.
00:10:06 Comment la technologie a amélioré les data warehouses depuis 20 ans.
00:12:14 Les avantages des systèmes à la demande dans les data lakes.
00:13:31 Les limites de la business intelligence et son approche obsolète.
00:15:22 Comparer la business intelligence aux data lakes et leur capacité à éclairer la prise de décision.
00:16:49 La complexité de la mise en œuvre : accéder aux sources de données et l’impact sur les entreprises multinationales.
00:18:32 Adoption des Data Lakes : avantages pour les entreprises orientées technologie et leur utilisation dans l’optimisation transversale.
00:20:08 L’avenir des Data Lakes : accessibilité et mise en œuvre accrues, prochaines étapes avec les APIs.
00:22:45 Remarques finales et conclusion.
Résumé
Dans cette interview, Kieran Chandler et Joannes Vermorel, fondateur de Lokad, abordent les data lakes et leur rôle dans l’optimization de la supply chain. Les data lakes sont des référentiels centralisés de données brutes qui permettent aux applications pilotées par le machine learning de prendre des décisions éclairées. Vermorel souligne les limites des outils traditionnels de business intelligence, en insistant sur le fait que les data lakes offrent une analyse des données plus efficace et automatisée. Il estime que les entreprises axées sur la technologie ont déjà adopté les data lakes et sont passées à la mise en œuvre d’interfaces de programmation d’applications (APIs) pour leurs sous-systèmes, permettant une automatisation de bout en bout. Vermorel prévoit que les grandes entreprises adopteront de plus en plus les data lakes et les APIs dans les cinq prochaines années pour une meilleure prise de décision.
Résumé étendu
Dans cette interview, Kieran Chandler discute des data lakes avec Joannes Vermorel, le fondateur de Lokad, une société de logiciels spécialisée dans l’optimization de la supply chain. Ils commencent par définir les data lakes et leurs origines. Les data lakes sont un type de base de données conçu pour consolider toutes les données transactionnelles clés d’une entreprise, telles que les ventes, les achats et les niveaux de stocks. Ces bases de données sont destinées à être utilisées par des applications, plutôt que par des humains, permettant à des applications spécifiques à un domaine, pilotées par les données, de prendre des décisions éclairées pour le marketing, la supply chain, les ressources humaines, et plus encore.
Les data lakes ont une histoire qui remonte au data warehousing et aux data marts, des tendances d’il y a plus de 20 ans. Vermorel explique que la principale différence entre les data lakes et les data warehouses réside dans la technologie et la philosophie qui les sous-tendent. Les data lakes sont plus efficaces pour stocker et distribuer de grandes quantités de données, tandis que le cloud computing les a rendus plus accessibles et abordables.
Il y a vingt ans, une entreprise devait acheter un appareil coûteux, comme un de chez Oracle, pour héberger son data warehouse. Aujourd’hui, avec les plateformes de cloud computing, les entreprises peuvent disposer de data lakes à la demande, évolutifs et proposés à des tarifs très compétitifs. Cette flexibilité permet aux entreprises d’ajuster facilement leur approche de stockage de données si nécessaire.
La philosophie derrière les data lakes a également évolué par rapport aux data warehouses. L’approche ancienne exerçait une forte pression sur les services informatiques pour organiser et gérer correctement les données. Les data warehouses étaient conçus avec des data marts pour différentes divisions, telles que le marketing, la supply chain et la finance. Cela créait des défis pour gérer et accéder aux données entre les différents départements.
Les data lakes visent à consolider les données de manière plus centralisée et accessible, facilitant ainsi le traitement par les applications et la prise de décisions éclairées. Ce changement de mentalité a permis une plus grande efficacité et flexibilité dans la gestion et l’utilisation des données.
Il y a vingt ans, le data warehousing était une méthode populaire pour gérer et organiser les données. Cette approche nécessitait un niveau élevé d’effort technique pour relier diverses tables de données et demandait un modèle unifié des données de l’entreprise. Cependant, cette méthode conduisait souvent à ce que les services informatiques soient submergés par l’ampleur du travail, ce qui entraînait de nombreux projets ratés.
Aujourd’hui, les data lakes ont émergé comme une approche plus allégée et efficace de la gestion des données. Les data lakes servent de référentiel pour les données brutes extraites de divers systèmes tels que le CRM, ERP, et les plateformes web. Au lieu de tenter d’organiser ou de combiner les données, elles sont simplement déversées dans le data lake, qui peut gérer de grandes quantités de données sans problème.
L’un des défis liés à l’utilisation des data lakes est de s’assurer que les données sont exactes et à jour. Les services informatiques sont chargés de veiller à ce que le data lake reflète fidèlement les systèmes d’origine, mais ils n’ont pas besoin de comprendre les implications commerciales des données. La responsabilité de l’interprétation des données contenues dans le CRM, par exemple, incombe aux divisions qui les utilisent, comme les ventes ou le marketing. Cette approche permet une interprétation des données plus spécifique aux problèmes, car différentes divisions peuvent avoir des besoins et des perspectives différents concernant les données.
Le paysage technologique a considérablement évolué depuis l’époque des data warehouses, rendant les data lakes une option plus viable. D’une part, la qualité des outils permettant de transférer des données sur Internet s’est améliorée, facilitant la consolidation des données provenant de systèmes distribués, tels que les supply chains. De plus, l’infrastructure Internet s’est améliorée, rendant possible le transfert de grandes quantités de données, même pour les plus petites entreprises.
De plus, les plateformes de cloud computing ont rendu les data lakes plus accessibles et rentables. Ces plateformes permettent une itération rapide et une utilisation à la demande, offrant aux entreprises la possibilité d’expérimenter les data lakes sans risque financier important.
Bien que les outils de business intelligence aient permis aux entreprises d’extraire des insights de leurs données, ils sont fondamentalement destinés à une consommation humaine. Cela signifie que les entreprises doivent payer des employés pour analyser les données au lieu d’automatiser le processus. Les data lakes, en revanche, permettent une analyse des données plus efficace et automatisée, ce qui en fait une option attrayante pour les multinationales cherchant à améliorer leur gestion des données.
Vermorel explique les limites des outils traditionnels de business intelligence (BI), les avantages des data lakes, et l’avenir de la gestion des données dans l’optimization de la supply chain.
Vermorel décrit la BI comme une technologie dépassée qui ne fournit qu’une analyse de données basique en quasi temps réel. Cette technologie était révolutionnaire il y a 30 ans, permettant aux entreprises d’accéder à leurs données et de les agréger, mais elle n’offre pas d’insights ou de décisions exploitables. En revanche, les data lakes font partie d’une vision plus globale, servant de référentiel pour les données brutes provenant de diverses sources. Des applications pilotées par le machine learning peuvent ensuite traiter efficacement ces données pour générer des décisions concrètes qui ont un impact sur l’entreprise et créent une valeur tangible.
La mise en œuvre d’un data lake dépend de la complexité de l’accès aux sources de données d’une entreprise. Pour les grandes multinationales, cela peut s’avérer être un processus difficile, chaque pays pouvant disposer de son propre système. Cependant, il n’existe pas d’alternatives si une entreprise souhaite obtenir des insights et prendre des décisions basées sur les données. Vermorel estime que les petites entreprises axées sur la technologie ont déjà adopté les data lakes, et sont même allées plus loin en mettant en place des interfaces de programmation d’applications (APIs) pour leurs sous-systèmes. Cela permet une optimisation transversale et une prise de décision intelligente.
Vermorel prévoit que les grandes entreprises adopteront de plus en plus les data lakes dans les cinq prochaines années, à mesure qu’ils deviennent plus accessibles et abordables. Les entreprises qui ne mettent pas en œuvre de data lakes risquent d’être dépassées par celles qui l’ont déjà fait. Toutefois, les data lakes ne constituent pas la dernière étape de la gestion des données. Vermorel suggère que les APIs représentent l’avenir, permettant aux entreprises non seulement de lire et d’analyser les données, mais aussi d’agir en conséquence. Les APIs peuvent permettre une automatisation de bout en bout, générant des décisions automatiquement et les mettant en œuvre dans le système.
Joannes Vermorel souligne l’importance de dépasser les outils traditionnels de BI et d’adopter les data lakes pour une prise de décision basée sur les données plus efficace dans l’optimization de la supply chain. Il envisage un avenir où les grandes entreprises mettent en œuvre des data lakes et des APIs pour automatiser leurs processus et prendre des décisions plus intelligentes.
Transcription complète
Kieran Chandler: Aujourd’hui sur Lokad TV, nous allons discuter un peu plus du concept des data lakes et comprendre pourquoi ces entreprises devraient s’y intéresser davantage. Alors Joannes, comme d’habitude, peut-être devrions-nous commencer par définir un peu plus ce que sont les data lakes et d’où ils proviennent.
Joannes Vermorel: Un data lake est généralement une sorte de base de données avec quelques particularités, destinée à consolider pratiquement toutes les données clés de votre entreprise, en particulier toutes les données transactionnelles telles que ce que vous avez vendu, ce que vous avez acheté, vos niveaux de stocks, etc. L’objectif et l’usage final du data lake est qu’il soit destiné aux applications, et non aux humains. L’idée est de mettre en place un data lake afin de disposer d’applications spécifiques à un domaine, très axées sur les données, pouvant exploiter une multitude de données issues du data lake pour générer des décisions éclairées pour le marketing, la supply chain, les ressources humaines, ou autre. Fondamentalement, c’est un endroit où vous pouvez centraliser toutes les données pour les fournir par lots à des applications intelligentes. Quant à la deuxième partie de votre question, les data lakes ont une longue histoire, remontant à l’idée du data warehousing et des data marts.
Kieran Chandler: Les data warehouses étaient une tendance que nous avons probablement vue il y a plus de 20 ans. Alors, qu’est-ce qui a changé entre alors et maintenant, et quelles sont les principales différences ?
Joannes Vermorel: C’est intéressant. Le mot à la mode de nos jours est « data lake » et « data scientist », tandis qu’il y a vingt ans, c’était « data warehouse » et « data mining », qui représentent en gros l’évolution des mêmes idées, revisitées vingt ans plus tard. Ce qui a changé, c’est plusieurs choses. Tout d’abord, la technologie des data lakes a évolué, ce qui les rend bien plus efficaces pour stocker et diffuser de grandes quantités de données. Puis, le cloud computing est intervenu, ce qui signifie qu’aujourd’hui, vous pouvez disposer de data lakes complètement à la demande, avec une facturation à l’usage par téraoctet. Cela est très différent de ce qu’il fallait faire il y a 20 ans, où il fallait acheter un appareil très coûteux, comme chez Oracle, pour stocker toutes vos données. De nos jours, avec les plateformes de cloud computing, vous pouvez avoir des téraoctets à la demande et à des tarifs extrêmement compétitifs.
Kieran Chandler: C’est en quelque sorte l’aspect technique. Qu’en est-il de la philosophie ? Qu’est-ce qui a changé dans la mentalité et dans notre utilisation des data lakes par rapport aux data warehouses ?
Joannes Vermorel: Il y a effectivement eu une évolution considérable. Le problème avec les data warehouses tels qu’ils étaient envisagés il y a 20 ans, c’est qu’ils imposaient une énorme pression sur le service informatique pour organiser correctement les données. Vous aviez même un data warehouse censé organiser des data marts, avec un data mart destiné à chaque division, comme le marketing, la supply chain, la finance, etc. Les data marts étaient comme des sous-ensembles au sein de votre data warehouse. Le problème de cette approche, qui était en quelque sorte similaire à l’esprit des data lakes actuels, est qu’elle nécessitait une organisation et une gestion importantes du côté informatique.
Kieran Chandler: Ce qui était fait pour la business intelligence, c’est qu’il y avait un niveau élevé, une attente considérable, sur le fait qu’il y aurait déjà une sorte de préparation, d’organisation, avec l’attachement, par exemple, des clients aux ventes et aux retours. Vous voyez, on collait les choses ensemble. Toutes les choses qui devaient aller ensemble demandaient en réalité beaucoup d’efforts. Techniquement, il s’agissait, vous savez, de joindre des tables, de connecter toutes ces tables ensemble avec des jointures adéquates. Ainsi, il y a 20 ans, la philosophie était de faire beaucoup, ce qui était assez similaire à ce qui se faisait en BI et naturellement pour les systèmes relationnels. Le problème avec cette approche était que le volume de travail requis était complètement énorme, aboutissant généralement à ce que les services informatiques soient complètement submergés par l’ampleur des exigences pesant sur eux à cause de ces projets de data warehousing. En conséquence, c’échouait fréquemment parce que, eh bien, le service informatique ne parvenait tout simplement pas à livrer. Mais qu’en est-il d’aujourd’hui ? J’imagine que la situation va devenir un peu chaotique maintenant que vous avez ces data lakes.
Joannes Vermorel: Les data lakes, d’un point de vue philosophique, sont bien plus allégés, car l’idée est qu’un data lake est simplement un récepteur pour une extraction brute, une extraction sans fioritures de toutes les données provenant d’autres systèmes. Vous n’essayez donc pas de faire une recombinaison sophistiquée des données issues du CRM, de l’ERP, ou de votre plateforme web. Vous allez simplement extraire ces sources de données et les déverser dans le data lake. Et le data lake se comporte bien grâce à la technologie, ce qui signifie que vous pouvez y déverser une quantité énorme de données, et il supportera la charge sans broncher. Si vous êtes sur le cloud, vous serez facturé pour cela.
Kieran Chandler: Comment savez-vous que les données que vous utilisez sont de bonne qualité ? Je veux dire, comment suivez-vous celles qui sont à jour ? Si vous les déversez toutes dans ce data lake, comment faites-vous le suivi ?
Joannes Vermorel: La responsabilité de l’informatique avec un data lake est de s’assurer que le data lake contient une représentation fidèle de ce qui se trouve dans les systèmes d’origine. Mais cela ne nécessite aucune compréhension de ce qui se passe au niveau commercial. Vous avez simplement un CRM qui comporte 200 tables, des tables relationnelles, et vous les répercutez dans le data lake, et voilà. Vous n’avez pas besoin de comprendre ce qui se passe dans le CRM.
Kieran Chandler: Alors, qui a besoin de comprendre ce qui se passe dans le CRM ?
Joannes Vermorel: Il s’avère que ce sont les divisions elles-mêmes qui veulent exploiter les données, et le problème est que l’interprétation des données est extrêmement spécifique à chaque problème. Par exemple, la façon d’analyser les données de ventes diffère selon que vous souhaitiez résoudre un problème de marketing ou un problème de supply chain. Voilà pourquoi, et c’était d’ailleurs l’une des raisons principales pour lesquelles, il y a vingt ans, de nombreuses initiatives d’entreposage de données ont échoué. C’était parce que la vision était de produire un modèle unifié de l’entreprise, mais il s’est avéré que c’était très frustrant pour chaque division, car le marketing disait : “Oh, cela ne correspond pas exactement à la vision que j’ai de mon domaine”, et la supply chain disait la même chose, et la Finance également. Ainsi, par contraste, l’idée est que désormais, ce sont plutôt les divisions elles-mêmes, comme la supply chain, le marketing, la finance, les ressources humaines.
Kieran Chandler: Cela signifie qu’ils ne vont pas échouer aujourd’hui. Je veux dire, encore une fois, qu’il y a une multitude de choses qui changent. Un défi particulier, surtout en supply chain, c’est que, par conception, nous travaillons avec des systèmes distribués. Que veux-je dire par distribué ? Je veux dire que tout n’est pas réuni en un seul endroit, car, par définition, si vous avez plusieurs entrepôts, ils ne se trouvent pas au même endroit. Vos fournisseurs ne sont pas au même endroit que vos entrepôts, et il en va de même pour vos clients. Ainsi, par définition, nous traitons avec des systèmes dispersés, et vous souhaitez consolider toutes ces données en un seul lieu, qui est votre data lake, ce qui, techniquement, doit se faire via le réseau.
Joannes Vermorel: Évidemment, il y a vingt ans, l’internet avait déjà été inventé. Il existait, mais la qualité des outils pour transférer des données sur internet était complètement différente de celle dont nous disposons aujourd’hui. Et de plus, le réseau, la qualité même du réseau, était également bien différente. De nos jours, si vous souhaitez transférer, disons, pour une entreprise pas très grande, une entreprise de 1 000 employés – donc de taille conséquente mais pas une méga-corporation – il y a vingt ans, si vous vouliez transférer un gigaoctet de données par jour sur internet, c’était compliqué.
Je veux dire, il fallait avoir accès à la fibre, par exemple, à Paris. Il n’y avait qu’un seul endroit à Paris, il y a vingt ans, où l’on pouvait accéder à la fibre, qui était la zone près de la Bourse. Il y avait environ un kilomètre carré où l’accès à la fibre était facile. Ailleurs, il fallait poser sa propre fibre si on la voulait. Ainsi, les méga-corporations pouvaient le faire, mais même une entreprise de taille conséquente, avec ses 1 000 employés, ne le pouvait pas. Cela a changé. Désormais, c’est très simple. Les outils sont meilleurs, et vous pouvez transférer littéralement des gigaoctets sans trop de tracas.
Et le fait de disposer de systèmes à la demande, ces data lakes ne sont pas seulement très bon marché, grâce aux économies d’échelle de ces plateformes de cloud computing, mais le fait qu’ils soient à la demande signifie que vous pouvez procéder par essais et erreurs. Si vous essayez simplement de mettre en place un data lake et que cela tourne complètement mal, vous pouvez simplement cliquer sur “delete” et réessayer, et vous ne payez que pour ce que vous utilisez. Ainsi, vous pouvez itérer rapidement. Ce n’est pas comme il y a vingt ans, lorsque vous deviez vous engager à acheter un appareil très coûteux et qu’une erreur posait un énorme problème.
Kieran Chandler: Et je parie que les services financiers disposent probablement encore de l’internet le plus rapide. Que diriez-vous à une grande multinationale qui a déjà une bonne maîtrise de ses données, qui comprend déjà les choses en utilisant des outils de business intelligence ? Je veux dire, pourquoi devraient-ils s’intéresser à un data lake ?
Joannes Vermorel: Le problème avec la business intelligence, c’est que, fondamentalement, elle est destinée aux humains. C’est bien, mais cela signifie que chaque minute que les gens passent à regarder ces chiffres est une minute où vous payez effectivement un employé pour examiner des chiffres au lieu de faire autre chose. Vous pouvez très facilement produire des millions de chiffres, ce qui nécessiterait des milliers d’heures de travail pour être traitées, ce qui est extrêmement coûteux.
Donc, le problème est que la business intelligence, telle que je la conçois, est une technologie assez dépassée. C’était une manière d’obtenir une analyse basique de vos données en quasi temps réel. C’était très intéressant car, si nous revenons trente ans en arrière, à l’époque où Business Objects a été fondée, ils étaient l’entreprise qui… Et autrement, vous ne pouviez tout simplement pas exécuter de requêtes synchronisées permettant d’obtenir ces informations : combien d’unités sont vendues par jour, par produit, etc. Cela n’était pas possible avec la business intelligence. Soudainement, il est devenu possible d’avoir ce cube, vous pouvez même avoir des hypercubes, et encore mieux, vous pouvez l’avoir de manière vraiment performante. Mais au final, vous n’obtenez qu’une agrégation très basique de vos données, et cette agrégation n’est pas une décision. Elle ne vous dit pas si vous devez augmenter ou baisser votre prix, ni si vous devez produire plus ou moins, ni si, dans un lot de production de 1 000 unités, vous devez expédier 100 unités en avion pour une livraison plus rapide. Fondamentalement, il s’agit simplement d’obtenir des insights quantitatifs. La grande différence entre, vous savez, la BI et le data lake, c’est que le data lake offre l’avantage d’être fondamentalement un rouage dans un ensemble plus vaste où, devant le data lake, vous aurez généralement une application pilotée par le machine learning qui analysera très efficacement les données fournies par le data lake afin de générer des décisions automatiquement. Et ces décisions auront un impact physique sur votre entreprise et créeront une valeur tangible d’une certaine manière.
Kieran Chandler: D’accord, donc si nous convenons que peut-être les outils de business intelligence présentent certaines limites, et en ce qui concerne la mise en place d’un data lake, qu’est-ce qui rend cela réellement facile à réaliser ? Est-ce simplement une question de télécharger toutes ces données sur le cloud et ensuite tout est prêt ?
Joannes Vermorel: La complexité de la mise en place d’un data lake est strictement proportionnelle à la complexité d’accéder à vos sources de données, c’est-à-dire, y accéder littéralement, sans rien faire d’astucieux avec elles. Cela signifie que, pour les grandes multinationals, eh bien, cela veut dire que si chaque pays de votre entreprise dispose de son propre système, eh bien, devinez quoi ? Vous aurez autant de types de data lakes à mettre en place afin de pouvoir intégrer les données de chaque pays dans le data lake. Mais, je veux dire, c’est regrettable, vous n’avez aucune alternative, car la seule alternative est d’avoir une intégration directe avec les pays eux-mêmes, et c’est encore plus coûteux, car si vous avez deux divisions, disons le marketing et la supply chain, qui souhaitent accéder aux données de ventes, vous paierez cette intégration deux fois. Ainsi, l’idée du data lake est que, une fois que vous l’avez mis en place, les données y sont intégrées, ce qui le rend très adapté pour que le reste de l’entreprise puisse y accéder. Donc, la complexité dépend entièrement de ce que vous avez. Mais encore une fois, si l’on revient à votre citation initiale, si vous n’avez pas de données, vous n’êtes qu’un homme avec une opinion. Eh bien, vous n’avez aucune alternative pour récupérer ces données si vous souhaitez effectuer des mesures.
Kieran Chandler: Rassemblons un peu les idées maintenant. S’il y a tant d’aspects positifs aux data lakes et qu’ils paraissent relativement simplistes – n’étant qu’un grand réceptacle de données au final – pourquoi n’est-il pas adopté massivement par l’industrie en ce moment ?
Joannes Vermorel: Il s’avère que de très petites entreprises axées sur la technologie ont adopté les data lakes il y a déjà un bon moment, et elles sont même allées plus loin avec, je dirais, l’API-fication de leur entreprise, ce qui signifie que vous allez mettre une API (Application Programming Interface) sur chaque sous-système, ce qui constitue la prochaine étape après le data lake. Donc, je dirais que le smart e-commerce, par exemple, a déjà consolidé ses données, et cela.
Kieran Chandler: Il faut jeter un œil aux deux aujourd’hui : ce qui provient du site web, ce que vous payez pour le marketing de marchandises sur les moteurs de recherche, vous savez, les Google AdWords et autres, et les commandes croisées. Ils sont capables de prendre des décisions intelligentes en termes d’actions de marketing direct, etc. Quant aux entreprises purement technologiques comme Microsoft ou Google, elles font également des choses similaires, littéralement depuis des décennies. Je veux dire, Google n’existe que depuis deux décennies, mais d’autres entreprises, comme toutes les entreprises technologiques, font cela depuis bien longtemps déjà. Alors, s’ils le font depuis des décennies, qu’en est-il de l’avenir ? Quelle est la prochaine étape ? Allons-nous parfois plonger dans un océan de données ?
Joannes Vermorel: Oui, je veux dire, ce que je vois pour la suite, c’est que les entreprises très orientées supply chain, maintenant que les data lakes sont devenus très accessibles et très bon marché, vont implémenter ces data lakes. Nous constatons chez nos clients qu’un grand nombre de clients qui n’avaient pas de data lake il y a un an en ont maintenant un. Je dirais qu’il y a eu un tournant dans les deux dernières années concernant les data lakes. Je soupçonne donc que la plupart des grandes entreprises, dans les prochaines – probablement cinq ans – auront effectivement mis en place leurs propres data lakes, car sinon, elles se feraient complètement dépasser par toutes les grandes entreprises qui l’auront fait pour elles.
Mais il y a aussi des limites, notamment, un data lake n’est qu’une copie en lecture seule de toutes les données qui se trouvent dans d’autres sous-systèmes. C’est pourquoi je disais que la prochaine étape consiste à faire en sorte que tous les sous-systèmes exposent des APIs, interfaces de programmation applicative, car c’est ce qu’a fait Amazon. Ces APIs vous permettent de faire encore plus : soudainement, vous n’êtes plus seulement en lecture seule, vous pouvez aussi agir. L’idée est que vous pouvez consolider toutes les données, les lire, les analyser, prendre toutes ces décisions, et ensuite, que fait-on de ces décisions calculées ? La réponse est que vous pouvez envoyer le tableur Excel à la bonne division afin qu’elle mette en œuvre vos décisions, telles que l’achat. Mais s’il existe une API, vous pouvez directement appeler cette API pour simplement injecter le bon de commande pour ce produit, pour cette quantité, de ce fournisseur, en précisant ce mode de transport, etc. Ainsi, vous pouvez réellement, si vous disposez d’APIs, avoir des automatisations de bout en bout où vous ne générez pas seulement la décision automatiquement, mais ensuite vous mettez en œuvre ces décisions physiquement de manière automatique parce qu’elles sont réinjectées dans l’un des systèmes.
Kieran Chandler: D’accord, nous allons devoir en rester là, mais merci pour votre temps aujourd’hui. Donc, c’est tout pour cette semaine. Merci beaucoup de nous avoir écoutés, et nous reviendrons la prochaine fois. Au revoir pour l’instant.
