Nicolas Garnier

Nicolas Garnier

Vous souvenez-vous du temps où « le cloud » faisait simplement référence à un ensemble de serveurs externes voir à Internet en général ? Au cours des dernières années, ce terme a évolué pour donner naissance à de nouveaux modèles économiques comme les SaaS (Software-as-a-Service : le logiciel comme service).

Les SaaS sont particulièrement avantageuses pour l’utilisateur final. Elles permettent de rendre des services accessibles aux petites sociétés ou aux particuliers. Mais en tant que développeur, je trouve les API (interfaces de programmation) plus intéressantes : c’est grâce aux API que les SaaS réinventent des choses que nous connaissons depuis des décennies. Ainsi, en 2011, Marc Andreessen, entrepreneur et co-fondateur de Netscape, déclare dans son discours « Software is eating the world » : « Grâce à des coûts de lancement réduits et un marché de services en ligne en pleine expansion, nous vivons dans une économie globale et pour la première fois intégralement numérique. » J’adore l’expression « intégralement numérique » qui résume parfaitement la situation. Or, comment relier plus efficacement cette économique numérique ? Grâce aux API bien évidemment, qui par définition permettent à deux logiciels de se connecter et d’interagir entre eux.

« Les API sont les éléments de base de l’économie numérique », Laura Merling, VP Ecosystems and Solutions, AT&T. (source)

Ce qui est génial pour un développeur – et qui m’a donné envie d’apprendre la programmation par moi-même – c’est la possibilité de construire et hacker autant que possible. Aujourd’hui, nous vivons le meilleur moment pour programmer, développer, hacker, parce que plein d’autres personnes peuvent vous épauler. Vous trouverez très facilement toute l’assistance dont vous aurez besoin auprès de communautés en ligne et hors ligne : sur des forums spécialisés comme Stackoverflow, sur des événements hors ligne ou lors de hackathons, qu’il s’agisse d’un hackathon local ou d’un événement d’envergure mondiale comme Techcrunch Disrupt. En plus de l’aide que vous trouverez auprès de ces communautés, nous avons également de nombreux outils et ressources à notre disposition. En tant que développeur, si vous essayez d’imaginer un outil – quelque chose vous permettant d’atteindre facilement un objectif – les API vous viennent immédiatement à l’esprit. Les API les plus en vue proviennent généralement de services tels que Yo, Twilio ou Venmo. Pourquoi ?

studenthackers

Source: http://studenthackers.devpost.com/

Les API sont formidables car elles vous permettent de créer des fonctions complexes que vous auriez eu bien du mal à développer par vous-même, en raison de leur complexité, du temps que cela vous aurait pris, ou des deux à la fois. Les API vous permettent de déléguer les tâches moins essentielles pour votre société, tout en gardant le contrôle. Que vous cherchiez à intégrer une fonctionnalité d’email transactionnel pour communiquer avec vos utilisateurs ou leur offrir une expérience de recherche plus riche, opter pour la facilité avec une SaaS telle que Mailjet (pour les emails) ou Algolia (pour la recherche) sera toujours plus intelligent que d’essayer de réinventer la roue.

Il est fort probable qu’un produit SaaS permettant de réaliser exactement la tâche que vous avez en tête existe déjà. Elle ne nécessite donc qu’une simple intégration de votre côté. Ceci explique la transition de certaines SaaS, qui deviennent des API-en-tant-que-Service. Elles vous permettent d’intégrer le marché plus rapidement, avec un produit plus complet, tout en vous proposant un service solide, sûr, abordable et évolutif. Le tout grâce à quelques lignes de code seulement.

Les API sont les nouvelles références. Elles modifient notre façon de développer les logiciels en réduisant le volume de code que nous écrivons tout en enrichissant notre façon de développer. Il est souvent possible de réutiliser le modèle fourni par le service que l’on souhaite intégrer et de l’adapter pour répondre à nos besoins.

Et pourquoi ne pas penser différemment et innover ? Pourquoi ne pas pousser les choses plus loin et imaginer les API comme des éléments modulaires grâce auxquels il n’est plus nécessaire d’écrire de code ? Cela semble impossible. Mais cela existe déjà grâce aux connecteurs API comme Zapier ou IFTTT. Besoin de générer des tâches pour votre Calendrier Google ? Facile ! Besoin de faire une sauvegarde automatique de vos pièces jointes Gmail sur Google Drive ? Tout aussi simple !

Vous allez me dire : « OK, super. Mais cela se limite à des actions sur mesure qui ne nous font pas profiter pleinement du potentiel des API. Et ce n’est pas demain que les services tels que Twilio deviendront accessibles aux non-développeurs. » En fait, cela n’est pas tout à fait vrai. Avec l’aide de services tels que Blockspring, tout non développeur peut utiliser Twilio, extraire des données fournies par le gouvernement américain ou créer une datavisualisation. Je suis d’accord avec Blockspring sur le fait que les API peuvent également être utilisées par les utilisateurs finaux ; le fait qu’Andreessen Horowitz et SV Angel leur aient donné 3,4 millions de dollars tend à confirmer cela.

Ne vous méprenez pas. Je ne suis pas en train de dire que les développeurs vont devenir obsolètes ni que quiconque sera capable de décrocher un poste dans la programmation sans aucune formation. Du moins, pas tout de suite. Je veux dire que, bien que les logiciels soient de plus en plus complexes, ils restent toutefois accessibles grâce aux API. Et heureusement. Cela nous permet à nous, développeurs, de nous concentrer sur ce qui est le plus important au niveau du développement et de l’utilisation des API. Dans le cadre de l’entreprise, cela veut dire une chose: toute société de SaaS peut sérieusement envisager de proposer des API, mais si elle décide de faire cela, elle devrait s’assurer d’avoir une solide expérience en programmation. Dès qu’il s’agit d’API, les développeurs ont certaines attentes : documentation, assistance, communauté, respect des standards (REST). Ces points sont importants non seulement parce qu’ils satisferont les développeurs qui utiliseront vos APIs, mais également parce qu’ils sont nécessaires pour que l’API soit reconnue et productive.