La question « pourquoi le SI coûte-t-il si cher ? » soulève un ensemble d’interrogations connexes sur la nature, la maîtrise, la mesure et la valeur du système d’information. Dans les faits, il représente une part importante des dépenses de l’entreprise, croissante dans de nombreuses industries. Il est perçu comme trop cher car la valeur qu’il produit est difficile à appréhender. Dans une grande entreprise d’un secteur de services tel que la banque, l’assurance ou les télécommunications, les logiciels accumulés représentent plusieurs centaines de millions d’euros. Ils sont mesurés en utilisant des « points de fonctions », qui sont l’équivalent abstrait, d’un point de vue fonctionnel, des composants élémentaires d’un système physique. Là où un avion moderne comporte plusieurs millions de composants (par opposition à une automobile pour laquelle on compte par milliers), les SI des grandes entreprises mentionnées comptent des millions de points de fonctions. L’essentiel des coûts du SI est directement lié à cette mesure, qu’il s’agisse de coûts d’acquisition du logiciel (de l’ordre de 200 euros par point de fonction) ou de coûts d’exploitation (représentant environ 15 % des coûts d’acquisition).

 

Trouver la taille idéale

 

Le SI n’est pas mesuré. La mesure du parc applicatif est peu effectuée et, même lorsque cet effort de mesure en points de fonction des applications déployées est réalisé, il est le plus souvent approximatif. Il n’est pas de progrès, ni même de maîtrise, sans mesure.

Il est souvent « mal gouverné » dans le sens où les « conseilleurs ne sont pas les payeurs ». Ce n’est pas la DSI qui choisit le parc applicatif, mais c’est souvent à elle que l’inflation des coûts est reprochée. S’il est judicieux de fixer des objectifs à la DSI sur ses coûts par unité d’oeuvre (produire un point de fonction, exploiter une transaction par minute de type commercial –  TPMC), les coûts induits par le nombre d’unités d’oeuvre doivent, eux, être placés sous la responsabilité de ceux qui les demandent.

Le SI n’est pas assez nettoyé (voire pas nettoyé du tout). Pourtant une application sous-utilisée ou mal utilisée coûte presque aussi cher qu’une application « populaire ». Certes, l’accumulation de générations de logiciels est un véritable casse-tête, mais le nettoyage est également une discipline
exigeante et difficile.

 

Tenir compte du niveau d’exigence

 

A priori, les coûts d’un projet informatique sont fonction de deux facteurs : le poids fonctionnel du projet, que l’on mesure précisément avec des points de fonction, et les exigences « non fonctionnelles » (un terme du jargon informatique qui signifie que l’on ne s’intéresse pas à ce que le logiciel fait, mais à la façon dont il le fait). Ces exigences sont déterminantes dans le coût des projets, ce qui a été établi scientifiquement par la méthode Cocomo II1. C’est la première cause d’incompréhension des coûts de la DSI. Nous avons tous déjà entendu un avis du type : « Je ne comprends pas, la DSI réclame 100 000 euros pour faire un projet qu’un stagiaire pourrait faire en six mois et qu’une start-up ferait pour 20 000 euros ». Il y a de nombreuses raisons pour une telle différence de prix (et toutes ne sont pas acceptables2), mais les raisons principales sont liées aux exigences non fonctionnelles dont voici les trois plus importantes.

La disponibilité est définie par son complément : le temps maximal d’indisponibilité, qu’il s’agisse d’arrêt programmé (le soir, les week-ends) ou des incidents. La nature stratégique de l’activité du SI conduit à des exigences de plus en plus strictes (7 jous/7, 24 heures/24, disponibilité à 99,9 %, voire 99,99 %). Ces exigences ont un impact direct sur les coûts, qu’il s’agisse de matériel (la disponibilité s’obtient par leur redondance) ou de logiciel. Boehm cite des surcoûts de 30 à 50 % sur le simple aspect du développement.

La performance exigée est également un facteur important de coût, qu’il s’agisse de temps ou de capacité de traitement (par exemple, en nombre de transactions par seconde). Cette exigence va en augmentant parce que le « temps réel client » (c’est-à-dire, ne pas faire attendre le client) devient une obligation du XXIe siècle. Le SI moderne doit être le plus réactif possible pour servir la stratégie de l’entreprise. Cette demande de performance conduit à créer des surcapacités (en termes de matériel) ou à opter pour des logiciels surperformants (solutions complexes destinées à absorber des pics ou à résister aux aléas). Différentes solutions sont possibles, de la mutualisationvirtualisation au lean IT3 en passant par le cloud computing, qui ont toutes en commun une simplification de l’architecture, car la complexité est le premier ennemi de la maîtrise des performances.

L’interopérabilité consiste à pouvoir faire coopérer un élément du SI avec les autres applications ou avec d’autres SI d’entreprises partenaires. L’essor du fonctionnement en « entreprise étendue » et l’augmentation de l’interdépendance des fonctions de l’entreprise au sein des processus métiers ont très fortement renforcé cette exigence pendant les vingt dernières années. Les contraintes d’interopérabilité et les coûts associés d’intégration représentent souvent la moitié des coûts d’un projet informatique.
Beaucoup de managers se plaignent du fait qu’il faille de plus en plus de moyens, de plus en plus « de lignes de code », pour faire « la même chose qu’avant ». C’est la conséquence de l’ensemble de ces exigences, que l’on retrouve également dans le monde du logiciel grand public. Quand oncompare la version actuelle d’un éditeur de texte leader du marché avec la version d’il y a 15 ans, la différence de taille ne s’explique pas simplement par les options de l’éditeur d’équations.

 

Gérer la complexité

 

La complexité est un facteur important de coût dans les grandes organisations. C’est ce qui explique le facteur non linéaire dans l’augmentation des coûts. Si le nombre de points de fonction double, le coût augmente de deux façons : il double d’abord par effet mécanique, puis par augmentation de la complexité d’intégration de l’ensemble produit un surcoût. La résultante est une augmentation exponentielle, avec un exposant qui varie entre 1,05 dans les cas les plus favorables jusqu’à 1,4 pour des systèmes très complexes. D’où vient cette complexité et pourquoi augmente-t-elle ? On peut schématiquement identifier trois axes :

 

  • La complexité fonctionnelle, liée à la quantité de choses que fait le SI (d’où l’augmentation des points de fonction). Cette complexité augmente à la fois parce que le monde d’aujourd’hui est plus complexe (un effet de la mondialisation, de l’hypercompétition et de l’omniprésence des technologies numériques), mais surtout – c’est une remarque très pertinente de Thomas Friedman – parce que ce qui était « facile à automatiser » l’a déjà été fait et que ce qui reste est, par construction, plus complexe.
  • La complexité structurelle du SI exprime le fait qu’un « grand SI » est plus difficile à gérer que de « nombreux petits SI » (de même masse totale) à cause du niveau d’intégration nécessaire. Cette complexité se mesure (difficilement) et elle se maîtrise à travers des démarches d’architecture d’entreprise et d’urbanisation, qui ont pour but de réintroduire de la modularité dans le SI (précisément pour pouvoir le gérer comme un ensemble de modules plus petits). Cet effort d’organisation du SI est difficile et requiert la collaboration d’experts du « quoi » (les utilisateurs métiers, responsables du devenir du SI) et les experts du « comment » (les architectes du SI).
  • La complexité des processus internes de la DSI augmente malheureusement en même temps que la taille du SI. Cette complexité est visible : on assiste à une augmentation du nombre de rôles, une multiplication des étapes et des règles procédurales. On produit alors un surcoût important par rapport aux méthodes « artisanales » mises en oeuvre par des structures plus agiles telles qu’une start-up ou un développeur indépendant, au nom de l’industrialisation du développement. Cette complexité n’est pas entièrement mauvaise ; elle est née au fil des ans pour prendre en compte des exigences non fonctionnelles telles que la sécurité ou celles mentionnées plus haut. À l’inverse, il existe un facteur culturel propre aux grandes organisations qui favorise la spécialisation à outrance et qui a atteint ses limites. L’attention portée récemment aux méthodes « agiles » (et au raccourcissement de la chaîne qui va du développeur à l’utilisateur, dans un esprit de lean IT) illustre le potentiel de réduction de cette complexité.

 

Le SI est-il « trop » cher ?

 

Le SI n’est pas simplement perçu comme cher, il est souvent perçu comme « trop cher ». Le « trop » implique un jugement de valeur, qui s’appuie soit sur la valeur intrinsèque, soit sur la valeur relative. Dans le premier cas, le SI est trop cher par rapport à la valeur qu’il produit. Dans le second cas, il est trop cher par rapport à des solutions alternatives. Autrement dit, le SI est cher lorsqu’on a la conviction qu’on pourrait faire autrement. La piste « pourrait-on faire autrement ? » est riche de possibilités, en s’appuyant sur les leviers qui ont été présentés.

Peut-on réduire la taille du SI ? Assurément. Peut-on réduire les exigences non fonctionnelles dans certains domaines ? Également, mais c’est à vous de juger. Certains besoins méritent des développements « jetablesbles » à titre exploratoire. D’autres besoins sont mieux couverts par un paramétrage direct des applications par les utilisateurs. Peut-on mieux maîtriser la complexité ? Oui, surtout si on le fait de façon continue, en suivant les prescriptions du Sita4, qui prône le développement durable du système d’information. La professionnalisation et l’adoption de référentiels (Itil, Cmmi, Cobit…) augmentent-elles la complexité de fonctionnement ? Absolument pas ! Au contraire, le fonctionnement régulé par les best practices est une des armes contre la complexité, permettant d’abaisser les coûts et d’augmenter la régularité de la performance.

[quote type= »center »]Améliorer la gouvernance du système d’information[/quote]

Répondre à la question « Le SI est-il trop cher ? » demande un travail collectif extrêmement productif pour améliorer la gouvernance du système d’information. Comprendre et maîtriser les coûts du SI est l’affaire de l’ensemble des managers de l’entreprise. Cela passe en premier lieu par une réappropriation par les maîtrises d’ouvrage de leur patrimoine informatique. En bons gestionnaires, ils doivent le mesurer, l’entretenir et se poser les questions, à long terme, de développement durable de ce patrimoine.

[tabs slidertype= »top tabs »][tabcontainer] [tabtext]1.[/tabtext] [tabtext]2.[/tabtext] [tabtext]3.[/tabtext] [tabtext]4.[/tabtext] [/tabcontainer] [tabcontent] [tab]1. Cocomo est un acronyme pour Constructive Cost Model. C’est une méthode pour estimer le coût d’un projet logiciel dans le but d’éviter les erreurs de budget et les retards de livraison. Développée par Barry Boehm, elle constitue une référence en termes d’analyse de coûts de développement. Voir Software Cost Estimation with Cocomo II, Prentice Hall, 2000.[/tab] [tab]2. cf. chapitre 9 du livre Performance du SI.[/tab] [tab]3. Lire The Art of Lean Software Development: An incremental Approach de Curt Hibbs, O’Reilly, 2009.[/tab] [tab]4. On peut consulter les publications du Sita (Sustainable IT Architecture) sur www.sustainableitarchitecture.com[/tab] [/tabcontent] [/tabs]

 

[box type= »shadow »]

Comment mesurer son parc informatique ?

La mesure du parc matériel se fait essentiellement sur deux axes : la puissance de calcul et le stockage. La puissance de calcul peut se mesurer en TPMC, qui signifie transaction par minute de type commercial. La TPMC est devenue une unité standard qui permet de comparer les coûts par unité d’oeuvre, indépendamment de la technologie ou de la gamme de matériel. On trouve sur le site www.tpc.org les meilleures performances du moment (de l’ordre de 0,5 dollar par TPMC pour un coût d’achat, qui n’est pas un coût complet).

Le parc logiciel se mesure en points de fonction (également appelés points-fonction), qui sont maintenant établis comme la meilleure unité de mesure, reconnue par l’ISO. Le calcul exact peut s’avérer fastidieux et le calcul effectué au moyen de taux de conversion à partir de la mesure du nombre de lignes de code source
reste approché (différente mesures pouvant conduire à des résultats quelque peu différents). Cependant, la mesure en points de fonction a le très grand mérite d’obtenir un résultat indépendant des technologies, pour lequel le benchmarking est possible et intéressant. [/box]

 

[learn_more caption= »en savoir plus »]

Performance du Système d’Information – Analyse de la valeur, organisation et management, Yves Caseau, Dunod, 2007, prix de l’Afisi 2008. [/learn_more]

Ce post est une reproduction d’un article publié dans la revue échanges datée de janvier 2010.