Clarifier le rôle d’une interface avant de la remplacer

Avant de remplacer une interface, il faut clarifier le travail qu’elle assure réellement aujourd’hui. La raison technique peut être justifiée : un ancien protocole ou une réalisation difficile à maintenir peut motiver un changement. Cela ne détermine pas encore les processus métier que le remplacement doit préserver.

Le transfert visible n’est qu’une partie du processus

Dans une entreprise fictive, une connexion nocturne transfère les nouvelles commandes d’un portail vers l’ERP. Elle attend aussi une clarification lorsque des identifiants d’article sont inconnus et renvoie le numéro de commande ERP le lendemain. Remplacer seulement le premier transfert pourrait faire perdre des requêtes non résolues ou omettre le retour du numéro.

L’exemple motive notre recommandation de recenser aussi les exceptions et les retours. Une ancienne connexion peut accomplir un travail utile même si sa forme technique doit être remplacée. Elle peut également porter des règles devenues inutiles. Ces deux aspects doivent être évalués sur le processus concret.

Examiner le sens avant la nouvelle forme

Microsoft décrit avec l’Anti-Corruption Layer une traduction entre systèmes ayant des sémantiques différentes. Une telle frontière peut aider à détacher la nouvelle connexion du modèle de l’ancien système. Elle ne décide toutefois pas quelles étapes d’attente ou quels retours restent nécessaires au métier.

Vérifiez donc une opération normale, un cas différé et une réponse tardive. Pour chacun, définissez le résultat à préserver. Chaque particularité existante n’a pas besoin d’une copie technique ; une règle délibérément simplifiée peut être préférable si ses conséquences sont clarifiées.

Dimensionner la transition selon les dépendances

Le modèle Strangler Fig décrit le remplacement progressif de fonctions individuelles. Il exige des points de passage adaptés et entraîne un effort supplémentaire temporaire. Pour une petite connexion clairement délimitée, une bascule commune peut être plus simple.

Le remplacement ne peut être évalué sur le plan métier que lorsque les opérations ouvertes disposent elles aussi d’un chemin. Une nouvelle connexion réussie en dit peu à ce sujet. Nous recommandons donc de définir le travail attendu à partir de cas concrets, puis d’en déduire le périmètre et la transition de la nouvelle connexion.

Sources

• Microsoft Learn: Anti-Corruption Layer pattern

• Microsoft Learn: Strangler Fig pattern