— 18 mai 2026 · 9 min de lecture
IAM Zero Trust pour flux B2B : architecture cible 2026
Le modèle Zero Trust (NIST SP 800-207, août 2020) a structuré la sécurité IAM des applications internes depuis BeyondCorp (Google 2014). Sa transposition aux flux B2B — où le « partenaire » est par définition externe — exige quelques adaptations techniques mais reste pertinente. Esquisse d'une architecture cible 2026.
Rappel : les principes Zero Trust
NIST SP 800-207 codifie sept principes : (1) toute ressource est considérée comme un actif, (2) toutes les communications sont sécurisées indépendamment de la localisation, (3) l'accès à chaque ressource est accordé par session, (4) la politique d'accès est dynamique et fondée sur les attributs de l'identité, de l'application et du contexte, (5) l'organisation supervise et mesure l'intégrité de tous les actifs, (6) l'authentification et l'autorisation sont strictement et dynamiquement appliquées avant chaque accès, (7) l'organisation collecte autant d'information que possible sur l'état des actifs et des communications pour améliorer la posture.
La rupture conceptuelle avec le modèle périmètre : il n'y a plus de zone « interne » de confiance implicite. Chaque appel — y compris entre microservices du même hub — est authentifié, autorisé, audité. Pour des flux B2B, le partenaire n'a évidemment jamais été dans une zone de confiance ; ce qui change, c'est la cohérence des contrôles avec les autres appels.
mTLS partout : la base
Le premier pilier d'une IAM Zero Trust B2B est mutual TLS sur toutes les communications. AS2 et AS4 reposent déjà sur TLS+signature payload ; l'extension à mTLS pour authentifier le partenaire au niveau transport est recommandée par OpenPEPPOL depuis la TLS Specification 1.7. mTLS oblige le client à présenter un certificat reconnu — le service ne fait plus confiance à un identifiant porté dans le payload mais à l'identité cryptographiquement prouvée.
Côté hub interne, mTLS partout entre microservices se déploie via un service mesh : Istio, Linkerd, Consul Connect. Le sidecar gère le handshake et l'application des policies. Toujours combiner mTLS et signature payload — mTLS protège le canal, la signature protège le contenu et le non-répudiation juridique.
SPIFFE/SPIRE pour l'identité workload
SPIFFE (Secure Production Identity Framework For Everyone, CNCF graduated 2022) définit un standard d'identité cryptographique pour workloads : chaque instance reçoit un SVID (SPIFFE Verifiable Identity Document) au format X.509 ou JWT, attesté par un agent local qui prouve « cette instance tourne bien sur cette machine, dans ce namespace Kubernetes, avec ce service account ».
SPIRE est l'implémentation de référence. Pour un hub EDI 2026, SPIFFE permet de donner à chaque service interne une identité forte, rotée automatiquement (typiquement toutes les 60 minutes), et utilisable directement pour mTLS et OAuth-MTLS. Adopté en production par Pinterest, Bloomberg, Anthem (cf spiffe.io/use-cases).
OAuth-MTLS sender-constrained tokens
Pour les API REST B2B (ex : l'API d'extension d'un hub EDI utilisée par des sales-ops partenaires), OAuth 2.0 Bearer tokens sont vulnérables au vol : qui présente le token peut l'utiliser. RFC 8705 — Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (février 2020) introduit les sender-constrained tokens : le token est lié au certificat TLS du client. Sans le certificat, le token ne sert à rien — bien plus robuste qu'un Bearer simple.
L'alternative actuelle est DPoP — Demonstrating Proof of Possession (RFC 9449, septembre 2023), qui lie le token à une clé asymétrique présentée par le client à chaque requête. DPoP n'exige pas mTLS et fonctionne donc même derrière des terminaisons TLS gérées par des CDN — plus flexible mais plus complexe à implémenter correctement.
Policy as code : OPA et Cedar
Les politiques d'accès Zero Trust doivent être versionnées, testées, déployées comme du code. OPA (Open Policy Agent), projet CNCF graduated, est le standard de fait pour exprimer des policies en Rego et les évaluer à la microseconde dans un sidecar. Amazon Cedar (open source depuis 2023) propose une alternative plus typée, conçue pour scaler et auditer plus facilement.
Cas d'usage EDI : « le partenaire X peut soumettre des INVOIC, mais seulement entre 06h et 22h heure CET, depuis l'AS plage IP déclarée, avec un certificat émis par notre CA partenaire, et uniquement pour les codes EAN du catalogue de son contrat ». Une telle policy s'exprime en 20 lignes Rego et est évaluée à chaque requête sans rien recoder côté application.
Cas pratique : hub EDI 2026 cible
Esquisse d'une architecture cible. Au niveau ingress (le AS4 endpoint qui reçoit les messages PEPPOL) : terminaison mTLS exigeant un certificat reconnu par l'access point souche OpenPEPPOL ; l'identité du partenaire est tirée du subject DN du cert, vérifiée contre l'annuaire SML/SMP. La signature SBDH du payload est vérifiée séparément pour intégrité contenu et non-répudiation.
À l'intérieur du hub, chaque microservice (parser, validateur, normalizer, router) a un identité SPIFFE/SPIRE rotée. Les appels inter-services passent par un sidecar Istio en mTLS, et les policies OPA décident dynamiquement qui peut lire/écrire quoi sur quel sujet Kafka. L'audit log immuable (Kafka topic compacté, archivé sur S3 avec object lock) trace chaque évaluation de policy pour conformité GDPR et SOX.
Pour les API externes (extension hub utilisée par UX partenaire ou intégration ERP), OAuth-MTLS RFC 8705 ou DPoP RFC 9449 selon que le partenaire est capable de présenter un cert TLS ou non. Refresh token court (15 min), rotation automatique par le client.
Conclusion : pas une révolution, une convergence
L'IAM Zero Trust appliquée aux flux B2B n'est pas une rupture. AS2 a 25 ans, AS4 et signature SBDH ont toujours été des modèles « zero trust avant la lettre » pour les partenaires. Ce qui change en 2026, c'est la cohérence de bout en bout : la même rigueur d'authentification, d'autorisation et d'audit s'applique aux appels internes du hub qu'aux interactions avec les partenaires externes. SPIFFE, OAuth-MTLS, OPA et le service mesh outillent cette cohérence sans réinventer les protocoles. Pour creuser, voir notre page sécurité des flux EDI 2026.