Aller au contenu
XSIS
Parler à un ingénieur

Intégrations

ERP et services tiers

De l’ERP aux services tiers : CRM, logistique, fiscalité et identité

Des connexions REST, SOAP, webhook et iPaaS entre votre ERP et les services qui l’entourent, avec nouvelles tentatives et alertes.

Schéma

De l’ERP aux tiers : une plateforme, de nombreux partenairesLes événements métier quittent l’ERP une seule fois, et la plateforme d’intégration les remet à chaque partenaire dans le format qu’il attend. Les rappels (callbacks) suivent le même chemin. Un message encore en échec après ses nouvelles tentatives rejoint une file des messages en échec et déclenche une alerte, contenu du message joint.ERPERPClients, commandes,facturesXSISPlateformed’intégrationiPaaS ou services surmesure, mapping etnouvelles tentativesTiersCRMComptes, contacts etopportunitésTiersLogistique ettransporteursExpéditions et suiviTiersPlateforme defacturationélectronique etfiscalitéValidation etdéclarationTiersFournisseur KYC etd’identitéVérification et filtrageServiceFile des messagesen échec et alertesRien n’est perduPersonnesÉquipe de support1REST · ODatawebhook2REST/JSON3REST/JSON4webhook5SOAP/XML · REST6REST/JSON7webhook89

De l’ERP aux tiers : une plateforme, de nombreux partenaires

Les événements métier quittent l’ERP une seule fois, et la plateforme d’intégration les remet à chaque partenaire dans le format qu’il attend. Les rappels (callbacks) suivent le même chemin. Un message encore en échec après ses nouvelles tentatives rejoint une file des messages en échec et déclenche une alerte, contenu du message joint.

  • Flux principal
  • Asynchrone
  • Chemin d’exception

Le flux, étape par étape

  1. Source ERP, destination Plateforme d’intégration : Événements métier, via REST · OData · webhook (flux principal).
  2. Source Plateforme d’intégration, destination CRM : Clients et commandes, via REST/JSON (flux principal).
  3. Source Plateforme d’intégration, destination Logistique et transporteurs : Expéditions réservées, via REST/JSON (flux principal).
  4. Source Logistique et transporteurs, destination Plateforme d’intégration : Événements de suivi, via webhook (asynchrone).
  5. Source Plateforme d’intégration, destination Plateforme de facturation électronique et fiscalité : Factures à valider, via SOAP/XML · REST (flux principal).
  6. Source Plateforme d’intégration, destination Fournisseur KYC et d’identité : Vérifications d’identité, via REST/JSON (flux principal).
  7. Source Fournisseur KYC et d’identité, destination Plateforme d’intégration : Résultats des vérifications, via webhook (asynchrone).
  8. Source Plateforme d’intégration, destination File des messages en échec et alertes : Échec après plusieurs tentatives, vers la file des messages en échec (chemin d’exception).
  9. Source File des messages en échec et alertes, destination Équipe de support : Alerte avec le contenu du message et l’erreur (chemin d’exception).

Présentation

Voici le flux entre votre ERP et les services qui l’entourent : le CRM, les transporteurs et prestataires logistiques, les plateformes de facturation électronique et de fiscalité, et les prestataires d’identité et de KYC. Chaque partenaire a sa propre API, son propre format et ses propres défaillances, et chacun fait généralement l’objet d’un projet distinct.

L’architecture de référence émet une seule fois chaque événement métier de l’ERP vers une plateforme d’intégration, qui le transmet à chaque partenaire dans le format attendu, en REST, SOAP, par webhooks, ou en EDI sur AS2 lorsque les partenaires commerciaux l’exigent. Les retours, comme les événements de suivi ou les résultats de contrôle, reviennent par la même plateforme.

L’indisponibilité d’un partenaire est un événement normal, et non une urgence. Les échecs temporaires font l’objet de nouvelles tentatives. Un message toujours en échec après ses nouvelles tentatives est placé dans une file des messages en échec, et une alerte parvient à l’équipe de support avec le contenu du message et l’erreur, afin qu’il puisse être corrigé et rejoué.

Fonctionnement du flux

  1. 01

    L’ERP publie un événement

    Lorsqu’un client, une commande ou une facture change, l’ERP publie un événement métier unique vers la plateforme d’intégration, via son API, ses services OData ou des webhooks.

  2. 02

    Le CRM reste à jour

    La plateforme met à jour les comptes, les contacts et les commandes dans le CRM, afin que les équipes commerciales et de service client voient ce que l’ERP connaît.

  3. 03

    Les expéditions sont réservées

    Les commandes prêtes à expédier sont réservées auprès du transporteur ou du prestataire logistique via son API, et les étiquettes et références sont renvoyées.

  4. 04

    Le suivi revient

    Le transporteur envoie les événements de suivi et de preuve de livraison par webhook, et la plateforme met à jour la commande dans l’ERP.

  5. 05

    Les factures sont validées

    Les factures sont transmises à la plateforme de facturation électronique ou de fiscalité dans le format exigé par l’administration, et le statut de validation est conservé avec la facture.

  6. 06

    Les identités sont vérifiées

    Les nouveaux clients ou fournisseurs sont transmis au prestataire de KYC ou d’identité, et le résultat revient par webhook avant l’activation du compte.

En cas d’erreur

Un partenaire est temporairement indisponible

L’appel est relancé avec des délais croissants. Une clé d’idempotence sur chaque écriture garantit qu’une nouvelle tentative ne crée jamais une seconde expédition ou une seconde facture.

Un message échoue encore après ses nouvelles tentatives

Il est placé dans une file des messages en échec avec son contenu et l’erreur du partenaire, et l’équipe de support est alertée. Une fois corrigé, il est rejoué depuis la file.

Un partenaire modifie son API

Des tests de contrat exécutés sur l’environnement de test de chaque partenaire détectent la modification. Les changements annoncés sont planifiés et testés avant l’échéance fixée par le partenaire.

Les données sont rejetées

Un partenaire qui refuse des données pour un motif métier, comme un numéro fiscal manquant, renvoie l’erreur sur l’enregistrement de l’ERP, où son responsable peut la corriger.

Standards et systèmes

Intégration
  • REST
  • SOAP
  • Webhooks
  • OpenAPI
  • EDI (EDIFACT, ANSI X12)
  • AS2
  • MuleSoft
  • Boomi
  • Azure Logic Apps
Identité et accès
  • OAuth 2.0

Questions et réponses

Quels services tiers pouvez-vous connecter ?

Tout service doté d’une API ou d’une interface de fichiers documentée. Exemples courants : plateformes CRM, transporteurs et prestataires logistiques, places de marché, plateformes de facturation électronique et de fiscalité, paie, prestataires de KYC et d’identité, et partenaires commerciaux qui échangent des documents EDI sur AS2. Nous examinons l’API, les limites et l’environnement de test de chaque partenaire avant de nous engager sur un plan.

Lien vers cette question
Avons-nous besoin d’une plateforme d’intégration ?

Dès que plusieurs partenaires sont connectés à un même ERP, une plateforme telle que MuleSoft, Boomi ou Azure Logic Apps, ou un ensemble de services spécifiques construits sur une file de messages, regroupe la transformation des données, les nouvelles tentatives et la supervision en un seul endroit. Avec un ou deux partenaires, des connexions directes peuvent suffire. Nous présentons les compromis, y compris le coût des licences, adaptés à votre situation.

Lien vers cette question
Pouvez-vous nous connecter aux plateformes de facturation électronique et de validation fiscale ?

Oui. De nombreux pays exigent désormais que les factures soient émises ou validées via une plateforme publique ou agréée, dans un format défini. Nous intégrons l’ERP à la plateforme exigée dans votre pays ou à un prestataire agréé, conservons le statut de validation et les identifiants avec chaque facture, et traitons les rejets. Vos conseillers fiscaux confirment les règles qui vous sont applicables.

Lien vers cette question
Comment sécurisez-vous les webhooks entrants ?

Chaque webhook entrant est vérifié avant d’être traité : par signature lorsque le partenaire signe ses messages, et par contrôle du jeton, de la source et de l’horodatage dans le cas contraire. Le contenu est validé au regard du contrat d’interface, et chaque événement n’est traité qu’une seule fois, même si le partenaire l’envoie plusieurs fois.

Lien vers cette question
Que se passe-t-il lorsqu’un partenaire subit une panne ?

Les autres flux continuent de fonctionner. Les messages destinés à ce partenaire sont relancés puis mis en file d’attente, l’équipe de support est alertée, et rien n’est perdu. Lorsque le partenaire est rétabli, les messages en attente sont rejoués dans l’ordre. Le tableau de bord indique quel partenaire est concerné et combien de messages sont en attente.

Lien vers cette question
À qui appartiennent les connecteurs que vous développez ?

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Les connecteurs vous sont livrés avec leur code source, leurs tests et leur documentation, afin que votre équipe ou un autre prestataire puisse les maintenir. Les outils XSIS préexistants restent notre propriété et vous sont concédés sous licence. Les API des partenaires et les licences des plateformes d’intégration restent soumises aux conditions propres de leurs éditeurs.

Lien vers cette question

Dites-nous ce que vous devez construire ou connecter.

Décrivez les systèmes, le calendrier et les contraintes. Les ingénieurs concernés prennent ensuite le relais.

  • Notre équipe vous appellera dans les 24 heures, sur le créneau de votre choix
  • Notre équipe est disponible 24 h/24, 7 j/7