Aucun homme n’est une île. Ce célèbre vers du poète anglais John Donne de 1624 résonne particulièrement en ce début de 21ème siècle. A l’époque de la 5G et de l’hyper-connexion, l’Homme ressemble plus à une carte du métro parisien, avec ses nœuds et ses lacets, qu’à une terre isolée au milieu d’un océan. On vise même à supprimer les derniers bastions insulaires, les fameuses zones blanches, pour sauver les naufragés du numérique et les embarquer avec nous sur le paquebot de l’internet. La France ne veut pas de Robinsons dans l’accès au digital.
Pourquoi parler de littérature britannique du XVIIème dans un billet sur les API ? Parce que la vision de John Donne s’adapte étonnamment bien à la situation actuelle du numérique (et qu’un peu de poésie n’a jamais tué personne). Aucun logiciel n’est une île. Ou plutôt, aucun logiciel ne devrait être une île.
Les API, définition et mise en oeuvre
Pour bien comprendre les API, intéressons-nous en premier lieu à ce qu’Accenture qualifiait en 2016 de « révolution industrielle silencieuse » : l’économie de plateforme.
Raisonner en plateforme c’est passer de la fourniture d’opportunités de consommation à la fourniture d’opportunités de création de valeur. Les interfaces de programmation applicatives (API donc) sont les piliers de cette nouvelle économie. Elles représentent une façon pour un logiciel de se brancher à un autre pour bénéficier de ses fonctionnalités et de ses données. Les API connectent des systèmes, des services et des technologies disparates. Ce sont elles qui rendent possible l’infrastructure virtuelle du cloud.
Les organisations peuvent ainsi intégrer les capacités logicielles d’autres plateformes dans leurs propres applications ou sites web. Cela permet de proposer des fonctionnalités supplémentaires qu’elles ne pourraient pas normalement fournir à leurs clients. On pense par exemple au « Click to Call » (appel téléphonique) d’Avencall que l’on peut ajouter à sa messagerie, carnets d’adresses et agendas BlueMind.
Pour les mettre en œuvre, les organisations doivent d’abord comprendre où les appliquer au mieux. L’analyse du parcours client est souvent le meilleur moyen d’identifier les opportunités d’API. Il permet d’identifier les points de friction et les endroits où l’on peut créer ou récupérer de la valeur. Par exemple, quand vous commandez une voiture sur Uber, la connexion avec votre banque qui permet de régler la course directement depuis votre téléphone, s’effectue via une API. Dans le parcours client de ce type de service, il est important de pouvoir régler une somme fixe (pas de surprise de la part du chauffeur) simplement (sans avoir à utiliser une carte bleue ou un autre outil que l’application Uber). En enlevant cette friction du parcours client, Uber assure un taux de transformation plus important.
Les données sont l’un des actifs les plus précieux d’une entreprise. En tant que clés de manipulation et exploitation de ces données, les API elles-mêmes deviennent extrêmement précieuses. Pour le MagIT « ces interfaces de programmation permettent d’ouvrir des SI préhistoriques à l’innovation et de relancer des secteurs de plus en plus sous pression, » comme les compagnies aériennes ou les banques par exemple.
BlueMind et les API
La messagerie de BlueMind fait partie des solutions conçues dès le départ sur le principe des API, permettant à notre écosystème de co-construire le produit au travers d’une marketplace.
Toutes les opérations de BlueMind passent par des APIs webservices, qui sont donc l’unique point d’entrée aux données de la solution. Ce choix technique garantit la cohérence et la complétude de toutes les opérations effectuées via le composant BM-Core. Il permet surtout une intégration simple avec tous types de composants et logiciels tiers et apporte ainsi une interconnexion facilitée au système d’informations.
En plus d’interagir via les webservices, BlueMind a conçu un système de plugins permettant de modifier ou d’étendre les fonctionnalités. Grâce à cette technologie, il est maintenant possible d’adapter ou d’enrichir la solution mail, facilement, sans la modifier. Par exemple BlueMind permet de définir ou modifier par plugin les règles de la création de mot de passe afin de laisser la liberté aux administrateur d’établir leurs propres normes de sécurité. Pour définir un format standard de mot de passe (majuscule, caractères spéciaux etc.) vous pouvez utiliser un add-on de la marketplace.
De plus, via des points d’extension maintenus entre les versions, les plugins BlueMind restent compatibles avec les versions à venir de la solution : les modifications faites par vous-même ou votre intégrateur restent utilisables même après des mises à jour mineures ou majeures.
Les plugins vous permettent aussi de modifier dynamiquement les interfaces utilisateur et administrateur. En combinant API web-services et plugins, BlueMind vous facilite le développement de fonctionnalités additionnelles comme la gestion des signatures d’entreprise, l’intégration de logiciels tiers (nextcloud) etc.
Côté technique, notre API est constituée de web services REST, soit accessibles directement via des appels HTTP REST, soit via l’utilisation des clients fournis (aujourd’hui pour Java, Javascript, C#, Python et PHP). Le repository bluemind-samples est disponible et rassemble tout ce qui est nécessaire pour contribuer à BlueMind en développant un Add-On. Un archetype maven est également disponible pour faciliter la définition d’un nouveau projet.
Que peut-on imaginer avec des API dans la messagerie ? A peu près tout ! Reliez votre messagerie à votre logiciel de congés par exemple afin que les congés validés soient automatiquement renseignés dans les agendas des personnes ou faites correspondre vos contacts BlueMind a votre annuaire RH en temps réel.
A ce jour, plusieurs partenaires technologiques ont publié leurs travaux: Avencall pour la communication unifiée, VadeRetro pour une intégration à ses outils de sécurité, ou encore Numvision, Teclib ou Nextcloud sur des intégrations du partage de fichier volumineux.
Et si on ne veut pas ? L’iceberg qui a coulé Google+
Google+ fermera définitivement ses portes le 2 avril 2019 pour aller rejoindre le cimetière des services Google qui n’ont pas su convaincre. La tentative de réseau social de Google est née en 2011, 8 ans après Linkedin, 7 ans après Facebook, 5 ans après Twitter, soit avec des siècles de retard dans le monde accéléré du digital. Mais ce n’est pas ce démarrage tardif qui est en cause dans l’échec du produit. Après tout, les très populaires Snapchat et Instagram ont été lancés à la même période. Alors qu’est ce qui a coulé G+ et quel est le rapport avec les « Interface de Programmation applicative », les fameuses API ?
C’est un ancien salarié de Google qui nous donne la réponse. Steve Yegge a travaillé 12 ans chez le G de GAFA en tant que « Senior Staff Software Engineer » après avoir passé 6 ans chez Amazon. Il est devenu célèbre dans le microcosme des ingénieurs logiciels pour avoir diffusé par erreur un « blog rant » – une diatribe par blog (beaucoup moins sexy traduit en français) – très critique envers à la fois Google et Jeff Bezos, l’emblématique patron d’Amazon.
Steve expliquait dans cet article que, bien que Bezos soit un « infâme micro-manager » obsédé par le contrôle, il a réalisé avant tout le monde l’importance des plateformes. Dès 2002 il aurait ordonné à ses troupes de ne concevoir que des interfaces qui puissent être externalisables, réutilisables par des développeurs en dehors d’Amazon. Avec l’effritement des marges de son core business (la librairie en ligne), il devait trouver une autre source possible de revenus. Tout ce que Bezos avait entre les mains pour envisager un changement de business model, c’était un grand nombre d’ingénieurs et d’ordinateurs. Il lui fallait pouvoir monétiser cette compétence.
En quelques années sous l’effet Bezos, Amazon a changé totalement de culture, depuis la librairie en ligne vers une entreprise de service web : l’incontournable AWS. En 2018 le Cloud Amazon pesait 17,46 milliards de dollar, soit 10% du chiffre d’affaires du Groupe.
Si Bezos a su pivoter dès 2002, Google n’a pas du tout compris ce qu’était une plateforme. Ses dirigeants de 2011, Larry Page, Sergueï Brin et Eric Schmidt cherchaient à créer le produit parfait qui convienne à tout le monde. Pour cela ils ont déployé une philosophie de la simplicité extrême. Chrome par exemple est un produit à « configuration zéro », on ne peut même pas changer la taille des polices de caractère. Tant pis pour les malvoyants, Chrome est obstinément le même pour tout le monde.
Ce manque d’accessibilité est l’iceberg qui a fait couler le Titanic Google+. Ce réseau social était une réaction spontanée court termiste, basée sur l’idée erronée que Facebook a du succès parce que son produit est excellent. C’est faux. Facebook a du succès parce qu’il a construit toute une constellation de produits en permettant à d’autres personnes de faire le travail. Facebook est donc différent pour tout le monde. Certaines personnes passent tout leur temps sur un jeu, d’autres pour organiser des événements, d’autres sur messenger… Il y a des centaines, voire des milliers de façons de perdre du temps sur Facebook, chacun y trouve son compte.
Google+ s’est contenté de proposer un produit « one size fits all » qui ne proposait aucune API à son lancement. Le raisonnement plateforme est un raisonnement long terme qui implique de concevoir dès le départ une architecture permettant à n’importe qui de construire par-dessus et une philosophie qui valorise l’émergence et le développement d’un écosystème. En 2011 cela ne faisait pas partie de la culture de Google.
Pour conclure
Les API permettent à l’économie numérique hyper-connectée d’exister, rien que ça. Elles sont devenues des canaux indispensables à la valorisation de la data. Si aucun logiciel n’est une île les API sont tout ce qui permet de les relier entre eux.
Attention cependant à un point crucial : la sécurité des données. Qui peut y avoir accès ? Comment sont-elles utilisées ? Malgré le RGPD qui exige un consentement éclairé il n’est pas toujours simple de comprendre les implications du partage avant d’approuver. Cocher « J’accepte » en bas d’une liste de conditions ne permet pas de justifier de la compréhension de l’usage exact qui sera fait de vos données.
Saviez-vous par exemple que confier des données à un acteur américain, même si elles sont hébergées en Europe, autorise les autorités US à les consulter ? Dans un monde d’API, il est essentiel d’éduquer et de responsabiliser les consommateurs.
