API unifiée : combler le fossé entre les applications SaaS

Une interface de programmation d'applications (API) unifiée est une API qui sert de couche d'abstraction pouvant communiquer simultanément avec plusieurs API sous-jacentes.

Par conséquent, chaque objet et point de terminaison de l’API unifiée est mappé à un objet et un point de terminaison correspondants dans l’ API sous-jacente. Cela permet aux entreprises SaaS de créer une intégration unique avec l'API unifiée et de livrer instantanément des intégrations avec chacune des API sous-jacentes.

Dans cet article, nous approfondirons les API unifiées, leur fonctionnement, leurs défis et fonctionnalités, ainsi que leurs avantages pour les entreprises SaaS.

Quel problème les API unifiées résolvent-elles ?

Les acheteurs SaaS s'attendent désormais à des intégrations natives transparentes de la part des solutions qu'ils achètent. L’interopérabilité n’est plus un plaisir mais une exigence. Cependant, la création de ces intégrations natives avec leurs autres outils constitue aujourd’hui un défi auquel toute entreprise SaaS est confrontée, car leur expédition et leur maintenance nécessitent d’importantes ressources d’ingénierie.

Pour chaque intégration, les ingénieurs doivent créer une authentification sécurisée, parcourir la documentation API de l'application tierce, mettre en œuvre la logique métier requise pour fournir le cas d'utilisation et créer une expérience de configuration intuitive pour l'utilisateur final.

Et cela ne tient pas compte de tout le travail impliqué dans la maintenance et la mise à jour de l'intégration à mesure que de nouvelles demandes de fonctionnalités sont ajoutées, lorsque l'API tierce publie des modifications importantes, ni du temps que les développeurs passent à aider les clients à déboguer les problèmes d'intégration.

Dans le contexte des intégrations SaaS , des API unifiées sont apparues ces dernières années comme un moyen de relever le défi de la compréhension de la documentation API de chaque application tierce.

Fondamentalement, cela devrait éviter aux équipes d’ingénierie d’apprendre ou de revoir constamment les nuances, les formes et la nomenclature de chaque API individuelle, une fois pour chaque intégration.

Comment fonctionnent les API unifiées ?

Voyons comment fonctionne une API unifiée avec un exemple concret.

Imaginez que vos clients demandent que votre produit s'intègre à leur CRM : parmi votre base d'utilisateurs, certains clients utilisent Salesforce, d'autres utilisent HubSpot et certains utilisent Dynamics ou Pipedrive.

Une API CRM unifiée ferait abstraction des API de chacun de ces CRM en conservant des références à chacune des API des CRM sous-jacents.

Source : Parangon

L'exemple ici montre que chaque CRM sous-jacent possède un objet qui représente un « contact ».

HubSpot l'appelle un contact, Salesforce fournit à la fois un objet Lead et un objet Contact, et Pipedrive fait référence aux contacts en tant que prospects. Lorsqu'un appel est effectué vers l'objet « Contact » au sein de l'API unifiée, l'API unifiée référencera alors l'objet correspondant dans le service spécifié.

Désormais, les références au niveau des objets constituent la première couche, mais au sein de ces objets, il existe également des propriétés ou des champs qui sont abstraits. Dans l'exemple ci-dessus, cela pourrait inclure une nomenclature différente pour le nom, l'identifiant, l'entreprise, etc.

Ainsi, si votre équipe crée plusieurs intégrations CRM, vous pouvez théoriquement créer une seule intégration avec une API CRM unifiée qui vous permet de livrer simultanément toutes les intégrations CRM sous-jacentes.

API unifiées spécifiques à une catégorie

Toutes les API ne peuvent pas être unifiées en une seule API, car les différentes applications SaaS ont des modèles de données, des structures et des fonctionnalités uniques.

Par conséquent, les fournisseurs proposent généralement plusieurs API unifiées spécifiques à un certain secteur SaaS, tel que le CRM, la comptabilité ou la publicité, car ces applications SaaS auront des structures de données relativement similaires et partageront de nombreux objets ou propriétés communs.

Lors de la conception d'une API unifiée, le fournisseur d'API doit choisir soigneusement les API sous-jacentes à inclure dans l'API unifiée, car plus les API sous-jacentes se chevauchent, plus la couverture que l'API unifiée peut fournir est large.

Cependant, si l'API unifiée devait inclure des applications qui ne sont pas aussi similaires les unes aux autres, elle serait moins utile car elle ne serait pas en mesure de faire apparaître tous les objets et propriétés que partagent les API sous-jacentes. Par exemple, une API unifiée comprenant un CRM et une application de comptabilité peut ne pas être très utile car en dehors d'un objet « client », il peut y avoir peu de chevauchement entre les modèles de données du reste des applications.

Quels sont les avantages des API unifiées ?

Les API unifiées offrent de nombreux avantages aux équipes d'ingénierie qui doivent livrer et maintenir des dizaines d'intégrations.

Abstractions d'API

Au lieu d'apprendre et d'interagir avec les API individuelles de chaque service, votre équipe d'ingénierie n'a besoin d'apprendre à s'interfacer avec l'API unifiée qu'une seule fois (par catégorie).

Cela rend non seulement la création de ces intégrations plus facile et plus rapide, mais contribue également à réduire la complexité des intégrations.

De plus, en matière de maintenance, le fournisseur d'API unifiée est responsable de la gestion de la communication avec les API sous-jacentes, ce qui signifie que votre équipe n'a pas à s'inquiéter des modifications importantes apportées à l'une des API sous-jacentes. En fin de compte, le fournisseur d'API unifiée sera responsable de la mise à jour de son abstraction pour garantir que l'intégration continue de fonctionner.

Authentification gérée

Les fournisseurs d'API unifiées proposent généralement un service d'authentification géré qui élimine les complexités de l'authentification avec les API sous-jacentes, que ce soit via des clés API ou OAuth.

Lorsque vous intégrez directement plusieurs API, vous devez gérer le processus d'authentification pour chacune d'entre elles, notamment la gestion des informations d'identification des utilisateurs et la garantie de politiques d'actualisation sécurisées des jetons.

Étant donné qu'il existe de nombreuses nuances dans la façon dont chaque application gère l'authentification, cela peut s'avérer une tâche fastidieuse et sujette aux erreurs, surtout si vous travaillez avec un grand nombre d'API.

Enregistrement

Par nature, l'API unifiée envoie des requêtes proxy à ses API sous-jacentes. A ce titre, ils collecteront et analyseront les données relatives aux requêtes adressées aux applications tierces. Par conséquent, lorsqu'une demande échoue, le fournisseur d'API unifiée peut enregistrer cet événement et fournir des détails sur le message d'erreur renvoyé par l'API sous-jacente.

Cette fonctionnalité de journalisation peut être utile pour votre équipe car elle lui permet d'identifier rapidement les problèmes pouvant survenir avec leurs intégrations. Plutôt que de parcourir les journaux de plusieurs API tierces, ils peuvent s'appuyer sur le fournisseur d'API unifié pour centraliser la journalisation et le rapport d'erreurs.

Avec les erreurs de débogage, les fournisseurs d'API unifiées peuvent souvent fournir des messages d'erreur plus détaillés que les API sous-jacentes elles-mêmes. En effet, ils peuvent analyser la réponse à l'erreur et fournir plus de contexte sur la cause première du problème, ce qui peut réduire considérablement le temps consacré au diagnostic des erreurs et accélérer les temps de réponse aux incidents .

Interface utilisateur prédéfinie

La plupart des fournisseurs d'API unifiées fournissent une interface prédéfinie permettant à vos clients de s'authentifier dans une intégration, ce qui vous évite de créer vous-même l'expérience de configuration.

Cela décharge votre équipe de la conception de l' expérience utilisateur pour chaque intégration, ce qui peut se traduire par un gain de temps si l'on considère les dizaines d'intégrations potentielles que vous pouvez créer sur l'API unifiée.

Quels sont les défis liés à l’utilisation d’API unifiées ?

Même si les API unifiées offrent les avantages évoqués ci-dessus, elles sont paralysées par certaines limitations structurelles dont les entreprises commencent à prendre conscience.

Limites des cas d'utilisation

Étant donné que les API unifiées ne peuvent faire abstraction que des objets et points de terminaison « partagés » entre les API sous-jacentes, vous ne pouvez créer que des fonctionnalités relativement simples et généralisables à toutes les intégrations. Il s’agit de loin de la plus grande limitation de toute solution API unifiée.

De plus, plus il y a d’applications prises en charge au sein d’une API unifiée, plus celle-ci devient limitée.

Source : Parangon

Passons en revue quelques exemples de ces limitations.

Des caractéristiques irréconciliables

Si vous devez créer une fonctionnalité d'intégration impliquant des fonctionnalités ou des propriétés spécifiques à l'une des intégrations, cela ne sera pas possible avec une API unifiée.

Par exemple, disons que vous souhaitez intégrer plusieurs outils de commentaires clients via une « API de commentaires unifiés ». Si un outil exploite un modèle quantitatif avec des scores de feedback compris entre 1 et 10, tandis qu'un autre ne collecte que des « négatifs, neutres, positifs » accompagnés de « notes », il n'y a aucun moyen pour qu'une API unifiée puisse prendre en charge ces cas d'utilisation, car vous ne pouvez pas concilier ceux-ci en une seule référence.

Champs manquants

Si la propriété que vous devez mettre à jour via l'intégration n'est disponible que pour un sous-ensemble spécifique des intégrations prises en charge, cette propriété ne sera pas disponible dans l'API unifiée.

Par exemple, même si quelques applications tierces sous-jacentes ont un code postal comme champ, tant que ce n'est pas le cas, le code postal n'est pas accessible en tant que propriété via l'API unifiée.

Objets et champs personnalisés

Par nature, les API unifiées fournissent un ensemble de références prédéfinies à chaque API sous-jacente. Toutefois, si vous introduisez des objets ou des champs personnalisés dans le mélange, le fournisseur d'API unifiée ne peut pas anticiper la nature de ces objets ou champs. Par conséquent, ils ne peuvent pas prendre en charge les intégrations impliquant des objets ou des champs personnalisés.

Cela peut constituer un obstacle majeur si vos clients ont besoin des intégrations que vous proposez pour prendre en charge l'utilisation d'objets personnalisés dans les applications tierces.

Limites de taux

Lorsque vous intégrez plusieurs API à la fois via une API unifiée, vous devez connaître les limites de débit de chaque API et vous assurer que votre logique d'intégration ne dépasse pas les limites d'une API.

Cela signifie que la logique que vous créez doit respecter les limites de débit de l'API avec le seuil de limite de débit le plus bas. En termes simples, l'API avec la limite de débit la plus basse sera le facteur limitant pour votre intégration. Si vous essayez d'envoyer trop de requêtes aux points de terminaison de cette API, vos requêtes commenceront à échouer, même si les autres API de l'API unifiée peuvent techniquement prendre en charge ce même volume.

Pour éviter d'atteindre les erreurs de limite de débit lors de l'envoi de requêtes groupées à des points de terminaison spécifiques pour ces intégrations, vous devez utiliser le traitement par lots ou la limitation pour contrôler le débit de requêtes que vous envoyez à chaque API.

Ainsi, même s'il est toujours possible de contourner des limites de débit inférieures, vous vous retrouverez à créer une complexité supplémentaire dans votre base de code afin de tenir compte des limitations de l'une des intégrations sous-jacentes.

Sécurité

Les API unifiées nécessitent généralement que vous autorisiez l'accès à toutes les étendues d'un service tiers afin d'utiliser leur API, au lieu de vous permettre de sélectionner des étendues individuelles pour chaque intégration.

Cela signifie que lorsque vous authentifiez un utilisateur pour utiliser votre intégration, l'utilisateur sera obligé de vous donner accès à toutes les données associées à ce service tiers, et pas seulement aux données requises pour l'intégration.

À titre d'exemple, vous créez une intégration CRM via une API unifiée, et le CRM a accès aux données de vente, de marketing et de support client. Lorsqu'un utilisateur authentifie son compte pour utiliser votre intégration, vous aurez accès aux trois ensembles de données, même si votre application n'a besoin que des données de vente.

Cela peut soulever des problèmes de sécurité pour vos clients. Pour atténuer ces préoccupations, il est important d'être transparent avec vos utilisateurs sur les données auxquelles vous demandez l'accès et d'expliquer clairement pourquoi vous avez besoin de ces données.

De plus, étant donné que le fournisseur héberge généralement des API unifiées, vous comptez sur lui pour garantir qu'il dispose de mesures de sécurité solides pour protéger les données de vos utilisateurs contre les accès non autorisés ou les violations.

Modèle de données avisé

La manière dont le fournisseur réconcilie les différentes API sous-jacentes et les points de terminaison de référence dépend de sa propre opinion. Bien que cela ne pose pas de problème dans la plupart des cas d'utilisation, il y aura des moments où ils pourront présenter une abstraction avec laquelle vous n'êtes pas d'accord ou qui n'adhère pas au comportement attendu.

Contraintes de la feuille de route

Par rapport aux plates-formes d'intégration intégrées , qui fournissent des abstractions individuelles de chaque API tierce dans de nombreuses catégories, les fournisseurs d'API unifiées sont limités aux catégories pour lesquelles ils ont créé des API unifiées.

Bien qu'ils puissent créer et créeront de nouvelles API unifiées au fil du temps, si vous demandez une intégration avec une catégorie qui n'est pas actuellement prise en charge, il est probable que vous deviez attendre des années pour que cette intégration soit disponible.

La seule exception serait si le fournisseur était en train de créer une API unifiée pour la catégorie à laquelle appartient l'intégration demandée. Pourtant, compte tenu de l’étendue de l’écosystème SaaS et des catégories potentielles qu’il pourrait prendre en charge, cela sera rarement le cas.

Quand devriez-vous utiliser une API unifiée

Lorsqu'il s'agit de décider si une API unifiée est la bonne solution pour votre équipe, vous pouvez suivre des critères de décision simples.

Si vous ne pouvez pas dire oui en toute confiance aux quatre points ci-dessus, vous ne voudrez peut-être pas être obligé d'utiliser une API unifiée.

Au lieu de cela, un La plate-forme d'intégration intégrée peut constituer une meilleure solution, car elle vous permet de créer des intégrations beaucoup plus approfondies tout en fournissant des outils plus complets pour vous aider à rationaliser le processus de développement de l'intégration.

Le défi de l’intégration B2B SaaS

Choisir une solution pour vous aider à faire évoluer la feuille de route d'intégration native de votre produit SaaS n'est pas une tâche facile. Vous devez non seulement vous assurer qu'il peut répondre à vos cas d'utilisation actuels, mais également à tous les cas d'utilisation possibles que vos clients pourraient demander à l'avenir.

Les API unifiées peuvent constituer une excellente solution pour réaliser des dizaines d'intégrations avec un minimum d'effort, à condition que les cas d'utilisation dont vos clients ont besoin soient uniformes pour chaque intégration au sein d'une catégorie donnée.

Il s’agit d’un marché en développement avec de nombreux nouveaux acteurs et constitue certainement une approche intéressante pour résoudre le défi de l’intégration SaaS B2B.

Apprenez tout sur les API, leurs avantages, leurs défis et leurs cas d'utilisation dans le guide complet.