Comme la qualité logicielle dans les années 1990, après un grand essor dans les années 2000, les référentiels de bonnes pratiques se ringardisent… Pour au moins dix raisons.
Raison n° 1 : la surproduction. Après le succès et l’engouement pour les premiers référentiels très opérationnels tels que ITIL (Information Technology Infrastructure Library), une multitude de référentiels sont apparus dans les DSI : CobiT (Control Objectives for Information and related Technology), CMMi (Capability Maturity Model Integration), Togaf (The Open Group Architecture Framework), Six Sigma, ISO 27001 (pour la sécurité des systèmes d’information), eSCM (eSourcing Capability Model)…
Raison n° 2 : un socle (trop) commun. Chaque référentiel couvre des domaines et processus IT différents, mais, souvent, il y a des chevauchements.
Raison n° 3 : un enjeu commercial. La profusion de référentiels a fait les beaux jours des nombreuses associations qui se sont créées pour en assurer la promotion. Accompagnées par une multitude de consultants, des démarches commerciales sous-jacentes ont contribué à rendre ces initiatives parfois illisibles au regard de leurs objectifs initiaux.
Raison n° 4 : trop de versions. Afin de progresser et d’occuper les hordes d’experts, certains référentiels, dans leur stratégie de versionning, ont induit des chevauchements encore plus grands avec les autres référentiels (ITIL V3, CobiT V5…). Cela a engendré « une course à l’échalote » pour les DSI qui se sont lancées dans le déploiement de ces méthodes.
Raison n° 5 : une évolution limitée. Si certains référentiels souffrent d’avoir trop de versions, d’autres, au contraire, ont peu ou pas évolué (par exemple CMMi, eSCM). Résultat : les équipes de la DSI en charge des déploiements se sont assoupies…
Raison n° 6 : une internalisation des bonnes pratiques. Tous ces référentiels ont favorisé l’émergence de nouveaux experts promettant de faire mieux, moins cher et plus vite… C’est à ce moment que sont apparues, dans les DSI, de nouvelles fonctions comme directeur de la gouvernance du SI, urbaniste fonctionnel, responsable de la politique de sourcing, pilote de processus SI, etc …
Raison n° 7 : une complexité accrue. Malgré la promesse initiale pour les DSI d’atteindre l’excellence opérationnelle, les référentiels ont souvent eu l’effet inverse, en complexifiant les processus SI, en amenant une certaine rigidité dans les relations avec les métiers et en occasionnant délais et coûts supplémentaires.
Raison n° 8 : un besoin d’agilité incompatible avec la rigidité d’un référentiel. Pendant que les DSI déployaient les référentiels dans leurs organisations, ils n’ont pas tous vu que le concept d’agilité devait impérativement devenir une réalité… au risque de voir les DSI comme un service support et non comme un créateur de valeur !
Raison n° 9 : un pouvoir attractif d’autres approches. C’est à ce moment que les directions métiers se sont appropriées de nouvelles méthodes comme le « test and learn », le lean ou les développements agiles. Bien orientés par des consultants bienveillants, les métiers ont ainsi commencé à développer de nouveaux services en dehors des DSI.
Raison n° 10 : une implémentation chronophage. A l’heure où la contrainte de temps se fait de plus en plus sentir pour les DSI, la mise en œuvre de référentiels consomme des ressources et du temps. L’arbitrage leur est de moins en moins favorable.
Dès lors, faut-il pour autant ignorer les référentiels ? La réponse est évidemment non. Il est, en revanche, vain de vouloir courir après une certification qui n’a pour intérêt que de faire plaisir aux DSI et à ceux qui l’ont obtenue. De même, il convient de viser grand, mais de commencer petit et, surtout, de déployer de bonnes pratiques correspondant au contexte et aux objectifs concrets de l’entreprise. Cela sous-entend d’avoir des objectifs à atteindre et non pas l’objectif de déployer un référentiel. Il faut toujours penser que « le mieux est l’ennemi du bien ».
Enfin, il ne faut pas laisser le déploiement de bonnes pratiques à des experts du sujet qui agiraient en parallèle des activités opérationnelles, comme le responsable qualité tentait d’assurer la qualité d’un projet en son temps. Il est préférable d’associer les métiers pour les convaincre et partager avec eux l’intérêt et le mode de déploiement de la démarche. Cela signifie aussi savoir renoncer, si la valeur n’est pas démontrée à tous. Ce qui existait avant n’est donc pas à jeter… mais à utiliser différemment ! •
Cet article a été écrit par Patrick Geai, qui a été responsable des audits informatiques dans un grand groupe public.