Certaines DSI ont vu les clouds privés comme des étapes intermédiaires dans leur roadmap de modernisation : ils permettent d’expérimenter ces nouvelles technologies, sans prendre de risque sur la maîtrise ni sur la sécurité des données (dans le cadre d’une réglementation qui évolue), avant de franchir le pas du cloud public. Aller vers un cloud privé permettrait donc, en théorie, de limiter l’effort et les risques d’une migration. Pour les mettre en place, les DSI se tournent vers des éditeurs qui mettent en avant des clouds privés « clef en main » et immédiatement utilisables. Mais cette option a pour l’instant des difficultés à tenir ses promesses pour plusieurs raisons :

- Difficultés d’intégration avec l’écosystème historique (gestion des identités, des clefs de chiffrement, …) ;
- Couverture fonctionnelle moins riche que celle des clouds publics ;
- Rareté des compétences sur les logiciels star (OpenStack, OpenShift, …) ;
- ROI non atteint pour l’instant, avec la persistance de coûts fixes qui empêchent un réel modèle de coût de type pay-as-you-go.7

Les clouds privés condamnés à terme

Ces solutions de cloud privé ne sont donc pas matures actuellement. Et l’écart avec le cloud public risque de se creuser avec la difficulté qu’auront les fournisseurs à suivre le rythme d’amélioration des services qu’un pure player peut apporter à son offre (quelle DSI peut concurrencer Amazon Web Services et ses milliers de développeurs ?).

Les cloud publics ont été créés par les GAFA, initialement pour l’hébergement de leurs propres applications. Une des attentes est de pouvoir mettre en œuvre des applications à haut niveau de service (en particulier très fortement scalables)/ Par exemple : Netflix peut avoir besoin d’adapter son service pour ajouter des milliers d’utilisateurs d’un claquement de doigt, alors que le jeu en ligne Halo subit de fortes variations d’utilisation (selon le cycle de vie, très rapide, d’un jeu en ligne), ce qui a été une des raisons du développement d’Azure par Microsoft, qui en héberge les services.

Les cloud publics, des circuits de formule 1 sur lesquels les SI historiques sont limités à 50km/h

Pour atteindre ces niveaux de service, il ne suffit pas de disposer d’une infrastructure efficace. Il faut également que les applications elles-mêmes implémentent des architectures modernes : découplage entre l’application et l’infrastructure, architecture massivement distribuée (avec bases de données décentralisées), multi-tenancy, scalabilité horizontale, fonctionnement stateless, …

Les applications historiques, basées sur le modèle n-tiers classique, ne possèdent pas ces caractéristiques, qui relèvent des choix de conception fondamentaux de l’application, et ne sont pas en mesure de bénéficier de l’ensemble des apports techniques du cloud. Les adapter pour les rendre compatible nécessite une réecriture en profondeur, souvent plus couteuse qu’un nouveau développement. Pour cette raison, la quasi-totalité des logiciels en mode SaaS a été écrite spécialement pour le cloud, sans migration de logiciel historique (Microsoft par exemple a complètement réécrit son logiciel Office 365).

Musclez vos compétences en architectures modernes et redéveloppez

Les clouds privés manquent de maturité, les applications traditionnelles n’ont pas les besoins en niveau de service offerts par les clouds publics (le nombre d’utilisateurs de votre comptabilité ne va pas être multiplié par 10 du jour au lendemain…), et les transformer pour les rendre  compatibles cloud n’est pas rentable. En parallèle, les infrastructures traditionnelles vont coûter de plus en plus cher au fur et à mesure qu’une partie du patrimoine applicatif est recréé dans le cloud. Que faire ?

1. Formez vos développeurs aux architectures modernes et à l’utilisation des patterns de développement du cloud. Les nouvelles compétences à acquérir sont importantes, et le changement culturel n’est pas à négliger, mais il s’agit d’un passage obligé pour rester dans la course.

2. Prenez des solutions SaaS ou redéveloppez vos applications existantes directement dans le cloud et supprimez les versions historiques. Chercher à les adapter pour pouvoir les migrer n’a pas de sens : la migration pose des problèmes d’intégration, nécessite des refontes en profondeur, et risque d’aboutir à des déploiements d’applications qui ne bénéficient pas des avantages du cloud. Le plus simple : redévelopper, en se contentant du jeu de fonctionnalités strictement minimal, ou bien adopter les solutions SaaS adaptées à votre business.

3. L’adoption du cloud est difficile mais amène une répercussion bienvenue : l’occasion, (enfin !), d’inciter à une rationalisation salutaire du portefeuille applicatif de l’entreprise.