Modernisation du SI : prioriser les chantiers
Une trajectoire de modernisation se juge à ce qu’elle rend possible pour l’activité. Le choix du framework vient ensuite.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Une modernisation mérite d’être financée quand elle lève une contrainte concrète. La nouvelle architecture est un moyen ; la capacité retrouvée et la sortie de l’ancien fonctionnement sont les résultats à vérifier.
- Définir le problème avant d’arrêter une cible technique.
- Comparer une évolution ciblée à une refonte plus large.
- Budgéter la coexistence et nommer un responsable de sa sortie.
1. L’âge d’une application ne décide pas de sa priorité
Un système ancien peut rendre un service stable. Un système récent peut déjà ralentir les équipes. La bonne question est donc : quelle opération, quelle évolution ou quelle décision devient difficile à cause du fonctionnement actuel ? Il peut s’agir d’un délai d’intégration, d’une ressaisie récurrente, d’un risque d’exploitation ou d’une dépendance à une compétence devenue rare.
Notre recommandation : formuler le problème en une phrase qu’un responsable métier peut confirmer. « Nous voulons une architecture plus moderne » ne permet pas d’arbitrer. « Chaque ajout de canal de vente impose une modification de la facturation » identifie une dépendance à examiner. La première formulation décrit une préférence ; la seconde donne un objet au travail.
Cette lecture n’efface pas les impératifs techniques. Une fin de support ou une vulnérabilité peut rendre une intervention prioritaire. Il faut alors expliciter l’échéance, le risque et les mesures possibles, plutôt que d’attribuer à la refonte des bénéfices métier encore hypothétiques.
2. Comparer les options avant d’engager la refonte
Nous proposons de soumettre chaque périmètre à quatre options simples. L’objectif est de rendre les compromis visibles, puis de choisir une première étape dont le résultat pourra être observé.
| Option | Question décisive | Point à vérifier |
|---|---|---|
| Conserver et stabiliser | Le service répond-il encore au besoin ? | Support, compétences et risque résiduel. |
| Faire évoluer un périmètre | Peut-on lever le frein sans tout remplacer ? | Frontières et dépendances réellement isolables. |
| Remplacer | La cible apporte-t-elle une capacité nécessaire ? | Reprise des données, interfaces et adoption. |
| Retirer | Le service est-il encore utilisé ou obligatoire ? | Usages résiduels et accès aux données historiques. |
Cette grille est un support de discussion proposé par Spark, pas un score universel. Un composant peu visible peut être une dépendance critique ; une application très utilisée peut aussi être suffisamment stable pour attendre. L’ordre des travaux doit intégrer ces deux réalités.
3. Exemple : isoler un changement qui bloque plusieurs équipes
Le choix dépend aussi de la capacité de l’équipe à maintenir deux fonctionnements pendant la transition. Un découpage séduisant sur un schéma peut être inadapté si personne ne peut exploiter les interfaces ajoutées ou traiter leurs incidents.
4. Prévoir la fin de la coexistence dès son démarrage
Le pattern Strangler Fig décrit un remplacement progressif des fonctionnalités d’un système. Microsoft souligne aussi les contraintes de coexistence, les dépendances et le coût de l’architecture transitoire. Il n’est notamment pas adapté à toutes les situations de retrait rapide. Voir la description et les limites du pattern par Microsoft.
Notre recommandation est de traiter chaque interface temporaire comme un engagement à suivre : qui la maintient, qui décide de son retrait et quel événement permet de l’arrêter ? Sans ces réponses, une étape de transition peut devenir une couche supplémentaire durable.
- Identifier les consommateurs qui utilisent encore l’ancien parcours.
- Définir les validations nécessaires avant de basculer chaque usage.
- Préciser jusqu’à quand un retour au fonctionnement antérieur reste possible.
- Attribuer le retrait des composants et la gestion des données historiques.
Le coût de coexistence doit apparaître aux côtés du coût de construction : suivi des échanges, support de deux parcours, réconciliations et maintenance des composants temporaires. C’est ce coût complet qui permet de comparer les scénarios.
5. La fiche à apporter au prochain comité
Avant de valider une étape, réunissez les réponses suivantes sur une page. Les inconnues doivent rester visibles : elles deviennent des travaux d’investigation, pas des engagements implicites.
- Contrainte actuelle : quelle opération est bloquée ou rendue difficile ?
- Capacité attendue : qu’est-ce qui deviendra possible après cette étape ?
- Options comparées : pourquoi ce scénario et quel compromis accepte-t-on ?
- Dépendances : qui doit contribuer et quels usages peuvent être affectés ?
- Preuve de réussite : quel test, quelle mesure ou quelle validation permettra de conclure ?
- Sortie de transition : que pourra-t-on retirer, à quelles conditions et sous quelle responsabilité ?
La décision peut être de réaliser, d’investiguer ou de différer. Un bon cadrage n’oblige pas à lancer une refonte : il permet de choisir en connaissance de cause. Pour la réalisation, le besoin peut ensuite porter sur un architecte, un consultant applicatif ou un chef de projet, selon la contribution manquante.
Source et périmètre de ce point de vue
Le cadre technique cité est celui de Microsoft. La grille, la fiche de décision et l’exemple sont des propositions éditoriales de Spark ; ils ne constituent pas un retour d’expérience client.
Retrouvez nos prochains points de vue Cloud, Data et Pilotage sur la page LinkedIn Spark Conseil.
