L’essor du cloud computing a changé à jamais le visage des technologies de l’information. Avant le cloud, l’accès à l’infrastructure nécessitait un investissement initial en capital et des délais de plusieurs mois. Après le lancement du cloud computing, l’infrastructure était disponible en quelques minutes seulement, pour un coût mesuré en centimes par heure.
À son tour, cette révolution de l’infrastructure a donné naissance au Web 2.0, un ensemble d’entreprises nées dans le cloud. Ces innovateurs ont lancé de nouvelles offres qui substituaient des technologies numériques bon marché à des processus analogiques poussifs, provoquant de profondes perturbations chez de grandes entreprises au riche passé. De nouveaux verbes sont apparus pour caractériser cette disruption : Ubered. Ou Airbnbed. Ou encore Netflixed.
Bien sûr, les acteurs historiques de ces secteurs n’étaient pas disposés à les céder aux nouveaux venus. Ils ont donc suivi les disrupteurs dans le cloud. Mais leurs efforts ont connu, pour la plupart, une issue surprenante : ils n’ont pas porté leurs fruits.
Les entreprises se sont succédé à lancer de vastes initiatives cloud, sans constater la moindre accélération de leurs processus informatiques ni parvenir à avancer à la vitesse des disrupteurs.
Il s’avère que l’adoption du cloud ne suffit pas pour avancer à la vitesse du Web 2.0. Une infrastructure rapide doit aller de pair avec des pratiques logicielles rapides. Autrement dit, le parcours logiciel jusqu’à la mise en production doit fonctionner à la vitesse des ressources d’infrastructure sous-jacentes.
Les entreprises du Web 2.0 ont généralement construit des chaînes d’outils hautement personnalisées afin de réduire au minimum le temps nécessaire pour faire passer une modification logicielle du clavier à la production. L’usage intensif de composants open source reliés par des composants d’intégration propres à l’entreprise pour créer une solution DIY sur mesure est une constante du Web 2.0.
En réaction, de nombreuses entreprises ont lancé leurs propres initiatives DIY. Mais beaucoup trop d’entre elles n’aboutissent jamais à une solution opérationnelle, ce qui freine les entreprises dans leurs efforts pour avancer à la vitesse du Web 2.0. La question évidente est donc la suivante : pourquoi ? Qu’est-ce qui empêche tant d’entreprises de créer avec succès leur propre parcours jusqu’à la mise en production ?
J’ai observé bon nombre de ces initiatives DIY avortées et je souhaite partager les problèmes récurrents que j’ai constatés, tout en proposant des pistes pour aider les professionnels de la tech à créer un parcours rationalisé jusqu’à la mise en production.
Voir aussi : Principaux fournisseurs et entreprises de services cloud
Attention aux inconvénients du cloud DIY
Quels problèmes ai-je vus apparaître dans les grandes entreprises qui tentent de créer un cloud computing parcours jusqu’à la mise en production ?
Voici quelques-unes des raisons pour lesquelles ces initiatives DIY n’aboutissent pas :
Sélection des composants
Il existe une vertigineuse multitude de composants open source disponibles pour répondre aux différentes étapes du parcours jusqu’à la mise en production, si bien que la simple sélection d’un ensemble pertinent à intégrer à la chaîne d’outils constitue déjà une tâche majeure.
Le paysage de la CNCF, qui ressemble à un tableau de contrôle illisible, rend déjà difficile le simple fait de répertorier les options correspondant aux différentes parties de la chaîne d’outils, sans même parler de les évaluer et d’en sélectionner une bonne. Bien sûr, une autre possibilité consiste à laisser un employé en choisir une en fonction de sa réputation ou parce qu’une de ses connaissances l’a utilisée, mais cela semble au mieux hasardeux et au pire très risqué.
Coûts d’intégration sous-estimés
Certains composants intègrent des connecteurs pour des composants complémentaires, ce qui donne l’impression que la tâche d’intégration sera simple.
Cependant, tous les composants susceptibles d’être sélectionnés ne disposent pas d’intégrations avec les autres composants qu’une organisation pourrait choisir. Et, dans tous les cas, mon expérience montre que supposer que les intégrations intégrées fonctionneront correctement dans tous les cas d’usage et pourront opérer à grande échelle relève d’une confiance mal placée. En réalité, ce qui ressemble à un simple logiciel de « colle » d’intégration demande généralement beaucoup plus de travail que prévu, avec davantage de main-d’œuvre et des calendriers plus longs que ce qui avait été budgété au départ.
Oublier de couvrir l’ensemble du cycle de vie applicatif
Les initiatives de chaînes d’outils DIY démarrent souvent dans une équipe qui souhaite « résoudre son propre problème ». L’équipe entreprend d’automatiser ses tâches, de réduire les coûts opérationnels et d’accélérer le débit. C’est très bien, dans la mesure où cela va.
Malheureusement, il n’y a souvent aucun travail pour relier un workflow automatisé aux équipes en amont et en aval qui contribuent elles aussi au parcours jusqu’à la mise en production. Le transfert d’une tâche à une autre finit donc par se faire manuellement. Très souvent, l’automatisation d’une tâche isolée n’accélère pas l’ensemble du processus, car la majeure partie du temps du parcours jusqu’à la mise en production est passée entre les tâches, et non au sein des tâches.
Pénurie de personnel
Le revers de la sous-estimation de la difficulté du travail et de la complexité de l’automatisation de bout en bout est qu’un nombre insuffisant de collaborateurs est affecté au projet. Ces projets commencent souvent comme des initiatives clandestines, mobilisant à temps partiel quelques personnes d’une équipe ; cela permet d’éviter les frais généraux liés à la création d’un projet « officiel », comme la budgétisation, la planification, etc.
À mesure que la véritable portée du projet se précise, lorsque les autres équipes participant au parcours jusqu’à la mise en production présentent leurs exigences, les capacités en personnel de l’initiative clandestine sont rapidement dépassées. Les organisations doivent alors faire face à des choix peu réjouissants : abandonner le projet — et rester ainsi prisonnières d’un long processus manuel — ou lui consacrer de véritables budgets, ce qui nécessite une documentation et une mise en concurrence budgétaire.
Détournement des talents
Chaque organisation technologique ne dispose que d’un nombre limité d’ingénieurs talentueux. Si ces ingénieurs sont affectés à l’amélioration d’un processus interne, ils ne contribuent pas aux objectifs plus larges de leur entreprise mère.
Très peu d’entreprises sont prêtes à décider consciemment de consacrer des talents précieux et rares à un projet interne, aussi pertinent soit-il. Le projet DIY interne manque donc de talents, ce qui entraîne des retards ou des fonctionnalités incomplètes.
Retard dans la création de valeur
Le début de cet article soulignait la principale motivation des entreprises pour adopter des pratiques cloud natives : répondre aux bouleversements du marché provoqués par des concurrents nés dans le cloud.
Se lancer dans un projet DIY coûteux et complexe, qui sera miné par des déficits de talents et de budget, est la recette idéale pour livrer en retard et retarder la création de valeur. Si une chaîne d’outils logiciels développée en interne procure une certaine fierté, il faut savoir que mettre 24 à 36 mois à la rendre opérationnelle empêche l’entreprise mère de répondre à une concurrence dangereuse dans l’immédiat.
Voir aussi : Principales entreprises de transformation numérique
Guide du cloud DIY : bien faire les choses
« Ah ! », pensez-vous. Je veux éviter tous ces problèmes en créant le parcours automatisé de mon entreprise jusqu’à la mise en production. Mais comment faire ?
Lorsque je discute avec de grandes entreprises qui se lancent dans un projet DIY visant à créer un parcours vers une production cloud, voici les facteurs auxquels, selon moi, elles doivent veiller dans leur plan :
Comprendre votre pourquoi
Pour quelle raison l’entreprise a-t-elle besoin d’un système développé en interne ? Trop souvent, un projet DIY sert à quelqu’un à se constituer un fief, ce qui répond à ses intérêts, mais pas nécessairement à ceux de l’entreprise.
Comprenez donc ce que vous cherchez à accomplir en créant votre propre parcours jusqu’à la mise en production. Et n’imaginez pas que vous êtes un flocon de neige, unique au monde, qui nécessite une solution conçue spécialement pour vous — ou, à tout le moins, comprenez pourquoi vous êtes un flocon de neige afin de mieux évaluer l’importance d’un système développé en interne.
La plupart des entreprises, si elles sont honnêtes avec elles-mêmes, peuvent très bien se contenter d’une solution générique pour leur parcours jusqu’à la mise en production.
Intégrer tous les silos
Comme indiqué précédemment, beaucoup trop de projets DIY commencent au sein d’une seule équipe et ne répondent jamais aux besoins des autres parties prenantes du cycle de vie applicatif. Le vieux cliché veut qu’il faille mesurer deux fois et scier une fois ; autrement dit, planifier avant d’exécuter.
Avant de commencer la construction, assurez-vous que la solution aide chaque équipe qui touche au code sur le chemin de la mise en production à automatiser sa partie du processus — ou que le système obtenu puisse facilement intégrer les propres systèmes automatisés de ces autres équipes.
Sinon, au mieux, vous courez le risque de ne constater aucune amélioration de la vitesse de vos pratiques logicielles ; au pire, vous vous exposez à des conflits organisationnels lorsque ces autres équipes dressent des obstacles et refusent de participer.
Prévoir la maintenance continue
Sachez que vous construisez une plateforme, et que toute plateforme nécessite un travail continu pour étendre ses fonctionnalités, intégrer les corrections de bugs et améliorer son fonctionnement ainsi que sa résilience. Il s’agit d’un engagement budgétaire à long terme qu’il est important de prévoir. Sinon, vous vous retrouvez avec un système obsolète, peu satisfaisant pour les utilisateurs et qui survit tant bien que mal.
Créer un budget
J’espère que cet article a montré à quel point un système important qui accompagne votre parcours jusqu’à la mise en production constitue un engagement à long terme, et non quelque chose que quelques collaborateurs à temps partiel peuvent bricoler.
Lorsque vous créez votre plan de projet cloud, affectez des effectifs et prévoyez les coûts de personnel. Calculez également l’infrastructure dont vous aurez besoin pour exploiter une plateforme ; cela signifie qu’il vous faudra des environnements de développement, de préproduction et de production afin de permettre les améliorations de la plateforme et les tests avant mise en production.
Calculer le coût d’opportunité de vos ressources
Les collaborateurs que vous affectez à la construction de votre plateforme pourraient travailler sur d’autres sujets. Lesquels ? Quelle valeur pourriez-vous créer en les affectant à d’autres tâches ?
Toute organisation technologique dispose d’une liste inépuisable de tâches à accomplir : certaines offriraient-elles davantage de bénéfices à l’organisation ou à l’entreprise dans son ensemble ?
Analyser l’achat par rapport au développement interne
Comme je l’ai indiqué au début de cet article, la plupart des entreprises du Web 2.0 construisent leurs propres systèmes personnalisés de parcours jusqu’à la mise en production. Cela a parfaitement du sens sur le plan financier, car ce sont avant tout des entreprises numériques qui font transiter de très gros volumes de modifications de code et de mises en production par leurs systèmes.
Répartir le coût des ressources techniques et de l’infrastructure sur un tel volume rend un système développé en interne financièrement pertinent pour elles. La question est donc la suivante : est-ce financièrement pertinent pour vous ?
Il existe des produits commerciaux qui fournissent des fonctionnalités couvrant l’ensemble du parcours jusqu’à la mise en production. Vous pouvez comparer vos chiffres de budget et de coût d’opportunité au prix d’une solution commerciale afin de déterminer quelle approche est adaptée à votre situation.
Voir aussi : Les gagnants et les perdants du cloud native
À retenir : créer des solutions cloud DIY
Quels sont les points les plus importants à retenir de cet article ?
- La maîtrise du logiciel est un préalable essentiel à l’ère du cloud computing. L’application de pratiques de développement logiciel héritées à une infrastructure cloud n’entraîne aucune hausse de la vélocité applicative. Pire encore, elle peut coûter plus cher que de laisser une application existante inchangée. Pour être compétitif dans l’économie de demain, vous devez disposer d’une solide expertise logicielle.
- Vous devez mettre en place dès que possible un système moderne de parcours jusqu’à la mise en production. Les bouleversements sectoriels illustrés par les entreprises du Web 2.0 ne montrent aucun signe d’essoufflement. Ne pas commencer immédiatement vous expose au risque d’être laissé sur le bord du chemin.
- Réfléchissez soigneusement à votre approche. Le DIY est tentant. Il semble facile de démarrer et peu coûteux grâce à l’utilisation de composants open source. Il est essentiel de comprendre toutes les implications d’un système développé en interne en matière de coûts, d’engagement du personnel et de délai avant création de valeur.
- Votre plan est-il exhaustif ? Assurez-vous que votre solution finale couvre l’intégralité du parcours jusqu’à la mise en production et englobe toutes les tâches par lesquelles passe une mise à jour du code avant son arrivée en production.
Gardez ces éléments constamment à l’esprit et vous augmenterez considérablement vos chances de réussite.