Petite leçon pour les fournisseurs d'API

Le mouvement a débuté avec Twitter, il s'est enflammé avec Reddit, et, selon toute probabilité, il devrait s'étendre : ces plates-formes drainant des millions d'utilisateurs prennent soudain conscience de la charge que représentent leurs API et cherchent en urgence des moyens d'en amortir le coût. Tous les fournisseurs peuvent apprendre de ces exemples.

Naturellement, le problème ne date pas d'hier mais il prend un relief particulier dans un contexte économique qui impose un surcroît de rigueur budgétaire. Pour les géants de l'internet communautaire, les infrastructures informatiques constituent un poste de dépenses colossal qui attire nécessairement l'attention du directeur financier. Et si, dans une certaine mesure (les dernières restrictions de Twitter en montrent aussi les limites), les ressources consommées par les applications web et mobile sont faciles à corréler avec des revenus, l'exercice est généralement plus délicat avec les API.

Ces interfaces, mises en place très tôt dans l'histoire de ces services, avaient pour objectif de démultiplier la portée de ces derniers en autorisant (gratuitement) leur intégration au sein de solutions tierces. Évidemment, avec le succès enregistré par la suite et la croissance exponentielle du nombre d'utilisateurs directs, le besoin initial a tendance à s'estomper, tandis que des usages dérivés, totalement imprévus à l'origine, commencent à prendre de l'ampleur… et que, globalement, la facture ne cesse de grimper.

Dans ces entreprises, on peut ainsi incriminer un défaut d'anticipation aux racines de leurs déboires, bien qu'il ne puisse pas entièrement leur être reproché, d'un point de vue stratégique. Or, parce qu'il guette tous les acteurs qui misent à grande échelle sur ces nouvelles formes de distribution – dont, bien sûr, les institutions financières, qui y voient un relais de croissance essentiel pour leur avenir –, le risque doit être appréhendé le plus en amont possible, dans une perspective extrêmement rationnelle.

Par rapport à des modèles classiques, les API ont ce pouvoir de susciter la naissance d'innovations – il s'agit même d'une de leurs raisons d'être – et donc d'être parfois exploitées à des fins qui n'avaient jamais été envisagées par leurs concepteurs. C'est cette caractéristique qu'il faut alors toujours garder en tête dans leur déploiement. Une réponse, d'autant plus simple à instaurer dans les environnements régulés, tels que la banque, où les utilisateurs sont filtrés à l'entrée, consisterait à interdire ces « écarts ».

En revanche, pour les producteurs un peu plus audacieux, qui savent que des opportunités inédites sont susceptibles d'émerger en laissant plus d'autonomie à leurs clients créatifs, c'est plutôt la préparation qu'il va falloir soigner. Il ne s'agit pas de prévoir toutes les éventualités, ce qui serait illusoire, mais de définir les scénarios à dérouler dans des circonstances exceptionnelles, notamment celles qui génèrent des sollicitations hors normes, que ce soit par leur cible ou en raison de leur fonctionnement.

Comme le montrent les réactions virulentes aux décisions de Twitter et Reddit, ce qui engendre frustrations et rancœurs parmi les adeptes de leurs API est le changement brutal, qui affecte jusqu'à leur survie. C'est le genre de choc qu'il faut absolument éviter afin de maintenir l'équilibre dans les relations entre les parties prenantes et garantir une proposition de valeur partagée équitablement. Établir par avance les règles du jeu en cas de mauvaise surprise représente un des moyens de l'amortir, à tout le moins.