COBIT : mise en oeuvre des outils informatiques (partie 2)

II – Acquire and Implement (acheter et mettre en exploitation)

Cette partie couvre les processus concernant la mise en œuvre des outils informatiques.

Notons que COBIT ne précise pas la nécessité d’un contrat entre la MOA et la MOE. Il ne mentionne pas l’importance de la MOA dans la phase de recette et d’accompagnement au changement. Il n’insiste pas sur la nécessité d’une conduite du changement et de rappels aux utilisateurs sur le bon usage du SI.

Cette partie décrit les sept processus suivants :
– Définir les solutions automatisées
– Acquérir et entretenir les logiciels applicatifs
– Acquérir et entretenir la plate-forme technique
– Permettre l’exploitation et l’utilisation
– Gérer les achats
– Gérer les évolutions
– Installer et recetter les solutions et les changements

1) Définir les solutions automatisées : il s’agit d’équiper les agents opérationnels en outils automatiques et de fournir des indicateurs de contrôle aux managers opérationnels. Pour cela, il faut trouver des solutions faisables et économiques : cela suppose des études de faisabilité.

COBIT ne mentionne pas le besoin d’une réflexion sur le travail des agents opérationnels : elle est pourtant nécessaire pour délimiter le contour de l’automatisation. L’analyse des risques est ici limitée au SI : les risques considérés sont ceux qui concernent la qualité des données, la sécurité, la conformité à la réglementation, et non ceux qui concernent le fonctionnement de l’entreprise : conséquences d’une panne, d’un défaut de mise à jour etc.

Les décisions sont prises par le « business sponsor », personnage qui n’a pas été défini jusque-là mais qui est sans doute le MOAS. Le « business manager » formule des recommandations, sans doute d’agit-il du MOAD.

Lorsque l’on est au stade « managed and measurable » de la maturité, l’entreprise fait une veille SI ainsi qu’une veille technologique, et elle dispose d’une méthode d’étude et d’évaluation des solutions.

2) Acquérir et entretenir les logiciels applicatifs : il s’agit ici de rédiger les spécifications (générales, détaillées puis techniques), de définir les habilitations et règles de sécurité, d’intégrer les acquisitions sur la plate-forme de l’entreprise, de réaliser ou faire réaliser les logiciels spécifiques, d’assurer le suivi de la réalisation et des modifications des exigences, de mettre en place la gestion de configuration et la maintenance.

Lorsque l’entreprise est immature, ses décisions ne font que répondre aux propositions des fournisseurs. Les projets sont conduits un par un et il en résulte une architecture d’ensemble incohérente. Dans les entreprises plus avancées la maintenance pose encore souvent problème. Les méthodes existent mais comme elles sont trop rigides elles ne sont pas exactement appliquées. Lorsque les entreprises sont mûres, les méthodes sont bien adaptées et bien appliquées.

3) Acquérir et entretenir la plate-forme technique : il s’agit de fournir à l’entreprise une plate-forme matérielle et logicielle convenable en regard des besoins des applications et de l’état de l’art technique. Cette plate-forme doit pouvoir satisfaire les besoins applicatifs connus et elle devra dans le futur satisfaire les besoins que l’on anticipe ; elle doit être convenablement dimensionnée (taille des processeurs et des mémoires, débit des réseaux) et mettre en œuvre des solutions d’architecture bien choisies : bref, il faut qu’elle soit convenable au plan qualitatif comme quantitatif.

Elle doit comporter les outils de contrôle et de sécurité et les responsabilités doivent avoir été définies. Son entretien doit être assuré. Elle doit comporter un environnement pour tester les modifications qui lui sont apportées. Elle doit être équipée d’une gestion de configuration.

Lorsque l’entreprise est immature, les décisions concernant la plate-forme sont prises au coup par coup, et les tests (si l’on peut dire) sont réalisés « à chaud » – c’est-à-dire que l’on découvre les problèmes lors de la mise en œuvre.

4) Permettre l’exploitation et l’utilisation : il s’agit dans ce processus de documenter les applications afin de former les exploitants comme les utilisateurs.

Il faut documenter tous les aspects : technique, opérationnel, niveaux de service.

Tous les aspects, c’est évidemment trop dire puisque toute documentation doit être sélective. La diversité des destinataires de la documentation suppose une segmentation de cette population et une activité éditoriale gérant une dissémination sélective.

COBIT ne considère que le transfert de connaissances relatif au SI, aux applications ; or il convient de considérer aussi le processus de production que le SI outille, et les connaissances doivent porter autant sur l’organisation du travail humain que sur le fonctionnement du SI.

Les applications et les solutions techniques doivent être intégrées sans couture dans les processus de production.

Cette dernière phrase est importante mais elle est énoncée incidemment. Elle implique que les diverses applications soient appelées par l’IHM en fonction des besoins de l’utilisateur, sans que celui-ci ait à se connecter/déconnecter ni à faire des doubles saisies. L’expression « sans couture » suppose ainsi que le Graal du SI ait été atteint : chaque utilisateur dispose sur son écran-clavier, à chaque instant, des données, espaces de saisie et commandes dont il a exactement besoin.

L’entreprise sans maturité en est au stade de la documentation sur papier, peu commode et non à jour. Lorsque la maturité croît, l’entreprise met la documentation sur l’Intranet et la formation est organisée. Si elle s’améliore encore, elle recherche le feedback des utilisateurs et met en place une gestion automatisée de la documentation.

COBIT situe au niveau 5 la mise en œuvre de workflows et la tenue à jour de la documentation : elles devraient être assurées dès le stade « managed and measurable ».

5) Gérer les achats : il s’agit d’équiper le SI d’une direction des achats. Elle y appliquera la politique de l’entreprise en matière d’achats, gèrera les contrats avec les fournisseurs, les droits de propriétés sur le logiciel et contrôlera la qualité des fournitures (développements et infrastructure).

Si l’on progresse dans l’échelle de maturité la DSI commence par gérer les achats au coup par coup, elle se concentre sur les gros achats ; ensuite elle assure une politique d’achats semblable à celle de l’entreprise et elle gère les contrats, enfin elle gère dans la durée la relation avec les fournisseurs.

6) Gérer les évolutions : il ne s’agit pas de la « gestion du changement », qui concernerait aussi l’organisation du travail humain, mais de la gestion des évolutions du SI interne à la DSI. Il s’agit donc de documenter, autoriser, suivre et faire connaître les changements techniques.

Lorsque l’entreprise n’est pas mûre, la gestion de configuration est souvent trop négligée.

7) Installer et recetter les solutions et les changements : ce processus concerne les opérations de recette, d’essai sur site pilote et de déploiement d’un nouveau produit.

Il faut un « plan de test », qui définisse le site de test et le cahier de recette, et un plan de déploiement. L’environnement de test est un atelier qui utilise une génération artificielle de données ou un site pilote utilisant de vraies données. Il faut prévoir la migration des données, l’interfaçage avec les autres outils et l’intégration dans le SI.

Les tests comportent deux étapes, technique et fonctionnelle. Puis il faut procéder au déploiement et à la mise en place. Enfin le nouvel outil doit être soumis à une gestion de configuration.

III – Deliver and support (produire et gérer le service)

Cette partie couvre les treize processus suivants :
– Définir et gérer les niveaux de service
– Gérer les services fournis par l’extérieur
– Gérer les performances
– Assurer la continuité du service
– Assurer la sécurité du SI
– Identifier et imputer les coûts
– Former et entraîner les utilisateurs
– Gérer les incidents et le service desk
– Gérer la configuration
– Gérer les problèmes
– Gérer les données
– Gérer l’environnement physique
– Gérer l’exploitation

Que la partie « deliver and support » soit dans COBIT la plus détaillée, c’est une excellente chose : on a trop tendance, lorsqu’on pense à la qualité d’un SI, à se focaliser sur les projets et à négliger l’exploitation et l’utilisation.

1) Définir et gérer les niveaux de service : ce processus concerne la qualité du service rendu aux utilisateurs, les « service level agreements » etc.

Le SLA doit être défini en fonction des exigences et associé à un OLA (« operating level agreement ») qui précise le niveau que doivent atteindre les services techniques en vue de répondre aux SLA (on pense ici au débit des réseaux, à la dimension des mémoires etc.). Le suivi des SLA doit faire apparaître les tendances en cours.

Dans les entreprises immatures, le reporting sur les niveaux de service est souvent incomplet, non pertinent ou fallacieux (on pense ici à ces rapports qui font apparaître le pourcentage de temps CPU disponible mais n’informent pas sur la qualité du service de bout en bout). Lorsque l’entreprise est mûre, la satisfaction des utilisateurs est évaluée périodiquement et les mesures de performance reflètent les besoins des utilisateurs plutôt que les buts propres au SI.

2) Gérer les services fournis par l’extérieur : il s’agit ici de documenter les relations avec les fournisseurs, de gérer les risques (engagements de confidentialité, pérennité du fournisseur et du produit, pénalités etc.) et de mettre en œuvre un suivi de la performance des fournisseurs.

Les entreprises immatures ne gèrent pas les fournisseurs, n’introduisent pas d’obligation de reporting dans le contrat etc.

3) Gérer les performances : ce processus concerne la physique du SI. Il s’agit de le mettre en mesure de fournir la charge de travail anticipée, de minimiser le risque de blocage, de gérer la pénurie en cas de sous-capacité (prioriser les tâches, tolérance de faute, allocation de ressources). Toute panne doit faire l’objet d’un rapport se concluant par des recommandations.

Dans les entreprises immatures, la mesure des performances considère les besoins du SI et non ceux des utilisateurs.

4) Assurer la continuité du service : il s’agit d’assurer une exploitation en continu minimisant le risque de panne sur les fonctions cruciales.

Le service que l’on considère ici est celui qui est rendu de bout en bout à l’utilisateur final : on considère donc l’enchaînement des serveurs, réseaux, applications et postes de travail et non le seul fonctionnement de la CPU. Il faut prévoir une gestion de crise en cas d’incident et des solutions de repli ; il faut identifier les fonctions à restaurer en priorité, les classer selon la durée de panne tolérable ; le dispositif doit faire l’objet de tests périodiques, les personnes qui en sont chargées doivent être formées ; des plans d’action doivent avoir été préparés pour faire face aux diverses situations de crise, un back-up des ressources critiques doit être prévu sur un autre site. Le responsable est le directeur de l’exploitation.

5) Assurer la sécurité du SI : on doit trouver à l’intérieur de la DSI une équipe spéciale chargée de la sécurité. Elle met en œuvre un plan de sécurité. Elle définit la gestion des identifications et habilitations, détecte les attaques, documente les incidents, assure le chiffrement, met en œuvre les antivirus, firewalls et autres outils de protection. Elle protège les données sensibles.

6) Identifier et imputer les coûts : il s’agit ici d’évaluer le coût du SI et de l’imputer aux utilisateurs. Une fonction de coût du SI doit être établie.

Connaître la fonction de coût du SI suppose (mais COBIT ne le dit pas clairement) que l’on sache relier ce coût au volume des unités d’œuvre qu’il fournit, ce qui implique de savoir définir ces unités d’œuvre.

COBIT dit qu’il faut savoir ventiler « de façon équitable » les dépenses du SI pour les faire porter par les entités utilisatrices, mais il ne mentionne pas les pièges que comporte une telle ventilation. Si en effet certaines des dépenses sont clairement imputables à des services de l’entreprise, d’autres correspondent à une infrastructure que se partagent plusieurs services et la clé de ventilation que l’on utilisera pour en répartir le coût sera toujours arbitraire, donc péniblement négociée et susceptible en outre d’avoir des effets pervers.

Il ne suffit donc pas de dire « un processus d’affectation des coûts aux divers services utilisateurs a été défini » : encore faut-il qu’il soit convenable, et qu’il n’entraîne pas d’effet pervers [6].

Une bonne règle pourrait être de ne faire supporter à chaque service que les coûts qui résultent de ses propres décisions. Cela conduit en pratique à ne lui imputer que les coûts affectables sans ambiguïté ainsi que le coût marginal de l’infrastructure et des services transverses, le coût fixe, lui, devant être imputé à la DG.

7) Former et entraîner les utilisateurs : COBIT recommande de distinguer des segments différents dans la population des utilisateurs.

C’est une excellente chose : les divers segments d’utilisateurs n’ont pas les mêmes besoins en information et en formation. Mais COBIT ne dit pas comment on peut réaliser cette segmentation.

Il s’agit de former le personnel en tenant compte des besoins de l’entreprise, de ses valeurs, du contenu du SI (infrastructure et applications), des besoins de compétence et des méthodes de formation (cours magistral, Intranet etc.).

COBIT ne mentionne pas la nécessité d’élucider les processus de l’entreprise ; il n’évoque pas la contrainte de synchronisme entre le déploiement d’un nouvel outil et la formation, le besoin de piqûres de rappel, les apports de l’Intranet et de la GED en complément du service desk téléphonique.

Dans les entreprises mûres, les managers se forment en même temps que les agents opérationnels.

8) Gérer les incidents et le service desk : il s’agit de fournir un dépannage en cas d’incident. Le service desk reçoit les appels téléphoniques et les oriente vers l’équipe compétente. Il assure la traçabilité de la réponse à l’incident.

En cas de difficulté particulière, il enclenche une démarche d’escalade et met en place, s’il le faut, des procédures de contournement. Des statistiques sont produites sur la qualité et le délai de la résolution des incidents.

9) Gestion de configuration : il faut établir un référentiel du matériel, du logiciel, des paramètres, de la documentation, comportant des identifiants, des numéros de version, des détails sur les licences etc. Ce référentiel doit être tenu à jour et être utilisé pour prévenir la mise en place de logiciels non autorisés. Une procédure doit être mise en œuvre pour vérifier sur le terrain son exactitude.

10) Gestion des problèmes : par « problème », COBIT désigne la cause d’incidents répétés. Traiter un problème, cela suppose donc que l’on ait su remonter des incidents à leur cause, et que l’on sache passer « de l’intervention du pompier à l’amélioration du fonctionnement de l’entreprise » (p. 140).

11) Gestion des données : il ne s’agit pas ici de l’administration des données, qui traite de la sémantique, mais de la gestion physique des données : back-up et restauration des données, disponibilité, dispositifs de saisie et traitements, sécurité etc. On considère ici le stockage, l’accessibilité, l’archivage, le back-up et la reprise de service en cas d’incident.

12) Gestion de l’environnement physique : il s’agit de la gestion des locaux, des accès (périmètre de sécurité), de l’alimentation électrique et télécoms, des risques sismiques etc.

13) gestion de l’exploitation : on considère ici la chorégraphie des opérateurs, la supervision de la plate-forme, etc. Le passage des consignes d’une équipe à la suivante doit avoir été organisé.

COBIT n’évoque pas les alertes que la supervision peut utilement envoyer aux utilisateurs pour éviter les mauvaises pratiques ou prévenir les incidents : taux d’encombrement des espaces disques, des réseaux etc.

(6) Il arrive qu’une direction de l’entreprise refuse une décision qui serait rentable parce que les règles de la comptabilité analytique conduisent à lui en imputer le coût.

Lire la première partie de l’article 

Lire la troisième partie de l’article

Michel Volle
Source : www.volle.com

COBIT : mise en oeuvre des outils informatiques (partie 2)