Aller au contenu principal
FromNine
Menu

Ingénierie

Intégration API et interopérabilité : des données qui circulent sans rupture

Nous connectons CRM, ERP, systèmes de gestion de dossiers et plateformes publiques au moyen de contrats, d’événements et d’une gestion des identités rigoureuse, pour que les données circulent de façon fiable, que les erreurs soient visibles et que de nouvelles capacités, IA comprise, puissent s’y brancher en toute sécurité.

Pour les organisations qui raccordent leurs systèmes aux services de base fédéraux et régionaux, ainsi qu’au réseau Peppol.

Échanger sur votre projetDécouvrir notre approche
Intégrations et API : les couches de la solutionQuatre couches superposées en profondeur. De haut en bas : les consommateurs tels que portails, applications et agents, la passerelle d’API et l’identité, le socle événementiel, et en dessous les systèmes de référence.01Portails, applications et agents02Passerelle d’API et identité03Socle événementiel04Systèmes de référence
  1. 01Des API conçues contrat d’abord avec OpenAPI et AsyncAPI, versionnées et documentées
  2. 02Des événements avec ordonnancement, idempotence, gestion des messages en échec et rejeu
  3. 03Chaque flux supervisé, chaque file d’erreurs confiée à une équipe désignée

01 Enjeux

Les problèmes d’intégration pour lesquels nos clients nous sollicitent

  1. 01

    Des liaisons point à point que personne n’ose modifier

    Des dizaines de connexions directes entre CRM, ERP et applications spécifiques. Modifier un champ oblige à tester dix interfaces.

  2. 02

    Doublons et échecs silencieux

    Une nouvelle tentative crée une seconde commande. Un message en échec disparaît. Les équipes métier l’apprennent par les clients.

  3. 03

    Chaque nouveau canal exige un nouveau chantier d’intégration

    Le portail, l’application mobile et désormais un assistant IA ont besoin des mêmes données, et chacun reçoit sa propre extraction.

  4. 04

    Les échanges avec les administrations sont un projet à part entière

    Se connecter à une plateforme nationale d’échange de données ou à un dispositif d’identité électronique demande à chaque fois des mois de travail de sécurité et d’habilitation.

02 Prestations

Ce que nous livrons

  1. 01 Stratégie et gestion des API

    Une conception API first avec des contrats OpenAPI et AsyncAPI, une politique de versionnage, une passerelle qui l’applique et un portail développeurs pour que les équipes trouvent et réutilisent l’existant.

    Ce que nous faisons

    • Cartographie des API et de leurs responsables
    • Règles de conception et processus de revue
    • Politiques de passerelle pour la sécurité, les quotas et le versionnage
    • Portail développeurs et catalogue d’API

    Ce que vous recevez

    • Règles de conception d’API adoptées par vos équipes
    • Configuration de la passerelle en code
    • Catalogue d’API documentées

  2. 02 Intégration orientée événements

    Brokers, capture des changements (CDC) et pattern outbox, avec les détails qui décident du succès : ordonnancement, consommateurs idempotents, gestion des messages en échec et rejeu.

    Ce que nous faisons

    • Modèle d’événements et conventions de nommage
    • Outbox et CDC sur les systèmes sources
    • Idempotence des consommateurs et garanties d’ordonnancement
    • Files de messages en échec (dead-letter) avec outillage de rejeu

    Ce que vous recevez

    • Socle événementiel en production
    • Registre de schémas et règles de compatibilité
    • Procédure de rejeu et de reprise

  3. 03 Des plateformes d’intégration choisies avec honnêteté

    SAP Integration Suite, MuleSoft et les services d’intégration natifs du cloud ont chacun leur place. Nous vous disons quand une iPaaS l’emporte sur du code spécifique, et quand ce n’est pas le cas.

    Ce que nous faisons

    • Évaluation du middleware existant
    • Choix de plateforme fondé sur le coût total de possession
    • Mappings et connecteurs réutilisables
    • Migration depuis un middleware hérité

    Ce que vous recevez

    • Dossier de décision sur la plateforme d’intégration
    • Bibliothèque de patterns d’intégration
    • Plan de migration des interfaces existantes

  4. 04 Identité et confiance entre systèmes

    OAuth 2.0 et OpenID Connect, TLS mutuel, identités de service à service, et intégration des identités électroniques des citoyens et des entreprises : itsme, DigiD et eHerkenning, BundID, FranceConnect, Cl@ve, SPID et CIE.

    Ce que nous faisons

    • Architecture d’identité pour les utilisateurs et les services
    • Conception des jetons, des périmètres (scopes) et du consentement
    • Accompagnement à l’habilitation et à la certification eID
    • Préparation aux portefeuilles européens d’identité numérique

    Ce que vous recevez

    • Conception de l’identité et modèle de menaces
    • Intégration eID en production
    • Identités de service et rotation des secrets en place

  5. 05 Interopérabilité avec les administrations

    Connexions aux plateformes nationales d’échange de données, comme le Federal Service Bus et MAGDA en Belgique, Digikoppeling et Common Ground aux Pays-Bas, les standards XÖV et FIT-Connect en Allemagne, la PDND en Italie et API Entreprise en France, ainsi qu’au système technique « une fois pour toutes » de l’UE (Once-Only Technical System).

    Ce que nous faisons

    • Habilitation auprès de l’opérateur de la plateforme
    • Correspondance avec les standards de données nationaux
    • Exigences de sécurité et de journalisation propres à chaque échange
    • Conception de l’échange de pièces justificatives selon le principe « une fois pour toutes »

    Ce que vous recevez

    • Connexion certifiée à la plateforme d’échange
    • Documentation des correspondances
    • Procédures d’exploitation convenues avec l’opérateur

  6. 06 Une visibilité opérationnelle pour les équipes métier

    Une supervision des flux lisible par les équipes métier, des rapprochements entre systèmes et des files d’erreurs qui ont un responsable et sont effectivement traitées.

    Ce que nous faisons

    • Supervision des flux au niveau métier
    • Rapports de rapprochement entre systèmes
    • Classification et aiguillage des erreurs
    • Alertes par responsable de flux

    Ce que vous recevez

    • Tableau de bord d’intégration par processus métier
    • Contrôles de rapprochement en production
    • Cartographie des responsables de chaque file d’erreurs

03 Architecture

Une architecture de référence illustrative

Deux chemins partent des systèmes de référence. Les requêtes synchrones passent par des API système et une passerelle qui contrôle l’identité, les périmètres et les quotas. Les modifications sont publiées sous forme d’événements via une outbox ou une capture des changements, et les consommateurs les traitent de façon idempotente.

Les messages en échec aboutissent dans une file dédiée avec rejeu, pas dans un fichier journal. Une bande de supervision présente chaque flux en termes métier, pour que les responsables d’un processus voient quand il s’arrête.

Couches du schéma

Systèmes de référence
ERP, CRM et gestion des dossiers gardent l’autorité sur leurs données.
API synchrones
API système versionnées derrière une passerelle avec OAuth 2.0, mTLS et quotas.
Événements
Outbox, broker, file de messages en échec et mappings de la plateforme d’intégration.
Consommateurs
Portails, applications, agents, partenaires et échanges avec les administrations, avec identité électronique lorsque des citoyens sont concernés.
Exemple illustratif

  1. Systèmes de référence

    • ERP, CRM et gestion des dossiers

  2. API synchrones

    • API système
    • Passerelle d’API : OAuth 2.0, mTLS, quotas

  3. Événements

    • Outbox et CDC
    • Broker d’événements
    • Messages en échec et rejeu
    • Mappings de la plateforme d’intégration

  4. Consommateurs

    • Portails, applications et agents
    • Échanges partenaires et administrations
    • Identité : OIDC, mTLS, eID

  5. Exploitation

    • Supervision des flux, rapprochement, files d’erreurs attribuées
API et socle événementiel, côte à côte

Architecture illustrative, pas un système client.

Lire le schéma sous forme de texte

Le parcours principal part des systèmes de référence, passe par des API système versionnées et une passerelle d’API, et aboutit aux portails, applications et agents.

En parallèle, les systèmes de référence publient leurs modifications via une outbox et une capture des changements vers un broker d’événements, qui les transmet aux échanges avec les partenaires et les administrations ainsi qu’à une plateforme d’intégration pour les mappings. Les messages en échec vont dans une file dédiée avec rejeu. Des services d’identité avec OAuth, mTLS et eID sécurisent les échanges avec les partenaires.

Une bande de supervision, en dessous, présente l’état des flux, les rapprochements et les files d’erreurs avec leurs responsables.

04 Points d’attention et limites

Choix d’ingénierie et limites

  • « Exactement une fois » se conçoit, ne se paramètre pas

    Notre méthode

    Nous partons du principe que les messages arrivent en double ou dans le désordre, et concevons des consommateurs idempotents, avec des clés et des règles d’ordonnancement convenues par type d’événement.

    Limites et dépendances

    Certains systèmes hérités ne peuvent ni accepter de clés d’idempotence ni indiquer ce qu’ils ont traité. Autour de ceux-là, nous ajoutons des rapprochements plutôt que de faire semblant.

  • Une iPaaS n’est pas toujours la réponse

    Notre méthode

    Les plateformes l’emportent pour de nombreux connecteurs et mappings standards. Les services spécifiques l’emportent pour une logique complexe, de forts volumes ou une latence stricte. Nous documentons le choix pour chaque intégration.

    Limites et dépendances

    Les modèles de licence évoluent. Une plateforme bon marché aujourd’hui peut devenir le premier poste de votre budget d’intégration : nous modélisons donc les coûts sur plusieurs années.

  • Les plateformes publiques ont leur propre calendrier

    Notre méthode

    Nous préparons tôt les dossiers d’habilitation, les éléments de sécurité et les plans de test, et travaillons avec l’opérateur de la plateforme dès la première semaine.

    Limites et dépendances

    Les délais de certification et d’habilitation sont fixés par l’opérateur, pas par nous. Nous planifions en conséquence et vous indiquons où ils se situent sur le chemin critique.

  • Les consommateurs IA ont besoin d’API étroites

    Notre méthode

    Les agents et assistants reçoivent des API dédiées, à périmètre restreint, avec limites et journal d’audit, et non le même accès étendu que les services internes.

    Limites et dépendances

    Exposer une API à un agent ajoute du risque. Nous examinons chacune avec votre équipe sécurité avant sa mise en production.

05 Notre façon de travailler

Notre façon de travailler

Nous démêlons avant de construire, et chaque flux repart avec un responsable.

  1. 01

    Cartographier les flux

    Chaque interface, son volume, son historique d’incidents et son responsable métier.

    LivrableCartographie des intégrations et classement des risques

  2. 02

    Fixer les règles

    Règles de conception d’API, conventions d’événements, modèle d’identité et choix de plateforme.

    LivrableRègles d’intégration et dossiers de décision

  3. 03

    Migrer flux par flux

    Les flux les plus risqués d’abord, avec un rapprochement en parallèle de l’ancienne interface jusqu’à ce que les chiffres concordent.

    LivrableFlux migrés avec preuves de rapprochement

  4. 04

    Exploiter en toute transparence

    Tableaux de bord par processus métier et files d’erreurs confiées à des responsables désignés.

    LivrableCartographie des responsables de flux et tableaux de bord

06 Contrôle humain

Là où l’humain garde la main

L’intégration fonctionne sans intervention humaine. La responsabilité de ce qui dysfonctionne, elle, reste humaine.

  • Chaque file d’erreurs a un responsable

    Les messages en échec vont à une équipe qui en répond, avec le contexte et un bouton de rejeu, et non dans un journal partagé.

  • Les changements de contrat sont revus

    Les modifications d’API ou d’événements non rétrocompatibles font l’objet d’une revue avec les consommateurs avant d’être publiées.

  • Les rejeux sont délibérés

    Rejouer des messages dans un système de référence est une action autorisée, journalisée avec son auteur et son motif.

07 Technologies

Technologies que nous utilisons

Plateformes d’intégration
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Services d’intégration AWS et Google Cloud
Événements et streaming
  • Apache Kafka
  • RabbitMQ
  • Brokers d’événements cloud
  • Debezium pour la capture des changements
API
  • OpenAPI et AsyncAPI
  • Passerelles d’API et portails développeurs
  • GraphQL lorsqu’il est pertinent
  • Tests de contrat
Identité
  • OAuth 2.0 et OpenID Connect
  • TLS mutuel
  • Keycloak et fournisseurs d’identité cloud
  • Dispositifs nationaux d’identité électronique

La mention d’une technologie décrit notre expérience d’ingénierie. Elle n’implique ni partenariat avec son éditeur ni recommandation de sa part.

08 Exemple

Un exemple illustratif

Exemple illustratif

Peppol et Mercurius pour un grossiste bruxellois

01Situation
Un grossiste bruxellois facture à la fois des entreprises et des administrations. Ses factures partent encore en PDF, les rejets de Mercurius arrivent par courriel et personne ne sait quelles factures ont été reçues.
02Ce que nous construirions
Un flux unique qui génère des factures structurées depuis l’ERP, les envoie via un point d’accès Peppol aux clients privés comme aux pouvoirs publics, et remonte chaque accusé de réception ou rejet dans une file de suivi.
03Là où l’humain décide
Le service comptable traite les rejets dans la file et décide de chaque nouvel envoi ; aucune facture n’est renvoyée automatiquement.
04Ce que nous mesurerions
Part des factures acceptées au premier envoi, délai de traitement des rejets et délai moyen de paiement par catégorie de client.

09 Regard sectoriel

Dans votre secteur

  • Secteur public et administrations

    Échange de données « une fois pour toutes » avec les sources authentiques, identité électronique pour les citoyens et les entreprises, et journalisation exigée par les plateformes nationales. Voir notre accompagnement du secteur public.

  • Industrie manufacturière

    ERP, MES et portails fournisseurs connectés par des événements, pour que planification, production et service partagent la même vision.

  • Services financiers

    Systèmes cœurs de métier, CRM et API partenaires connectés avec une identité forte, un journal d’audit et des rapprochements auxquels la finance se fie.

Belgique

Les briques belges de l’interopérabilité

Intégrer en Belgique, c’est connaître un écosystème bien établi : le Service fédéral d’authentification pour l’eID et itsme, l’eBox pour les notifications officielles, Mercurius pour les factures adressées aux pouvoirs publics, et Peppol pour la facturation électronique entre entreprises, obligatoire depuis 2026.

À Bruxelles, Paradigm porte les services numériques régionaux, et en Wallonie la stratégie Digital Wallonia encourage la réutilisation des services et des données. Nous construisons des couches d’intégration où chacun de ces services est un connecteur derrière un contrat interne stable.

Questions sur les intégrations et les API

Faut-il utiliser une plateforme d’intégration ou développer des intégrations spécifiques ?

Les deux, pour des flux différents. Les connecteurs standards, les mappings et l’intégration de partenaires plaident pour une plateforme. Les flux à fort volume, sensibles à la latence ou riches en logique plaident souvent pour des services spécifiques. Nous décidons flux par flux et documentons nos raisons.

Intégrez-vous Salesforce, SAP et Odoo ?

Oui, régulièrement, entre eux et avec des applications spécifiques et des systèmes publics. FromNine a le statut de partenaire des trois éditeurs (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner) : nos équipes d’intégration travaillent donc aux côtés de spécialistes de ces plateformes. Découvrez notre accompagnement en intégration SAP.

Avons-nous besoin d’une intégration orientée événements ?

Lorsque plusieurs systèmes doivent réagir à la même modification, ou lorsque vous devez découpler les cycles de livraison, les événements sont utiles. Pour un simple échange requête-réponse entre deux systèmes, une API suffit souvent. La plupart des systèmes d’information utilisent les deux.

Pouvez-vous intégrer les dispositifs nationaux d’identité électronique ?

Oui. Nous intégrons les dispositifs d’identité électronique des citoyens et des entreprises, et tenons compte, dès la conception, des portefeuilles européens d’identité numérique que les États membres mettent en place au titre d’eIDAS 2. Les exigences d’habilitation varient selon les dispositifs, et nous les anticipons.

Notre middleware est vieillissant. Faut-il le remplacer ?

Pas d’un seul coup. Nous cartographions ce qui y tourne, migrons d’abord les flux les plus risqués ou les plus coûteux et maintenons les rapprochements jusqu’à ce que chaque flux migré ait fait ses preuves.

Montrez-nous l’interface qui tombe le plus souvent en panne

Nous vous montrons comment la rendre observable, rejouable et suivie, et ce qu’il faudrait pour en faire autant avec vos autres flux, Peppol compris.

Demander un premier entretienDécouvrir notre approche