Modèles de coûts informatiques

L'évaluation des coûts du système d'information de l'entreprise et leur refacturation aux utilisateurs peuvent être source de conflits[1]. Le recours à une approche structurée et largement répandue limite ces risques. L’approche Activity-Based Costing a pour objectif de mieux mesurer la consommation de ressources liés aux activités et aux processus. Les modèles ont d’abord été développés dans les directions générales puis les directions opérationnelles des entreprises. Depuis le milieu de la décennie 2000-2010, les DSI (Direction des Systèmes d'information) ont appris à appliquer la méthode ABC à leur profit. Pour cela, les DSI disposent de deux référentiels de la profession, complémentaires :

  • Le modèle benchmarking des coûts informatiques du Cigref
  • Le modèle d’analyse des coûts de la production informatique du CRIP

Contexte et enjeu[modifier | modifier le code]

Le modèle ABC a été appliqué car on a eu tendance à vouloir diminuer le budget du DSI alors qu’il y a de plus en plus de technologies à exploiter, de plus en plus de complexité applicative. D'autre part, la DSI était perçue comme un centre de coût et éprouvait souvent des difficultés pour justifier ses moyens financiers (valeur des services fournis aux entités de l‘entreprise, apporter une lisibilité sur les coûts de l’IT). Enfin, les entreprises ont besoin d'identifier les leviers d’optimisation économique.

Le modèle des coûts informatiques du Cigref[modifier | modifier le code]

Benchmarking des coûts informatiques – Modèle et guide de mise en œuvre du standard IGSI (2006)[modifier | modifier le code]

Contexte[modifier | modifier le code]

En 2004, le Cigref[2] et l’AFAI ont créé l’Institut de la Gouvernance des Systèmes d’Information (IGSI). Cette structure commune représente l’un des premiers instituts nationaux de gouvernance des systèmes d’information affilié à l’IT Governance Institute (ITGI), créé en 1998 par l’ISACA. Les objectifs de l’IGSI sont de :

  • Rationaliser les systèmes d'information et préparer l'entreprise du futur.
  • Créer de la valeur et mesurer plus particulièrement celle créée par les systèmes d’information.
  • Proposer un cadre de rencontres et de référence promouvant des SI plus « lisibles ».
  • Promouvoir des normes internationales.

Le contexte des DSI en 2006 est particulièrement propice à la création d’un référentiel des coûts informatiques :

  • La fonction informatique est sous pression, du fait des demandes des actionnaires, de la concurrence croissante mais aussi parce que les Technologies de l'Information de la Communication deviennent de plus en plus le levier de transformation stratégique de l’entreprise.
  • Les Directeurs des Systèmes d’Information sont en manque d’outil pour évaluer leurs actifs et leurs dépenses, comparer leurs coûts et leurs processus avec leurs pairs, montrer l’efficacité de la DSI et sa valeur ajoutée pour l’entreprise.
  • Un manque de normalisation dans le pilotage des coûts informatiques est constaté : les référentiels ne sont pas assez précis dans la méthode (COBIT, ITIL, CMMI), et les organismes abordent le sujet mais sans le normaliser.

Objectifs du modèle[modifier | modifier le code]

Les objectifs du modèle sont de positionner la DSI dans l’entreprise, de piloter les coûts et de se benchmarker grâce à un langage commun :

  • Positionner la DSI dans l’entreprise, en contribuant aux objectifs de base de la gouvernance, en améliorant le dialogue avec la direction générale et avec les directions métiers mais aussi en responsabilisant les directions fonctionnelles clientes en les refacturant. Le modèle permet en effet de calculer des coûts unitaires des services de la DSI et ainsi de refacturer aux clients la totalité des coûts informatiques à partir d’un catalogue de produits et services.
  • Piloter les coûts informatiques, autrement dit apporter plus de valeur aux métiers, mesurer la performance des processus et des activités et connaître les coûts et leurs causes. Ces éléments constituent des données de base à l’établissement du tableau de bord décisionnel comparant les indicateurs de coûts, délais et qualité.
  • Se benchmarker grâce à un langage commun, c’est-à-dire se positionner par rapport à une référence afin de s’améliorer, se comparer en toute transparence et redonner confiance par un modèle de benchmarking approuvé et utilisé.

Création du modèle de 2006[modifier | modifier le code]

Afin de documenter le modèle IGSI de benchmarking des coûts informatiques, 26 entreprises volontaires, membres du Cigref et représentant 8 secteurs différents (assurance, banque, distribution, énergie, industrie, services, services sociaux et santé et transport) ont participé au groupe de travail constitué à l’occasion de ce projet.

Les entreprises du groupe de travail ont eu un regard sur le guide tout au long de son écriture, en partageant leur expérience au travers d’interviews réalisées au cours du projet, et dont l’objectif était de pouvoir récolter des témoignages sur les attentes, les difficultés et les gains perçus dans la démarche de mise en œuvre du modèle de benchmarking des coûts informatiques.

Outre les réunions avec le groupe d’entreprises membres du Cigref, des ateliers ont été réalisés avec l'AFAI, partenaire du Cigref sur ce sujet.

Les ateliers ont été animés par Steve Gordon[3], alors chargé de mission au Cigref. Steve Gordon a également rédigé le modèle et les différents livrables publiés sur ce sujet en 2006 par le Cigref et l'IGSI.

Le modèle et son guide de mise en œuvre[modifier | modifier le code]

À la fin des travaux, le Cigref a publié un ensemble de livrables : modèle de benchmarking, guide de mise en œuvre pratique du standard IGSI[4], questionnaire de collecte de données et quelques retours d’expérience.

Le modèle a pour vocation la normalisation du reporting sur les coûts, pour répondre à la fois aux besoins des DSI et des auditeurs. Le modèle est complet dans la mesure où il part de la dépense pour aboutir au coût des services délivrés. Cette approche est souvent mise en œuvre dans le cadre de méthode d’analyse des coûts de revient de type ABC (Activity Based Costing, qui repose sur l’analyse des processus de l’entreprise et non sur l’organisation, pour mesurer les coûts). Dans ce modèle, le suivi et la projection des coûts s'effectuent selon plusieurs axes :

  • L’analyse des coûts par nature. Elle permet le contrôle des engagements, des factures fournisseurs et assure la bouclage avec la comptabilité générale.
  • L’analyse des coûts par activités, qui est nécessaire au contrôle par centres de responsabilité : centre de coûts ou centres de profit si les coûts sont refacturés aux maîtrises d’ouvrage avec un contrôle budgétaire.
  • L’analyse des coûts par prestation, qui consiste à mettre en évidence ce à quoi contribue l’informatique dans les activités de l’entreprise.

Le modèle IGSI de benchmarking des coûts informatiques a ainsi plusieurs usages : replacer la DSI dans l’entreprise, piloter les coûts informatiques et se comparer. Cependant, la mise en œuvre de ce modèle doit respecter quelques prérequis. Tout d’abord, elle doit être précédée d’une mise en place de management par processus. Ensuite, le DSI intervient comme sponsor, pour impliquer les utilisateurs dans la réussite du projet en tant que créateur de valeur. La fonction informatique joue en effet un rôle transverse de pilotage, en conciliant les priorités parfois contradictoires de la direction métier concernée, de la direction des achats et de la direction financière. Autre prérequis : l’implication des utilisateurs, dans la mesure où les directions opérationnelles doivent pouvoir construire leur propre budget et consolider les données. De fait, la mise en place du modèle ne doit pas être un projet de contrôle de gestion mais un projet d’entreprise.

Le modèle couvre les six processus suivants :

  • P1 : Mise à disposition des PC.
  • P2 : Mise à disposition des imprimantes.
  • P3 : Mise à disposition des autres périphériques.
  • P4 : Mise à disposition des applications.
  • P5 : Maintenance évolutive.
  • P6 : Projets

Le modèle décrit également une trentaine d'activités Run (réseau, support, exploitation, maintenance corrective, etc.), Build (étude, développement, pilotage de projet, etc.) et Transverses (Gestion administrative, etc.). Chaque activité peut contribuer au coût d'un ou de plusieurs processus.

Un poster de synthèse présente les différents "étages" du modèle[5].

Les cinq apports majeurs du modèle de benchmarking des coûts[modifier | modifier le code]

  • Un budget de frais par centre de responsabilité.
  • Un coût unitaire de chaque activité (développement, hot line, maintenance, etc.).
  • Un coût unitaire des produits/services fournis par l’informatique à ses clients (PC, applications, maintenance évolutive et projets, etc.).
  • Une facturation pour chaque client (optionnel).
  • La mise en évidence des éléments de benchmarking (coûts d’acquisition des PC, de traitement d’un appel, de la maintenance, de la page bureautique imprimée, du Go sauvegardé, etc.).

Modèle d'analyse et de benchmarking des coûts informatiques du Cigref (2009)[modifier | modifier le code]

Ce schéma est une représentation graphique de la méthode ABC

Il s'agit d'un modèle d'analyse et de pilotage des coûts informatiques, basé sur la méthode ABC, appliqué aux systèmes d'information. Outre le pilotage des coûts, il permet notamment de se comparer avec d'autres DSI, il s'agit là de benchmarking externe, et dont l'utilité ici est de justifier ses coûts par rapport à ceux qui sont pratiqués sur le marché, mais aussi de mesurer les coûts et les suivre dans le temps, on parle cette fois de benchmarking interne.

Le principe de cette méthode est simple : la direction du système d'information (DSI) fournit des services qui implique des activités, et dont ces activités consomment des ressources. Les ressources représentent tout ce qui est dépensé et les services sont ceux délivrés aux clients.

Le modèle suit donc la méthode Activity Based Costing (ABC) et se distingue au travers de 3 niveaux qui sont liés entre eux : le niveau des ressources, le niveau des activités et celui des services. Les services sont délivrés au travers d'activités (organisés en processus), qui engendrent une consommation des ressources représentant les différents postes du budget de la DSI.

  • Le niveau « ressources » fait appel à ce que la DSI dépense (budget).
  • Le niveau « activités » fait référence à ce que la DSI réalise (les projets, la maintenance).
  • Le niveau « services » correspond à ce que la DSI délivre (les services du catalogue).

Chaque niveau représente 100 % du budget de la DSI.

  • La DSI fournit des services formalisés au sein d’un catalogue.
  • Ces services consomment des activités.
  • La mesure de cette consommation se fait au moyen d’inducteurs qui représentent une réalité technique.
  • Ces activités, qui représentent les tâches opérationnelles des différents métiers de la DSI, consomment des ressources.
  • Ces ressources représentent les différents postes de dépenses de la DSI.

À partir de la méthode ABC, il est alors possible de déterminer un lien de causalité entre les différents postes de dépenses et ceux de services.

Le Groupe de Travail a été piloté par Alain Moustard, DSI de Bouygues Télécom. Le rapport a été rédigé par Joachim Treyer (Directeur Général du cabinet de conseil Cost House) et Stéphane Rouhier, chargé de mission au Cigref.

Le modèle a également donné lieu à la publication d'un livre[6], écrit par Joachim Treyer et Olivier Brongniart.

Analyse prospective des coûts informatiques du Cigref (2011)[modifier | modifier le code]

L'analyse prospective des coûts informatiques est un modèle qui découle du référentiel d'analyse et de benchmarking des coûts informatiques du Cigref, publié en 2009[7].

Cette méthode est basée sur une connaissance des coûts passés et ne propose pas de vision sur les coûts futurs ni même sur les possibilités de simulation de coûts. De plus, elle est complémentaire au modèle d'analyse des coûts et benchmarking dont elle se base.

L'analyse prospective s'établit en plusieurs étapes :

  • Identifier les facteurs d'évolutions majeurs à intégrer Analyse de chaque facteur structurée de la manière suivante :
  • Définition du facteur
  • Situation actuelle et tendances d'évolution,
  • Impact sur le modèle d'analyse et de benchmarking des coûts informatiques (analyse de l'impact et des zones d'influence sur la structure des coûts et temporalité de l'influence du facteur d'évolution)
  • Exemples d'applications

L'analyse prospective permet donc d'identifier 10 facteurs d'évolution des coûts IT qui doivent être pris en compte par l'entreprise lors de sa réflexion sur l'évolution de ces coûts et dont l'objectif est de permettre aux DSI de disposer d'un modèle qui puisse leur offrir la possibilité d'établir des scénarios d'évolution de leur structure de coûts.

Les 10 facteurs d'évolutions sont donc les suivantes :

  • Gouvernance du SI
  • Réglementation
  • Politique d'achat et de sourcing de la DSI
  • Évolution des technologies
  • Politique d'hébergement
  • Organisation interne du SI
  • Stratégie des Business Units
  • Écosystème IT
  • Stratégie de l'entreprise
  • Politique de sécurité et des risques

Le Groupe de Travail a été piloté par Alain Moustard, DSI de Bouygues Télécom. Le rapport a été rédigé par Alain Moustard et Joachim Treyer (Directeur Général du cabinet de conseil Cost House).

Modèle d'analyse des coûts et benchmarking (2014)[modifier | modifier le code]

Le modèle de 2009 étant déjà mis en place dans différentes structures, il a été possible de d'apporter d'autres modifications, qui ne changent en rien les finalités même du modèle[8]. Outre certaines améliorations structurelles, le modèle a été étoffé de manière à prendre en considération les évolutions en matière « d'appliances » et « as a service », en évitant les activités trop complexes qui rendent le choix d'un inducteur trop difficile et en apportant une cohérence accrue entre les activités d'infrastructure et celles d'exploitation correspondantes.

Le modèle de 2014 est donc structuré en 3 branches :

  • RUN : représentant les activités qui contribuent à la mise à disposition de services.
  • BUILD : activités liées à la mise en place de projets et activités de maintenance évolutive.
  • ENABLE : activités transverses, dites « facilitatrices », faisant référence à celles qui permettent la mise en place de services RUN et/ou BUILD.

Une codification anglaise a été créée tout en gardant les descriptions en français et en anglais, le déploiement est désormais possible à l'international.

  • La notion de « macro-activité » a été revu en permettant aux DSI d'avoir des options simplificatrices, tout en étant tournée vers le benchmark.
  • Prise en compte également des évolutions technologiques et l'apparition de nouveaux métiers.
  • Apparition de la notion de « services techniques intermédiaires ».
  • Le modèle a été étoffé de manière à prendre en considération les en matière « d'appliances » et « as a service »

Le Groupe de Travail a été piloté par Gérard Russeil, DSI de MGEN Technologies. Le rapport a été rédigé par Gérard Russeil et Joachim Treyer (Directeur Général du cabinet de conseil Cost House).

Le modèle des coûts de la production informatique du CRIP[modifier | modifier le code]

Schéma représentant la spécificité du modèle CRIP

Pour s'adapter spécifiquement aux particularités de la production IT, le CRIP et son groupe de travail « Analyse des coûts de Production » a créé un référentiel dérivé de celui créé par le Cigref, toujours basé sur la méthode ABC.

Le modèle CRIP exige un suivi plus fin des tâches opérationnelles des équipes de production mais offre aussi une plus juste imputation des coûts sur le service. Ainsi, le modèle CRIP détaille plus finement certaines activités RUN.

Le modèle CRIP se divise en deux modèles différents : un modèle d'activité basé en centre technologique et un modèle basé uniquement sur le service par catalogue de services, par typologie de service.

Modèle d'activité basé en Centre Technologiques[modifier | modifier le code]

Le modèle CRIP se base sur deux types d'activités :

  • Activité d'acquisition : coût d'acquisition et de maintien en condition (MCO) opérationnelle de la technologie
  • Activité humaine : exploitation et administration

Chaque activité est codée d'après le centre technologique auquel elle appartient. Ces codes sont regroupés dans un tableau, ainsi les codes des activités d'acquisition commenceront par INF et les codes des activités humaines commenceront par EXP. Par exemple pour une activité d'acquisition concernant "Unix Propriétaires" sera codée INFUNI.

Comme pour la méthode ABC, chaque activité est rattachée à un inducteur spécifique. Cet inducteur technique permettra d'imputer les coûts des activités sur les services avec une plus juste précision. L'inducteur pourra être unique ou partagé par plusieurs activités. Si l'on reprend notre exemple, on pourra utiliser comme inducteur le nombre d'OS exploité.

Modèle de catalogue de service par typologie de service[modifier | modifier le code]

Dans ce modèle, chaque activité peut être allouée à un service métier ou/et à un service technique. Un service métier correspond aux services spécifiques à chaque entreprise car cela représente le cœur de métier de celle-ci alors que le service technique correspond aux infrastructures mises à disposition par les DSI.

Une DSI proposant des services métiers et des services techniques impute le coût de ses activités sur les services des 2 typologies.

Ainsi, pour les infrastructures de stockage par exemple, on pourra imputer le coût soit en partie à la mise à disposition de stockage (service technique) soit directement au service métier correspondant.

Apports et limites[modifier | modifier le code]

L’utilisation d'un des deux modèles va permettre à l'entreprise :

  • De resserrer les liens avec les parties prenantes en améliorant les échanges
  • De mieux piloter ses activités
  • De formaliser un catalogue de services
  • D'introduire une logique « technique » dans l'évaluation des coûts, au travers des inducteurs d'activité
  • De simplifier la mise en place d’un modèle de facturation
  • D'obtenir des gains importants au niveau de sa profitabilité et d’améliorer ses performances
  • De pouvoir réaliser un benchmark, principalement au niveau des activités définies dans le modèle, sur la base d'un référentiel "ouvert".

Dans la mise en œuvre d'un tel modèle, les points d'attention suivants sont notés :

  • Le modèle de costing nécessite d’être simple, souple et lisible, afin de pouvoir facilement intégrer progressivement de nouveaux périmètres potentiels.
  • Le modèle de costing doit disposer d’axes d’analyse afin de permettre un meilleur pilotage économique, rendre possible le benchmark et produire un reporting adapté aux différentes populations utilisatrices ou clientes du modèle.
  • Le modèle de costing nécessite également d’être outillé, industrialisé, et adopté par les équipes.

Tutoriels pratiques[modifier | modifier le code]

Un tutoriel pratique[9] contribue à faciliter l'implantion d'un système de coûts dans les entreprises. En proposant gratuitement des requêtes RDF "INSERT" et des requêtes SPARQL, ce tutoriel est inspiré de l'ouvrage de Pierre Mévellec: "Les Systèmes de coûts: Objectifs, paramètres de conception et analyse comparée." publié chez Dunod en collaboration avec l'Ordre des experts comptables.

Notes et références[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]