Le challenge des solutions d’automatisation reste l’intégration au reste de l’écosystème du SI. Une solution d’automatisation ne doit pas porter le besoin mais doit simplifier l’interconnexion des données et des processus de l’entreprise où qu’ils soient (i.e. aller chercher l’information où elle se trouve).
[Spoiler Alert] Cet article tente de vulgariser (sans trop simplifier non plus) des principes techniques complexes. Les profils sans aucune compétence technique pourrait avoir du mal à en saisir le sens, et je m’en excuse.
Il y a deux approches (qui ne s’opposent pas mais qui sont malgré tout très différentes) : Le RPA et les API. Pour faire simple, les technologies RPA simulent les clics que vous auriez à faire sur votre écran, tandis que les API vont directement accéder à l’information fournie par le service sans passer.
Chez Hubi.ai nous avons fait le choix des API (Application Programming Interface) fournis par les éditeurs de ces services (qu’ils soient des SIRH, des ITSM, ou des CRM, ou autre). C’est-à-dire que chaque fournisseur de service permet, via ces API, d’exécuter une partie (voire toutes) des fonctionnalités du service.
Aujourd’hui les fournisseurs de services exposent leurs API en respectant pour la plupart des normes établies. La plus exposée à ce jour, reste la norme OpenAPI (https://www.openapis.org/ dans sa version 3.1.0 depuis février 2021). Cette norme assure la bonne communication entre plateformes. La plupart des fournisseurs vont jusqu’à exposer leur fichier définition (un format Swagger json ou yaml) afin que les autres services puissent les intégrer. Ces contrats d’interface seuls suffisent à décrire la portée du service.
Il faut savoir qu’une API seule, ne suffit pas. Elle est généralement accompagnée d’un fournisseur d’authentification. Et c’est là où cela se corse un peu, car, de ce côté-là, c’est un peu plus le far-west : API Key, BearerToken, OAuth2 (avec toutes ses subtilités), MSGraph, Basic Auth… Bref chaque API fournit ses méthodes d’authentification. La bonne nouvelle, c’est que normalement, ces méthodes d’authentification sont listées dans la définition OpenAPI (dans le meilleur des cas!).
Mais attention, ces méthodes d’authentification n’ont pas toutes la même capacité. Il faut différencier deux cas : Ceux capables d’identifier l’utilisateur courant et ceux qui utilisent une communication générique entre les services. En effet, certains fournisseurs ne font que du Application-to-Application. Cela signifie qu’une application est autorisée à communiquer avec une autre application pour une durée déterminée. D’autres gèrent des tokens qui permettent d’identifier un service avec un compte de service, mais dans ces deux cas, elle ne permettent aucunement d’identifier l’utilisateur qui a effectué l’appel.
Certains fournisseurs permettent, quant à eux, de réaliser ce genre de besoin d’identification de l’utilisateur source. C’est le cas par exemple des services Microsoft qui utilisent l’authentification MSGraph. Ainsi avec une petite manipulation normalisée par Microsoft (à ne faire qu’une seule fois à l’initialisation de la plateforme), vous pourrez faire en sorte que votre plateforme communique au nom de l’utilisateur connecté avec la plateforme cible en respectant les limitations que les équipes IT internes auront malgré tout validées (https://docs.microsoft.com/fr-fr/graph/auth-v2-user). Une fois cette action effectuée, vous pouvez l’exécuter dans le contexte de l’utilisateur courant.
Ça, c’était pour la théorie!
Exemple d’usage du connecteur Dynamics365
Chez Hubi.ai, au-delà de la gestion de bases de connaissances et des bots multi canaux, nous intégrons une solution complète d’automatisation en usage illimité qui permet d’intégrer vos bots à un ensemble de solutions via une liste de connecteurs précréés, disponible Out-Of-The-Box sur la plateforme.
En clair, dès qu’un service expose une API, nous pouvons nous y connecter. Il y a bien entendu, deux cas… les services que nous avons déjà intégrés, et ceux qui n’attendent que ça!
Nativement nous intégrons plusieurs dizaines de connecteurs vers les outils les plus standardisés du marché (ou vers des services plébiscités par nos clients). En plus, Hubi.ai intègre un créateur de connecteurs sur mesure qui permet à tout administrateur d’ajouter son propre connecteur et de définir ses propres méthodes d’authentification lié à ce connecteur.
Pour cela rien de plus simple, tout se fait au sein du même portail. 3 clics pour ajouter la définition OpenAPI du connecteur (allez je chipote, un quatrième pour valider). 3 clics pour déclarer l’authentification (nous supportons tous les fournisseurs existant), et à partir de là, vous pouvez utiliser vos connecteurs au sein de notre éditeur No-Code sans n’avoir aucune connaissance technique. Des formulaires sont automatiquement générés en utilisant la définition OpenAPI. Ceux-ci sont entièrement fonctionnels et ne nécessitent aucune connaissance en développement.
Exemple d’appel de création d’un ticket GLPI
Le nombre de connecteurs que vous pouvez créer est illimité et n’impactera jamais le coût de votre solution, au même titre que le nombre de scénarios, ou le nombre d’appels que vous pourrez faire de ces services. Il n’y aura jamais de « connecteurs premium ».
OUI MAIS… Une API, ça ne sort pas toujours un format textuel, un chiffre ou une date. Ça peut également sortir des objets plus complexes, et souvent des formats JSON (un format de structuration de données, digne successeur du XML, pour faire simple), et vous, cher designeur de scénarios, vous n’êtes pas forcément un expert des technologies de lecture JSON. Il n’y a pas de problème puisque le connecteur inclut nativement un parseur JSON simple qui vous permet de récupérer sans moindre mal (en 2 clics), n’importe quelles données que votre connecteur fournit, que ce soit de la donnée simple ou des tableaux).
Cliquez simplement sur la donnée qui vous intéresse, nous faisons le reste!
La preuve en vidéo.