00:00:08 Les data lakes et leur importance.
00:00:39 Définition des data lakes et leur rôle dans les affaires.
00:02:13 L’évolution des data lakes à partir des entrepôts de données.
00:04:15 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 entrepôts de données depuis 20 ans.
00:12:14 Les avantages des systèmes à la demande dans les data lakes.
00:13:31 Limitations de l’intelligence d’affaires et de son approche obsolète.
00:15:22 Comparaison de l’intelligence d’affaires aux data lakes et à leur capacité à éclairer la prise de décision.
00:16:49 Complexité de la mise en œuvre : accès aux sources de données et impact sur les entreprises multinationales.
00:18:32 Adoption des data lakes : avantages pour les entreprises axées sur la technologie et leur utilisation dans l’optimisation interfonctionnelle.
00:20:08 L’avenir des data lakes : augmentation de l’accessibilité et de la mise en œuvre, prochaines étapes avec les interfaces de programmation d’applications (API).
00:22:45 Remarques de clôture et conclusion.
Résumé
Dans cette interview, Kieran Chandler et Joannes Vermorel, fondateur de Lokad, discutent des data lakes et de leur rôle dans l’optimisation de la supply chain. Les data lakes sont des référentiels centralisés de données brutes qui permettent aux applications basées sur l’apprentissage automatique de prendre des décisions intelligentes. Vermorel souligne les limites des outils traditionnels de business intelligence, en insistant sur le fait que les data lakes offrent une analyse de 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 se sont tournées vers la mise en œuvre d’interfaces de programmation d’applications (API) pour leurs sous-systèmes, permettant ainsi une automatisation de bout en bout. Vermorel prédit que les grandes entreprises adopteront de plus en plus les data lakes et les API au cours des cinq prochaines années pour une meilleure prise de décision basée sur les données.
Résumé étendu
Dans cette interview, Kieran Chandler discute des data lakes avec Joannes Vermorel, fondateur de Lokad, une entreprise spécialisée dans l’optimisation de la supply chain. Ils commencent par définir les data lakes et leur origine. Les data lakes sont un type de base de données conçu pour consolider l’ensemble des données transactionnelles essentielles d’une entreprise, telles que les ventes, les achats et les niveaux de stock. Ces bases de données sont destinées à être utilisées par des applications, plutôt que par des humains, permettant aux applications spécifiques à un domaine et axées sur les données de prendre des décisions intelligentes en matière de marketing, de supply chain, de ressources humaines, et bien plus encore.
Les data lakes ont une histoire qui remonte à plus de 20 ans, à l’époque des entrepôts de données et des data marts. Vermorel explique que la principale différence entre les data lakes et les entrepôts de données réside dans la technologie et la philosophie qui les sous-tendent. Les data lakes sont plus efficaces pour stocker et servir de grandes quantités de données, tandis que le cloud computing les rend plus accessibles et abordables.
Il y a vingt ans, une entreprise devait acheter un appareil coûteux, tel qu’un appareil Oracle, pour héberger son entrepôt de données. Aujourd’hui, grâce aux plateformes de cloud computing, les entreprises peuvent disposer de data lakes à la demande, évolutifs et à des prix compétitifs. Cette flexibilité permet aux entreprises d’ajuster facilement leur approche de stockage des données si nécessaire.
La philosophie des data lakes a également évolué par rapport aux entrepôts de données. L’approche précédente mettait beaucoup de pression sur les services informatiques pour organiser et gérer correctement les données. Les entrepôts de données é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 la gestion et l’accès aux données entre les différents services.
Les data lakes visent à consolider les données de manière plus centralisée et accessible, ce qui facilite le traitement des applications et la prise de décisions intelligentes. 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, l’entreposage de données était une méthode populaire pour gérer et organiser les données. Cette approche nécessitait un effort technique important pour connecter différentes tables de données et nécessitait un modèle unifié des données de l’entreprise. Cependant, cette méthode entraînait souvent une surcharge de travail pour les services informatiques et de nombreux projets échouaient.
Aujourd’hui, les data lakes se sont imposés comme une approche plus légère et plus efficace de la gestion des données. Les data lakes servent de référentiel pour les données brutes extraites de différents systèmes tels que CRM, ERP et plateformes web. Au lieu de tenter d’organiser ou de combiner les données, elles sont simplement stockées dans le data lake, qui peut gérer de grandes quantités de données sans problème.
L’un des défis de l’utilisation des data lakes est de s’assurer que les données sont précises et à jour. Les services informatiques sont responsables de veiller à ce que le data lake contienne une réflexion précise des systèmes d’origine, mais ils n’ont pas besoin de comprendre les implications commerciales des données. La responsabilité de comprendre les données du CRM, par exemple, incombe aux divisions qui l’utilisent, telles que les ventes ou le marketing. Cette approche permet une interprétation plus spécifique aux problèmes des données, car les différentes divisions peuvent avoir des besoins et des perspectives différentes sur les données.
Le paysage technologique a considérablement évolué depuis l’époque des entrepôts de données, ce qui rend les data lakes plus viables. Tout d’abord, la qualité des outils de transfert de données sur Internet s’est améliorée, ce qui facilite 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, ce qui permet même aux petites entreprises de transférer de grandes quantités de données sans difficulté.
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, ce qui permet aux entreprises d’expérimenter les data lakes sans prendre de risques financiers importants.
Les outils de business intelligence ont été utiles aux entreprises pour tirer des enseignements de leurs données, mais 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 entreprises multinationales souhaitant 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’optimisation de la supply chain.
Vermorel décrit la BI comme une technologie obsolète qui ne fournit qu’une analyse de base des données de manière quelque peu temps réel. Cette technologie était révolutionnaire il y a 30 ans, permettant aux entreprises d’accéder et d’agréger leurs données, mais elle n’offre pas d’informations ou de décisions exploitables. En revanche, les data lakes font partie d’une vision plus large, servant de référentiel de stockage pour les données brutes provenant de différentes sources. Les applications basées sur l’apprentissage automatique peuvent ensuite traiter efficacement ces données pour générer des décisions exploitables qui ont un impact sur l’entreprise et créent une valeur tangible.
La mise en place d’un data lake dépend de la complexité de l’accès aux sources de données d’une entreprise. Pour les grandes entreprises multinationales, cela peut être un processus difficile, car chaque pays peut avoir son propre système. Cependant, il n’y a pas d’alternatives si une entreprise souhaite tirer des enseignements 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 les ont même dépassés en mettant en œuvre des interfaces de programmation d’applications (API) pour leurs sous-systèmes. Cela permet une optimisation interfonctionnelle et une prise de décision intelligente.
Vermorel estime que les grandes entreprises adopteront de plus en plus les data lakes au cours des cinq prochaines années, car ils deviendront plus accessibles et abordables. Les entreprises qui ne mettent pas en place de data lakes risquent d’être surpassées par celles qui l’ont déjà fait. Cependant, les data lakes ne sont pas l’étape finale de la gestion des données. Vermorel suggère que les API sont l’avenir, permettant aux entreprises non seulement de lire et d’analyser les données, mais aussi d’agir en fonction d’elles. Les API peuvent permettre une automatisation de bout en bout, générant automatiquement des décisions 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’optimisation de la supply chain. Il envisage un avenir où les grandes entreprises mettent en place des data lakes et des API 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 de data lakes et comprendre pourquoi ces entreprises devraient s’y intéresser davantage. Alors Joannes, comme toujours, peut-être devrions-nous commencer par définir un peu plus ce que sont les data lakes et d’où ils viennent.
Joannes Vermorel: Un data lake est généralement une sorte de base de données avec certaines particularités, qui vise à consolider pratiquement toutes les données essentielles 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 stock, etc. L’intention et l’utilisation finale du data lake est qu’il est censé être destiné aux applications, pas aux humains. L’idée est que vous mettez en place un data lake afin de pouvoir avoir des applications spécifiques à un domaine qui sont très axées sur les données et peuvent utiliser des tonnes de données provenant du data lake pour générer des décisions intelligentes en matière de marketing, de supply chain, de ressources humaines, ou autre. Fondamentalement, c’est un endroit où vous pouvez consolider toutes les données pour les servir en lots à des applications intelligentes. Quant à la deuxième partie de votre question, les data lakes ont une longue histoire, remontant à l’idée de l’informatique décisionnelle et des entrepôts de données.
Kieran Chandler: Les entrepôts de données étaient une tendance que nous avons vue il y a probablement plus de 20 ans. Alors, qu’est-ce qui a changé entre-temps 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”, alors qu’il y a vingt ans, c’était “data warehouse” et “data mining”, qui sont essentiellement la même évolution des mêmes idées, juste revisitées vingt ans plus tard. Ce qui a changé, ce sont plusieurs choses. Tout d’abord, la technologie des data lakes a évolué, de sorte qu’ils sont beaucoup plus efficaces pour stocker et servir de grandes quantités de données. Ensuite, nous avons eu l’informatique en nuage au milieu, ce qui signifie qu’aujourd’hui, vous pouvez avoir des data lakes entièrement à la demande avec une tarification au téraoctet à la consommation. C’est assez différent par rapport à il y a 20 ans, où vous auriez dû acheter un appareil très coûteux, comme chez Oracle, pour stocker toutes vos données. De nos jours, avec les plateformes d’informatique en nuage, vous pouvez avoir des téraoctets à la consommation et être extrêmement agressif en termes de tarification.
Kieran Chandler: C’est un peu le côté technique des choses. Et la philosophie ? Qu’est-ce qui a changé dans la mentalité et la façon dont nous utilisons les data lakes par rapport aux entrepôts de données ?
Joannes Vermorel: Il y a en effet eu une évolution assez importante. Le problème avec les entrepôts de données tels qu’ils étaient conçus il y a 20 ans est qu’ils mettaient beaucoup de pression sur les services informatiques pour organiser correctement les données. Vous aviez même un entrepôt de données qui était censé organiser des data marts, avec un data mart destiné à chaque type de division, comme le marketing, la supply chain, la finance, etc. Les data marts étaient comme des sous-ensembles ou des sous-systèmes au sein de votre entrepôt de données. Le problème avec cette approche, qui était un peu similaire dans l’esprit aux data lakes que nous avons aujourd’hui, c’est qu’elle nécessitait beaucoup d’organisation et de gestion de la part des services informatiques.
Kieran Chandler: Ce qui a été fait pour l’intelligence d’affaires, c’est qu’il y avait un niveau élevé, un degré élevé d’attentes sur le fait qu’il y aurait déjà une sorte de préparation, d’organisation, vous savez, avec où vous avez attaché, vous savez, les clients aux ventes aux retours. Donc, vous savez, vous collez les choses ensemble. Toutes les choses qui vont ensemble, c’est beaucoup d’efforts, en fait. Techniquement, il s’agit de, vous savez, joindre des tables, c’est de connecter toutes ces tables ensemble avec une jointure appropriée. Donc, il y a 20 ans, la philosophie était de faire beaucoup, et c’était donc assez similaire à ce qui était fait en BI et assez similaire à ce qui était fait naturellement pour les systèmes relationnels. Le problème avec cette approche était que la quantité de travail qu’elle nécessite est complètement énorme, et donc vous vous retrouvez généralement avec des divisions informatiques qui étaient complètement submergées par la quantité de demandes qui leur tombaient dessus à cause de ces projets d’entrepôts de données. Par conséquent, fréquemment, cela échouait parce que, eh bien, simplement l’informatique n’arrivait pas à livrer. Mais qu’en est-il aujourd’hui ? Je veux dire, sûrement les choses vont devenir un peu chaotiques maintenant que vous avez ces data lakes.
Joannes Vermorel: Les data lakes, en termes de philosophie, sont beaucoup plus légers car la philosophie est que le data lake est simplement un réceptacle pour une extraction propre, mais une extraction propre de toutes les données qui se trouvent dans d’autres systèmes. Donc, vous n’essayez pas de faire une quelconque recomposition fantaisiste des données qui proviennent du CRM, plus les données qui proviennent de l’ERP, plus les données qui proviennent 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 déverser une énorme quantité de données et qu’il gérera la charge sans se plaindre. Si vous êtes dans le cloud, vous serez facturé pour cela.
Kieran Chandler: Comment savez-vous que les données que vous utilisez sont des bonnes données ? Je veux dire, comment suivez-vous quelles données sont à jour ? Je veux dire, si vous les déversez toutes dans ce lac, comment faites-vous le suivi ?
Joannes Vermorel: La responsabilité des services informatiques avec un data lake est de s’assurer que le data lake contient une réflexion précise de ce qui se trouve dans les systèmes d’origine. Mais cela ne nécessite aucune compréhension de ce qui se passe sur le plan commercial. Vous avez simplement un CRM qui a 200 tables relationnelles, et vous les reflétez simplement dans le data lake, et c’est tout. Vous n’avez pas besoin de comprendre ce qui se passe dans le CRM.
Kieran Chandler: Donc, qui doit 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 très spécifique au problème. Par exemple, la façon dont vous regardez les données de vente est différente selon que vous voulez résoudre un problème marketing ou un problème de supply chain. C’est pourquoi, et c’était aussi l’une des principales raisons pour lesquelles, il y a vingt ans, bon nombre de ces initiatives d’entrepôts de données ont échoué. C’est 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 les finances disaient la même chose. En revanche, l’idée est maintenant que ce sont plutôt les divisions elles-mêmes, comme la supply chain, le marketing, les finances, les ressources humaines.
Kieran Chandler: Cela signifie qu’elles ne vont pas échouer aujourd’hui. Je veux dire, il y a encore beaucoup de choses qui changent. Un défi particulier, surtout dans la supply chain, est que nous traitons par nature avec des systèmes distribués. Que veux-je dire par distribué ? Je veux dire que tout n’est pas au même endroit car, par définition, si vous avez plusieurs entrepôts, ils ne sont pas au même endroit. Vos fournisseurs ne sont pas au même endroit que vos entrepôts, et vos clients non plus. Donc, par définition, nous examinons des systèmes dispersés, et vous voulez consolider toutes ces données en un seul endroit, qui est votre data lake, ce qui doit techniquement se faire via le réseau.
Joannes Vermorel: De toute évidence, il y a vingt ans, Internet avait déjà été inventé. Il existait, mais la qualité des outils pour déplacer des données à travers Internet était complètement différente par rapport à ce que nous avons aujourd’hui. Et puis le réseau lui-même, la qualité du réseau, était également complètement différente. De nos jours, si vous voulez déplacer, disons, pour une entreprise de taille moyenne, une entreprise de 1 000 employés, donc vous êtes important mais pas une méga-corporation. Il y a vingt ans, si vous vouliez déplacer un gigaoctet de données par jour à travers Internet, c’était compliqué.
Je veux dire, vous deviez avoir accès à la fibre, par exemple, à Paris. Il n’y avait qu’un seul endroit à Paris il y a vingt ans où vous pouviez avoir accès à la fibre, qui était la zone près de la Bourse. Il y avait environ un kilomètre carré où vous pouviez facilement avoir accès à la fibre. Partout ailleurs, vous deviez poser votre propre fibre si vous la vouliez. Les méga-corporations pouvaient le faire, mais même une entreprise de taille importante, vous savez, avec 1 000 employés, ne le pouvait pas. Cela a changé. Maintenant, c’est très simple. Les outils sont meilleurs, et vous pouvez déplacer littéralement des gigaoctets sans trop de tracas.
Et le fait que vous disposiez de systèmes à la demande, ces lacs de données 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 faire des essais et des erreurs. Si vous essayez simplement de mettre en place un lac de données et que c’est un échec complet, vous pouvez simplement dire “supprimer” 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 cher, et si vous vous trompiez, c’était un gros problème.
Kieran Chandler: Et je parie que ces zones financières ont probablement toujours Internet le plus rapide. Que diriez-vous à une grande entreprise multinationale qui maîtrise déjà bien ses données, qui comprend déjà les choses à l’aide d’outils de business intelligence ? Je veux dire, pourquoi devraient-elles s’intéresser à un lac de données ?
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 vont passer à regarder ces chiffres est une minute où vous payez réellement un employé pour regarder des chiffres au lieu de faire autre chose. Vous pouvez très facilement produire des millions de chiffres, ce qui nécessitera des milliers d’heures de travail pour être traités, ce qui est extrêmement coûteux.
Donc, le problème est que la business intelligence, telle que je la vois, est un type de technologie assez dépassée. C’était un moyen d’obtenir une analyse de base de vos données de manière relativement en temps réel. C’était très intéressant car, si nous remontons il y a 30 ans, à l’époque où Business Objects a été fondée, ils étaient la société qui. Et sinon, vous ne pouviez tout simplement pas savoir que vous ne pouviez pas effectuer de requêtes synchronisées qui vous donneraient ces informations : combien d’unités sont vendues par jour, par produit, et ainsi de suite. Cela n’était pas possible avec la business intelligence. Soudain, il était possible d’avoir ce cube, vous pouvez même avoir des hypercubes, et encore mieux, vous pouvez l’avoir très, très bien. Mais ensuite, en fin de compte, vous ne regardez qu’une agrégation très basique de vos données, et cette agrégation n’est pas une décision. Cela ne vous dit pas si vous devez augmenter ou baisser votre prix, cela ne vous dit pas si vous devez produire plus ou moins, cela ne vous dit pas si, sur un lot de production de 1000 unités, vous devez mettre 100 unités dans un avion pour une livraison plus rapide. Fondamentalement, il s’agit simplement d’obtenir des informations quantitatives. La grande différence entre, vous savez, la BI et le lac de données, c’est que le lac de données s’inscrit dans une vision plus large où, assis devant le lac de données, vous aurez généralement une application pilotée par l’apprentissage automatique qui traitera les données servies de manière très efficace par le lac de données afin de générer automatiquement des décisions. Et ces décisions, ce sont des choses qui ont un impact physique sur votre entreprise et qui créeront une valeur tangible d’une manière ou d’une autre.
Kieran Chandler: D’accord, donc si nous convenons que peut-être les outils de business intelligence ont leurs limites, et s’il s’agit de mettre en œuvre un lac de données, à quel point est-ce facile à faire ? Est-ce simplement une question de téléchargement de toutes ces données sur le cloud, et ensuite vous êtes prêt à partir ?
Joannes Vermorel: La complexité de la mise en œuvre d’un lac de données est strictement proportionnelle à la complexité d’accès à vos sources de données, vous savez, y accéder littéralement, sans faire quoi que ce soit de intelligent avec elles. Cela signifie donc, pour les grandes multinationales, que si chaque pays de votre entreprise a son propre système, devinez quoi ? Vous aurez autant de types de lacs de données à mettre en place pour pouvoir amener les données de chaque pays dans le lac de données. Mais je veux dire, c’est malheureux, vous n’avez pas d’autre choix car la seule alternative est d’avoir une intégration directe avec les pays directement, et cela coûte encore plus cher car si vous avez deux divisions, disons le marketing et la supply chain, qui veulent accéder aux données de vente, vous paierez cette intégration deux fois. L’idée avec un lac de données est que vous le faites une fois, puis il est dans le lac de données, ce qui le rend très adapté pour le reste de l’entreprise pour accéder aux données. La complexité dépend complètement de ce que vous avez. Mais aussi, encore une fois, si nous revenons à 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 autre alternative pour récupérer ces données n’importe où si vous voulez faire des mesures.
Kieran Chandler: Regroupons maintenant les choses. S’il y a tant d’aspects positifs aux lacs de données et que cela semble assez simpliste, c’est simplement un grand réceptacle de données à la fin de la journée, pourquoi est-ce quelque chose qui n’est pas adopté facilement 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 lacs de données il y a déjà un certain temps, et elles sont même allées au-delà avec, je dirais, l’API-fication de leur entreprise, ce qui signifie que vous allez mettre une API (Interface de programmation d’application) sur chaque sous-système, ce qui est comme la prochaine étape qui se produit après le lac de données. Donc, je dirais que les entreprises de commerce électronique intelligentes, par exemple, ont déjà consolidé leurs données, et ainsi de suite.
Kieran Chandler: Vous devez regarder à la fois aujourd’hui, ce qui provient du site web, ce que vous payez pour le marketing des marchandises des 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, et ainsi de suite. En ce qui concerne les entreprises purement axées sur la technologie comme Microsoft ou Google, elles ont également fait des choses similaires, vous savez, depuis littéralement des décennies. Je veux dire, Google existe depuis seulement deux décennies, mais d’autres entreprises comme toutes les entreprises technologiques le font depuis un certain temps maintenant. Donc, s’ils font cela depuis des décennies, qu’en est-il de l’avenir ? Qu’est-ce qui vient ensuite ? Allons-nous plonger dans un océan de données parfois ?
Joannes Vermorel: Oui, je veux dire, ce que je peux voir ensuite, c’est que les entreprises très axées sur la supply chain, maintenant que les lacs de données sont devenus très accessibles et très bon marché, mettront en œuvre ces lacs de données. Nous constatons parmi nos clients que de nombreux clients qui n’avaient pas de lac de données il y a un an en ont maintenant un. Je dirais qu’il y a eu un tournant au cours des deux dernières années en ce qui concerne les questions de lac de données. Donc, je suppose que la plupart des grandes entreprises auront, dans les cinq prochaines années, vraiment mis en œuvre leurs propres lacs de données, car sinon, elles seraient complètement dépassées par toutes les grandes entreprises qui l’auront fait pour elles.
Mais il y a aussi des limites, en particulier, un lac de données est simplement 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 à ce que tous les sous-systèmes exposent des API, des interfaces de programmation d’applications, car c’est ce qu’Amazon a fait. Ces API vous permettent de faire encore plus, soudainement vous n’êtes plus seulement en lecture seule, vous pouvez également 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 faisons-nous de ces décisions qui ont été calculées ? La réponse est que vous pouvez envoyer le fichier Excel spreadsheet à la division appropriée afin qu’elle mette en œuvre vos décisions, telles que les achats. Mais s’il y a une API, vous pouvez appeler directement cette API pour injecter directement la commande d’achat pour ce produit, de cette quantité, de ce fournisseur, avec ce mode de transport spécifié, etc. Ainsi, si vous disposez d’API, vous pouvez automatiser l’ensemble du processus où vous ne générez pas seulement la décision automatiquement, mais vous mettez également en œuvre ces décisions physiquement automatiquement car elles sont réinjectées dans l’un des systèmes.
Kieran Chandler: D’accord, nous devons en rester là, mais merci pour votre temps aujourd’hui. C’est tout pour cette semaine. Merci beaucoup de nous avoir suivi et nous serons de retour la prochaine fois. Au revoir pour le moment.
