Prédictions 2015

Prédictions Cloud 2015Le début d’une nouvelle année est toujours la période des bonnes résolutions et du bilan.

Non, ne craignez rien, je ne vais pas vous annoncer le plan des grandes manœuvres 2015 pour Qualilogy. D’abord, il n’y a pas de plan, et ensuite je fais partie des personnes dont 90% des bonnes résolutions échouent, et je ne crois pas que les rendre publiques pourra améliorer ce faible taux de réussite.

Simplement, cela fait déjà un bon moment  (1) que je réfléchis aux impacts que le Cloud pourrait avoir en matière de management des applications et de bonnes pratiques de programmation.

Or, il m’est arrivé plusieurs fois en 2014 d’aborder ce sujet avec différents interlocuteurs pour ne rencontrer qu’une absence totale de réaction, pour ne pas dire une indifférence polie : de collègues et amis consultants en matière de qualité et qui n’ont jamais rencontré de clients qui se préoccupaient d’applications dans le Cloud, ou de décideurs informatiques qui considèrent manifestement le Cloud comme une nouvelle technologie à la mode, au même titre que le Big Data, les apps mobile ou l’Internet of Things, et vont écouter, blasés, les sempiternelles considérations sur la nécessité urgente d’inclure celles-ci dans leur stratégie informatique au risque de ne pouvoir répondre aux évolutions toujours plus rapides du business.

La « capacité de réaction aux demandes du marché » et « l’amélioration de la performance des services IT » sont les arguments les plus souvent rencontrés en guise d’introduction de toute présentation, et donc les clichés les plus ressassés et usés qui soient.

A l’heure d’imaginer ce qui nous attend en cette nouvelle année, verra-t-on en 2015 plus d’applications dans le Cloud ?

Où est le Cloud ?

Les étapes du cycle de vie d’un nouveau marché sont bien connues : dans une phase initiale, les précurseurs techno-enthousiastes sont les premiers ‘early adopters’ avant que les bénéfices de cette nouvelle technologie soient démontrés et que le marché entre dans une deuxième phase d’adoption, sinon massive, du moins plus large, en tout cas de croissance.

Je crois que nous sommes probablement entre ces deux phases. D’ailleurs il suffit de voir la maturité des offres des géants comme Amazon, Microsoft, Google, etc. mais également l’existence d’acteurs locaux, comme l’a démontré l’expérience du Cloud souverain. Et je note aussi l’absence des IBM, HP et autres CA, qu’on pourrait juger significative d’une rupture de marché, d’une nouvelle vague technologique. Bon, je ne me fait pas souci pour eux : ils sont plus riches que moi et ont déjà maintes fois prouvé leur capacité à prendre les trains en marche. Ou/et à licencier afin de faire monter leur action en bourse, traditionnelle manière de rassurer les investisseurs, le Board, et même les clients.

Mais il existe un fossé à franchir pour passer à la deuxième phase : les avantages pour les early adopters ne sont pas forcément significatifs pour les décideurs informatiques, s’ils ne répondent pas à un problème ou ne présentent pas de bénéfices suffisants.

Qui est dans le Cloud ?

Une startup qui démarre sans avoir son application mobile dans le Cloud, aujourd’hui, cela n’existe tout simplement pas.

Et si vous décidez de démarrer votre petite entreprise, bien sûr que vous avez d’autres priorités que d’embaucher un directeur informatique et une équipe de programmeurs : vous choisissez un programme de compta, de gestion des commandes, et votre progiciel de paie dans le Cloud. Et si vous parvenez à vous développez, un Salesforce parce qu’un peu de prévisions commerciales et surtout un peu de visibilité sur ce que fait réellement votre force de vente, vous savez bien que c’est toujours mieux que naviguer à vue, et accessoirement, vos nuits seront plus tranquilles.

Mais attention : c’est là que commencent les problèmes. Passe encore que votre progiciel soit indisponible parfois, ou avec une performance complètement dégueulasse : vous pouvez toujours saisir les commandes avec un peu de retard, ou expliquer à vos employés que leur chèque arrivera le 1er ou le 2 du mois, à cause de problèmes informatiques. De temps en temps.

Mais ne donnez jamais une seule occasion à vos commerciaux de vous dire que « ça ne marche pas ». Vous croyez vraiment qu’ils vont vous laissez dans les mains un outil pour les surveiller, sans rechigner et sans tirer moyen de la moindre opportunité de se plaindre du temps qu’ils perdent à utiliser ce foutu machin ? Accessoirement, c’est là où vous allez découvrir que nous autres informaticiens pouvons nous révéler utiles, afin d’expliquer à vos utilisateurs que « si, ça marche », lorsqu’on se souvient de son password, sinon « ça bloque » après quelques tentatives infructueuses.

Pression sur le CIO

Si j’étais le CIO de ma compagnie d’assurances, je me ferais un peu de souci. Cela fait déjà longtemps que j’ai succombé aux appels de LinkedIn, de Twitter et autres Facebooks pour avoir leur app sur mon smartphone. En même temps, c’est vrai que dans le métro, cela aide à prendre l’air important de quelqu’un très occupé, pas comme ma voisine accro à Candy machin chose au point d’en oublier de couper le son.

Par contre, j’ai noté que ma banque m’assaille de mails pour downloader leur app sur mon mobile. Sans trop de succès : c’est déjà assez pénible d’être dans le métro sans en plus me faire encore plus mal à y réviser mon compte en banque, ou à passer mon temps à supprimer leurs messages pour leur dernier emprunt à taux miraculeusement préférentiel et remboursable en 50 ans.

Mais j’ai aussi noté que ma compagnie d’assurances n’a toujours pas franchi ce pas. Je ne suis pas certain que les membres du Board de cette compagnie soient sur Facebook, mais je suis certain qu’ils ont comme moi une banque, et qu’ils vont comme moi noter que notre chère compagnie d’assurances, dont ils sont les membres les plus éminents, n’est pas ‘digitale’. Ce qui risque de mettre un peu de pression sur le CIO de cette compagnie.

Pression sur le cycle de vie applicatif

Prédire la multiplication des apps ou l’adaptation des sites internet existants vers une version mobile (ou les deux) n’est pas vraiment une révélation. En quoi cela peut-il aider le Cloud à franchir le fossé entre la phase des visionnaires techno-avancés et la phase d’adoption massive par des acteurs plus traditionnels ?

Parce que ces nouvelles applications impliquent une nouvelle stratégie marketing, appelée « inbound marketing » (2), qui consiste à attirer le client vers son site à travers sa promotion sur les réseaux sociaux, l’inscription à une newsletter, des blogs, podcasts et vidéos qui améliorent le classement sur les sites de recherche (Search Engine Optimization ou SEO).

Qui dit SEO dit « analytics », c’est-à-dire l’étude de toutes les statistiques de fréquentation et de comportement des visiteurs sur votre site, par des personnes adeptes du marketing « inbound » qui analysent ces données, sous la houlette d’un Chief Digital Officer, afin d’identifier les meilleures méthodes pour attirer et transformer les visiteurs en prospects et clients. Ils vont par exemple vérifier qu’un bouton en haut et à droite de la page web, ou en bas en fin de blog, ou à travers un popup, donne de meilleurs résultats en termes d’inscriptions à une newsletter ou de downloads d’un PDF.

Et donc ils vont bien sûr demander régulièrement aux développeurs qui maintiennent cette app ou ce site internet, d’implémenter ces modifications en fonction de leurs analyses. Et évidemment, pas dans un mois, plutôt pour la fin de la semaine. Ce qui va mettre plus de pression sur les cycles de vie de ces applications et les équipes de projet, encourager l’adoption de pratiques Agile et de Continuous Integration, mais également de Continuous Delivery.

Si vous êtes capables de livrer une nouvelle version chaque semaine, mais que vous ne parvenez pas à la déployer correctement, vous avez un problème. Le classique problème du DevOps, où votre application doit fonctionner sur des serveurs d’âge et de technologies différentes, avec des systèmes d’exploitation différents, en version différentes, des Java différents, un Tomcat ou un Websphere différent, etc. Et l’ingénieur système qui ne parvient pas à déployer sur tel serveur appelle le développeur qui répond que cela marche sur sa machine, et donc que le problème n’est pas chez lui.

Surtout que votre app peut se comporter différemment sur certains mobiles ou tablettes. La gestion des onglets dans une page n’est pas la même avec iOS et Android, et certains smartphones ont des débits super-lents qui interdisent certaines pratiques de programmation. Donc vous pouvez vous retrouver à gérer, pour une même app, des projets distincts avec un langage spécifique à différentes catégories de mobiles, ce qui accroît encore plus la complexité et la pression sur les équipes de dev et la prod.

Il existe différentes manières de résoudre ces problèmes (la « containerization » par exemple), mais le Cloud constitue une solution qui présente nombre d’avantages puisque vous déployez votre application dans une infrastructure unique et centralisée, et non plus dispersée sur de multiples serveurs. Et vous vous évitez des maux de tête dans la gestion des problèmes de performance et d’indisponibilité, puisque le Cloud prend en compte les contraintes d’élasticité et la capacité à répondre automatiquement aux variations de fréquentations de votre site. Votre CIO n’a pas envie de voir le CEO l’appeler parce qu’il a voulu tester sur son smartphone cette nouvelle campagne marketing et qu’il attend plus de 10 secondes pour accéder à chaque page.

Transformation des applications existantes

Si votre app se base sur un nouveau développement avec un langage spécifique aux applications mobiles (Objective-C, Android, etc.), vous aurez plus de facilité à prendre en compte les APIs particulières de chaque fournisseur de Cloud, et nécessaires au bon comportement de votre application (APIs REST, gestion sécurisée du login dans chaque Cloud, etc.). Je pense que l’on verra apparaître progressivement des nouvelles ‘programming best practices’ spécifiques au Cloud.

Si vous app se base sur une application existante, il va falloir très certainement effectuer les adaptations nécessaires. Vous ne pouvez pas simplement pousser une application dans le Cloud et espérer tirer parti de ses bénéfices en matière de scalabilité, sans un refactoring. Voire un re-engineering parce qu’il peut s’avérer nécessaire d’architecturer différemment votre code, ou de le porter dans un nouveau langage.

Certaines applications vont devoir s’adapter également. Je me suis acheté une enceinte Bluetooth récemment et le vendeur m’a proposé une assurance contre le dommage et le vol au prétexte qu’il s’agissait d’un matériel portable qui pouvait s’abîmer ou se voler plus facilement (j’ai refusé puisque je dispose déjà d’une assurance qui couvre ces risques). De la même manière qu’on va vous proposer une assurance médicale et rapatriement lorsque vous achetez un billet d’avion sur Internet. Ma banque me suggère aussi régulièrement l’adhésion à une mutuelle privée (le service public de la santé ne couvre que le minimum en Espagne).

Vous croyez que mon vendeur de matériel électronique ou votre compagnie aérienne ou ma banque se sont lancés dans les contrats d’assurance ? Non, c’est une compagnie d’assurances qui leur proposent des applications «  en marque blanche », c’est-à-dire configurables et personnalisables par chaque client pour les intégrer dans leur propre site Internet et/ou leur app. Ce qui suppose encore plus de pression sur les équipes de développement qui maintiennent ces applications et doivent les adapter très fréquemment aux desideratas de ces clients ou aux particularités de leurs sites, et donc de pression sur les équipes de production qui doivent les déployer. Arguments supplémentaires en faveur du Cloud.

Je pense que l’on va également voir de plus en plus de sociétés de service intégrer le Cloud dans leur offre. Certaines utilisent déjà le Cloud en mode PaaS pour leurs développements et la maintenance des applications outsourcées, donc la continuation logique sera de proposer à leurs clients d’effectuer leurs livraisons dans le Cloud, manière de démontrer qu’elles maîtrisent cette technologie, et d’intégrer celle-ci lors des renouvellements de leurs contrats. Bénéfices pour le client et avantage compétitif pour ces SSII.

Applications Mainframe Cobol

Qu’en est-il des applications Mainframe Cobol ? Sont-elles candidates à un portage dans le Cloud ?

Si je reprends l’exemple de ma compagnie d’assurances, l’époque où ses employés travaillaient directement avec un terminal 3270 est révolue (enfin, en principe). Quand je me rends dans mon agence bancaire, je vois bien que la personne qui me reçoit consulte mon compte à travers une application Windows.

Cependant, ces applications ‘front-end’ ne sont que l’interface cliente d’applications Cobol en ‘back-end’. Un transfert bancaire, une modification de votre contrat d’assurances ou la souscription à un nouveau service sera enregistré à travers cette interface, et effectué par une transaction mainframe. Puis, des programmes batch vont travailler pendant la nuit afin de répercuter cette opération vers d’autres applications, notamment comptables.

Si, comme nous l’avons vu, ces applications ‘interface’ se multiplient en plusieurs versions de site Web mobile et apps, la pression va également rebondir sur les équipes mainframe. Une modification du front-end ne va pas toujours nécessiter une évolution correspondante du back-end, mais lorsque cela arrivera, le développeur Cobol ne va pas pouvoir répondre « dans 3 semaines ». Il va lui aussi devoir s’adapter et adopter les best practices Agile et s’insérer dans le cycle d’intégration continue, voire de déploiement en production.

Je pense que cela va inciter à réfléchir à la question de porter ces applications Cobol dans le Cloud, au moins celles qui sont en ‘back-end’ des apps ou sites Web mobile. Or aujourd’hui je ne connais pas de solution qui permette de pousser des applications Cobol telles quelles dans le Cloud. A mon avis, on devrait voir plus de projets de reengineering d’applications Legacy et une migration préalable de celles-ci vers une technologie compatible Cloud, comme Java. Je sais, ce type de projet peut s’avérer lourd et compliqué. Mais si on considère que le coût du MIPS mainframe (entre 3,000$ et 5,000$ minimum, dont la majeure partie sur le software) est largement supérieur au coût du Cloud, le transfert du Cobol vers une autre technologie présente un ROI très élevé.

2015, l’année du Cloud pour les développeurs ?

Je ne veux pas tomber dans les prédictions qui font de chaque année, l’année du Cloud. Le Cloud est déjà bien installé pour tout ce qui est IaaS, et de plus en plus pour le PaaS. En définitive, ce qui peut inciter à une phase d’adoption plus massive pour pousser des applications en mode SaaS dans le Cloud :

  • Pression sur le CIO pour une stratégie digitale avec plus d’apps et de versions mobiles de leurs sites internet, plus d’analytics et un Chief Digital Officer comme stakeholder de ces applications. A noter que les informaticiens constituent de bons candidats à ce poste.
  • Pression sur les équipes de développement et la production, pour livrer et déployer plus fréquemment plus de versions différentes d’applications. Généralisation des pratiques Agile, d’Intégration/Déploiement Continu, de DevOps, mais celles-ci ne peuvent pas tout résoudre. Le Cloud permet d’aller plus loin.
  • Pression pour transformer les applications existantes, Legacy ou non, afin de les pousser dans le Cloud, et pour migrer les applications Cobol en interface du ‘front-end’ vers du Java ou autre technologie compatible Cloud. Multiplication des SSII qui intègrent le Cloud dans leur offre.

Et enfin, je pense qu’on devrait commencer à voir apparaître des bonnes pratiques de programmation et des métriques spécifiques au Cloud. Mais là je ne sais pas si c’est une prédiction ou un vœu pieux.

                                          

[1] Voir La qualité dans le Cloud, Elasticité des applications 1 et 2.

[2] Par opposition au « outbound marketing » qui consiste à aller vers le client à l’aide des campagnes d’emails, d’appels téléphoniques, de publicité, etc.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *