Aller au contenu

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é.

Katharina Weber2 min de lecture
Bloc logiciel vert avec panneau à engrenage et panneau au symbole de cube légèrement sorti.

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 : SR-18, 90 minutes ; SR-19 est absent. Champs, format et accès autorisés sont documentés.

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 : SR-18, 90 minutes. Les écarts de sens métier sont clarifiés.

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.

Suivre ASES

À lire aussi

Tous les articles

Développement logiciel avec ASES

Logiciels sur mesure, applications web et mobiles