Logiciels anciens. Risques croissants.

Préserver le comportement métier plutôt que transposer aveuglément l'ancien code

Dans les systèmes historiques, le code n'explique souvent qu'une partie du processus. Des exports de tableaux, des corrections manuelles de données et des tâches planifiées peuvent avoir pris en charge des fonctions indispensables. Nous recensons ces voies annexes et constituons un catalogue de cas caractéristiques : cas standards, exceptions historiques, valeurs limites et erreurs connues. Une exécution comparative entre l'ancien et le nouveau système rend les écarts visibles, mais ne détermine pas encore quel résultat est correct sur le plan métier.

Le service métier évalue les écarts conjointement avec l'équipe de développement. Les arrondis, les fuseaux horaires, l'ordre de tri ou d'anciennes règles tarifaires peuvent produire des écarts apparemment mineurs mais aux effets importants. Les changements de comportement souhaités sont distingués des régressions involontaires. C'est seulement ainsi que se constitue une base de recette pertinente. Les cas documentés servent ensuite de filet de sécurité durable pour les transformations ultérieures et conservent un savoir jusque-là détenu par quelques personnes seulement.

Piloter les données en exploitation parallèle et planifier la bascule

Tant que les anciens et les nouveaux composants coexistent, la responsabilité des accès en écriture ne doit pas être ambiguë. Nous déterminons un système maître par domaine de données et planifions le transfert de cette responsabilité. Deux applications qui écrivent sans coordination peuvent créer des états contradictoires, même si chacune fonctionne correctement de son côté. L'architecture intermédiaire nécessite donc ses propres interfaces, ses propres contrôles de cohérence et une durée de vie limitée.

Un plan de migration comprend la reprise initiale, les modifications intermédiaires et le contrôle de cohérence final. Nous vérifions le nombre d'enregistrements, les totaux métier, les relations et des cas individuels représentatifs. Avant la bascule, les critères d'abandon, le pouvoir de décision et les pauses d'écriture admissibles sont définis. Un retour arrière n'est réaliste que si les données nouvellement créées peuvent être retraitées. Lorsque ce n'est pas possible, le moment et les conséquences de cette limite sont indiqués avant la validation.

Découplage technique et achèvement du remplacement

Une nouvelle interface posée sur une architecture ancienne inchangée n'en supprime pas automatiquement les limites. Nous examinons les tables partagées, les formats de fichiers implicites, les accès directs à la base de données et les bibliothèques qui lient plusieurs applications à la fois. Des adaptateurs introduits progressivement peuvent absorber les changements. Ce sont toutefois des composants transitoires qui demandent leur propre maintenance et ne doivent pas devenir, sans que l'on s'en aperçoive, un second paysage applicatif permanent.

Chaque fonction remplacée fait donc aussi l'objet d'une tâche de mise à l'arrêt. Les anciennes tâches planifiées, les comptes utilisateurs, les interfaces, l'infrastructure et les licences sont vérifiés quant à leur usage résiduel. Les demandes d'informations historiques peuvent nécessiter un accès en lecture ou un export documenté. La modernisation de cette étape n'est achevée que lorsque les dépendances sont résolues, la documentation d'exploitation mise à jour et les responsabilités transférées. Cela évite que les coûts de l'ancien et du nouveau système ne s'additionnent durablement.