1. Pourquoi le schéma directeur a mauvaise réputation
Dans beaucoup de DSI, le schéma directeur est perçu comme un “livre sacré” : volumineux, figé, rarement relu après sa validation, et souvent déconnecté du backlog réel des équipes. Pour les utilisateurs et les métiers, il rime avec contraintes, arbitrages technos incompris et projets imposés “d’en haut”.
Ce décalage vient souvent de deux biais : d’un côté, un document produit en mode “one shot” tous les 3–5 ans, sans gouvernance vivante ; de l’autre, une traduction insuffisante de la stratégie en décisions concrètes sur les processus, les données, les applications et l’organisation.
Pour l’architecte d’entreprise, le défi est d’en faire exactement l’inverse : un artefact vivant, orienté décisions, qui aide à choisir quoi faire (et ne pas faire), dans quel ordre, avec quels compromis.
2. Interpréter les ambitions stratégiques (et les challenger)
La première étape n’est pas de dessiner une cible, mais de comprendre ce que l’entreprise veut devenir. Ce travail d’interprétation est souvent sous‑estimé : il ne s’agit pas de recopier le plan stratégique, mais de le traduire en enjeux de capacités et de données.
Concrètement, cela implique :
- Capter la vision : entretiens avec COMEX, directions métiers, marketing, finance ; compréhension des enjeux de marché, de la concurrence, des mouvements réglementaires.
- Distinguer ambition et posture : “être customer‑centric”, “faire de l’IA”, “passer au cloud” sont des slogans ; l’architecte doit demander “pour quoi faire ?”, “sur quels segments ?”, “avec quels indicateurs de succès ?”.
Exemples de traduction stratégique :
- « Mettre le client au centre” devient :
- Capacité à consolider les données client (identité, consentements, interactions, contrats) dans un modèle gouverné.
- Capacité à personnaliser les parcours (recommandations, offres, service) dans les canaux opérationnels (site, app, centre de contact, back‑office).
- “Croissance via nouveaux business models (abonnements, usage, partenaires)” devient :
- Capacité de construire des offres modulaires (catalogue flexible, pricing dynamique).
- Capacité de gérer des revenus récurrents (facturation récurrente, reconnaissance de revenus, churn, CLV).
- Capacité à ouvrir un écosystème (API, marketplace, portails partenaires).
Un point clé : ne pas rester à un niveau DSI. Le plan stratégique SI doit être lisible par les métiers, direction générale et finance, avec des formulations centrées sur les capacités business (ex : “capacité à lancer un nouveau produit digital en moins de 3 mois”) plutôt que sur les technologies.
3. Relier ambitions et enjeux opérationnels
Ensuite, l’architecte doit faire le lien entre ce que l’entreprise veut faire et ce que le SI permet (ou empêche) aujourd’hui. C’est là que le schéma directeur se nourrit de la réalité du terrain.
Ci-dessous une approche efficace :
- Cartographier les irritants : ateliers avec équipes métier, produit, support, RUN ; collecte des 10 principaux problèmes qui freinent la performance (lenteur time‑to‑market, duplication de saisies, manque de données fiables, incidents récurrents…).
- Les regrouper en enjeux opérationnels :
- Efficience des opérations (automatisation, IA, simplification des processus).
- Modernisation / move to cloud (résilience, sécurité, coûts, élasticité).
- Qualité et gouvernance des données (référentiels, qualité, ownership, catalogage).
- Expérience utilisateur (cohérence des parcours, omnicanal, mobilité, accessibilité).
- Puis faire le lien entre les 2:
- Quels enjeux sont directement alignés avec les ambitions stratégiques ?
- Quels enjeux sont purement “hygiène” mais bloquants (dette technique, obsolescence, Shadow IT) ?
Cette étape permet d’éviter deux travers : un schéma directeur purement “vision COMEX” sans prise avec la réalité, ou au contraire un catalogue d’irritants sans direction stratégique.
4. Des axes de transformation et des principes d’architecture
À ce stade, les axes de transformation clairs (3 à 6 maximum) et les principes d’architecture associés peuvent être formalisés
Exemples d’axes de transformation :
- “Unifier et valoriser la donnée client et produit pour soutenir les nouveaux business models digitaux.”
- “Simplifier le paysage applicatif cœur pour accélérer les évolutions et réduire les coûts de run.”
- “Moderniser les fondations (cloud, sécurité, identité) pour supporter l’industrialisation des cas d’usage IA.”
Exemples de principes d’architecture qui en découlent :
- Data‑centric : gouvernance des données, MDM, data platform, modèles partagés, mesure de la qualité.
- Composable / modulaire : découpage en domaines, capacités, services, architecture orientée événements pour limiter les couplages.
- API‑first : intégration standardisée et contrôlée, ouverture raisonnée vers l’écosystème.
- Security & privacy by design : exigences dès la conception (authent, traçabilité, protection des données).
Ces principes sont précieux plus tard pour arbitrer : c’est grâce à eux que l’on peux dire “non” à une solution qui va à l’encontre de la cible, même si elle semble rapide.
5. Construire une architecture cible qui parle à tout le monde
La vision cible ne doit pas être un macro schéma technique illisible. Une bonne pratique consiste à la décrire en trois couches compréhensibles :
- Côté métier :
- Capabilities clés par domaine (ex : gestion client, order‑to‑cash, logistique, data & analytics).
- Grands parcours (client, collaborateur, partenaire) que la cible doit rendre possibles ou fluidifier.
- Côté données :
- Domaines de données majeurs (client, produit, contrat, transaction, IoT, etc.).
- Où se trouvent les “sources de vérité”, quelles plateformes data (lakehouse, MDM, analytics, IA).
- Côté applicatif / techno :
- Applications / plateformes pivot (CRM, ERP, OMS, Billing, Data Platform, API Gateway, IAM…).
- Patterns structurants (microservices, events, serverless, low‑code sur certaines briques, etc.).
Pour que la cible soit compréhensible et interprétable par le plus grand nombre, ci-dessous quelques tips :
- Mettre en évidence les grandes transformations (fusion/remplacement de systèmes, création de hubs, refonte de canaux) plutôt que de lister tous les composants.
- Garder un niveau d’abstraction suffisant pour que la cible survive à un changement de fournisseur ou de technologie.
6. La vraie difficulté : la trajectoire et les architectures de transition
C’est là que tout se joue. La cible parfaite qui n’est jamais atteinte ne sert à rien. Construire la trajectoire consiste à définir une suite de paliers stables, chacun apportant de la valeur business tout en réduisant la complexité globale.
Quelques leviers sur lesquels l’architecte peut s’appuyer dessus:
- Découper par “plateaux” de valeur : associer chaque palier à des résultats tangibles (ex : “palier 1 : unifier les identités et simplifier les accès”, “palier 2 : refonte du domaine client + data hub client”, etc.).
- Travailler les scénarios de migration : pour chaque bloc legacy important, définir si on fait du “strangler pattern”, du replatforming, du remplacement big‑bang, ou de la coexistence longue.
Ensuite, gérer trois dimensions de stabilité / cohérence à chaque palier :
- Stabilité / cohérence d’architecture : pas de “spaghetti temporaire” qui durerait 5 ans ; des flux d’intégration clairs, des responsabilités de domaines nettes, même en transition.
- Stabilité / cohérence des données :
- Éviter les doublons de vérité ; si coexistence, définir qui est “master” de quoi.
- Prévoir des stratégies temporaires de synchronisation (events, réplication, ETL transitoires) et des plans de nettoyage.
- Stabilité de l’expérience utilisateur :
- Ne pas sacrifier les utilisateurs sur l’autel de la trajectoire : fédérer les écrans via un portail, un shell d’application ou des liens intelligents ; harmoniser les patterns UX même si plusieurs applis coexistent.
7. Obsolescence, Shadow IT et réalités politiques
Deux points méritent d’être adressés explicitement dans l’article.
- Obsolescence IT ou la gestion du legacy :
- Cartographier les applications obsolètes (risques, coûts, dépendances) et les planifier dans la trajectoire (décommissionnements, consolidations).
- Mettre en face des chiffres : coûts de run, risques de sécurité, indisponibilités, manque de compétences ; c’est ce qui permet de financer la modernisation.
- Shadow IT :
- Le voir comme symptôme d’un manque d’offre officielle plutôt que comme simple problème.
- Décider : intégrer (quand pertinent), remplacer (par une offre standard), ou éteindre ; et surtout proposer des plateformes capables de supporter l’innovation (low‑code, API, data self‑service) dans un cadre gouverné.
Un article dédié au Shadow IT a été écrit sur notre blog : le consulter
Politiquement, le schéma directeur devient un outil de dialogue : il explicite les arbitrages (ce qu’on fait maintenant, après, ou pas du tout) et offre un langage commun entre COMEX, métiers, DSI et équipes produit.
8. Ce qui fait un “bon” schéma directeur
Au final, un bon schéma directeur / roadmap d’architecture se reconnaît à quelques critères simples :
- Il est compréhensible par un directeur métier en 10–15 minutes (axes, trajectoire, impacts).
- Il aide à dire “non” à certains projets ou choix techniques qui ne s’alignent pas avec les principes définis.
- Il est révisé régulièrement (au moins annuellement, souvent de manière plus incrémentale) plutôt que redéfini tous les 5 ans en partant de zéro.
C’est cette capacité à relier la stratégie, les irritants du terrain, la vision d’architecture et la trajectoire pragmatique qui transforme le schéma directeur d’un document rigide en vrai outil de pilotage de la transformation.
Dans les prochains articles, je partagerai des outils utilisés pour élaborer la démarche (Business Capability, ABB, SBB), mais également des zoom sur les sujets comme la gestion de la dette / legacy, les principes d’architecture, ….
