Capacity planning pour pics de trafic B2B

Un hub EDI tient sans broncher 99,9 % du temps — puis sature le 30 juin à 23h pendant le pic de fin de mois, ou le 1er juillet 2030 pendant le cut-over ViDA. Le capacity planning EDI doit anticiper les pics, pas seulement la moyenne.

Quels pics anticiper en EDI 2026

Le profil de charge d'un hub EDI est très inégal :

• Fin de mois : tous les ERP émettent leurs INVOIC mensuelles entre le 25 et le 31. Pic ~5x au-dessus du baseline.
• Fin de trimestre / d'année : pic ~8-10x, avec forte concentration le dernier jour ouvré.
• Black Friday / Cyber Monday : pour le retail, multiplication 10-50x des ORDERS pendant 4-5 jours.
• Cycles de promotion saisonnière : soldes d'hiver/été France, Sales US, Prime Day Amazon, Singles Day Alibaba (11 nov).
• Cut-over réglementaire : 1er juillet 2030 pour ViDA, autres dates pour mandats nationaux. Pic durable de plusieurs semaines.
• Pic d'incident : après une panne partenaire de 6h, le rattrapage envoie 6h de backlog en quelques minutes. Effet thundering herd.

Modéliser avec Little's Law

La loi de Little (John Little, 1961) est la brique fondatrice du capacity planning :

L = λ × W

L : nombre moyen de requêtes en cours (in-flight)
λ : taux d'arrivée des requêtes (msg/s)
W : temps moyen passé dans le système (latence end-to-end)

Exemple pratique pour un hub EDI : si on traite 500 msg/s en baseline avec 200 ms de latence moyenne, on a en moyenne 100 messages in-flight. Si le pic est 5x (2 500 msg/s) à latence inchangée, il faut pouvoir maintenir 500 messages in-flight. Si on n'a que 200 slots de concurrence, on sature — les nouveaux messages sont mis en queue (backlog) ou rejetés (HTTP 429, AS4 503).

Pour chaque composant du hub (ingestion AS4, parser, validator, mapping, publisher broker), calculer L, λ, W actuels et projetés. Identifier le goulot d'étranglement (composant avec L/capacity ratio le plus haut).

Définir le headroom approprié

Le headroom est la marge de capacité disponible au-dessus de la charge moyenne. Trop bas : saturation au moindre pic. Trop haut : surcoût permanent. Règles de référence :

• Headroom 30 % (charge cible ≤ 70 %) : pour flux prévisibles (par ex. INVOIC fin de mois), sans pic anormal.
• Headroom 50 % (charge cible ≤ 50 %) : pour flux avec pics réguliers (Black Friday), permet d'absorber sans autoscaling complexe.
• Headroom 100-200 % (charge cible ≤ 33 %) : pour flux à pics imprévisibles ou très critiques (santé HL7v2 temps-réel).
• N+1 ou N+2 redondance : une instance ou deux de plus que le minimum, pour absorber une panne sans dégrader le service.

Brendan Gregg (méthode USE, 2012) recommande d'alerter à 70 % d'utilisation et de passer en mode critique à 80 %. Au-delà de 90 %, la file d'attente explose non-linéairement (théorie des files M/M/1).

Autoscaling pour EDI : limites et patterns

L'autoscaling cloud (AWS ASG, GCP MIG, K8s HPA/KEDA) fonctionne bien pour les API REST stateless. Pour EDI, trois limites :

• Latence de scale-up : 30-90 secondes pour provisionner un nouveau pod K8s ou une nouvelle instance EC2. Pendant ce délai, le pic sature le pool existant. Pour les pics brefs (< 1 min), l'autoscaling arrive après la bataille.
• Connexions partenaires stateful : AS4 et OFTP2 maintiennent des sessions TLS persistantes. Un nouveau pod doit renégocier le handshake, ce qui prend 50-200ms supplémentaires sans session resumption configurée.
• Brokers : Kafka, RabbitMQ ne scalent pas en minutes (ajout de broker = rebalance des partitions). Doivent être provisionnés à l'avance pour le pic anticipé.

Patterns recommandés :

• Predictive scaling : scale-up programmé avant les pics récurrents connus (fin de mois, Black Friday) via cron ou AWS Predictive Scaling.
• Queue depth based scaling : scale les consumers Kafka/SQS en fonction du lag, pas du CPU. Plus prédictif.
• Pre-warmed pool : garder 2-3x la capacité baseline en permanence, scale rapide sur le facteur résiduel uniquement.

Tests de charge réalistes

Un test de charge EDI doit reproduire la réalité partenaire :

• Mix de messages : pas seulement des ORDERS, mais le bon ratio ORDERS/DESADV/INVOIC/CRDADV observé en production.
• Taille de payload : distribution réelle (un INVOIC moyen 50 lignes, mais 5 % des INVOIC font 5 000+ lignes — ce sont eux qui cassent le parser).
• Distribution temporelle : ne pas envoyer en flux constant lissé, mais avec des bursts (loi de Poisson, paramètre λ adapté).
• Connexions concurrentes : si on a 200 partenaires AS2, simuler 200 sessions TLS distinctes, pas une session unique en boucle.

Outils 2026 : k6 (Grafana Labs, Go-based, scriptable JS), Gatling (Scala, suite enterprise), Locust (Python), Apache JMeter (legacy mais largement déployé), Vegeta (CLI Go, simple). Pour les protocoles EDI spécifiques (AS2, AS4, OFTP2), aucun outil grand public ne couvre — il faut écrire des injecteurs custom basés sur les libs de production (phase4 pour AS4, Mendelson SDK pour OFTP2).

Dimensionnement broker, DB, network

Trois ressources qui se saturent typiquement avant le compute :

Kafka

• Compute : 2-4 cores par broker pour 10 000 msg/s par broker. Réserver 30 % CPU pour la compaction et la rebalance.
• Disque : IOPS critique. Sur AWS, recommander gp3 EBS avec IOPS provisionnés ou io2 pour très haut débit. Capacité = rétention en jours × volume quotidien × replication factor.
• Partitions : 1000-2000 partitions par broker max (au-delà, latence controller dégradée). Pour ordre par partenaire, partitionner par partner_id.
• Network : 1-10 Gbps par broker. Replication trafic = N-1 × produce trafic.

PostgreSQL

• Connexions : max 200-300 connexions actives par instance, mettre PgBouncer en front pour multiplexer.
• WAL : si on utilise CDC (Debezium), garder rétention WAL ≥ lag max consumer + 24h marge.
• IOPS : 5 000-20 000 IOPS pour un hub à 10M msg/mois.
• Replicas read-only : 1-3 replicas pour les projections CQRS et les requêtes BI.

Network egress

Les hubs EDI consomment significativement de bande passante sortante (publication broker cross-region, envoi AS4 vers partenaires). Sur AWS, le coût egress vers internet est ~0,09 USD/GB pour les premiers To, dégressif ensuite. Pour 100M msg/mois × 5 KB moyens = 500 GB/mois, soit ~45 USD/mois. Mais avec cross-region replication Kafka 3 réplicas inter-AZ, le coût peut décupler.

Cas spécifique : pic ViDA 2030

Le 1er juillet 2030 à minuit, la directive ViDA Pillar 3 s'applique à toutes les transactions B2B intra-UE. Conséquences :

• Des dizaines de milliers d'entreprises basculent simultanément vers l'e-invoicing structuré EN 16931.
• Les opérateurs PEPPOL (Pagero, Storecove, Comarch, Sovos, B2Brouter) voient leur trafic potentiellement multiplié par 5-10 en 24 heures.
• Les hubs internes des grands groupes (qui jusque-là émettaient en PDF ou EDIFACT bilatéral) doivent basculer leurs flux vers PEPPOL.

Plan d'anticipation recommandé :

• 2027-2028 : pilotes à 10 % du volume en parallèle.
• 2029 : ramp-up progressif à 50 % du volume.
• S1 2030 : 80 % du volume, plein régime des infrastructures.
• 30 juin 2030 : maintenance window contrôlée, équipe d'astreinte renforcée, capacité 200 % du nominal.
• 1er juillet : surveillance 24/7, capacité 300 % des prévisions pendant la première semaine, dégressif ensuite.

Pour aller plus loin

• Disaster Recovery EDI — pour dimensionner la région DR de façon cohérente.
• Stack monitoring EDI — pour mesurer la charge et anticiper les pics.
• Back-pressure — pour gérer les pics quand le scaling arrive trop tard.
• Rate Limiter — pour protéger les downstreams pendant les pics.
• Little J.D.C. — A Proof for the Queuing Formula L = λW, Operations Research 1961.
• Gregg B. — The USE Method: Utilization Saturation and Errors, 2012. brendangregg.com/usemethod.html
• Allspaw J. — The Art of Capacity Planning, 2e éd. O'Reilly 2017.
• Google SRE Book — chap. 5 « Eliminating Toil » et chap. 21 « Handling Overload ». sre.google/sre-book
• AWS — Capacity Planning for Microservices, Architecture Blog 2024.