Schéma directeur SI : méthode, étapes et livrables

Que doit permettre un schéma directeur ?

Le document doit permettre à la direction de choisir les transformations à engager, de comprendre leurs dépendances et de réserver les moyens nécessaires. Une liste de projets ne remplit pas ce rôle lorsqu’elle ne montre ni les problèmes à résoudre, ni les bénéfices attendus, ni les compromis retenus.

La stratégie SI exprime les orientations : simplifier les parcours clients, fiabiliser les données ou réduire une dépendance critique, par exemple. Le schéma directeur transforme ces orientations en cible et en décisions d’investissement. La feuille de route organise ensuite les travaux dans le temps. Ces trois niveaux doivent rester cohérents et pouvoir être révisés ensemble.

1. Cadrer les décisions et le périmètre

Commencez par les décisions que la démarche doit éclairer. Faut-il remplacer un logiciel, harmoniser plusieurs entités, soutenir une acquisition ou sécuriser une activité ? Précisez les métiers, les sites et les services concernés, puis désignez le commanditaire et les personnes qui arbitreront les désaccords.

Rassemblez les contraintes avant de dessiner la cible : échéances contractuelles, capacité des équipes, engagements clients et enveloppe financière. L’horizon de planification dépend des transformations envisagées. Une trajectoire sur trois ans peut être pertinente, avec un premier ensemble d’actions beaucoup plus précisément défini que les suivantes.

2. Établir un diagnostic fondé sur des faits

Interrogez la direction, les métiers, les utilisateurs et les équipes informatiques. Croisez leurs observations avec les incidents, les coûts, les contrats et les applications réellement utilisées. Distinguez les faits vérifiés, les perceptions et les informations encore manquantes.

La cartographie doit servir les décisions du périmètre : quels processus dépendent de quelles applications, quelles données circulent et quels composants deviennent des points de fragilité ? Il est rarement nécessaire de tout décrire au même niveau de détail. Un irritant isolé ne mérite pas automatiquement un projet de remplacement.

3. Décrire la cible et comparer les scénarios

Décrivez les capacités attendues et les principes de fonctionnement avant de sélectionner des produits. Pour un même besoin, plusieurs options sont possibles : améliorer l’existant, remplacer une application, mutualiser un service ou externaliser une activité.

Comparez les options selon les mêmes critères : valeur métier, coût complet, faisabilité, risques, dépendances, réversibilité et délai. Documentez aussi l’option de maintien de l’existant. Elle permet de mesurer le coût de l’inaction et d’éviter qu’un projet soit retenu uniquement parce qu’il paraît nouveau.

4. Construire une trajectoire réalisable

Pour chaque initiative, identifiez un responsable, les résultats attendus, les prérequis, la charge et les coûts de transition. Les dépendances imposent parfois de traiter la qualité des données ou les interfaces avant de déployer un nouvel outil. Le planning doit aussi préserver l’exploitation quotidienne et la capacité des métiers à absorber le changement.

Exemple fictif : une PME veut fiabiliser ses commandes. Elle commence par clarifier la responsabilité des données clients et corriger les doublons. Elle simplifie ensuite les échanges entre la vente et la gestion, puis déploie le nouveau parcours. L’indicateur suivi est le taux de commandes nécessitant une reprise manuelle ; la seule mise en production du logiciel ne suffit pas à constater un bénéfice.

Les livrables à faire valider

La validation doit porter sur des choix explicites, avec leurs conditions de réussite. Faites vivre le schéma directeur au rythme des décisions importantes et des changements de contexte. Une présentation approuvée une fois puis oubliée ne constitue pas un pilotage de la transformation.