Un ERP accepte une commande seulement après le traitement nocturne du crédit client. Le commerce promet pourtant une réponse en moins de dix minutes et l’équipe logistique doit réserver un créneau avant midi. La tentation est d’ajouter dans l’application web une copie du plafond, du statut client et de la règle de validation. Six mois plus tard, deux moteurs décident et personne ne sait lequel justifie le refus.
L’ERP n’est pas nécessairement mal conçu. Il peut protéger la comptabilité, le référentiel articles ou les écritures avec une cadence compatible avec sa mission. L’application métier sert, elle, un parcours plus rapide, une collaboration ou une exception que l’ERP ne modélise pas. Les symptômes sont concrets : blocages sans motif, correction manuelle écrasée, retard client, charge support et dette invisible. Le problème vient moins de la différence de cadence que de l’absence de frontière : lectures directes, tables tampon sans propriétaire et règles copiées pour tenir une date.
Le vrai enjeu est de compléter une capacité sans créer un second ERP caché. Il faut nommer les décisions détenues par chaque système, traduire les concepts, enregistrer les intentions et rapprocher les résultats. La reprise doit rester possible lorsque l’ERP est lent, refuse une écriture ou renvoie une réponse ambiguë.
Dans un projet de développement web sur mesure, cette discipline transforme une contrainte historique en contrat exploitable. Ce guide montre comment diagnostiquer la limite, isoler l’adaptation, choisir les flux, tester un mode dégradé et décider si le complément doit rester, évoluer ou préparer un remplacement.
Distinguer limite ERP et besoin métier
Partir d’un dossier, pas d’un jugement sur l’outil
Prenez un cas qui échoue : utilisateur, action, données disponibles, résultat attendu, réponse ERP et correction appliquée. Une limite peut être fonctionnelle, par exemple aucun statut pour une validation intermédiaire ; temporelle, comme un export toutes les nuits ; contractuelle, avec une API qui refuse certains champs ; ou opérationnelle, lorsque seuls deux experts savent relancer un lot.
Mesurez l’impact sans confondre inconfort et rupture. Combien de dossiers attendent ? Quelle marge, quelle obligation ou quel délai client est exposé ? Combien de minutes le support consacre-t-il à reconstruire le contexte ? Une demande d’écran plus moderne ne justifie pas le même investissement qu’une commande perdue ou une écriture financière non rapprochée.
Vérifier si la limite est réellement durable
Une API non activée, un module déjà prévu ou une mauvaise utilisation peut rendre le développement inutile. Interrogez l’éditeur et l’équipe ERP sur les contrats supportés, les versions, les quotas et la feuille de route, puis consignez la réponse. À l’inverse, une personnalisation profonde de l’ERP peut coûter davantage et compliquer les mises à jour ; la décision compare coût complet, réversibilité et exploitation.
Attribuer les règles au bon système
Écrivez une matrice par décision. L’ERP peut être propriétaire de la création comptable du client, du plan de comptes et de la facture. L’application métier peut posséder la collecte documentaire, l’avis d’un responsable et le brouillon de demande. Le connecteur traduit l’intention et transporte la réponse ; il ne décide pas silencieusement qu’un client est solvable.
Une donnée répliquée ne devient pas une donnée possédée. L’application peut conserver le code client, le statut et leur version pour afficher vite, mais elle les présente comme une projection de l’ERP. Une correction passe par un cas d’usage autorisé ou une demande de changement. Écrire directement dans la base ERP contourne validations, audit et support éditeur.
Contre-intuitivement, laisser une étape manuelle explicite peut être plus sûr qu’une automatisation partielle. Si cinq dossiers mensuels exigent un arbitrage fiscal complexe, un geste tracé avec une échéance vaut mieux qu’une heuristique non détenue. L’automatisation devient prioritaire lorsque volume, répétabilité et preuve justifient son coût.
Protéger le domaine par un adaptateur
L’application ne devrait pas parler le dialecte ERP dans toutes ses classes. Une couche d’adaptation transforme un « dossier prêt à facturer » en code société, type de pièce, conditions de paiement et lignes attendues. Au retour, elle convertit les codes techniques en résultats métier : accepté, en attente, refusé avec motif ou inconnu. Le domaine reste lisible si l’ERP change de version ou si une deuxième instance apparaît.
Le modèle rejoint le principe d’Anti-Corruption Layer documenté par Microsoft : une façade ou un adaptateur isole les sémantiques de deux sous-systèmes. La source officielle rappelle aussi les coûts de cette couche, notamment latence, exploitation et cohérence. Elle n’est donc ni une excuse pour ajouter un microservice ni un endroit où cacher les règles sans propriétaire.
L’adaptateur possède des mappings versionnés et testés avec des exemples opposables. Une valeur inconnue échoue clairement au lieu de choisir un défaut commode. Les codes pays, unités, devises et statuts utilisent une table dont chaque ligne porte source, cible, date d’effet et responsable. Les logs n’exposent ni secret ni donnée personnelle inutile.
Choisir les lectures et écritures autorisées
Lire une projection avec son âge
Pour l’affichage et la recherche, une copie locale peut réduire la dépendance et la latence. Chaque enregistrement garde l’identifiant ERP, la version ou date source, l’heure de synchronisation et l’état de qualité. Une page signale qu’une donnée est périmée lorsque cette information change la décision. Le budget de fraîcheur dépend du champ : une raison sociale tolère parfois une journée, un blocage crédit quelques minutes.
Écrire une intention avant l’effet externe
L’application enregistre d’abord la commande métier, son identifiant idempotent et le statut « à transmettre ». Un worker appelle ensuite l’ERP et rattache réponse, tentative et corrélation. Un timeout ne signifie pas échec : l’ERP a peut-être accepté avant la coupure. La reprise interroge le résultat par clé stable avant toute nouvelle création.
Une opération non idempotente reçoit une protection spécifique. La documentation actuelle de Symfony Messenger rappelle qu’un message peut être livré plusieurs fois et recommande des handlers idempotents ou une clé stable dérivée de l’événement métier. Cette contrainte appartient au contrat, pas seulement à la configuration de la file.
Découpler les cadences sans perdre les effets
L’asynchrone convient lorsque l’utilisateur peut recevoir un accusé de prise en charge avant le résultat ERP. Il absorbe un quota, une indisponibilité ou un traitement long. Il ne convient pas si le parcours exige une décision immédiate pour engager de l’argent sans mode d’attente clair. Le produit choisit la promesse avant que la technique choisisse la file.
Le message transporte l’identifiant de l’intention et sa version, pas un objet métier entier susceptible de vieillir. Le handler recharge l’état autorisé, vérifie que l’action est toujours pertinente et écrit un résultat. Un retry avec temporisation traite les erreurs transitoires ; une erreur fonctionnelle passe dans une file d’analyse sans être rejouée indéfiniment.
La boîte d’envoi transactionnelle ferme le risque entre l’enregistrement local et la publication. Le consommateur déduplique. Une file d’échec conserve motif, nombre de tentatives et prochaine action. Le support peut relancer un élément ou un lot borné, jamais « tout rejouer » sans comprendre les effets déjà produits.
Cas concret : une promesse de livraison avant le batch ERP
Un industriel reçoit des commandes jusqu’à 16 h pour une expédition le lendemain. Son ERP calcule la disponibilité à 22 h et ne sait pas réserver un créneau de quai. Les commerciaux maintiennent donc un tableur, puis ressaisissent les commandes acceptées. Les doubles réservations apparaissent lorsque deux équipes traitent le même stock ou lorsqu’une annulation n’est pas reportée.
L’application métier possède la demande, le créneau et l’approbation commerciale. Elle lit une projection de stock issue du dernier calcul ERP, applique un tampon décidé par famille et enregistre une réservation opérationnelle. Elle ne produit ni facture ni mouvement comptable. À 22 h, l’ERP confirme ou refuse ; l’application rattache le résultat et ouvre une tâche si la promesse ne peut être tenue.
Chaque intention utilise la clé commande, version et société. Le connecteur traduit unités, dépôt et code client, puis cherche l’écriture ERP existante après un timeout. La projection affiche son âge. Lorsque le flux dépasse vingt minutes sur une famille tendue, la nouvelle réservation est suspendue ; sur une famille abondante, le tampon est renforcé. Ces valeurs sont locales et réévaluées avec le débit réel.
Prouver l’intérêt sur un pilote borné
Le pilote couvre une société, deux commerciaux, cinquante références et un cycle de facturation. L’équipe rejoue une annulation tardive, un code article inconnu, un timeout après acceptation et un refus crédit. Le support doit expliquer chaque statut depuis l’identifiant de commande et reprendre sans modifier directement l’ERP.
Le go est conditionné à zéro création double, moins de 1 % de dossiers sans mapping traité automatiquement et moins de quinze minutes pour diagnostiquer une divergence. Ces seuils d’exemple ne deviennent pas une norme : le sponsor les relie à la marge, au volume et à la capacité de contact client. Une preuve contraire réduit le périmètre.
Rapprocher les états sans les écraser
Une balance compare intentions locales, résultats ERP et objets attendus. Elle ne se contente pas d’un nombre total : elle produit la liste des absents, doublons, montants ou statuts divergents avec leur dernière version commune. Chaque écart reçoit une catégorie, un responsable, une date et une procédure.
Le rapprochement traite d’abord le risque métier. Une facture dupliquée ou une commande promise sans écriture passe avant une différence de libellé. L’ajustement conserve la trace avant et après. Si l’ERP corrige une donnée, la projection locale attend sa version officielle plutôt que de fabriquer une convergence visuelle.
Les corrections récurrentes deviennent un signal de conception. Trois mappings manuels par mois peuvent rester acceptables si le coût est faible et la preuve bonne. Trente interventions quotidiennes indiquent que le contrat, le référentiel ou la règle de propriété doit évoluer. La revue compare charge support, impact et coût d’industrialisation.
Préparer panne, retard et indisponibilité
Le mode dégradé décrit ce que l’utilisateur peut lire, créer, modifier ou annuler lorsque l’ERP ne répond pas. Une demande peut rester en brouillon, être acceptée sous réserve ou être refusée. Le choix dépend de la réversibilité. Il est souvent raisonnable d’enregistrer un commentaire ; il est dangereux de promettre une limite de crédit inconnue.
Chaque mode porte une durée maximale, un périmètre, une information visible et une autorité de sortie. Le retour au nominal commence par les intentions acceptées pendant la panne, puis rapproche les réponses avant de rouvrir. Rebrancher les flux sans traiter l’arriéré mélange les nouvelles commandes et les anciennes incertitudes.
Un interrupteur permet de fermer une opération ou une société sans arrêter l’application entière. Il est audité, expire et ne remplace pas la supervision. Le runbook précise qui déclenche, qui informe, qui réconcilie et quelle preuve clôt l’incident.
Instrumenter les contrats et la reprise
La mise en œuvre décrit les entrées, les sorties, les dépendances, la responsabilité et les seuils de chaque flux. L’instrumentation relie intention, message, appel ERP et résultat par une corrélation stable. La journalisation conserve version de mapping, latence, retry et motif de repli. Un tableau sans ces liens mesure une file, pas une promesse métier.
Le rollback interdit les nouvelles écritures sur le chemin cible, laisse terminer les transactions connues et bascule vers le repli documenté. La sortie de crise exige une balance, une file d’échec vide ou qualifiée et une validation du responsable. Le monitoring alerte sur âge, volume, échec fonctionnel et saturation, avec un seuil qui déclenche une action nommée.
Les tests couvrent contrat, mapping, concurrence et sécurité. Une donnée inconnue est refusée ; une réponse tardive ne remplace pas une version récente ; un même message ne crée pas deux effets ; un utilisateur ne consulte que sa société. La recette utilise des identifiants proches de la production sans recopier de données sensibles.
Pour qui cette architecture devient utile
La méthode concerne les directions métier et SI qui ajoutent un portail, un workflow, une mobilité terrain ou une collaboration autour d’un ERP difficile à modifier. Le product owner possède le parcours et les règles ajoutées. L’équipe ERP possède ses objets, ses contraintes et les écritures. L’intégration possède traduction, disponibilité et diagnostic. L’exploitation valide le mode dégradé.
Pour un besoin purement analytique, un entrepôt de données ou une vue de lecture suffit peut-être. Pour une règle standard déjà couverte par un module ERP, paramétrer ce module évite un doublon. Le complément sur mesure devient pertinent lorsque la valeur tient à une expérience, une cadence ou une collaboration absente, et que la frontière peut être financée dans la durée.
La démarche serait excessive pour une exportation ponctuelle sans conséquence opérationnelle. Elle devient indispensable dès que l’application prend une décision, engage une commande, transforme une donnée opposable ou doit survivre à une indisponibilité.
Erreurs fréquentes autour de l’ERP
Copier une règle pour aller plus vite
Une copie non détenue diverge au prochain changement de seuil. Si l’application a besoin d’une prévalidation, donnez-lui un nom et un résultat distincts. L’ERP conserve sa validation officielle. Une équivalence supposée doit être prouvée par contrat, pas par deux conditions qui se ressemblent.
Utiliser une table partagée comme API
La lecture directe couple au schéma, contourne les droits et rend les mises à jour risquées. Une vue officiellement supportée peut convenir à la lecture, avec version et fraîcheur. L’écriture passe toujours par un contrat qui garantit validations et audit.
Confondre retry et reprise
Relancer cent fois une erreur fonctionnelle augmente le bruit et peut répéter un effet. Le retry traite une panne transitoire ; la reprise identifie l’état externe, décide et trace. Une file d’échec sans owner devient un nouvel outil de contournement.
Arbitrer complément, extension ou remplacement
Bloc de décision. Complétez l’ERP lorsque sa mission reste stable, que la nouvelle capacité possède un périmètre clair et que l’adaptation est exploitable. Étendez-le lorsque le besoin est standard, supporté par l’éditeur et moins coûteux dans son cycle complet. Préparez un remplacement lorsque les frontières se multiplient, que les données ne sont plus accessibles ou que chaque évolution exige une correction parallèle.
Si le besoin appartient au standard éditeur et que son calendrier convient, alors privilégiez le module maintenu plutôt que sa copie locale. En revanche, une collaboration distinctive et réversible peut rester dans l’application métier. À éviter : transformer l’adaptateur en moteur de règles uniquement parce qu’il est plus facile à déployer.
Différez la livraison si personne ne possède le mapping, si le résultat d’un timeout est inconnu ou si le rollback exige une correction en base. Refusez le temps réel lorsqu’un accusé d’attente tient la promesse et réduit le couplage. Priorisez la chaîne qui protège argent, engagement client et preuve avant les écrans de confort.
- Choisir le module ERP pour une capacité standard et durablement supportée.
- Choisir l’application métier pour une expérience ou une collaboration réellement distincte.
- Choisir un adaptateur pour traduire les concepts, jamais pour cacher une règle orpheline.
- Choisir le remplacement si le coût des frontières dépasse la valeur du système conservé.
Plan d’action sur quatre semaines
Semaines un et deux : fermer le contrat
Sélectionnez dix dossiers, dont un refus, une annulation, un doublon suspect et une panne. Dessinez les décisions et les données, puis attribuez chaque verbe. Relevez les accès directs, tableurs et corrections. Mesurez le temps utile et le risque exposé. Le dossier de cadrage contient les réponses de l’équipe ERP et les alternatives standard étudiées.
Définissez l’intention locale, la clé idempotente, le mapping versionné et les résultats possibles. Écrivez les erreurs avant le code : inconnu, refus fonctionnel, indisponible, timeout et conflit de version. Associez chacune à un comportement utilisateur et une action de run.
Semaines trois et quatre : observer puis ouvrir
Faites tourner l’adaptateur en observation ou sur des copies de messages autorisées. Comparez les mappings et les verdicts sans produire d’écriture. Provoquez réponse tardive, doublon et rupture réseau après acceptation. Le support doit retrouver l’effet externe et rapprocher le dossier depuis la corrélation.
Ouvrez un type d’opération et un périmètre. Le rollback ferme le nouveau chemin sans effacer les intentions acceptées. Exécutez un cycle de rapprochement et une astreinte simulée. Étendez lorsque les seuils locaux sont tenus, que les erreurs inconnues diminuent et que la reprise ne dépend plus d’un expert unique.
- Qualifier la limite et vérifier les options officiellement supportées.
- Attribuer règles, données, erreurs et décisions de secours.
- Tester adaptation, idempotence, timeout et réconciliation en observation.
- Ouvrir un périmètre réversible et décider depuis les preuves du run.
Approfondir intégration et exploitation
Connecter sans doubler le métier
Le guide connecter un ERP sans doubler les règles métier prolonge le travail sur propriété, mappings et contrats.
Choisir les traitements asynchrones
Pour dimensionner files, retries et reprise, poursuivez avec les usages pertinents des messages asynchrones. Les deux lectures doivent être testées sur un timeout après acceptation, un mapping inconnu et une écriture rejouée.
- Relier le contrat d’intégration à une décision métier nommée.
- Vérifier les options de l’ERP avant de construire un doublon.
- Exécuter la reprise avec les accès du support et une balance de contrôle.
Conclusion : compléter sans contaminer
Une application métier peut absorber une limite de l’ERP sans absorber sa sémantique entière. Elle possède ses intentions, ses workflows et sa promesse ; l’ERP conserve les décisions qui relèvent de son domaine. L’adaptateur traduit, journalise et rapproche.
La frontière est crédible lorsque les équipes savent expliquer un refus, retrouver un effet après timeout, rejouer sans doublon et travailler pendant une indisponibilité. La réconciliation ferme les écarts ; elle ne maquille pas les soldes.
Commencez par un dossier coûteux, un contrat étroit et un pilote réversible. Mesurez la charge support, les délais et les erreurs inconnues. Si la couche d’adaptation grossit plus vite que la valeur livrée, le bon arbitrage peut devenir l’extension standard ou le remplacement progressif.
- Une règle, un propriétaire.
- Une intention, un identifiant stable.
- Un écart, une reprise vérifiable.
Dawap peut accompagner ce chantier de développement web sur mesure : diagnostic ERP, frontière de domaine, adaptateurs, workflows asynchrones, réconciliation et préparation du run.
