Aligner la gouvernance des systèmes d’information sur la stratégie de l’entreprise
Une bonne gouvernance est un gage pour une contribution optimale des systèmes d’information (SI) aux performances globales de l’entreprise. Pour les utilisateurs des systèmes d’information et leurs représentants les directions des métiers de l’entreprise, la gouvernance des SI est ce qu’est la gouvernance d’entreprise pour les actionnaires et le conseil d’administration d’une entreprise : elle est un dispositif de direction et de contrôle des SI qui concilie au mieux l’efficacité de la gestion d’une part et les intérêts, besoins et sécurité des utilisateurs d’autre part.
Une synthèse de la gouvernance de SI actuelle
En 2005, le sujet était suffisamment d’actualité pour que l’Association française de l’audit et du conseil1 et le Club informatique des grandes entreprises françaises2 publient un document jetant les bases d’une bonne gouvernance de SI [1]. Depuis, principes d’organisation pour les uns, normes ou bonnes pratiques soutenues par des outils logiciels ad hoc pour certains ou dispositifs relationnels pour d’autres, la gouvernance a été mise en œuvre sous de nombreuses variantes.
En premier lieu, les effets de la gouvernance sont visibles par l’organigramme3 de son bras exécutif, la direction des systèmes d’information (DSI). Ainsi, une DSI d’une grande ville4 sera composée de deux sous-directions : la sous-direction du développement et des projets responsable du patrimoine applicatif et de la réalisation des projets qui compte cinq « bureaux » : ressources humaines, achat et finances, projet de l’habitant, projets patrimoniaux et géographiques, projets de l’informatique communicante et des nouveaux médias et la sous-direction de la production et des réseaux, responsable pour sa part de l’équipement des services, de l’ingénierie des réseaux et de l’exploitation informatique (figure 1).
Cette forme organisationnelle est couramment décidée par les directeurs informatiques car elle reflète en effet un double impératif : assurer une bonne écoute des directions métiers afin de leur fournir les projets qui les aideront à remplir leur mission, et prendre en compte le cycle de vie imposé par les technologies de l’information afin d’optimiser l’emploi des ressources opérationnelles informatique
En faisant coller au plus près son organisation avec celle de l’entreprise, le directeur informatique prépare la mise en œuvre des dispositifs de pilotage avec les directions métiers des différents projets inscrits au schéma directeur informatique. Dans notre exemple5, il aura affaire avec la direction des finances, la direction du patrimoine et de l’architecture, la direction des affaires scolaires et la direction de la voirie et des départements, et les projets seront les applications d’élaboration et de passation des marchés publics, de gestion des opérations d’investissement, de recensement des besoins et des achats, des commandes et des stocks et de la gestion des interventions de maintenance de la ville, les directions métiers.
Redevable vis-à-vis de l’entreprise des performances de sa direction, le directeur informatique déploie les bons processus, compétences et outils informatiques dans l’ensemble de son organisation. Si une politique de certification qualité est poursuivie par son entreprise, il pourra rechercher une certification ISO 9 000 pour sa propre direction. Il peut également s’inspirer de recueils de pratiques de gestion informatique publiés par différents organismes et que l’on a vu apparaître depuis quelques années sous l’appellation de « best practices ». Certes, le terme autoproclamé « best practices » peut faire sourire. Néanmoins certaines peuvent être le fruit d’une expérience cumulée depuis de longues années ou d’une recherche approfondie.
Publié par l’IT Governance Institute, le Control Objectives for Information and Related Technology (COBIT6) adresse les moyens pour assurer et contrôler l’alignement des systèmes d’information sur la stratégie et l’organisation de l’entreprise.
En matière de développement logiciel, on peut citer le Capability Maturity Model Integration (CMMI7) conçu au sein de la prestigieuse Carnegie Mellon University ; l’architecture de systèmes d’information sera traitée par The Open Group Architecture Framework (TOGAF8) développé initialement par le US Department of Defense (DoD) en 1995. Pour la production informatique, ce sera l’Information Technology Infrastructure Library (ITIL9) née dans l’administration anglaise dans les années 1990 ; pour gérer le cycle de vie des fournitures externes, on pourra s’appuyer sur une pratique émergente, l’eSourcing Capability Model for Client (eSCM-CL) développé également par Carnegie Mellon University ; enfin pour la sécurité, on consultera la norme ISO 17 799. Par exemple, grâce à ITIL, les équipes de la sous-direction de la production et des réseaux disposent d’une base de modèles de processus éprouvés, gestion des incidents, gestion des changements (informatiques), gestion des mises en production, gestion de la disponibilité, gestion de la capacité, etc., qu’il leur appartiendra d’adapter à leur contexte particulier
Ces pratiques sont loin d’être figées et poursuivent un développement analogue à un logiciel10. Certaines ont même débordé de leur domaine initial pour envahir celui de leurs consœurs jusqu’à pouvoir prétendre couvrir tous les domaines de mise en œuvre de gouvernance de SI.
Dès lors, il a été nécessaire de réaliser des rapprochements pour orienter les entreprises utilisatrices et prestataires [9]. Néanmoins, en considérant les domaines historiques respectifs des six pratiques, nous pouvons tenter de les positionner dans une chaîne de valeur unique11 (figure 2).
Structurée et munie de bonnes pratiques, la DSI est prête à assurer la conformité fonctionnelle des applications aux besoins des directions métiers ainsi que leur disponibilité et leur sécurité.
Régimes transactionnels de gouvernance de SI
Si l’on en croit une étude du Cigref réalisée avec McKinsey en 2004 [2], le directeur informatique (DI) et les directeurs métiers (DM) ont pris conscience de leur nécessaire complémentarité qui permet à l’entreprise d’être plus productive, réactive ou innovante. Aussi, une mesure de bonne gouvernance est de prévoir différents lieux de concertation où le directeur informatique pourra échanger avec les directeurs métiers sur des points essentiels du cycle de vie des systèmes : comité de portefeuille de projets et du patrimoine applicatif, comité sur la sécurité, comité sur la qualité de service, comité technologique.
Or une bonne communication n’emporte pas un bon partage des responsabilités, ce qui est une opération tout autrement délicate : la relation DI/DM n’est pas un long fleuve tranquille et « leur couple ne tient qu’à la présence d’un chaperon de luxe : la direction générale qui, maniant carotte et bâton, surveille (…) la bonne avancée de certains systèmes d’information jugés stratégiques » [4]
Par exemple, si l’on se penche sur les spécifications d’une application métier, on peut se poser deux questions, l’une sur le moment de leur acceptation – avant ou après la décision d’investissement, et l’autre sur leur porteur -, le directeur informatique ou le directeur métier.
Notre expérience dans une branche particulière des systèmes d’information, les télécoms d’entreprise [6] [7], nous a amenés à identifier plusieurs cas de figures qui depuis semblent se révéler également pertinents pour l’ensemble du système d’information.
Lorsque l’entreprise recherche une productivité accrue, les spécifications sont réalisées avant la décision d’investissement et sont portées par le directeur informatique, celui-ci livrant des services qui, partagés entre différentes directions métiers, sont à même de générer des effets d’échelle. Lorsque l’entreprise souhaite augmenter sa réactivité face aux variations de la demande, elles sont également réalisées avant la décision d’investissement, mais sont portées par la direction métier la plus directement touchée par les variations qui dès lors définit un système laissant une large part à ses besoins spécifiques. Enfin, si l’on poursuit des opportunités d’innovation, les spécifications seront réalisées postérieurement à la décision d’investissement et seront portées conjointement par l’ensemble des parties afin d’assurer une bonne mobilisation des connaissances de part et d’autre.
Il reste à mettre en place des dispositifs pour maintenir une solidarité entre les différentes parties en dépit des responsabilités ainsi tranchées. On prévoira ainsi des conditions d’utilisation des services partagés, on assurera un consensus sur la prévision des besoins lors de l’ingénierie d’un système spécifique et on s’entendra sur un partage de connaissance dans le dernier cas. Nous désignons respectivement ces différents dispositifs par User Level Agreement (ULA), Traffic Level Agreement (TLA) et Knowledge Level Agreement12 (KLA).
Ainsi nous sommes amenés à établir différents régimes transactionnels13 (Balanced Level Agreement12) :
• la souscription de services partagés spécifiés par la DSI,
• la maîtrise d’ouvrage d’un système privé virtuel spécifiée par la direction métier prioritaire,
• l’alliance au sein d’une entité ad hoc où les enjeux et les risques sont partagés entre la DSI et le(s) direction(s) métier(s) que nous désignons par Opérateur privé virtuel (Virtual Private Operator12) de services.
Architecture et urbanisme transactionnel
Les Balanced Level Agreement remettent au centre de la gouvernance l’essence de la relation entre la DSI et les directions métiers (voir tableau).
De nature contractuelle, leur logique renouvelle les mises en œuvre de la gouvernance. Jusqu’à présent, la relation entre la DSI et une direction métier porteuse d’un projet était actualisée en fin de cycle lors de la phase d’élaboration du contrat de service qui intervient après la phase de spécification-conception du système d’information.
Les BLA permettent d’aborder dès la phase de l’architecture d’entreprise14 la problématique des modalités de coopération entre les différentes parties selon les différents projets. Parallèlement à l’architecture d’entreprise et à l’urbanisme d’entreprise, on élabore dans le champ relationnel une opération équivalente, que l’on peut appeler architecture et urbanisme transactionnel, que nous désignons par Balanced Level Sourcing12 (BLS) (figure 3).
Une gouvernance des systèmes d’information renouvelée
En établissant un lien entre les objectifs stratégiques de l’entreprise et les modalités de coopération entre les directions métiers et la DSI, l’architecture et l’urbanisme transactionnel (Balanced Level Sourcing) constituent une nouvelle15 approche de gouvernance de systèmes d’information. Leur mise en scène dans des modèles d’organisation des systèmes d’information pour les adapter à la nature des objectifs recherchés (effets d’échelle, time to delivery, innovation) peut aider à une meilleure collaboration et mobilisation des différentes directions, et finalement, une meilleure performance économique globale.
___________
1. www.afai.fr
2. www.cigref.fr. Le Cigref regroupe 120 des plus grandes entreprises utilisatrices des technologies de l’information.
3. Ainsi que par les titulaires des principaux postes.
4. Ville de Paris, source : Bulletin municipal officiel de la Ville de Paris, 7 novembre 2006.
5. Source : Bulletin municipal officiel de la Ville de Paris, 10 novembre 2006.
6. COBIT est une marque déposée par l’IT Governance Institute (ITGI).
7. CMMI est une marque déposée par Carnegie Mellon University.
8. TOGAF est une marque déposée par The Open Group.
9. ITIL est une marque déposée par l’Office Government of Commerce, UK (OGC). ITIL a donné naissance à la norme BS 15 000 puis ISO 20 000.
10. Ainsi COBIT en est à la version 4.
11. On aura reconnu la chaîne de valeur de M. Porter [10]. Néanmoins, la nôtre en diffère notamment par deux points : aux activités primaires et support du modèle initial, on a ajouté en amont de la chaîne des activités au cœur de la gouvernance ; les activités de support deviennent des activités transverses autant génératrices de valeur que les activités primaires que sont le développement applicatif et la fourniture-production de services.
12. Marque déposée, également protégée par les droits d’auteur.
13. Dans un article précédent portant sur la stratégie de sourcing externe [8], nous avons utilisé le terme « régime contractuel ».
14. L’architecture d’entreprise a pour objet la projection des différentes ressources qui composent le corps de l’entreprise sur un modèle de processus (process model). L’urbanisme a pour objet de préparer la disponibilité des différentes composantes du SI (modules applicatifs, serveurs, réseaux…) qui constitueront les différents systèmes soutenant ce modèle de processus. Un alignement des SI avec les affaires de l’entreprise se concrétise en un alignement de l’urbanisme de SI avec l’architecture d’entreprise [5].
15. On voit apparaître depuis peu une approche complémentaire qui s’attache à différencier les rôles tenus par les directeurs informatiques au-delà de la typologie classique « directeur informatique », « directeur des systèmes d’information », « Chief Information Officer » [3].