Un bon schéma directeur SI n’est utile que s’il aide à trancher entre continuité, modernisation et sécurité. Dans une organisation, il sert à décider quelles briques garder, lesquelles refondre, quels risques accepter et dans quel ordre exécuter les chantiers. Je vais ici aller droit au but : définition concrète, contenu attendu, méthode de construction, place de la cybersécurité et erreurs qui le transforment en document décoratif.
Les points à garder en tête avant de lancer la feuille de route
- Le document doit relier objectifs métiers, architecture cible, budget et risques dans une même trajectoire.
- Un horizon de 3 à 5 ans fonctionne bien, mais la revue doit rester annuelle et parfois trimestrielle pour les chantiers critiques.
- La cybersécurité ne se traite pas en annexe : IAM, sauvegardes, mises à jour, logs et réponse à incident doivent entrer dans la roadmap dès le départ.
- Sans sponsor, arbitrages et critères de priorisation, la démarche devient vite un catalogue de vœux pieux.
- Le bon indicateur n’est pas le nombre de slides, mais la capacité à livrer des jalons mesurables.
Ce que ce document apporte vraiment
Je définis ce document comme une trajectoire de transformation, pas comme un inventaire de projets. À l’échelle de l’État, la DINUM a la même logique lorsqu’elle élabore la stratégie numérique et pilote sa mise en œuvre : il faut un cap, une coordination et une capacité à arbitrer. Dans une entreprise, le principe est identique, même si le vocabulaire change.
Le piège classique, c’est de confondre vision, roadmap et catalogue d’initiatives. Un bon SDSI ne dit pas seulement ce qu’il faudrait faire ; il explique pourquoi, dans quel ordre, avec quelles dépendances et avec quel niveau de priorité.
| Ce que le document doit faire | Ce qu’il ne doit pas devenir |
|---|---|
| Fixer un état cible clair pour le SI | Une liste vague d’objectifs du type « moderniser » ou « digitaliser » |
| Arbitrer les chantiers selon la valeur, le risque et l’effort | Un backlog sans ordre où tout semble urgent |
| Relier la trajectoire au budget et aux capacités réelles | Un tableau financier déconnecté du delivery |
| Intégrer les contraintes de sécurité, de conformité et de résilience | Un chapitre cyber ajouté à la fin, sans effet sur les choix |
| Clarifier qui décide, qui exécute et qui arbitre | Un document sans sponsor ni gouvernance |
Je vois souvent la différence très tôt : quand un document permet de dire non à certains projets sans débat stérile, il commence à devenir utile. Quand il ne sert qu’à produire un joli support de comité, il a déjà raté sa cible. Pour qu’il reste vivant, il faut maintenant préciser ce qu’il doit contenir.
Les briques qu’il faut documenter pour qu’il serve aux arbitrages
Un SDSI solide tient sur quelques blocs lisibles. Inutile d’en faire un roman technique ; il faut surtout que chaque bloc réponde à une question de décision. Si le comité de direction ne peut pas lire ces éléments sans passer par dix explications, le document est trop abstrait.
| Bloc | Ce qu’il doit contenir | Pourquoi il compte |
|---|---|---|
| Contexte et enjeux | Objectifs métiers, contraintes réglementaires, maturité actuelle | Donne la raison du changement et évite les projets « pour faire moderne » |
| État des lieux | Cartographie applicative, infrastructures, flux, dépendances, dette technique | Montre ce qui bloque réellement et ce qui peut être conservé |
| Architecture cible | Principes d’urbanisation, standards techniques, niveaux de service attendus | Évite de recréer les mêmes silos à chaque nouveau projet |
| Trajectoire | Chantiers phasés, jalons, séquencement, dépendances | Transforme la vision en exécution concrète |
| Budget et capacité | Coûts récurrents, investissements, ressources internes, recours externes | Relie la stratégie aux moyens réels |
| Gouvernance et indicateurs | Instances, responsables, KPI, critères d’arbitrage | Permet de suivre l’avancement sans se raconter d’histoires |
Sur la partie budgétaire, je conseille de distinguer trois masses : le run pour faire tourner l’existant, les dépenses de mise en conformité et les investissements de transformation. Dans beaucoup d’organisations, je réserve au moins 15 à 20 % de la capacité de delivery à l’hygiène technique et à la sécurité, sinon la dette revient par la fenêtre. Ce n’est pas une loi universelle, mais c’est un bon point de départ pour éviter l’asphyxie.
Le point qui manque le plus souvent, ce sont les principes d’architecture. Sans eux, chaque projet négocie sa propre exception, et le SI finit en patchwork. C’est précisément là qu’une méthode de construction rigoureuse fait la différence.
Comment bâtir une trajectoire crédible sans tout figer
Je préfère une méthode simple, lisible et répétable à un grand atelier de cinq mois qui accouche d’un document parfait et inutilisable. L’objectif n’est pas de tout prévoir ; il est de poser des choix robustes et de réserver de la marge pour ce qui va forcément évoluer. En 2026, avec la pression de l’IA, du cloud, de la dette applicative et des exigences cyber, le besoin de souplesse est même plus fort qu’avant.
- Commencer par un diagnostic honnête. Cartographier les applications, les flux de données, les dépendances, les contrats, les compétences et les points de fragilité. Sans ce socle, le reste repose sur des impressions.
- Énoncer une cible claire. Je veux savoir ce qui sera standardisé, mutualisé, externalisé, refondu ou abandonné. Une cible utile tient en quelques principes lisibles, pas en trente pages d’architecture abstraite.
- Prioriser avec des critères explicites. J’utilise souvent un score pondéré autour de cinq axes : valeur métier, réduction du risque, baisse de dette technique, effort de mise en œuvre et niveau de dépendance. Les poids varient selon le contexte, mais la logique reste la même.
- Phaser en trois horizons. 0 à 6 mois pour sécuriser les fondamentaux, 6 à 18 mois pour industrialiser, 18 à 36 mois pour transformer les briques lourdes. Ce découpage donne du rythme sans verrouiller l’avenir.
- Relier chaque chantier à un livrable mesurable. Pas seulement « migrer vers le cloud » ou « renforcer la cybersécurité », mais réduire de X % le parc non supporté, basculer tel périmètre, ou atteindre tel niveau de couverture.
Quand je vois une trajectoire crédible, je vois aussi ses limites. Un bon document ne promet pas une rupture totale en douze mois ; il admet ce qu’il faut stabiliser, ce qu’il faut moderniser vite et ce qui devra attendre. Cette lucidité est plus utile que l’ambition mal maîtrisée. Et c’est précisément là que la cybersécurité doit entrer dans l’équation, sans bloc séparé ni traitement de faveur de dernière minute.
Pourquoi la cybersécurité ne doit pas être traitée à part
Je ne traite jamais la cybersécurité comme un chapitre isolé, parce que les attaques exploitent justement les zones où l’on a séparé les sujets. L’ANSSI publie en 2026 une stratégie nationale de cybersécurité 2026-2030 et des feuilles de route annuelles pour la sécurité numérique de l’État : le signal est clair, le cap est pluriannuel, mais les priorités d’exécution doivent être resserrées et suivies de près.
Cybermalveillance.gouv.fr rappelle aussi des mesures très basiques, mais toujours décisives : mots de passe robustes, sauvegardes régulières, mises à jour rapides et double authentification. Je trouve cette insistance saine, parce qu’un document stratégique se juge aussi à sa capacité à faire financer les fondamentaux avant les chantiers plus visibles.
| Chantier sécurité | Effet recherché | Moment où je le place |
|---|---|---|
| Gestion des identités et MFA | Réduire fortement le risque de compromission de comptes | Première vague |
| Sauvegardes isolées et tests de restauration | Garantir la reprise après incident ou rançongiciel | Première vague |
| Gestion des correctifs et inventaire des actifs | Réduire la surface d’attaque et les vulnérabilités connues | Première vague |
| Journalisation et supervision | Détecter plus tôt les comportements anormaux | Deuxième vague |
| Plan de réponse à incident et exercices | Éviter l’improvisation le jour où l’attaque arrive | Deuxième vague |
| Clauses de sécurité fournisseurs | Limiter le risque de la chaîne d’approvisionnement | À intégrer dès les nouveaux contrats |
Je considère que l’approche la plus efficace est celle du security by design appliqué à la feuille de route : on ne sécurise pas après coup, on décide quelles briques sont admissibles, à quelles conditions et avec quel niveau de contrôle. Cela change beaucoup de choses, surtout quand le SI dépend de prestataires, de cloud publics ou d’outils métiers déjà très imbriqués. Une fois cette base posée, il reste à faire tenir la trajectoire dans le temps.
Comment piloter l’exécution sans perdre le cap
Un SDSI meurt rarement faute d’idées ; il meurt faute de rythme. Je préfère donc une gouvernance légère mais ferme, avec des décisions régulières et des indicateurs lisibles. À mon sens, un bon rythme ressemble à cela : un comité opérationnel mensuel, un comité d’arbitrage trimestriel et une revue stratégique annuelle.
Le plus important n’est pas de surveiller vingt indicateurs. Cinq à sept suffisent, à condition qu’ils poussent vraiment à décider. Voici ceux que je trouve les plus utiles :
| Indicateur | Ce qu’il dit | Pourquoi il aide à décider |
|---|---|---|
| Taux de couverture MFA sur les comptes sensibles | Niveau réel de protection des accès | Permet de voir si la politique sécurité avance vraiment |
| Taux de restauration des sauvegardes testé | Capacité de reprise effective | Évite de découvrir trop tard que les sauvegardes sont inutilisables |
| Part des applications hors support | Niveau de dette technique et d’exposition | Aide à prioriser les remises à niveau les plus urgentes |
| Respect des jalons des chantiers critiques | Fiabilité de l’exécution | Montre si la feuille de route est tenable ou déjà en dérive |
| Délai moyen de correction des vulnérabilités prioritaires | Réactivité opérationnelle | Relie la sécurité à des délais concrets, pas à des intentions |
Je conseille aussi de documenter chaque arbitrage important dans un journal de décision. Ce n’est pas bureaucratique ; c’est la seule manière de comprendre, six mois plus tard, pourquoi telle option a été retenue plutôt qu’une autre. Sans cette mémoire, l’organisation refait les mêmes débats à l’infini, surtout quand les équipes changent.
Dans beaucoup de structures, la bonne pratique consiste à réviser la trajectoire au moins une fois par an, et plus tôt si un changement majeur survient : acquisition, migration cloud, incident de sécurité, bascule de SI métier ou changement réglementaire. Cette révision n’est pas un aveu d’échec ; elle montre que le document est vivant. Le vrai danger, au contraire, c’est l’immobilité.
Les erreurs qui rendent la feuille de route inopérante
Je vois revenir les mêmes erreurs, quelle que soit la taille de l’organisation. Elles sont rarement spectaculaires, mais elles tuent la valeur du document en silence. La plus fréquente consiste à écrire depuis la technique au lieu d’écrire depuis les objectifs métiers.
- Faire un document trop large. Quand tout est prioritaire, rien ne l’est vraiment.
- Confondre cible et exécution. Décrire un état futur n’est pas encore le rendre atteignable.
- Oublier la capacité réelle des équipes. Dans beaucoup d’environnements, 8 à 10 chantiers majeurs par an est déjà un plafond raisonnable.
- Ne pas nommer les responsables. Sans propriétaire clair, les projets glissent vite vers l’informel.
- Négliger les dépendances. Une migration applicative sans préparation des données, des interfaces et des usages finit mal.
- Oublier la mise à jour du document. Un SDSI non révisé devient faux très vite, parfois en moins d’un an si le contexte bouge beaucoup.
Le travers que je trouve le plus coûteux, c’est le document qui veut tout concilier : modernisation, baisse des coûts, cybersécurité, sobriété, IA, cloud, réorganisation, sans choix nets ni renoncements assumés. Dans la vraie vie, la qualité d’une feuille de route se mesure à sa capacité à dire ce qu’elle ne fera pas tout de suite. C’est souvent là que se joue la crédibilité.
Les cinq décisions qui font la différence en 2026
Si je devais réduire la démarche à l’essentiel, je garderais cinq décisions non négociables. Elles ne résolvent pas tout, mais elles créent les conditions d’un pilotage sérieux.
- Nommer un sponsor unique. Sans sponsor exécutif, les arbitrages deviennent flous et les priorités se dispersent.
- Fixer un horizon clair. Trois à cinq ans, avec des jalons semestriels, donne une ossature crédible sans figer le SI.
- Définir une baseline sécurité. MFA, sauvegardes, patching, journalisation et gestion des accès doivent être acquis avant les grands chantiers de transformation.
- Limiter le travail en cours. Mieux vaut peu de chantiers bien tenus qu’une accumulation de projets à moitié lancés.
- Réviser la trajectoire sans attendre le prochain grand projet. Une revue annuelle, complétée par des points trimestriels, suffit souvent à garder le cap.
Au fond, ce qui fonctionne le mieux, c’est une feuille de route qui aide à arbitrer aujourd’hui sans empêcher d’adapter demain. Quand le document permet de prioriser, de sécuriser et de financer les bons sujets au bon moment, il cesse d’être un exercice de rédaction et devient un vrai outil de management du SI.
