.svg)
1. Comment avez-vous commencé à créer des intégrations d'IA ?
« Peu après le lancement de ChatGPT, j'ai commencé à expérimenter l'intégration de l'IA à l'aide de la plateforme d'intégration Alumio (iPaaS). Les résultats obtenus avec les premiers modèles GPT n'étaient pas excellents, mais vu le potentiel futur, je les ai d'abord utilisés pour soutenir mon processus de création de flux de travail au sein d'Alumio.
Mon premier projet d'intégration de l'IA est né lorsque je conseillais à un client de ne pas utiliser un outil de traduction pour son site Web de commerce électronique, ce qui était trop technique et problématique à long terme. Au lieu de cela, j'ai proposé une alternative pilotée par l'IA utilisant l'iPaaS Alumio, que nous utilisions déjà pour les aider à intégrer Akeneo, leur système PIM (Product Information Management).
Après avoir exploré plusieurs solutions d'IA, je me suis retrouvé sur la plateforme Vertex AI de Google et j'ai choisi leurs modèles Gemini pour le projet d'intégration. La traduction des produits de l'anglais ou du néerlandais vers d'autres langues avec Gemini a été simple et rapide. L'utilisation de l'iPaaS Alumio pour intégrer l'IA au système PIM Akeneo du client s'est également révélée relativement simple et directe.
Le flux d'intégration que nous avons mis en place au sein d'Alumio implique :
a) Récupération des données sur les produits (en anglais ou en néerlandais) depuis le PIM d'Akeneo vers Alumio.
b) Cartographier les données dans Alumio à envoyer à la solution Gemini AI.
c) Envoi des attributs des produits qui doivent être traduits vers le modèle Gemini AI via Alumio.
e) Recevoir les traductions de Gemini et les enregistrer dans le domaine spécifique de cette langue.
En 16 heures environ, nous avons traduit 12 000 produits grâce à cette intégration d'IA. Nous avons fait économiser au client environ 500 à 600€ sur les frais mensuels que l'autre application de traduction lui aurait coûté. Le retour sur investissement a été atteint en seulement trois mois. »
2. Comment un iPaaS contribue-t-il à l'intégration de l'IA ?
« Lorsque vous utilisez un iPaaS comme Alumio, l'ajout de l'IA au flux d'intégration est relativement simple et correspond parfaitement au fonctionnement actuel de l'iPaaS. Généralement, l'iPaaS extrait les données d'un système, les transforme en un format structuré et les transmet à un autre système. Lorsque vous introduisez l'IA, le processus est presque identique : vous récupérez les données, structurez et cartographiez ces données de la manière attendue par l'IA, vous les envoyez dans le modèle/la boîte noire de l'IA, vous recevez une réponse, puis vous traitez ou acheminez cette réponse en conséquence.
L'IA peut être utilisée efficacement de deux manières en combinaison avec un iPaaS : la première est plus difficile à l'heure actuelle, et elle implique d'utiliser l'IA pour améliorer le développement de l'intégration elle-même au sein de l'iPaaS, et la seconde consiste à intégrer l'IA pour améliorer les capacités des produits.
- Améliorer le développement de l'intégration grâce à l'IA : En ce qui concerne le premier cas d'utilisation, j'alimente l'outil d'IA avec mes stratégies et mes modèles pour créer des intégrations à l'aide d'Alumio. En réponse, l'IA aide à générer une mise en œuvre de base de ces stratégies, dans laquelle elle ne créera pas la cartographie complète ni n'appliquera la logique métier, mais elle me fournira la configuration de base. Par exemple, cela me donnera la configuration entrante pour récupérer les données d'Akeneo et inclura une logique pour stocker les horodatages. De cette façon, chaque exécution ne récupère que des données nouvelles ou mises à jour. En d'autres termes, il permet de générer rapidement un squelette pour Routes, ce qui peut accélérer les premières étapes de la configuration de l'intégration.
- Intégrer l'IA à d'autres outils ou applications : Du côté des produits, l'intégration de l'IA via l'iPaaS d'Alumio peut aider à automatiser des tâches complexes telles que la traduction des données des produits (comme expliqué dans l'exemple précédent). L'IA est particulièrement efficace pour structurer des données non structurées. Par exemple, l'une des preuves de concept que nous exécutons actuellement consiste à automatiser le traitement des bons de commande reçus au format PDF par e-mail. Le client souhaite importer automatiquement ces bons de commande dans son ERP. Alors que certains de leurs fournisseurs envoient des données EDI structurées qui s'intègrent facilement à leur ERP, nombre d'entre eux se contentent d'envoyer des PDF par e-mail après une commande verbale. Les outils d'OCR traditionnels qui peuvent être utilisés pour lire des PDF nécessitent un modèle unique pour chaque fournisseur, qui rompt constamment avec les modifications de mise en page. Pour résoudre ce problème, nous avons mis en place un système dans lequel les fournisseurs envoient les PDF par e-mail dans une boîte de réception dédiée. Nous avons ensuite construit une intégration pour l'iPaaS d'Alumio afin de récupérer les commandes PDF depuis cette boîte de réception et de les envoyer à l'outil Gemini AI, tout en enrichissant la demande avec des données contextuelles provenant de l'ERP (telles que le catalogue complet des fournisseurs). Gemini croise ces données ERP, puis extrait des données spécifiques du PDF, telles que les noms des fournisseurs ou les détails des commandes, ce qui nous permet de créer automatiquement des bons de commande structurés.
Dans l'ensemble, alors qu'Alumio accélère déjà la façon dont nous créons des intégrations et automatisons les processus pour nos clients, l'ajout de l'IA contribue certainement à améliorer l'efficacité sur les deux fronts. »
3. Quelle est la marge d'erreur lors de la création d'intégrations d'IA ?
« La plupart des erreurs génératives d'IA dépendent de la quantité d'informations contextuelles que l'IA reçoit. Par exemple, dans l'exemple précédent, où nous avons utilisé Alumio pour créer une intégration permettant d'envoyer les PDF des fournisseurs à Gemini à des fins d'enrichissement, nous avons également modifié l'échange de données pour inclure des données contextuelles provenant de l'ERP (catalogue complet des fournisseurs). Cela permet à l'IA d'établir des associations intelligentes lors de la transformation des PDF des fournisseurs en bons de commande. Par exemple, si un PDF indique « BR Green » comme fournisseur, l'IA peut comprendre qu'il fait probablement référence à « Brothers Green » dans l'ERP. L'ajout d'informations contextuelles supplémentaires réduit donc définitivement les risques d'erreur.
Pour réduire la marge d'erreur associée à l'IA générative, nous combinons généralement nos intégrations d'IA à une interface utilisateur, qui affiche le contenu généré par l'IA et permet aux utilisateurs de le consulter avant de l'autoriser à être mis en ligne. Nous configurons également Alumio pour effectuer des contrôles en arrière-plan, par exemple en signalant les écarts si le prix de la commande ne correspond pas aux attentes de l'ERP. Le niveau de supervision dépend du cas d'utilisation, certaines entreprises acceptant de transférer les données de produits traduites par l'IA directement vers leur boutique en ligne sans les revoir. D'autres insistent sur l'approbation manuelle avant la publication. Mais pour les processus critiques tels que les bons de commande, où les erreurs peuvent avoir un impact financier, il est essentiel de valider ce que génère l'IA. »
4. Quels sont quels sont les plus grands défis en matière d'intégration de l'IA ?
« Le plus grand défi à l'heure actuelle est que la plupart des modèles d'IA reposent encore fondamentalement sur de grands modèles de langage (LLM). Même du côté des API, elles sont principalement conçues pour les interactions de type chatbot, ce qui n'est pas la façon dont nous les utilisons généralement dans les intégrations. Des fonctionnalités telles que les appels de fonctions ou les sorties structurées existent (que, par exemple, Gemini de Google prend en charge). Pourtant, nous recevons encore souvent des réponses en texte brut contenant un objet JSON, au lieu de recevoir directement un JSON structuré approprié. Cela reflète la façon dont ces modèles sont toujours ancrés dans la conception conversationnelle, même lorsqu'ils sont utilisés pour les processus backend.
Cela nous a causé pas mal de problèmes, notamment en ce qui concerne la désérialisation des réponses. Les modèles peuvent très bien comprendre le code, mais ils le génèrent toujours sous forme de texte brut. Cela signifie qu'ils peuvent oublier une virgule, manquer un accolade ou commettre d'autres petites erreurs de syntaxe susceptibles d'interrompre un processus. La gestion de ces incohérences demande un certain travail dès le début, mais les modèles s'améliorent rapidement et sont déjà beaucoup plus fiables qu'ils ne l'étaient il y a un an. »
.svg)
.svg)
.svg)
.svg)
.svg)
