Pillar page

Intégration de systèmes pour entreprises

Nous connectons les ERP, CRM, systèmes comptables, paie/RH, registres d'entreprises, Microsoft Graph, Salesforce, SAP. Intégrations via API, files d'attente, ETL, webhooks — avec un contrôle qualité total, un audit trail et un monitoring de production.

Discutons de votre projet d'intégration Tous nos services

Une entreprise de taille moyenne utilise entre une douzaine et plusieurs dizaines d'applications métier. Chacune stocke des fragments des mêmes données — client, facture, employé, commande. Sans intégration, les collaborateurs passent des heures par jour à ressaisir, exporter et importer manuellement des données entre les systèmes.

L'intégration de systèmes n'est pas un luxe — c'est le fondement de la transformation numérique. Avec une couche d'intégration bien conçue : un client ajouté dans le CRM apparaît dans l'ERP sans intervention, une facture émise en comptabilité met à jour le tableau de bord financier du dirigeant, un statut de commande est cohérent entre la boutique en ligne, l'entrepôt et le service client.

Pourquoi les intégrations sont-elles difficiles ?

Chaque système possède son propre modèle de données, son propre nom pour le même champ, sa propre séquence d'opérations, ses propres contraintes d'API (limites de débit, latence, erreurs transitoires). Deux systèmes peuvent sembler « compatibles » en théorie, mais en pratique exigent des semaines de travail sur les mappings, les transformations, la gestion des cas limites et la résolution des conflits.

La deuxième couche de difficulté est la fiabilité en production. Une intégration qui fonctionne correctement en environnement dev représente environ 30% du chemin. Les 70% restants concernent la gestion des situations exceptionnelles : le système externe est indisponible, il a modifié son contrat d'API, renvoie des données inattendues, un nouveau client apparaît dans le CRM avec des caractères que l'ERP legacy ne sait pas gérer. Chacun de ces cas exige une réflexion, un test et une alerte lorsqu'il se produit.

Types d'intégration

Six patterns fondamentaux. Dans la plupart des projets, nous en combinons plusieurs, en choisissant la bonne méthode pour chaque cas.

API REST / GraphQL

Communication synchrone entre applications. JSON comme format d'échange, OAuth2/JWT pour l'autorisation, OpenAPI/Swagger pour la documentation. Le choix le plus courant pour les systèmes cloud modernes.

Files d'attente de messages

RabbitMQ, Redis Streams, Kafka — échanges asynchrones quand l'émetteur n'attend pas le récepteur. Idéal pour les notifications, les événements métier, les opérations longues. Garantie de livraison + retry.

ETL / ELT

Chargement par lots de données dans un entrepôt (Snowflake, BigQuery, Redshift, PostgreSQL on-premise). Airflow ou dbt comme orchestrateur, validation de la qualité des données (Great Expectations), monitoring du lineage.

Webhooks

Notifications push depuis un système source (Stripe, GitHub, Slack, Salesforce) vers notre application. Vérification de signature HMAC, idempotence, dead-letter queue pour les livraisons échouées.

SOAP / XML

Systèmes enterprise legacy (SAP, Oracle, banque, assurance) — support complet WSDL, validation XSD, WS-Security. Adaptateur vers les protocoles modernes pour le reste du système.

Bases de données — réplication, CDC

Change Data Capture (Debezium, AWS DMS) pour la réplication en streaming des changements d'une base source vers une cible. Réplication logique PostgreSQL pour la haute disponibilité et le reporting.

Six défis clés en production

Les éléments que nous surveillons dans chaque projet d'intégration. L'absence de l'un d'entre eux = bombe à retardement.

Idempotence

Chaque requête exécutée plusieurs fois produit le même résultat. Clés d'idempotence dans les en-têtes, déduplication au niveau applicatif, transactions autour des opérations critiques.

Retry et backoff

Les erreurs réseau transitoires sont la norme. Backoff exponentiel (1s, 2s, 4s, 8s…), jitter pour éviter le thundering herd, circuit breaker après N tentatives échouées.

Mapping et transformations

Le système A nomme un champ "client_id", le système B "customerId", le système C "id_klienta". Un catalogue central de mappings, des transformations en un seul endroit, des tests pour chaque transformation.

Eventual consistency

Les données dans deux systèmes ne sont jamais cohérentes à 100% en temps réel. Nous acceptons la latence (typiquement des secondes), surveillons la dérive et alertons en cas de divergence prolongée.

Audit et conformité

Chaque opération d'intégration enregistre : qui/quoi/quand/d'où/vers où, payload (anonymisé s'il contient des PII), résultat. Le journal d'audit répond aux exigences RGPD et ISO 27001.

Scaling et coûts

Les intégrations croissent avec le business. Scaling horizontal (plus d'instances), rate limiting (protection contre les requêtes excessives), monitoring des coûts par intégration.

Comment nous livrons un projet d'intégration

Discovery (1-2 semaines) : cartographie des flux de données actuels, identification de la source de vérité pour chaque entité, collecte des contrats d'API, évaluation des risques et des dépendances.
Conception d'architecture (1 semaine) : choix des patterns (synchrone vs asynchrone, push vs pull, hub-and-spoke vs point-à-point), schéma du journal d'audit, plan de monitoring.
Pilote sur une seule entité (2-3 semaines) : nous livrons l'intégration pour un type de données (par ex. clients) de bout en bout. Validation des contrats, tests de charge, dry-run en environnement de test.
Extension aux autres entités (4-8 semaines) : synchronisations suivantes (factures, commandes, produits) avec le même pattern. Chaque mise en production précédée d'un Change Request et de tests de régression.
Migration des données historiques (1-3 semaines) : transfert des données existantes. Dry-run, audit, plan de rollback. Migration incrémentale ou pendant une fenêtre de service.
Hypercare (4 semaines en production) : monitoring intensif, réponse rapide aux incidents, tuning des alertes. Après l'hypercare, transition vers la maintenance standard.

Exemples d'intégrations livrées

KRS + CRBR — RejestrFirm

Microservice connectant les données du Registre judiciaire polonais (740k+ entreprises) avec le Registre central des bénéficiaires effectifs. Smart caching (24h), dual-source avec fallback automatique, 15+ endpoints REST. Utilisé dans les processus KYC, la vérification de contreparties et le reporting de conformité.

SSO sur plusieurs applications

Plateforme Keycloak centrale (realm eskom-ai) intégrée avec une douzaine d'applications clientes. OAuth2/OIDC + PKCE, social login (Google, Microsoft, Apple, Facebook), provisioning des utilisateurs, facturation basée sur l'usage des tokens LLM. Single sign-on sur l'ensemble des produits ESKOM AI.

Microsoft Graph — calendriers, e-mail, OneDrive

Intégration avec Microsoft 365 pour l'automatisation du calendrier (planification de réunions par assistant IA), l'envoi d'e-mails transactionnels, l'archivage de documents. OAuth2 avec delegated permissions, refresh tokens dans Vault, monitoring des rate limits Graph API.

LLM Proxy — routage multi-fournisseur

File d'attente centrale connectant plusieurs fournisseurs LLM (Anthropic, OpenAI, Ollama local). Routage par tâche (petite — modèle local, complexe — Claude Opus), cache des réponses, monitoring des coûts par projet, fail-over entre fournisseurs.

Questions fréquentes

Que signifie l'intégration de systèmes ?

L'intégration de systèmes est le processus consistant à connecter deux applications ou plus afin qu'elles puissent échanger des données, déclencher des événements mutuellement et rester cohérentes. En pratique : quand un client est ajouté au CRM, il apparaît automatiquement dans l'ERP ; quand une facture est émise en comptabilité, les données circulent vers le CRM et l'analytique. Sans intégration, l'entreprise jongle manuellement avec les données (exports CSV, copier-coller entre systèmes), ce qui génère des erreurs, des retards et des coûts.

Quelles technologies d'intégration utilisez-vous ?

Le choix technologique dépend du contexte : API REST et webhooks pour les systèmes cloud modernes, SOAP/XML pour les ERP/bancaires legacy, files de messages (RabbitMQ, Redis Streams, Kafka) pour l'échange asynchrone, ETL/ELT pour l'alimentation d'entrepôts, GraphQL lorsque le client veut de la flexibilité. Nous mélangeons souvent les approches — synchrone là où l'utilisateur attend un résultat, asynchrone là où le débit prime.

Les intégrations cassent-elles quand les systèmes sources sont mis à jour ?

C'est l'un des plus grands problèmes en intégration — et c'est pourquoi nous construisons des adaptateurs avec isolation (anti-corruption layer). Un système externe change son contrat → seul l'adaptateur change, le reste de l'intégration n'est pas affecté. En plus : les contrats sont versionnés (v1, v2), les tests d'intégration s'exécutent quotidiennement contre les API sandbox, des alertes Sentry/Wazuh se déclenchent en cas de changement de format de réponse. Le client est informé d'un problème avant qu'il n'atteigne les utilisateurs finaux.

Combien de temps prend une intégration typique ?

Les intégrations simples (un système vers un autre, ~5 endpoints, synchronisation unidirectionnelle) sont livrées en 1 à 2 semaines. Les intégrations complexes (synchronisation bidirectionnelle, une douzaine d'entités, mappings, transformations, déduplication) prennent 4 à 8 semaines. Les intégrations multi-systèmes (hub-and-spoke) sont planifiées par phases, en livrant de la valeur métier dans des itérations de 2 à 3 semaines.

Et les données historiques lors d'une nouvelle intégration ?

Chaque projet d'intégration inclut une étape distincte de migration historique. D'abord une analyse complète : combien d'enregistrements, quels types de données, où se trouvent les doublons, quels champs sont requis vs. optionnels. Ensuite un script de migration avec dry-run, audit trail (ce qui a été déplacé, ce qui a été rejeté, pourquoi) et plan de rollback. La migration s'effectue pendant une fenêtre de service ou de manière incrémentale, selon le risque métier.

L'intégration doit-elle fonctionner 24/7 ?

Cela dépend de la criticité métier. Les processus en ligne (paiements, autorisations) exigent une haute disponibilité — nous les concevons avec redondance (load balancer, instances multiples, health checks, auto-restart). Les processus nocturnes (rapports, synchronisations par lots) peuvent s'exécuter dans des fenêtres de service. Nous classifions chaque intégration avec un SLA : temps de réponse p95, downtime mensuel acceptable, RTO/RPO.

Comment monitorez-vous les intégrations en production ?

Chaque intégration émet des métriques vers Prometheus (request rate, error rate, latence p50/p95/p99), des logs vers un SIEM central (Wazuh), des erreurs vers Sentry. Les alertes se déclenchent en cas de chute de débit, de pic du taux d'erreur ou de timeouts. Un tableau de bord montre l'état de toutes les intégrations en un seul endroit — l'opérateur peut voir, par exemple, que l'intégration avec le fournisseur X a 3% d'erreurs tandis que le reste tourne normalement.

Et la sécurité pour les intégrations externes ?

Chaque intégration utilise un accès au moindre privilège. Les clés et tokens vivent dans HashiCorp Vault (pas dans les fichiers .env, pas dans le code). La communication passe toujours par TLS 1.2+, les certificats sont vérifiés (jamais verify=False). Les webhooks entrants ont une vérification de signature HMAC. En cas de fuite de token — rotation immédiate, le journal d'audit montre ce qui s'est passé et quand.

En quoi l'approche d'intégration d'ESKOM AI diffère-t-elle d'un ESB classique (Enterprise Service Bus) ?

Les ESB classiques (Mule, BizTalk, WebMethods) sont des plateformes monolithiques — coûteuses en licences et exigeant une équipe dédiée. Notre modèle : microservices d'intégration, chaque intégration comme un composant distinct avec son propre déploiement et son propre monitoring, infrastructure construite sur de l'open source (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Coût de licence plus bas, maintenance plus facile, pas de vendor lock-in. Pour certains clients c'est un argument financier, pour d'autres — un argument stratégique.

Intégrez-vous avec les systèmes publics polonais (KRS, CRBR, KSeF, ePUAP) ?

Oui. En production, nous exploitons un microservice intégré à KRS et CRBR (rejestrfirm.eskom.ai — données pour 740k+ entreprises incluant les bénéficiaires effectifs). KSeF (facturation électronique polonaise) — nous avons des composants d'intégration prêts dans le projet Kontroling. ePUAP, e-livraisons — disponibles via Microsoft Graph API et intégrations directes. Conformité complète à la loi polonaise (RGPD, obligations de reporting).

Vous avez un projet d'intégration ?

Nous commençons par un audit gratuit — cartographie des flux de données actuels, identification des goulots d'étranglement et proposition d'un plan en phases claires.

Réserver un audit d'intégration Voir nos produits