vendredi 27 janvier 2012

Les web api comme outil d'intermédiation

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. Chaque 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.


lundi 5 décembre 2011

Le design des web api

Une web api est essentiellement une porte, un point d'accès à un traitement ou une ressource distante. Tout le challenge du design d'api se résume à faciliter au maximum l'accès à ce qui se trouve derrière la porte d'entrée.

Une api va raccorder une application au reste du monde, à autre chose que ses utilisateurs humains et permettre son intégration dans des contextes variés comme l'import et l'export de données, l'automatisation d'un grand nombre de traitements et bien d'autres choses encore.
Des développeurs tiers vont pouvoir créer de nouvelles solutions en agrégeant les fonctionnalités exposées par vos api avec celles d'autres fournisseurs. Bien souvent cela générera des usages que les créateurs d'origine n'avaient pas imaginé.

Pour les concepteurs en charge d'un  projet api, le produit final doit être l'api elle-même. Cette dernière n'est pas un objet de deuxième zone raccordé tant bien que mal à l'application principale. Les utilisateurs ne sont plus ceux de l'application mais les intégrateurs ou les développeurs qui vont l'utiliser dans leurs programmes.

Elle doit donc être pensée pour faciliter l'activité de ce type particulier d'utilisateurs et non pas seulement pour résoudre une problématique technique ou métier. L'api est malheureusement souvent un élément rajouté, qui n'a pas été forcément prévu dès le départ.

Pourquoi web api ?
On parle de web api parce que les traitements et les données sont accessibles à travers des urls http (même principe que pour les sites web, par exemple : https://api.faascape.com/mail/messages). Les principes techniques qui ont fait le succès du web sont utilisés exactement comme pour la consultation d'un site avec un navigateur à ceci près qu'au lieu de retourner des données visualisables par un utilisateur humain, l'url pointe vers des données destinées à être utilisées par un programme informatique.

Il y a quelques règles simples à garder en tête pour fournir à vos utilisateurs une api de bonne qualité.

Simplicité d'utilisation.
Une bonne api doit être simple d'utilisation, sa mise en oeuvre doit être rapide et intuitive. On peut mesurer une partie de cette simplicité par le nombre de lignes de code nécessaires pour utiliser une fonctionnalité ou par le temps mis à l'intégrer.

La rapidité de prise en main est, entre autres choses, lié au nombre de nouveaux concepts que doit maîtriser un nouvel utilisateur. Il est donc peu recommandé de mettre en oeuvre des mécanismes exotiques qui seraient propres uniquement à votre seule implémentation.

Etre basé sur des standards est un avantage. Selon le site ProgrammableWeb, la technologie la plus utilisée pour exposer une web api est REST et le format de données le plus populaire est JSON.

Le nombre d'éléments à utiliser pour effectuer une action doit être limité en terme de nombre de paramètres et de structure des urls. En faisant cela, on limite les risques d'erreur et de mauvaise utilisation.

Exemple
Imaginons un site de vente de voitures d'occasion qui souhaite mettre à disposition sa base de données via une api.

Compliqué : http://api.monsite.com/v1.314/fr/recherche?type-vehicule=tourisme&annee=1996&couleur=rouge& .......

Simple : http://api.monsite.com/vehicule/tourisme/1996?couleur=rouge& ....

On peut néanmoins envisager plusieurs niveaux d'utilisation : un niveau simple permettant de très rapidement mettre en oeuvre les premières fonctionnalités, puis éventuellement un mode "avancé" autorisant un paramétrage plus détaillé.

La démarche est exactement la même que pour une interface visuelle, moins de fonctionnalités accessibles directement pour ne pas perdre l'utilisateur dans un méandre d'options peu compréhensibles, mais toute la puissance du logiciel est disponible en activant les options "expert".

Aspects métier / aspects techniques
La vue "métier" présentée par l'api doit être lié au monde réel. Le vocabulaire utilisé pour exprimer telle ou telle fonction ou ressource doit se rapporter à la vrai dénomination du métier pas à un mot en relation avec  la technique d'implémentation. Même si le produit s'adresse à des développeurs, il ne faut dénaturer les traitements sous-jacents  en les affublant de noms uniquement techniques.

Dans notre exemple précédent ajouter la version (v1.314) et la langue des critères (fr) revient à mélanger des informations techniques avec des informations métiers. Il y a d'autres moyens de transmettre des informations dans les requêtes sans "polluer" les urls.

Performance
La perception d'efficacité est lié au temps nécessaire pour un obtenir un résultat.
N'oublions pas que la web-api va nécessiter des allers-retours sur Internet pour récupérer des données. Il est très important de prévoir systématiquement un mode 'traitement de masse' pour pouvoir à partir d'une seule requête effectuer plusieurs traitements, ajout de données, modification ou suppression.
En faisant cela, un seul appel au service distant permettra d'effectuer plus de traitements ou d'obtenir plus de résultats en moins de temps.

Exemple
Pour ajouter un nouveau véhicule à notre base de données de voiture, nous envisageons d'utiliser une requête POST avec un descriptif du véhicule à ajouter sur l'url http://api.monsite.com/vehicule

POST http://api.monsite.com/vehicule
{
"marque":"aston martin",
"modele": "v12 vantage",
"annee":"1993",
"couleur":"gris"
}

On peut sans effort envisager une variante pour créer plusieurs véhicules avec une seule requête :


POST http://api.monsite.com/vehicule
[
   {
   "marque":"aston martin",
   "modele": "v12 vantage",
   "annee":"1993",
   "couleur":"gris"
   },

   {
   "marque":"renault",
   "modele": "clio",
   "annee":"1998",
   "couleur":"rouge"
   }
]



Dans la définition de l'api, un juste équilibre doit être trouvé entre la possibilité de récupérer le maximum de données avec le moins d'appels possible ou, au contraire, transférer uniquement les données utiles et minimiser le volume d'information à télécharger.
Un ou deux paramètres peuvent servir à décrire le détail des informations à récupérer pour chaque url cible et ainsi permettre un ajustement du volume de données transféré en fonction des besoins réels.
Typiquement pour une requête de sélection, on permettra de spécifier facultativement le nombre de résultats à transmettre et à partir de quel rang on souhaite récupérer les données. Sans option, la requête retourne tous les résultats. C'est l'utilisateur de l'api qui est en contrôle.

Robustesse
Au delà du fait d'avoir pris toutes les dispositions pour avoir une api constamment opérationnelle, avec des temps de réponses raisonnables, géré les questions de montée en charge lié au succès, la perception de robustesse est également lié à un comportement prévisible. Par exemple, il faut éviter, en cas de problème, de remonter des messages d'erreurs ésotériques liés à l'implémentation interne. "Erreur d'accès
aux données" fait moins peur que "4565XDH : corrupted index". Ce qui se passe derrière l'api est hors de portée de l'utilisateur, il ne peut pas agir dessus, inutile donc de l'ensevelir sous des détails techniques qu'il ne pourra pas exploiter. Par contre, votre gestion de log devra bien entendu enregistrer toutes ces informations ainsi que ce qui permettra de rejouer éventuellement la requête ayant entraîné l'apparition du problème.

Dans le même ordre d'idée, toutes les données transmises à la web api doivent être soigneusement vérifiées avant d'être utilisées. Si une incohérence est détectée, un message d'erreur décrivant précisément la nature de l'erreur doit être retourné (pour le développeur) accompagné d'un code d'erreur significatif (pour l'application) indiquant que le traitement demandé n'a pu être effectué.

L'interface utilisateur de la web api : la documentation
Claire, synthétique, la documentation d'une web api se doit absolument d'être accessible en ligne, la mise à jour de la documentation doit être en permanence synchronisée à celle du code.
Il est fondamental d'accompagner le descriptif de chaque fonctionnalité d'exemples de code dans plusieurs langages, utilisables par simple copier / coller.
Cette documentation peut être lié à un système de discussion permettant aux utilisateurs de faire remonter leurs remarques et leurs questions directement. Les réponses apportées seront un bon complément à la documentation de base.
A titre d'exemple, voici un excellent outil en ligne qui vous permettra d'obtenir des documentations dignes de ce nom pour vos api : http://turnapi.com/

http://www.faascape.com
http://twitter.com/faascapefr

vendredi 25 novembre 2011

A bas les silos, vive les web-api !

Toutes les applications métiers ont maintenant une déclinaison Saas. Les éditeurs et les distributeurs s'organisent. Les fournisseurs de cloud fourbissent leurs armes et se font tout sourire pour attirer les éditeur sur les plate formes d'hébergement. Les juristes revoient les contrats pour transformer les licences en  abonnement. Bref, les acteurs du Saas s'organisent.

Qu'en est-il des clients ? Ceux ci, sensibilisés par le flux d'informations continus, les séances de formation, les encouragements des éditeurs et la publicité découverte au détour d'une page Facebook perçoivent les avantages de ces nouvelles offres qui les soulagent des problèmes d'installation, de maintenance, de mise à jour.

Tout va bien !

Hummm, un instant .... comment faire pour que les pointeuses dans mes usines remontent automatiquement les horaires dans ma solution RH (qui n'est plus sur mes serveurs) ?

Et mon logiciel de gestion financière ? quel lien avec ma facturation ? Je n'utilise pas l'une des solutions majeures du marché ! il n'y a pas de connecteur prévu à cet effet ? Aie, actuellement mon informaticien maison avait fait une petite moulinette (20 lignes de code) pour gérer ces différents problèmes et automatiser les imports et les exports de données. Mais aujourd'hui que faire ?

Et oui, les problèmes d'intégration restent les mêmes, certaines solutions sont plus ouvertes que d'autres et rien n'a changé de ce côté là.

Les grands comptes et autres ETI pourront toujours monter des projets et faire développer (à grand frais) les passerelles nécessaires. Pour les plus petites entreprises, quand il était autrefois possible de créer des "applications" maison en 10 lignes de VB et 3 macros Excel (ou pour les tenants de linux : 10 lignes de
script bash, perl ou autre python), fini l'intégration sparadrap. Ce sont pourtant ces pratiques, en dehors de toute gestion de la qualité, cahier des charges digne de ce nom et autre tests d'intégration qui ont permit à des milliers de PME de monter leur micro-SI au fil du temps.

Si l'arrivée du Saas apporte bien son lot d'avantages, un certain nombre de nouvelles difficultés restent à traiter et en premier lieu celui de l'interoperabilité entre les applications. Comment faire communiquer simplement deux applications Saas en provenance d'éditeurs différents, hébergés sur deux datacenters distincts avec des systèmes d'authentification incompatibles ?

Une seule réponse : disposer d'un jeu de web-api permettant d'agir sur l'application en dehors de l'interface utilisateur standard.
A partir de là, il est à nouveau possible de développer quelques moulinettes pour générer des flux, importer / exporter des données, déclencher des traitements, etc.
Conclusion, avant tout choix de solution, vérifiez bien la disponibilité d'une api en bonne et dû forme, correctement documentée.

Mieux encore qu'avec les api classiques, une bonne api REST vous permettra d'utiliser l'environnement et la technologie de développement de votre choix.

Vous êtes libre !!!

Pour aller un peu plus loin vous pouvez utiliser un outil d'orchestration (par exemple RunMyProcess en mode Saas également) qui vous permettra de lier l'ensemble des api de vos applications Saas pour mettre en oeuvre de vrais processus avec une facilité déconcertante.

http://www.faascape.com
http://twitter.com/faascapefr

mercredi 16 novembre 2011

Un nouveau métier : distributeur d'API

Du petit commerçant au distributeur

De nombreuses web-api fleurissent quotidiennement sur le net, il est aujourd'hui possible de construire des applications sophistiquées en agrégeant uniquement des fonctionnalités distantes.

Dans ce contexte, un distributeur d'api propose à ses clients un accès à des web-services conçus et hébergés par des tiers.

L'utilisation, par une équipe de développement, de nombreux fournisseurs d'api est l'équivalent de la tournée des commerçants de centre-ville : il faut du temps pour les sélectionner et si l'un de vos fournisseurs habituels n'a pas le produit recherché, il vous faut changer le menu.

A l'inverse, Le passage dans l'hypermarché (physique ou virtuel) vous permet de retrouver rapidement à un seul endroit l'intégralité des produits dont vous avez besoin.

Quels sont les avantages de la notion de distributeur dans le cadre de l'utilisation d'api ?

Tout d'abord, le site du distributeur permet d'avoir sous les yeux à un seul endroit un vaste ensemble de fonctionnalités sans avoir à parcourir Internet pour découvrir les offres correspondant à ses besoins.

La gestion se simplifie : une seule facture détaille les différentes consommations, un tableau de bord unique permet de mesurer et visualiser de manière cohérente les différents usages.
De la même manière, il n'y a qu'une seule gestion des accès et des autorisations, ce qui facilite grandement la mise en oeuvre et l'exploitation des applications.


Amener de la valeur ajoutée
Pour justifier son existence et au delà de la facilité d'accès aux fonctionnalités, le distributeur doit amener de la valeur ajoutée à l'ensemble des api proposées. Il peut, notamment, harmoniser les modes d'appel des services en proposant des conventions d'utilisation identiques pour toutes les api et masquer les différences techniques entre les différents fournisseurs.
En traitant tous les appels avant de les aiguiller vers le fournisseur final, le distributeur peut aussi dynamiquement convertir des formats de données et éviter ce travail au client.

Gain de temps
L'un des apports majeur du distributeur d'api est d'amener un gain de temps sur l'intégration des différentes fonctionnalités.

L'harmonisation des conventions techniques a pour effet une diminution importante des temps d'intégration. En effet, le développeur n'a plus besoin de se plonger dans les arcanes des systèmes de chaque fournisseur mais au contraire utilise un seul jeu de conventions cohérent.

Le distributeur doit aussi proposer des facilités sur les aspects multitenants.
Le client ne doit pas avoir à gérer les multiples aspects de configuration, de copie des données pour gérer ses environnements de test, de préproduction, de production. Le gain de temps est, sur ce sujet, également considérable.

Interactions
La position d'intermédiaire entre le client et le fournisseur du service final permet d'ajouter très simplement des mécanismes d'interaction entre les services. Lorsqu'une api est utilisée, un évènement est généré. Ce dernier peut être signalé par le biais d'un "webhook" (une url) à un autre
service ou à l'application cliente.

Interlocuteur unique
L'équipe de développement du client ne s'adresse plus qu'à une seule équipe de support, avec des engagements identiques, sur l'ensemble des apis du catalogue. Plus de temps à passer à traquer les messages des différents fournisseurs avec chacun leur temps de réactivité et leur délai propre.
Sur ce point également, la centralisation entraîne un gain de productivité.

Des services orientés client et non pas produit.

Chaque fournisseur d'api présente (ou devrait présenter) une documentation indiquant comment utiliser son produit (son api) de manière claire et pédagogique. Malheureusement, le format, la langue et les technologies utilisées dans les exemples peuvent être très différentes d'un fournisseur à un autre.
Un distributeur s'attachera à faciliter globalement l'agrégation des api à ses clients en fournissant de l'information et du support personnalisés.

La meilleure offre au meilleur prix
La nature désincarnée du produit permet au distributeur de changer dynamiquement le fournisseur d'un service en fonction du contexte de l'appel.
Par exemple, si l'on considère un service d'envoi de SMS, pour une qualité de service donné, le distributeur choisira le fournisseur en fonction du pays et du réseau du destinataire du message pour obtenir le prix le plus avantageux.
Le client peut ainsi utiliser le fournisseur le plus adéquat de manière totalement transparente.
La même approche permet aussi d'utiliser des fournisseurs proposant des SLA différentes pour un même service rendu. Typiquement, avoir des SLA différentes pour les environnements de développement et de production, peut amener des économies substantielles.

Dépendance et réversibilité
L'une des objections principales que l'on pourra présenter à l'encontre du distributeur est la génération d'une dépendence unique beaucoup plus critique que dans l'accès aux différents fournisseurs de manière
individuelle.

Cette dépendance n'est pas aussi forte qu'on pourrait le croire au premier abord.

Tout d'abord, d'un point de vue technique, il n'y a pas (obligatoirement) de point centralisateur pour traiter toutes les requêtes des clients avant de les redistribuer vers les fournisseurs de services. L'architecture la plus commune se rapproche plutôt des CDN, tel Akamai, où les points d'accès sont distribués au plus près des fournisseurs d'accès pour être le plus proche possible des
utilisateurs. De la même manière, le distributeur va placer ses web-services chez les hébergeurs à côté des applications clientes pour diminuer au maximum les temps de transit. Cette multiplication des points d'accès chez les différents entreprises d'hébergement induit, de plus, un mécanisme de résilience
naturel en cas de défaillance de l'un d'eux.
Même si des éditeurs persistaient à revendre eux-mêmes l'accès à leurs api, ils ne pourraient pas bénéficier de l'ensemble des points d'accès placés chez les hébergeurs par les distributeurs. L'effort serait trop grand pour chaque acteur individuellement.

D'un point de vue contractuel ensuite, il est assez facile de prévoir des clauses de réversibilité si le distributeur venait à être en difficulté.
La nature de la prestation du distributeur permet de pouvoir aisément mettre à disposition des clients une "appliance" embarquant toutes les fonctionnalités d'accès aux services à la manière d'un proxy.
Ainsi le client pourra gérer son propre point d'accès et conserver tous les avantages de l'intermédiation si le distributeur venait à faire défaut.

Mode direct, mode indirect
L'arrivée massive de web-api en tout genre est en train de bouleverser l'approche du développement. Ce changement technique implique également de grandes modifications dans l'approche commerciale.

La revente d'utilisation d'api permet une intermédiation purement virtuelle organisée autour de services en ligne. Cette démarche se rapproche plus de l'activité classique de la grande distribution que du VAR traditionnel :

- catalogue : linéaire de la grande surface, tout est disponible au même
  endroit
- support unifié : service après vente
- achat en gros auprès des fournisseurs et revente au détail
- gestion de la logistique (point d'accès au plus près du consommateur)
- notion de marque de distribution, gage de qualité

Ce glissement à venir du mode de vente direct au mode indirect pour les applications Saas et les api correspond à une meilleure redistribution des efforts. Aujourd'hui les éditeurs (et les startup en particuliers) doivent s'impliquer autant dans la R&D pour offrir des applications innovantes que dans
la commercialisation de leur produit pour générer les revenus indispensables au bon fonctionnement de l'entreprise. Pour de petites pme, il est difficile de progresser au même rythme sur tous les fronts. Pour des raisons de ressources, de culture, de maturité, l'une des activités se fait souvent au détriment de l'autre.

Si vous souhaitez prendre contact : http://www.faascape.com/contact/contact.html

Xavier Milliard

http://www.faascape.com

lundi 7 novembre 2011

En quoi les fournisseurs cloud et api peuvent-ils changer la chaine logistique Internet ?

La mise en oeuvre d'une application web nécessite l'utilisation d'une chaîne logistique faisant intervenir plusieurs fournisseurs.

Quelles sont les composantes de cette chaine  ?

1) Infrastructure

La prestation d'hébergement met à disposition les ressources matérielles permettant l'accès des utilisateurs à l'application.

Elle fournit, au minimum, alimentation électrique, connectivité et éventuellement ressources de calcul (ram, cpu, stockage, ...).
Le coût de l'hébergement est en général basé sur un forfait mensuel ou annuel.

Un coût d'installation forfaitaire est très souvent présent au démarrage de la plate forme. Cette installation génère un délai dans la mise à disposition des machines.

La mise en place manuelle de cette infrastructure nécessite des actions (manutention, câblage, initialisation, formatage, ...) dont l'efficacité est limitée par le monde physique.
    Les avantages sur ce premier maillon du mode cloud, proposant des ressources virtualisées, sont :
    • des délais de mises en oeuvre raccourcis (provisionning) du fait du self service sans intermédiaire
    • l'ajustement de l'infrastructure aux besoins réels (modification du  dimensionnement sans délai)
    • la diminution des coûts en relation avec la prise en compte de la consommation effective
    2) Briques techniques

    Les ressources matérielles mises à disposition précédemment reçoivent des briques logicielles techniques liées au rôle de chaque serveur dans l'architecture : base de données, serveur d'application, moteur de recherche, etc.

    En fonction du type de logiciel utilisé, il faut prendre en compte  des coûts d'installation, de configuration et éventuellement de licence.

    Certains fournisseurs de cloud offrent des "briques techniques" clés en main comprenant à la fois les éléments d'infrastructure et les briques techniques associées. Ainsi vous ne louez plus un serveur avec 12Go de RAM et 6 coeurs sur lequel vous installerez votre moteur de base de données, mais un package "Base de données taille moyenne". Dans un monde idéal vous pourriez, le moment venu,  faire simplement évoluer votre package vers "Base de données grande taille et fort trafic" sans reconfiguration manuelle de votre part.

    La capacité de pouvoir ajuster plus ou moins automatiquement le dimensionnement de l'ensemble des couches techniques (infrastructure + logiciel technique) est un point important qui permet de gagner en coût, en flexibilité et en qualité.

    3) Briques métiers

    Au dessus des éléments techniques on peut trouver des briques applicatives métier (logiciel e-commerce, gestion de contenu, CRM, logiciel métier spécifique Saas, ...). De la même manière que pour les couches précédentes, des configurations complètes sont disponibles en self service chez certains fournisseurs.

    Les clients peuvent aussi court-circuiter les deux étapes précédentes (infrastructure et brique technique) pour louer directement l'accès à la solution métier (mode SaaS).

    Quoiqu'il en soit, la notion de self-service permet de disposer de certaines fonctionnalités :
    • très rapidement,
    • à des coûts très raisonnables,
    • sans compétence technique très pointue
    Une fois les applications opérationelles, certaines questions commencent à se poser :
    • quid de l'interaction entre les différents fournisseurs / plate formes / logiciels ?
    • est-il possible de compléter facilement une application Saas (clé en main) par un développement spécifique ?
    • la récupération des données, le changement de prestataire est-il possible à moindre frais ?

    4) La place des API

    L'une des tendances qui se dégage aujourd'hui est la mise à disposition, par tous les intermédiaires de la chaîne,  d'API permettant d'interagir avec les solutions.
    • les hébergeurs cloud proposent des api permettant de contrôle et modifier les configurations des ressources utilisées sur la plate forme. Cette fonctionnalité autorise les clients à mettre en oeuvre leurs propres règles de fonctionnement et de gestion de ressources.
    • c'est la même chose pour les briques techniques, il est possible via quelques api judicieusement mises à disposition de pouvoir prendre le contrôle du dimensionnement (et donc de la consommation) de la globalité de la plate forme. Par exemple, la détection d'un temps de réponse supérieur à un seuil donné déclenchera la modification d'un paramètre décrivant la taille d'un cache. Ces règles sont très délicates à mettre en oeuvre et ne doivent pas être manipulées inconsidérément  et sans préparation. Néanmoins, avoir la capacité d'ajuster facilement son infrastructure à ses besoins est un point très important. Cela est particulièrement efficace si les logiciels techniques et l'infrastructure peuvent être ajustées de manière coordonnée (et automatique ?)
    • les applicatifs métiers, enfin, donnent accès aux fonctionnalités et aux données via des api ad hoc et permettent ainsi un certain degré d'interopérabilité entre différentes solutions.
    Ces deux points essentiels (self service et utilisation d'api) permettent un gain considérable de temps et d'argent.

    Il y a un retournement important dans la manière de piloter l'ensemble des éléments de la chaîne. Avec l'approche traditionnelle, le client (ou un prestataire unique) pilotait l'ensemble des activités effectuées par tous les fournisseurs. Avec l'automatisation de la gestion des ressources, il n'y a plus de multiples prestataires à suivre mais un seul, responsable de l'assemblage des différentes ressources mises à disposition sans interlocuteur intermédiaire.

    Cette nouvelle organisation impacte la valeur ajoutée perçue des grosses entreprises qui intègrent l'ensemble des compétences de la chaîne. Ce qui était précédemment un avantage déterminant en terme de gestion de projet (meilleure communication entre les différents intervenants, méthodologie commune, ...) est maintenant à la portée d'intégrateurs de plus petite taille manipulant des ressources virtuelles. Le nombre d'intermédiaires est réduit, les délais sont raccourcis, l'organisation est simplifiée.

    Plusieurs points doivent être néanmoins examinés avec attention pour s'assurer que cette vision idéale ne soit pas dégradée :
    • importance des opérateurs télécoms : la communication entre les différents fournisseurs de ressources est un élément critique. Une mauvaise interconnection avec les fournisseurs et c'est toute la chaîne qui en pâtit.
    • responsabilité : l'avantage du fournisseur intégré est encore la prise de responsabilité unique, le dos qui prendra la bâton en cas de problème.
    En copiant les mécanismes de résilience d'Internet (si un problème survient à
    un endroit du réseau, les données pourront transiter par un autre chemin), on
    peut agréger différents fournisseurs de la même prestation et activer tel ou
    tel prestataire en fonction de la charge, des tarifs, ...

    A la crainte de dilution de responsabilité à travers une myriade de fournisseurs, on peut opposer :
    • l'intérêt de chacun des prestataires à la qualité de sa source principale de revenu
    • le bénéfice de la mutualisation des efforts des vendeurs d'API pour tous leurs clients

    La mise à disposition de web-services offrant des fonctionnalités prêtes à
    l'emploi commence à démocratiser l'approche du développement basée sur
    l'assemblage.

    Cette tendance possède de nombreuses vertus mais nécessite un changement d'état
    d'esprit pour en tirer tous les bénéfices : passer du "je contrôle toute la
    chaîne technique" à "je m'appuie sur des forces extérieures à mon entreprise"
    pour aller plus vite, faire baisser mes coûts, augmenter la qualité.
    En un mot comme en cent, passer de l'IT traditionnel au mode Internet.

    mercredi 30 mars 2011

    Pourquoi API et Web-Services sont les carburants indispensables au développement de votre business ?

    Le lancement d'un nouveau site permettant la vente de produits en ligne, l'amélioration de votre relation client, l'utilisation de votre application Saas ou plus largement tout ce qui facilite l'interaction avec vos clients et prospects est un exercice délicat.

    Il faut soigner l'ergonomie, l'aspect visuel, la pertinence et l'efficacité des fonctionnalités proposées.

    Une fois votre application en place, il faut amener les utilisateurs à surfer sur votre site. Tout une panoplie de moyens divers et variés sont à votre disposition depuis le référencement et l'achat de mots-clés jusqu'aux réseaux sociaux en passant par l'envoi de newsletters et bien d'autres encore.
    Si vous en avez les moyens, vous pourrez même utiliser d'autres médias : journaux, radios, télévision, affichage pour faire connaitre votre site.

    Vous allez ensuite fiévreusement mesurer les variations de trafic et ajuster les arguments et les cibles vos campagnes.

    Votre chiffre d'affaire est proportionnel au volume de visites, le but est donc de maximiser ce flux.

    Dans cette optique, et pour toucher toujours plus d'utilisateurs, vous allez décliner votre application en version mobile et tablette.

    La règle générale est toujours la même, il faut attirer le chaland dans votre "boutique".

    Une fois tout cela effectué, optimisé, industrialisé comment faire pour augmenter encore votre visibilité ?

    L'étape suivante consiste à inverser le processus. Plutôt que de faire venir les utilisateurs à vous, il faut projeter vos fonctionnalités, vos contenus, vos services vers les utilisateurs sur différents points de consommation, sur des sites et applications tierces.

    La manière la plus simple d'atteindre cet objectif est d'ouvrir votre application et permettre ainsi l'usage de vos contenus et fonctionnalités à l'extérieur de votre site par des tiers.

    D'un point de vue technique, il "suffit" d'ajouter un ensemble de web-services autorisant l'utilisation de vos fonctionnalités hors de votre contexte sans votre interface utilisateur.

    Ces web-services (appelés également API :Application Programming Interface) correspondent à des urls (http://services.monsite.fr/catalogue/audiovisuel/télévisions/promos) qui au lieu de produire des informations destinées à être affichées dans un navigateur, fabrique des données destinées à d'autres applications. On peut également créer des urls pour ajouter, modifier ou supprimer des informations.
    Cette interface doit refléter des traitements ou des données métiers et non pas techniques

    Si vous créez une nouvelle application, le choix de cette architecture dès le départ facilitera vos développements puisque votre propre application consommera vos fonctionnalités de la même manière qu'une application extérieure.

    La publication d'une API publique ouvre la voie à des usages nettement plus variés que ce que vous aviez imaginé initialement. Ces nouveaux usages sont le fruit de développements externes qui ne sont plus à votre charge.

    En mettant à disposition vos API, vous permettez à des tiers de générer de la valeur à travers vous et pour l'avantage de tous.

    Soyez néanmoins prudent, la mise à disposition de web-services ne doit pas s'improviser. Ces derniers doivent être très simple à utiliser, faute de quoi les développeurs ne s'y intéresseront pas, sécurisés et harmonieusement intégrés à votre plate forme.

    Quelques exemples et chiffres

    • Google et Facebook traitent 5 milliards de requêtes (chacun) quotidiennement sur leurs API,
    • 75% du trafic de Twitter (3 milliards d'appels par jour) est relatif à l'utilisation de ses web-services,
    • NetFlix génère 20 Milliards requêtes / mois.

    Rien d'exceptionel pour ce type d'acteurs que d'offrir l'accès à leur plate forme à des développeurs extérieurs.

    Du côté des commerçants, si personne ne s'étonnera de la publication d'API chez des acteurs comme Amazon ou Ebay, on trouvera peut être plus surprenant la position de BestBuy, d'USA Today, du New York Times ou de Zappos sur ce sujet.

    Voici quelques références parmi un grand nombre qui ne cesse d'augmenter :

    Distribution, commerce


    Média


    Finance



    Je vous invite à parcourir ces sites qui pourront peut être susciter des vocations et si des questions supplémentaires ou des projets voyaient le jour, n'hésitez pas à nous contacter : http://www.faascape.com/contact/contact.html


    http://www.faascape.com

    lundi 24 janvier 2011

    Le classement mondial des éditeurs logiciels, que faire pour que ça change

    Le classement mondial des éditeurs logiciels

    Il y a quelques jours, l'AFDEL a dévoilé son étude annuelle sur le classement des éditeurs logiciels. A l'occasion de cet évènement, divers commentaires ont été exprimés, nous y reviendrons par la suite.

    Commençons par examiner quelques éléments de cette dernière, fruit du travail de PwC  et PAC.

    L'étude

    1) Classement mondial
    Sur les 100 premiers éditeurs mondiaux, on trouve une seule entreprise française, Dassault Systèmes, en 22ième position. Il n'y a que 13 éditeurs européens dont le premier est SAP en 4ième position. L'écrasante majorité des places de ce classement est occupée par des compagnies américaines qui prennent 9 des 10 premières places.

    Notons que si ce classement prenait en compte l'industrie du jeu, deux français entreraient dans le classement : Activision Blizzard et Ubisoft.

    2) Saas
    On trouve dans le classement, les éditeurs diffusant, tout ou partie de leur logiciel, en mode Saas :
    Salesforce : 24
    Amazon : 40
    Google : 48
    Le classement ne prend, bien entendu, en compte que les revenus liés à la vente de logiciels.
    La proportion est encore faible mais déjà tous les acteurs sont américains.

    En 2009, 3,7% des revenus de l'édition logicielle américaine était constitué à travers un canal Saas contre 1,1 en Europe.

    3) Europe
    Dans le classement européen, on compte 17 français dont un seul dans les dix premiers, notre champion national, Dassault systèmes, en 3ième position.

    Le détail du classement par pays fait apparaitre une très grosse différence entre les premières entreprises du classement et le reste du peloton. En France et en Allemagne le premier a un CA dix fois plus gros que son suivant.

    4) Asie
    Le Japon place 6 entreprises dans le top 100.

    La Chine et l'Inde sont encore loin derrière les premiers (un seul chinois dans les 100 premiers en 96ième position) mais recèlent un potentiel extrêmement important.


    Les commentaires

    http://www.lemondeducloud.fr/lire-opiniatre-l-afdel-poursuit-ses-actions-pour-doper-l-industrie-du-logiciel-32565.html
    http://itrmanager.com/articles/113771/rapport-pwc-afdel-logiciel-secteur-profonde-mutation.html
    http://www.distributique.com/actualites/lire-l-afdel-sonne-le-rassemblement-15711.html


    1) Changement de modèle
    L'industrie du logiciel commence à être significativement affecté par le phénomène du Saas. Au delà de la partie purement marketing, on voit émerger des modèles économiques innovants, de nouveaux canaux de distribution, des offres tarifaires différentes.

    Les technologies du cloud computing, du web, du Saas permettent à toutes les entreprises du secteur de proposer des solutions plus souples, plus simples, moins chères. La transition entre le modèle de vente traditionnel du logiciel et le Saas remets, en quelque sorte, les compteurs à zéro et permet aux entreprises imaginatives de se démarquer.

    2) Collaboration
    D'une manière générale, tout le monde constate la difficulté d'émerger dans la bagarre mondiale du secteur. L'une des approches permettant aux PME françaises de tirer leur épingle du jeu consiste à mettre en place des éco-systèmes de plusieurs entreprises collaborant pour générer de la valeur ajoutée pour leurs clients. Ces collaborations doivent avoir pour but la création d'une dynamique commerciale et être centrées sur l'efficacité à court terme, privilégier le "bottom-up" tactique plutôt que le "top-down" stratégique.

    Pour reprendre l'expression de Pierre Gattaz, il faut apprendre à "chasser en meute".

    Ces deux idées montrent bien que nous sommes à l'orée de changements importants sur le plan des modes de construction techniques des offres mais aussi sur la manière de les commercialiser.

    Ce contexte semble particulièrement favorable à notre initiative de "Coopérative du Cloud".

    http://www.faascape.com