Intégration & architecture événementielle
Intégration de systèmes et architecture événementielle
Veraplot connecte ERP, CRM, plateformes SaaS et API partenaires grâce à des intégrations événementielles sur AWS, en remplacement des scripts point à point et des ESB vieillissants. Nous publions les événements métier sur EventBridge ou Kafka, transformons des formats comme les IDoc SAP en XML vers du JSON, et les livrons avec idempotence, reprises, dead-letter queues et traçabilité de bout en bout. Chaque intégration est réalisée au forfait par des ingénieurs seniors qui ont déjà fait tourner des flux SAP vers le cloud en production.
Découplé par défaut
Le producteur publie une fois, les consommateurs s'abonnent. Ajouter un système ne veut plus dire toucher à l'ERP ni réécrire l'existant.
Rien de perdu, rien en double
Consommateurs idempotents, reprises avec backoff et dead-letter queues : une panne chez un partenaire retarde les messages, sans les perdre ni les dupliquer.
Traçable de bout en bout
Un identifiant de corrélation suit chaque message de la source à la cible : le support localise une commande sans ouvrir cinq consoles.
Ce que vous recevez
Cartographie des flux et catalogue d'événements
Systèmes, flux, responsables et schémas d'événements documentés, avec des règles de versionnement pour que producteurs et consommateurs évoluent indépendamment.
Moteur de mapping
Des mappings déclaratifs depuis IDoc, XML, CSV ou formats propriétaires vers JSON, versionnés et testés unitairement, champ par champ.
Colonne vertébrale événementielle
Bus EventBridge ou topics Kafka, files SQS et diffusion SNS, configurés avec schémas, durées de rétention et politiques d'accès.
API et webhooks
Des points d'entrée API Gateway sécurisés pour les partenaires et les webhooks entrants, avec authentification, limitation de débit et validation des requêtes.
Observabilité et rejeu
Tableaux de bord, alertes et suivi par identifiant de corrélation, plus des dead-letter queues avec une procédure de rejeu que votre support peut lancer seul.
La stack
Choisie pour votre contexte, pas pour un badge partenaire. Les formats ouverts d'abord, les services managés AWS là où ils se rentabilisent.
Écouter
Capter les changements là où ils se produisent
- SAP IDoc
- Amazon API Gateway
- Webhooks
- AWS DMS
- Amazon AppFlow
Traduire
Des formats mappés, testés et versionnés
- Python
- AWS Lambda
- Pydantic
- JSON Schema
- EventBridge Schema Registry
Aiguiller
Chaque événement vers ceux qui en ont besoin
- Amazon EventBridge
- Apache Kafka
- Amazon MSK
- Amazon SNS
- Amazon SQS
Livrer
Des appels fiables vers chaque cible
- AWS Step Functions
- EventBridge API destinations
- Amazon Data Firehose
- Dead-letter queues
Tracer
Chaque message, de bout en bout
- Amazon CloudWatch
- AWS X-Ray
- OpenTelemetry
- Grafana
Cas d'usage types
Des IDoc SAP vers les API partenaires
Groupe industriel. Des événements de commande SAP reçus en IDoc XML, convertis en JSON et envoyés aux API HTTPS des partenaires, message par message, avec reprises et rejeu.
Les événements ERP dans le data lake
Groupe industriel. Des flux SAP et Marketo déposés par des ingesters dédiés, et un speed layer Firehose qui livre les événements récents au reporting sans attendre le batch de nuit.
Modernisation d'un ESB
Les interfaces d'un ESB on-premise vieillissant migrées vers des services serverless AWS, flux par flux, sans bascule big-bang risquée.
Orchestration événementielle
Des processus métier en plusieurs étapes coordonnés par Step Functions et EventBridge, chaque étape visible et rejouable, au lieu d'une chaîne fragile de tâches cron.
Du premier appel à la mise en production
- 01
Appel découverte
Nous cartographions vos systèmes, vos contraintes et le résultat attendu. Vous échangez avec l'ingénieur qui réalisera le projet, pas avec un chargé d'affaires.
- 02
Périmètre au forfait
Un périmètre écrit, avec livrables, jalons et un prix unique, validé avant la première ligne de code. Aucun compteur de jours qui tourne.
- 03
Réalisation en itérations courtes
Des incréments fonctionnels toutes les une à deux semaines, présentés sur vos données, dans votre compte AWS. On corrige le tir tôt, pas à la fin.
- 04
Passation et run optionnel
Code, infrastructure as code, runbooks et passation avec votre équipe. Ensuite, vous exploitez vous-mêmes, ou nous assurons le support au mois ou sur 1 à 3 ans.
Les questions que l'on nous pose
Comment un projet d'intégration est-il chiffré ?
Au forfait, par interface ou par lot d'interfaces, une fois connus les formats source et cible, les volumes et les règles de gestion d'erreur. Les fondations communes (bus d'événements, supervision, moteur de mapping) sont construites une fois puis réutilisées : chaque flux supplémentaire coûte moins cher à ajouter que le premier. Vous connaissez le coût total avant le démarrage.
Combien de temps faut-il pour connecter deux systèmes ?
Un flux unique entre deux systèmes dotés d'API documentées est généralement en production en deux à quatre semaines, tests compris. Mettre en place une colonne vertébrale événementielle et sortir plusieurs interfaces d'un ESB représente un à trois mois, livrés interface par interface : rien n'attend une mise en production big-bang.
EventBridge ou Kafka ?
EventBridge pour la plupart des événements métier : serverless, peu coûteux à volume modéré, avec registre de schémas et cibles AWS natives. Kafka sur Amazon MSK quand il vous faut un très haut débit, une longue rétention, un rejeu piloté par les consommateurs, ou si vous avez déjà un écosystème Kafka. Beaucoup d'architectures combinent les deux, avec SQS entre eux pour absorber les pics. Nous choisissons selon vos volumes et vos contraintes, pas par habitude.
Savez-vous intégrer SAP ?
Oui. Nous avons construit des intégrations en production qui consomment des IDoc SAP, convertissent leur XML en JSON et les routent vers des services cloud, des API partenaires et un data lake. Nous travaillons aux côtés de votre équipe SAP, qui garde la main sur l'ERP, et prenons en charge le transport, le mapping, la livraison et la supervision sur AWS.
Que se passe-t-il quand un système cible est indisponible ?
Les messages attendent au lieu de disparaître. Les livraisons sont retentées avec un backoff exponentiel ; au-delà d'un nombre d'essais défini, elles tombent dans une dead-letter queue avec tout leur contexte, et une alerte est levée. Une fois la cible rétablie, la file est rejouée, et les consommateurs idempotents garantissent qu'un message rejoué ne crée jamais de commande ou de facture en double.