Aller au contenu principal
FromNine
Menu

Ingénierie

Des intégrations qui font circuler les données et signalent tout arrêt.

Contrats d’interface, événements et identités maîtrisées : c’est ainsi que nous faisons dialoguer CRM, ERP, outils de gestion des dossiers et plateformes publiques. Les flux sont fiables, une erreur ne passe pas inaperçue, et toute nouvelle brique, une IA par exemple, se raccorde sans risque.

Pour les organisations qui relient systèmes, partenaires et plateformes publiques au Luxembourg et dans les pays voisins.

Parler de votre projetPlateformes d’entreprise
Intégrations et API : les briquesQuatre couches superposées. En haut, ceux qui consomment les données : portails, applications, agents ; ensuite la passerelle d’API et la gestion des identités ; plus bas, le bus d’événements ; au fond, les systèmes qui font référence.01Portails, applications et agents02Passerelle d’API et identités03Bus d’événements04Systèmes de référence
  1. 01API conçues à partir du contrat, en OpenAPI et AsyncAPI, versionnées et documentées
  2. 02Événements ordonnés et idempotents, avec file des messages en échec et rejeu
  3. 03Flux suivis de bout en bout, files d’erreurs confiées à des équipes nommées

01 Problèmes

Pourquoi on nous appelle

  1. 01

    Des liaisons point à point intouchables

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

  2. 02

    Doublons et pannes muettes

    Une nouvelle tentative crée une deuxième commande. Un message en échec s’évapore. Ce sont les clients qui préviennent les métiers.

  3. 03

    Chaque nouveau canal relance un chantier d’intégration

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

  4. 04

    Chaque échange avec l’administration devient un projet

    Se raccorder à une plateforme publique d’échange de données, à un moyen d’identification électronique ou au réseau Peppol demande à chaque fois des mois de travail de sécurité et d’inscription.

02 Prestations

Nos prestations

  1. 01 Stratégie et gestion des API

    Une conception API d’abord, avec des contrats OpenAPI et AsyncAPI, une règle de versionnement, une passerelle qui la fait respecter et un portail développeurs pour retrouver et réutiliser l’existant.

    Ce que nous faisons

    • Cartographie des API et de leurs responsables
    • Règles de conception et procédure de revue
    • Règles de passerelle pour la sécurité, les quotas et les versions
    • Portail développeurs et catalogue d’API

    Ce que vous recevez

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

  2. 02 Intégration par événements

    Brokers, capture des changements et modèle outbox, avec les détails dont tout dépend : ordre des messages, consommateurs idempotents, file 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’ordre
    • Files des messages en échec avec outils de rejeu

    Ce que vous recevez

    • Bus d’événements en production
    • Registre de schémas et règles de compatibilité
    • Mode opératoire de rejeu et de reprise

  3. 03 Une plateforme d’intégration choisie flux par flux

    SAP Integration Suite, MuleSoft, services d’intégration des clouds : chaque outil a son terrain. Nous vous indiquons franchement quand une iPaaS vaut mieux que du code spécifique, et quand c’est l’inverse.

    Ce que nous faisons

    • Évaluation du middleware existant
    • Choix de plateforme en coût total de possession
    • Correspondances et connecteurs réutilisables
    • Sortie de l’ancien middleware

    Ce que vous recevez

    • Fiche de décision sur la plateforme d’intégration
    • Bibliothèque de modèles 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, et raccordement aux moyens d’identification électronique : au Luxembourg, LuxTrust et la carte d’identité électronique acceptés par MyGuichet.lu ; chez les voisins, itsme, BundID, DigiD et eHerkenning.

    Ce que nous faisons

    • Architecture d’identité pour les utilisateurs et les services
    • Conception des jetons, des périmètres et du consentement
    • Accompagnement à l’inscription 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
    • Identification électronique en production
    • Identités de service et rotation des secrets en place

  5. 05 Interopérabilité avec les administrations

    Côté luxembourgeois, les factures électroniques destinées aux pouvoirs adjudicateurs transitent par Peppol ou MyGuichet.lu. Pour vos activités chez les voisins, nous raccordons vos systèmes au Federal Service Bus et à MAGDA (Belgique), à Digikoppeling (Pays-Bas), aux standards XÖV et à FIT-Connect (Allemagne), à API Entreprise (France), et au système technique « une fois pour toutes » de l’UE.

    Ce que nous faisons

    • Inscription auprès de l’exploitant de la plateforme
    • Correspondance avec les standards de données nationaux
    • Exigences de sécurité et de journalisation de chaque échange
    • Conception de l’échange de justificatifs selon le principe « une fois pour toutes »

    Ce que vous recevez

    • Raccordement certifié à la plateforme d’échange
    • Documentation des correspondances
    • Procédures d’exploitation convenues avec l’exploitant

  6. 06 Des flux lisibles pour les métiers

    Un suivi des flux que les métiers comprennent, des rapprochements entre systèmes et des files d’erreurs qu’une équipe prend en charge et traite.

    Ce que nous faisons

    • Suivi des flux exprimé en termes métier
    • Rapports de rapprochement entre systèmes
    • Classement et aiguillage des erreurs
    • Alertes adressées au responsable de chaque flux

    Ce que vous recevez

    • Tableau de bord d’intégration par processus métier
    • Contrôles de rapprochement en production
    • Responsable désigné pour chaque file d’erreurs

03 Architecture

Une architecture de référence, à titre d’illustration

Depuis les systèmes de référence, deux voies coexistent. D’un côté, les appels synchrones passent par des API système puis par une passerelle qui contrôle identité, périmètres et quotas. De l’autre, chaque changement devient un événement publié par outbox ou CDC, que les consommateurs traitent sans risque de doublon.

Au lieu de se perdre dans un fichier journal, un message en échec rejoint une file dédiée d’où il peut être rejoué. Sous l’ensemble, la supervision décrit chaque flux dans le vocabulaire des métiers, si bien que le responsable d’un processus remarque aussitôt un arrêt.

Couches du schéma

Systèmes de référence
ERP, CRM et gestion des dossiers restent maîtres de 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 des messages en échec et correspondances de la plateforme d’intégration.
Consommateurs
Portails, applications, agents, partenaires et échanges avec les administrations, avec identification électronique quand 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
    • Correspondances de la plateforme d’intégration

  4. Consommateurs

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

  5. Exploitation

    • Suivi des flux, rapprochements, files d’erreurs avec responsable
API et bus d’événements, côte à côte

Schéma d’illustration : il ne représente le système d’aucun client.

Lire le schéma sous forme de texte

Le chemin principal mène des systèmes de référence aux portails, applications et agents, via des API système versionnées et une passerelle d’API.

Sur une voie parallèle, les changements des systèmes de référence partent par outbox et CDC vers un broker. Le broker alimente les échanges externes, partenaires comme administrations, et une plateforme d’intégration chargée des correspondances. Une file à part recueille les messages en échec, rejouables. OAuth, mTLS et eID protègent les échanges avec l’extérieur.

En dessous, une bande de supervision montre l’état des flux, les rapprochements et les files d’erreurs avec leurs responsables.

04 Choix et limites

Choix techniques et limites

  • Le « exactement une fois » se conçoit, il ne se paramètre pas

    Notre approche

    Doublons et désordre sont considérés comme normaux. Chaque consommateur est rendu idempotent, et chaque type d’événement reçoit ses clés et ses règles d’ordre.

    Limites et dépendances

    Certains systèmes anciens ne savent ni accepter une clé d’idempotence ni dire ce qu’ils ont traité. Autour d’eux, nous ajoutons des rapprochements plutôt que de faire semblant.

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

    Notre approche

    La plateforme gagne pour les connecteurs et correspondances standard. Le développement spécifique gagne pour la logique complexe, les gros volumes ou les délais serrés. Le choix est documenté pour chaque intégration.

    Limites et dépendances

    Les conditions de licence bougent. La plateforme bon marché d’aujourd’hui peut peser demain plus que tout le reste du budget d’intégration : nos projections de coûts portent donc sur plusieurs années.

  • Les échanges publics ont leur propre rythme

    Notre approche

    Dossiers d’inscription, preuves de sécurité et plans de test sont préparés tôt, et nous travaillons avec l’exploitant de la plateforme dès la première semaine.

    Limites et dépendances

    Les délais de certification et d’inscription dépendent de l’exploitant, pas de nous. Nous planifions en conséquence et vous montrons où ils pèsent sur le chemin critique.

  • Les consommateurs IA ont besoin d’API étroites

    Notre approche

    Agents et assistants reçoivent des API dédiées, au périmètre restreint, avec plafonds et journal d’audit, et non les accès larges des services internes.

    Limites et dépendances

    Toute API ouverte à un agent est un risque de plus. Votre équipe sécurité examine chacune avec nous avant la mise en production.

05 Méthode

Notre méthode

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

  1. 01

    Recenser les flux

    Chaque interface, son volume, son historique de pannes et son responsable métier.

    LivrableCartographie des intégrations et classement des risques

  2. 02

    Poser les règles

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

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

  3. 03

    Migrer flux par flux

    Les flux les plus risqués passent en premier ; l’ancienne interface tourne en parallèle, sous rapprochement, jusqu’à ce que les chiffres concordent.

    LivrableFlux migrés avec preuves de rapprochement

  4. 04

    Exploiter en toute visibilité

    Un tableau de bord par processus métier, des files d’erreurs aux mains de responsables nommés.

    LivrableCarte des responsables de flux et tableaux de bord

06 Contrôle humain

Là où les personnes gardent la main

L’intégration tourne sans surveillance. La responsabilité de ce qui échoue, elle, ne s’automatise pas.

  • Chaque file d’erreurs a un responsable

    Un message en échec va à l’équipe qui en répond, avec son contexte et un bouton de rejeu, et non dans un journal partagé.

  • Les changements de contrat sont relus

    Toute modification incompatible d’une API ou d’un événement passe par une revue avec ses consommateurs avant publication.

  • Un rejeu est un acte réfléchi

    Seule une personne autorisée peut rejouer des messages vers un système de référence ; le journal garde son nom et la raison du rejeu.

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 flux
  • Apache Kafka
  • RabbitMQ
  • Brokers d’événements des clouds
  • Debezium pour la capture des changements
Interfaces API
  • OpenAPI et AsyncAPI
  • Passerelles d’API et portails développeurs
  • GraphQL quand il est pertinent
  • Tests de contrat
Identité
  • OAuth 2.0 et OpenID Connect
  • TLS mutuel
  • Keycloak et fournisseurs d’identité cloud
  • Moyens nationaux d’identification électronique

Une technologie citée ici reflète notre expérience d’ingénierie. Elle ne signifie ni partenariat avec son éditeur ni recommandation de sa part.

08 Exemple

Un exemple illustratif

Exemple illustratif

Des factures électroniques de l’ERP vers les acheteurs publics luxembourgeois

01Situation
Une entreprise de construction et de maintenance travaille pour des communes, des établissements publics et des clients privés au Luxembourg et en Lorraine. Ses factures aux pouvoirs adjudicateurs sont saisies une à une sur MyGuichet.lu, et les rejets arrivent sans que la comptabilité sache pourquoi.
02Ce que nous construirions
Une intégration qui produit à partir de l’ERP des factures Peppol BIS Billing 3.0, les envoie par un point d’accès Peppol, rapproche les accusés de réception et range les rejets dans une file d’erreurs avec leur motif.
03Où les personnes décident
La comptabilité valide chaque facture avant envoi ; un responsable désigné traite la file des rejets et décide des corrections.
04Ce que nous mesurerions
Part des factures publiques transmises sans ressaisie, délai entre facturation et acceptation, et nombre de rejets par motif.

09 Par secteur

Selon votre secteur

  • État et communes

    Échanges selon le principe « une fois pour toutes » avec les sources authentiques, identification par LuxTrust ou carte d’identité électronique, et la journalisation qu’exigent les plateformes publiques. Voir nos travaux pour l’État et les communes.

  • Industrie

    ERP, MES et portails fournisseurs reliés par des événements : planification, production et service partagent la même image, y compris avec des clients en France, en Belgique ou en Allemagne.

  • Secteur financier

    Pour les banques, gestionnaires de fonds et assureurs : systèmes cœur, CRM et API partenaires reliés avec une identité forte, une journalisation d’audit et des rapprochements dignes de la confiance de la direction financière.

Luxembourg

Interopérabilité d’un État membre à l’autre

Un service transfrontalier rencontre dans chaque pays une autre plateforme d’échange, un autre moyen d’identification et d’autres standards de données. Le règlement pour une Europe interopérable demande aux organismes publics d’évaluer l’interopérabilité transfrontalière, et eIDAS 2 impose à chaque État membre de proposer un portefeuille européen d’identité numérique.

Au Luxembourg, la loi modifiée du 16 mai 2019 rend la facture électronique structurée obligatoire dans les marchés publics : pour les grandes entreprises depuis le 18 mai 2022, pour tous les opérateurs économiques depuis le 18 mars 2023, quel que soit le montant. Seuls Peppol et MyGuichet.lu sont admis, l’envoi par courriel est exclu ; Peppol BIS Billing 3.0 et XRechnung figurent parmi les formats acceptés. Le CTIE reçoit les factures destinées à l’État via Peppol.

Nos couches d’intégration traitent plateformes nationales et moyens d’identification comme des adaptateurs placés derrière des contrats internes stables. Ajouter un pays revient alors à ajouter un adaptateur et son inscription, sans retoucher les systèmes en arrière-plan.

Vos questions sur les intégrations et les API

Plateforme d’intégration ou intégrations sur mesure ?

Les deux, selon le flux. Connecteurs standard, correspondances et inscription de partenaires plaident pour une plateforme. Les flux volumineux, sensibles au délai ou chargés de logique plaident souvent pour du spécifique. Nous décidons flux par flux et écrivons pourquoi.

Intégrez-vous Salesforce, SAP et Odoo ?

Oui, souvent, entre eux comme avec des applications sur mesure ou publiques. Nous sommes partenaires des trois éditeurs (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), si bien que nos intégrateurs travaillent avec des spécialistes de chaque plateforme. Voir nos travaux d’intégration SAP.

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

Les événements aident quand plusieurs systèmes doivent réagir au même changement ou quand vous voulez découpler les rythmes de livraison. Pour une simple question-réponse entre deux systèmes, une API suffit souvent. La plupart des parcs combinent les deux.

Savez-vous intégrer LuxTrust et les autres moyens d’identification électronique ?

Oui. MyGuichet.lu accepte LuxTrust, la carte d’identité électronique luxembourgeoise et les moyens eIDAS notifiés d’autres États de l’UE et de l’EEE, ces derniers ne permettant pas de signer certaines démarches. Nous intégrons ces moyens et préparons les portefeuilles européens d’identité numérique que les États membres doivent proposer au titre d’eIDAS 2 d’ici au 24 décembre 2026. Les conditions d’inscription varient d’un moyen à l’autre ; nous les anticipons.

Nous avons un middleware ancien. Faut-il le remplacer ?

Non, et surtout pas en une fois. Après un inventaire de ce qu’il porte, les flux les plus risqués ou les plus chers migrent en premier, et chaque flux déplacé reste sous rapprochement tant qu’il n’a pas fait ses preuves.

Venez avec l’interface qui tombe le plus souvent en panne

Nous montrerons comment la rendre observable, idempotente et confiée à un responsable, et ce qu’il faudrait pour en faire autant avec les autres.

Parler de votre projetAssistance aux demandes