Schéma Directeur SI : les éléments majeurs toujours oubliés

Pour certains auditeurs externes, l’absence de SDSI suffit presque à disqualifier toute maturité SI. À les entendre, ne pas en disposer reviendrait à débarquer de la planète Mars. C’est d’ailleurs assez frappant : l’existence même du document semble parfois compter davantage que sa qualité réelle, son contenu ou son caractère opérationnel. Un jour, juste pour tester, je serais presque tenté de glisser un texte sans rapport derrière une page de garde bien présentée, histoire de voir si la seule forme suffit à rassurer.

Mais là où les choses deviennent vraiment intéressantes, c’est dans la méthode de rédaction du SDSI. Si vous avez du temps et de l’argent, et de préférence beaucoup d’argent, vous pouvez toujours faire appel à des consultants généralistes. Vous obtiendrez parfois une prestation très soignée sur la forme, mais nettement moins convaincante sur le fond. Les derniers que j’ai vu passer — je tairai leur nom — appartenaient pourtant à une grande société se revendiquant d’une solide expérience dans le secteur de la santé. Ils se sont principalement contentés de recueillir les souhaits de chacun avant de les consigner dans un rapport visuellement impeccable. Et lorsqu’il a fallu aborder le volet cyber, l’approche semblait se limiter, pour l’essentiel, au choix d’un firewall. Autant dire que l’on peut légitimement s’interroger sur la valeur ajoutée réelle de ce type de prestation.

Mais revenons sur Terre. Un SDSI devrait, en principe, répondre à quelques questions simples :

• où en est-on en matière de SI ;
• quelles sont les contraintes endogènes et exogènes auxquelles l’organisation devra faire face : réglementation, enjeux sectoriels, enjeux nationaux, écosystème global, etc. ;
• où souhaite-t-on aller, malgré ces contraintes ;
• comment souhaite-t-on y aller, et avec quels moyens financiers et humains.

Que l’on fasse appel à des intervenants externes ou que l’on conduise cet exercice en interne, la production de ce type de livrable se heurte à plusieurs difficultés.

D’abord, les grands plans quinquennaux gravés dans le marbre fonctionnent mal dans un environnement aussi mouvant que celui du système d’information. On attribue souvent à différents stratèges l’idée qu’aucun plan ne survit vraiment au premier contact avec la réalité. En matière de SI, c’est assez juste : les priorités évoluent, les contraintes réglementaires changent, les risques cyber se déplacent, les budgets fluctuent, et les usages réels ne correspondent pas toujours aux intentions initiales.

Ensuite, il y a le phénomène de la lettre au Père Noël : le meilleur moyen de ne pas parvenir à faire ce que les gens veulent, c’est parfois de leur demander d’en dresser la liste exhaustive. Cette liste sera presque toujours interminable, hétérogène, insuffisamment priorisée et rarement compatible avec les moyens disponibles.

Bref, l’idée selon laquelle on pourrait figer sur un document l’ensemble de ce qui sera fait pendant les cinq années à venir au sein du SI d’une organisation paraît très fragile. L’agilité est indispensable. Dans ce contexte, le concept même de SDSI mérite d’être réinterrogé : il semble préférable de s’orienter vers un SDSI plus ciblé, régulièrement réévalué, plutôt que vers un document massif, rapidement obsolète. Cela soulève d’autres enjeux, notamment en matière de gouvernance et d’arbitrage, mais ce n’est pas le sujet principal ici.

Le point majeur que cet exercice devrait impérativement aborder peut se résumer en une phrase : définir ce qu’est une Direction des Systèmes d’Information (DSI). Cela peut paraître évident. Pourtant, dans la pratique, ça ne l’est pas toujours.

Prenons un exemple. Tous les SDSI du monde n’empêcheront pas qu’un jour, une direction métier, support ou fonctionnelle arrive dans le bureau du ou de la DSI en expliquant que l’organisation vient d’obtenir un financement auprès d’une agence quelconque, et que la DSI doit « juste » brancher trois serveurs et quatre PC sur le LAN.

Et là, le malentendu apparaît.

Cette demande revient à considérer la DSI comme un simple service de branchement, voire comme une sorte de fournisseur interne de matériel et de connectivité. Or, une DSI n’est pas là uniquement pour raccorder des équipements à un réseau. Elle met en œuvre les besoins fonctionnels exprimés par les métiers, mais elle porte aussi ses propres exigences en matière d’architecture, d’interopérabilité, de sécurité, d’infrastructure et de cohérence technique globale.

Dit autrement, connecter des serveurs à un LAN, c’est un moyen, pas un besoin. La DSI est là pour répondre à des besoins, mais les moyens techniques mobilisés pour y répondre ne peuvent pas être définis sans elle. Elle n’est pas seulement exécutante : elle est aussi garante de la cohérence, de la sécurité et de la soutenabilité du SI.

Définir ce qu’est une DSI, ce qu’elle n’est pas, ce qu’elle fait et ce qu’elle ne fait pas, c’est partager au sein de l’organisation un modèle mental commun. Faire l’impasse sur cette étape majeure revient à créer les conditions de malentendus récurrents.

Dans l’exemple précédent, imaginons que le projet implique un traitement de données personnelles sensibles. Si les rôles ne sont pas clairement définis, le service demandeur peut penser que l’ensemble des sujets de conformité relève automatiquement de la DSI. Résultat : le DPO, le RSSI, le juridique ou d’autres acteurs clés peuvent être sollicités trop tard, voire pas du tout. Ce n’est pas seulement un problème d’organisation : cela peut devenir un problème réglementaire, sécuritaire et opérationnel.

Dit autrement, un SDSI ne devrait pas se limiter à aligner une liste de projets pour les cinq prochaines années. Il devrait d’abord permettre de clarifier qui fait quoi sur le SI : qui exprime les besoins, qui arbitre, qui conçoit, qui met en œuvre, qui sécurise, qui contrôle, et selon quelles règles.

Sans ce modèle mental commun, le SDSI risque de n’être qu’un document de plus. Avec lui, il peut devenir un véritable outil de gouvernance.