Préface 1 1. L’évolution naturelle du système d’information

3

2. Mettre à disposition des ressources

4





2.1. Le standard REST 4 2.2. Une Web API REST, ou des Services ? 6

3. Une transition en 7 étapes

7

3.1. Partager une vision 7 3.2. S’organiser 8 3.3. Se former 8 3.4. Faciliter le développement 8 3.5. Identier les Ressources, dimensionner l’API 9 4. Les données : enjeu du back-end

11

4.2. Stockage 12 4.3. Recherche 12 4.4. Analytique 12 4.5. Prédiction 13 5. Un front-end par application

14

5.1. L’architecture de l’expérience utilisateur 5.2. Les langages du Front

14 15

6. Mettre à disposition sa plateforme

16

6.1. Des utilisateurs qui développent 16 6.2. L’authentification 17 6.3. Le contrôle d’accès entre domaines 17 6.4. Vendre une plateforme 17 18 6.4.1. Les coûts liés à l’infrastructure 6.4.2. Vendre un SAAS

18

7. developer.mycompany.com 19 Références 20

Préface Nous avons fait appel à des acteurs reconnus dans le domaine des Plateformes afin d’enrichir ce livre blanc de leur réflexion sur cette évolution structurelle du logiciel. Un immense merci à ces intervenants. Et si on était enfin entré dans l’ère de l’économie de la connaissance, théorisée par Peter Drucker ? De plus en plus, ce qui régit le monde aujourd’hui, est la connaissance de l’information et son exploitation : connaître les habitudes de ses clients pour les fidéliser et leur vendre davantage, connaître la météo pour prévoir la demande et optimiser ses stocks, anticiper les soucis de fonctionnement sur ses machines ou serveurs de production… Cette “data-driven economy”, ou économie portée par la donnée, est l’un des aspects les plus intéressants de la transformation numérique qui s’opère dans nos sociétés et nos entreprises. Elle met en lumière les effets de levier, voire les changements de modèles économiques, qui peuvent advenir grâce à la maîtrise de la donnée. L’information peut provenir de l’entreprise, mais aussi de la combinaison de sources externes et internes. Or les systèmes d’information actuels ne sont pas, dans leur immense majorité, prévus pour cela. Conçus pour informatiser et optimiser les processus de l’entreprise, ils sont à la peine dès lors qu’il faut partager de la donnée. Les architectures orientées services (SOA) ont donné une certaine agilité aux systèmes d’information, mais toujours avec une orientation processus, alors que les API se centrent sur la donnée. L’élégance des API vient donc de ce qu’elles sont à la fois plus simples techniquement, et plus ouvertes sur le monde extérieur. Elles sont le biais par lequel les entreprises peuvent se transformer, et s’immiscer dans le cercle de ces acteurs qui font l’économie numérique aujourd’hui. Les API résolvent le principal obstacle technique à cette transformation. Ne reste plus aux entreprises qu’à résoudre le problème le plus délicat : imaginer de nouveaux services !

Olivier Rafal, Principal consultant PAC, groupe CXP “Le logiciel dévore le monde” disait Marc Andreesen en 2011. Les plateformes, basées sur l’exposition de fonctionnalités de plus en plus évoluées sous forme d’APIs, dans un marché biface (développeurs / utilisateurs), sont le moteur caché de ces disruptions qui touchent toutes les industries. En 2002, Hal Varian, un des théoriciens des plateformes, a rejoint Google comme Chief Economist, et en 2014, Jean Tirole, qui a énormément contribué à la théorie des “marchés bifaces”, a reçu le prix Nobel d’économie. Le socle technique mis en place dans les 5 dernièrezs années, basé sur le mobile et le cloud, permet la création de plateformes et de business models révolutionnant des secteurs existants, ou créant de nouveaux marchés : réservation de logement chez des particuliers (Airbnb), mise en relation client/conducteur (Uber), outils de recherche

1

gratuits financés par la publicité (Google),... Les plateformes sont une ruée vers l’or, demarrée comme en 1849, à San Francisco. Les décideurs d’entreprises existantes qui n’ont pas encore été disruptées par ce phénomène doivent se poser une question : y-a-t-il une plateforme potentielle cachée dans mon business? Comment cela pourrait-il affecter mon business model? Le livre blanc d’Aline Paponaud, tel un manuel du chercheur d’or, donne aux décideurs une idée des composants techniques qui permettent cette révolution, et des questions à se poser pour appliquer ces technologies pour transformer votre business model en devenant un fournisseur de plateforme.

Patrick Chanezon, Docker De la même façon que la logistique est au cœur des échanges commerciaux traditionnels, les APIs sont aujourd’hui le moteur des échanges numériques. La clé de la transformation du business passe donc par le déploiement et la gestion de ce qui est une véritable chaîne logistique numérique. Grâce aux APIs et aux plateformes applicatives, les entreprises sont à même de s’interconnecter, d’offrir de nouveaux modes d’accès à leurs services et de pleinement valoriser leurs actifs numériques que sont les données.

Jérôme Louvel, CEO, Restlet

2

1. L’évolution naturelle du système d’information Dans les entreprises de technologie (startups, éditeurs) comme dans toute entreprise ayant un système d’information à gérer (grands comptes, services, finance, industrie...) la question du tout connecté se pose. Les smartphones ont fait leur apparition dans tous les secteurs et tous les domaines. Ils sont suivis par d’autres objets. Donner un sens à son système d’information sur ces supports est un vecteur d’innovation, d’attractivité, de productivité. Tout système d’information a besoin de faire appel à des services afin d’accéder à des données spécifiques. Les services dans un système d’information sont réalisés sur mesure, pour une utilisation bien précise. Dans leur conception, c’est l’appelant (l’interface utilisateur) qui détermine ce dont il a besoin. Lorsqu’une entreprise entre dans le monde du Web, elle peut voir l’aspect services d’une manière différente. Afin de donner toute la flexibilité aux applications qui l’accèdent, le métier est interprêté comme un ensemble de ressources. Une interface utilisateur peut y accéder mais pas uniquement : il faudra peut-être rendre ces ressources disponibles à plusieurs dispositifs et applications, pas encore connues ni dimensionnées. Utiliser une plateforme implique plus d’éléments que se mettre à utiliser une technologie ou un outil. Il s’agit d’une transformation complète qui peut avoir des impacts à tous les niveaux. Nous allons voir dans ce document quelles sont ces ressources qui exposent le métier, en quoi consistent les étapes d’une transition vers une plateforme, et comment le produit et ses applications pourront évoluer.

Figure 1 - Système d’information, verticalisé

Figure 2 - Une plateforme et son Application Program Interface (API)

3

2. Mettre à disposition des ressources Une Application Program Interface (API) est un ensemble de points d’accès à des ressources au travers d’une interface. Les ressources et l’intelligence permettant de les mettre à disposition constituent le back-end. Les applications en mesure d’accéder à l’interface constituent le frontend.

Figure 3 Plusieurs front-end peuvent se connecter à une API, qui expose les fonctionnalités métier du back-end

Utiliser des services Web, c’est restreindre la valeur ajoutée de l’entreprise à des applications développées spécifiquement. Dans le cas d’une API standard, le nombre et la forme des applications ayant accès à cette valeur sont encore inconnus et en augmentation dans le temps : de nouveaux objets connectés et de nouveaux usages émergent chaque jour. De ce fait, l’objectif de l’API est d’être aussi simple que possible, compréhensible par le plus grand nombre, mettant à disposition des ressources directement utilisables de manière durable. Un standard est massivement admis pour créer des API simples et efficaces : Representational State Transfer (REST).

2.1. Le standard REST REST est un style d’architecture réseau pour les systèmes hypermédia distribués [1]. L’avantage est qu’en utilisant cette architecture pour son API Web l’interface est uniforme, il est possible de monter en charge, d’effectuer le déploiement par composants indépendants. Si l’objectif est de créer une API sur un système existant, les fonctionnalités historiques peuvent être encapsulées dans des composants [2].

4

La plateforme peut avoir une structure complexe, l’API REST se résumera toujours par des accès uniformes à des ressources identifiées. La complexité de la mise à disposition des données prêtes à l’emploi s’implémente dans la plateforme. Traditionnellement, ce qui correspond le mieux à une implémentation de REST sur le Web est le protocole Hypertext Transfer Protocol (HTTP) [3], qui définit la manière d’accéder à des pages Web sur Internet. En effet, une ressource se définit par un nom et différentes actions permettant de la manipuler. Ces actions sont définies par des verbes (créer, modifier, rechercher. . . ). Une fois obtenue, la ressource nous informe de l’état de l’action : Ressource créée, modifiée, OK. Ces verbes et ces codes retour existent dans le protocole HTTP, qui est utilisable en l’état pour cela. De plus, HTTP est un standard accepté et implémenté partout sur l’internet. Ainsi, REST peut être mis en oeuvre au moyen d’HTTP pour accéder aux ressources. Chaque ressource aura sa propre adresse Unied Resource Locator (URL), et chaque action sera derrière un verbe HTTP, par exemple GET, POST. Les erreurs seront directement retournées en tant que code retour HTTP. Pour échanger les ressources entre le front-end et le back-end il est nécessaire de définir un type d’objet standard, le plus répandu est JavaScript Object Notation (JSON).

Figure 4 Le front-end communique avec l’API au moyen de HTTP et des objets JSON

Enfin, en récupérant une ressource, il est nécessaire d’obtenir suffisamment d’informations pour savoir ce qu’il est possible de faire avec elle. C’est la notion d’hypermédia : la ressource contient toute l’information nécessaire pour l’utiliser, dont des liens vers d’autres URL de l’API. En lisant une ressource, je sais exactement ce que je peux en faire. [4]

5

2.2. Une Web API REST, ou des Services ? Un problème facile à voir dans une architecture REST est que, par rapport à une architecture orientée services (SOA), c’est à dire l’utilisation de services spécifiques, l’implémentation de l’API peut être complexe et inutilement exhaustive. En effet, l’intérêt d’utiliser une interface uniforme est de permettre à un maximum d’objets et applications d’accéder aux ressources mises à disposition. L’interface doit être la même pour tous. Par conséquent, certaines des ressources à disposition ne seront pas utiles à toutes les applications utilisant l’API. Utiliser une API REST est destiné à répondre aux problématiques du Web, multi-support, multi-connecté, et non d’exposer un service à une interface utilisateur particulière.

Figure 5 Le Webservice et l’API ne s’accèdent pas de la même manière, et donc, n’ont pas la même utilisation

6

3. Une transition en 7 étapes Lorsqu’une entreprise a pour projet de diversifier ses applications et mettre en place une architecture Front-API-Back (FAB), il n’est pas toujours nécessaire d’effacer tout ce qui a été fait sur le produit et de recommencer. Cependant, cette transition va bien au-delà du produit. Les données changent de main, se centralisent, se manipulent autrement. Par conséquent, les personnes changent de rôle. Il peut s’agir d’un bouleversement des équipes, et d’une remise en question de certains concepts et idées fondamentaux, pas toujours comprise par tous. La transition se fait sur trois principaux axes : technique, humain et business. L’axe humain est aussi important que les autres. Pas de bonne transition technologique si les personnes concernées ne sont pas préparées ! L’équipe va naturellement passer par les étapes suivantes :

3.1. Partager une vision C’est la vision de l’entreprise et les questions de futur, d’objectifs et de stratégie métier qui entrent en jeu pour faire le choix d’aller vers une plateforme. La transition technologique donne l’occasion de soulever ces points avec toute l’équipe. Que faire ? Comment le vendre ? S’il est facile de vérifier que REST a été choisi par de nombreuses pointures du Web (Google, Facebook, Twitter. . . ), cela ne s’applique pas partout. A chaque métier et niveau d’exigences sa solution. L’objectif se situe dans le monde multi-device, avec des enjeux d’interconnexions, de mobile-first, et d’encapsulation. L’entreprise sort du monde logiciel packagé : elle entre dans celui d’une plateforme extensible, sur laquelle il est aussi possible de développer. C’est à cela que répond REST.

Figure 6 Tous les objets peuvent être connectés à une API REST

7

3.2. S’organiser S’organiser implique d’avoir une bonne connaissance de l’équipe en charge de la transition : Qui sont les personnes qui la composent ? Quelles sont les compétences de chacun ? Une fois cette connaissance acquise, il sera plus facile de répartir les rôles. Ces rôles vont naturellement devoir se combiner avec l’architecture FAB : des développeurs vont s’identifier en tant que plutôt front d’autres seront plutôt back, et tous auront la responsabilité de l’API et de sa composition. Plus qu’une simple réorganisation de l’équipe de développement, cette disposition structure aussi l’entreprise et son socle de connaissance commun. Lors d’un nouveau développement, il est important d’identifier ce qui doit rester dans l’entreprise et ce qui peut être réalisé à l’extérieur.

3.3. Se former La notion d’API existe depuis longtemps, et peut être implémentée quel que soit le langage ou la complexité. Dessiner les contours d’une API correspond à une tâche de conception du système dans sa globalité. Avant de se lancer, il est nécessaire de connaître les différentes architectures client-serveur possibles et de comprendre en quoi l’architecture REST adresse les enjeux du Web moderne. Côté back, il faudra être capable d’utiliser des frameworks et outils pour manipuler les données, et de s’adapter aux différentes contraintes de l’environnement. Côté front, maîtriser à la fois les langages et les technologies Web, en pleine expansion, mais aussi savoir concevoir, structurer l’application. Dans les deux cas, il est primordial de savoir écrire du code de qualité, testé, durable.

3.4. Faciliter le développement L’efficacité de l’équipe de développement est plus que jamais un aspect primordial pour la réussite de l’entreprise. Un bon développeur n’est pas seulement capable d’absorber une charge de travail importante et d’être très réactif, il est préoccupé par la réussite de l’entreprise et sait se concentrer sur les tâches pour lesquelles il créera le plus de valeur. Figure 7 Permettre au développeur de se concentrer sur l’essentiel lui permettra d’exprimer toute sa créativité [5]

8

Un bon outillage, l’automatisation d’un maximum de tâches répétitives, une bonne organisation en amont, du temps alloué à la réduction de la dette technique et au refactoring permettra de tirer le meilleur parti de l’expérience et des compétences de l’équipe de développement.

3.5. Identier les Ressources, dimensionner l’API Sur le plan technique, la première étape est de savoir quelles sont les données métier à mettre à disposition dans le système. Trouver le niveau d’abstraction. Peut-être, commencer par redéfinir quel est le métier principal de l’entreprise, qu’est-ce que l’entreprise apporte à ses clients. C’est cela qui va permettre de constituer l’ensemble des ressources. Une fois que les ressources sont créées, il faut définir quels sont les liens entre elles. Par exemple, si je suis un organisateur d’événements, je vais avoir des ressources de type utilisateur, ville, événement, météo. Puis-je accéder aux événements pour chaque ville ? Les transitions permettent de définir quels sont les liens entre les données, ce qui est intéressant de mettre à disposition, et dans quel ordre. La valeur ajoutée du produit se trouve ici.

Figure 8 Identier les ressources et leurs relations est la première étape du dimensionnement de l’API

Arrivé à cette étape, il est possible de documenter exactement les points d’accès de l’API. La documentation, c’est en fait le standard HTTP, le contenu de l’URL, et le contenu des liens de chaque ressource. Pour faciliter le développement front-end il est au moins nécessaire de lister les différentes ressources auxquelles il est possible d’accéder, la structure des objets JSON à échanger, le type d’authentification.

9

3.6. Isoler le back-end Si aujourd’hui l’architecture en place est un client lourd, un client-serveur Web ou un ensemble de services, le back-end est une notion qui existe déjà. Le travail est de déterminer à quel niveau il se situe. Cela peut être au niveau le plus proche de la base de données, ou alors il existe un ensemble d’objets prêts à être envoyés sur le réseau et directement utilisables par des services. En premier lieu, il va falloir séparer vraiment le client et le serveur. Sur le plan fonctionnel, le back-end doit correspondre aux fonctionnalités qui différencient l’entreprise par rapport à une autre, à sa valeur ajoutée. Mais les questions à se poser sont aussi sur le plan technique : qu’est ce qui doit absolument être exécuté sur le serveur ? Qu’est-ce qui peut être mutualisé ? Et de la même manière, qu’est-ce qui peut changer selon les dispositifs ?

3.7. Concevoir les Front-End Un bon produit sera celui qui donne le meilleur accès aux innovations de la plateforme dans un contexte donné. Le front-end n’est pas seulement à considérer comme la couche présentation de l’application, ni même uniquement l’expérience utilisateur. Dans une architecture de type REST, le front-end ne se limite pas, comme dans le cas d’une architecture SOA, à mettre en forme et afficher. Le front-end a pour responsabilité d’appeler différentes API dans le bon ordre, avec les bons paramètres, pour construire ses objets et services. Il nécessite donc sa propre phase d’architecture et de conception, et un soin constant à limiter la dette technique, à penser long-terme. Comme c’est lui qui définit et pilote les applications, le front-end embarque une partie des règles métier. Lors de la conception du back-end, de nouvelles tâches, qui étaient historiquement confiées au serveur, deviennent désormais les siennes. Son importance est démultipliée.

10

4. Les données : enjeu du back-end Maintenant qu’il est bien dissocié du client et des vues, Le back-end peut se concentrer sur l’idée principale qu’il représente : manipuler et valoriser des données. Les données sont la colonne vertébrale de l’entreprise. Elles se présentent sous plusieurs formes et sont accessibles de plusieurs manières. Manipuler des données ne se résume pas uniquement à écrire des requêtes SQL. Les notions d’accès, de stockage, de recherche, d’analytique ou encore de prédiction, représentent les réels enjeux de la manipulation de données aujourd’hui.

Figure 9 Autour des données, différentes manipulations sont possibles

4.1. Accès Il s’agit de la fonction principale des données : pouvoir les lire, les écrire, les modifier, les supprimer. Cela se fait assez naturellement. Mais la question de la manière d’accéder à ces données se pose : est-ce que l’opération de lecture se passe comme celle d’écriture ? En termes de performances, de trafic réseau, peut-être pas. Différentes architectures existent pour organiser l’accès aux données, dont Command Query Responsibility Segregation (CQRS) qui part de ce principe : L’opération d’écriture ne se passe pas de la même manière que l’opération de lecture : séparons-les. Partant de cet exemple parmi d’autres, la notion d’accès peut aller beaucoup plus loin que d’écrire des requêtes SQL…

11

4.2. Stockage Comment le faire, et à quel endroit ? En fonction du besoin, la question peut être d’utiliser une base de données relationnelle ou NoSQL. Stocker des fichiers directement dans le système, ou utiliser un système de stockage cloud. Mettre des machines virtuelles chez un hébergeur, ou éclater l’infrastructure en une plateforme dans le cloud. Les possibilités sont infinies. Et le tout peut être combiné en fonction des besoins.

4.3. Recherche La quantité et la diversité des informations manipulées, et la volonté de simplifier les expériences utilisateurs, ont conduit au développement d’outils de recherche fonctionnant avec des indexes et des algorithmes. Apache Lucene est l’un des outils les plus répandus. Il permet de faire de la recherche par texte en utilisant des notions mathématiques, tels que par exemple la distance de Levenshtein. Cet outil libre, assisté de frameworks en facilitant l’utilisation tel que Elasticsearch ou Solr, met une recherche performante et intelligente à la portée de tous les développements back-end, du plus simple au plus complexe.

4.4. Analytique L’analyse et la consolidation des données de manière lisible et exploitable doit aujourd’hui aller plus loin que la Business Intelligence. En effet, dans certaines situations, il n’est pas possible d’attendre la construction d’une librairie de rapports, ni de construire des structures complexes afin d’accéder à du NoSQL, des fichiers, des données indexées… Un bon exemple d’analyse de données performante en temps réel est Google BigQuery. BigQuery permet d’exécuter un calcul consolidant des centaines de milliers voir des millions d’informations en quasi temps réel. Pour analyser un flux de Tweets ou exploiter directement des données renvoyées par des dizaines de milliers de smartphones. Les données métier ne sont plus les seules données d’un produit : les logs, l’historique, le comportement de ce produit sont aussi des données exploitables. Par exemple, un outil comme Logstash, utilisé avec Kibana et Elasticsearch, permet le stockage, l’indexation et l’analytique sur des logs de manière immédiate.

12

4.5. Prédiction Les données emmagasinées dans la durée peuvent être utilisées pour prédire un comportement ou un état à venir. C’est l’utilité du Machine Learning, discipline définissant des algorithmes qui reconnaissent des motifs dans les données, identifient des courbes de tendance, et finalement utilisent ces informations pour améliorer une expérience utilisateur, la performance d’un algorithme ou l’adaptativité au changement d’une application.

13

5. Un front-end par application Une multitude d’applications peuvent se connecter à notre API. Cela va du simple site Web de gestion au plugin d’une application pour montre connectée, en passant par un ensemble d’applications mobiles. Avec une plateforme, le but de l’entreprise n’est pas d’avoir la maîtrise des applications clientes, mais d’offrir la meilleure expérience utilisateur quel que soit l’usage qui en est fait.

5.1. L’architecture de l’expérience utilisateur Dans une architecture FAB, développer un front-end consiste à la fois à intégrer des contenus dans du HTML / CSS, à présenter des données avant l’affichage, ainsi qu’à gérer les appels aux API. Le périmètre à gérer est beaucoup plus étendu que dans une simple application monolithique qui n’exploite pas d’API. Il peut y avoir plusieurs API appelées, des zones réutilisables, des interdépendances...

Figure 10 Le front-end s’architecture comme le reste. Cet exemple est une sorte de « trois couches » côté front. Il est courant d’y retrouver des patterns tels que MVC (Model View Controller)

Une tâche de conception en amont est nécessaire pour déterminer, selon le cas et l’usage, comment l’application va être construite, de l’interface graphique aux appels unitaires à l’API.

14

5.2. Les langages du Front Les langages et technologies front-end sont en pleine explosion. De nombreux outils ont pour but de faciliter la conception et la réalisation d’applications Web dynamiques, ergonomiques et structurées, capables de faire appel aux API de manière très simple. Le langage de prédilection de tout développeur Front, après HTML et CSS, est Javascript. Associé à ce langage, différents frameworks tels que BackboneJS, AngularJS, EmberJS, KnockoutJS, ..., facilitent et structurent le développement d’applications riches côté client. Le monde des WebComponents, représenté par l’outil Polymer, propose des composants Web prêts à l’emploi. Enfin des langages construits spécifiquement pour le Web, tel que Dart ou Typescript rendent les développements encore plus efficaces et puissants.

15

6. Mettre à disposition sa plateforme 6.1. Des utilisateurs qui développent Les clients ne sont pas forcément des utilisateurs finaux. Ce sont aussi des agences, des intégrateurs, des développeurs d’applications qui ont besoin d’accéder à tout ou partie du métier mis à disposition. Plus les clients savent développer, plus le fournisseur de plateforme peut se concentrer sur les aspects données, performance et optimisation côté back-end, ainsi que sur la structure et la facilité d’utilisation de la plateforme.

Figure 11 Les utilisateurs, les clients, sont aujourd’hui mieux habitués à la technologie

Une des manières de mettre son produit à disposition des développeurs dans une architecture de type SOA est le Software Development Kit (SDK). Un SDK a pour but d’encapsuler les appels aux services, afin de faciliter les développements et l’intégration de la solution. Si l’API est RESTful, elle est standard et tout le monde peut la comprendre. Mais dans le cadre du développement d’un front-end capable de dialoguer avec l’API, le SDK devient une couche front-end intermédiaire facilitant ces accès.

16

6.2. L’authentification Authentifier les clients qui viennent se connecter à l’API peut se faire par différents moyens, dont par exemple une clé d’API ou un login/mot de passe à envoyer avec chaque requête. Ce système manque de sécurité : le mot de passe doit être stocké en clair, il peut facilement être cassé, et une fois qu’un accès a été donné à un client il est difficile de le contrôler. Un système plus avancé, utilisant l’authentification par jeton et la signature de chaque requête, est préférable. Et pour aller encore plus loin, le protocole ouvert OAuth propose une couche d’autorisation sécurisée et orchestre la séquence d’authentification. Utiliser ce standard permet aussi de partager des identifiants entre différentes plateformes avec un OpenID.

6.3. Le contrôle d’accès entre domaines Sur le Web, les navigateurs implémentent un contrôle d’accès, pour des raisons de sécurité, qui contrôle les requêtes cross-domain, c’est à dire qui sortent d’un domaine HTTP (par exemple http://monsite.fr) vers un autre, distant. Cela implique que si un front-end Web, destiné à être exécuté un navigateur, utilise Javascript et une requête HTTP de type XMLHttpRequest pour accéder à un autre domaine (par exemple, un appel ajax vers une API distante), un contrôle d’accès Cross-origin resource sharing (CORS) est effectué par le navigateur, et l’API distante doit autoriser les requêtes provenant de ce domaine.

6.4. Vendre une plateforme Que ce soit sur une infrastructure dédiée, ou sur un cloud, le client voit cette API comme une Platform As A Service (PAAS). Pour l’éditeur, qui devient fournisseur de plateforme, le modèle business de monétisation d’un logiciel en est bouleversé. Il faut trouver un système pour rentabiliser la plateforme et ses applications .

Figure 12 Ne plus vendre un logiciel packagé et sa notice, mais une plateforme, un service, un accès…

17

6.4.1. Les coûts liés à l’infrastructure Le coût de l’infrastructure détermine celui de la plateforme. La première chose qui peut venir à l’esprit est la quantité de données qu’un client ou une application peut requérir. Il y a aussi le trafic réseau, le nombre de connexions. La monétisation de l’API suivra logiquement un modèle pay per use, lié au coût. Afin de pouvoir au mieux définir le prix, il est également nécessaire de mesurer l’utilisation de la plateforme. Cela permet aussi de comprendre quelles sont les fonctionnalités les plus utilisées, d’identifier les endroits où il y aura besoin de plus de performance.

6.4.2. Vendre un SAAS Dans le cas du SAAS (Software As A Service), ce n’est pas la plateforme seule qui est monétisée, mais son accès via un ensemble de front-ends développés par le fournisseur lui-même. Citons par exemple Office 365, Flickr ou les applications Google. Dans ce cas, le coût n’est pas le seul élément dont dépend le prix, il y a aussi un fort facteur marketing et expérience utilisateur.

18

7. developer.mycompany.com

Figure 13 Une API, accessible dans le monde entier

Google, Facebook, Twitter, ne sont que quelques exemples d’entreprise donnant accès au grand public à leurs API via un site spécial pour les développeurs. Ainsi, l’utilisation de ces plateformes devient massive, intégrée à tout type d’application. Si le choix a été fait d’être multi-support, dans un monde hyperconnecté, plus l’API est ouverte, disponible et utilisée, mieux c’est : chaque consommateur de l’API est un nouveau vecteur de consommation du produit. Une récente publication de the Harvard Business Review déclare que salesforce.com génère 50% de son revenu grâce aux APIs, expedia.com en génère 90%, et eBay 60%. Des applications externes utilisant des APIs amènent plus d’utilisateurs aux entreprises qui les fournissent, et donc plus de revenus. L’API peut devenir le terreau des projets les plus innovants. Le site http://www.programmableweb.com répertorie celles qui sont disponibles sur le Web, il en compte aujourd’hui plus de 12000. La transition du système PLAYOFFSPLAYOFFSPLAYOFFS d’information vers une plateforme Web à base d’API doit se faire dès maintenant. Et cette évolution sera faite pour longtemps. Le back-end doit être concentré sur la durabilité et le long-terme en gardant toujours une dette technique réduite, en concentrant un maximum de temps aux tests et au refactoring. Le front-end doit être conçu de manière à ce que si l’utilisation et le style de l’application changent et que les applications se multiplient, un socle commun puisse être préservé, et optimisé. Dans tous les cas, c’est bien plus que d’une transition technique qu’il s’agit : c’est un investissement stratégique dans la croissance et la compétitivité des entreprises.

19

Références [1] R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, 2000 [2] M. Fowler, Richardson Maturity Model, http://martinfowler.com/articles/richardsonMaturityModel.html, 2010 [3] R. Fielding, UC Irvine et al., Hypertext Transfer Protocol – HTTP/1.1, https://www. ietf.org/rfc/rfc2616.txt, 1999 [4] J. Barthe, Introduction à HATEOAS, http://jeremybarthe.com/slides/humantalks-hateoas/#, 2013 [5] A. Hunt, D. Thomas, The Pragmatic Programmer, Addison Wesley, 1999 [6] R. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008 [7] D. Betts, J. Dominguez, Exploring CQRS and Event Sourcing, Microsoft, 2012 [8] A. Osmani, Patterns for Large-Scale JavaScript Application Architecture, http://addyosmani.com/largescalejavascript, 2011 [9] D. Hardt, The OAuth 2.0 Authorization Framework, http://tools.ietf.org/html/ rfc6749 [10] Mozilla Contributors, HTTP access control (CORS), https://developer.mozilla. org/fr/docs/HTTP/Access_control_CORS, 2015 [11] A. Dsouza, J. Kabbedijk et al., Software-as-a-service: Implications for business and technology in product software companies, PACIS 2012 [12] Proceedings Pacific Asia Conference on Information, 2012 D. Durkee, Why cloud computing will never be free, Communications of the ACM, v.53 n.5, 2010 [13] L. Murphy, SAAS Pricing Strategy: The 10x Rule, http://sixteenventures.com/ saas-pricing-strategy, 2012 [14] B. Iyer, M. Subramaniam, The Strategic Value of APIs, https://hbr.org/2015/01/ the-strategic-value-of-apis, 2015

20

Rejoignez nous sur join.sfeir.com

Chez Sfeir, chaque vendredi après-midi, c’est Playoffs ! Il s’agit d’un processus de recrutement éxigeant au cours duquel le candidat fera connaissance avec au moins trois Sfeiriens différents autour de tests techniques. Sont alors évalués son savoir-être, son savoir-faire, son leadership, son potentiel et son empathie client. Plus que de simples entretiens nous faisons des Playoffs de véritables échanges entre candidats et Sfeiriens à l’issue desquels nous sommes convaincus de vouloir travailler ensemble.

Organisés par pôles, les Sfeiriens se retrouvent au moins une fois par mois lors des Soirées Techniques pour échanger autour d’un thème qui leur tient à cœur. Les Sfeiriens qui le souhaitent peuvent y partager leurs dernières expériences ou recherches avec leurs collègues. C’est aussi une opportunité pour préparer leur présentation prévue pour un prochain meetup ou même une conférence ! Et c’est avec de bons bagels que la soirée continue pour échanger sur les sujets abordés ou pour simplement se retrouver au babyfoot ou au ping-pong.

Afin de favoriser l’essor des technologies et de leurs communautés, nous vous proposons d’accueillir vos meetups dans nos locaux et de financer le repas de la soirée. Pour cela, nous mettons à votre disposition notre salle Meetup ; elle est équipée pour accueillir dans les meilleurs conditions jusqu’à 70 personnes. Pour en profiter, il vous suffit de vous mettre en contact avec un Sfeirien qui veillera à ce que tout se déroule parfaitement.

22

+ de 300

N’hésitez pas à nous contacter :

collaborateurs

26M€

de chiffre d’affaire

@sfeir

[email protected] [email protected] [email protected] 01 41 38 52 00

Suivez-nous !

23

Paris • Strasbourg • Luxembourg • Lille