Ne pas lier une application IA à un seul fournisseur.

Contexte

Un appel API devient vite une dépendance.

Au départ, brancher un modèle à une application est direct : un appel HTTP, une clé API, une réponse. Cette simplicité cache un couplage qui se révèle vite : la forme exacte de l’API du fournisseur, le nom du modèle, son comportement de retry, son coût, sa latence, ce qui quitte réellement la machine, et ce qui se passe quand ce chemin échoue. Sans couche intermédiaire, ces décisions se dispersent dans le code applicatif au lieu d’être posées une fois, explicitement.

Ce qui a été construit

Une interface commune et des règles explicites

• Interface AIRuntime.generate() : un point d’entrée commun pour tous les appels de génération.
• Adaptateurs par fournisseur : OpenAI, Anthropic, Mistral et Ollama derrière une même interface ; cloud et local traités de la même façon côté application.
• Routage déterministe par politique : des politiques YAML décident du chemin exécuté plutôt qu’une sélection opaque.
• Retry et fallback structurés : un nombre de tentatives défini, puis un chemin alternatif si le premier échoue.
• Observabilité structurée : latence, fournisseur, chemin exécuté et coût estimé journalisés, sans prompt, réponse ni secret.

Architecture

Les politiques décident, les adaptateurs exécutent

L’application appelle le runtime ; une politique sélectionne un fournisseur et un modèle ; l’adaptateur traduit ensuite l’appel pour le fournisseur concerné. Les tentatives, la reprise et les métadonnées sont gérées autour de ce chemin, plutôt que dans chaque cas d’usage. Le Runtime n’essaie pas de masquer les différences entre fournisseurs : il impose un contrat commun autour duquel le routage, le retry et le fallback peuvent être testés une fois, plutôt que réimplémentés à chaque intégration.

Choix et compromis : la souveraineté a un coût opérationnel

Les zones S0 Frontier, S1 Hybride et S2 Souveraine sont des conventions de routage internes, pas des labels. Elles expriment un niveau de confidentialité ou de performance visé par une politique ; elles ne constituent ni une certification ni une garantie de conformité réglementaire.

Le coût est estimé au mieux à partir des métadonnées renvoyées par chaque fournisseur. Les prix et le comportement des fournisseurs changent, et les paramètres de génération ne sont pas parfaitement interchangeables d’un fournisseur à l’autre.

Le mode local évite l’envoi du contexte vers un fournisseur distant : c’est un gain réel de contrôle sur la donnée. Mais sur la machine de test (un portable CPU-only, sans GPU), ce gain a un coût direct : qwen3:4b via Ollama répond en dizaines de secondes, contre quelques centaines de millisecondes pour Mistral dans le cloud. Ce n’est pas un verdict sur les modèles eux-mêmes, mais la démonstration d’un compromis matériel : la confidentialité locale se paie en latence sur du matériel contraint, et l’architecture doit rendre ce compromis explicite et réversible plutôt que de le masquer derrière une interface uniforme.

Validation

Mesurer les chemins réellement exécutés

Les intégrations Mistral et Ollama ont été exécutées en conditions réelles. Le fallback local → distant a été testé en rendant volontairement indisponible l’endpoint Ollama : les tentatives locales échouent, puis Mistral prend le relais sans intervention manuelle. Les journaux de métadonnées ont été contrôlés pour vérifier l’absence de prompts, de réponses et de secrets.

Les trois chemins ont exécuté les 10 requêtes du benchmark sans échec. En local, Ollama avec qwen3:4b affiche une moyenne de 29,5 s (p95 : 48,9 s), avec un écart marqué entre la requête la plus rapide (7,1 s) et la plus lente (53,8 s), signe d’une forte variance sur ce matériel. Interrogé directement, Ollama tourne à un débit de 6,46 jetons/s avec un premier chargement de 12,4 s, pour une moyenne quasi identique (30,3 s ; p95 : 43,7 s). Mistral répond en 447 ms de moyenne (p95 : 715 ms ; minimum 282 ms, maximum 851 ms). Ces chiffres ne classent pas les modèles entre eux : mesurés sur un Intel i7-8650U CPU-only, 4 cœurs / 8 threads, 16 Go de RAM, ils décrivent un compromis matériel (confidentialité locale contre latence cloud) dans cet environnement précis, pas une comparaison générale entre fournisseurs. Sur ce benchmark, le coût par requête Mistral était estimé entre 0,000006 $ et 0,0000084 $.

Limites connues

Pas encore un service de production

• Maturité de production : pas de déploiement de production complet ni de SLA.
• Échelle : pas de test de charge à grande échelle ni d’orchestration multi-instance.
• Sécurité : pas d’audit de sécurité complet.
• Télémétrie de coût : estimation au mieux, pas une facturation exacte.
• Dépendance à l’environnement : les performances locales dépendent fortement du matériel et du modèle choisis ; le comportement et la tarification des fournisseurs peuvent évoluer.