Ce que doit contenir un portail API (3/3) : Le support, la communauté, le centre d'aide
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
Enfin sur chaque page, n'oubliez pas de mettre un formulaire de contact avec menu déroulant pour en spécifier la raison , et si vous avez les ressources pour s'en occuper, ne numéro de téléphone d'assistance.














