Stratégie

Les bonnes pratiques du FinOps, ép. 2 : le contrôle des coûts du cloud au coeur de la culture d'entreprise

---

Passé les premières optimisations, la démarche FinOps s'apparente à une course de fond. Car c'est la culture IT de l'entreprise qu'il faut transformer, pour l'adapter à la logique du cloud. Et revenir sur des décennies de surprovisionnement.

PublicitéEn abordant le chantier de l'optimisation des coûts du cloud, les entreprises pourraient y voir un exercice ponctuel, voué à s'éteindre une fois les optimisations mise en place. Rien n'est plus faux. Les spécialistes des grandes entreprises que nous avons interrogées - SNCF Connect & Tech, Société Générale et Veolia - confirment que le FinOps est bien une pratique à installer au coeur de la culture d'entreprise.

Car, dans le cloud public, ce sont les choix d'architecture - ou l'absence de remise en cause des choix préexistants - qui déterminent le niveau des factures. Une logique totalement différente de celle qui prévalait sur les infrastructures IT internes et qui impose un changement des mentalités. A l'échelle de l'organisation. Une gageure car les réflexes IT restent marqués par des décennies de culture du surprovisionnement, chaque silo technique intégrant ses propres marges de sécurité dans ses calculs de dimensionnement. « On continue à massivement gaspiller des ressources informatiques : récemment, sur un parc comprenant plus de 1000 VM, j'ai relevé un taux d'utilisation des serveurs de 8%, soit environ ce que nous observions lors des premiers projets de virtualisation il y a des années de cela », note Renaud Brosse, senior partner au sein de la société de services Timspirit.

1) Repenser l'architecture pour contenir les coûts

Sur le cloud, c'est fondamentalement l'architecture des applications qui détermine les coûts. C'est, en partie, cette règle qui pousse les entreprises ayant migré une partie significative de leur portefeuille applicatif à rechercher une transformation de leurs architectures applicatives pour embarquer des services proposés par les prestataires de cloud offrant un rapport performance/prix attractif. « Le refactoring, qui consiste à aller de plus en plus vers infrastructures pensées pour le cloud, est un levier d'économie clairement identifié. Le meilleur exemple reste probablement le recours aux bases de données managées », abonde Renaud Brosse.

« Lors de notre Move-to-cloud, nous avons adopté majoritairement l'approche Lift & Shift pour gagner en rapidité. Désormais, nous profitons de la modernisation ou du remplacement des applications pour exploiter des technologies cloud native comme les conteneurs et le serverless ou encore pour basculer toutes les applications vers la base de données PostgreSQL », illustre Michel Poulalion, responsable FinOps et sobriété numérique au sein de la DSI de Veolia. Autant d'approches qui débouchent sur une réduction des coûts de fonctionnement.

Passé les premières optimisations, le FinOps s'apparente donc plutôt à une course de fond. « Il faut continuer à surveiller que les bonnes pratiques sont respectées, mais aussi tenir compte de l'évolution du catalogue AWS, où apparaît régulièrement de nouveaux services managés ou de nouveaux gabarits qu'il faut analyser pour évaluer les optimisations qui peuvent en découler. Car, même sur le cloud, on peut se retrouver dans des situations d'obsolescence technologique », reprend le responsable de Veolia, groupe dont 80% de l'empreinte cloud actuelle repose sur AWS (les 20% restants étant externalisés chez GCP, surtout autour de services PaaS).

PublicitéLe constat est similaire chez SNCF Connect & Tech, l'entité e-commerce et technologies de la compagnie nationale. « Aujourd'hui, nous privilégions des approches de refactoring ou de redéveloppement pour certaines applications, en s'appuyant davantage sur les services managés. Cette phase est associée à une démarche d'optimisation de nos coûts », résume Sébastien Gobin, son directeur de la qualité et des opérations. Avec un impact direct sur les choix d'architecture, opérés par une instance dédiée, le comité IT : « celui-ci regroupe des compétences tech, mais aussi produits. Car ces dernières doivent aussi avoir en tête l'impact budgétaire de telle ou telle nouvelle fonctionnalité. Lors de ce comité IT, sont présentés des choix d'architecture et de services ainsi que des projections en termes de dépenses. C'est cette instance qui amende, interroge et, in fine, valide ces options. » Et les choix à opérer sont parfois subtils comme l'illustre Martin de Roquefeuil, Lead FinOps au sein de SNCF Connect & Tech : « dans le choix des services, tout l'enjeu consiste à trouver le bon équilibre avec le prestataire. Par exemple, sur DynamoDB, on peut soit laisser AWS gérer la table, soit effectuer nous-mêmes la gestion des capacités. Or, avec ce dernier choix, la facture est parfois divisée par dix. Bien positionner le curseur s'avère donc crucial. »

Ce que Renaud Brosse qualifie de FinOps by Design est par définition une activité récurrente et ne peut se passer de l'implication des équipes applicatives. « Il est impossible de considérer le FinOps comme une pratique figée, car les catalogues et les tarifs des fournisseurs évoluent. La nécessaire veille sur ces sujets n'est pas simple à organiser et c'est pourquoi il est important de disposer d'une communauté FinOps, et non de quelques compétences centralisées. Car se tenir à jour et modifier les pratiques au fil de l'eau est un défi important », tranche Sylvain Jannot, en charge du pilotage des coûts et de la performance au sein de la direction des infrastructures à la Société Générale.

Pour les entreprises déjà solidement installées sur le cloud public, chez qui les mécanismes d'économies les plus immédiats (relâchement des ressources inutilisées, engagements de consommation, recours aux instances spot...) sont déjà largement exploités, cette veille sur les nouvelles architectures proposées par les prestataires apparaît bel et bien comme la principale arme pour contenir les factures cloud. Ainsi de Veolia. « La facture du cloud reste relativement stable depuis un à deux ans. Mais nous nous sommes fixés pour objectif de la faire reculer de 10% sur trois ans, explique Michel Poulalion. Un objectif atteignable grâce aux changements de gabarit ou au renouvellement d'applications. » Et de prendre l'exemple - extrême - d'un site Web qui, après migration en Lift & Shift, coûtait 250 dollars par mois et dont la facture, après redéveloppement en technologies serverless, est désormais descendue à 2 dollars par mois.

2) Installer la culture FinOps

Le corollaire des constats précédents ? Le FinOps n'est pas et ne peut pas être la chasse gardée d'une petite cellule intervenant à posteriori pour optimiser les dépenses des équipes applicatives. Une telle approche serait vouée à ne produire que des résultats par trop limités. Dans les grandes entreprises que nous avons interrogées, le FinOps est avant tout une démarche collaborative entre des spécialistes du sujet, des profils plus financiers et les équipes applicatives.

« Le FinOps, c'est avant tout un changement culturel qu'il faut opérer auprès d'un grand nombre d'acteurs », dit ainsi Sylvain Jannot, à la Société Générale. Les responsables applicatifs doivent visualiser leurs dépenses pour s'approprier peu à peu les pratiques ; les architectes doivent intégrer les bonnes pratiques au plus tôt dans les projets ; la direction financière doit mesurer l'impact du recours au cloud sur la mécanique budgétaire, etc. « On parle donc bien d'une organisation et d'une gouvernance associée permettant de porter une vision partagée largement dans l'entreprise. » Au sein de la Société Générale, groupe comprenant de nombreuses entités aux métiers très différents, la démarche FinOps combine proximité avec les équipes applicatives et cadre global cohérent (contrats groupe, reporting harmonisé, standard de tagging...). « Notre vision, c'est que ce sujet doit rester proche des équipes métiers, qui comprennent la valeur de leurs applications et sont à même de les rapprocher de KPI centrés sur l'activité », reprend Sylvain Jannot, qui peut s'appuyer sur une communauté largement composée de spécialistes immergés dans les business units.

La complémentarité entre spécialistes FinOps et équipes applicatives est d'ailleurs essentielle à l'identification des leviers d'économies. L'équipe centralisée fournissant l'expertise sur les leviers d'économies, tandis que les équipes applicatives ont la main sur les évolutions et les arcanes techniques de leur portefeuille. Au sein de SNCF Connect & Tech, deux spécialistes FinOps au niveau central bénéficie de relais au sein de la dizaine de divisions que compte cette structure. « Ces profils FinOps intégrés aux métiers sont objectivés sur le respect de leurs budgets, ce qui ne peut pas être le cas de l'équipe en central qui n'a pas les leviers d'action en main », commente Martin de Roquefeuil.

Son collègue Sébastien Gobin, directeur de la qualité et des opérations, souligne d'ailleurs la complémentarité entre ces deux niveaux d'optimisation : « L'équipe FinOps en central va gérer la relation avec le prestataire, suivre les tendances en matière de consommation, traiter des optimisations haut niveau, comme des réservations d'instance pour l'ensemble des applicatifs. L'autre niveau s'effectue à une échelle plus locale, avec un suivi applicatif par applicatif de l'ensemble du cycle de vie, de l'émergence d'un besoin à l'évolution en production. » Car, au-delà des choix d'architecture, il faut également monitorer les coûts et détecter les dérives. Ce qui passe notamment par des tableaux de bord et la mise en place d'alertes. « A partir de certains seuils, 1000 ou 2000 $, les équipes sont informées afin de prendre les actions de remédiation nécessaires en se basant sur l'expertise FinOps centralisée pour orienter les actions et capitaliser sur ce qui peut être fait dans d'autres projets. C'est un travail au quotidien avec les équipes applicatives sur la partie production », reprend Sébastien Gobin.

Et ce travail nécessite parfois également une expertise fonctionnelle approfondie, pour comprendre l'origine de certaines dérives budgétaires, comme le souligne Sébastien Jannot : « savoir comment optimiser la consommation d'un applicatif n'est pas forcément évident d'emblée. Par exemple, nous avions le cas d'un applicatif qui voyait ses coûts augmenter légèrement, avec une cyclicité de ses fluctuations. Via une analyse fine du fonctionnement de cette application, nous avons compris que ce phénomène provenait en réalité d'un dysfonctionnement dans les mécanismes de relâchement des ressources. Pour identifier ce genre de dérives, les équipes applicatives sont clairement les mieux placées, car ce sont elles qui possèdent les compétences fonctionnelles. » Notons que ce travail d'optimisation au quotidien ne se limite pas à la production et doit être complété par des actions menées sur le hors-production, où les coûts sont plutôt liés au nombre de développeurs ou au développement de fonctionnalités, et sur les projets. « Encadrer et anticiper le coût des PoC et des expérimentations s'avère plus complexe. On se base sur des seuils pour arrêter une initiative ou la réadapter quand on sent que la maîtrise nous échappe », dit Sébastien Gobin.

Autant d'exemples qui montrent combien l'animation de la démarche FinOps dans la durée s'avère cruciale, « sinon un risque de délitement existe » juge Olivier Rafal, directeur de la stratégie conseil de WeEnvision, la branche conseil du groupe SFEIR. « Sans cette phase de run, visant à surveiller les pratiques, les mettre à jour et à automatiser, le chaos va se réinstaller, ne serait-ce que sur la politique de tags, qui est le nerf de la guerre en matière de FinOps ».

Pour installer cette culture, certaines entreprises mettent en place des mécanismes d'incitation pour les équipes techniques, comme une embauche si un certain volant d'économies est réalisé. Ou des badges pour les équipes les plus sobres en matière de GreenOps. L'alignement naturel entre FinOps et sobriété numérique est fréquemment mis à profit par les entreprises, qui y trouvent un levier intéressant de mobilisation des équipes. C'est par exemple le cas au sein de la Société Générale. Sa stratégie FinOps, qui couvre ses deux prestataires (AWS et Azure) mais aussi son cloud interne, est alignée avec la politique GreenOps du groupe. « C'est un levier de mobilisation intéressant au sein des équipes applicatives, qui sont souvent sensibles à cet aspect », observe Sylvain Jannot.

« Travailler en parallèle sur la soutenabilité de l'IT permet souvent de renforcer la motivation des équipes. Car les deux démarches sont largement alignées », abonde Renaud Brosse, qui de toute façon dit ne pas croire à une gouvernance centralisée qui limiterait les usages à quelques services et imposerait des standards. « Ce serait tuer dans l'oeuf les bénéfices du cloud. Mais il faut veiller à actionner plusieurs leviers : garder l'attention du management sur les factures du cloud et l'avancement des plans d'optimisation ; instaurer un fonctionnement en communauté tout en conservant une expertise globalisée assurant la veille sur l'offre et accompagnant les équipes dans leurs campagnes d'analyse et d'optimisation ; veiller à la formation des informaticiens aux problématiques financières et à celle des contrôleurs de gestion à la nature du cloud et des catalogues des prestataires. »

3) Le levier contractuel

Quand une entreprise possède une certaine maturité dans ses usages du cloud public - et donc une certaine visibilité sur l'évolution de sa consommation globale -, elle peut se tourner vers une nouvelle forme d'optimisation : l'engagement global, portant sur sa consommation auprès d'un prestataire sur une durée pluriannuelle contre un rabais sur le coût de chaque service consommé. C'est d'ailleurs le cas tant de Veolia, que de la Société Générale et de SNCF Connect & Tech. « Sur le plan contractuel, nous n'avions auparavant recours qu'aux instances réservées, ce qui était contraignant car nous ne pouvions pas changer de service pendant la durée de l'engagement, commente Michel Poulalion (Veolia). Notre expérience du cloud nous permet désormais de prendre un engagement global sur une durée d'un à trois ans auprès d'AWS, associé à un tarif à la consommation horaire offrant un discount de 20 à 30%. » La maturité de cet engagement est panachée entre un et trois ans, pour répartir les risques.

Ces contrats globaux peuvent d'ailleurs être couplés à des mécaniques d'engagement plus classiques portant sur des ressources particulières, pour aboutir à des niveaux d'économies globaux plus importants par rapport aux prix publics affichés par les prestataires. « Prendre des engagements au niveau de l'entreprise elle-même, contre un rabais global, amène un changement de paradigme. En le couplant à des engagements plus locaux, on parvient à des économies comprises entre 20 et 70%, détaille Martin de Roquefeuil (SNCF Connect & Tech). Sur un projet pris unitairement, s'engager sur plus d'un an reste difficile, alors qu'au niveau de l'entreprise au global, on peut aller au-delà, et miser sur des durées de trois ans. C'est en jouant sur cette dualité que nous avons bâti notre stratégie d'engagement en maniant des durées et des périmètres variables, tout en s'assurant que ces engagements n'ont pas d'impact opérationnel sur les équipes. » Une stratégie réexaminée tous les trimestres avec la DAF afin de vérifier que les économies attendues sont bien au rendez-vous.

Retrouvez la première partie de notre enquête sur le déploiement des pratiques FinOps :

- Les bonnes pratiques du FinOps, ép. 1 : lutter contre les dérives des coûts du cloud

Article rédigé par

Reynald Fléchaux, Rédacteur en chef CIO
Suivez l'auteur sur Twitter

Partager cet article