GUIDE
Modernisation SI : le guide complet pour les DSI
Diagnostic, urbanisation, patterns de modernisation et mesure du progrès. Tout ce qu'il faut savoir avant de lancer votre programme
Recevez le guide modernisation SI en PDF
Avec le template de diagnostic et la matrice de priorisation des chantiers
La modernisation du système d’information est le chantier le plus stratégique (et le plus complexe) qu’un DSI puisse entreprendre. Trop souvent reportée par manque de temps, de budget ou de courage, elle finit par s’imposer d’elle-même quand la dette technique paralyse l’innovation, quand les incidents se multiplient, ou quand les meilleurs talents refusent de travailler sur des technologies obsolètes
Ce guide est né de l’expérience accumulée par les architectes Nobori Partners sur des dizaines de programmes de modernisation. Il ne s’agit pas de théorie : chaque recommandation a été testée en conditions réelles, dans des contextes allant de la PME au groupe international
De la détection des signaux d’alerte au suivi des KPIs de modernisation, en passant par les patterns architecturaux et l’urbanisation, ce guide vous donne un cadre concret pour structurer votre programme et mesurer son avancement
1. Quand faut-il moderniser ?
La modernisation n’est pas un objectif en soi. C’est une réponse à des problèmes concrets qui menacent la capacité de l’entreprise à opérer, à innover et à se conformer aux réglementations. Voici les cinq signaux d’alerte qui indiquent qu’il est temps d’agir, et que reporter ne fait qu’aggraver la situation
Signal 1 : Time-to-market supérieur à 6 mois
Quand le déploiement d’une fonctionnalité simple prend plus de 6 mois, le problème n’est pas l’équipe, c’est l’architecture. Les systèmes monolithiques fortement couplés imposent des cycles de test et de déploiement longs, des régressions fréquentes et des dépendances croisées qui paralysent les équipes. Pendant ce temps, vos concurrents livrent en continu.
Benchmark : les entreprises les plus performantes livrent en production en moins de 1 jour (DORA metrics, Elite performers).
Signal 2 : Incidents récurrents et indisponibilités
Des incidents de production récurrents, des temps de rétablissement longs (MTTR > 4 heures), des cascades de pannes, ce sont les symptômes d’un SI fragilisé par la dette technique. Chaque incident non résolu à la racine devient un patch qui ajoute de la complexité. Le cercle vicieux s’accélère : plus de patches → plus de complexité → plus d’incidents → plus de patches.
Un SI obsolète coûte en moyenne 3 à 5 fois plus cher en incidents que le budget nécessaire à sa modernisation.
Signal 3 : Coût de maintenance supérieur à 60 % du budget IT
Quand plus de 60 % du budget IT est consacré au maintien en conditions opérationnelles (MCO) des systèmes existants, il ne reste plus de capacité d’investissement pour l’innovation. C’est le piège classique : on ne modernise pas parce qu’on n’a pas le budget, et on n’a pas le budget parce que tout est consommé par la maintenance du legacy. La seule sortie est une décision stratégique de réallouer une partie du budget MCO vers la modernisation.
Cible : un ratio 60/40 (60 % innovation, 40 % MCO) est le standard des organisations digitalement matures.
Signal 4 : Pénurie de compétences legacy
Les développeurs COBOL, les administrateurs mainframe et les experts sur les progiciels des années 2000 partent à la retraite sans être remplacés. Les jeunes talents refusent de travailler sur ces technologies. Résultat : un risque de key-person dependency critique, des coûts de prestation qui explosent et une incapacité à faire évoluer les systèmes. La modernisation n’est plus un choix technique, c’est une question de survie opérationnelle.
Le coût d'un développeur COBOL senior a augmenté de 40 % en 3 ans, quand celui d'un développeur cloud-native est resté stable.
Signal 5 : Non-conformité réglementaire
RGPD, NIS2, DORA, AI Act : les réglementations se multiplient et imposent des exigences de traçabilité, de sécurité et de résilience que les systèmes legacy ne peuvent pas satisfaire. Les audits révèlent des non-conformités structurelles (données non chiffrées, absence de journalisation, impossibilité de droit à l’effacement). Moderniser devient une obligation légale, pas seulement technique.
Les amendes RGPD en 2025 ont atteint 4,3 milliards d'euros cumulés en Europe. La non-conformité n'est plus un risque théorique.
2. Le diagnostic : cartographier votre SI
Avant de moderniser, il faut comprendre. Un diagnostic rigoureux du SI existant est le prérequis indispensable à toute décision éclairée. Sans cartographie, vous naviguez à l’aveugle, et vous risquez de moderniser les mauvaises applications ou de sous-estimer les dépendances
Cartographie applicative
Recenser toutes les applications du SI avec leurs caractéristiques : nom, fonction métier, technologie, âge, nombre d’utilisateurs, volumétrie, équipe responsable, coût annuel (licences + MCO + infrastructure). Ne négligez pas le shadow IT : les applications métier non référencées (tableurs Excel, bases Access, scripts Python) sont souvent les plus critiques et les plus fragiles.
Matrice criticité × obsolescence
Placez chaque application sur une matrice à deux axes : la criticité métier (quel impact si l’application est indisponible 24h ?) et le niveau d’obsolescence technique (version du framework, fin de support éditeur, sécurité). Les quatre quadrants guident la stratégie :
Critique + obsolète : modernisation prioritaire (risque maximal)
Critique + moderne : maintenir et optimiser (pas de modernisation urgente)
Non critique + obsolète : candidat au décommissionnement ou au remplacement SaaS
Non critique + moderne : laisser en l’état (investissement minimal)
Identification des SPOF (Single Points of Failure)
Un SPOF est un composant dont la défaillance entraîne l’arrêt de plusieurs applications. Base de données centrale sans réplication, serveur d’intégration unique, expert unique sur une technologie critique, chaque SPOF est une bombe à retardement. Le diagnostic doit les identifier et les classer par impact potentiel. La modernisation doit les éliminer en priorité.
Livrable du diagnostic : le rapport de santé SI
Le diagnostic produit un rapport de santé SI qui sert de base à toutes les décisions de modernisation. Il contient : la cartographie applicative complète, la matrice criticité/obsolescence, la liste des SPOF, l’estimation de la dette technique par application (en jours-homme de remédiation), les dépendances inter-applications, et une recommandation de priorité de modernisation. Ce rapport doit être validé par la DSI et les métiers avant de lancer le programme.
3. Les patterns de modernisation
La modernisation d’un SI ne se fait pas en big bang. Les patterns architecturaux éprouvés permettent de moderniser progressivement, en limitant les risques et en livrant de la valeur à chaque étape. Voici les quatre patterns les plus utilisés, avec pour chacun les situations où il excelle et les risques à surveiller
Strangler Fig Pattern
Principe : construire le nouveau système en parallèle de l’ancien, et migrer les fonctionnalités une par une. Le nouveau système « étrangle » progressivement l’ancien, comme un figuier étrangleur entoure un arbre hôte. Quand toutes les fonctionnalités sont migrées, l’ancien système est décommissionné
Quand l’utiliser : monolithes complexes avec de nombreuses fonctionnalités, applications critiques où le big bang est trop risqué, équipes qui doivent livrer de la valeur pendant la modernisation
Avantages : risque minimal (rollback facile par fonctionnalité), valeur incrémentale, pas d’interruption de service
Risques : durée longue (12-24 mois), coexistence de deux systèmes (complexité temporaire accrue), risque de « modernisation éternelle » si le planning n’est pas tenu
API Gateway Pattern
Principe : placer une couche API entre les consommateurs (front-end, partenaires, applications tierces) et les systèmes backend. L’API Gateway expose une interface stable et moderne, tout en routant les appels vers les systèmes legacy ou les nouveaux services selon l’avancement de la modernisation
Quand l’utiliser : systèmes avec de nombreux consommateurs (applications mobiles, partenaires, API publiques), modernisation orientée « API-first », besoin de découpler les frontends des backends
Avantages : découplage immédiat, possibilité de moderniser le backend sans impacter les consommateurs, versioning des API, monitoring centralisé
Risques : point de passage unique (SPOF potentiel), complexité de routage, performance (latence ajoutée), gouvernance des API nécessaire
Event-Driven Architecture
Principe : remplacer les intégrations synchrones point-à-point par un bus d’événements (Kafka, RabbitMQ, Amazon EventBridge). Chaque système publie des événements (« commande créée », « client mis à jour ») et les systèmes intéressés s’y abonnent. Le couplage est réduit au minimum : les systèmes ne se connaissent pas directement
Quand l’utiliser : systèmes fortement couplés par des intégrations point-à-point (fichiers plats, appels synchrones), besoin de temps réel ou quasi-temps réel, architecture nécessitant une scalabilité importante
Avantages : découplage radical, scalabilité horizontale, résilience (un système en panne n’impacte pas les autres), traçabilité des événements
Risques : complexité accrue (eventual consistency, ordering), debugging plus difficile (flux asynchrones), compétences spécifiques nécessaires, monitoring indispensable
Micro-services
Principe : décomposer le monolithe en services autonomes, chacun responsable d’un domaine métier (catalogue, commandes, facturation, utilisateurs). Chaque micro-service a sa propre base de données, son propre cycle de déploiement et son propre choix technologique
Quand l’utiliser : applications à forte croissance nécessitant une scalabilité indépendante par domaine, équipes nombreuses travaillant sur le même produit, besoin d’agilité maximale par domaine
Avantages : déploiement indépendant, scalabilité granulaire, autonomie des équipes, polyglottisme technologique, résilience par isolation
Risques : complexité opérationnelle élevée (réseau, monitoring, debugging distribué), overhead organisationnel (Conway’s law), risque de « nano-services » si le découpage est trop fin, nécessite une plateforme mature (Kubernetes, service mesh)
4. Urbanisation : organiser la complexité
L’urbanisation du SI est la discipline qui organise l’architecture globale du système d’information en zones fonctionnelles cohérentes, avec des règles claires de communication entre elles. C’est l’équivalent informatique de l’urbanisme d’une ville : chaque quartier a sa fonction, les routes sont planifiées, et les règles de construction garantissent la cohérence de l’ensemble
Les 4 zones fonctionnelles
Zone métier
Les applications qui implémentent les processus métier cœur : CRM, ERP, supply chain, production. C’est la zone la plus critique et souvent la plus difficile à moderniser. Chaque application métier doit être alignée avec un domaine métier identifié (DDD : Domain-Driven Design).
Zone support
Les applications transverses qui supportent les processus métier sans en être le cœur : RH, finance, gestion documentaire, communication interne. Ces applications sont souvent les meilleures candidates au remplacement par du SaaS (Workday, SAP S/4HANA, ServiceNow).
Zone d'échange
L’infrastructure d’intégration qui permet aux applications de communiquer : ESB, API Gateway, bus d’événements, ETL. C’est le système nerveux du SI. Sa modernisation est souvent le prérequis à la modernisation des autres zones : un bus d’intégration moderne (Kafka, API Management) débloque la modernisation incrémentale.
Zone référentiel
Les référentiels de données partagées : référentiel client, référentiel produit, référentiel géographique, référentiel organisationnel. La qualité de ces référentiels conditionne la qualité de tout le SI. Un MDM (Master Data Management) est indispensable pour les organisations de plus de 500 personnes.
Règles d’urbanisme et ADR
ADR : la mémoire architecturale
Les règles d’urbanisme sont les principes architecturaux qui garantissent la cohérence du SI dans la durée. Elles doivent être documentées, communiquées et respectées par toutes les équipes. Exemples : « toute communication inter-zone passe par la zone d’échange », « chaque nouvelle application expose une API REST », « les données de référence sont consommées depuis le MDM, jamais dupliquées »
Les ADR (Architecture Decision Records) documentent chaque décision architecturale importante : le contexte, les options évaluées, la décision prise et ses conséquences. Les ADR sont versionnés dans le code (dossier docs/adr/) et constituent la mémoire architecturale de l’organisation. Sans ADR, chaque nouvelle équipe redécouvre les mêmes problèmes et prend les mêmes mauvaises décisions
5. Mesurer le progrès
« Ce qui ne se mesure pas ne s’améliore pas. » Un programme de modernisation sans KPIs est un programme sans gouvernance. Voici les cinq indicateurs clés qui permettent de suivre l’avancement de votre modernisation et de démontrer la valeur créée
KPI 1 : Dette technique
Mesure : nombre de jours-homme nécessaires pour ramener le code à un état « propre » (mesure par SonarQube, CodeClimate ou équivalent). Cible : réduction de 20 % par an. Pourquoi : la dette technique est le meilleur indicateur avancé de la santé du SI. Si elle augmente malgré la modernisation, quelque chose ne va pas.
KPI 2 : Time-to-market (Lead Time for Changes)
Mesure : temps entre le commit d’un développeur et le déploiement en production (métrique DORA). Cible : passer sous 1 semaine (Elite < 1 jour). Pourquoi : c’est l’indicateur que le métier comprend le mieux. Un time-to-market court signifie que la DSI est capable de répondre rapidement aux besoins business.
KPI 3 : Incidents (Change Failure Rate + MTTR)
Mesure : pourcentage de déploiements qui causent un incident (Change Failure Rate) et temps moyen de rétablissement (MTTR). Cible : CFR < 15 %, MTTR < 1 heure. Pourquoi : la modernisation doit améliorer la stabilité, pas la dégrader. Si les incidents augmentent pendant la modernisation, c’est un signal d’alarme.
KPI 4 : Satisfaction développeurs (Developer Experience)
Mesure : enquête trimestrielle (eNPS développeur) sur la facilité à développer, tester et déployer. Cible : eNPS > 30. Pourquoi : les développeurs sont les premiers utilisateurs du SI. Leur satisfaction est un indicateur avancé de la qualité de l’architecture. Un SI moderne attire et retient les talents.
KPI 5 : Couverture API
Mesure : pourcentage des fonctionnalités du SI accessibles via API documentée. Cible : > 80 % des fonctionnalités critiques exposées en API. Pourquoi : la couverture API est un indicateur de l’ouverture et de la modularité du SI. Un SI avec une bonne couverture API peut être composé, étendu et intégré facilement.
6. Cas concret : modernisation en 18 mois
ETI industrielle, 800 collaborateurs, SI legacy de 15 ans, 35 applications
Avant : le diagnostic
Un ERP monolithique sur-customisé (SAP ECC 6.0, fin de support annoncée), 12 applications satellites en PHP 5 et Java 6, des intégrations par fichiers plats échangés par SFTP toutes les nuits, aucune API, un time-to-market de 9 mois en moyenne. La maintenance consommait 75 % du budget IT. Deux développeurs COBOL maintenaient un module de calcul critique, tous deux à 3 ans de la retraite
Le plan de modernisation par vagues
Vague 1 (mois 1-6) : Mise en place d’un API Gateway et d’un bus d’événements Kafka. Migration des 5 intégrations les plus critiques de SFTP vers des événements temps réel. Résultat : les données circulent en temps réel au lieu de H+24, les erreurs d’intégration sont détectées immédiatement
Vague 2 (mois 6-12) : Strangler Fig sur l’ERP : extraction du module de calcul COBOL en micro-service Python, exposition du catalogue produit et du référentiel client en API REST. Décommissionnement de 4 applications satellites remplacées par des SaaS (SIRH, gestion documentaire, CRM). Résultat : 4 applications en moins à maintenir, le risque COBOL éliminé
Vague 3 (mois 12-18) : Migration de l’ERP vers S/4HANA Cloud, avec le périmètre réduit au strict nécessaire (fin de la sur-customisation). Modernisation des 3 applications métier restantes en architecture cloud-native. Mise en place du pipeline CI/CD et du monitoring centralisé. Résultat : time-to-market passé de 9 mois à 3 semaines
9 mois → 3 semaines
Time-to-market
75 % → 45 %
Budget MCO (ratio)
-60 %
Incidents de production
35 → 18
Applications dans le SI
Besoin d’un accompagnement pour moderniser votre SI ?