← L'édition
IANouveau2 min de lecture

OpenAI Realtime : l'identifiant connector_id déprécié au profit des serveurs MCP

OpenAI a mis à jour la documentation technique de son API temps réel pour préciser l'évolution de ses intégrations. Pour les modèles récents, les connecteurs intégrés laissent définitivement leur place aux serveurs MCP configurés par URL ou tunnel sécurisé.

Fil « Changement de compatibilité MCP dans l'API OpenAI Realtime »

Illustration de l'article — developers.openai.com
Image : developers.openai.com

Lors du développement d'applications réactives avec l'API Realtime d'OpenAI (interface de communication réseau bidirectionnelle en direct pour le texte et la voix), deux approches permettent de fournir des outils au modèle. D'une part, les function tools (fonctions exécutées sur vos propres serveurs ou clients), et d'autre part, les outils MCP (Model Context Protocol, un standard ouvert d'interconnexion entre modèles d'IA et services externes). Avec les outils MCP, c'est l'API d'OpenAI qui exécute elle-même les requêtes vers le serveur distant.

Une mise à jour importante de la documentation vient clarifier les règles de compatibilité pour les équipes d'ingénierie. L'attribut connector_id (identifiant permettant d'utiliser d'anciens connecteurs intégrés comme Google Calendar) est officiellement déprécié pour tous les modèles publiés après le 1er septembre 2026, à l'image du modèle gpt-realtime-2.1. Seules les versions antérieures, telles que gpt-realtime-1.5, conservent la prise en charge de ces connecteurs dits legacy (hérités d'anciennes versions).

Migration vers server_url et tunnel_id

Pour vos projets s'appuyant sur les modèles récents, le raccordement à un serveur d'outils doit désormais employer le champ server_url dans la configuration de session, ou le champ tunnel_id pour joindre un serveur local à travers un tunnel sécurisé (Secure MCP Tunnel). L'exemple suivant montre la structure requise lors de l'envoi d'un événement de mise à jour de session :

{
  "type": "session.update",
  "session": {
    "type": "realtime",
    "model": "gpt-realtime-2.1",
    "tools": [
      {
        "type": "mcp",
        "server_label": "docs_interne",
        "server_url": "https://api.entreprise.internal/mcp",
        "allowed_tools": ["search_docs"],
        "require_approval": "never"
      }
    ]
  }
}

Gestion explicite du cycle de vie des appels

Outre cette rupture de compatibilité au niveau du schéma de configuration, OpenAI détaille le cycle de vie des événements transmis via WebSockets ou WebRTC (protocoles de communication réseau en temps réel). Les points d'attention majeurs pour vos architectures sont :

  • La phase d'importation : l'API émet un événement mcp_list_tools.in_progress puis mcp_list_tools.completed. Le modèle ne peut appeler un outil tant que sa liste n'est pas complètement chargée.
  • Les autorisations : si require_approval n'est pas réglé sur never, le client doit intercepter mcp_approval_request et répondre par un mcp_approval_response pour débloquer l'exécution.
  • Le suivi des réponses : l'API OpenAI ne génère pas automatiquement de relance après l'exécution d'un outil MCP. Une fois l'appel terminé (marqué par l'événement response.output_item.done), votre code client doit explicitement renvoyer un événement response.create afin d'inciter le modèle à exploiter le résultat retourné.