Le point de départ.
L’ERP soutenait les opérations retail quotidiennes. La fiabilité était donc une exigence produit, pas une note de maintenance. Chaque changement devait améliorer le système tout en préservant le travail existant.
Les performances, les intégrations et le comportement de l’interface étaient liés. Traiter une couche isolément n’aurait fait que déplacer le problème ailleurs dans le parcours de la requête.
Ce que le travail devait respecter.
Un ERP opérationnel laisse peu de place aux changements imprudents :
- Les workflows existants devaient continuer à soutenir le travail retail quotidien.
- Base de données, backend et frontend devaient évoluer ensemble lorsque le contrat changeait.
- Les intégrations devaient rester compréhensibles à la frontière du système.
- Le travail de performance devait suivre le parcours réel, pas un symptôme isolé.
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.
J’ai travaillé sur ce parcours complet. SQL Server, les services .NET et l’interface web ont été traités comme les éléments d’un même comportement, y compris la frontière d’intégration.
La vue utile du système.
L’unité de changement pertinente était la requête de bout en bout : une action dans le frontend, les règles applicatives en .NET, le travail de données dans SQL Server et l’échange à la frontière d’intégration.
Les décisions importantes.
Le travail a privilégié une évolution contrôlée plutôt qu’une réécriture spectaculaire.
Suivre toute la requête
Le travail sur la performance et la fiabilité part du comportement visible et le suit à travers le backend jusqu’à la base de données.
Cela demande plus d’enquête qu’un correctif sur le premier composant lent, mais évite de simplement déplacer le goulot d’étranglement.
Modifier les contrats avec soin
Lorsque les données ou le comportement backend changent, le frontend et les intégrations ont besoin d’un contrat explicite et compatible.
Le travail de compatibilité rend le changement moins spectaculaire, mais protège les opérations qui dépendent déjà du système.
Améliorer par tranches livrables
Des changements ciblés sont plus faciles à comprendre dans un système critique et rendent l’effet de chaque version plus clair.
La livraison progressive exige de la patience et des frontières précises. Elle garde aussi le risque visible.
Livraison et vérification.
Chaque changement peut être vérifié dans sa couche, puis dans le parcours utilisateur qu’il soutient. Le comportement de la base de données, les règles backend, les réponses d’intégration et l’état frontend doivent s’accorder.
Cette vérification de bout en bout compte surtout sur les parcours quotidiens. Un changement techniquement correct n’est pas terminé s’il rend le travail courant moins compréhensible ou moins fiable.
Le résultat qualitatif.
Performances, intégrations et fiabilité quotidienne ont progressé ensemble parce que le travail a traversé les frontières où ces sujets se rejoignaient.
Le système a continué d’évoluer sans prétendre qu’un ERP critique pouvait être arrêté et remplacé d’un seul geste. La voie pragmatique consistait à le comprendre, l’améliorer et le garder utile pendant tout le processus.