L’ouverture des APIs représente un changement culturel très fort pour beaucoup d’entreprises, tant au niveau de l’humain que de la technologie. On parle d’ailleurs souvent de révolution digitale, mais Thierry Gaillet, Developer Advocate chez Orange, lui préfère le terme de renaissance digitale (voir le sujet sur API Days). Nous avons donc rencontré Thierry Gaillet pour approfondir ce sujet et répondre aux questions suivantes : quel est le rôle d’un developer advocate ? Quelle est la nouvelle place du développeur dans la transformation digitale ? Comment s’adapter au changement culturel induit par l’ouverture et les APIs ?

Thierry Gaillet a principalement deux casquettes. Son premier rôle est de promouvoir les différentes ressources destinées aux développeurs : les API, des kits, de la connectivité, de l’hébergement… tout ce qui permet aux développeurs, externes ou internes, de travailler avec Orange. Son second rôle, plus technique, consiste à faire en sorte que tout ce qui est produit soit compréhensible, utilisable, pertinent et attractif pour les différents développeurs. Cela passe par des Getting started, des exemples, des tutoriaux… Thierry s’occupe donc de cette rédaction technique et du support généraliste sur l’ensemble des ressources. Ces deux facettes se traduisent en ligne par deux sites : Orange Partner, la partie “marketing”, qui explique la démarche, et un site plus technique, Orange Developer, où on trouve toutes les ressources (API, SDK, kits de communication…) à disposition des développeurs.

Thierry Gaillet, Developer Advocate, Orange

Pourquoi la nécessité d’un developer advocate ?

Pour nous les développeurs sont des clients. C’est quelque chose de nouveau, et le rôle de mon équipe est de tenir compte de leurs spécificités en tant que clients. Ils ont besoin de pouvoir accéder à toutes les ressources à n’importe quel moment (c’est le self-service), d’être supportés très rapidement en cas de souci, et de comprendre par l’exemple. Les développeurs se méfient des discours marketing : ils veulent pouvoir tester par eux-mêmes en téléchargeant des outils, en instanciant ce dont nous faisons la promotion. C’est pourquoi nous essayons de les rencontrer durant des événements différents des traditionnels rendez-vous B to B ou B to C. Nous participons aux API Days et à de nombreux salons/conférences, nous organisons des challenges pour des équipes de développeurs, etc. En interne, nous essayons de faire en sorte que tous ceux qui conçoivent de nouveaux services pensent aux développeurs dès le début de la conception. Le rôle de l’advocate en interne, c’est d’assurer que tous incluent le développeur en tant que client potentiel dans le développement de nouveaux services. Cela doit devenir un réflexe.

C’est une nouvelle culture ?

Nous avons toujours été dans une culture d’innovation, avec beaucoup de nouveaux produits, mais il y a quelques années ces produits étaient trop centrés sur Orange. Nous essayons aujourd’hui d’ouvrir les écosystèmes, ce n’est possible qu’au travers de ressources bien découpées, et les API aident beaucoup à cela. Par exemple, l’API du Cloud Orange sortie il y a deux ans permet d’accueillir des partenaires et développeurs externes qui ajoutent de la valeur et améliorent l’expérience client. C’est un changement de culture, qui n’a de sens que si on montre l’exemple. Il faut montrer des réussites, des success stories avec des partenaires pour inspirer d’autres équipes, en faisant notre possible pour promouvoir les développeurs qui ont intégré nos API, par exemple.

Comment définissez-vous une API ?

C’est une interface entre plusieurs systèmes, entre plusieurs logiciels de différentes plateformes. Sur les interfaces homme-machine, on travaille beaucoup sur l’optimisation de l’expérience utilisateur; c’est la même chose avec les API, qui visent à améliorer l’interface entre deux machines ou deux logiciels. En automatisant cette liaison entre différents systèmes, on la rend beaucoup plus fiable. Cela permet aussi le découpage entre plusieurs modules logiciels, qui est très intéressant non seulement pour réutiliser différents modules, mais aussi pour le sourcing. Dans mon rôle d’advocate, j’explique que le fait d’avoir des API permet d’avoir des relations beaucoup plus factuelles, concrètes et pérennes avec les fournisseurs. Comme on découpe en différents modules, on se pose plus facilement la question : est-ce qu’on fait nous-mêmes, ou est-ce qu’on achète tel module? La normalisation des interfaces permet cela.

Pourquoi va-t-on de plus en plus vers les microservices ?

Les microservices apportent la modularité. Pour les équipes, cela permet de réutiliser ce qui a été fait. Le Cloud a évidemment favorisé l’essor des microservices, avec des instances beaucoup plus flexibles et dynamiquement configurable, pour faire travailler les microservices.

En quoi les API sont indispensables à l’automatisation et au développement applicatif ?

C’est une discipline de découpage fonctionnel, d’organisation à la fois interne et externe, et cela permet à un développeur de plus facilement qualifier, tester ses différents développements, faire de l’intégration continue sur ses briques de service à partir des API. Nous avons deux principes clé : l’agilité en amont du côté des développements de services, et le DevOps pour abattre les frontières traditionnelles entre le build et le run. Les API permettent justement d’automatiser beaucoup de choses à ce niveau. Nous avons des systèmes pour ordonnancer les différents développements logiciels, les tester unitairement et dans leur ensemble sur les différents environnements. Avec les API, on déclenche ces différentes phases de déploiement, et cela permet aussi de maintenir les scripts de test beaucoup plus facilement, et à faire évoluer. Les API servent justement à orchestrer, automatiser tout cela.

Quelle est la tendance aujourd’hui sur le marché des API? Les API self service ?

Les interfaces existent depuis très longtemps, mais des entreprises comme Google et Amazon ont popularisé le concept. Ce qui change aujourd’hui c’est une combinaison de plusieurs facteurs : tout d’abord l’adoption de REST, un style très simple d’échange et de commande d’informations entre différents systèmes, par opposition à SOAP. Cela a simplifié les échanges. Puis le self-service, qui évite d’avoir des workflows très compliqués avec des demandes d’autorisation et des formulaires pour ouvrir des flux, disposer de VM, etc. Le self service permet de découvrir, d’intégrer ou déployer plus facilement des applications et des services grâce aux API. Nous participons activement au TM Forum, qui rassemble différents acteurs de l’industrie en vue de standardiser des API pour l’IT au sens large du terme. Cela permet de partager les bonnes pratiques et d’avoir une visibilité sur qu’il est utile de faire pour l’IT, et de voir ce qui fonctionne. Il est important d’avoir cette réflexion sur la standardisation.
Autre facteur à citer : il y a de plus en plus d’API dites hypermédia (on y décrit de façon intégrée les possibilités et le fonctionnel de l’API au sein de l’API), et cela permet d’automatiser la découverte et l’intégration des différentes API. C’est tout cela qui a accéléré l’essor des API depuis ces dernières années : la standardisation croissante, et la simplification.

C’est un changement culturel très fort pour l’entreprise, comment l’accompagner au quotidien ?

Nous avons beaucoup formé les équipes depuis quelques années. Il y a 3 ans nous avons décidé de mettre l’accent sur l’acculturation, sur la formation des différentes équipes, mais pas uniquement sous l’angle technique. Nous voulions sensibiliser au bénéfice de cette nouvelle approche, et notamment le développement de l’éco-système. Nous avons ainsi lancé différents cycles de formation, aujourd’hui nous en animons toujours mais elles sont de moins en moins généralistes, et plus thématiques. On s’assure ainsi que les gens s’approprient le phénomène. Nous incitons également les chefs de produits à réfléchir aux API quand ils créent un produit. Est-ce qu’il est opportun d’ouvrir des API sur ce produit ? Est-ce qu’il faut utiliser des API tierces? Dans certains cas, décider de créer un produit qui est une API : le chef de produit ne crée plus une application traditionnelle pour accompagner son service, mais uniquement une API, à charge pour les partenaires de développer des produits autour. Créer un produit qui est une API, culturellement c’est très nouveau. Et le fait que les API soient self service contribue énormément à la propagation de leur travail. C’est un changement profond, qui accroît le rôle des développeurs, qui étend leur cercle d’influence, et ouvre les possibilités d’utilisation de leurs ressources.

Quel est l’enjeu de la formation en continu face à la rapidité d’évolution de l’IT ?

Nous adaptons en permanence les contenus (les formations API), qui deviennent plus thématiques, plus pointus et plus courts, afin de bien cibler les domaines d’intérêts. Notre équipe est associée à différentes conceptions de produits, ce qui permet de distiller au bon moment les différentes évolutions. Créer des événements, des challenges développeurs est une façon idéale de faire rencontrer à nos développeurs d’autres développeurs (start-up, partenaires, étudiants…), et cela permet de se confronter à l’évolution du marché, aux nouvelles plateformes ou langages et d’évoluer. Nous avons par ailleurs la chance d’avoir un footprint très diversifié avec les marchés MEA (Middle East Africa), dont l’Egypte et l’Afrique de l’Ouest. Culturellement, c’est enrichissant pour nos équipes car les développeurs y sont très jeunes, dynamiques et souvent entrepreneurs au sein d’écosystèmes de start-up. Cela nous permet de nous adapter très rapidement.

Pouvez-vous citer des exemples ?

Nous avons beaucoup de pays très innovants, où les start-up locales proposent des services très pertinents grâce aux API. Tous les secteurs sont concernés : agriculture, commerce, site de mise à relation, information… On est partis de l’USSD, mais maintenant en Afrique, la plupart des consommateurs ont des smartphones Android, et donc nos partenaires développent des applications natives, avec des API de paiement ou d’envoi de SMS. Beaucoup de sujets sont traités par l’envoi de SMS (applications B to B, mais aussi dans le domaine de la santé). Par exemple en Egypte, nous avons une application B to B qui contrôle la qualité des eaux des bassins de pisciculture, gérée par des API SMS. C’est un peu le début de l’IoT : nous ne sommes pas encore en réseau LoRa, mais de nombreux sites sont supervisés avec des API de type SMS. Ce sont des cas d’usage différents de ceux qu’on a en France, mais cela permet d’être au plus près des technologies et des moyens disponibles, et de pouvoir répondre au bon moment en intégrant de nouvelles technologies, ou en optimisant ce qui existe déjà.

Où en sommes-nous dans l’intégration de l’IoT dans les applications ?

Ce que les développeurs attendent, ce n’est pas juste une API pour collecter et récupérer des informations, mais de le faire de manière complètement flexible, en libre-service, avec des moyens simples, et de façon sécurisée. Il y a deux aspects à cette question : le device management d’une part, et les plateformes de traitement des données d’autre part. Par exemple, dans le cas d’usage de la détection des feux de fourrages, où les capteurs permettent de prédire les conditions d’inflammation, ce qui intéresse nos partenaires est d’avoir des API et SDK permettant d’embarquer une remontée d’informations pertinente. Cela signifie ne pas remonter la même information en permanence, faire l’analyse en local et ne remonter qu’une alerte. Cela demande un code minimal, et des API très efficaces… De l’autre côté (du côté des plateformes), les enjeux sont plutôt du côté du management des différents capteurs, et l’exploitation de ces données. Dans tous les cas, pour les données instanciées sur ce genre de cas de figure, nous nous efforçons, avec notre solution Datavenue, de proposer des interfaces vers les standards du marché (Elasticsearch pour le traitement et la recherche de donnée, Kibana pour la visualisation) avec des API très simples pour travailler sur ces différentes plateformes.

Comment est-ce que l’automatisation IT change les méthodes de travail ?

Personnellement, je constate que l’automatisation a fortement accéléré le time to market, mais surtout la réactivité sur les évolutions. Cela permet de publier et tester très régulièrement et de faire évoluer les produits et services bien plus rapidement qu’avant : le développeur peut rapidement inclure de nouvelles fonctions ou corriger des problèmes. Cette accélération est fondamentale. Au-delà du déploiement, quand on est dans le run, l’automatisation permet de reconfigurer dynamiquement des ressources, de ré-allouer des VMs, d’augmenter les bandes passantes, de basculer entre différents sites… Tout cela a accéléré le déploiement et la réactivité, mais également apporté plus de sérénité du côté de l’exploitation. En contrepartie, il faut énormément préparer en amont. Tout ce travail fait au préalable grâce à l’automatisation fait que les passages en production se font beaucoup plus sereinement.

Pour rester informé de l’actualité des API et de l’automatisation, inscrivez-vous à la newsletter du TIAD :