Archimag – « Des connecteurs aux API » (06/2016)

Pour relier un logiciel métier à la Ged ou à une solution de gestion de contenu, il faut parfois développer ou faire développer un connecteur spécifique, ce qui peut être coûteux. Mais les langages standardisés et les interfaces de programmation (API) facilitent aujourd’hui les connexions.

« Assurez-vous qu’il existe déjà des connecteurs qui vous permettront de relier la plateforme à vos applicatifs existants… »
Dans Archimag, ou dans d’autres magazines sectoriels, les conseils de ce type sont légions lorsqu’il s’agit d’éclairer les lecteurs sur les points à prendre en compte avant de décider de migrer vers tel ou tel ECM… Cela s’explique. « Les solutions de gestion de contenu sont de plus en plus utilisées en back office et en appui d’une foule de logiciels, souligne Caroline Buscal, responsable du département conseil de Serda. Il faut donc que la DSI puisse les interfacer facilement avec la solution de gestion de la relation client, le logiciel de compta, le système d’information RH ou bien encore la solution d’usinage de pièces mécaniques, le logiciel de conception et le progiciel de traitement des images médicales… »

Connecteurs

Qu’en disent les éditeurs ? Il y a, d’une part, ceux qui éditent des plateformes de Ged et d’ECM et qui ont un intérêt bien compris à s’interfacer avec tous types de logiciels. Everteam s’est, par exemple, équipé d’une gamme de connecteurs permettant d’interfacer sa plateforme d’ECM avec des logiciels de messagerie (Outlook…) ou des progiciels de gestion (Microsoft Dynamics NAV, SAP…) et il propose aux entreprises un « kit d’intégration » pour toutes les autres applications métier (Everteam Business Document Enabling Toolkit). ELO fournit pour sa part un module BLP (Business Logic Provider) à ses clients afin de faciliter les échanges entre son ECM et les applications tierces, et Efalia (ex-Eric Archivage) a fait sien le concept de « web services » au standard CMIS (pour content management interoperability services) en vue d’améliorer les capacités de sa Ged Multigest à se connecter à tous types de solutions métier et ce, « sans investissements additionnels », précise l’entreprise.

Mais à l’opposé du spectre, « les fournisseurs de logiciels métier n’ont pas tout de suite vu d’intérêt à se baser sur des langages standardisés et à ouvrir leurs portes », confie un développeur en poste dans l’une des principales entreprise de services du numérique (ESN) hexagonales. « Pour ces éditeurs, les connecteurs et les interfaces de programmation sont synonymes d’une plus faible adhérence des clients pros, qui peuvent éventuellement quitter leurs univers et aller voir ailleurs plus facilement. Ils ne sont donc allés dans cette direction qu’à marche forcée, sous la pression des entreprises ». Et bien souvent seulement après avoir tenté de pousser dans un premier temps leur propre solution de Ged, intégrée à leur plateforme.

API qui parlent un langage connu

Le plus souvent leurs efforts n’ont pas été couronnés de succès et les plateformes de gestion de contenu centralisées sont restées en place. Car à l’heure du big data, notamment, « il est avantageux de capitaliser toutes les données créées par les applications sur un seul et unique socle de Ged », estime Jean-Philippe Porcherot, directeur général de la société de services Atol Conseils et Développements (Atol CD), spécialiste de l’intégration de logiciels Alfresco, Drupal ou Pentaho… Pour y arriver, vous avez trois possibilités, détaille-t-il : « Un, vous vous procurez le connecteur fourni par l’éditeur du logiciel, s’il existe déjà. Deux, vous le faites développer à façon par un intégrateur – Atol CD a, par exemple, déjà conçu un connecteur pour relier le principal parapheur électronique sous licence libre et la Ged Alfresco. Trois, vous faites en sorte que le logiciel de Ged puisse appeler l’API (application programming interface) du logiciel métier afin de récupérer les données ». Cette dernière solution semble être de loin la plus en vogue actuellement.

Car à l’opposé des connecteurs – qui s’inscrivent « dans une logique assez ancienne », selon le développeur interrogé – « les API permettent de créer un point de communication standardisé, qui reste toujours sous le contrôle de l’éditeur du logiciel ». Un point de contrôle censé faciliter les échanges de données entre les systèmes, ce qui est de plus en plus important à l’heure où se multiplient les appels vers des services en ligne…

Résultat : « Les clients ne nous demandent plus d’afficher une liste exhaustive de connecteurs à jour pour tous les logiciels », relève Michael Harlaut, directeur avant vente Europe du Sud chez Alfresco – cet éditeur propose néanmoins des interfaces clés en main pour la plupart des solutions métier utilisées dans les administrations et les collectivités locales. Alfresco préfère mettre l’accent sur « les capacités d’intégration » offertes par les nouvelles API ouvertes. « Cela suppose que l’éditeur cible accepte de ne pas être le stockeur du document et qu’il admette que les clients préfèrent s’appuyer sur un socle de base en gestion documentaire ».

Simplification des développements

« Il est aussi nettement plus facile pour un utilisateur lambda de s’approprier ces API qu’il y a dix ans, ajoute Michael Harlaut ; il n’est plus indispensable d’être un expert Java ou C# ou de passer six mois à développer un service dans un langage propriétaire ! » En complément du « métalangage » XML (extensible markup language), le standard ouvert CMIS, soutenu par le consortium Oasis, et les protocoles SOAP (simple object access protocol) et REST (representational state transfer) ont précisément été conçus pour fluidifier les échanges de données entre des applications et des services cloud distants les uns des autres. Avec succès. Si SOAP pâtit d’une image vieillotte, et semble en perte de vitesse, « il est désormais relativement facile de mettre en œuvre une API de type REST », selon Michael Harlaut.

Mieux, des outils facilitent aujourd’hui le développement et la diffusion de ces API. Entre autres exemples, MuleSoft, jusqu’ici connu pour ses bus de services (ESB), propose la plateforme Anypoint, qui se pose en facilitateur des connexions entre les applications sur site et les services cloud… Tibco s’est pour sa part emparé de Mashery, portail de création et de publication d’API pour les entreprises. Et CA Technologies a racheté courant 2013 Layer 7, une société spécialisée dans la mise à disposition de bibliothèques d’API prêtes à l’emploi, par exemple pour l’accès aux services cloud ou la gestion des identités. Il en résulte l’offre API Management, centrée autour de la création et de la gestion centralisée de toutes les interfaces de programmation internes ou externes…

Autre signe du potentiel de ce marché émergent : de plus en plus de start-up font leur entrée et se spécialisent dans les plateformes permettant de créer plus facilement des API. C’est le cas d’Apigee ou de Restlet, qui développent des plateformes cloud permettant de développer et de déployer très facilement des API. Pour Yves de Montcheuil, responsable marketing de Restlet, « les entreprises dépendent de plus en plus des API », notamment pour faire en sorte que leurs systèmes puissent plus facilement interagir avec ceux de leurs clients et partenaires. Mais à son grand regret, elles commencent tout juste à modéliser et à tester le bon fonctionnement de ces API, qui restent invisibles aux yeux des utilisateurs (contrairement aux applications), avant leur mise en production. La Restlet Platform comprend à la fois un environnement de développement intégré (Restlet Studio), un système d’appel et de test (DHC Service), et une plateforme dédiée aux API web (APISpark).

Reste pour les entreprises intéressées à ne pas oublier que la difficulté ne se situe pas simplement dans les connecteurs et les API. « Ce n’est pas le plus compliqué », souligne Gilles Batteux, PDG-fondateur de l’éditeur de logiciels de gestion documentaire Kentika.

« Pour les utilisateurs de Kentika qui souhaitent s’appuyer sur des services extérieurs, il ne suffit pas de développer des interfaces permettant d’appeler ces services, conclut-il ; il faut surtout gérer les problèmes de droits associés aux données ainsi utilisées et éventuellement faire en sorte que celles-ci ne puissent être utilisées que par des personnes habilitées ».
La réflexion sur les interfaces doit être assortie d’une réflexion sur les droits d’utilisation.

Voir l’article ici.