API : la distribution des services 2.0

Le support avec une aide de qualité assurée à vos utilisateurs donne un vrai gage de professionnalisme pour vos équipes API et crée véritablement le lien avec votre communauté. 

Mais attention à ne pas consommer trop de ressources en interne pour assurer ce retour à vos utilisateurs ! 

Il faudra susciter la remontée d'informations via des canaux contrôlés et féderer l'entraide entre utilisateurs  avec des outils adaptés.

Voici quelques modules  qui feront de votre plateforme API un lieu d'échange, de construction et de collaboration.

Un forum

Le forum est au centre de votre communauté API et constitue la partie ''communautaire'' du support. Malgré son ancienneté, ce système est prisé par les développeurs et constitue un véritable outil d'échange, de collaboration et de consultations.

C'est en plus un outil qui permet de manager un grand nombre d'utilisateurs sans une grosse infrastructure.

C'est aussi une plate-forme puissante de community management , car elle permet un fort esprit d'engagement et de support réciproque entre membres du forum.

D'ailleurs, si votre forum est public, il permettra un référencement naturel de qualité (SEO) sur les problématiques liées à votre API ou votre secteur, qui viendra appuyer vos efforts en e-marketing.

Une FAQ

La partie FAQ, Frequently Asked Questions est la partie ''prévention'' du support. Elle permet de répondre d'une manière statique et sans consommer aucune ressource en interne à la plupart des questions qui seront posées. Ne la négligez pas car elle vous économise potentiellement beaucoup de ressources !

S'il y a beaucoup de questions, vous pouvez les décomposer en catégories et mettre un petit outil de recherche. Une bonne pratique est d'afficher les questions, et de générer au clic la réponse juste en dessous. Cela permet d'avoir affiché l'ensemble des problématiques sans avoir à descendre la page.

N'oubliez pas aussi de mettre un formulaire pour permettre aux développeurs de soumettre eux mêmes une question qui n'est pas dans FAQ . Vous aussi ,complétez la FAQ avec les retours fréquents des vos utilisateurs lors de discussions, via les feedback mails, les tweets ou sur votre page facebook.

Un Report de bug 

Il y aura des bugs. Ce n'est pas une fatalité.

Pour une amélioration continue de votre service par vos utilisateurs et pour une identification de ce qui ne marche pas, il faut qu'un développeur puisse vous faire remonter un bug.

Mais une simple adresse mail « reporter un bug » n'est pas très efficace car elle ne différencie pas les bugs importants des simples bugs d'affichage, ou de la priorité (urgence ou pas).

Un petit formulaire simple permet d'économiser un grand nombre de ressources en interne sur cette partie.

Au préalable , proposer de consulter un historique des bugs pour éviter les doublons. Si le bug ne fait pas partie de l'historique, alors vous proposerez à l'utilisateur reportant le bug de remplir en ligne les champs suivants :

- Titre de la page - Type de bug (menu déroulant) - Url de la page qui génère le bug - le statut du bug (1ère demande, 2ème demande) - Description du bug - Le niveau de priorité (urgence de 1 à 5) - Son email - la possibilité d'envoyer un screenshot pour montrer à vos équipes

Cet outil permet dont un retour technique en temps réel de la plateforme, et directement à vos équipes techniques sans polluer le forum de messages « bug, big bug, does'nt work, why it does'nt work... » qui ne laissent pas une bonne image du service quand un visiteur vient pour la 1èer fois.

Statut de disponibilité, compte Twitter

La transparence sur vos ressources et sur la disponibilité de votre API est importante pour votre image et votre crédibilité.

Mais les APIs tombent , ont besoin de maintenance et aucune API qui a vu le succès de fédérer une communauté de développeurs n'est fiable à 100% du temps. Même les plus gros comme Twitter ou Facebook ont des problèmes, c'est normal et les développeurs le comprennent.

Cependant, ce n'est pas une raison pour ne pas faire très attention à la chute de votre API qui doit être exceptionnelle et laquelle vous devez vite réagir en prenant des mesures.

Pour informer les développeurs et leur donner de la visibilité , il est recommandé de mettre en place un tableau de bord qui montre :

- Le statut actuel de l'API et son taux de disponibilité - L'historique des interruptions de service de l'API - Un planning estimatif des taux de disponibilité (dans le cas de requêtes saisonnières ou à des moments identifiés) - Les fonctionnalités qui sont le plus touchées par les pannes.

Un compte twitter de l'API qui indique le statut de l'API, qui tweete les pannes et le retour du service en temps réel est un outil intelligent pour votre communauté.

Cette transparence à 2 principaux avantages :

Elle réduira les ressources en interne nécessaires pour répondre aux utilisateurs qui demanderont des informations par mail ou par téléphone

Elle donnera un gage de crédibilité et de professionnalisme dans votre API pour établir uen relation de confiance entre vous et votre communauté.

Termes of use et conditions et d'utilisation

En effet, votre API est une extension de votre société. Vous devez penser la manière dont vous autorisez vos utilisateurs à « représenter votre service en votre nom »

Cette partie est à réaliser avec un avocat, mais quelques conseils peuvent être donnés.

Restez simples dans les droits que vous autorisez, et faites ressortir clairement votre politique de ré-utilisation. Fermée, semi-libre, ou libre, peu importe tant que le développeur comprend ses droits. Vous pouvez d'ailleurs vous inspirer de ce que font les concurrents qui ont le m^meme positionnement que vous, car ils possèdent déjà un historique et ont souvent re-travaillé plusieurs fois cette partie avec leur avocats. Cette partie est facilement accessible, vous la retravaillerez en l'adaptant à votre cas spécifique.

Ne pouvant pas prévoir la créativité et les usages que les développeurs feront de votre API, pensez à faire évoluer les conditions en fonctions des applications et des usages tiers.

N'oubliez pas de mentionner dans les termes et conditions d'utilisation votre stratégie de marque et si les développeurs doivent mentionner votre logo, ajouter un copyright et ou des mentions et attributions, ou publier leurs sources sous une certaine licence.

Calendrier, planning et roadmap

Tenez votre communauté informée des événements concernant votre plateforme API

Il peut s'agir des releases, des updates, des sessions de maintenance, des webinars, des conférences, des challenges, des hackathons. Le moindre changement a potentiellement son importance, et pour cela pensez à communiquer avec autant de transparence que s'il fallait le faire avec les salariés de la plateforme en interne.

Notifiez tous ces événements sur votre blog, compte twitter de l'API et surtout la page d'acceuil du portail, avec un flux RSS.

Tous ces événements pourront être mis sous la forme d'une calendrier VCS, iCal ou Google Calendar pour pouvoir utiliser votre planning comme outil marketing. Directement implanté dans l'emploi du temps de vos utilisateurs, s'ils le désirent bien sur, il donnera plus de visibilité à vos actions pour votre communauté.

Une approche innovante de community management pourrait être même de laisser les membres de la communauté poster leurs rencontres et réunions sur le calendrier officiel.

Module de pré-paiement

Pour les business models payants ou Freemium, il est conseillé de mettre en place un système de pré-paiement pour simplifier et fluidifier la facturation.

En effet, au lieu de facturer à la fin d'une période donnée, vous pouvez offrir une option de pré-paiement, ce qui donne du sens car il est souvent difficile de facturer des utilisateurs qui ont sous -estimé le succès de leur application et qui n'accepteront pas de payer ce qu'ils ont consommé.

De leur côté, cela leur permet de piloter leur application avec un budget planifié et de contrôler leurs dépenses et leur trsoererie.

Support spécifique sur demande

Pour des demandes très spécifiques sur les API, peut être facturé un ''custom support'' ou un ''premium support'' correspondant à des demandes particulières. Ce support doit être facturé au temps passé sur des problématiques non encore résolues dans le forum et qui nécessitent un traitement immédiat au milieu d'une grosse communauté d'utilisateurs. Ce seront plutôt des partenaires professionnels qui seront prêts à effectuer ce genre de demandes. (SLA , nombre de requêtes supérieur au quota, statistiques avancées, etc...)

Contacts

La documentation est le véritable outil de travail du développeur dont l'application n'est que l'aboutissement. Elle doit être accessible en mode public, sans authentification et au moins en anglais. Pour une communauté française , cela peut être un avantage d'avoir une documentation dans la langue de molière, mais à défaut de temps, faites la en anglais.

Il faut la penser comme un outil professionnel, et donc la faire coller au mieux aux attentes des développeurs.

Pour cela, quelques bonnes pratiques que vous retrouverez sur la majorité des portails API de qualité :

Des exemples et du code prêt à copier/coller

En effet, des exemples de script, avec des 'run code' ou des 'try me' pour voir dans une vue dynamique le résultat exécuté du code permettront de comprendre comment le code fonctionne et d'en voir les applications immédiatement.

Des bouts de code directement utilisables, en copier/coller pour des applications prêtes à l'emploi, dsont autant de productivité que les développeurs sauront apprécier.

Pour les non-développeurs, pensez à mettre des boutons qui génèrent des embed, qu'ils auront directement à mettre dans leur page HTML pour certaines foncionnalités de votre API . Les boutons connect( Facebook connect, Twitter connect, Linkedin connect et Viadeo connect utilisent ce système)

Un Changelog (journal des modifications)

Gardez les développeurs au courant de toutes les changements de documentation ou de fonctionnalité en éditant un fichier ''changelog'', traduisez par journal des modifications, qui fera état de toutes les actualisations et mise à jour de contenu.

Des libraires et SDK (Software Development Kit)

Les développeurs ne travaillent pas tous avec les mêmes langages. Il faut donc que vous offriez , toujours selon votre cible, des libraires et de SDK dans différents langages de programmation.

Actionscript, Curl, Ruby, Delphi, Java, scala, go, .NET, Objective C, Perl, PHP, Python etc....

Tout le travail que vous ferez sera autant de travail qui ne sera pas à faire par vos développeurs utilisateurs. N'hésitez pas à susciter l'intérêt pour votre communauté de participer à cet effort, pour des langages que vous n'auriez pas mis d'entrée dans l'API.

N'oubliez pas  un Mobile SDK si vous vous orientez vers des développeurs mobile. En effet, une API est la seule porte d'entrée pour les applications mobiles, donc elle dirige tout votre écosystème mobile, vous ne devez pas négligez l'expérience mobile de vos utilisateurs finaux et donc fournir les outils adaptés aux développeurs. Cela peut se présenter comme des outils pour site mobiles ou pour plateforme iOS, Android ou BlackBerry directement.

Tutoriaux interactifs et multimédias

Vous devez éduquer votre communauté avec pédagogie et des outils interactifs. Une communauté éduquée est une communauté qui utilise pleinement les fonctionnalités de votre API en fonction de leur besoin.

Pour cela il faut fournir des tutoriaux visuels ou vidéos, des présentations de type slides ou même des webinaires, es études de cas expliquées...

Utilisez alors une chaîne Youtube (ou Dailymotion) pour les vidéos, slideshare pour les présentations et animez les par du contenu régulier. Pour faciliter cette mise à jour de contenu, le community manager peut s'appuyer sur des éléments générés par la communauté, tout ne doit pas être fait par les personnes en interne.

 Console d'exploration et de debug

Dans le cas d'une API REST, une console d'exploration dans votre documentation permet aux développeurs de vérifier les réponses que renvoie l'API via une interface web.

Page d'accueil de votre portail développeurs

Votre page d'accueil doit pouvoir accueillir tous les potentiels utilisateurs de votre écosystème, qu'ils soient techniques ou non techniques, partenaires de premier ou de second rang. Ils doivent , à partir de cette simple page avoir accès aux informations et fonctionnalités qu'ils recherchent.

Elle doit notamment rediriger directement vers :

L'API et sa documentation (notamment sans enreistrement!)

Le support et le centre d'aide

votre communauté et vos contenus

Votre portail développeurs doit être vivant, actualisé avec du contenu et faire ressortir ce qui se passe en ce moment sur le portail. Mise à jour, nouvelle version bientôt, concours d'applications...

Le parcours développeur ou l'expérience développeur

Voici un bref aperçu d'un parcours développeurs cohérent, qui doit intervenir juste après avoir été accueilli sur le portail.

Une page : Vue générale de votre API

C'est un excellent point d'entrée pour expliquer le pourquoi de la sortie de votre API. Il permettra à la fois aux développeurs et aux non développeurs de comprendre la problématique qui vous a poussé à sortir une API de vos services , le problème que vous essayez de résoudre et votre intention auprès de l'écosystème innovant.

Vous pourrez décrire dessus les fonctionnalités principales et ce qui est possible de faire comme applications avec :

- Des liens vers des études de cas qui montreront les utilisations possibles dans divers types d'industries

- des liens vers des livres blancs, qui permettront de comprendre une problématique à la quelle répond votre API et de se positionner par rapport à elle.

- des liens vers des articles externes à votre entreprise qui parlent de votre API qui viendront donner de la crédibilité de votre plate-forme (articles de blogs, podcasts,

Une page : Découverte

La découverte d'une API est une phase cruciale, qui va faire adhérer les développeurs à votre API, à condition que vous sachiez les garder attentifs. Pour cela il faut répondre concrètement aux questions qu'ils se posent

- Qu'est ce qui est accessible via l'API ? - Pour quel genre d'applications ? - Comment on s'enregistre ? - Quel protocole d'authentification est utilisé ? - La documentation est elle claire et accessible ? Dans mon langage de programmation ? - Y a t-il un forum d'entraide ? Qu'en est il du support ?

Une page : Authentification et sécurité

La sécurité est l'une des choses les plus importantes pour un développeur, et c'est la raison pour laquelle il doit comprendre très rapidement quelle méthode d'authentification vous utilisez.

Nous conseillons d'utiliser les standards, que sont Oauth (et notamment Oauth 2.0 maintenant) , mais vous pouvez avoir votre propre protocole.

C'est un point tellement important qu'il peut faire la différence entre 2 fournisseur API d'un même service.

Publiez également à cet endroit votre politique de sécurité et des informations sur votre infrastructure (firewall, installation, architecture serveur, certificats, cryptage)

Une page : Bien démarrer

Cette partie doit aider les développeurs dans leur parcours pour tout de suite effectuer les premières étapes d'inscription

Elle doit permettre

- de s'enregistrer - obtenir sa clé d'API - s'authentifier - télécharger les outils nécessaires - de rappeler les possibilités d'usage de l'API en précisant la limite ou le quota de requêtes autorisées et les fonctionnalités Freemium ou Premium disponibles, le SLA et un accès à la licence d'utilisation.(voir après)

Cette succession d'étape doit être simple à remplir, pensez à la faire évoluer dans le temps avec les retours des développeurs. En effet, tout le temps passé à cette étape n'est pas encore productif, et peu jouer contre l'adoption de votre API.

Une page : documentation

Cette page permettra de mettre en avant le fait que vous avez une documentation claire et simple, faite pour faciliter la vie des développeurs. Elle doit montrer que vous avez pensé à tout et notamment à :

- des exemples, - du code de démonstration - des librairies dans différents langages - des SDK, une console d'exploration d'API des tutoriaux

Une page : communauté/Support  

Cette page servira à présenter rapidement ce qui est mis en œuvre pour et par la communauté de développeurs qui utilisent et les moyens techniques associés.

- un blog - un forum - un compte twitter - le statut de l'API - une FAQ - une chaîne Youtube - une assistance téléphonique - un planning des évènements importants

Une page roadmap 

En effet, il est important que les développeurs qui vont engager une relation professionnelle avec votre service savant dans quoi ils s'engagent pour ne pas être déçus et abandonner votre service aux dépends d'un un autre.

C'est en beta ? Dites le ? Ca va changer ? Dites le et dans ce cas faites participer la communauté !

Vous avez des projets à moyen terme, vous alller mettre l'accent sur certaines fonctionnalités, dites le également.

Sur cette page, vous présenterez les points stratégiques importants , notamment

- la roadmap prévue - les fonctionnalités attendues à moyen terme - les limitations de la BETA (si tel est le cas) - ce qui est stable ou pas encore - l'apport attendu par la communauté - où faire son feedback pour les équipes API

Le « Community Management», gestion de communauté d'une API  permet :

- La relation directe avec les développeurs - Le marketing et la veille concurrentielle   - La communication interne et externe, web ET terrain  Dans une entreprise qui utilise une API pour développer ses activités, le Community Management, assuré par un community manager est chargé de construire des relations durables avec lesd déverloppeurs, à travers des espaces communautaires (forums, blogs, réseaux sociaux) qu'il anime.

Les enjeux de la fonction du community management pour une API

Promotion de l'API et des services liés: 

Interventions éditoriales sur les blogs, forum, et espaces communautaires , à la fois orientés développeurs et marketing sectoriel.

Animation sur le blog du site et de l'API, animation des comptes twitters de l'API, Facebook de l'API, avec des informations de qualité et réponses aux demandes.

Ecoute, fidélisation et co-optation des développeurs : 

Réponses adaptées aux feedbacks développeurs témoignant de la capacité d'écoute de l'entreprise. Ses Interventions « éditoriales » sur les espaces communautaires pour attirer l'attention de nouveaux développeurs.

Améliorer la plate-forme technique de la communauté, en signalant les dysfonctionnements du site et veiller à la disponibilité technique de la plate-forme.

Transmettre aux équipes techniques les améliorations à apporter au site de la communauté.

Communication, représentation sur le terrain

Grâce à la mise à jour régulière de nouveaux contenus, à la multiplication de liens vers les activités/produits/services de l'entreprise

Par la présence physique à des réunions de développeurs,ateliers, workshops, des évenements, conférences, salons etc...

Veille, Compétitivité

Pour surveiller les initiatives et dégager les stratégies concurrentes

Identifier les nouveaux usages liés à son secteur, percevoir les signaux faibles

Le profil du community manager de vos API

N'espt pas community manager qui veut. C'est un poste spécifique qui nécessite un nombre de talents spécifiques.

Il faut un vrai community manager. Le meilleur profil est celui d'un geek extraverti, ou d'un communicant autodidacte en informatique. Sinon se rabattre sur un développeur ayant une double compétence en marketing/communication.

Pour le vérifier c'est assez simple. Vous pouvez voir à quel point il déjà intégré à des communautés de développeurs, s'il commente des articles, s'il écrit sur des forums, s'il a peut être lui même un blog, s'il fait partie d'une association d'hacktivistes, s'il a un compte twitter pertinent et si vous sentez que c'est quelqu'un de réactif, de curieux et d'éveillé sur le monde, surtout le monde du web et du mobile.

Il faut aussi que cette personne connaisse bien les problématiques de développement, si possible quelqu'un de niveau moyen intermédiaire en développement, qui saurait utiliser votre API pour faire une application. Il ne doit pas avoir réponse à tout mais pouvoir faire le lien avec les core développeurs en cas de problème, et il saura le faire car il aura la culture développeur nécessaire. Il doit être connecté (twitter, skype, blogosphère, forum, réseaux sociaux, Geekli.st et il ne faut pas trop l'embêter avec les horaires, tout comme pour un core développeur.

Pensez-le comme un développeur qui a choisi le côté obscur de la force, celui de la relation utilisateur/client du marketing et de la communication...

Cette personne doit être donc très impliquée dans le développement de l'API car il en est l'une des pièces maîtresses, et ses posts resteront pour toujours sur le blog et le forum, donc s'il s'en va cela se saura. La relation qu'il aura créé avec votre écosystème peut pâtir de son départ.

Comment trouver le community manager de mon API ?

Selon la taille de l'entreprise et la stratégie API, le volume des espaces communautaires à gérer, le Community Manager peut être recruté en interne, intégré à l'entreprise suite à un recrutement.

Nous verrons aussi pourquoi il ne faut pas externaliser la fonction dans le cas d'une API

Pour les web start-up dont l'API est au coeur du développement de l'entreprise

Par souci de pérennité , le community manager doit être assuré par une personne de confiance. Un des co-fondateurs ou par l'un des premiers salariés fondateurs, pas seulement impliquée mais engagée dans la réussite de la start-up. En effet le Community Manager est appelé à être stratégique pour le développement de l'entreprise et doit être considéré comme un membre à long terme dans l'entreprise. Il va être au moins aussi visible que le CEO sur la toile !

Il peut s'agit d'une question d'indépendance stratégique face à ce poste à haute visibilité. Vu qu'il consomme quand même beaucoup de temps , peut-être ne pas mette à ce poste directement le CTO , mais une fonction support du CTO.

Un point important : Le CTO et le CEO doivent s'impliquer dans le community management sur des points précis, en réponse à des articles ou pour des posts répérés par le community manager. Ils répondront alors en leur nom et qualité pour montrer la proximité et l'écoute des dirigeants de la start-up.

Pour les PME ou groupes industriels dont l'API est un enjeu commercial ou de visibilité

2 solutions. Le recrutement interne ou externe. De nombreuses entreprises optent pour le recrutement pour une question d'efficacité dans l'organisation du travail : notamment si le Community Manager est appelé à collaborer étroitement avec les différents services de l'entreprise : marketing, relation clients, chef produits, communication, etc. Mais intention , on ne s'improvise pas community manager !

Sinon il va falloir recruter.

Important : Pour une API, ne pas externaliser le community management

Des entreprises délèguent les responsabilités de Community Management à des intermédiaires - agences ou prestataires freelances

, ce qui comporte également plusieurs avantages : en termes de flexibilité (intervention contractuelle, plus économique) mais aussi en termes de prise de distance : le Community Manager externalisé a plus de latitude de prise de parole qu'un salarié de l'entreprise et se met plus facilement à la portée de la communauté. Une neutralité et une objectivité qui peuvent rendre ses interventions plus crédibles.

Mais pas pour une API.Il ne s'agit pas seulement de communication mais d'utilisation et de business.

Resumé : Les 4 erreurs à ne pas commettre

Ne pas s'occuper du community management quand il n'y a rien à faire, c'est une fonction à part entière.

Ne pas pas croire que tout le monde peut être community manager pour une API. Mettre un communicant, un commercial ou toute personne pas valable techniquement, cela se verra tout de suite et vous perdrez toute crédibilité.

Ne pas mettre non plus un stagiaire ou quelqu'un qui n'est pas engagé dans la réussite de l'entreprise ou de l'API tout du moins.

N'externalisez pas cette fonction, c'est trop important pour le développement de votre API et c'est en plus une fonction visible.

Conseil pratique : Mettre un blog/forum/plateforme collaborative directement sur votre site

Vous allez être au plus proche de vos utilisateurs, et ils vont découvrir une partie jusqu'alors secrète ou cachée de votre métier.

C'est une relation forte qui peut s'installer entre vous et les développeurs qui souhaitent utiliser votre webservice. Ne la négligez pas !

Alors dès le début, investissez sur cette relation privilégiée.

Un blog pour communiquer sur votre actualité, un forum pour échanger, un bouton de FAQ et de feedback/report bug accessible sur toutes les pages de votre plate-forme API.

Evitez tant que possible les plate-formes externes de blogging ou forum qui vont faire sortir les développeurs de votre page et de votre site, en implémentant ces éléments directement sur votre plate-forme développeurs.

Le succès d’un écosystème ouvert est fortement dépendant de l’enthousiasme et de réponse aux attentes des développeurs. Il faut alors anticiper leur attentes, dont une majorité son répertoriées ici.

Simplicité d'utilisation ; opter pour un protocole REST/JSON, tous les développeurs ne maîtrisent pas forcément les langages objets ! Elles représentent 80% des nouvelles openAPI. Exemples des API Google, Yahoo, Mappy, etc. Aussi , pensez à Fournir des SDK dans les langages de vos utilisateurs. 

une bonne documentation: des exemples, avec des bouts de code à copier coller pour les fonctions classiques, avec des 'run code' et des 'try me' pour voir dans une vue dynamique le résultat exécuté du bout de code présenté en exemple. Rendez la accessible sans authentification et en anglais.

Une console de développement/debug  qui permet de vérifier les réponses que renvoie l'API.

De l'enthousiasme, alors faites des applications intéressantes de démonstration et un tutorial de comment vous l'avez faite

Du lien, ouvrez une FAQ, un forum ou espace de discussion pour lire les questions et réponses, un bouton de feedback accessible sur toutes les pages, et si possible un community management pour animer le dialogue.

De la confiance en votre service, alors mettez l'historique du statut de l'API et de ses taux de disponibilités depuis sa création. En cas de chute du service, expliquez le pourquoi, soyez réactifs et pro et tout ira bien. Les services tombent, les bug s'arrangent, c'est le concret du développement, personne ne vous en tiendra rigueur si vous agissez

Liberté, les développeurs veulent des droits de ré-utilisation ouverts dans leurs application.

Les développeurs sont des gens logiques. Qu'ils aient fait de longues études ou qu'ils soient autodidactes, ils ne sont pas en général touchés par la communication traditionnelle, et n'adhèrent pas aux valeurs d'une marque par le simple fait de la publicité. Il y a même une sorte de rejet du monde de la grande consommation et du marketing.

Les développeurs sont pragmatiques et souhaitent du concret, du tangible, vous devrez communiquer auprès d'eux d'une manière différente de ce qu'on peut lire dans les livres ou de ce que les cabinets et agences classiques savent faire. 

Voici en 4 points les attentes principales des développeurs dans leur vie professionnelle quotidienne.

       les développeurs veulent augmenter leur productivité et se simplifier la vie

les développeurs veulent gagner de l'argent pour vivre de leur travail

les développeurs veulent augmenter leur champ de compétences

les développeurs veulent s'accomplir dans leur développement en réalisant de grandes choses et de grands projets, souvent engagés pour une cause.

Il faut adapter le niveau de sécurité de l'accès à votre API selon vos utilisateurs et l'usage que vous autorisez.

Il existe différents nivaux de sécurité techniques , les voici :

Identification : savoir à chaque fois qu'une même personne fait une requête.

Authentification : savoir que celui qui vous fait une requête est bien celui que vous pensez qu'il est,

Autorisation : savoir si celui qui vous fait la requête à le droit de faire cette requête

Cryptage : savoir que les données ne sont pas lisibles par un tiers

Limitation et quotas : limiter l'utilisation de votre service en fonction de l'identité réelle et les intentions de vos utilisateurs.

L'identification : Les clés d'API ou APIkeys

Les clés d'API permettent de générer une clé unique, ou avec le protocole UUID (universally unique identifier ) qui ve permettre de donner l'accès identifié d'un développeur à votre API.

Elles sont issues des premières Open APIs de FiclkR , Google et Yahoo.

L'API key est une première identification d'un même développeur à chaque fois qu'il va utiliser votre service., sans avoir besoin de s'identifier à chaque fois avec un mot de passe.

Il permet d'aller plus loin qu'avec la seule adresse IP avec laquelle il est plus difficile de remonter à l'utilisateur initial.

Attention : avec une API key vous prouvez uniquement que le compte développeur qui appelle votre API sera toujours le même. Il n'y a aucune notion de certification m'assurant que ce compte correspond à une personne donnée.

Le fait qu'il n'y ait pas d'authentification par mot de passe permet une expansion rapide du service

 - Quand et pourquoi utiliser une API key ?

Il faut utiliser une clé d'API dans le cas d'une Open API, avec données non sensibles dans une logique ouverte.

Leur facilité d'utilisation et leur flexibilité permettra une large utilisation de votre service avec en prime :

l'enregistrement les applications utilisant votre service

Maintenir les sessions actives des applications tierces et mash-up

gérer les quotas et les limites d'utilisation par application

d'établir statistiques par utilisateur et globales de votre service

- Exemples

Google Maps API ne demande qu'une clé d'API pour gérer les 25000 requêtes par jour autorisées par application. Les données de GoogleMaps ne sont pas sensibles et la carte du monde globale fournie par GoogleMap n'est pas différente selon l'authentification ou non de celui qui la fournit ou la regarde. Pas de données sensibles, pas d'accounting, l'API Key suffit amplement et facilite la ré-utilisation du service et permet de gérer facilement les quotas.

YahooPlacefinder API qui transforme les adresses en 'latitude' 'longitude' est aussi un bon exemple d'application aux données non sensibles.

Authentification : nom d'utilisateur/mot de passe

Avec des données plus sensibles, type données personnelles ou commerciales, la clé d'API n'est pas suffisante.

Vous devrez la compléter avec une authentification. Une des solutions les plus simples et les plus utilisées est la solution nom d'utilisateur/mot de passe , basé sur une authentification par le protocole HTTP.

Le problème de l'authentification par mot de passe est d'inciter ses utilisateurs à bien stocker le mot de passe et à si possible le crypter.

« La plus grosse faille de sécurité est assise devant l'ordinateur »

Mais si cette protection est effective, alors le nom d'utilisateur/mot de passe peut à cette condition être utilisé dans des interactions applications-applications.

D'ailleurs, dans le cas de l'utilisation d'une application serveur utilisant une base de données, qui requiert elle aussi un mot de passe, le problème est allors résolu.

- Quand utiliser une protection par login/mot de passe ?

Utilisez cette protection pour donner accès à des données personnelles ou commerciales de vos utilisateurs. Vous allez pouvoir authentifier vos utilisateurs, basés sur leur déclaration et leur boite mail.

Si vous avez un site qui compte déjà des utilisateurs qui se sont enregistrés par nom d'utilisateur/mot de passe, il peut être pratique pour les développeurs d'utiliser les mêmes identifiants utilisateurs pour leur compte développeur API.

Comme cela vos utilisateurs développeurs pourront accéder à leur compte sur votre site et à votre API de la même manière, sans avoir a s'authentifier 2 fois. (c'est ce que fait Twitter) 

Autorisation : L'open Authentication ou Oauth

OAuth est un protocole libre, créé par Blaine Cook et Chris Messina, qui permet l'authentification à une API sécurisée d'une façon simple et standard.

Du côté fournisseur d' API, OAuth permet de donner accès aux données de vos utilisateurs tout en protégeant leur pseudo et mot de passe.

Du côté développeur d'une application accédant à une API, OAuth est une façon de publier et d'interagir avec des données protégées des utlisateurs d'un webservice.

Du côté utilisateurs OAuth permet de donner, à une application ou un site « consommateur », l'accès à des informations personnelles sur un site "fournisseur" de service.

OAuth permet de gérer toutes les les autorisations sans avoir besoin de donner son identité à chaque fois.

- Comprendre l'Oauth, ou l'authentification par un site tiers

L'utilisation de OAuth se décompose en plusieurs étapes entre les applications tierces et mash-up utilisant votre API

      Un développeur doit déclarer la nouvelle application qu'il est en train de développer sur votre site avec lequel il souhaite se connecter.

Suite à cette déclaration, votre API lui fournit un identifiant et une clé secrète.

 A l'aide de ces codes, le site du développeur va rediriger ses utilisateurs vers une URL spécifique fournie par votre webservice, que vous avez spécifié dans la documentation de votre API, en retour, vous récupérez un code d'autorisation. Cette étape est normalement manuelle c'est à dire que l'utilisateur de l'application devra connecter à l'URL en passant son navigateur Web, généralement via une pop-up . A ce moment là, c'est votre web service qui  lui  demandera directement de se connecter avec son login/mot de passe habituel (s'il ne l'est pas déjà).  Ce qui veut bien dire que l'utilisateur de l'application tierce ou du mash-up qui tente de se connecter à votre webservice possède déjà un un compte officiel chez vous. 

Ce code, associé à l'identifiant de l'application et à votre utilisateur, lui permettra de se connecter sur une autre URL spécifique de votre webservice, que vous aurez aussi spécifié dans la documentation de l'API.

En retour le site du développeur recoit un jeton d'accès (token), qui permettra d'accéder aux données de l'utilisateur. Il sera nécessaire à chaque fois que l'application ou le mash-up effectueront une action spécifique (recherche, création, modification, ...) sur votre webservice, et ont une généralement une durée de vie.

Votre webservice envoie les données protégées voulues par l'application tierce ou le mash-up le temps de durée de vie du jeton d'accès.

- Quand utiliser Oauth ?

Le seul vrai avantage d'OAuth est de permettre de supprimer des accès via le service contenant mes données. Il n'y a donc pas à pour l'utilisateur à donner son login/motdepasse à chaque fois que son application demande un accès à une autre application tierce. On gère une fois les droits, et ils sont ensuite enregistrés pour toujours.

En d'autres mots, si vous voulez que votre API puisse être appelée automatiquement par d'autres API ou que votre API est liée à un site qui requiert une authentification, il vaut mieux utiliser la solution Oauth (OpenAuthentication)

Cryptage : Encryptage SSL

La quasi totalité des systèmes d'authentification ne sont en fait que des pseudo-authentifications, se basant sur l'identité déclarée des utilisateurs, et ne sont pas vraiment sécurisées sans un cryptage des données.

Dans une authentification classique, le mot de passe est encodé et non crypté. Il est alors facile de revenir au mot de passe initial.

La solution est d'utiliser un cryptage SSL pour toutes les interaction entre le client et le serveur. Cela peut néanmoins diminuer les performances de votre serveur.

En ce qui concerne l'Oauth, qui est un solution d'authentification et non pas une technologie, c'est quand même resistant aux attaques. Notamment le fait que si un tiers intercepte un jeton (token) dans une requête, le jeton devient alors obsolète pour la prochaine requête.

Pour protéger vos ressources des applications consommatrices, des développeurs gourmands ou malveillants et sécuriser votre service, il faudra pour votre API fournir des limitations d'utilisation à vos clients. Selon le business model de votre API, vous pourrez les moduler, notamment dans le cas du Freemium/Premium

Limites d'utilisation

La 'limite d'utilisation' est une limite basée sur un nombre fixe de transactions, dans un logique de limitation de stock.

Exemple : L'API de Geoportail qui est limitée à 150 000 requêtes avant d'être payante. C'est à dire que quelque soit la durée pour les atteindre, il devient payant d'utiliser le service au delà. Il se gère comme un stock.

Ce modèle peut être adapté dans un premier temps mais les développeurs savent qu'ils atteindront la limite « un jour » et ne peuvent pas considérer votre API comme une charge variable mais comme une charge fixe une fois la limite atteinte.

Quotas

Le quota est limite d'utilisation basée sur un nombre fixe de transactions sur une durée de temps définie, dans une logique de limitation de flux. Les quotas sont souvent exprimés par seconde, par heure, ou par jour.

Exemple : l'API GoogleMaps qui est limitée à 25 000 requêtes par jour. Tous les jours, le compteur revient à 0, vous avez donc une sorte de bande passante autorisée. Ce modle à l'avantage de faire payer à la variation de consommation est d'être perçu comme une charge variable pour les développeurs tiers.

SLA : Service Level Agreement

Le SLA est un niveau de disponibilité que le fournisseur d'API va assurer pour les applications tierces. Il peut se définir par un quota personnalisé en fonction des besoins du clients.

Si l'application tierce à des visites saisonnières, des pics récurrents à des moments précis de la journée, ou toute autre usage qui nécessite une adaptation des quotas standards présentés dans votre offre de services API.

Vous pouvez proposer un SLA standard dans votre offre mais il est conseillé de faire du cas par cas pour ne pas surdimensionner votre offre SLA.

Pour cela, mettez en place un formulaire de demande de contact pour mettre en place ce SLA directement avec vous. 

C'est un bon moyen de monétiser son API dans le cadre d'une version gratuite ou Freemium.

Surveiller le trafic de son API et décider des limites et quotas à mettre en place

Il existe plusieurs moyens de limiter l'utilisation de votre API pour gérer vos ressources ou méntiser votre service.

Vous pouvez limiter l'utilisation de votre API par compte développeur, par application, par société cliente, par clé 'API ou par adresse IP selon votre stratégie utilisateur.

Vous pouvez aussi différencier le trafic entre vos applications propriétaires, partenaires et externes, et mettre des requêtes en mémoire tampon, en cache ou en file d'attente selon leur priorité ou leur "qualité" gratuite ou payante.

Au niveau des statistiques liées à votre API, vous devrez aussi surveiller le trafic et mettre en place des procédures de remontée d'information. Vous devez être prévenu dès qu'une limite est dépassée par une application tierce, ou dès qu'un comportement sort de l'ordinaire, pic, croissance ou baisse soutenue sur une longue période pour réagir intelligemment.

Des systèmes d'alertes en cas de consommation à 70 ou 80 % de la limite permettront par exemple d'identifier les dépassement en amont.

Avec cette surveillance, vous pourrez identifier les tendances de consommation et les potentiels clients pour des services et quotas adaptés au cas par cas. Si vous vous rendez compte que tous les dimanche une application est proche des limites standards, il serait intéressant de les contacter pour comprendre pourquoi et proposer un quota adapté ou un SLA.

Vous devez aussi planifier votre réaction en cas de dépassement des quotas. Bloquerez vous tout simplement l'accès parce que vous ne voulez pas qu'on abuse de votre service, ou laisserez vous exceptionnellement des requêtes passer pour amorcer une démarche commerciale dans la foulée?

Une bonne solution, qui peut d'ailleurs se monétiser est de proposer aux développeurs les statistiques d'appels de leurs applications à votre API pour qu'ils puissent eux même manager leur trafic et faire la démarche auprès de vous directement en cas de demande adaptée.

Quel est votre but dans l'ouverture de vos services ? 

Augmenter votre chiffres d'affaires, créer une communauté de développeurs, découvrir de nouveaux usages en open innovation, donner de la visibilité à vos services, créer un écosystème autour de vos services, proposer à vos clients des services exclusifs, communiquer sur vos services...

Et selon votre but vous devez décider en amont d'un business model.

Business model PAYANT

Paiement selon l'utilisation: vous facturez selon l'utilisation, plus on consomme votre API , plus on vous paye. Ce modèle est intéressant si vous avez un service avec une valeur ajoutée immédiate, plutôt orientée BtoB. Pour la grande masse des développeurs, préférez un autre business model, freemium notamment, qui en est la version douce.

Freemium : vous donnez accès à un service gratuit limité , qui ouvre sur un service illimité ou plus complet mais payant. Il a l'avantage de générer beaucoup d'utilisateurs gratuits sur lesquels vous pourrez capitaliser dans le futur.  Attention à bien dimensionner son infrastructure pour ne pas avoir des coûts trop importants à assumer en attendant l'adhésion aux services premium.

Business model GRATUIT

« Si vous ne payez pas un service, c’est que vous n’êtes pas le consommateur, vous êtes le produit vendu" Andrew Lewis à propos du business model de Google.

Audience/Partage de revenus: Vous pouvez ouvrir une API en misant sur les retombées en terme de trafic qualifié ou de ventes généré sur votre site ou plate-forme. Intéressant si vous avez déjà un business model basé sur la visite de votre site, comme de la publicité ou bien du e-commerce. Votre API sera alors gratuite et basé uniquement sur l'expansion de votre service, avec des conditions d'accès à votre API simplifiées. Vous pouvez intéresser les développeurs en partageant les revenus générés par le trafic avec eux sous forme de commission

- Les modèles existants avant les APIs: tout ouvert ou tout fermé

La licence privée est un système complètement fermé, qui n'autorise aux utilisateurs aucune modification sur le produit qu'ils achètent. Ils sont souvent considérés comme des boites noires, et sont en général faits pour l'utilisation directe et prête à l'emploi. Prenons les cas grands publics des licences Microsoft office, ou des logiciels Apple.

L'open source est un mouvement international , venu d'abord du monde scientifique avec les problématiques transnationales de partage des données (en climatologie notamment). Ensuite le monde informatique a suivi et l'open source est un système qui tend à divulguer les sources pour la ré-utilisation libre et l'indépendance d'un utilisateur par rapport à son fournisseur.

- L'API, le bon compromis

L'API se situe entre les 2 , c'est vous de décider la manière dont vous souhaitez être ouverts ou être fermés

Est ce que les développeurs pourront ré-utiliser vos services facilement ? Quelles sont vos conditions de ré-utilisation ? Votre licence ? Quels droits accordez vous à vos utilisateurs ? Utilisez vous des technologies propriétaires ou libres ?

       Private API : API déstinée en interne d'un groupe ou une société. Souvent pour une utilisation pratique sur des sites distants ou pour avoir un accès uniformisé à un service. Elle permet un contrôle complet de sa ré-utilisation.

Partner API : API destinée aux partenaires et clients, elle peut être considérée comme semi-publique. Elle permet un contrôle  de sa ré-utilisation par le choix des ré-utilisateurs.

Open API : API publique, destinée à tous les utilisateurs qui veulent l'intégrer dans des applications tierces. Elle permet ne permet aucun contrôle sur sa ré-utilisation mais uniquement sur la limitation des requêtes de  ses ré-utilisateurs.

- Stratégie d'ouverture : cas d'une entreprise dont internet n'est pas le métier

- Cas n° 1 : un groupe ou une grosse entreprise, industriel ou commercial qui possède une technologie de pointe, une base de données propriétaire, un service exclusif.

En effet , il faut pour un groupe, en général garder son cœur de métier et son savoir faire sous format propriétaire. C'est l'avantage concurrentiel ou le savoir faire exclusif qui justement vous permet de générer votre chiffre d'affaires, et qui s'est construit après des années de développement, d'erreurs, de savoir-faire, et des millions d'euros investis. Il peut quand même ouvert à des partenaires très privilégiés dans des licences d'utilisation contraignantes et moyennant une grosse contrepartie financière.

Si vous êtes un opérateur telecom, comme ORANGE ou SFR vous pouvez mettre à disposition votre infrastructure pour faire des télécommunications

Si vous avez une base de données commerciales, comme Voyages-SNCF, vous pouvez vendre l'accès à vos données en temps réel, vos prix, horaires etc... a des agences de voyages privées Dans une politique d'ouverture plus axée business développement ou innovation, certains savoir-faires technologiques non stratégiques ou certaines bases de données commerciales peuvent être monétisées en laissant accès via une API aux développeurs partenaires ou clients. Ou par exemple un accès à une infrastructure.

Il peut s'agir de données commerciales comme PagesJaunes ou une cartographie routière comme Viamichelin.

Arrive le cas des données qui n'ont en soi pas de valeur commerciale, mais qui permettent à vos utilisateurs de gagner en productivité. C'est un service pratique qui est rendu avec votre API. Vous avez alors le choix de le mettre dans une version de l'API plus libre (par exemple autoriser l'utilisation à des fins non commerciales), ou même directement les libérer pour évangéliser votre service.

Si vous êtes un fournisseur de données, il s'agira de fournir en libre accès une API de traitement des fichiers ou de traduction.

Si vous êtes un réseau social, il s'agira de fournir un outil de publication ou d'inscription comme le Facebook connect, le Linkedin connect ou le Twitter connect.

Enfin il ne faut pas intégrer les données ou les services considérés comme ''utiles'' fermés dans votre API, mais au contraire les mettre à disposition d'une manière ouverte pour démocratiser votre service.

De toute façon ce service ne contient pas assez de valeur ajoutée pour être monétisé, et il est souvent mis à disposition par des concurrents, dont utiliser le comme un vecteur de publicité et de fidélisation. Si vous êtes un site de e-commerce, il peut s'agir d'un comparateur de devises, de calculs des frais de port, la liste de vos lieux de vente réels.

- Stratégie d'ouverture : cas d'une Société ou start-up dont internet est le métier (pure player)

- Cas n°2 : une start-up qui possède une technologie web ou un savoir faire spécifique

En effet, les start-up ont souvent une stratégie différente par rapport à la sortie d'une API.

Car le seul capital de la start-up est sa technologie ou son savoir faire technique spécifique Alors l'API sera basé exclusivement sur ce capital car il n'y a souvent que cela. Donc à la fois le cœur de métier les données et services commerciaux sont à mettre dans l'API. On pourra les différencier dans une API Premium pour les données stratégiques et une API Freemium pour les données commerciales et professionnelles.

Si vous êtes une start-up qui possède un moteur de recherche sémantique, vous pourrez mettre à disposition de vos partenaires cet outil via votre API. Si vous avez peur de perdre votre avantage concurrentiel, proposer le alors qu'à une certaine typologie de développeurs (voir la partie suivante « Droits d'accès à mon API » Pour les start-ups, les outils pratiques, productifs et utiles sont à prendre comme des investissements marketings, car la notoriété de la start-up ne permet pas, dans beaucoup de cas de monétiser ce genre de services. Il sont donc un outil de fidélisation et de communication auprès de ses utilisateurs.

Il faut  adapter à la fois sa politique de ré-utilisation et de ré-utilisateurs, comme on a pu le voir dans les posts précédents, selon que l'on recherche de l'innovation, du développement de business ou des revenus directs.

Récapitulatif en 4 points :

Plus la ré-utilisation de votre API sera ouverte, plus vous devrez cibler sur des populations qui cherchent l'utilisation de votre service.

Plus la ré-utilisation de votre API sera fermée, plus vous devrez cibler des populations qui cherchent à monétiser votre service.

Plus vous restreindrez l'accès à votre API, plus vous devrez ciblez une population qui cherche à monétiser votre service

Moins vous ouvrirez l'accès à votre API, plus devrez cibler une population qui cherche déjà  à utiliser votre service.

L'API permet de pondérer l'ouverture de vos services et de trouver avec justesse ce que vous êtes prêts à investir dans la sphère publique afin d'obtenir des retours sur investissement.

L'API va être un accès, certes limité, à vos programmes, vos serveurs, vos bases de données ou vos services, il faut donc que cet accès corresponde à votre marketing.

Il faut aussi pour cela déterminer pour qui l'on souhaite ouvrir ses services. Uniquement en intra-groupe ? En inter-entreprises ? Ouvert à tous ?

Cela dépend de la sensibilité du service, du degré d'avancement de la technologie et de la valeur des données mises à disposition.

- Comment cibler mes utilisateurs d' API ?

Avant de voir la gestion des droits de ré-utilisation de mon API, voici comment déterminer qui doit ré-utiliser votre webservice via votre API selon votre stratégie marketing.

Voulez vous contrôler l'utilisation à un cercle restreint de personnes ou libérer l'accès à votre API pour tout le monde ? Ou alors les uns après les autres ? Vos donnés sont elles sensibles ? A très forte valeur ajoutée ?

       Tout le monde : tous les gens qui possèdent la compétence pour développer des applications avec votre API. Cela va du passionné d'informatique, à l'étudiant, un développeur freelance et indépendant, au développeur salarié...

Selection : Il peut s'agir de développeurs d'un secteur d'activité en particulier, ou bien uniquement des professionnels reconnus, des partenaires commerciaux ou des clients existants à qui vous ouvrez une service complémentaire.

VIP : Il s'agit d'un petit nombre de personnes que vous autorisez à utiliser votre service. Il peut s'agir des salariés de votre groupe à travers un territoire donné, aux filiales, aux sociétés sœurs ou aux partenaires distributeurs exclusifs.

- Les acteurs cibles du développement informatique

Pour identifier envers qui vous voulez sortir votre service, il faut connaître les acteurs susceptibles d'utiliser votre API

Il peut s'agir :

de développeurs passionnés, étudiants, freelance, indépendants

de start-up, de TPE/PME, de Webagences, de SSII, d'éditeurs d'applications

d'éditeurs logiciels, d'intégrateurs, de grosses SSII, de groupes industriels, des géants de l'internet

- Cibler mes utilisateurs potentiels selon ma stratégie marketing.

Pour cela , il faut savoir ce que vous attendez de votre API. Vous avez pu voir dans la partie pourquoi sortir une API les 2 motivations liées que sont Innovation, Développement et Revenus. Alors vous allez cibler les les acteurs de l'écosystème du développement informatique selon leur capacité à répondre à votre besoin.

Voici la répartition des acteurs de l'écosystème des développeurs utilisateurs de votre API. 

Les raisons de fournir une API à son service web sont multiples, mais il faut bien comprendre que c'est un réseau de distribution supplémentaire pour votre service.

Principalement 3 choses sont recherchées dans l'ouverture d'une API : de l'innovation, du développement , du chiffre d'affaires.

         - Augmenter son chiffre d'affaires par des revenus directs

Une API distribue votre service ou vos données au delà de votre site internet. Ainsi vous pouvez mettre à disposition une partie de votre technologie, de votre base de données ou de votre savoir faire, de votre infrastructure , de votre hébergement pour la monétiser ou en amortir l'investissement.

Vous permettrez à des utilisateurs tiers de bénéficier d'un service haut de gamme selon leur besoin sans qu'ils aient à investir massivement pour développer leur propre service concurrent du votre.

Vous pourrez rentabiliser votre investissement en revendant/louant votre service avec une plus forte valeur ajoutée.

Quelques exemples :

AmazonS3 et Microsoft Azure fournissent des infrastructure cloud permettent de stocker et d'héberger des applications. Cela revient nécessite moins d'investissement de la part des start-ups pour s'équiper par des serveurs cloud et Amazon et Microsoft gagnent de l'argent grâce à des couts d'exploitation mutualisés que de passer par des serveurs dédiés.  

Youtube le service vidéo racheté par Google , permet via son API d'afficher une Vidéo Youtube sur n'importe quel site, grâce à l'embedding. Ainsi pour les développeurs et les blogueurs, il devient très facile de charger et d'afficher des vidéos en streaming alors que cela es plutôt compliqué et coûteux de monter soi même son propre serveur de streaming. Vu que le revenu de Youtube est généré par la publicité affichée, plus des vidéos Youtube seront affichées et lues dans les sites, les blogs et les pages web en général, plus le chiffre d'affaire de Youtube augmentera. C'est un circuit de distribution supplémentaire que le simple site www.youtube.com.

Voyages SNCF possède tous les tarifs, les horaires et le taux de remplissage des trais du site voyages-sncf.com, le site de e-commerce le plus visité de france. Voyages-sncf met à disposition des agences de voyages l'accès automatisé à sa base de données contre rémunération, via une API. Ainsi elle distribue le service de voyages-sncf aux professionnels au déla du simple site reservé plus aux particuliers.

Donc si vous avez une technologie , un service exclusif, une base de données propriétaire, vous pouvez en monétiser une partie directement via une API et ainsi augmenter votre chiffre d'affaires. (plus de détailes dans la partie business model)

- Gagner en notoriété, en visibilité, se développer et recruter des utilisateurs

Sortir une API peut avoir comme objectif de gagner en notoriété sur son service.

Elle pourra permettre si vous êtes un réseau social d'attirer de nouveaux utilisateurs, ou si vous avez un webservice particulier de répandre l'usage de votre service et dominer le marché par rapport à vos concurrents.

Si vous êtes un industriel ou un institutionnel qui met à disposition une technologie, une base de données ou un service propriétaire, cela permettra de communiquer sur votre service et son ouverture dans la presse et sur internet et atteindre ainsi de nouveaux clients, utilisateurs, ou partenaires.

Quelques exemples :

FlickR, site de stockage et d'affichage de photos sur leweb qui a conquis les professionnels des photos numériques par l'ouverture de son service via une API. Cette conquête des professionnels de la photo à été un fort prescripteur pour la diffusion du service comme LE service de photo sharing/photo hosting du web.

Foursquare, le réseau social géolocalisé qui permet de savoir ce qui se passe dans les commerces de proximité sous forme d'un jeu. Foursquare a gagné de nombreux utilisateurs via son API en obligeant ses utilisateurs à ouvrir un compte pour utiliser n'importe quelle application tierces qui utilise Foursquare. Ainsi, chaque application tierce qui utilise la puissante base de données de Foursquare était un agrégateur d'utilisateurs du réseau social. Je mets à disposition ma base de donnée pour votre application , ce qui me permettra d'obetnir des utilisateurs supplémentaires.

Les collectivités publiques et les états, qui ouvrent des données au public , dans la voie du mouvement OPENDATA. C'est le cas des gouvernements américains et anglais, de nombreuses villes à travers le monde (Chicago, New york, Paris, Rennes etc..) qui ont ouvert des données sur des portails web et ont ouvert des API pour aller directement utiliser les données. Ces collectivités ont pu fortement communiquersur leur transparence et leur volonté d'une démocratie 2.0. Leurs APIs ont permis à des développeurs de créer des applications tierces qui vont répandre les promesses de l'Opendata que sont la transparence et l'information à un maximum de citoyen et ainsi atteindre leurs objectifs d'évangélisation.

- Innovation ouverte avec les développeurs, nouveaux usages, nouveaux modèles de revenus

En effet une API permet de s'ouvrir à un écosystème de développeurs et de marketeurs qui vont développer des applications tierces avec votre service via votre API.

Des milliers de développeurs, d'ingénieurs, d'entrepreneurs, vont utiliser votre service pour créer des applications dont

vous n'auriez pas pensé,

vous n'aviez pas le temps pour les produire

vous n'aviez pas les moyens financiers pour les développer

De nouveaux usages et de nombreuses applications vont pouvoir être réalisées dans un temps record et pour des coûts moindres. On peut dire que vous "provoquez l'innovation par la sérendipité".

Vous obtiendrez les résultats du plus concret des brainstorming concernant vos modèles de revenus possibles en vous inspirant ce ce qui a été fait avec votre API. C'est donc cette analyse fine des tendances d'utilisation de votre service qui va vous permettre de relancer l'innovation en interne.

Prenons par exemple le cas de Twitter, le réseau social de micro-blogging limité à 140 caractères, qui possède plus d' 1 000 000 d'application tierces, qui ont été faites par les développeurs, et dont les services ont été rachetés par la maison mère Twitter au fil du temps.

Combien aurait coûté le développement de toutes ces applications ? Et combien de temps cela aurait pris pour les 450 employés ? 10 ans ? 20 ans ?

Twitter a sorti son API en 2006, a racheté au fur et à mesure des applications nées de l'idée des développeurs. Tweetie fut racheté le 9 avril 2010, Tweetdeck le 24 mai 2011 pour 40 Millions de $.

Des usages nouveaux comme le raccourcissement des URL (bit.ly ou tinyurl) ont été démocratisés

Lancé en 1999 par Ebay, puis suivi par Amazon en 2002, les API ou interface de programmation permettent de distribuer un webservice au delà d'un simple site internet . C'est avec le développement du cloud computing que les API ont pu facilement émerger.

On dénombre près de 25000 webservices dont des API s'ouvrent tous les jours. Plus de 5200 PI sont référecnées sur le site programmableweb.com, l'annuaire des API, bien qu'elles ne soient pas toutes dessus.

Il faut bien comprendre qu'une API n'est rien d'autre qu'un circuit de distribution pour votre service. Au lieu de promouvoir votre webservice uniquement sur votre site web monsite.com, vous allez pouvoir le promouvoir par l'affichage sur d'autres sites web, par une webapplication, par une application mobile, sur une tablette. Une fois la valeur de votre webservice bien identifiée dans son écosystème, vont se créer alors par le biais des développeurs  des applications tierces, que l'on appelle des mash-ups (mélange de plusieurs API dans une application) qui vont utiliser votre webservice et en tirer la meilleure valeur ajoutée pour leur utilisateur, donc pour vous.

Exemple de mash-up de 3 APIs : KANJARIV' permet faire une recherche sur la base Foursquare autour des gares Transilien SNCF , affichées sur une GoogleMaps.

-  Le cas des open API

Si votre API est complètement ouverte à tout développeur , alors elle sera considérée comme une open API et connaîta peut être le succès des API comme Googlemaps, FlickR ou Facebook, ou Twitter, qui ont été reprises dans plusieurs centaines de milliers de sites et reçoivent plusieurs milliards d 'appels par jour.

Vous devrez alors créer et animation d’une communauté de développeurs, mettre des exemples de code test, une documentation exhaustive dans chaque langage de programmation, puis organiser des challenges ou Hackathons (marathon du code),  des séminaires/conférences, et manager les appels de votre API pour identifier les tendances d'utilisation, pour sortir ensuite une 2ème version....

- Un outil pour les développeurs

Avant l'essor des API, vos webservices ne pouvaient être que opaques pour vos clients telle une licence logicielle "boîte noire", ou totalement ouverts avec l'open source, en divulguant potentiellement tout votre avantage concurrentiel.

Avec les API, maintenant vous avez le choix de placer la barrière où vous le souhaiter.    

Cet outil est fait pour les développeurs informatiques, qui sont par leur compétences  les seuls à pouvoir les utiliser pour les intégrer dans des applications tierces (web ou mobile) et évangéliser votre webservice.

Il peut être utilisé en interne comme un outil de travail collaboratif dans un groupe réparti en plusieurs sites (Closed API), ou avec des proches partenaires et clients (Semi-open API ou Partner API) , ou alors complètement ouvert (OpenAPI) et partagé avec qui pense y trouver une valeur ajoutée pour son métier ou son application, c'est à dire à la communauté des développeurs.