Sacha Labourey, CloudBees: «Le PaaS permet aux développeurs de se rapprocher du business»

Comment vous est venue l’idée de créer CloudBees il y a trois ans?

J’ai quitté Red Hat en avril 2009 et, à cette époque, le cloud ne m’intéressait pas du tout ; je n’y voyais que des machines simplement installées ailleurs. J’ai eu le déclic lorsqu’en discutant avec un de mes collègues je me suis rendu compte que le concept allait bien au-delà, avec les notions de self-service, de pay-as-you-go, de partage des ressources, avec l’idée que de pouvoir acheter sans passer par un vendeur et de disposer du même service pour 1 ou 1000 utilisateurs. Je me suis rapidement dit que si le concept s’appliquait aux logiciels et aux serveurs, il pouvait tout aussi bien profiter aux développeurs. Le développement est trop souvent obnubilé par la notion de serveurs et se perd dans les détails. En fin de compte, l’entreprise demande deux choses au développement : apporter plus d’argent ou en dépenser moins. Dans ce sens, le cloud permet au développeur de se rapprocher du business. Ce qui l’intéresse c’est de produire du code, de le tester et de le déployer, pas de s’occuper de load balancer, de SSL ou de firewall. Ce d’autant plus que le cloud permet à chacun de profiter des best practices en la matière, qui deviennent ainsi disponibles et abordables pour les entreprises de toute taille. La vision au départ de la société était de rendre la liberté aux développeurs et de leur permettre de se concentrer sur l’essentiel. De leur donner un bouton «deploy», et qu’’après l’application tourne sur un serveur la nuit ou sur 300 au moment des pics, sans que, le programmeur n’ait pas en à s’en soucier. Sur la base de cette vision j’ai formalisé un business plan et engagé la première équipe. En avril 2010, on était lancés.

Quels types d’entreprises emploient votre plateforme?

Nous avons divers types de clients. Il y a d’abord ceux qui s’enregistrent en ligne et se mettent à consommer, sans que l’on ne sache ce qu’ils font. Nous avons aussi des clients plus gros de par leur usage du cloud (pas forcément de pas leur taille). La société Lose it! par exemple, qui propose une app pour perdre du poids, ne compte que quatre collaborateurs, mais elle enregistre des pics de 30 '000 transactions par minute. Ce sont des clients qui ne veulent plus nécessairement être facturés chaque mois. On s’assied autour d’une table, on évalue leurs besoins, et ils paient un montant annuel dont nous débitons leur consommation réelle tout au long de l’année. C’est un modèle qui permet de laisser de la liberté aux développeurs tout en ayant une meilleure planification des coûts.

Collaborez-vous aussi avec des prestataires de services?

Oui, de plus en plus de clients nous arrivent via des prestataires de services eux-mêmes utilisateurs. Ces sociétés ont l’avantage de connaître les nouveaux projets de leurs clients, qui sont les premiers à partir dans le cloud, et savent quels clients ne sont pas allergiques au cloud. Notre plateforme leur permet de dire à leurs clients: «Dès demain, nos consultants peuvent travailler à votre projet. Nous n’avons pas besoin de provisionner des serveurs ou de parler à votre IT. Et nous pouvons intégrer vos collaborateurs pour qu’ils aient accès à l’application au fur et à mesure de sa construction.» C’est une façon très flexible de travailler, sans compter qu’à la fin du projet, on peut transférer directement ce qui a été développé aux collaborateurs de l’entreprise: les tests, le code, l’environnement de production, etc. C’est un différentiateur important pour ces sociétés de développement. L’une d’elle a remporté récemment un contrat, alors qu’elle était en concurrence contre un très gros fournisseur indien, en mettant justement en avant cette agilité. Un dernier segment relativement récent est celui des hébergeurs traditionnels – opérateurs, équipementiers - qui développent peu à peu des offres d’infrastructure cloud, et qui souhaitent aussi proposer un PaaS pour répondre aux besoins de leurs clients. Nous leur proposons de faire tourner notre plateforme sur leur infrastructure, tandis que nous nous occupons de sa gestion, ce qui leur simplifie la tâche. L’intérêt pour nous, c’est que nous profitons de la crédibilité de ces gros fournisseurs et de la relation de confiance qu’ils ont avec les entreprises.

En quoi la plateforme CloudBees se différencie-t-elle de PaaS plus connues?

Nous nous attachons à proposer des services allant du développement au déploiement d’applications Java, ce que nous appelons le continous cloud deployment. Ce qui nous importe, c’est que les entreprises puissent rapidement traduire leurs idées d’application en code, qu’elles puissent faire de l’intégration continue, donc faire des tests en temps réel et s’assurer que le code est à tout moment releasable. Ensuite elles peuvent pousser ce code en production, déployer leurs applications et monter en charge. Ce qui nous différencie des PaaS comme Heroku ou Google App Engine, c’est le fait que nous ne nous intéressons pas qu’aunon seulement au déploiement, mais aussi au développement en amont. A l’instar d’autre plateformes, nous proposons également toute une gamme de services complémentaires - – bases de données SQL et NoSQL, monitoring, etc. – via notre écosystème de partenaires. Là aussi, les choses sont beaucoup plus simples qu’avec les logiciels traditionnels. Si un client veut par exemple l’offre de New Relic pour le monitoring de ses serveurs, il choisit simplement le service souhaité, nous injectons les agents New Relic dans ses containers et quelques minutes plus tard, il a un nouveau bouton pour monitorer ses applicatifs en production. Idem s’il a besoin d’une base de données ou de IaaS d’Amazon, le choix est ouvert. Il faut casser l’idée selon laquelle les PaaS seraient des environnements fermés. C’est un cliché lié à Force.com, la première plateforme à être apparue sur le marché, avec son propre langage, ses propres API et sa propre base de données. Cela ne correspond plus à la réalité. Quand on regarde CloudBees, le logiciel de gestion de versions c’est du Subversion ou du Git,  l’intégration continue c’est du Jenkins, le projet open source le plus connu dans le domaine dont le fondateur travaille d’ailleurs pour nous.

Comment voyez-vous évoluer vos deux activités, la plateforme de développement d’une part et l’hébergement d’applications de l’autre?

Aujourd’hui, la partie développement représente un tiers de notre chiffre d’affaires. C’est une activité stratégique et qui peut se suffire à elle-même. La croissance la plus forte va cependant venir de la partie déploiement, car elle ne dépend pas du nombre de développeurs, mais des charges qui sont appelées à exploser.

Les entreprises qui ont recours à votre plateforme pour le développement de leurs applications peuvent-elles les déployer sur d’autres PaaS?

Oui, et c’est un message auquel nous tenons. Nous avons établi des partenariats avec nos concurrents, comme CloudFoundry et Google App Engine, pour envoyer le message que le cloud n’est pas un environnement fermé. Nous proposons le bus complet, mais si un client souhaite par exemple employer GitHub ou son propre système de gestion des versions, libre à lui de le faire. Nous avons un intérêt commun avec les autres acteurs du cloud à ce que ce caractère ouvert soit compris. C’est une évolution analogue à ce qui s’est passé il y a quinze ans avec J2EE, qui a fait exploser le marché Java, quand bien même ce standard ouvert entraînait un risque pour chaque fournisseur, pris séparément.

Que pensez-vous du conflit entre Oracle et Google à propos de l’API Java?

C’est un débat extrêmement intéressant avec d’importantes répercussions sur la liberté des développeurs et plus généralement de l’IT. Les tribunaux américains doivent décider s’il est possible de réimplémenter une API. Oracle ne s’oppose naturellement pas à l’utilisation de son API, mais voudrait empêcher qu’une autre société puisse l’implémenter une seconde fois. Si je fais une analogie avec la météo, on pourrait imaginer que Météo Suisse développe une API permettant de lui adresser des requêtes avec la date et le lieu pour obtenir le temps qu’il fait en retour. Mettre un copyright sur cette API signifierait qu’un service météorologique concurrent ne pourrait pas proposer aux utilisateurs de lui adresser des questions de la même manière. C’est aberrant, la valeur n’est pas dans la façon dont l’appel est formulé, mais dans les données qui sont livrées en retour et dans les services additionnels. Cette idée de protéger les API avec un copyright est un combat d’arrière-garde livré par des géants de l’informatique, qui veulent garder leurs utilisateurs captifs. L’enjeu est important car il concerne toutes les API.

L’un des reproches qui est fait au cloud concerne justement le manque de standards…

Je ne pense pas que ce soit un problème dans la phase actuelle de forte innovation. De plus, si je prends le cas du SaaS, la situation n’est pas différente que celle que connaissent les utilisateurs avec les logiciels installés. Il n’y a pas de standard pour les CRM, ni pour les ERP. En ce qui concerne le IaaS et le PaaS, il n’y a pas non plus de véritable standard, mis à part des standards de facto qui émergent comme OpenStack ou les API d’Amazon. Là aussi, je n’y vois pas de problème dans la mesure où l’on trouve des outils qui apportent des couches d’abstraction. Sans compter que, dans le cas du PaaS, on retrouve des standards ouverts comme Java, MysSQL, PostgreSQL, Jenkins, Git, etc. 

Aujourd’hui, le PaaS semble intéresser surtout les sociétés technologiques très orientées web. Pensez-vous que les entreprises classiques vont elles aussi adopter ces plateformes?

Je pense que l’on va assister à la même évolution qu’avec le SaaS et le IaaS. Au début, Amazon Web Services semblait réservé aux start-up et aux environnements de test; aujourd’hui, c’est un business de la même taille que VMware. Les entreprises recourent de plus en plus aux diverses formes de cloud public et souvent à l’insu de leurs départements informatiques – ce qu’on appelle le shadow IT. Il en va de même chez nous, il est rare que ce soit le CIO qui s’adresse à nous, mais des équipes de développement et des architectes qui se plaignent du temps nécessaire à obtenir une machine à l’interne. Ou alors des responsables d’unités d’affaires, comme le marketing, qui doivent attendre des mois pour obtenir une application mobile. Ils s’adressent donc à des agences web et mobiles, mais après ils ne peuvent pas retourner vers leur IT pour le déploiement ou pour interfacer l’app avec les systèmes existants. C’est là que notre plateforme intervient. Pour donner un exemple, une grande banque française a récemment recouru à notre plateforme, et il ne leur a fallu que trois mois et demi entre l’idée et le déploiement de la première solution – le temps qu’il leur fallait d’habitude pour obtenir un serveur vierge. Le continous cloud deployment redéfinit d’autre part sur la façon même de faire évoluer les applications, de les développer, de les tester, de les déployer. Ces environnements permettent de créer de nouvelles fonctionnalités de façon incrémentale, par micro-itérations. On développe quelque chose, on le pousse en temps réel en production, on teste des alternatives en parallèle, on tue ce qui n’est pas bon, on garde ce qui fonctionne. Ce sont de nouveaux processus et une nouvelle mentalité; les notions d’exploration et de recherche deviennent plus importantes que le développement lui-même. Je pense que les entreprises et leurs départements IT vont peu à peu adopter cette nouvelle manière de faire, car cette évolution a lieu, avec ou sans eux.