Le Cloud Computing est souvent vendu à tort et à travers par les discours marketing des différents éditeurs comme une solution miracle et à bas coûts, qui va transformer les organisations.
De plus en plus, des voix discordantes s’élèvent pour remettre en question ces plaquettes commerciales, en mettant entre autre en avant des “coûts cachés” et un coût de possession, le fameux “TCO” (Total Cost Ownership), de la solution qui serait plus élevé qu’une solution traditionnelle installée sur site.
La réalité se trouve à mi-chemin de ces extrêmes : si l’aspect “low cost” du Cloud Computing est parfois avéré, la problématique des “coûts cachés” relève plutôt d’un manque de préparation ou de compréhension de ceux qui ont franchi le pas.
Nous essayerons de remettre en contexte le TCO, pour ensuite le détailler et le comprendre dans un contexte Cloud.
Le coût de possession, un indicateur parmi d’autres pour le pilotage des investissements
La gestion financière d’une entreprise repose sur un pilotage fin des actifs, notamment immobiliers, de l’organisation. Cela est particulièrement vrai dans le cas des investissements qui, s’ils sont clés pour le développement et la pérennité des entreprises, doivent être pertinents et surtout être mesurables. Cette capacité à mesurer permet d’abord une comparaison entre les différentes hypothèses d’investissement, mais surtout le pilotage des efforts financiers à consentir pour mettre en place cet investissement. Par exemple, on peut distinguer la capacité d’amortissement lié à un investissement, le TRI (le Taux de Rendement Interne d’un projet) ou encore le coût de possession.
Le Taux de Rendement Interne est un indicateur purement comparatif : il s’agit de disposer d’un indice qui quantifie l’apport d’un projet par rapport à la situation existante en s’attardant sur les bénéfices en termes de productivité et d’efficacité (que ce soit au niveau financier ou opérationnel).
Enfin, le coût de possession s’attarde lui sur la charge financière que fait porter le projet sur l’entreprise.
Concrètement, le coût de possession prend en compte l’intégralité des coûts relatifs à un projet : la phase de conception (Think), la phase de réalisation (Build), et la phase de maintenance (Run).
Ce calcul complexe doit de plus être homogène entre les projets considérés pour permettre une véritable comparaison à périmètre égal.
Cette maîtrise du coût total de possession est essentielle, car elle permet le pilotage financier des infrastructures et des solutions SI. Pour autant, la dépendance vis à vis de cet indicateur et plus grave, sa non maîtrise, ont des conséquences importantes sur le pilotage des investissements.
“Avec l’externalisation, un des rares leviers de pilotage qui reste dans les mains de l’entreprise est le coût, […] parfois au dépens des usages.” |
Le TCO s’est imposé de lui-même avec l’essor des projets informatiques structurants, dont les coûts ont atteint des sommes faramineuses car le périmètre organisationnel concerné était très vaste.
Avec le développement du recours à l’externalisation du SI, le coût de possession pour l’entreprise a diminué : en effet, les coûts matériels et d’infrastructure ont été impactés à la baisse grâce à la mutualisation des matériels et des infrastructures pour les exploitants externes. Pour autant, certains coûts perdurent (notamment ceux liés aux logiciels et à la prestation de service) et d’autres apparaissent (comme ceux inhérents au pilotage du prestataire de service par exemple).
Le recours quasi-systématique à l’externalisation a ainsi fait évolué peu à peu les points de vue liés aux coûts de possession . A la question stratégique de “quel outil pour supporter le développement de mon entreprise, et surtout à quel coût dans le temps ?” s’est substituée la question “comment puis-je réduire à tout prix mes coûts informatiques à court terme ?”, en déconnexion totale du pilotage stratégique de l’entreprise. Cela est renforcé par le fait qu’avec l’externalisation, un des rares leviers de pilotage qui reste dans les mains de l’entreprise est le coût, qui devient la justification stratégique ultime, parfois au dépens des usages.
“La DSI doit être un moteur sur la question du contrôle des dépenses IT en apportant un renouveau des services mis à disposition des équipes métiers.” |
Paradoxalement, entre l’émergence de ce questionnement sur la rationalisation des coûts informatiques et l’essor du Cloud Computing, il existe une réelle opportunité pour la DSI d’être un moteur sur la question du contrôle des dépenses IT tout en apportant un renouveau des services et des usages informatiques mis à disposition des équipes métiers.
Comprendre le Cloud pour se ré-approprier le coût de possession
Le Cloud Computing, par nature, introduit une logique et une approche différente du coût de possession. La flexibilité financière qu’apporte ce moyen de consommer les ressources IT permet de conserver les capacités d’investissements pour des projets liés au coeur d’activité de l’entreprise. Au niveau financier, pour les entreprises, le choix du Cloud peut donc avoir un réel impact stratégique qui sera à même de participer au développement de l’activité.
Pour autant, ce choix du Cloud doit être motivé et surtout avoir une vraie pertinence pour l’organisation, que ce soit d’un point de vue efficacité opérationnelle ou financière. Pour mesurer ces aspects, et comparer les bénéfices d’une solution Cloud à une solution traditionnelle sur site, il faut donc considérer le coût de possession.
“La flexibilité financière qu’apporte le Cloud permet de conserver les capacités d’investissements pour des projets liés au coeur d’activité de l’entreprise.” |
Cependant, comment construire cette mesure du coût de possession?
Le Cloud Computing, en rupture des usages traditionnels, ne propose pas l’achat d’une licence logicielle mais un modèle proche du leasing.
Pour rappel, le leasing permet l’utilisation d’un bien qui appartient à un tiers sous réserve du paiement d’une redevance récurrente sur la durée de l’utilisation; les dépenses d’entretien sont prises en charge par le propriétaire du bien. A l’expiration du contrat d’utilisation, l’utilisateur rend le bien à son propriétaire.
A ce titre, la notion de TCO n’est pas complètement adaptée au Cloud : si cet indicateur ne peut disparaître, car il reste une base compréhensible pour les comparaisons, la nature de son calcul doit évoluer pour rester pertinent dans un contexte cloud.
Dans l’absolu, le calcul de TCO dans le cloud sera donc plutôt un coût total d’utilisation, soit le TCOp (Total Cost of Operation).
Voici un tableau proposant quelques éléments constitutifs du TCO et TCOp pour chacun des types de déploiement considérés:
| Installation sur site (TCO) | Utilisation de services Cloud (TCOp) |
|
|
Les services Cloud impliquent des modalités d’accès et d’utilisation dans le temps qui diffèrent radicalement du modèle traditionnel sur les points suivants :
- La logique de redevance à l’usage du modèle Cloud Computing implique que l’utilisation de ces solutions s’envisage sur un espace de temps défini. En établissant cet espace de temps, il est alors possible de considérer un coût non pas de possession mais de location de la solution.
- Les coûts de maintenance matériels et logiciels sont inclus dans la redevance, et ne sont plus à considérer comme un poste de coûts à part entière. Il en va de même pour l’exploitation par les prestataires.
- L’utilisation de ressources distantes, et plus particulièrement Cloud, entraîne une prise en compte du coût de la connectivité : sans connectivité, pas d’utilisation des solutions Cloud.
En résumé, le calcul du TCOp d’une solution Cloud peut s’exprimer de la façon suivante:
- Les coûts d’accès au service (à savoir la connectivité et les terminaux d’accès)
- Le coût du service (le tarif de souscription), en prenant en compte le coût des extras liés au service (les options, les ajustements temporaires,…)
- Le coût des services complémentaires nécessaires, pour la mise en place et l’exploitation du service (formation, intégration, conseil,…; en somme, les prestations complémentaires fournies par un tiers en interne, ou en externe)
Mais alors, s’il y a moins d’éléments, une solution Cloud Computing, c’est moins cher non?
Si seulement les choses étaient aussi simples…!
Une subtilité rentre en ligne de compte : la durée d’utilisation de la solution, mais aussi les variables d’utilisation de la solution (performance, nombre d’utilisateurs, services additionnels,…). Ce sont ces éléments qui vont conditionner l’intérêt économique du passage au Cloud Computing.
“Si l’aspect financier doit être mesuré au cas par cas, il est un avantage qui reste lui universel : le gain de temps.” |
Globalement, le type de solution retenue (Cloud ou on-premises) sera propre à chaque cas, et devra faire l’objet d’une étude spécifique; il est compliqué de définir des grands cas standards qui auraient vocation à s’appliquer de façon universelle.
Pour autant, si l’aspect financier doit être mesuré au cas par cas, il est un avantage qui reste lui universel : le gain de temps.
La mise en route d’un service Cloud est comparativement plus rapide qu’une solution on-premise; il en résulte donc des gains opérationnels directs en terme d’efficacité des utilisateurs finaux, mais aussi une amélioration de la DSI interne qui peut se consacrer intégralement au développement de solutions spécifiques au coeur de l’activité de l’entreprise.
Un autre élément essentiel est le nombre de comptes utilisateurs : la rentabilité d’une solution traditionnelle sera dépendante du nombre d’utilisateurs attendus; plus ils seront nombreux sur un serveur, plus celui-ci (et les logiciels installés) seront rentables.
Enfin, comme illustré par la formule identifiée plus haut, on voit que la plus forte variable de comparaison réside dans les prestations complémentaires, liées à la formation des utilisateurs, à la gestion du changement, et plus généralement à l’accompagnement nécessaire à la transition vers l’utilisation de services Cloud. Les modèles de tarification de ces services n’ont que très peu évolué pour s’adapter aux services Cloud, à l’exception notables d’acteurs innovants qui s’adaptent vraiment aux attentes de leurs clients.
Mais alors, quels sont ces coûts cachés dont on parle quand il s’agit du Cloud Computing?
Les clients lésés par un accompagnement incomplet font référence à des “coûts cachés du Cloud” alors qu’ils s’agit simplement de coûts non maîtrisés et non identifiés par les parties motrices de cet accompagnement.
Comme nous vous l’avons montré dans une newsletter précédente, les entreprises ayant déjà adopté une architecture modulaire réduisent d’autant le temps et l’investissement financier nécessaire à l’intégration des services Cloud, et ont déjà limité de fait l’existence de ces coûts cachés.
Au final, comment piloter le coût des solutions Cloud?
La décision de migrer une partie de son SI vers le Cloud doit être réfléchie : le critère financier ne doit pas être le critère décisif pour cette décision.
Le choix du Cloud implique une remise en question du modèle SI traditionnel : au lieu d’améliorations en rupture tous les 5 à 10 ans, il faut envisager une évolution graduelle tous les mois, avec des solutions qui se réinventent tous les 3 à 5 ans.
Ainsi, la comparaison du TCO entre une solution traditionnelle et une solution Cloud doit s’envisager aussi sur une période longue, en incluant le coût des transformations “radicales”.
La solution Cloud apportera alors une maintenance continue avec une période d’indisponibilité très limitée, qui sera transparente pour les utilisateurs finaux. Les mises à jour étant incrémentales, le besoin d’effectuer une transformation radicale à échéance plus ou moins fixe s’estompe (sauf le besoin impérieux d’ajouter une ou plusieurs fonctionnalité(s) identifiées comme critique et absente du logiciel utilisé). Ces mises à jour en continu induisent une nouvelle façon de procéder: il s’agit d’accompagner les utilisateurs de façon plus continue, à l’aide de communications et de formations plus fréquentes.
Pour autant, dans le cas d’un changement de fournisseur SaaS, le besoin en terme d’intégration sera moindre (car l’architecture nécessaire à une intégration aisée des solutions Cloud aura été anticipée – cf. notre newsletter précédente sur l’architecture SOA), et le besoin d’accompagnement des utilisateurs sera aussi limité (la migration précédente aura formé les utilisateurs à ce nouveau moyen d’utiliser les services informatiques, et pourra se concentrer uniquement sur l’aspect ergonomique et fonctionnel).
Le TCOp doit donc comprendre l’ensemble des éléments que vous avons identifié plus haut :
- le coût de la prestation du cabinet de conseil pour définir le périmètre du projet, l’audit de l’existant, la gestion du changement, l’AMOA,…
- le coût de gestion des contrats et de la relation fournisseurs
- le coût de location des licences logicielles et leur mise à jour, sur une échelle de temps donnée
- le coût d’intégration au SI existant (comprend les options que certains fournisseurs proposent pour une meilleure intégration – APIs étendues, services, etc…)
- le coût de la connexion internet
Et en conclusion?
“Un service Cloud permettra de débloquer du temps disponible […] critique à la performance de l’entreprise.” |
Il faut dépasser le cadre des solutions traditionnelles pour s’approprier correctement le TCO d’une solution Cloud : le nouveau business model, ainsi que les impacts en termes de maintenance et de transformation technologique sont tels que la comparaison directe entre le TCO d’une solution traditionnelle avec son infrastructure et le TCOp d’une solution Cloud est un exercice compliqué, et qui n’aura qu’une valeur indicative.
La vraie valeur du Cloud ne peut se résumer à un indicateur économique et financier : adopter une solution Cloud, c’est avant tout choisir une nouvelle façon de consommer les services informatiques, et surtout un moyen de rapprocher les besoins métiers des impératifs marché.
L’innovation et l’efficacité apportées par les outils Cloud sont des éléments non financiers majeurs qui doivent rentrer en considération. La valeur débloquée par ces éléments sera d’autant plus significative que les métiers seront rapprochés de leur marché.
Enfin, un service Cloud permettra de débloquer du temps disponible en interne pour les équipes de la DSI, un temps qui pourra être mis au service du développement et de l’amélioration des outils internes critiques à la performance de l’entreprise.
Très bon article, clair et complet. Bravo.
Au titre de coût récurrent, je rajouerai juste le fait que les releases en continu impliquent de faire des séries de tests de non régression (ou autres si les fonctionnalités rajoutées sont susceptibles d’améliorer les processus métier) et dont le planning est dépendant de la fréquence de release de l’éditeur et donc pas dans « les mains » du client (cout organisationnael lié à la fréquence).
A bientôt.
Un lecteur intéressé…
Merci ! En effet, les releases continues demandent un niveau d’organisation en interne pour absorber des tests de non-régression à un rythme qui dépend des fournisseurs. Il est donc important d’optimiser les procédures de test : avoir des scénarios définis et clairs pour les tests de non régression partiels ou complets, identifier des utilisateurs clés qui maîtrisent le processus à tester et l’application, et surtout parvenir à automatiser les tests basiques et répétitifs. Le but est de minimiser l’effort pour valider chaque « release ».
Il est également important d’avoir de bonnes relations avec l’éditeur pour comprendre et potentiellement anticiper les évolutions (voire les influencer parfois) : cela permet de limiter les débordements, mais ça ne dispense quand même pas de la phase de test.
Enfin, même si ce processus de release continues est clairement un coût supplémentaire en termes de tests, c’est aussi le moyen d’être en permanence à jour sans effort technique, et donc d’assurer en partie la sécurité de l’application ou de profiter de nouvelles évolutions « par défaut ».