Aller au contenu
XSIS
Parler à un ingénieur

Intégrations

Intégration d’API et de services tiers

API et services tiers reliés, avec les cas d’échec traités

Intégrations REST, SOAP, webhooks et iPaaS avec les CRM, la logistique, la fiscalité, les fournisseurs KYC et d’identité.

Présentation

La plupart des entreprises dépendent de services qu’elles n’exploitent pas elles-mêmes : un CRM, des transporteurs, des plateformes fiscales et de facturation électronique, des fournisseurs d’identité et de KYC, des places de marché et des outils SaaS. Chacun a sa propre API, ses propres limites et sa propre manière d’échouer. Reliés un par un, ils finissent en un ensemble de scripts que personne ne maîtrise entièrement.

Nous concevons et développons des intégrations en REST, SOAP, GraphQL et par webhooks, en direct ou via une plateforme d’intégration comme MuleSoft, Boomi ou Azure Logic Apps. Nous connectons aussi la gestion des identités : authentification unique avec OpenID Connect ou SAML, provisionnement des utilisateurs avec SCIM et accès entre services avec OAuth 2.0.

Chaque appel est conçu pour le jour où l’autre partie tombe en panne. Nous utilisons des requêtes idempotentes, afin qu’une nouvelle tentative ne crée jamais de doublon, des nouvelles tentatives à délais croissants pour les incidents temporaires, et une file des messages en échec avec alertes pour le reste. Les contrats sont écrits, les versions sont gérées, et votre équipe peut voir ce qui a transité et ce qui n’a pas transité.

Ce que nous livrons

  1. Inventaire des intégrations

    Chaque service tiers dont vous dépendez, les données échangées avec lui dans les deux sens et le responsable de chaque liaison.

  2. Contrats d’API

    Des définitions OpenAPI ou WSDL pour chaque interface, avec les règles de champs, les codes d’erreur, les limites et des exemples.

  3. Connecteurs

    Le code ou les flux de plateforme d’intégration qui appellent chaque service et traitent ses rappels (callbacks), développés et testés.

  4. Identité et authentification unique

    La connexion via votre fournisseur d’identité avec OpenID Connect ou SAML, et le provisionnement des utilisateurs avec SCIM lorsqu’il est pris en charge.

  5. Nouvelles tentatives, idempotence et messages en échec

    Des nouvelles tentatives sûres pour les incidents temporaires, une protection contre les doublons sur chaque écriture et une file d’attente pour les messages toujours en échec.

  6. Gestion des versions et politique de changement

    Un schéma de gestion des versions pour les API que vous publiez, et un processus pour absorber les évolutions des API que vous appelez.

  7. Secrets et accès

    Les identifiants et les clés conservés dans un coffre-fort de secrets, limités à chaque intégration et renouvelés selon le calendrier que vous fixez.

  8. Supervision et alertes

    Les traces, les taux d’erreur et la latence par partenaire, avec des alertes qui indiquent quel partenaire a échoué et de quelle manière.

  9. Tests de contrat et d’intégration

    Des tests automatisés sur chaque contrat et dans l’environnement de test de chaque partenaire, exécutés avant chaque mise en production.

Notre méthode

  1. 01

    Faire l’inventaire

    Nous recensons les services dont vous dépendez, les données nécessaires à chacun et les échecs que vous constatez aujourd’hui.

  2. 02

    Concevoir les contrats

    Nous rédigeons les contrats d’API et choisissons, pour chaque flux, entre appels directs, événements et plateforme d’intégration.

  3. 03

    Développer les connecteurs

    Nous développons chaque connecteur avec sa gestion des erreurs, sa protection contre les doublons et sa journalisation dès le départ.

  4. 04

    Tester avec chaque partenaire

    Nous exécutons des tests de contrat et des scénarios de bout en bout dans l’environnement de test de chaque partenaire, y compris les cas d’échec.

  5. 05

    Mettre en production sans risque

    Nous mettons en production derrière des bascules de fonctionnalités (feature flags) ou par étapes, et gardons l’ancien chemin disponible jusqu’à ce que le nouveau ait fait ses preuves.

  6. 06

    Exploiter et adapter

    Nous suivons les taux d’erreur et les messages en échec, et adaptons les connecteurs lorsque les partenaires modifient leurs API.

Comment tout se connecte

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).

Technologies

Données et analytique
  • Apache Kafka
Tests
  • Postman
Intégration
  • REST
  • SOAP
  • GraphQL
  • Webhooks
  • OpenAPI
  • MuleSoft
  • Boomi
  • Azure Logic Apps
  • Apache Camel
  • RabbitMQ
Identité et accès
  • OAuth 2.0
  • OpenID Connect
  • SAML 2.0
  • SCIM
  • Keycloak
  • Microsoft Entra ID
Standards de santé
  • HL7 v2
  • HL7 FHIR

Modes de collaboration

Questions et réponses

Faut-il une plateforme d’intégration ou du code sur mesure ?

Cela dépend du nombre de liaisons et de l’équipe qui les exploitera. Une plateforme d’intégration comme MuleSoft, Boomi ou Azure Logic Apps réunit des connecteurs prêts à l’emploi, la correspondance des données et la supervision en un seul endroit, moyennant un coût de licence. Des services sur mesure vous donnent une maîtrise complète, sans licence, mais davantage de code à maintenir. Nous comparons les deux options pour votre cas et nous appuyons sur une plateforme que vous possédez déjà.

Lien vers cette question
Que se passe-t-il lorsque l’API d’un partenaire est indisponible ?

Les requêtes qui échouent pour des raisons temporaires sont relancées avec des délais croissants. Chaque écriture porte une clé d’idempotence, si bien qu’une nouvelle tentative ne crée jamais une deuxième commande ou facture. Si un message échoue encore, il rejoint une file des messages en échec avec son contenu et l’erreur, une alerte parvient à votre équipe, et il peut être rejoué une fois le partenaire rétabli.

Lien vers cette question
Comment gérez-vous les changements de version des API ?

Les API que vous publiez sont versionnées : nous maintenons les anciennes versions pendant une durée convenue et informons les consommateurs des changements. Pour les API que vous appelez, nous suivons les avis d’obsolescence de chaque partenaire, testons les nouvelles versions dans son bac à sable et migrons avant l’arrêt de l’ancienne version. Les tests de contrat détectent un changement non annoncé avant qu’il n’atteigne la production.

Lien vers cette question
Pouvez-vous connecter notre fournisseur d’identité ?

Oui. Nous mettons en place l’authentification unique avec OpenID Connect ou SAML 2.0 via des fournisseurs comme Microsoft Entra ID ou Keycloak, et provisionnons automatiquement les utilisateurs avec SCIM lorsque l’application le permet. Les services s’appellent entre eux avec des jetons OAuth 2.0 limités à ce dont chacun a besoin. Votre fournisseur d’identité reste le seul endroit où les accès sont accordés et retirés.

Lien vers cette question
Comment gérez-vous les limites de débit ?

Nous étudions les limites publiées par chaque partenaire et concevons en conséquence : regroupement des requêtes lorsque l’API le permet, mise en cache des données qui changent rarement, étalement des tâches planifiées et ralentissement lorsque le partenaire signale qu’une limite est proche. La supervision indique l’écart entre chaque flux et sa limite, afin que la croissance ne se traduise pas en échecs.

Lien vers cette question
Combien de temps faut-il pour intégrer un service tiers ?

Cela dépend de la qualité de l’API et de la documentation du partenaire, de l’existence d’un environnement de test exploitable, de la rapidité d’émission des comptes et des clés, et de la complexité de la correspondance de vos données. Les étapes de validation du partenaire peuvent imposer le rythme. Nous vous remettons un plan par partenaire après l’inventaire et commençons par la liaison qui supprime le plus de travail manuel.

Lien vers cette question
Qu’est-ce qui détermine le coût ?

Le nombre de partenaires et de flux, la qualité de leurs API, la correspondance des données et les règles métier, les besoins de volume et de délai, et les éventuelles licences de plateforme d’intégration. La gestion des identités et la certification auprès d’un partenaire demandent un effort supplémentaire. Nous chiffrons chaque liaison après l’inventaire, afin que vous puissiez choisir l’ordre et voir le coût de chacune.

Lien vers cette question
À qui appartiennent le code et les travaux que vous produisez ?

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. Cela couvre le code spécifique, la documentation et les autres livrables réalisés pour vous. Les éléments préexistants que nous apportons, tels que des outils internes ou des bibliothèques, restent notre propriété, et vous recevez une licence pour les utiliser dans vos systèmes. Les composants open source conservent leurs propres licences, et nous vous en fournissons la liste.

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