Après le cloud « technique », permettant de consommer des ressources de calcul et de stockage à la demande, voici venir l'ère du cloud « métier » qui permet d'utiliser et d'agréger des fonctionnalités de provenances diverses pour construire rapidement des applications sur mesure. Cette approche devient possible grâce à la prolifération des web api, qui sont des interfaces de programmation accessibles à travers des url. Internet
Ouverture
Une web api est un point d'accès utilisant l'infrastructure Internet et le protocole HTTP pour faire communiquer deux applications. L'utilisation de ces deux piliers technologiques est la garantie d'une fondation pérenne, maitrisée et déjà largement déployée.
De plus, une web api ouverte repose sur des standards métiers non propriétaires d'échanges de données, utilisables librement par n'importe quelle entreprise. Ce dernier point est particulièrement important car l'api doit encourager les interactions entre les acteurs et ne surtout pas représenter une barrière aux échanges. La facilité d'utilisation et la neutralité par rapport à la technologie sont des caractéristiques fondamentales.
Pour devenir plus performante et réactive, toutes les entreprises ont maintenant intérêt à ouvrir l'accès à leur système d'information et automatiser les échanges entre partenaires, fournisseurs et clients.
Cette interconnexion n'a longtemps été qu'un effet de bord de la mise en place d'une relation contractuelle classique, aboutissement d'une laborieuse recherche de fournisseurs.
De nos jours la démarche s'inverse. La publication d'une web api est quasiment devenu un pré requis au lancement d'une activité. L'api ne fait pas que représenter l'accès au service, elle EST le service.
Toute entreprise sachant se "brancher" sur une web api est susceptible de participer à la chaine de valeur de l'entreprise qui la publie. Les barrières limitant les échanges disparaissent, les systèmes communiquent facilement, les échanges économiques se fluidifient.
Le SI virtuel résultant de l'agrégation de toutes ces api possède un certain nombre de caractéristiques intéressantes :
- il peut être construit très rapidement, éventuellement pour une courte durée et de manière ad hoc,
- il ne nécessite que des investissements réduits,
- il limite les risques de mise en oeuvre, il est flexible, reconfigurable, agile,
- il est naturellement résilient. Une même api peut solliciter des fournisseurs différents en fonction de certains critères. Notamment si l'un des fournisseurs ne peut pas, ou plus, répondre à une demande, d'autres peuvent, de manière transparente, pallier à cette défaillance.
Toutes ces points d'entrée, hétérogènes dans leur convention d'utilisation, leur authentification et éventuellement leur mode de facturation, peuvent être regroupées, homogénéisées par des prestataires spécialisées, l'équivalent de distributeurs, pour faciliter l'usage et la consommation de ces fonctionnalités distantes.
Dans ce cas, de la même manière que les outils de virtualisation présentent une abstraction du matériel aux systèmes d'exploitation hébergés, les web apis ouvertes ne sont en fait que des intermédiaires gérant l'accès à des web services proposés par des prestataires extérieurs. Elles prennent en charge tout un tas de fonctions utilitaires (authentification, cache, conversion, …) mais n'implémentent pas les fonctions métiers qui sont déléguées à des prestataires spécialisés.
On peut faire le parallèle avec les hébergeurs « cloud », utilisant une technologie VMWare, xen ou autre pour vendre l'utilisation de ressources matérielles.
Automatisation des échanges et alignement des process
L'accélération des échanges doit passer impérativement par l'automatisation de nombreux traitements transverses à plusieurs entreprises. Cette démarche est aujourd'hui complexe et lourde à mettre en place. Elle passe par des accords contractuels, juridiques, techniques et commerciaux.
Cette automatisation est déjà terriblement complexe à mettre en oeuvre à l'intérieur même des entreprises, on imagine volontiers que son application à des partenaires extérieurs frôle l'impossible ou reste pour le moins artisanale.
Les problèmes d'organisation sont souvent liés à la volonté de mise en place de process détaillés, globaux et … rigide.
Laisser chaque entreprise associer des activités prédéfinies à sa manière est une bonne façon de laisser un espace de liberté dans l'organisation des tâches tout en pouvant garantir le fonctionnement de chaque tâche unitaire présente derrière la web api. L'agilité qui découle de ce mode de construction permet à des entreprises de taille et de culture différente de mieux collaborer.
Chaque web api est une brique de base, prenant en charge un périmètre fonctionnel bien défini. C'est la façon d'agréger ces différentes briques qui va définir le process personnalisé de chaque participant. Chaque étape peut faire appel à une brique interchangeable (car utilisant des interfaces standards) et solliciter des prestataires différents suivant les cas de figure.
En utilisation des web api, on évite la contrainte d'utilisation de la même application ou d'applications plus ou moins compatibles. C haque participant à une transaction (client ou fournisseur) peut intégrer de manière beaucoup plus souple les échanges avec ses partenaires et peut modifier son fonctionnement interne à sa guide sans impacter qui que ce soit.
Engagement, confiance et responsabilité
Un autre avantage lié à l'utilisation des web api est la capacité de vérifier, a priori, les capacités des fournisseurs.
En préalable à la mise en production réelle, il est tout à fait possible d'exécuter automatiquement des cas d'usages spécifiques permettant de valider l'adéquation du service rendu avec les besoins de l'entreprise cliente, de simuler des échanges avant de les effectuer réellement.
Les caractéristiques de l'api constituent une forme de contrat que le fournisseur s'engage à respecter et qui est techniquement vérifiable. La confiance se base sur la transparence. Plus le fournisseur veut être transparent et plus il ouvrira son système d'information.
On entend énormément parler de problème de responsabilité, de sécurité, de règlementation. L'externalisation de traitements informatiques est souvent vu comme un risque supplémentaire, une perte de contrôle. C'est effectivement le cas, mais il y a peut être plus à gagner qu'à perdre : une baisse des coûts, une souplesse et agilité incomparable, une indépendance vis à vis des solutions techniques.
Et quid de la sécurité ? L'illusion de croire qu'une informatique interne géré par des salariés est plus sécurisée qu'une plate forme externe prise en charge par des spécialistes est démentie tous les jours. Comment croire que de grands groupes faisant appels à des hordes de développeurs issus de SSII maitrisent un tant soit peu la confidentialité de leur données alors que l'intégralité de leur base client peut être stockée dans une clé usb grande comme un dé à coudre ?
Les règlementations ne peuvent pas grand chose là dessus. Le fait qu'une action soit prohibée n'empêche pas qu'elle ne soit pas très facilement réalisable.
Les seuls engagements réels qui peuvent être pris sont ceux qui sont concrètement démontrables. Il est beaucoup plus rassurant de travailler avec un prestataire qui vous proposera de faire des tentatives d'intrusions par les spécialistes de votre choix que de celui qui vous fera uniquement signer un contrat avec 50 pages d'engagements très nébuleux sur les questions de sécurité.
Aucun engagement n'est garanti a priori, seuls sont sérieux ceux qui n'ont pas été techniquement pris en défaut avant la signature du contrat par une démarche de tests intensives et qui sont revalidés régulièrement. Les sociétés de sécurité informatique ont de beaux jours devant elles.
Une redistribution des cartes
Les gros acteurs de progiciels intégrés n'ont pas intérêt à s'intégrer trop rapidement à un éco-système de producteurs de web api. Ils disposent déjà de l'ensemble des fonctionnalités permettant de répondre aux besoins de leurs clients . Aider ces derniers à s'interfacer plus facilement avec d'autres fournisseurs et diminuer par là même ses propres revenus, n'est pas une idée très intuitive.
La volonté de préserver un modèle qui a bien fonctionné jusqu'à aujourd'hui est un réflexe normal mais il va à l'encontre de l'intérêt des clients qui vont vouloir avancer de plus en plus vite dans l'intégration avec tous les autres participants de leur environnement, qui vont demander de plus en plus de fonctionnalités à un rythme effréné avec une personnalisation de plus en plus grande.
Le seul moyen de suivre la demande est de faire agréger des fonctionnalités existantes de provenance variées, de monter et démonter des systèmes, de faire évoluer en permanence des solutions. L'éditeur logiciel classique, lui, doit répondre au plus grand nombre. En centralisant toutes les responsabilités, il devient un à la fois un frein à l'innovation mais aussi un point de verrouillage pénalisant dans la recherche de l'interconnexion avec d'autres partenaires.
Les distributeurs de web-api, au contraire favorisent la mise en relation des acteurs de l'éco-système, permettent de distribuer les efforts d'innovation et diminuent les risques en permettant la recombinaison des prestataires.
Bien sûr, tout cela n'est possible que si l'offre de web api augmente et que le développement de solutions par composition de services se généralise. C'est bien ce qui semble se mettre en place.