Vous êtes dans : Accueil > Tribunes libres >

Normes et guides de bonnes pratiques en IT

Cédric Cartau, LUNDI 02 NOVEMBRE 2015 Soyez le premier à réagirSoyez le premier à réagir

Lorsque l'on s'intéresse un tant soit peu à la question des normes dans l'IT, deux choses frappent immédiatement le chercheur curieux : d'une part, le foisonnement des normes en question, et d'autre part la manifeste difficulté à les faire adopter par les DSI.  

Foisonnement tout d'abord, c'est le moins que l'on puisse dire. En vrac, et je vais certainement en oublier : la suite ISO 27000 pour la partie sécurité du SI (sans parler de la ribambelle des méthodes telles EBIOS), eSCM pour la gestion de la relation client-fournisseur, ITIL pour l'offre de services de la DSI, Théorie des contraintes(TOC) et LeanIT pour le pilotage de l'activité de la DSI, ABC pour le modèle de structure de coûts des services, COBIT pour la maturité générale et l'alignement avec la stratégie de la Direction Générale. Nous pouvons également citer la certification des comptes (CICF), la certification HAS (version 2014), sans parler des différentes normes afférentes à d'autres services tels les laboratoires (ISO 15189), mais qui comportent un volet SI dont l'importance n'ira que croissant. Et enfin l'ISO 9000, last but not least.

Alors pourquoi cette difficulté à adopter ces guides de bonnes pratiques ? L'argument des moyens nécessaires à leur mise en œuvre – donc du manque de moyens – ne tient pas dans la majorité des cas : par exemple, la check-list de mise en production (recommandation ITIL au même titre que le comité des changements) n'engendre que peu de contraintes et permet de réduire de façon drastique les incidents de production. Donc au final cela fait gagner du temps.

A cela certainement au moins deux réponses : la résistance au changement d'un secteur essentiellement technique mais sans culture du processus, et le delta entre l'activité de la DSI (qui tend vers l'industrialisation de ses processus) et les demandes des métiers (qui tendent vers le particularisme). Sur la première cause nous ne reviendrons pas, le lecteur intéressé pourra lire ou relire un de mes précédents billets sur le sujet (http://www.dsih.fr/article/1695/la-fin-du-temps-des-divas.html).

Concernant la seconde explication, force est de constater que les processus support on tous le même problème : les MOA sont toutes expertes en plomberie, en électricité, et bien entendu en informatique (« mais si voyons, je lis SVM et 01 tous les mois depuis 10 ans! ») et savent mieux que la DSI quoi faire du SI. Les MOA sont toujours d'accord, sur le principe, pour standardiser leurs processus et pour rentrer dans le moule, mais sur le principe seulement ! Dans ce contexte, difficile de se concentrer sur des méthodes et des standards quand vos clients vous tirent à longueur de journée dans la direction opposée, le particularisme et l'exception. J'ai ainsi croisé un temps un directeur des achats qui a expliqué avec forces de détail à ma DSI que l'achat obéissait à une démarche d'analyse des besoins, et qui n'a pas saisi le problème lorsqu'il a copié-collé le manuel d'utilisation d'un logiciel qu'il voulait nous faire acheter en guise d'expression des besoins. Inutile de dire que pour la personne en question, eSCM kesako ?

 

dsi, production