Change de provider LLM en 3 minutes
Guide de migration avec filet de sécurité

La plupart des équipes qui veulent changer de provider LLM ne le font jamais. Pas parce que le switch est dur, mais parce que switcher en sécurité, sans casser la prod, sans perdre des semaines à réécrire, sans s'engager avec un vendor qu'on n'a pas encore validé, semble dur.

Pas besoin. Voici le chemin de migration minimum viable d'OpenAI vers Claude (ou entre deux providers compatibles OpenAI), avec un filet de sécurité qui te laisse rollback en quelques secondes.

Le changement de deux lignes

Si ton code utilise le SDK OpenAI aujourd'hui, et la plupart du code Python et JavaScript le fait, le switch minimal possible c'est :

# Avant
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

# Après
client = OpenAI(
    api_key=os.environ["HIWAY_API_KEY"],
    base_url="https://app.hiway2llm.com/v1",
)

Deux lignes. Tes appels client.chat.completions.create(...) ne changent pas. Ton code de streaming ne change pas. Ton code de tool use ne change pas.

Le proxy parle l'API OpenAI côté entrée et traduit vers le provider que tu as configuré côté sortie. Anthropic, Google, Mistral, xAI. Tu choisis le provider dans un dashboard, pas dans le code.

Ça marche parce que l'industrie a convergé sur "OpenAI-compatible" comme lingua franca. La plupart des proxies, gateways et routers modernes implémentent l'API chat completions d'OpenAI, même quand ils appellent Claude ou Gemini derrière.

Le filet de sécurité

Voici la partie que la plupart des guides de migration ratent : tu n'es pas obligé de t'engager sur un provider immédiatement. Le bon chemin de migration c'est :

Phase 1, tourne les deux en shadow. Ton trafic primaire tape toujours OpenAI. Un petit pourcentage (disons 5 %) est dupliqué vers Claude via le proxy. Tu logges la latence, le coût, et la sortie de chaque. Au bout d'une semaine, tu as des données réelles sur qualité, latence et delta de coût pour ton workload spécifique.

Phase 2, promote. Une fois que les données shadow sont propres, tu switches le trafic primaire. Le proxy est toujours là. Tu gardes OpenAI comme fallback, si Claude erre ou si la latence spike, le proxy bascule automatiquement.

Phase 3, retire le fallback. Des mois plus tard, quand tu es confiant, tu drops le fallback. Ou pas. Garder la redondance de provider ne coûte rien et te sauve le jour où un provider a un outage.

La plupart des équipes essaient de faire les trois phases d'un coup, en un week-end, et finissent par rollback quand le premier incident arrive.

Implémentation

Étape 1 : Prends une clé API chez ton provider cible

Crée un compte chez Anthropic, OpenAI, Google, qui tu veux. Prends une clé API. Funde le compte. Ça prend 3 minutes avec une carte.

Critique : la clé vit dans ton compte, pas dans le compte revendeur d'un middleware. C'est ça que veut dire BYOK. Si le middleware tombe, ta clé marche toujours en direct.

Étape 2 : Câble le proxy

Tu peux skipper si tu veux aller en direct chez le provider. Mais si tu veux le routing, les contrôles budgétaires, et le filet de sécurité, tu pointes vers un proxy :

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["HIWAY_API_KEY"],
    base_url="https://app.hiway2llm.com/v1",
)

response = client.chat.completions.create(
    model="claude-sonnet-4-6",  # ou "auto" pour smart routing
    messages=[
        {"role": "user", "content": "Combien fait 2+2 ?"},
    ],
)

Le paramètre model accepte maintenant n'importe quel nom de modèle provider. Mets-le à "auto" et le router choisit par requête.

Étape 3 : Active le shadow mode

Dans le dashboard du proxy, configure le shadow routing : 5 % des requêtes vont vers Claude en parallèle d'OpenAI. La réponse primaire est renvoyée à l'utilisateur ; la réponse shadow est loggée.

Au bout de 1 000 requêtes shadow, tu as un dataset décent. Compare :

• Coût par requête (Anthropic est souvent moins cher sur le tier Sonnet)
• Latence (le TTFT d'Anthropic est souvent meilleur ; le throughput d'OpenAI est souvent plus haut)
• Qualité de sortie (regarde 20-30 paires à l'œil toi-même ; fais pas confiance à un juge LLM là-dessus)

Étape 4 : Flip le primaire

Une fois content des résultats shadow, flip le routing : Claude est maintenant primaire, OpenAI est le fallback. C'est un changement de dashboard, pas un deploy.

Surveille ton taux d'erreur 24-48 h. Si c'est stable, t'as fini.

Étape 5 : Décide pour le fallback

Garder OpenAI en fallback ne coûte rien tant qu'il n'y a pas d'incident. Quand Anthropic a eu son outage de janvier, notre trafic a basculé vers OpenAI pendant 90 minutes sans impact visible utilisateur. Ce jour-là seul a payé le fait de garder le fallback câblé pour l'année.

Si tu es sur un budget serré et que tu fais confiance à ton primaire, tu peux drop le fallback. Mais pour des services en prod, je le garderais.

Les choses qui différeront

Quelques comportements qui ne sont pas parfaitement identiques entre providers, même à travers un proxy compatible OpenAI :

System prompts. Anthropic traite le system prompt distinctement. OpenAI le merge avec les messages user. La plupart des proxies normalisent ça, mais si tu as de très longs system prompts, teste soigneusement.

Strictness JSON du tool use. Claude est plus strict sur les tool schemas mal formés. Si tes tool definitions ont du typage lâche, OpenAI tolèrera ; Claude va errer. Fixe les tool schemas, pas la peine de blâmer le proxy.

Deltas de streaming. La shape des chunks de streaming est légèrement différente. Si ton frontend parse les deltas bruts au lieu du champ content normalisé, tu peux voir des artefacts. Utilise la couche d'abstraction du SDK.

Rate limits. La structure de tiers d'Anthropic est différente de celle d'OpenAI. Tu devras peut-être demander des augmentations de tier séparément chez chacun.

Aucun de ces points n'est bloquant. C'est la friction habituelle de changer n'importe quel composant d'infra.

Ce que tu n'as pas besoin de changer

• Tes prompts. Bouge-les tels quels d'abord, tune après si besoin.
• Ta logique de retry. Les retries du SDK OpenAI marchent inchangés à travers le proxy.
• Ton code de streaming. Les chunks ont la même allure pour ton code.
• Ton code de tool use. Même schema, même handling de réponse.
• Ton caching. Si tu cachais côté client, continue.

Le switch est principalement un changement de configuration. Le code reste.

Pourquoi bouger

Les raisons habituelles : coût plus bas, meilleur fit, redondance provider. La raison sous-estimée : l'optionalité. Une fois que tu peux switcher de provider avec un changement de config, tu négocies différemment. Tu n'es jamais lock-in. Quand Anthropic sort un meilleur modèle, tu l'essayes immédiatement. Quand OpenAI baisse ses prix, tu évalues. Quand Mistral ouvre un nouveau modèle, tu le shadow-testes en un après-midi.

Cette optionalité vaut plus que les économies de coût pour la plupart des équipes prod.

À lire aussi : BYOK, décrypté, pourquoi apporter ses propres clés est la fondation de toute cette approche.