Le commercial clique sur « confirmer ». L’écran attend trente secondes, puis affiche une erreur. Il recommence. L’ERP, qui traite chaque commande en quatre-vingt-dix secondes, finit par accepter les deux requêtes. Le portail ne voit aucun résultat, la finance reçoit deux écritures et le support doit deviner laquelle annuler. Accélérer le bouton n’aurait pas résolu le problème.
Un ERP lent ou rigide impose une contrainte de cadence, de contrat et parfois de fenêtre d’ouverture. Le risque apparaît lorsque l’application web prétend fonctionner au rythme de l’ERP tout en promettant une expérience instantanée. Timeouts trop courts, retries agressifs, lectures périmées et files sans limite transforment alors la lenteur en incohérence métier.
Le vrai enjeu n’est pas de rendre l’ERP artificiellement rapide. La bonne architecture sépare prise en charge et décision, persiste l’intention, protège l’idempotence, régule la charge et rend la fraîcheur visible. L’utilisateur obtient une réponse honnête ; l’exploitation sait traiter l’arriéré ; l’ERP conserve les décisions qui lui appartiennent.
Dans une stratégie de développement web sur mesure, cette frontière permet d’améliorer le parcours sans créer un second ERP. Ce guide détaille les choix synchrones et asynchrones, le cache, les modes dégradés, la réconciliation et les seuils qui doivent déclencher une réduction du service.
Mesurer la contrainte réelle de l’ERP
Le diagnostic observe latence médiane et haute, débit soutenable, quotas, fenêtres de maintenance, tailles de lot, verrouillages et variations selon l’opération. Une recherche d’article et une création de facture n’ont pas le même coût. Les mesures portent sur des scénarios représentatifs, avec le réseau, l’authentification et les dépendances réelles.
Il faut distinguer lenteur stable, saturation et comportement imprévisible. Un appel toujours long peut être placé dans un parcours asynchrone. Une latence qui explose sous concurrence nécessite régulation et capacité. Une réponse parfois perdue après effet exige d’abord une clé de recherche et une reprise idempotente. Le remède dépend du profil, pas du seul nombre de secondes.
Chercher les signaux avant l’incident
Les utilisateurs ouvrent plusieurs onglets, rafraîchissent l’écran ou gardent une liste de « commandes à vérifier ». Les tâches planifiées prennent du retard après chaque pic. Les comptes techniques sont multipliés pour contourner un quota. Ces signaux faibles montrent que le système reporte la contrainte sur les personnes ou sur l’ERP au lieu de la réguler.
Séparer promesse utilisateur et réponse ERP
Le produit définit ce qu’il peut promettre avant de choisir un composant technique. « Votre demande est enregistrée » signifie que l’intention est durable et consultable. « Votre commande est acceptée » signifie que l’autorité compétente a rendu sa décision. Confondre les deux conduit à afficher un succès optimiste, puis à demander au support d’expliquer le refus tardif.
Le parcours peut proposer trois sorties : décision immédiate, prise en charge avec suivi ou impossibilité temporaire. Le choix dépend de la réversibilité et de l’engagement. Enregistrer une demande de contact peut attendre ; confirmer un prix ou une disponibilité rare exige parfois une réponse autoritative avant de promettre.
Le délai visible est qualifié, non inventé. Si 95 % des commandes reçoivent un verdict en trois minutes dans un périmètre donné, l’interface peut annoncer cette attente avec prudence. Le seuil n’est ni universel ni permanent : il est mesuré, révisé et accompagné d’une action lorsque la capacité change.
Attribuer chaque décision au bon système
L’ERP peut posséder la validation comptable, la facture, le crédit et le stock officiel d’un établissement. L’application possède le brouillon, la collecte, l’expérience de suivi et parfois une prévalidation distincte. Le connecteur traduit et transporte ; il ne décide pas silencieusement qu’un client est solvable pour éviter un appel lent.
Une projection locale ne devient pas une source d’écriture. Elle contient valeur, version, date de source et statut de qualité. Une correction passe par un cas d’usage adressé au propriétaire. Copier une règle ERP dans l’application pour répondre vite crée deux moteurs dont les écarts apparaîtront au prochain changement de paramétrage.
Nommer les décisions de secours
Lorsque l’ERP est indisponible, le produit décide ce qui reste possible. Une entité peut accepter une intention sous réserve, une autre fermer le parcours. La politique précise périmètre, durée, autorité et information client. Elle ne bascule pas automatiquement vers une table historique dont le sens diffère.
Choisir synchrone ou asynchrone par usage
Le synchrone convient lorsque la décision tient dans le budget du parcours, que l’échec peut être présenté immédiatement et que la dépendance dispose d’une capacité suffisante. Il réduit les états intermédiaires, mais couple la disponibilité. Une lecture ponctuelle ou un contrôle avant engagement peut justifier ce coût.
L’asynchrone convient lorsque l’utilisateur peut poursuivre après une prise en charge durable. Il absorbe les variations et permet de réguler le débit, mais ajoute attente, notification, reprise et observation. Une file ne rend pas l’ERP plus rapide : elle transforme la saturation immédiate en arriéré. Sans limite et sans priorité, elle ne fait que retarder l’incident.
Un modèle hybride est fréquent. L’application valide localement le contrat, persiste l’intention et répond avec un identifiant. Un worker appelle l’ERP. Le portail consulte le statut ou reçoit un événement. Les opérations irréversibles attendent le verdict, tandis que l’utilisateur peut préparer la suite sans croire que la décision est acquise.
Persister l’intention avant l’appel externe
L’intention contient acteur, entité, objet, version, commande, date et clé idempotente. Elle est enregistrée avant l’envoi. Une boîte d’envoi transactionnelle garantit que l’état local et le message sont persistés ensemble, puis un processus publie. Cette séquence ferme le trou où l’écran confirme une demande qui ne sera jamais transmise.
Les états distinguent à transmettre, transmis, accepté, refusé, résultat inconnu et compensé. Une réponse perdue ne passe pas directement en échec. Le système tente d’abord de retrouver l’effet dans l’ERP par une clé stable. Si l’ERP ne permet aucune recherche idempotente, cette limite doit influencer le périmètre et la promesse.
Le message transporte l’identifiant de l’intention et les données nécessaires, pas un objet entier susceptible de vieillir dans la file. Avant traitement, le worker recharge l’état et vérifie que la commande reste pertinente. Une annulation survenue pendant l’attente peut empêcher l’envoi ou déclencher une action distincte.
Borner timeouts, retries et concurrence
Le timeout est plus court que le budget global, mais suffisamment long pour le profil de l’opération. Il inclut connexion, traitement et marge mesurée. Un timeout trop long monopolise les workers ; trop court, il multiplie les appels alors que l’ERP travaille encore. La valeur est testée sous charge et par opération, non copiée depuis une valeur par défaut.
Le retry ne concerne que les erreurs probablement transitoires. Il utilise temporisation, aléa et nombre borné afin d’éviter que tous les workers reviennent simultanément. Le Retry Pattern de Microsoft insiste sur la nature transitoire, l’idempotence et l’impact d’un retry agressif sur un service déjà dégradé.
Un circuit breaker peut arrêter temporairement les appels lorsqu’une dépendance échoue durablement. Il protège les ressources et donne une réponse rapide, sans résoudre l’état des commandes déjà parties. Le Circuit Breaker Pattern distingue bien cette fonction de celle du retry. La réouverture est prudente et observable.
Réguler plutôt que saturer
Le nombre de workers, la taille des lots et les priorités respectent la capacité ERP. Un limiteur répartit les appels et réserve éventuellement une capacité aux opérations critiques. L’arriéré possède une limite ; au-delà, le produit réduit l’acceptation ou allonge explicitement le délai au lieu d’empiler une dette invisible.
Servir une projection avec sa fraîcheur
Pour les lectures fréquentes, une projection locale évite d’appeler l’ERP à chaque page. Elle contient identifiant source, valeur, version, date d’effet, date de synchronisation et qualité. Le cache sert la lecture ; l’écriture continue de passer par l’autorité. Une valeur calculée localement est nommée comme telle.
Le budget de fraîcheur dépend du champ. Un libellé produit peut tolérer plusieurs heures ; un blocage crédit ou un stock tendu exige davantage de prudence. Lorsque le budget est dépassé, l’interface affiche la situation et change de comportement. Elle peut interdire la confirmation, demander une vérification ou proposer un traitement assisté.
Par exemple, si la projection de stock dépasse le seuil décidé pour une référence à forte rotation, alors le backend refuse la réservation immédiate et conserve le panier. Sur une référence abondante, une politique distincte peut autoriser un tampon prudent. Le scénario et son seuil restent liés au débit et au coût d’une promesse rompue.
Contre-intuitivement, un cache plus court peut aggraver la panne en provoquant une avalanche de rafraîchissements. La stratégie prévoit expiration décalée, rafraîchissement en arrière-plan et conservation contrôlée de la dernière valeur. Elle n’utilise une donnée périmée que si la décision produit l’autorise.
Cas concret : confirmer une commande en trois minutes
Cas hypothétique : un distributeur doit confirmer aux commerciaux qu’une commande est prise en compte. L’ERP met entre quarante secondes et quatre minutes selon le nombre de lignes et n’accepte que cinq créations concurrentes. L’ancien portail attendait trente secondes, affichait une erreur et encourageait les doubles clics.
La cible valide le contrat, enregistre l’intention et répond « reçue » avec un identifiant. Une file applique une priorité aux commandes urgentes sans dépasser la capacité. L’ERP reçoit une clé stable. Après timeout, le worker recherche cette clé avant de retenter. Le portail distingue reçu, en validation, accepté et refusé.
Une projection sert articles et clients, mais le crédit reste vérifié par l’ERP. Lorsque la file atteint l’âge défini avec le métier, les nouvelles commandes standard annoncent un délai allongé ; les commandes sensibles passent au canal assisté. Une panne totale ferme l’acceptation qui engagerait le stock, tout en conservant les brouillons.
Le pilote couvre deux équipes et un assortiment. Les critères locaux portent sur zéro double création, une part bornée de résultats inconnus, un âge maximal de file lié à la promesse et un diagnostic réalisable par le support. Ces valeurs sont ajustées selon le volume, la marge et la capacité à contacter le client.
Définir un mode dégradé honnête
Le mode dégradé répond à quatre questions : que peut-on lire, créer, confirmer et annuler ? Une donnée périmée peut rester visible avec sa date, mais ne pas autoriser l’engagement. Une intention peut être conservée en brouillon sans être transmise. Un parcours peut basculer vers une validation humaine si cette équipe existe réellement.
Le repli est segmenté par opération, entité ou produit. Un interrupteur ferme les créations sans bloquer le suivi. Il est audité, limité dans le temps et assorti d’une communication. Le mode n’est pas activé automatiquement sur un signal unique si son impact métier exige un arbitre.
Le retour au nominal traite d’abord les intentions acceptées sous réserve et les résultats inconnus. Il rapproche l’arriéré avant de rouvrir au débit complet. Relancer tous les messages dès que l’ERP répond risque de le saturer à nouveau et de mélanger anciens dossiers et nouvelles commandes.
Rapprocher les effets et traiter l’arriéré
Une balance compare intentions locales, requêtes envoyées, objets ERP et résultats attendus. Elle produit une liste de dossiers absents, en double, divergents ou inconnus avec leur dernière version commune. Le total global ne suffit pas : deux erreurs opposées peuvent s’annuler dans la somme.
La priorité suit le risque : doubles factures, commandes promises sans effet, blocages crédit puis écarts de libellé. Chaque anomalie a un propriétaire, une action et une date. Une correction crée une opération traçable ; elle ne modifie pas directement la table locale pour faire disparaître l’alerte.
Le tableau d’exploitation suit âge des intentions, latence par opération, quota consommé, état du circuit, résultats inconnus, retries et corrections manuelles. Chaque seuil déclenche une action nommée. Une alerte sur la seule moyenne masque souvent la queue longue qui affecte les dossiers complexes.
Outiller la frontière ERP pour l’exploitation
Dans l’architecture Symfony, l’API enregistre l’intention via Doctrine et une boîte d’envoi ; un worker Messenger consomme selon le rate limit de l’ERP. Le cache porte version et fraîcheur. Les tests d’intégration simulent timeout et doublon, tandis que la CI bloque le déploiement si le contrat ou les droits régressent.
L’instrumentation relie dépendance, entrée, sortie et corrélation dans l’observabilité. La journalisation conserve les tentatives sans exposer les secrets. Le runbook précise responsabilités, seuil de repli et ordre de réconciliation ; le rollback ferme une opération sans supprimer les commandes déjà acceptées.
Pour qui cette architecture devient-elle nécessaire ?
Produit, équipe ERP, intégration, exploitation, sécurité et support doivent participer. Le produit définit l’attente acceptable et les modes. L’ERP qualifie contrats et capacité. L’intégration construit la frontière et la reprise. L’exploitation régule et rapproche. Le support valide la lisibilité des statuts et les outils de diagnostic.
Pour une lecture analytique non urgente, un batch peut suffire. Pour une décision financière immédiate, le synchrone autoritatif ou un état d’attente explicite est nécessaire. Une architecture complexe n’est pas une obligation : elle devient pertinente lorsque la cadence web et la capacité ERP divergent durablement.
Erreurs fréquentes face à un ERP lent
Multiplier les workers
Plus de concurrence peut saturer l’ERP et augmenter la latence de tous. Dimensionnez depuis sa capacité et la priorité métier, pas depuis la taille de la file.
Retenter sans rechercher l’effet
Après un timeout, l’ERP peut avoir accepté. Retenter avec une nouvelle clé produit un doublon. La reprise commence par retrouver la décision externe.
Servir le cache comme vérité
Une projection accélère la lecture, mais sa fraîcheur et son propriétaire restent visibles. Elle ne doit pas confirmer une décision sensible que seul l’ERP peut rendre.
Décider l’architecture et ses limites
Bloc de décision. Gardez le synchrone lorsque le verdict est rapide, indispensable et fiable. Utilisez une intention asynchrone lorsque la prise en charge peut précéder le résultat. Servez une projection pour les lectures répétées. Introduisez batch et agrégation lorsque l’ERP préfère les lots et que le délai métier le permet.
Différez l’ouverture si aucune clé ne permet de retrouver un effet après timeout, si l’arriéré n’a pas de limite ou si le retour au nominal n’est pas testé. Refusez une promesse immédiate lorsque le système propriétaire ne peut pas la tenir. Priorisez idempotence, régulation et statuts avant d’optimiser quelques millisecondes côté interface.
- Synchroniser uniquement les décisions qui exigent un verdict immédiat.
- Découpler les traitements longs avec une attente visible.
- Limiter la charge selon la capacité réellement mesurée.
- Fermer le service avant que l’arriéré ne dépasse la promesse récupérable.
Plan d’action en six semaines
Semaines 1 et 2 : mesurer et attribuer
Mesurez opérations, latences, quotas et erreurs sur des dossiers réels. Classez les promesses utilisateur et les décisions ERP. Définissez les clés, résultats, budgets de fraîcheur et seuils de capacité. Le premier livrable relie chaque parcours à son mode nominal et dégradé.
Semaines 3 et 4 : construire et perturber
Persistez les intentions, ajoutez outbox, idempotence, régulation et projection. Provoquez timeout après effet, saturation, réponse tardive et cache périmé. La balance doit retrouver les écarts. Support et exploitation exécutent le diagnostic avec leurs droits.
Semaines 5 et 6 : piloter et étendre
Ouvrez un type d’opération et une entité. Surveillez âge, résultats inconnus, doubles effets et corrections. Jouez le repli et le retour au nominal. Étendez seulement si la promesse reste tenue pendant un cycle représentatif et si l’ERP n’est pas fragilisé par le nouveau débit.
Le bilan rapproche le nombre d’intentions, les effets ERP, l’âge maximal et la charge support. D’abord, l’équipe ferme les résultats inconnus ; ensuite, elle réduit les reprises manuelles ; puis elle augmente progressivement le débit. Une priorité commerciale ne contourne pas le plafond technique sans mode dégradé accepté.
La tranche suivante documente entrées, sorties, dépendances et responsabilités par opération. L’instrumentation contrôle le seuil de file avant acceptation ; le monitoring surveille le circuit et les retries ; le rollback conserve les intentions tandis que le repli désactive seulement les nouvelles écritures.
- Mesurer la contrainte par opération et par période.
- Séparer intention, traitement et décision opposable.
- Tester saturation, timeout, idempotence et reprise.
- Ouvrir progressivement avec limites et mode dégradé.
Guides complémentaires pour l’intégration ERP
Garder les règles au bon endroit
Le guide pour connecter un ERP sans doubler les règles aide à fermer la propriété et les mappings.
Traiter l’asynchrone comme un produit exploitable
Le guide des messages asynchrones approfondit files, priorités, erreurs et reprises lorsque le résultat peut attendre.
- Mesurer la capacité ERP avant de dimensionner les workers.
- Conserver un identifiant retrouvable après chaque timeout.
- Traiter l’arriéré avant de rouvrir le débit nominal.
Conclusion : absorber la latence sans cacher l’incertitude
Un ERP lent n’oblige pas l’utilisateur à attendre devant un écran, mais il interdit de présenter une décision qui n’existe pas encore. La frontière sépare prise en charge, traitement et verdict.
Idempotence, régulation, projection datée et rapprochement protègent le système lorsque la cadence varie. Ils ne remplacent ni la propriété métier ni une promesse produit réaliste.
La qualité se voit pendant la saturation : l’arriéré reste borné, les commandes ne doublonnent pas, le mode dégradé est lisible et le retour au nominal commence par les dossiers exposés.
Dawap peut accompagner la mesure de cette contrainte et construire une trajectoire résiliente dans une stratégie de développement web sur mesure. L’objectif est d’améliorer l’expérience sans mentir sur l’ERP, ni déplacer sa lenteur vers une dette opérationnelle invisible.
