Stack IA : concevez-la pour pouvoir la remplacer

Stack IA : concevez-la pour pouvoir la remplacer

Chaque fonctionnalité IA que vous construisez repose sur un tarif qui n'est pas réel. Les API des modèles de langage sont aujourd'hui lourdement subventionnées par leurs fournisseurs, qui brûlent du capital pour gagner des parts de marché. Comme Uber et Lyft à leurs débuts, où une course coûtait moins cher que le bus. Quand les subventions s'arrêteront, et elles s'arrêteront, le vrai coût de votre stack IA va se révéler.

La question n'est pas de savoir si les prix vont augmenter, mais quand. Et à ce moment-là, votre architecture décidera si vous pouvez changer de fournisseur ou subir.

Ce n'est pas un problème nouveau. Les DSI ont toujours dû arbitrer entre vitesse de mise sur le marché et coût de la dépendance. Ce qui change aujourd'hui, c'est la vitesse à laquelle ces dépendances sont construites, souvent sans aucune visibilité.

Illustration par Google DeepMind

Ce que vous contrôlez : la couche d'abstraction

Le socle de la portabilité, c'est la couche d'abstraction : un service interne que vos applications appellent au lieu d'appeler directement Claude, GPT ou Gemini.

# Au lieu de faire ça dans chaque service :
import openai
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[...]
)

# Vous faites ça :
from your_gateway import llm
response = llm.chat(
    model="claude-sonnet",  # change ici, rien d'autre
    messages=[...]
)

Le principe est simple : votre service définit un format de requête, et la couche d'abstraction le traduit vers le format attendu par le fournisseur derrière. Changer de fournisseur devient un changement de configuration, pas une réécriture de code.

Vous n'avez pas besoin de construire ça de zéro. Des outils open-source existent :

• LiteLLM : le plus adopté. Propose une interface compatible OpenAI pour plus de 100 fournisseurs. Gère le fallback, le rate limiting, le suivi des coûts.
• Portkey : plus orienté observabilité et gouvernance. Idéal si vous avez besoin de tracing et de contrôle d'accès.

Un ou deux ingénieurs peuvent mettre en place l'essentiel en 2 à 3 semaines. Commencez par le cas d'usage principal : text in, text out, tool calls. Laissez de côté le fine-tuning et les batch APIs pour plus tard.

Ce que vous ne contrôlez pas, et qui coûte cher

L'appel API est la partie facile à abstraire. Les vraies dépendances sont ailleurs, et elles sont plus insidieuses.

Les prompts sont calibrés sur un modèle spécifique

Chaque modèle a ses particularités. Un prompt optimisé pour Claude ne donnera pas les mêmes résultats sur GPT-4o ou Gemini. Les instructions de format, le ton, la structure des réponses, tout ça est finement ajusté à un modèle. Si vous changez de fournisseur, prévoyez de re-calibrer chaque prompt.

Les embeddings ne sont pas interchangeables

Les vecteurs générés par le modèle d'embedding d'un fournisseur ne sont pas compatibles avec ceux d'un autre. Changer de fournisseur d'embedding signifie ré-embedder toute votre base de connaissance. Selon la taille de votre corpus, cela peut prendre des jours et coûter des milliers d'euros en calcul.

Le tool calling et le structured output

Chaque fournisseur a ses propres conventions pour le tool calling et le structured output (JSON mode, function calling, etc.). Le code écrit autour du schéma d'un modèle devra être réécrit pour un autre.

Le caching et le batching

Les mécanismes de caching et de batching sont spécifiques à chaque fournisseur, avec des règles de calcul de coût qui ne se recoupent pas. Ce qui est rentable chez un fournisseur peut ne pas l'être chez un autre.

En résumé : la portabilité du code est bon marché et bien outillée. La portabilité comportementale est le vrai coût, et aucun gateway ne la résout pour vous.

Comment auditer votre dépendance réelle

La plupart des équipes ne réalisent pas à quel point elles sont verrouillées tant qu'elles ne sont pas forcées de bouger. C'est le pire moment pour le découvrir.

Si vous voulez une réponse honnête, pas une estimation : prenez un workflow non critique et essayez de le porter vers un autre modèle. Regardez ce qui casse et combien de temps il faut pour réparer. Ce test révélera vos dépendances mieux qu'aucune checklist.

Quelques questions à vous poser dès maintenant :

• Combien de parties de votre codebase importent directement un SDK fournisseur, plutôt qu'une fonction interne partagée ?
• Vos prompts sont-ils stockés de manière centralisée ou dispersés dans le code ?
• Avez-vous une stratégie de test qui compare les sorties de différents modèles sur les mêmes entrées ?

Une stratégie viable pour un SaaS

Si vous construisez un SaaS, l'approche pragmatique est la suivante :

1. Mettez en place LiteLLM ou Portkey comme gateway : c'est le pare-feu contre le lock-in.
2. Centralisez vos prompts dans un système de templates versionné (pas de strings en dur dans le code).
3. Testez systématiquement sur au moins 2 modèles : si vos réponses sont qualitativement différentes, c'est un signal d'alarme.
4. Préférez les modèles open-weight pour le fine-tuning : si vous devez absolument fine-tuner, faites-le sur un modèle que vous pouvez héberger vous-même (Llama, Mistral).
5. Gardez un fonds de migration : budgétez 2 à 3 semaines par an pour pouvoir changer de fournisseur si nécessaire.

Un exemple concret : le routage chez LiteLLM

Pour que ce ne soit pas de la théorie, voici à quoi ressemble une config LiteLLM minimale qui route vers plusieurs fournisseurs :

model_list:
  - model_name: "assistant-principal"
    litellm_params:
      model: "anthropic/claude-sonnet-4"
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: "assistant-principal"
    litellm_params:
      model: "openai/gpt-4o"
      api_key: os.environ/OPENAI_API_KEY
  - model_name: "assistant-economique"
    litellm_params:
      model: "groq/llama-3.3-70b"
      api_key: os.environ/GROQ_API_KEY

Avec cette config, votre application appelle assistant-principal sans savoir quel modèle se cache derrière. LiteLLM applique les règles de fallback : si Anthropic est indisponible ou trop lent, la requête part chez OpenAI. Vous pouvez aussi basculer un environnement de staging vers le modèle économique pour réduire les coûts, sans toucher au code applicatif.

Les tests de régression comportementale

Le piège, c'est de croire que le gateway suffit. La portabilité réelle se joue sur le comportement, pas sur l'appel. Mettez en place une suite de tests qui :

1. Fixe des golden prompts : une centaine de cas représentatifs de vos usages réels, stockés dans des fichiers versionnés.
2. Joue les mêmes entrées sur 2 modèles différents : comparez la structure, le format, la pertinence des réponses.
3. Mesure le coût par requête : le même résultat peut coûter 3 fois plus cher chez un fournisseur que chez un autre.

Ces tests ne sont pas un luxe. Ils transforment le changement de fournisseur d'un pari risqué en opération maîtrisée. Le jour où votre fournisseur principal annonce une hausse de prix, vous savez déjà exactement quoi faire, et combien ça coûtera.

Conclusion

Traitez les fournisseurs d'IA comme n'importe quel autre fournisseur d'infrastructure où le risque de concentration existe. Les prix des API IA vont augmenter : c'est une question de temps, pas de probabilité. Quand ce moment arrivera, les équipes qui auront architecturé pour la portabilité pourront négocier, bouger, ou simplement dire non.

Les autres paieront deux fois : le nouveau tarif, et la réécriture.

Checklist pour votre prochain sprint :

• Mettre en place une couche d'abstraction (LiteLLM ou Portkey)
• Router un premier workflow non critique via le proxy
• Centraliser les prompts dans un système versionné
• Porter un workflow vers un autre modèle et mesurer l'effort
• Documenter les dépendances identifiées (embeddings, tool calling, caching)