Vidéo

Discours liminaire du directeur technique Jeremiah Stone, directeur technique chez SnapLogic [Integreat 2025]

Transcription :

Merci, Dayle, et merci à tous d'être ici avec nous aujourd'hui. C'est une époque incroyable pour être en vie, pour exercer notre profession.

Vous savez, je suis régulièrement enthousiasmé par les progrès réalisés par le monde universitaire en matière de création de nouvelles technologies qui peuvent nous aider à faire progresser l'espèce humaine, à mieux gérer la planète, à mieux gérer les sociétés, à offrir de meilleurs soins de santé et de meilleurs services aux populations du monde entier. C'est passionnant de participer à cela, et c'est ce qui est vraiment formidable dans le domaine de l'intégration : nous rassemblons les gens, nous rassemblons les technologies et nous obtenons des résultats commerciaux. Merci donc pour ce que vous faites chaque jour.

C'est un héroïsme méconnu et, ayant moi-même occupé ce poste, je le sais très bien. C'est donc toujours un grand plaisir pour moi de participer à ces événements.

Dale a parlé de notre façon de penser, de fonctionner, et je pense qu'il est logique de commencer par là pour entreprendre un parcours ensemble. C'est vraiment notre priorité avec notre clientèle et nos partenaires, et c'est au cœur de notre réflexion sur la manière dont nous relevons les défis quotidiens. L'une des choses sur lesquelles nous voulons vraiment insister et nous engager à nouveau, c'est la co-innovation avec nos clients et la collaboration pour accélérer la création de valeur, éliminer le gaspillage, les frictions et les défis de notre travail quotidien, et créer un véritable avantage concurrentiel.

Nous ne sommes donc pas ici pour parler du middleware en soi ou des bits et des octets, mais plutôt pour travailler à rebours à partir de la technologie, vous savez, les résultats commerciaux que nous devons absolument aider à atteindre avec nos collègues dans différents domaines. Vous devez donc toujours inviter à nouveau si vous travaillez sur quelque chose de difficile, nous voulons être aussi proches que possible des problèmes difficiles et vous aider à les résoudre et à apporter une grande valeur commerciale, et vraiment profiter de ce moment pour saisir un avantage concurrentiel et bouleverser vos propres industries. Et c'est passionnant de participer à bon nombre de ces initiatives.

Nous avons tenu notre conseil consultatif des directeurs informatiques hier, avant l'événement. Nous organisons deux événements de ce type par an.

Et le nombre d'entreprises membres de notre conseil consultatif qui adoptent des approches vraiment disruptives pour rester compétitives a vraiment explosé. Je pense que ces deux dernières années ont été des années d'expérimentation, d'observation ciblée, disons, de tests de maturité technologique.

Nous assistons aujourd'hui à une transition complète vers la mise en œuvre. Je voudrais vous présenter certaines des mesures que nous prenons, sans complexe et avec humilité, dans notre domaine afin de contribuer à la réalisation de cet objectif.

Et ce que nous constatons réellement, je pense, c'est que le mouvement est déjà en marche, qu'à terme, nous verrons l'IA agentique prendre en charge et automatiser un nouveau domaine de processus métier et traiter différents types de données, de flux de processus métier, etc. que nous ne pouvions pas traiter auparavant, ce qui a un impact. Cela a un impact sur la réduction du temps de cycle dans les processus métier existants.

Cela a un impact, cela réduit le nombre d'interventions manuelles nécessaires et cela contribue à faire avancer les organisations. Cela fait également perdre beaucoup de temps à des personnes qui ne savent pas de quoi elles parlent, qui ne font pas la preuve de concept et qui créent beaucoup de difficultés, mais je pense que nous sommes très concentrés sur l'aide à l'identification des domaines dans lesquels cette technologie a du sens et sur l'aide à sa mise en production.

Et de notre point de vue, les principes fondamentaux restent valables. Nous sommes donc convaincus depuis longtemps qu'une approche axée sur les données et modulable de l'architecture d'entreprise est essentielle pour améliorer les processus métier, fournir des services à l'ensemble de l'entreprise ou aux clients, et nous continuons de croire que les processus axés sur les données et l'architecture orientée services favorisent également les investissements agents.

Et la bonne nouvelle, c'est que nous constatons que les premiers utilisateurs travaillent en fait à rebours. Cela dit, nous voulons repenser et réinventer une partie de notre paysage d'entreprise.

Que pouvons-nous faire aujourd'hui avec les nouvelles technologies pour aborder les problèmes qui se posent ici et examiner certaines parties de l'architecture afin d'adopter une approche modulable ou, vous savez, travailler sur la connectivité des données sous-jacentes, la gestion des données afin d'y parvenir. La bonne nouvelle, c'est que nous constatons clairement qu'il est possible d'adopter une approche axée sur les résultats et de procéder à une refonte progressive pour obtenir des résultats, ce qui est vraiment passionnant.

L'impact de cette évolution est toutefois considérable. À mesure que nous renforçons l'automatisation et que nous augmentons notre capacité à exécuter des processus 24 heures sur 24, 7 jours sur 7, sans être limités par nos horaires de travail, cela modifiera l'impact sur nos environnements sous-jacents.

Nous allons adopter une approche différente en matière de volume, et tous ceux qui travaillent dans le secteur industriel ont pu constater que lorsque nous mettons en œuvre des technologies opérationnelles, la convergence des technologies de l'information, les architectures IT/OT, cela modifie le profil de charge, la fréquence et le volume des demandes, et je pense que nous assistons ici au même phénomène. Le parcours d'investissement que beaucoup d'entre nous ont suivi ensemble pour évoluer vers une architecture centrée sur des API faiblement couplées est donc d'autant plus important si vous cherchez maintenant à disposer d'un agent.

Un agent n'est rien d'autre qu'une boucle avec un modèle linguistique en son centre, et cela commence à avoir un impact réel si vous faites appel à des services d'entreprise, dans le monde sous-jacent. Cela continue donc d'avoir un impact majeur et de représenter un domaine d'investissement important, en particulier pour les autres acteurs de votre environnement.

Je pense donc que la grande majorité d'entre nous travaille avec un ou plusieurs méga-fournisseurs, souvent trois ou quatre, et que chacune de ces entreprises développe ses propres capacités dans le domaine de l'IA agentielle et prétend être la solution miracle pour tout, capable de résoudre tous les problèmes pour tout le monde. Je pense que ce que nous constatons dans ces premières versions, et même à mesure qu'elles mûrissent, c'est que, comme c'était le cas avec une architecture centrée sur les API ou une architecture orientée services, la plupart des méga-fournisseurs sont performants dans leur domaine, mais dès que vous sortez de ce domaine, cela devient très difficile.

La disponibilité des données pour ces capacités y est donc limitée, ce qui signifie que si vos processus métier restent dans le domaine, tout va bien. Mais combien de nos processus métier restent dans un seul domaine ? Vous savez, c'est un sous-ensemble.

La plupart de nos processus importants et influents sont multidomaines et transversaux, vous savez, le paysage que nous avons depuis l'avant-bureau jusqu'à l'arrière-bureau et notre capacité à prendre en compte et à convertir les exigences d'un client et à fournir cette valeur commerciale s'étend à l'ensemble de l'espace et je pense que c'est vraiment là que nous voyons notre valeur, à savoir être capable de traverser ces différents domaines et de prendre en charge une infrastructure diversifiée où vous avez des choix d'achat de technologie et où vous n'avez pas à vous standardiser dans un domaine particulier. Je pense que les défis auxquels nous sommes confrontés sont assez répétitifs.

Nous pouvons parler de la puissance croissante d'un modèle linguistique donné ou d'une certaine capacité. Cependant, malgré les capacités de ces modèles, ils n'ont pas accès à vos données.

Ils n'ont pas accès à vos systèmes de domaine. Ils ne peuvent pas atteindre ces systèmes, et s'ils le pouvaient, vous enfreindriez probablement vos exigences en matière de confidentialité ou vos exigences réglementaires de toute façon, sans aucune amélioration de la gouvernance.

Nous constatons également une adoption massive dans les différents secteurs d'activité, avec une sorte de « bring your own AI » (apportez votre propre IA), où les gens travaillent avec ces systèmes et les intègrent. Qui ici a plus de 10 ou 15 systèmes d'IA différents en fonctionnement dans son environnement ? Une centaine, deux cents, personne ne lève la main, personne ne veut l'admettre, d'accord, il y en a quelques-uns ici.

Il est certain que chaque nouvelle architecture apporte ses propres systèmes, et que les employés apportent également leurs propres systèmes, qu'il s'agisse cloud de bureau, du chat IA ouvert, du GPT, etc. Cela soulève alors des défis en matière de confidentialité et de gouvernance, qu'il est absolument nécessaire de gérer.

Mais ce n'est pas vraiment nouveau, n'est-ce pas ? Nous avons été confrontés à ces problèmes à chaque nouvelle vague technologique, qu'il s'agisse de l'expansion du cloud nous gérions nos systèmes sur site, de la création du traitement analytique en ligne et de la séparation des données entre les applications et le stockage des données. Et bien sûr, à chaque fois, nous avons dû gérer un nouvel acronyme et une nouvelle technologie. Vous connaissez MCP A2A, vous connaissez les derniers acronymes à apparaître ici, « model context protocol agent to agent », ne sont que les derniers en date de ce qui n'est qu'une accumulation de dette technique gérée à travers vos environnements, car bien sûr, nous devons gérer la technologie au fil du temps. Nous ne pouvons pas, vous le savez, prendre une décision à un moment donné et nous en accommoder.

En fait, c'est l'accumulation des décisions prises au fil du temps qui dicte nos activités quotidiennes et la majeure partie de notre travail. Et c'est pour cela que nous sommes faits.

Nous sommes conçus pour aider à gérer la dette technique au fil du temps, pour aider à gérer l'évolution de l'architecture du système au fil du temps à un coût et une charge beaucoup moins élevés pour vous et vos collègues, afin de pouvoir évoluer en permanence avec les environnements et de pouvoir tout regrouper, depuis les ordinateurs centraux qui constituent nos systèmes hérités et qui continuent de fonctionner. Vous savez, notre propre technologie sur site, environ 50 % de la technologie d'entreprise est encore gérée sur site ou par des fournisseurs de services gérés ou cloud . C'est fondamentalement ainsi que nous abordons la question.

Mais je souhaite prendre du recul et réfléchir à cela d'un point de vue, disons, architectural et philosophique, car souvent, lorsque je discute avec des membres de notre communauté qui nous accompagnent depuis un certain temps, nous perdons de vue la stratégie sous-jacente qui détermine notre approche de ces questions et qui influence la manière dont nous les aborderons à l'avenir. Ainsi, notre approche pour adopter toute nouvelle technologie, y compris dans le domaine de l'IA, consiste à considérer d'abord les choses comme étant très hétérogènes et diverses.

Comme je l'ai mentionné, que ce soit pour les systèmes que nous avons mis en place il y a dix ou vingt ans ou ceux que nous avons mis en place la semaine dernière, notre objectif est de créer une couche d'abstraction ou une façade pour tous ces systèmes. Tout ce qui touche à SnapLogic est converti en un langage commun afin que vous puissiez disposer d'un modèle de programmation commun. Je pense que c'est essentiel pour gérer les coûts de main-d'œuvre au sein de nos équipes, pour gérer l'architecture de notre système dans le temps et pour pouvoir adopter ces différents paradigmes.

Qu'il s'agisse d'intégrer des processus et des systèmes à partir d'une couche API dans le monde des affaires ou de réaliser des modèles à haute fréquence ou d'intégration de données basés sur les événements, nous pouvons les gérer de la même manière grâce à ce modèle opérationnel commun. Cela nous permet également d'intégrer des éléments tels que l'intelligence artificielle dans l'exploitation et de développer le système.

Comme Dayle l'a mentionné, SnapGPT s'occupe de tout, de la création et la gestion de votre infrastructure à la prise en charge future des contrôles administratifs et de supervision, en passant par l'intégration de l'IA dans vos les workflows Cela se traduit par un catalogue d'actifs commun qui couvre l'ensemble du portefeuille. Nous avons récemment lancé une fonctionnalité permettant d'exposer tout ce qui se trouve dans le portefeuille SnapLogic au niveau des actifs ou même au niveau de l'exécution, via une lignée ouverte vers des systèmes de gestion de catalogues externes, tels que les données.

Je sais que plusieurs personnes dans cette salle sont venues me voir pour me demander : « Quand pourrons-nous exporter cela dans notre système de gestion de catalogue, qu'il s'agisse de Calibro, Relation ou d'un autre système open source, comme DataHub, afin que nous puissions également le gérer ? Et si nous examinons les espaces axés sur les services dans le domaine sur lequel nous travaillons depuis un certain temps et que nous continuons à développer des capacités permettant de gérer notre architecture faiblement couplée via un système de gestion des API qui gère toutes les opérations du cycle de vie de nos services, ainsi qu'une expérience utilisateur de premier ordre, qu'il s'agisse d'un utilisateur souhaitant utiliser un service d'IA, par exemple un point de terminaison MCP ou une API, et être en mesure de développer ces multiples types d'utilisateurs à travers ce spectre, mais aussi un endroit commun pour découvrir tous les services disponibles afin d'améliorer réellement la composabilité des nouveaux services et systèmes pour stimuler la vitesse des affaires, et c'est le même paradigme ici pour la façon dont nous allons permettre une gestion sécurisée de l'accès pour les agents.

En passant par la même porte d'entrée et en appliquant le même processus et la même gouvernance que ceux que nous appliquerions à l'accès programmatique aux agents, nous sommes en mesure de gérer l'autorisation, l'identification, mais aussi les règles métier et le traitement déterministe de manière mixte avec les agents, ce qui nous ouvre ensuite à des systèmes d'engagement, qu'il s'agisse d'un système de bureau, d'un autre système d'application, de n'importe quel type d'interface de chat, etc. C'est ainsi que nous envisageons la gestion de cette grande diversité et hétérogénéité des systèmes au fil du temps, qu'il s'agisse d'un système transactionnel back-end ou d'un système en contact avec la clientèle, qui peut être utilisé avec les produits et systèmes de votre entreprise.

Il s'agit donc autant d'un état d'esprit philosophique que d'une architecture technique qui nous permet de simplifier radicalement le fouillis dans lequel se trouvent souvent nos environnements système d'entreprise, et de simplifier la capacité à ajouter de nouveaux investissements et à accélérer le processus. Est-ce un rappel ou un résumé utile de la façon dont nous voyons l'univers ? D'accord.

Quelques hochements de tête approbateurs. En termes d'impact, même si nous sommes extrêmement enthousiastes et que nous parlons du monde du travail numérique, il est important de voir les premiers utilisateurs qui se lancent dans la bataille, ce qui est incroyablement excitant.

Alors, venez-vous de passer en revue certains des membres de notre communauté qui peuvent être cités publiquement ? APTIA. APTIA est, comme vous le savez, un acteur du secteur de la gestion des prestations de santé, qui est parvenu à réduire de plus d'une heure à quelques secondes le temps nécessaire à la gestion des processus d'explication des prestations. Il s'agit donc d'un cas d'utilisation de l'intégration d'applications ou de la gestion des processus métier, dans lequel l'entreprise a pu intégrer des modèles linguistiques dans un processus déjà défini et gagner énormément en productivité dans le cadre de son traitement.

Digital Federal Credit Union, aujourd'hui la plus grande coopérative de crédit des États-Unis, a considérablement réduit le temps nécessaire à la gestion des alertes de fraude. Elle dispose d'un système de gestion des dossiers et d'un centre de services partagés chargé d'examiner tous les cas de fraude d'identité.

Ils disposaient déjà de modèles prédictifs, grâce à l'entraînement de réseaux neuronaux et à d'autres moyens permettant d'identifier les valeurs aberrantes et les transactions. Mais ceux-ci produisaient des résultats très complexes et sophistiqués.

Ils ont ensuite utilisé AgentCreator créer un résumé clair et concis du cas, ce qui a considérablement réduit leur temps de traitement dans le cadre d'un centre de services partagés. Spirent a complètement changé sa façon d'envisager le service client et, en réalité, la manière dont elle pouvait améliorer sa capacité à vendre à de nouveaux clients en créant un dossier client dédié pour ses commerciaux avant qu'ils ne se rendent sur site.

Et KBS est l'une des plus grandes entreprises de services de nettoyage au monde. La plupart de leurs échanges avec leurs clients se font en réalité sur papier.

Ils remplissent des bons de travail papier, puis ils décrivent le service fourni. Ils utilisent une combinaison de vision par ordinateur et d'un modèle de classification pour classer les workflows commencent sous forme papier, afin de pouvoir piloter leurs processus métier.

Il existe une grande variété de ce que nous appellerions, et je pense, vous savez, si vous lisez les récentes recherches de Keith Guttrich sur la différence entre l'IA quotidienne et l'IA transformationnelle, je pense que c'est là que nous verrions ces investissements dans l'IA transformationnelle. Il ne s'agit pas d'installer un chatbot sur le bureau.

Cela change fondamentalement la recherche approfondie. À partir de là, je voudrais donc parler du protocole de contexte de modèle.

C'est quelque chose qui préoccupe tout le monde. Y a-t-il parmi vous quelqu'un qui expérimente ou travaille actuellement avec MCP dans le cadre de son travail ? Très bien.

Un peu moins de la moitié des personnes qui utilisent l'IA au quotidien, c'est donc un indicateur préliminaire. Hier soir, nous avons dîné avec des collègues de Gartner, qui nous ont dit que les demandes MCP dépassaient largement le volume d'entrées.

Nous le constatons également. Mais pour ceux d'entre vous qui ne savent pas ce qu'est le protocole de contexte de modèle, je vais vous donner une description simplifiée : il s'agit d'un moyen d'améliorer l'inférence du modèle linguistique afin d'utiliser des outils, des ressources ou des invites dans le cadre de leur utilisation, car le modèle linguistique lui-même crée l'accès au système.

Eh bien, si vous voulez le faire de manière très fiable, vous devez disposer d'un formatage structuré et basé sur des modèles. C'est essentiellement ce que nous offre MCP.

Mais si vous le faites de manière fiable et fréquente, vous pouvez accélérer l'innovation, car vous pouvez réduire le temps nécessaire pour ouvrir la surface de vos systèmes d'entreprise aux modèles linguistiques et à leur fonctionnement réel. Du point de vue du processus décisionnel, si vous utilisez des processus qui font appel à des LLM pour faciliter la prise de décision, vous pouvez par exemple réaliser des résumés ou des synthèses des informations sous-jacentes.

Le MTP peut nous aider dans ce domaine et peut également créer une couche d'abstraction qui nous permettra de développer les services sous-jacents au fil du temps, en utilisant essentiellement une approche standard. Nous considérons donc le MCP comme n'importe quel autre type d'interface ou de technologie d'intégration, en cherchant à déterminer comment l'utiliser au mieux à l'aide des mêmes paradigmes que ceux que nous aurions utilisés pour d'autres types d'intégration.

La première fonctionnalité que nous proposons pour prendre en charge MCP est déjà disponible. Je pense que c'était il y a un ou deux versions, mais vous pouvez désormais appeler des points de terminaison MCP à partir des processus ou des pipelines SnapLogic.

Ainsi, dans un pipeline standard, supposons par exemple que vous ayez besoin de classer certaines informations comme nous l'avons vu dans l'exemple KBS. Vous pouvez désormais appeler non seulement un modèle linguistique, mais aussi un point de terminaison qui pourrait être un système plus sophistiqué avec MCP, ou même appeler d'autres systèmes qui exposent des données, également via MCP, puis les intégrer dans un pipeline SnapLogic. Il s'agirait donc du snap client, et je sais que plusieurs personnes dans cette salle ont déjà travaillé avec aujourd'hui.

La prochaine étape consiste toutefois à exposer SnapLogic en tant que serveur MTP. Cela devient alors très intéressant, car si vous disposez d'un serveur MCB dans le plan de données de SnapLogic, cela signifie implicitement que tout pipeline ou ressource accessible via SnapLogic peut désormais être accessible à un point de terminaison de modèle linguistique pour le développement d'une interface utilisateur directe, si nous voyons le monde évoluer vers des interfaces utilisateur de plus en plus conversationnelles, ou vers d'autres traitements eux-mêmes.

À titre d'exemple, l'un des projets de recherche que nous menons actuellement en interne consiste à rendre les API d'exécution SnapLogic compatibles avec MCP. Vous êtes probablement nombreux à utiliser nos API publiques pour extraire des données ou des informations d'exécution.

Nous les rendons désormais accessibles via MCP afin que vous puissiez effectuer une requête en langage naturel. Vous pouvez par exemple demander combien de pipelines ont été dégradés au cours des dernières vingt-quatre heures et pourquoi, et obtenir une réponse pertinente du système afin de réduire le temps et l'énergie nécessaires à la gestion de cette tâche.

De plus, si vous disposez de SnapLogic et d'un serveur MCP, vous pouvez activer MCP sur n'importe quel système que vous avez créé et qui dispose de ce type d'API à l'aide de SnapLogic. Réfléchissez-y un instant.

Si vous gérez des investissements hérités et que l'administration des systèmes est complexe, vous pouvez en réalité vous faciliter la tâche. Mais je voudrais illustrer cela par un exemple plus concret. Avant cela, je vais m'assurer que mon système, qui est en place depuis un certain temps, fonctionne correctement, notamment en vérifiant que la sécurité et les délais d'expiration des utilisateurs sont opérationnels.

Je vais donc m'en occuper en arrière-plan. Parlons d'un exemple où cela pourrait être utile, que je rencontre régulièrement dans mon domaine, à savoir l'intégration des fournisseurs.

Si vous êtes comme SnapLogic, votre processus d'intégration des fournisseurs est opaque, profondément frustrant, prend trop de temps, mais il est absolument nécessaire de suivre une certaine approche pour qu'il soit correctement mené à bien. Donc, dans mon univers, pour intégrer un fournisseur, même dans une petite start-up de la Silicon Valley, je dois remplir un formulaire pour décrire mon fournisseur.

Je dois ensuite télécharger ce document, je crois qu'il s'agit en fait d'un formulaire Google que je soumets. Ensuite, l'équipe financière examine le dossier et effectue toute une série de procédures commerciales afin de s'assurer que nous pouvons effectivement intégrer ces fournisseurs.

Qu'il s'agisse d'examiner la cote de crédit du fournisseur, de vérifier l'exactitude des coordonnées bancaires, d'évaluer les risques, de voir si le Better Business Bureau a signalé ce fournisseur en particulier, etc. Ce fournisseur existe-t-il déjà dans mon système CRM, pour pouvoir travailler avec lui ? Tout cela se passe en arrière-plan.

Ils prennent beaucoup de temps. Ils sont manuels.

Ils sont sujets aux erreurs. Nous pouvons donc imaginer maintenant, si vous aviez déjà intégré de bonnes règles commerciales dans la manière dont vous accomplissez ces tâches, comment pourriez-vous les présenter à un utilisateur final d'une manière qui soit très utile et utilisable ? À titre d'exemple, je vais vous montrer une démonstration si nous pouvons passer à mon écran.

D'accord. J'ai donc apporté ma propre IA, et je suis même trop radin pour payer les 20 dollars par mois que coûte l'abonnement.

Voici donc mon cloud . Je voudrais maintenant vous présenter à quoi pourrait ressembler l'intégration d'un fournisseur dans cet environnement.

Par exemple, j'ai mon formulaire d'intégration. Vous pouvez voir ici l'entreprise pour laquelle je souhaite travailler, Global Office Supplies.

C'est une société de démonstration, mais elle dispose de toutes les informations nécessaires. J'ai rempli le formulaire. Je peux maintenant l'importer dans mon cloud .

Et puis, à des fins de démonstration, pour que vous n'ayez pas à me regarder taper nerveusement, j'ai quelques suggestions ici, mais nous pourrions aussi les taper. Nous pouvons dire, par exemple, « lis le PDF sur l'intégration des fournisseurs et raconte-moi tout ».

Bon, d'accord, ce n'est pas vraiment un tour de passe-passe. Nous avons tous déjà fait ce genre de chose.

J'utilise déjà des modèles linguistiques, et vous connaissez ces services intégrés qui nous aident dans des tâches telles que les questions-réponses sur des documents, etc. Ce qui devient intéressant, cependant, c'est lorsque je donne à Claude des compétences supplémentaires.

Comme vous pouvez le voir ici, j'ai activé le serveur MCP d'intégration des fournisseurs SnapLogic, et maintenant que je suis authentifié dans le système, je peux effectuer des tâches telles que valider des fournisseurs, créer de nouveaux fournisseurs et effectuer des analyses sur ceux-ci. Commençons par la première tâche.

Je souhaite valider le fournisseur à l'aide du système SnapLogic de validation des fournisseurs. Actuellement, le cloud charge cette invite, examine les services disponibles et appelle un outil.

L'outil qui se cache derrière tout cela est donc un pipeline très simple qui procède à une validation à l'aide de nos systèmes d'entreprise afin d'effectuer une vérification Dun & Bradstreet. Il procède ensuite à une vérification de la solvabilité du fournisseur.

Utiliser concrètement les données contenues dans mon outil d'intégration pour suivre un processus métier prescrit, afin d'obtenir le résultat escompté. Voyons si les dieux de la démo sont avec moi aujourd'hui.

J'ai eu cette conversation plus tôt. Alors, j'ai dit : « Tu vas vraiment faire une démonstration en direct ? » J'ai répondu : « Eh bien, c'est mon intention. »

Mais voyons si Claude travaille avec nous. Il semble en tout cas vouloir le faire.

Allez, Claude. Tu crois que je vais avoir le temps ici ? J'ai déjà testé ça plus tôt dans la journée.

Pendant que Cloudtravaille, je vais fermer ça et le redémarrer. Oui.

Ça devrait être bon. Ça fait trois ans que je fais ça.

Est-ce mon premier plan de démonstration ? Nous verrons bien. Peut-être que la côte est des États-Unis est à nouveau en panne.

D'accord. Eh bien, pendant que cela se passe, vous pouvez imaginer, vous savez, si cela revenait, ce qui se passe réellement en arrière-plan ? Oh, c'est parti.

Très bien. La validation des fournisseurs est donc terminée et améliorée. Le temps d'inférence est un peu plus long, mais beaucoup plus court que si mon équipe financière s'en chargeait, je peux vous l'assurer.

Comme vous pouvez le voir ici, nous avons utilisé les pipelines en arrière-plan, les résumés pour approuver le fournisseur, puis les risques détaillés. Vous pouvez donc voir ici que nous procédons à la vérification Dun & Bradstreet, à la notation de crédit, à la conformité bancaire, à la double vérification du code SWIFT, etc.

Et ensuite, dire concrètement : « Écoutez, ce fournisseur a été approuvé pour l'intégration. Vous pouvez procéder à la configuration. »

Donc, vous savez, créez ce fournisseur dans CRM. Et encore une fois, grâce à l'enregistrement de la création du fournisseur, vous verrez qu'il sait déjà que ce que je veux dire, c'est qu'il faut créer le fournisseur dans Salesforce et utiliser les informations qui ont déjà été extraites du document.

Et donc, dans ce processus, nous utilisons le même outil sous-jacent. Quel est donc l'outil qui est réellement utilisé ? Il s'agit d'un pipeline SnapLogic simple, dans lequel nous effectuons une création Salesforce basée sur les informations réelles du compte.

Vous pouvez donc voir que ces informations ont été créées dans Salesforce et que nous pouvons accéder directement au compte ici. Allez-y, ouvrez-le.

Je pense donc qu'il s'agit simplement d'illustrer ici comment vous pouvez utiliser ces technologies pour répondre aux besoins de vos utilisateurs là où ils se trouvent, dans les interfaces qu'ils utilisent, afin de leur ouvrir ces capacités sous-jacentes, et l'idée que si vous avez déjà investi beaucoup de temps et d'énergie dans vos intégrations de données, vos intégrations d'applications, votre orchestration réelle, vous pouvez désormais les ouvrir également. Vous pouvez alors faire des choses encore plus intéressantes et sophistiquées.

Notre équipe avant-vente, par exemple, a cessé d'utiliser des rapports prédéfinis et standardisés sur la productivité et se contente désormais de générer automatiquement ce qui aurait normalement été fait dans Tableau ou un outil similaire. Vous pouvez également commencer à développer et à fournir des rapports analytiques à l'aide de ces outils.

Je combine donc désormais un pipeline d'intégration de données en arrière-plan pour extraire les informations et les performances des fournisseurs, et j'utilise ce qui est devenu un prototypage rapide très pratique si vous souhaitez simplement réaliser une visualisation ponctuelle. Pourquoi extraire ces données dans un tableur et créer tous vos tableaux croisés dynamiques, etc. si vous pouvez demander au modèle de développer quelque chose pour vous ?

Ainsi, en demandant à ce que cela permette une visualisation que je puisse partager avec mes cadres, nous sommes en mesure de créer quelque chose d'assez intéressant dans le cadre d'une activité relativement agréable, éphémère, presque jetable, afin de comprendre les analyses des fournisseurs, etc. Je paierai pour cloud .

Mais comme vous pouvez le constater, je pense que réduire les frictions pour prototyper rapidement afin d'accéder à l'information et même automatiser les processus métier, c'est là où nous allons. Nous sommes désormais en mesure de briser les frontières ou les courbes entre notre paysage d'entreprise bien structuré, bien géré, disons bien gouverné, et d'aider les utilisateurs à accéder à ces informations de manière plus fluide.

Et je pense que cela illustre bien ce que nous pouvons faire avec différentes expériences frontales, différents types de systèmes, lorsque vous commencez à réduire réellement la capacité à exploiter votre investissement existant. Plutôt intéressant, non ? Oui ? Non ? Oui ? Très bien.

Bravo, Claude. Très bien.

Retour à la présentation. D'accord.

Comme nous pouvons le voir ici, vous pouvez repenser la manière d'appliquer ces technologies. Dans ce cas, nous utilisons le modèle pour interpréter les données saisies par l'utilisateur et sélectionner les outils sous-jacents appropriés qui nous permettent de maintenir notre gouvernance.

Je pense qu'il est essentiel de souligner que le simple fait d'utiliser ces outils ne signifie pas que vous renoncez à la rigueur et à la gestion des processus dans la manière dont nous concevons et exploitons nos entreprises. Vous pouvez avoir les deux, c'est-à-dire des processus bien définis, bien délimités et livrés, et vous pouvez appliquer la valeur et la vitesse que vous apportez grâce à ces technologies pour rendre les choses bien gérées, rapides et efficaces, mais aussi à un niveau de qualité que vous devez avoir. Si vous connaissez notre préoccupation, je pense que notre observation est que si vous ne maintenez pas ces deux mondes en équilibre l'un avec l'autre, vous allez ouvrir une enveloppe de risque beaucoup plus grande et vous allez créer un monde dans lequel vous ne serez pas satisfait des résultats.

Bon, c'est très intéressant. Tout ce que vous avez du point de vue de SnapLogic, vous pouvez l'exposer en tant que point de terminaison MCP, vous pouvez l'exposer et vous pouvez orchestrer les processus et l'acquisition de données, mais que se passe-t-il si vous avez investi pendant vingt ou trente ans dans d'autres solutions middleware et que vous disposez déjà de ces environnements ? La grande majorité des middleware actuels de technologie d'intégration ont été livrés entre 1995 et 2006.

Nous avons été fondés en 2006. La version actuelle de SnapLogic a environ dix ans.

En termes d'architecture d'exécution de base, ils ont été continuellement améliorés, mais nous sommes cloud . Nous sommes centrés sur JSON.

Nous sommes, disons, en phase avec les technologies actuelles. Aucun des systèmes affichés à l'écran ne correspond vraiment à cette description.

Tous ces systèmes sont, comme vous le savez, des systèmes en colonnes, orientés lignes, sur site, autogérés, qui continuent d'être la colonne vertébrale de l'intégration pour la plupart des entreprises de la planète. L'une des demandes qui nous est régulièrement adressée est donc la nécessité de réduire le coût de la modernisation de ces systèmes.

Nous ne pouvons pas continuer à maintenir nos systèmes en état de fonctionnement. Certains d'entre eux ne seront bientôt plus pris en charge.

Microsoft BizTalk, beaucoup de gens sont actuellement confrontés à une plateforme en crise plateforme BizTalk. Beaucoup d'entre nous, orchestrateur de processus SCP dont la fin de vie est prévue dans quelques années avec l'ECC vers le monde S4.

Ces contraintes nous sont imposées, mais vous savez que vous pouvez repousser l'échéance, vous pouvez obtenir une maintenance prolongée. Cependant, lorsqu'il devient impossible d'atteindre la vitesse nécessaire à votre activité, il devient impératif de passer à une architecture plus moderne et contemporaine, ce qui a toujours été beaucoup trop coûteux et beaucoup trop long à réaliser.

Nous avons donc lancé l'année dernière un projet de science des données dans le cadre duquel nous avons d'abord cherché à savoir s'il était possible de passer d'une approche de modernisation dirigée par des praticiens, c'est-à-dire où quelqu'un est assis devant deux écrans, examine l'ancien système, construit le nouveau système et fait en quelque sorte des allers-retours, à une approche axée sur les données. Nous avons constaté que non seulement cela était possible, mais que nous pouvions également réduire de 80 % le temps et le coût de la modernisation.

Le temps et le coût, lequel est le plus important ? Eh bien, le temps, si nous pouvons réduire de 50 % le temps nécessaire à la monétisation, réduire votre profil de risque, vous réduisez vos coûts et vos difficultés de transition, et le temps n'est pas seulement le temps passé par les personnes, c'est le temps global du projet et le temps de développement. La méthode que nous avons finalement adoptée n'est donc pas une approche purement technique consistant à effectuer une conversion technique ou un transfert, même si cela pourrait être tout à fait approprié pour une partie de vos charges de travail.

Nous examinons de manière holistique l'ensemble du processus de modernisation à partir de la compréhension du portefeuille. Bon nombre de ces portefeuilles datent de plusieurs décennies, et les personnes qui ont rédigé les charges de travail ne travaillent plus avec nous.

Ils ont probablement pris leur retraite ou sont décédés. Ils n'ont pas documenté les choses correctement, donc nous comprenons ces systèmes sur la base des réparations ponctuelles.

Et pour moderniser leur migration, nous avons souvent besoin d'un projet de six à huit mois juste pour comprendre ce dont nous disposons avec un niveau de détail utile. Nous automatisons donc complètement ce processus, puis nous élaborons une planification centrée sur l'activité, que ce soit par domaine d'activité ou par orientation processus, avant de développer et de livrer le produit avec des tests et une mise en production.

Ainsi, ce que nous constatons dans le cadre des premiers déploiements de production de Slim, c'est une réduction de 40 % de la complexité globale de l'intégration. Il est donc possible de refactoriser les solutions, non seulement en les transférant telles quelles, mais aussi en les refactorisant et en adoptant une méthodologie de conception différente pour les construire.

Si vous regardez, par exemple, certains de ces systèmes, vous remarquerez, grâce au terme « mappage », je veux dire Informatica, la capacité à effectuer une compression massive, d'un système à un autre, principalement grâce à la paramétrisation et à la réutilisation. Et puis, vous savez, la réduction du temps de mise en œuvre en particulier.

Pour vous donner une idée de notre approche, voici quelques captures d'écran du système. Si l'on considère la phase d'analyse, nous exportons essentiellement les métadonnées de ces systèmes hérités, généralement au format XML, puis nous les téléchargeons dans le système avant de procéder à une analyse statistique de ces métadonnées.

Quels sont les points finaux ? Quelles sont les transformations ? Comment gérez-vous cela ? Ensuite, nous élaborons les diagrammes détaillés du flux de travail et la compréhension du processus dont vous disposez. À partir de là, nous procédons à la planification, que je vais passer sous silence, puis au développement proprement dit.

En partant de là et en suivant les spécifications, nous avons élaboré les premières ébauches des pipelines eux-mêmes, les données de test et la gestion, vous savez, le contrôle de version CICD complet, puis, élément crucial, la gestion des tests et des versions. Il s'agit donc de tests entièrement automatisés et itératifs dans le cycle de développement, tant au niveau des unités qu'au niveau de la régression elle-même.

Et, au fait, cette approche de test que nous avons mise au point avec SLIM est également disponible indépendamment pour vos environnements SnapLogic. Vous pouvez ainsi intégrer les tests unitaires dans le cycle de vie du développement et gérer l'analyse complète des tests de régression.

Je vois certains yeux s'illuminer à cette annonce, car cela représentait depuis longtemps une lacune pour nous. Nous avons comblé cette lacune et nous avons désormais la possibilité d'effectuer des tests unitaires et de régression entièrement automatisés.

C'est donc très excitant. Représentant SnapLogic de haut niveau.

Vous savez, revenez me voir après, et nous serons ravis de vous faire une démonstration et d'examiner vos données dans ce système. D'accord.

Et maintenant, quelle est la prochaine étape ? Eh bien, vous savez, la première vague de middleware moderne, qui a débuté en 1996 avec Informatica, TIBCO, etc., était vraiment sur site, qu'il s'agisse de technologies de type ETL ou ESB. La prochaine vague, c'est cloud, avec iPaaS.

Notre prédiction et notre orientation vont vraiment vers l'intégration agentique, et je ne suis pas d'accord avec mon collègue du marketing qui pense qu'il s'agit simplement d'un effet de mode. En fait, ce que nous entendons par intégration agentique, c'est ce que je viens de vous montrer avec Slim.

Nous appliquons actuellement l'IA dans le domaine même du développement des systèmes. SnapGPT est désormais un copilote agentique.

Si vous utilisez SnapGPT et que vous avez constaté ses améliorations constantes, vous pouvez désormais adopter une approche plus approfondie, en utilisant SnapGPT dans le cadre d'un cycle itératif, qu'il s'agisse de refactoriser des charges de travail existantes ou d'en créer de nouvelles. Il s'agit d'un système agentique, et comme vous pouvez le constater, nous développons également ce type de système.

C'est donc ce que nous voulons dire. Comment minimiser le coût humain de l'intégration, de l'automatisation, de l'orchestration, du développement et de la gestion ? En automatisant tout.

D'accord. Nous sommes donc engagés dans cet avenir qui nous concerne tous.

Nous continuons à nous développer. Nous avons commencé en 2017, en créant nos premiers réseaux neuronaux artificiels et en développant notre propre expertise.

Nous avons déployé des efforts constants et continus pour lutter contre ce problème. Nous sommes déterminés à minimiser les coûts, les risques et le temps consacré à cette question. Nous venons de lancer MCP et nous étudions actuellement comment bien coordonner les systèmes multi-agents entre eux.

Nous commençons les premières recherches dans ce domaine. N'hésitez pas à nous contacter si vous êtes intéressé par les systèmes agent-à-agent.

Pour l'instant, nous nous concentrons vraiment sur la mise en avant de MCP dans les cas d'utilisation où cela a du sens. Pour conclure, venez nous parler.

Venez nous parler si votre travail est au point mort parce que vous ne savez pas comment permettre aux modèles ou agents d'IA d'accéder de manière sécurisée aux données clés de l'entreprise, de façon reproductible, hautement contrôlée et utile. Avec ce contrôle centralisé, venez nous parler si vous risquez un échec en matière de gouvernance.

En oubliant tout cela, votre capacité à former un groupe opérationnel hautement performant est bloquée par la dette technique et l'héritage, et vous avez alors besoin de plus que des outils. Vous avez besoin d'une communauté, vous avez besoin d'expertise, vous avez besoin de conseils.

Tout ce dont je parle ici est disponible sur notre communauté, ainsi que sur notre blog technique, et nous considérons vraiment cela comme une activité de groupe. C'est donc une période vraiment merveilleuse et passionnante, et nous continuons à voir le rythme et la vitesse de l'innovation s'accélérer.

Merci beaucoup.

Des entreprises leaders dans le monde entier nous font confiance