Embauché il y a 2 ans pour digitaliser les process, Alexandre Aubry raconte tous les changements que cela a induit : transformation de l'organisation, de l'infrastructure matérielle et réseau, ouverture et décommissionnement progressif de l'ERP Cobol...
Nous avons assisté à la conférence client de l'entreprise Orange à Agile en Seine. Cet article vous propose de découvrir comment l'IA Gen devient déjà un atout incontournable chez certains clients.
Un bon mix d'indicateurs - des KPI classiques ainsi que des KPI personnalisés - devrait vous aider, à condition de respecter un principe essentiel : faites simple !
Ne blâmez pas le Cloud quand les coûts deviennent visibles !
De par son modèle de facturation, le Cloud braque un projecteur sur les coûts. Une transparence qui invite à réfléchir sur les choix techniques et stratégiques.
Quelques histoires de rapatriements de workloads depuis le Cloud vers des datacenters on premises ont fait les gros titres ces derniers temps. Il y a quelques jours, le magazine CIO m'a interviewé sur le sujet (cf. ci-dessous). Or ce n'est pas ce que je constate autour de moi, chez nos clients. Nous connaissons tous des entreprises où les coûts ont dépassé les budgets estimatifs sans qu'on sache très bien pourquoi. Mais globalement, même sans une incroyable maturité FinOps, le simple fait d'aborder le Cloud de façon raisonnée permet de créer de la valeur sans que les coûts n'explosent.
En fait, le Cloud est souvent le révélateur des coûts. Comme le dit très bien l'architecte Gregor Hohpe, le Cloud met en lumière le sous-sol. Tout ce qui auparavant était opaque, noyé dans la masse d'un budget global, devient visible, par la grâce du passage en Opex, accompagné d'une facture extrêmement détaillée.
S'interroger d'abord sur la pertinence des choix techniques et architecturaux
On peut s'apercevoir à cette occasion du poids de certains traitements, des ressources que la conception architecturale et la manière de coder exigent. Et trouver que décidément, le Cloud est beaucoup plus cher. Plutôt que de blâmer le Cloud, il vaudrait mieux s'interroger sur la pertinence des choix qui ont été réalisés.
Le workload migré a-t-il intérêt à l'être ? S'agit-il d'un choix répondant à un véritable besoin : élasticité ? puissance ? latence ? fréquence d'évolution ?...
L'architecture du workload est-elle encore la meilleure possible ? N'y a-t-il pas des changements à effectuer pour bénéficier de l'environnement Cloud ? N'est-ce pas le moment, par exemple, de passer à une architecture orientée événements ?
Le code ne peut-il être réécrit ? La fonction ne serait-elle pas mieux exécutée en mode serverless ?
Intégrer le temps passé et les bénéfices business dans le calcul
A cette liste de questions non exhaustive, il faut ajouter l'examen des gains et opportunités business, ainsi que l'analyse du temps passé par les équipes IT sur des tâches qui ne créent pas directement de valeur business. Or dans la grande majorité des cas, l'entretien d'une infrastructure spécifique ne crée pas de valeur pour le business.
Ces éléments sont évidemment délicats à quantifier ; il faudra choisir avec soin les métriques business à suivre. C'est pourquoi il est si important de commencer tout projet Cloud par une phase d'analyse de la stratégie business. Dans tous les cas, que le Cloud, de par son modèle de facturation, mette les coûts en lumière n'est pas une mauvaise chose, au contraire ; c'est cette transparence qui permettra un pilotage par la valeur. En responsabilisant les acteurs du business sur les investissements nécessaires au regard de leur stratégie et de leurs initiatives.