Situation fréquente
L’application est ancienne, mais elle porte encore les gestes, documents et exceptions dont dépend l’activité.
Une application Windows, Access, Excel/VBA ou un logiciel interne gère des dossiers, des calculs, des validations et des éditions. Elle est peu documentée, difficile à faire évoluer et parfois dépendante d’un environnement technique vieillissant. Pourtant, l’arrêter brutalement mettrait en danger les opérations quotidiennes.
Le besoin métier n’est pas de “remplacer une technologie”. Il est de préserver le service rendu, les données nécessaires, les règles utiles et la capacité des équipes à traiter les cas normaux comme les exceptions. La modernisation devient alors une succession de décisions vérifiables, plutôt qu’un projet unique dont la valeur n’apparaît qu’au jour de la bascule.
Cadrage fonctionnel
Commencer par le service rendu aux utilisateurs
Les écrans, tables et technologies décrivent la solution actuelle. Le cadrage doit d’abord décrire le travail qui doit continuer.
- Quelles tâches les utilisateurs doivent-ils accomplir et dans quel délai ?
- Quels dossiers, calculs, contrôles, documents ou notifications sont produits ?
- Quelles exceptions mobilisent une décision humaine ou une correction ?
- Quelles données font foi et qui est autorisé à les modifier ?
- Quelles périodes de l’année ou échéances rendent une interruption impossible ?
- Quels résultats permettent de déclarer qu’un périmètre fonctionne correctement ?
Périmètres
Découper la modernisation en capacités métier vérifiables
Un bon périmètre peut être compris, testé et mis en service sans attendre le remplacement total de l’application.
| Capacité | Résultat métier | Dépendances à vérifier |
|---|---|---|
| Consulter un dossier | Retrouver les informations autorisées et leur historique | Identifiants, droits, documents et source de référence |
| Créer ou modifier | Enregistrer une donnée complète et contrôlée | Règles de validation, doublons, statuts et journalisation |
| Calculer ou valoriser | Obtenir un résultat explicable sur une date donnée | Formules, paramètres, arrondis et données de marché |
| Valider un traitement | Attribuer une décision et conserver sa justification | Rôles, seuils, exceptions et notifications |
| Produire un document | Générer le bon format avec les données validées | Modèles, versions, pièces jointes et archivage |
Définissez un premier périmètre modernisable sans interrompre l’activité.
Cadrer ma modernisationCompréhension
Rendre visibles les règles, les données et les dépendances
Une règle métier peut être répartie entre une consigne orale, un contrôle d’écran, une requête, du code, un modèle de document et une correction manuelle. L’inventaire technique sert à retrouver ces éléments, mais leur signification doit être validée avec les personnes qui produisent et utilisent le résultat.
Les dépendances externes doivent également être nommées : annuaire, fichiers partagés, base de données, ERP, messagerie, modèles Word ou PDF, tâches planifiées et exports repris par d’autres équipes. Une migration limitée à l’interface laisserait ces engagements invisibles.
À vérifier en interne
Ce que le métier peut documenter
- Les tâches prioritaires, cas normaux, exceptions et délais.
- Les données et documents attendus à l’entrée et à la sortie.
- Les décisions, rôles et responsabilités de validation.
- Les irritants actuels et leurs conséquences observables.
Accès technique nécessaire
Ce qui demande un accès technique
- Les tables, fichiers, requêtes, procédures, macros, API et tâches planifiées.
- Les dépendances entre composants et les consommateurs des exports.
- Les droits, journaux, sauvegardes, volumes et temps de traitement.
- Les versions, environnements et contraintes de déploiement.
Validation métier, comptable ou juridique
Ce qui doit être arbitré
- Les règles à conserver, simplifier ou abandonner.
- La source faisant foi pendant et après la coexistence.
- Les historiques à reprendre, archiver ou rendre consultables.
- Les exigences de sécurité, conservation et conformité applicables.
Transition
Organiser la coexistence entre l’ancien et le nouveau
Pendant une migration progressive, les équipes doivent savoir quel système utiliser pour chaque action et où se trouve la donnée de référence.
Choisir une capacité et une population pilote clairement délimitées.
Désigner, pour chaque donnée, le système autorisé à créer ou modifier pendant la transition.
Définir les échanges nécessaires, leur fréquence, leurs rejets et leur reprise.
Éviter la double saisie non contrôlée ; lorsqu’elle est provisoirement inévitable, organiser un rapprochement.
Prévoir un retour à l’ancien parcours si les critères de service ne sont pas atteints.
Informer les utilisateurs du parcours en vigueur, du support et des changements de responsabilité.
Validation
Comparer les résultats avant de basculer les usages
La recette ne doit pas seulement vérifier que les boutons répondent. Elle doit démontrer que le nouveau périmètre rend le service attendu : données retrouvées, calculs comparables, droits respectés, exceptions traitées et documents conformes aux exemples validés.
Lorsque l’ancien système produit encore le même résultat, une exécution parallèle limitée peut faciliter la comparaison. Les écarts sont qualifiés : erreur de reprise, règle différente, correction historique, amélioration décidée ou anomalie de l’ancien outil. Le métier arbitre les différences qui touchent au sens du résultat.
| Jeu | Objectif | Critère de sortie |
|---|---|---|
| Cas courants | Couvrir la majorité de l’activité quotidienne | Résultats conformes et parcours utilisable |
| Exceptions connues | Vérifier les règles et décisions moins fréquentes | Traitement expliqué, attribué et traçable |
| Historique repris | Contrôler les volumes, identifiants et relations | Écarts qualifiés et approuvés |
| Indisponibilité ou rejet | Tester le comportement en cas d’échec | Alerte, reprise et responsabilité connues |
| Droits utilisateurs | Confirmer les accès selon les rôles | Accès autorisés et refus attendus vérifiés |
Mise en service
Fixer les conditions de bascule et d’arrêt de l’ancien système
L’arrêt de l’application historique est une décision métier, opérationnelle et technique. Il doit avoir des conditions explicites.
- Les capacités du périmètre sont acceptées et les écarts résiduels sont connus.
- Les données utiles sont reprises, rapprochées et accessibles selon les droits attendus.
- Les procédures, responsabilités, support et supervision sont opérationnels.
- Les intégrations et consommateurs d’exports ont été migrés ou arrêtés.
- Les archives nécessaires restent consultables pendant la durée définie.
- Le scénario de retour et sa fenêtre d’utilisation ont été testés ou formellement clos.
Arbitrage
Choisir la trajectoire proportionnée au risque réel
| Option | Quand elle est pertinente | Vigilance principale |
|---|---|---|
| Maintenir et sécuriser | L’application reste adaptée et le risque peut être réduit localement | Tester la reprise et traiter l’obsolescence bloquante |
| Encapsuler ou connecter | Une nouvelle interface peut utiliser des règles ou données encore fiables | Définir une frontière claire avec l’ancien modèle |
| Remplacer une capacité | Un domaine est isolable et apporte une valeur rapide | Maîtriser la coexistence et les échanges temporaires |
| Migrer par vagues | Plusieurs capacités peuvent être ordonnées selon le risque et la valeur | Conserver une vision commune des données et dépendances |
| Reconstruire l’ensemble | L’ancien système ne permet pas une séparation sûre ou le modèle change profondément | Éviter un périmètre sans critères intermédiaires ni comparaison |
Exemple pédagogique
Étude de cas : moderniser progressivement une application WPF
Une application Windows WPF de suivi opérationnel doit évoluer vers le web. Le travail commence par les parcours utilisés, les familles de données, les règles de contrôle et les documents produits. La cible web n’est pas mise en service comme un remplacement global : les capacités sont reprises et vérifiées par versions successives.
Les données sont mappées, les exports PDF et XLSX sont comparés et les résultats sont testés localement. Cette progression permet de conserver les règles métier pendant la recette et de traiter séparément les écarts. L’étude de cas détaillée présente le périmètre, les preuves et la cible technique sans exposer les données du client.
À propos de cet exemple : Étude de cas issue d’un projet réel et présentée sous une forme anonymisée. Les visuels et données d’illustration sont reconstitués ; aucun fichier ni aucune donnée client ne sont publiés.
Accompagnement proportionné
Comment FreelanceDataDev peut intervenir
L’intervention relie le cadrage fonctionnel et la réalisation technique : comprendre le service rendu, cartographier les données et règles, définir les périmètres, construire la cible web, organiser la coexistence et préparer la recette.
Livrables possibles
- Carte des capacités métier, utilisateurs, données et dépendances.
- Inventaire des règles, exceptions, documents et échanges à préserver.
- Découpage de la modernisation en versions ou vagues vérifiables.
- Stratégie de reprise des données, coexistence, rapprochement et retour.
- Cas de recette fonctionnels et critères d’acceptation par périmètre.
- Architecture et déploiement adaptés : web, API, base de données et Docker lorsque cette cible est pertinente.
Limites et dépendances : La trajectoire dépend de l’accès à l’application, au code, aux données, aux utilisateurs et aux systèmes connectés. Une estimation fiable nécessite un périmètre et des preuves. Les exigences juridiques, réglementaires, comptables et de sécurité doivent être validées par les responsables compétents.
Questions fréquentes
Les points à clarifier avant de décider
Qu’est-ce qu’une application legacy ?
C’est une application historique encore utilisée, dont l’évolution ou l’exploitation devient difficile en raison de sa technologie, de sa documentation, de ses dépendances ou de ses compétences disponibles. Le terme ne signifie pas automatiquement qu’elle est inutile ou qu’elle doit être remplacée intégralement.
Faut-il reconstruire toute l’application pour la moderniser ?
Non. Une application peut être sécurisée, connectée, encapsulée ou remplacée par capacités. La reconstruction complète se justifie lorsque les périmètres ne peuvent pas être isolés, que le modèle métier change fortement ou que les contraintes de l’existant empêchent une coexistence sûre.
Comment éviter la double saisie pendant la coexistence ?
Il faut désigner le système autorisé à modifier chaque donnée, puis automatiser ou encadrer les échanges nécessaires. Si une double saisie provisoire est inévitable, elle doit avoir une durée, un rapprochement, un responsable et une condition de sortie.
Doit-on reprendre tout l’historique ?
Pas nécessairement. L’entreprise peut reprendre les dossiers actifs et les historiques indispensables, tout en conservant une archive consultable pour le reste. Le choix dépend des usages, des obligations de conservation, des droits d’accès et du coût de nettoyage.
Comment estimer une modernisation progressive ?
L’estimation doit porter sur des capacités délimitées et tenir compte des règles, données, exceptions, intégrations, documents, recette, conduite du changement et déploiement. Un inventaire technique seul ne suffit pas à mesurer l’effort fonctionnel.
Le modèle Strangler Fig convient-il à toutes les migrations ?
Non. Il est utile lorsque des capacités peuvent être déplacées progressivement et que l’ancien et le nouveau système peuvent coexister. Si l’application est très couplée, si la cohérence impose une bascule unique ou si le métier change entièrement, une autre stratégie peut être préférable.
Sources et vérification
Références utilisées
.
- Microsoft Learn — Azure Architecture Center — Strangler Fig Pattern — s’ouvre dans un nouvel ongletPrésentation officielle d’une approche incrémentale permettant de remplacer progressivement des fonctionnalités d’un système historique.
- Microsoft Learn — Azure Architecture Center — Anti-Corruption Layer Pattern — s’ouvre dans un nouvel ongletPrésentation officielle d’une couche de traduction destinée à préserver la frontière entre un nouveau modèle et un système existant.