Métriques EDI : SLO, error budgets, KPIs

Un hub EDI moderne ne se pilote pas « à l'œil ». L'instrumentation — métriques, traces, logs — et la définition explicite de Service Level Objectives sont les fondations d'une exploitation à grande échelle. Cette page pose le cadre conceptuel et les indicateurs clés.

Pourquoi mesurer un EDI

Un système EDI est un système distribué : dizaines de partenaires, plusieurs protocoles, plusieurs formats, et des flux asynchrones qui peuvent durer des heures voire des jours. Sans mesure : les incidents sont découverts par les partenaires qui appellent, les régressions silencieuses (un taux d'erreur qui monte de 1% à 5%) passent inaperçues, les arbitrages capacité/coût sont faits « au pifomètre ».

Les bénéfices d'une instrumentation rigoureuse :

• Détection précoce des dégradations avant que le partenaire les remarque.
• Diagnostic accéléré via traces distribuées et logs corrélés.
• Arbitrage budgétaire : décider où investir (capacité, fiabilité, nouvelle fonctionnalité) avec données.
• Conformité contractuelle : prouver le respect des SLA partenaire.
• Pilotage de la roadmap : traduire un objectif métier en cible technique mesurable.

SLO, SLI, SLA, error budget

Le vocabulaire SRE distingue rigoureusement :

• SLI (Service Level Indicator) : une mesure objective d'un aspect du service (latence p95 d'envoi AS2, taux d'erreur sur 24h).
• SLO (Service Level Objective) : une cible définie sur un SLI (ex : 99,5% des envois AS2 sous 5 secondes sur 30 jours glissants).
• SLA (Service Level Agreement) : l'engagement contractuel envers un partenaire ou un client, généralement plus souple que le SLO interne, et assorti de pénalités.
• Error budget : la marge tolérée par le SLO. Pour un SLO de 99,5%, l'error budget est de 0,5% — soit environ 3,6 heures d'indisponibilité par mois. Une fois consommé, on gèle les déploiements et on consacre les sprints à fiabiliser.

Le couple SLO / error budget est l'outil qui transforme la fiabilité en métrique tangible et arbitrable, plutôt qu'en injonction floue (« que ce soit fiable »).

Latence : p50, p95, p99

La latence d'un flux EDI se mesure à plusieurs niveaux :

• Latence ingest : temps entre réception AS2/AS4 et accusé MDN/receipt retourné. Cible typique : p95 < 5s.
• Latence pipeline interne : temps entre ingest et publication sur le canonical event store. Cible typique : p95 < 30s.
• Latence end-to-end : temps entre ingest et ack ERP destinataire. Cible typique : p95 < 5 min (variable selon flux).
• Latence partenaire : temps entre émission et réception d'ack partenaire. SLA contractuel partenaire.

Les percentiles (p50, p95, p99) sont indispensables : la moyenne masque les queues. Un système avec p95 acceptable mais p99 catastrophique est instable. Hidalgo (op. cit.) recommande de construire les SLO sur p95 ou p99 plutôt que sur la moyenne, et de s'aligner sur les attentes utilisateur réelles.

Taux de succès et erreur

Le taux de succès est l'autre pilier des SLO EDI :

• Taux d'acceptation syntaxique : % de messages reçus qui passent le parser (CONTRL positif).
• Taux d'acceptation sémantique : % qui passent les règles métier (validateurs EN 16931, Schematron).
• Taux d'acceptation business : % qui passent les règles client (limites de crédit, autorisations).
• Taux d'ack partenaire : % de messages émis qui ont reçu leur MDN/receipt.

Chaque taux est mesuré sur fenêtre glissante (24h, 7j, 30j) et décliné par partenaire et type de message. Les seuils acceptables dépendent du contexte — 99,9% pour des factures fiscales, 95% pour des flux moins critiques.

Dropped messages et DLC

Un message qui finit en Dead Letter Channel est un dropped message. Le taux de DLC est un indicateur clé de la santé du système. Cibles typiques : < 0,1% en régime stable, alerte si > 0,5%. Les causes de drop :

• Erreur de parsing (format inattendu, encoding inconnu).
• Erreur de validation sémantique (champ obligatoire absent).
• Erreur de routage (partenaire inconnu).
• Erreur d'enrichissement (référence non résolue).
• Échec d'envoi définitif (épuisement des retries).

Le dashboard DLC doit afficher la distribution par cause, par partenaire et par type de message — sans cela, on traite les symptômes au lieu des causes.

MDN / Receipt time-to-ack

Pour AS2, le MDN (Message Disposition Notification) est le récépissé cryptographique de réception. Le temps entre émission du message et réception du MDN signé est le MDN time-to-ack. Pour AS4, l'équivalent est le receipt ebMS. Cible typique : p95 < 30s en synchrone, < 5 min en asynchrone.

Un MDN qui n'arrive pas (timeout) est un événement majeur : il faut retransmettre selon le pattern Retry with backoff, ne jamais supposer que le partenaire a reçu sans preuve, et ouvrir un ticket de non-répudiation si le seuil de retries est atteint.

OTIF par partenaire

OTIF (On Time In Full) est l'indicateur historique de la supply chain : % de commandes livrées à temps et complètes. Appliqué à l'EDI :

• On Time : % de messages envoyés dans la fenêtre contractuelle (typiquement ≤ 24h après commande).
• In Full : % de messages complets et acceptés du premier coup.

Mesuré par partenaire, l'OTIF EDI permet d'arbitrer les investissements : un partenaire dont l'OTIF dérive depuis 3 mois mérite une analyse spécifique (changement de spec, montée en volume, dégradation du partenaire lui-même).

Stack d'observabilité 2026

Le stack moderne s'appuie sur OpenTelemetry (CNCF, 2019) comme standard d'instrumentation, et plusieurs backends :

• Métriques : Prometheus, Grafana Mimir, Datadog, New Relic, Splunk Observability Cloud.
• Traces : Jaeger, Tempo, Datadog APM, Honeycomb.
• Logs : Loki, Elasticsearch, Datadog Logs, Splunk.
• Dashboards : Grafana est dominant, avec des offres SaaS managées (Grafana Cloud, Datadog).

L'investissement majeur est moins dans le choix du backend que dans la discipline d'instrumentation : chaque service publie ses métriques et traces avec des tags cohérents, le traceId est propagé bout en bout, les logs sont structurés (JSON) et corrélés au traceId.

Pour aller plus loin

• Architecture d'intégration moderne — où instrumenter dans le pipeline.
• Architecture ISGo 2026 — observabilité multi-tenant en pratique.
• Pattern Wire Tap et Message History — la brique technique sous l'instrumentation.
• Correlation Identifier — sans cela, pas de tracing distribué fiable.