Sous le microscope de la direction générale, le budget informatique est encore essentiellement un budget de main-d’œuvre. Le coût des ressources internes permanentes et des prestataires externes représente la majorité des dépenses. Baisser les coûts c’est donc avant toute autre chose réduire les effectifs internes et externes. Cette approche est désormais insuffisante.
Le budget informatique se transforme sous la poussée de plusieurs évolutions structurelles. D’une part la contribution des ressources externes tend à ne plus être comptabilisée en équivalent temps plein dès lors que le fournisseur s’engage sur un résultat, forfait ou externalisation, et non plus sur la mise à disposition de moyens. Ces prestations de service font l’objet de contrats mesurés en unités d’œuvre accompagnés d’engagements de services. Toutefois, la régression du modèle bien français de « prestation en régie » est une mutation lente, l’invention de la « régie forfaitée » traduisant la résistance du modèle.
Le second facteur est le recours désormais massif à des logiciels ou progiciels achetés pour exécuter des fonctions naguère développées en interne. Cette transformation d’un travail artisanal effectué à l’unité en interne vers une logique industrielle correspond à acheter soit des machines outils pour produire de façon efficace du code, soit des produits finis permettant sans coût de main-d’œuvre additionnel d’exploiter un code fabriqué industriellement, et donc mutualisé entre les acheteurs. Dans tous les cas le recours à des logiciels, ou progiciels, doit se traduire par un gain visible en productivité, et donc par une baisse du coût de la main-d’œuvre. La rentabilité de cet investissement doit être directement mesurable.
C’est parce que cette logique industrielle froide est loin d’être celle mise en œuvre dans la majorité des organisations qu’il est essentiel de déployer une politique spécifique de maîtrise des logiciels et progiciels. Il s’agit désormais plus d’économie que de budget, de rationalisation des usages que de technique informatique.
On peut classer les logiciels en trois catégories :
- les logiciels liés au poste de travail, système d’exploitation et outils bureautiques et collaboratifs
- les logiciels applicatifs qui permettent d’exécuter une fonction métier, gestion ou production à partir d’un serveur
- les logiciels techniques qui servent à fabriquer des applications ou exploiter les infrastructures
Le contenu en « main-d’œuvre additionnelle » est un élément clef de la rentabilité de l’utilisation de ces logiciels. Une solution apparemment attractive peut se révéler coûteuse en support, en coûts de transition et en coûts de possession. Le coût apparent d’une solution ne se limite pas à l’acquisition du produit sur étagère, mais doit intégrer tous les éléments nécessaires à son déploiement au regard de la valeur produite. Ceci se condense en deux équations :
1/ Coût total de la solution = coût d’acquisition initial + coût d’intégration technique + coûts de maintenance + coût de support (par année de vie prévisionnelle).
2/ Valeur produite par la solution = gains fonctionnels (mesurés en efficience du processus ou impact métier d’une solution nouvelle) + réduction de coût total de possession + réduction de coût de la fonction - coûts de mise en œuvre fonctionnelle
La cause est à peu près entendue pour les logiciels du poste de travail, qui ne génèrent pas de fabrication de code supplémentaire, mais seulement du service dont il faut mesurer précisément l’impact. On ne voit plus, en principe, de département informatique produire son propre traitement de texte. Les produits sont exploitables dès la sortie de leur boîte après un effort de prise en main et d’appropriation. Néanmoins il faut être vigilant sur les effets d’accompagnement de choix impactant des dizaines de milliers d’utilisateurs sur le coût de la formation et surtout sur les risques de mauvaise utilisation des outils choisis. En cas de rejet par les utilisateurs, une bonne affaire pour la direction des achats ou l’informatique peut se révéler catastrophique pour l’entreprise.
Les logiciels qui permettent de gérer une fonction métier sont des outils désormais indissociables des processus qu’ils permettent d’exécuter. Dès lors ils se confondent avec la fonction qu’ils servent. Un département d’ingénierie n’est plus concevable sans outil de CAO, un service comptable ne fonctionnera pas sans logiciel comptable ou ERP intégré. La rentabilité du déploiement de tels outils ne se mesure pas seulement en réduction du coût de main-d’œuvre informatique, qui devient accessoire, mais surtout en productivité de la fonction. La tentation est dès lors pour la DSI de déléguer, ou d’abandonner, la gestion des ces outils aux directions métiers. Dans certains cas celles-ci n’hésitent pas à s’emparer du dossier d’elles mêmes pour prendre contact avec les éditeurs en direct et acheter des solutions sur leurs budgets propres.
Ce n’est certainement pas une bonne solution. Le coût total de possession de ces logiciels métier ne se résume pas en effet à la seule facture de l’éditeur. Il faut quand même rappeler qu’un système d’information d’entreprise est un ensemble dont seule la cohérence garantit l’efficacité et surtout l’efficience. Un logiciel acheté ne peut fonctionner sans une infrastructure d’exploitation, les postes de travail, le réseau de télécommunications, les serveurs et unités de stockage. Le coût d’utilisation de cette infrastructure est souvent plus élevé que les licences. Par ailleurs un logiciel métier s’intègre dans d’autres fonctions. Ces interfaces doivent être prévues et financées. C’est comme une voiture sans route, sans carburant, sans assurance…
Il est clair que la tentation des éditeurs est de mettre en lumière les gains fonctionnels apportés par leur solution sans s’attarder sur l’analyse des impacts collatéraux, ce qui fait des directions fonctionnelles des cibles plus attentives que les DSI qui naturellement replacent le coût d’acquisition dans une perspective plus large de coût de possession pluriannuel, intégrant l’inévitable et coûteuse maintenance, et les coûts d’intégration, de montée de version et de support.
Enfin les logiciels techniques représentent un ensemble complexe et opaque dont la maîtrise est délicate. En effet ces coûts s’accumulent dans le temps au gré des décisions techniques et leur durée de vie est liée à celle des applications ou services pour lesquels ces outils se révèlent initialement associés. Ils ne sont pas toujours indispensables, remplacés au fur et à mesure de l’évolution technique par des solutions intégrées, ou simplement obsolètes.
La complexité du sujet de la maîtrise des coûts des logiciels rend absolument indispensable une ferme maîtrise des décisions. Choisir et exploiter un logiciel implique un processus de décision de même nature pour les projets applicatifs eux-mêmes d’autant plus qu’il est moins visible et que l’imputabilité est diffuse. Qui doit prendre la décision de mettre en œuvre un logiciel ? Pour quoi faire ? Puis de l’acquérir en prévoyant un nombre approprié de licences pour en optimiser le coût. Puis de l’intégrer dans le système d’information de façon cohérente ? Quand décide-t-on d’arrêter de payer la maintenance, ou de retirer un logiciel, ou encore de vérifier que tous les droits sont convenablement exploités ?
On comprend aisément que ni la DSI, ni a direction des achats, ni une direction métier ne peuvent rassembler tous les éléments de décision. Sia conseil recommande donc la constitution d’une « filière logicielle » regroupant les parties prenantes et chargée de prendre les décisions et de suivre le cycle de vie des logiciels et progiciels.
Cette entité devient dès lors un axe fort de la politique de gouvernance de l’entreprise car elle dispose d’une autorité technique et fonctionnelle qui doit s’intégrer dans un système de décision identifié et maîtrisé relevant de la direction générale. Il est évident que cette entité doit piloter également les décisions de recours à des solutions en location, comme les applications en Saas ou de « cloud computing ».
L’informatique d’entreprise a engagé une marche inexorable vers la standardisation et l’industrialisation. Comme dans tout système industriel, les coûts des composants achetés vont croître au détriment des coûts de production interne. Cette transformation ne doit pas être simplement vue comme une mutation banale, mais au contraire gérée comme une transformation substantielle de la fonction de la DSI.
Commentaires