Le point de départ.
L’ERP web opérationnel était un monolithe sur SQL Server, C# et .NET Framework 4.8, Entity Framework, KnockoutJS, JavaScript, jQuery, Bootstrap et Crystal Reports. La fiabilité était une exigence produit, pas une note de maintenance.
Sa base de données n’avait pas de système de migrations et n’appartenait pas uniquement à l’application web. Un ERP desktop et une application de caisse VB6 beaucoup plus anciens utilisaient le même schéma ; un changement correct sur le web pouvait donc interrompre le travail quotidien ailleurs.
Le périmètre couvrait fonctionnalités, bugs, procédures stockées, vues, reporting, deux intégrations transporteurs, exigences, formation et support. Le contact direct avec le client était essentiel pour comprendre l’usage réel du logiciel avant de le modifier.
Ce que le travail devait respecter.
Le système ne pouvait évoluer que si les anciens et nouveaux parcours opérationnels continuaient de s’accorder :
- Les workflows existants devaient continuer à soutenir le travail retail quotidien.
- Les modifications du schéma SQL Server devaient être rétrocompatibles, car aucun historique de migrations ne coordonnait tous les consommateurs.
- L’ERP web .NET Framework et les anciennes applications desktop et caisse VB6 partageaient le même contrat de données.
- KnockoutJS, jQuery, règles backend et comportement de la base devaient évoluer ensemble lorsque le parcours web changeait.
- Les exigences devaient être validées avec le client en termes opérationnels avant de devenir code, rapports ou comportement d’intégration.
- Deux intégrations externes avec des transporteurs devaient rester compréhensibles à la frontière du système.
Le diagnostic.
Dans un ERP en couches, le ralentissement ou l’échec visible n’est souvent que le dernier maillon. Un écran peut être lent à cause de la forme de sa requête, du traitement backend ou d’un accès aux données. Un problème d’intégration peut apparaître comme une incohérence frontend.
La base partagée changeait la définition habituelle d’un détail d’implémentation interne. Tables, colonnes et procédures stockées étaient aussi des contrats avec du logiciel VB6 incapable de suivre une séquence moderne de migrations.
J’ai associé le traçage de bout en bout aux échanges directs avec le client. Requêtes et procédures SQL Server, règles .NET Framework, écrans KnockoutJS et jQuery, rapports, échanges transporteurs et ancien parcours desktop faisaient partie d’un même comportement opérationnel.
La vue utile du système.
L’unité pertinente était tout le contrat opérationnel : une action dans l’interface web KnockoutJS et jQuery, les règles .NET Framework 4.8, le travail sur le schéma SQL Server partagé et les anciens parcours desktop et caisse VB6 dépendant des mêmes données. Rapports et échanges transporteurs ajoutaient d’autres frontières autour de ce noyau.
Pourquoi la continuité était un choix d’architecture.
Il s’agissait de faire évoluer un ERP en production, pas de recommander son stack pour un projet greenfield. Le bon choix technologique consistait souvent à préserver un contrat opérationnel et à l’améliorer en place plutôt qu’à renouveler toutes les couches simultanément.
Conserver C#/.NET Framework et KnockoutJS pour évoluer progressivement
- Pourquoi
- Fonctionnalités, défauts et parcours quotidiens traversaient déjà ces couches. Travailler dans ce cadre permettait de suivre chaque changement sur le chemin réel de la requête et de le livrer sans suspendre l’exploitation.
- Ce que j’ai écarté
- Une réécriture big-bang du backend et du frontend aurait exigé de redécouvrir et remplacer tout le comportement existant avant que des améliorations opérationnelles plus petites atteignent les utilisateurs.
- Ce que cela a coûté
- Le travail accepte les contraintes de frameworks plus anciens, des modèles frontend mixtes et un besoin durable de compétences de maintenance au lieu d’obtenir immédiatement une base moderne uniforme.
Traiter SQL Server comme le contrat de données partagé
- Pourquoi
- L’ERP web, l’ERP desktop VB6 et l’application de caisse lisaient et écrivaient le même schéma. Des changements SQL compatibles protégeaient les consommateurs qui ne pouvaient pas avancer à chaque release web.
- Ce que j’ai écarté
- Migrer la base ou le schéma avec l’application web aurait supposé que tous les consommateurs puissent basculer ensemble malgré l’absence d’un système de migrations.
- Ce que cela a coûté
- Des évolutions additives et des structures transitoires peuvent subsister plus longtemps ; la conception doit tenir compte des anciennes lectures et écritures autant que du nouveau parcours.
Faire évoluer Crystal Reports et les parcours de reporting existants
- Pourquoi
- Le reporting appartenait déjà au système opérationnel et à son comportement SQL Server. Conserver ce parcours dans le périmètre permettait de vérifier les rapports avec le même contrat de données et d’application.
- Ce que j’ai écarté
- Introduire simultanément une nouvelle plateforme de reporting aurait ajouté une autre migration et imposé de traduire le comportement des rapports pendant que l’application et la base changeaient aussi.
- Ce que cela a coûté
- La solution conserve un outil de reporting historique et ses contraintes de conception ; les changements continuent d’exiger des compétences spécifiques et une vérification entre plusieurs couches.
Livrer un parcours de bout en bout à la fois
- Pourquoi
- Une modification pouvait couvrir l’écran opérateur, les règles .NET, le comportement SQL et, si nécessaire, rapports, intégrations et anciennes applications comme une tranche opérationnelle cohérente.
- Ce que j’ai écarté
- Moderniser une couche technique à la fois aurait partagé le comportement entre anciens et nouveaux parcours, repoussant la preuve du workflow réel jusqu’à l’achèvement de plusieurs migrations.
- Ce que cela a coûté
- Chaque tranche doit être terminée et vérifiée dans toutes les couches et applications qu’elle touche ; le progrès exige donc des frontières rigoureuses plutôt que l’uniformité visible d’un programme par couches.
Règles pour faire évoluer un système en activité.
La continuité technique fixait le cadre ; ces règles reliaient chaque changement au parcours opérationnel complet et aux retours des personnes qui l’utilisent.
Suivre toute la requête
Le travail sur la performance et la fiabilité part d’un comportement que le client ou l’opérateur peut décrire, puis le suit à travers l’état web, les règles backend et le travail en base au lieu de s’arrêter au premier symptôme visible.
Le compromisCela demande plus d’enquête qu’un correctif sur le premier composant lent, mais évite de déplacer le goulot ou de corriger un symptôme que le client ne rencontrait pas réellement.
Faire de la compatibilité un critère d’acceptation
Une modification n’est acceptée qu’après avoir fonctionné dans l’ERP web et dans les anciens parcours desktop et caisse qui partagent les mêmes données. Procédures stockées, vues, rapports et échanges avec les transporteurs rejoignent ce contrôle lorsque le workflow les traverse.
Le compromisLa surface d’acceptation dépasse le composant modifié, mais une réussite locale ne peut pas devenir silencieusement une panne dans un autre parcours quotidien.
Définir « terminé » dans le parcours réel du client
Les échanges avec le client traduisent une demande en parcours concrets, cas limites et vérifications d’acceptation avant la modification. La livraison est terminée seulement lorsque le résultat rejoint l’usage quotidien, pas lorsqu’un composant fonctionne isolément.
Le compromisCette définition de « terminé » demande du temps de coordination, mais coûte moins cher qu’une interprétation techniquement cohérente qui ne correspond pas au processus retail réel.
Utiliser le support et la formation comme retours de release
Les questions issues du support et de la formation maintiennent les exigences liées à la façon dont les personnes comprennent et accomplissent leur travail. Ces retours orientent la correction ou l’amélioration ciblée suivante.
Le compromisLa responsabilité de livraison se poursuit au-delà du merge, mais les difficultés d’usage deviennent visibles tant qu’elles peuvent encore guider la release suivante.
Livraison et vérification.
Chaque changement était vérifié dans sa couche et dans le parcours opérationnel : procédures stockées et vues, règles .NET, réponses des transporteurs, Crystal Reports et état KnockoutJS devaient s’accorder.
Le travail sur la base exigeait aussi une question de compatibilité : que liront ou écriront l’ERP et la caisse VB6 après cette modification ? Sans migrations, la réponse devait se trouver dans la conception et ne pouvait pas être reportée sur l’automatisation du rollout.
Le retour direct du client complétait la vérification des parcours quotidiens. Un changement techniquement correct n’était pas terminé s’il rendait le travail courant moins compréhensible ou ne correspondait plus à l’opération décrite par les utilisateurs.
Le résultat qualitatif.
Le résultat documenté n’est pas un lancement unique de modernisation, mais une série de changements circonscrits aux fonctionnalités et défauts de l’application, aux procédures et vues SQL Server, à Crystal Reports, à deux intégrations de transporteurs et aux parcours de réception des stocks.
Chaque changement a été vérifié dans le parcours web et, lorsqu’il touchait des enregistrements partagés, par rapport au contrat de données utilisé par l’ERP desktop VB6 et l’application de caisse. L’ERP web a ainsi pu évoluer sans traiter le schéma partagé comme s’il n’avait qu’un seul consommateur.
Cette étude de cas ne revendique aucune hausse mesurée de performance ou de fiabilité. Elle documente la méthode de livraison appliquée au système en activité : retracer le parcours opérationnel avec le client, définir la compatibilité aux frontières concernées et vérifier la tranche complète avant de la considérer comme terminée.
Organisation, produit, utilisateurs, fournisseurs, données commerciales, KPI et dates de livraison sont omis. Les technologies et les frontières d’intégration proviennent du dossier de projet.