Moderniser un export existant par étapes
Un plan de transition concret : mêmes données de test, droits de lecture explicites et retour arrière limité.

Choisissez une fonction aux limites claires
Partez d’un résultat concret, comme un export de rapport fiable. Le modèle Strangler Fig décrit le remplacement de fonctions tandis que d’autres restent dans le système existant. Vérifiez d’abord si les appels peuvent être aiguillés séparément et si les deux solutions peuvent fonctionner temporairement ensemble.
Recensez les utilisateurs appelants, interfaces et tâches de fond planifiées. Précisez champs, format de fichier, erreurs et droits d’accès. Fowler recommande de guider la modernisation par les résultats souhaités et les points de séparation adaptés. Ne prenez pas les anciens défauts pour des règles métier sans les examiner.
Exemple de plan pour un export en lecture seule
Ce plan est entièrement fictif. Un jeu de test figé contient SR-18, au statut approved, avec 90 minutes, et SR-19, au statut draft, avec 30 minutes. La règle convenue est d’exporter uniquement les entrées approuvées. Le tableau décrit les preuves attendues, pas des tests exécutés.
Phase | Tâche | Preuve attendue |
|---|---|---|
État initial | Exécuter l’ancien export sur le jeu de test figé. | 1 ligne de données : |
Nouvelle réalisation | Exécuter le nouvel export avec des droits de lecture sur le même jeu. | De nouveau 1 ligne de données : |
Bascule limitée | Aiguiller certains appels vers la nouvelle réalisation ; garder l’ancien chemin disponible. | Les appels autorisés donnent le résultat convenu ; les autres sont refusés. Le retour a été vérifié. |
Retrait de l’ancien export | Transférer les appels et tâches de fond restants ; attribuer la responsabilité d’exploitation. | Aucune dépendance à l’ancien export ne subsiste. Preuves et limites du retour sont consignées. |
Dans cet exemple, les écritures et la responsabilité des données de référence restent entièrement dans l’ancienne application. La nouvelle fonction reçoit seulement les droits de lecture nécessaires ; le schéma de base ne change pas. Comparez les deux exports sur le même jeu figé. Des instants différents dans des données réelles changeantes fausseraient la comparaison.
Vérifiez le nouvel accès et le retour
L’aiguillage ne remplace pas le contrôle d’accès. OWASP exige une vérification adaptée des droits à chaque requête. Vérifiez aussi les appels directs au nouvel export, les accès refusés et les messages d’erreur.
Le retour reste possible seulement tant que l’ancien chemin de lecture et le format sont compatibles. Il ne démontre aucune restauration de base. Après la bascule, l’ancien export peut disparaître ; le reste de l’application demeure nécessaire pour gérer et stocker les données. Si l’aiguillage séparé est impossible ou si tout l’ancien système doit être retiré rapidement, le plan demande un autre périmètre.
Sources
Écrit par
- Katharina WeberRédactrice logiciels et technologieKatharina Weber s’occupe chez ASES des articles consacrés au développement logiciel. Elle traite des questions que se posent les entreprises lorsqu’elles choisissent un logiciel, développent de nouvelles applications ou modernisent leurs systèmes existants.
À lire aussi
Tous les articles




Développement logiciel avec ASES
Logiciels sur mesure, applications web et mobiles


