Pour diffusion immédiate · Londres, le 28 mai 2026
Une spécification indépendante des fournisseurs permet aux agents vocaux IA, aux SVI, aux centres de contact et aux humains de gérer les conversations en direct, avec vérification de l'identité, de l'intention, du consentement et de la continuité des médias, sur différentes plateformes. La gestion multi-fournisseurs est une condition préalable à toute version 1.0.
Cloudax a publié aujourd'hui la version préliminaire publique de OHP : le protocole de transfert ouvert, une spécification indépendante des fournisseurs pour le transfert des conversations vocales en direct entre agents IA, SVI, centres de contact et personnel humain. Le projet est disponible à l'adresse suivante : github.com/OpenHandoffProtocol/OHP sous une licence Apache-2.0.
OHP comble une lacune que l'industrie vocale contourne depuis plus de dix ans : il n'existe aucun moyen standardisé pour une IA vocale d'un fournisseur de transférer une conversation en direct, avec vérification de l'identité de l'appelant, de son intention, de l'état de la conversation, du consentement et de la continuité du flux audio, vers une IA vocale, un SVI ou un opérateur humain d'un autre fournisseur. Chaque couche en dessous de la conversation dispose déjà d'une norme. La conversation elle-même, non.
Le problème, en quatre nombres
Cet écart se manifeste dans l'expérience client et les coûts mesurables, et pas seulement dans les schémas d'architecture.
Indice CX 2025 de Forrester : les appelants sont invités à répéter les informations après un transfert du serveur vocal interactif vers un agent.
Les normes industrielles régissant le transfert d'état des conversations entre IA sont les suivantes : SIP, WebRTC, MCP et OVON, chacun possédant sa propre couche.
Formats de transfert propriétaires observés chez Genesys, NICE, Avaya, Twilio, Vapi, Retell, Bland, ElevenLabs, Cloudax, Pindrop, Cresta, PolyAI, Cognigy et Voiceflow.
Coût supplémentaire moyen par appel dû à la réauthentification et à la redécouverte lors d'un transfert à chaud (audit interne Cloudax, n = 412 000 transferts SIP, T1 2026).
“Chaque couche située en dessous de la conversation possède déjà une norme : SIP pour la signalisation, WebRTC pour les médias, MCP pour l’utilisation des outils et OpenTelemetry pour l’observabilité. La conversation elle-même n’en possède pas. OHP est la couche manquante, et elle est trop importante pour être détenue par un seul fournisseur, y compris nous.”
Définition de l'OHP
OHP est un format de transmission hiérarchisé pour le transfert de conversation en direct. compose avec, ne remplace pas, SIP, WebRTC, MCP, OVON Open Floor et les plans de contrôle CPaaS existants. La spécification définit cinq couches composables.
- L4 : Enveloppe d'état de conversation (CSE). Un document JSON/CBOR canonique signé contenant l'identité vérifiée de l'appelant, la pile d'intentions, l'état de l'emplacement, la transcription expurgée, les indications de mémoire du modèle, les accusés de réception de consentement et les preuves de continuité des médias.
- L3 : Plan de contrôle. Cinq verbes idempotents, ack-ed :
PROPOSE,ACCEPT,REJECT,ASSUME,RETURN, plus une réserveINCIDENTverbe pour le signalement d'incidents graves en vertu de l'article 73 de la loi européenne sur l'IA. - L2 : Liaisons de transport. SIP INFO, WebSocket, HTTP et gRPC : la même enveloppe circule sans modification sur les plans de la téléphonie, du web et des opérations.
- L1 : Confiance et identité. Signatures hybrides Ed25519 + ML-DSA-65 (protection post-quantique, FIPS 204), scellement HPKE par destinataire, identifiants vérifiables SD-JWT, reçus de consentement ISO/IEC 27560 et un journal de transparence de type Sigstore.
- L0 : Continuité des médias. Indications SDP re-INVITE, transfert de piste SFU et vérification optionnelle de l'empreinte audio qui lie chaque enveloppe à une branche d'appel spécifique.
Quatre niveaux de conformité : du seuil d’adoption au plafond réglementé
La technologie OHP permet à un petit fournisseur de livrer le kit sol en un week-end prolongé, tandis qu'une entreprise réglementée peut illuminer le plafond sans modifier le câblage. Chaque kit est une version étendue du précédent.
Un document JSON signé avec cinq verbes via TLS. Suffisant pour la navigation IVR anonyme, la planification, les FAQ et la continuité des appels interrompus. Implémentable en quelques jours par tout fournisseur capable d'encoder une structure JSON et de l'envoyer via HTTPS.
Ajoute un JWS Ed25519 détaché sur CBOR canonique, la publication de l'ensemble JWK et l'idempotence de l'enveloppe. Suffisant pour un service client authentifié ne contenant pas d'informations personnelles.
Ajoute le scellement HPKE par destinataire, la divulgation sélective SD-JWT VC, les accusés de réception de consentement ISO/IEC 27560, la contrainte d'expéditeur DPoP et la liaison d'empreinte numérique RTP. Suffisant pour les données de santé protégées HIPAA via des références FHIR scellées, les jetons de réseau PCI et les données personnelles identifiables transfrontalières dans le cadre d'un mécanisme de transfert légal.
Ajoute la signature hybride post-quantique, un journal de transparence de type Sigstore, l'établissement de la confiance de la fédération OpenID et des métadonnées lisibles par machine de la loi européenne sur l'IA : attestation de pratique interdite de l'article 5, journalisation de l'article 12, état de surveillance de l'article 14, preuve de divulgation de l'article 50, signalement des incidents de l'article 73 et point de terminaison du droit à l'explication de l'article 86.
Les charges de travail définissent le niveau minimal requis, et c'est le format de transmission lui-même, et non la bonne volonté du fournisseur ou les attestations trimestrielles, qui empêche les transferts non conformes. Une entreprise réglementée peut l'imposer. audience.minTier="sealed" ou "regulated" en matière d'approvisionnement, et disposer d'un mécanisme de refus automatisé au niveau du virement si une contrepartie tente de transférer les fonds en dessous de ce seuil.
Conçu pour les données réglementées dès la première ligne
OHP est le premier format de transmission vocale conçu pour être lisible par machine, conformément à la réglementation européenne sur l'IA et à la norme ISO/IEC 42001 relative aux systèmes de management de l'IA. Une seule enveloppe contient l'identité et la version du système d'IA, sa classification des risques, la clause de l'annexe III, la référence de conformité CE, les références AIIA et FRIA, la chaîne de fournisseurs GPAI (article 53), la preuve de divulgation (article 50), le dispositif de surveillance (article 14) et une chaîne de provenance structurée pour chaque décision.
Un régulateur qui tombe sur un seul hachage d'enveloppe peut reconstituer l'ensemble des responsabilités d'une conversation : quel système d'IA a traité l'appel, dans quelle catégorie de risque, ce qui a été divulgué à l'appelant et quand, qui a supervisé, quelles décisions le système a prises et pourquoi, et quels modèles en amont étaient dans la chaîne, sans outils spécifiques au fournisseur et sans accès à la charge utile.
Toute implémentation conforme doit satisfaire aux six exigences.
- Divulgation minimale. Les PAN bruts, les CVV, les mots de passe, les OTP, les SSN complets, les modèles biométriques et les PHI en texte libre sont interdits dans tous les champs OHP, à tous les niveaux.
- Divulgation sélective. Les revendications d'identité utilisent des identifiants vérifiables SD-JWT : les destinataires ne voient que les attributs auxquels ils ont contractuellement droit.
- Confidentialité de bout en bout. Les champs sensibles sont scellés HPKE par clé publique du destinataire ; les intermédiaires acheminent les octets opaques.
- Provenance cryptographique. Hybride Ed25519 + ML-DSA détaché JWS, lié à DPoP, ancré à un journal de transparence.
- Consentement et finalité contraignants. Chaque transfert s'accompagne d'un accusé de réception de consentement ISO/IEC 27560 mentionnant la base légale, l'objectif, la portée et la juridiction.
- Limité dans le temps et révocable. Les enveloppes contiennent
notAfter≤ 5 minutes, liées à une étape d'appel spécifique, avec clé révocable et identifiants de consentement.
Pourquoi les normes existantes ne comblent pas l'écart
Chaque niveau inférieur à la conversation possède déjà une norme. La conversation elle-même n'en possède pas, et OHP indique clairement ce qu'il utilise plutôt que ce qu'il remplace.
- SIP / SIP RÉFÉRENCE. Il établit, transfère et met fin aux sessions vocales, mais ne contient aucune charge utile sémantique : les en-têtes X sont ad hoc, subissent des pertes entre les opérateurs et sont limités à quelques centaines d’octets.
- WebRTC + Canal de données. Définit un flux de données, pas un schéma. Chaque fournisseur conçoit son propre format JSON par-dessus.
- MCP. Normalise la manière dont un modèle appelle les outils. Limité à un seul agent d'exécution, sans notion de conversation, d'identité de l'appelant ni de transfert multimédia.
- OVON Open Floor. Un vocabulaire de haut niveau permettant aux agents de se présenter. Aucune liaison audio/média, aucune connexion téléphonique, aucune gestion du consentement ou de la conservation des données.
- CCXML / VoiceXML. Scripting IVR pré-LLM. Pas d'état du modèle, pas d'intégrations, pas de flux partiels.
- Webhooks CPaaS et données jointes CC. Lié à un seul fournisseur ; à sens unique ; aucune place pour l'état de l'IA et aucune défense transfrontalière.
- OpenTelemetry GenAI semconv. Télémétrie en lecture seule, et non une enveloppe de transfert en cours d'exécution.
Gouvernance : rédigée par Cloudax, une société appartenant au secteur.
Cloudax publie OHP sous licence Apache 2.0 avec un modèle de contribution basé uniquement sur DCO et ne conserve la mainmise que sur la série v0.x. Avant toute publication de la version 1.0, l'entreprise réunira un groupe de travail avec au moins trois fournisseurs d'IA vocale autres que Cloudax et transférer la gestion à un comité de pilotage multi-fournisseurs.
Une suite de tests de conformité publique est fournie avec le projet de spécification. Toute modification de cette dernière doit s'accompagner de nouveaux vecteurs de test, et l'outil d'exécution des tests de conformité fait foi quant à la signification de l'expression « parle OHP ».
“Cette norme doit appartenir au secteur qu'elle sert, et non à nous. Nous rédigeons la première version et publions la première implémentation de référence. Ensuite, nous rejoindrons les instances de décision, en tant que simples acteurs parmi d'autres.”
Feuille de route vers la version 1.0
- v0.1 : aujourd'hui. Publication du projet de loi public, de l'implémentation de référence et du générateur de conformité. Début des échanges avec les partenaires de conception.
- v0.2. Deux prestataires externes ont été intégrés ; des bancs d'essai publics ont été publiés.
- v0.9 RC. Groupe de travail élargi ; examen final des candidats par rapport au système d'analyse de conformité.
- v1.0. Le groupe de travail dirigé par Cloudax devient un comité de pilotage multi-fournisseurs.
Partenaires de référence pour la mise en œuvre et la conception
Cloudax a publié une implémentation de référence basée sur sa plateforme d'IA vocale existante, Cloudax Fabric. Le générateur de conformité complet, le schéma JSON, les règles de canonisation CBOR et des exemples d'enveloppes sont disponibles avec la version préliminaire.
Cloudax recherche activement des partenaires de conception et des participants à ses groupes de travail parmi les plateformes de centres de contact, les fournisseurs de CPaaS, les environnements d'exécution d'IA vocale, les fournisseurs de biométrie vocale, les fournisseurs d'identité et les entreprises déployant des solutions réglementées. Les fournisseurs qui utilisent déjà des formats de transfert propriétaires sont expressément invités : la conception progressive d'OHP vise à simplifier l'adoption et à la rendre rapide, sans nécessiter de déploiement complexe.
Disponibilité
À propos d'OHP
OHP (Open Handoff Protocol) est une spécification indépendante des fournisseurs permettant le transfert de conversations vocales en direct : contexte, intention, état, identité, consentement et média, entre agents vocaux IA, SVI, centres de contact et interlocuteurs humains. Conçu pour s’intégrer aux plans de contrôle SIP, WebRTC et HTTP/WS sans imposer de plateforme d’exécution, de modèle ou de fournisseur de téléphonie spécifique, il est optimisé dès le départ pour les flux de données réglementés. Ainsi, l’état d’authentification, les résultats d’identification et de vérification, les instructions de paiement, le contexte médical et autres données personnelles sensibles peuvent franchir les frontières entre fournisseurs avec la même valeur juridique qu’un message ISO 20022 échangé entre banques.
À propos de Cloudax
Cloudax conçoit des infrastructures d'IA vocale pour les entreprises des secteurs réglementés. L'entreprise est à l'origine de la version préliminaire publique d'OHP et assure la maintenance de l'implémentation de référence initiale. Cloudax est responsable uniquement de la série v0.x de la spécification et s'engage à une gestion collaborative entre plusieurs fournisseurs avant toute publication de la version 1.0.
Contact presse et rédaction
Rédacteurs des spécifications, demandes de renseignements de la presse et participation aux groupes de travail : [email protected]
Vous souhaitez contribuer à façonner OHP ? Rejoignez le groupe de travail.
Les fournisseurs, opérateurs, fournisseurs d'identité et organismes de réglementation sont invités à participer. Que vous déployiez Core en un week-end prolongé ou que vous imposiez la conformité réglementaire dans votre processus d'achat, la protection contre la pollution de l'information (OHP) n'est efficace que si elle constitue la norme adoptée par l'ensemble du secteur, et non celle que Cloudax définit seul.
