Qui va garder le chien ?

Il y a ensuite des questions sur lesquelles les acteurs ont un avis. Par exemple, le rattachement hiérarchique du RSSI (dans la DSI ou pas?), le pouvoir de blocage du RSSI dans un projet (pouvoir absolu ou simple avis dans la prise globale de décision?). Il en va de même d'ailleurs pour les contraintes CNIL, les aspects juridiques, etc. Tout est affaire d'arbitrage en ce bas monde, là plus qu'ailleurs.

Il est ensuite des questions sur lesquelles les interrogés avancent prudemment de peu de se faire taper sur les doigts. Les affres du décret confidentialité, le déploiement de la carte CPS dans les établissements de soins, l'avenir du DMP (non là je blague, on sait tous comment ça finira!), de la messagerie sécurisée, etc.

Et puis il est des questions pour lesquelles la majorité des parties prenantes ne sont même pas conscientes que la question existe. Par exemple, lorsque la DSI produit une prestation d'informatisation d'un service métier, le RSSI est censé sécuriser ledit processus informatisé, d'une part en sécurisant l'infrastructure (ce que l'on appelle le Plan de Secours Informatique) et d'autre part en rendant les métiers résilients à une future panne (procédures dégradée, cellule de crise, bref ce que l'on appelle le Plan de Continuité ou de Reprise d'Activité).

Mais si, globalement, le RSSI doit sécuriser les processus des métiers, qui sécurise les processus de la DSI ? Si l'on utilise la norme ABC (Activity Based Costing), ces processus se divisent en deux : les projets ou prestations de services qu'elle délivre à ses clients internes (projets métiers – le BUILD -, gestion de parc PC – le RUN - , etc.), et ses propres processus internes (circuit des demandes, traitement des incidents et des problèmes au sens ITIL du terme, etc.).

La seconde catégorie – les processus internes – fait l’objet de débats « sportifs » car de fait le RSSI se retrouve en mode ingérence vis-à-vis de la DSI qui est soit son rattachement hiérarchique, soit son prestataire maîtrise d'œuvre. Facile à dire que l'on est ITIL-compliant : dans les faits ce n'est jamais le cas : les problèmes sont rarement traités comme tels, la documentation rarement à jour, les procédures – qualification, changement, etc. - rarement respectées.

Quant à la première, la lecture d'ouvrages sur le Lean Management ou sur la théorie des contraintes (Goldratt) démontre un point indiscutable : en matière de production de services (ce qu'est la DSI au même titre qu'une usine produit des boulons ou des voitures) les informaticiens sont clairement à l'âge de pierre. Fondamentaux non respectés, notion de risque dans les projets rarement traités, voire même le simple quadriptyque projet (la gouvernance, le périmètre, les budgets et le niveau de qualité) même pas abordé. La DSI produit de l'énergie numérique pour ses clients, mais cette production en est à l'ère pré-fordienne. Qui alors doit surveiller la DSI ?