Le cloud peut être un formidable levier d’innovation. Il facilite l’utilisation d’outils d’Intelligence artificielle. Il fait changer les pratiques. Grâce – ou parfois à cause de lui – on fait ou on fera du DevOps, du SecOps, du FinOps… et bientôt du « Product as Ops ».
Cependant, tout cela ne se fait pas sans douleur. Quelle équipe n’a pas été surprise par « sa facture cloud » à la fin de l’année ? Quel « Product Owner » (PO) ne s’est pas senti « désœuvré » pendant la phase de migration ou dépassé face à tous les services offerts par les fournisseurs de cloud ? Et quel manager ne s’est pas retrouvé avec des PO et des team leaders à couteaux tirés (les premiers poussant de nouvelles features et les seconds poussant la mise en place d’une architecture microservices) ?
Reste que 90 % des entreprises (source Gartner) auraient déjà entamé leur migration vers le cloud pour en tirer les bénéfices. La tactique est sensiblement la même pour toutes.
Elle s’articule autour de deux phases. Après un pilote sur quelques applications représentatives, toutes les applications sont ensuite migrées en l’état en minimisant les changements dans le code (« lift and shift »). Les changements profonds, liés à l’utilisation de services managés ou à la mise en place d’une architecture distribuée afin de tirer tous les bénéfices du cloud, viendront dans un second temps et se feront au fil de l’eau.
Or cette seconde phase va avoir un impact significatif sur l’organisation. Car si d’importants moyens ont été investis sur la technique, très peu ont été mis sur les équipes produits. Or celles-ci seront très fortement impactées. Et l’on voit poindre un nouveau rôle : le Chief Product and Technology Officer (CTPO).
Après une migration, le premier impact notable est la difficulté des équipes à maîtriser les coûts des infrastructures.
Il faut veiller à éteindre les ressources qui ne sont pas utilisées. Lorsque c’est possible, il faut aussi prendre le réflexe de choisir les algorithmes qui consomment le moins de ressources. Cet apprentissage a une incidence sur le product management, car il impacte le ROI des applications.
Un autre effet concerne la gestion de la sécurité, dévolue maintenant aux équipes de développement. Elles doivent identifier et appliquer, avec les experts sécurité, une politique de protection de ces applications, de ces données et de gestion des patchs applicatifs.
On ne le répétera jamais assez : si les fournisseurs de cloud assurent la sécurité des infrastructures, il est de la responsabilité des entreprises de protéger leurs données.
Souvent ces considérations n’ont pas été anticipées et sont découvertes en chemin, ajoutant des délais, parfois importants, dans les roadmaps produites.
Une troisième et dernière répercussion concerne la nécessité de changer le code pour intégrer les services managés ou modifier les architectures afin d’obtenir des applications plus résilientes, dont les temps de réponse sont plus rapides, et qui peuvent être mises à jour très fréquemment sans arrêt de service.
Ici, une négociation doit avoir lieu au sein de l’entreprise.
Or les équipes produit peuvent se sentir démunies : non seulement la migration a pris toute la bande passante, mais il faut également en réserver une bonne partie pour le changement du code. Vendu comme une avancée majeure, le cloud peut alors au contraire apparaître à leurs yeux comme un frein majeur à l’évolution du produit. D’un autre côté, le refactoring du code n’est pas acquis aux yeux des développeurs. Le sacrifier au profit de nouvelles fonctionnalités ne serait pas une première.
Les équipes doivent donc – encore plus qu’avant – maîtriser les coûts d’exploitation, gérer la sécurité, offrir de la haute disponibilité applicative, tout en livrant fréquemment de nouvelles fonctionnalités.
Ces enjeux concernent à la fois les techs et les produits. Le modèle de migration « lift and shift », uniquement focalisé sur la technique, atteint ses limites, car il faut aussi et rapidement embarquer le product management. Il devient crucial d’aligner tous les employés sur les mêmes objectifs, business et techniques, et d’éduquer le produit aux contraintes et aux possibilités du cloud.
Le Chief Product and Technology Officer (CPTO) est un nouveau rôle de direction qui entre dans cette tendance.
Il chapeaute à la fois les équipes produit et les équipes techniques afin de mieux les aligner sur la stratégie de l’entreprise et de stimuler l’innovation. N’oublions pas : celle-ci se niche dans les ruptures technologiques et les ruptures d’usage.
La plupart des sites web utilisent aujourd’hui des chatbots pour améliorer leur relation client, et sont une rupture technologique du début des années 2010. Airbnb est un exemple de rupture d’usage. L’innovation ici n’est pas dans la technologie (après tout ce n’est qu’une application de gestion), mais avec une réelle valeur ajoutée dans la mise en relation simple et inspirante entre hébergeur et locataire avec un tiers se portant caution.
L’une des missions du CPTO est de créer des tensions positives dans les équipes entre le produit et la tech afin de bénéficier au plus vite des ruptures, qu’elles soient technologiques ou d’usages.
Dans le cadre du cloud, et pour bénéficier de toute sa puissance, il est nécessaire d’aligner le product management sur la mise en place d’une architecture distribuée, ou sur le refactoring lié à l’utilisation des outils de monitoring ainsi que sur le temps à consacrer à la sécurité.
Pour la tech, construire un produit sur une rupture d’usage implique d’adopter des démarches empiriques de création de produit, où l’enjeu est moins de sortir la solution définitive que de pouvoir faire évoluer très vite les fonctionnalités en fonction des remontées du terrain.
Côté product management, la maîtrise des coûts (FinOps) impacte la rentabilité du produit. Les architectures distribuées et la gestion de la sécurité (SecOps) ont un effet sur la résilience des applications et donc la haute disponibilité. Les usines logicielles et le monitoring en production (DevOps) impactent la capacité à livrer fréquemment des fonctionnalités. Et demain, les services managés ou les fonctionnalités en SaaS affecteront fortement les feuilles de route des produits.
En 2015, créer un chatbot passait par un développement interne. En 2022, les chatbots sont disponibles à travers des services cloud. Le time to market n’est plus le même.
Pour s’adapter à ces répercussions, trois nouveaux domaines de compétences semblent émerger chez les Product Owner (PO).
L’acquisition, par le PO, de ces nouvelles compétences ne doit en rien se substituer à celles du product management, ni déposséder les développeurs des décisions d’implémentations. Le PO n’a pas vocation à devenir un expert technique et c’est aussi l’un des atouts du cloud de proposer des services dont la compréhension d’utilisation ne nécessite ni un bagage technique ni un coût d’entrée très fort.
Encore une fois, l’intention derrière ces spécialisations est aussi d’utiliser le cloud comme une opportunité de rendre plus congruents le produit et la technique.
Au début des années 2000, on parlait autant d’eXtrême Programming (XP) que de Scrum. Scrum a percé, car la dissociation des rôles de PO et de développeurs était très proche des modèles existants en entreprise, là ou XP promouvait un modèle plus artisanal, où le sachant technique pouvait aussi bien participer à l’implémentation qu’à la conception du produit, comme un artisan est force de conseil, réalise les devis et les travaux.
L’histoire repassant les plats, il est intéressant de constater comment le cloud inscrit les PO dans ce mouvement.
Tous droits réservés, Copyright 2007 – 2022, TechTarget
