Lors du précédent article, nous avons passé en revue l’ensemble des options disponibles qui permettent aux entreprises de signer un contrat équilibré, performant et adapté à leurs besoins.
Négocier avec le fournisseur Cloud, un véhicule contractuel adapté à la stratégie et la gouvernance de l’entreprise permet de construire une relation commerciale équilibrée, basée sur le partage de valeurs.
Une fois ces règles du jeu contractuelles établies et partagées avec l’ensemble des parties prenantes, on va devoir s’assurer que les consommations futures tireront parti au maximum des conditions et de la tarification négociées.
En effet, un des aspects à mettre rapidement sous contrôle est la création des projets sur le Cloud afin de s’assurer que toute personne qui provisionne des services Cloud a bien l’autorisation de le faire.
Un processus d’engagement de dépenses historiquement long et complexe.
Historiquement, dans le cadre du lancement d’un nouveau projet en datacenter, les processus d’engagement de dépenses étaient connus et maîtrisés par l’ensemble des parties prenantes. On ne pouvait pas acheter des biens ou des services sans justification d’achat. Il fallait montrer patte blanche pour lancer une commande d’achat.
Quels sont les actifs et/ou services à commander ? Quel projet justifie cette acquisition ? Quels sont les métiers, les départements, les entités bénéficiaires ? Quel est le montant ? Sur quel budget ? S’agit-il de charges récurrentes ou d’investissements à amortir ?
Chaque dépense d’investissement ou de charges faisait l’objet d’un processus de justification d’achat et de validation financière à travers l’ERP de l’organisation. Une demande d’achat, associée à un code budgétaire (centre de coût) était soumise dans le système afin d’obtenir les validations nécessaires pour l’acquisition d’un actif matériel, logiciel ou d’un renouvellement de contrat de maintenance.
La validation se passait souvent en trois étapes :
- Validation technique : L’actif ou le service à commander est-il conforme avec le système d’information de l’entreprise?
- Validation Budgétaire : Le montant à payer sera pris sur un budget, un centre de coûts en particulier, son responsable valide t-il la dépense ?
- Contrôle de gestion : Les fonds sont-ils disponibles dans le budget sélectionné ?
Une fois validée, la demande d’achat se transformait en bon de commande qui était envoyée aux fournisseurs. En retour, les fournisseurs livraient le(s) actifs et/ou les services et émettaient des factures à payer correspondantes.
Une fois réceptionnés, les actifs et les services sont rentrés dans une CMDB et sont associés à un code budgétaire, à un code projet, à un trigramme applicatif. On a toutes les justifications qui décrivent les raisons qui ont motivé l’achat, la dépense. Les actifs seront ensuite installés et paramétrés pour fournir les services pour lesquels ils ont été acquis.
Un processus complexe mais qui a fait ses preuves en son temps.
Le Cloud c’est rapide mais souvent “open bar” lorsqu’on commence.
Sur le cloud, chacun peut facilement et rapidement provisionner n’importe quel service en pressant sur un bouton et sans aucun contrôle préalable, du moment qu’il possède les droits techniques pour le faire.
Un vrai accélérateur pour le “Time to market”. Sur le Cloud, on s’affranchit de toute la complexité des commandes physiques pour mettre rapidement en œuvre un projet.
Le revers de la médaille est que le Cloud est un peu trop ouvert aux équipes IT, qui déploient souvent des services sans avoir obtenu préalablement l’autorisation financière.
“La finance, c’est pas chez nous” entend-on souvent !
Il est donc important de remettre en place un processus de justification d’achat sur le Cloud afin de s’assurer que tout projet lié à une application, un produit, un département, une entité juridique, possède un budget et un porteur identifié au sein de l’organisation.
Les fournisseurs de Cloud offrent tous les outils pour le faire à travers deux fonctionnalités :
- Les tags ou labels,
- Les budgets et alertes.
Pour être efficace, un pré requis est de créer ces tags et budgets dès la création du projet, avant même d’avoir commencé à déployer des services et des ressources. L’objectif étant de s’assurer que le payeur des services déployés est connu et qu’il est autorisé à dépenser un montant identifié.
Les tags administratifs vont permettre d’identifier le propriétaire de l’application et l’ensemble des informations administratives et financières qui lui sont rattachées. C’est un peu la carte grise de votre véhicule Cloud. Il faut la renseigner dès sa naissance.
Le budget, c’est l’essence d’un projet Cloud. Sans budget identifié, on ne sait pas qui déploie des services, qui paye la consommation, quel est le montant prévu et budgété pour cette dépense ?
Sans baseline, sans budget et sans payeur identifiés, difficile de déterminer si l’on consomme correctement des services Cloud et de définir un seuil d’alerte en cas de dérapage de consommation.
Dans la plupart des organisations que j’ai pu rencontrer, la création des projets est dans les mains des équipes en charge des infrastructures de déploiements (IAC ou CI/CD). Ils créent les projets sans tags administratifs, sans codes budgétaires .Ils ne paramètrent pas d’alertes et commencent à déployer des services. Résultat, on ne sait pas qui se cache derrière les dépenses de tel ou tel projet.
La création d’un projet Cloud est un geste administratif
Sur le cloud, les CSP mettent à disposition des calculatrices pour évaluer le coût mensuel de la configuration cible.
On est complètement autonome pour estimer le coût des services nécessaires à l’application. Le responsable produit va pouvoir construire facilement et rapidement son budget, sur la base de son dossier d’architecture Cloud et le défendre en comité d’investissement.
Une fois le budget validé par ses pairs, le responsable produit a toutes les billes en main pour lier les informations financières à son projet Cloud.
Mais souvent, il manque aux organisations une interface pour renseigner ces informations cruciales pour un suivi transparent des coûts. Pourtant, toutes sont équipées d’un centre de service IT qui est capable de gérer ce type de demande.
En effet, la création d’un projet Cloud est un geste administratif. Il peut très bien passer par une solution de centre de service IT où le demandeur va pouvoir lancer une demande de création de projet Cloud, via une interface web, par exemple.
En intégrant le centre de services dans le processus de création de projets, on va pouvoir également offrir une certaine traçabilité des opérations sur le Cloud et donc améliorer la gouvernance Cloud.
La demande peut passer par un formulaire dans lequel le demandeur peut renseigner l’ensemble des informations administratives obligatoires :
- Le nom de l’application, du produit et/ou son ID associé,
- Le nom du responsable du budget,
- Le code budgétaire du projet,
- Le montant mensuel du budget,
- Le nom de l’entité juridique, propriétaire du compte de facturation,
- Le nom du département,
- Le nom de l’équipe,
- Le type d’environnement.
Bien entendu, cette liste n’est pas exhaustive. Chaque organisation a ses propres exigences, us et coutumes. Cela participe à la mise en place d’une gouvernance Cloud efficace, d’une politique de tagging standardisée et normée, grâce aux différents référentiels d’entreprise (organigramme, référentiel financier) qui alimentent le formulaire.
Une fois l’ensemble des informations administratives renseignées et en pressant le bouton “VALIDER”, le centre de services IT, branché aux services d’”infrastructure as code » comme Terraform et Ansible par exemple, va pouvoir automatiquement :
- Créer le projet (AWS Account, Azure Subscription, GCP Project),
- Lier les informations administratives sous forme de tags ou de labels,
- Créer le budget et son montant alloué,
- Créer les alertes et définir les seuils d’alertes de consommation.
Le processus de gestion de la demande de nouveaux projets Cloud est en sorte la ligne de départ de votre parcours sur le Cloud.
Grâce au centre de service IT, en plus de comptabiliser le nombre de projets Cloud créés tous les mois, on s’assure que tous les nouveaux projets sont correctement tagués, que tous les budgets sont créés et que les alertes de consommation sont paramétrées.
Une étape de contrôle indispensable pour assurer une bonne gouvernance et garantir un pilotage efficace des opérations financières sur le Cloud.
Une fois l’étape de création terminée, les DevOps peuvent reprendre la main et commencer à déployer les services communs et les ressources applicatives.
Mais au-delà de la bonne pratique FinOps, cela permet surtout de comprendre qui consomme quoi sur la plateforme Cloud, de s’assurer que chaque projet possède un propriétaire, un budget et un montant identifiés.
Toutes les informations techniques, financières, et métiers en provenance du Cloud, peuvent être regroupées dans un tableau de bord complet, clair, précis et fiable.
Idéal pour améliorer la transparence des coûts, prendre rapidement des décisions éclairées et tirer pleinement parti du modèle d’affaire du Cloud.
Avoir une approche cycle de vie est cruciale lorsqu’on aborde la question de la création de projet Cloud.
C’est le véhicule de votre parcours Cloud. Tout véhicule doit avoir la “carte grise” qui identifie le propriétaire.
Établir une carte grise est un processus obligatoire lors de l’acquisition d’un véhicule. Il en va de même sur le Cloud. Maîtriser le processus de création de projet Cloud en l’associant à une politique de tags vous permettra vraiment de favoriser la transparence des coûts, de limiter les dépenses mal maîtrisées et accessoirement, d’éviter de se faire rattraper par la patrouille…
