OmniRoute : la passerelle open source qui regroupe tous vos modèles d’IA

Un assistant de code, des automatisations, un outil qui rédige des articles, un générateur d’images… Chacun a ses propres clés, ses quotas et ses jours de panne. OmniRoute propose de tout regrouper derrière une seule adresse : c’est une passerelle open source, compatible avec l’API d’OpenAI, que l’on installe sur son ordinateur ou sur un serveur. Vos outils lui parlent comme ils parleraient à OpenAI ; c’est elle qui choisit quel fournisseur répond, et qui bascule sur un autre si le premier est en panne ou à court de quota. Voici ce qu’elle sait faire, comment l’installer, et surtout ce qu’il faut régler avant de s’en servir.

OmniRoute, c’est quoi ?

OmniRoute est un routeur pour modèles d’IA : une application web, avec un tableau de bord, qui reçoit les requêtes de vos outils et les transmet aux fournisseurs que vous avez connectés.

Open source : code en TypeScript (Next.js), base de données SQLite. Le dépôt compte près de 80 000 étoiles sur GitHub et date de début 2026.
Compatible OpenAI : tout outil dont on peut changer l’adresse de l’API (SDK, éditeurs de code, outils d’automatisation) peut s’y brancher. Le projet cite aussi les embeddings, les images, l’audio et la reconnaissance de texte.
Des centaines de fournisseurs : le tableau de bord en liste environ 370 (le README en annonce 375 et le site officiel 352), que l’on connecte par clé d’API, par compte (OAuth), par une offre gratuite ou en local. Vous apportez vos propres comptes : OmniRoute ne fournit aucun crédit.
Beaucoup d’à-côtés : journal des requêtes, statistiques, suivi des quotas, ligne de commande (plus de 80 commandes annoncées), serveur MCP (110 outils annoncés) et compression du contexte envoyé aux modèles (de 15 à 95 % annoncés, environ 89 % sur l’exemple documenté : ce sont les chiffres du projet, que nous n’avons pas mesurés).
Un projet qui a changé de giron : le site officiel indique « OmniRoute has joined Cheaper Inference ». Le dépôt GitHub est hébergé sous l’organisation de cette société, qui propose aussi un service hébergé. Le code reste open source.

Une adresse, plusieurs fournisseurs

Le principe tient en une image. Vos outils envoient leurs requêtes à OmniRoute avec une clé que vous avez créée ; la passerelle les transmet au fournisseur choisi, enregistre l’appel dans son journal et passe au suivant en cas d’échec. Voici un exemple de topologie : OmniRoute au centre, une vingtaine de fournisseurs connectés autour, avec un code couleur pour leur état (actif, récent, en erreur).

Ce que cela change :

On change de fournisseur sans toucher aux outils : il suffit de modifier la passerelle.
En cas de panne ou de quota épuisé, OmniRoute passe au modèle suivant. Un fournisseur défaillant est écarté (c’est un disjoncteur), puis retesté.
On suit au même endroit qui consomme quoi, quel modèle a répondu et en combien de temps.
Les clés des fournisseurs restent sur le serveur d’OmniRoute, pas dans chaque outil.

Les combos : des chaînes de modèles avec repli

Un combo est une liste de modèles qu’OmniRoute essaie selon une règle : priorité, tourniquet, le moins cher, le plus de quota restant… Vos outils demandent le nom du combo comme s’il s’agissait d’un modèle. Sans rien configurer, le modèle auto construit un combo à partir des fournisseurs connectés, avec des variantes : auto/coding, auto/fast, auto/cheap et auto/subscription, qui n’utilise que les abonnements déjà payés et ne bascule jamais sur un modèle facturé.

Pour un combo sur mesure, un assistant en quatre étapes (nom, modèles, stratégie, validation) propose des modèles de départ : « Free Stack », « High availability », « Cost saver », « Balanced load » et « Paid Premium ».

Comment l’installer

Trois façons : npm (npm install -g omniroute, puis omniroute ; Node.js 22 ou 24), Docker, ou l’application de bureau. Nous avons installé la version 3.8.52 par npm sur une machine de test : environ deux minutes, 2,8 Go sur le disque, environ 550 Mo de mémoire en fonctionnement.

Avec Docker

				
					# Une seule commande ; le port n'est ouvert qu'en local
docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --stop-timeout 40 \
  -p 127.0.0.1:20128:20128 \
  -e INITIAL_PASSWORD=choisissez-un-mot-de-passe \
  -v omniroute-data:/app/data \
  diegosouzapw/omniroute:3.8.52

L’image Docker pèse environ 1 Go. Le dépôt propose aussi un fichier Compose qui ajoute Redis et n’ouvre les ports qu’en local par défaut. Dans le tableau de bord (en anglais par défaut, avec un sélecteur de langue en haut à droite), le guide intégré donne quatre étapes :

Créer une clé d’API (API Keys), une par environnement.
Connecter des fournisseurs (Providers) : par compte, par clé d’API ou via une offre gratuite.
Pointer son client sur l’adresse de la passerelle, suivie de /v1.
Suivre les jetons, les coûts et les erreurs (Request Logs, Analytics).

Un appel de test, d’après le README :

				
					# Remplacez VOTRE_CLE par la clé créée dans le tableau de bord
curl http://localhost:20128/v1/chat/completions \
  -H "Authorization: Bearer VOTRE_CLE" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"Bonjour !"}]}'

Attention : auto a besoin d’au moins un fournisseur utilisable. Sur notre installation vierge, sans fournisseur connecté, il n’a pas répondu : les trois fournisseurs sans clé que nous avons essayés étaient inutilisables (l’un exige maintenant une clé, un autre est fermé, un troisième demande un navigateur embarqué). Le README prévient que l’installation seule ne garantit pas une réponse.

Sécurité : à régler avant d’exposer l’instance

OmniRoute avertit lui-même au démarrage : il écoute sur toutes les interfaces et n’exige pas de clé d’API par défaut. Dans notre test, la liste des modèles réclamait une clé, mais un appel au point d’entrée de conversation n’a pas été refusé pour absence de clé : il a tenté de router la requête. Pour un usage ouvert, activez l’exigence de clé avec REQUIRE_API_KEY=true.
L’écran de connexion rappelle le mot de passe par défaut (CHANGEME) : définissez INITIAL_PASSWORD avant le premier démarrage.
Placez l’instance derrière un reverse proxy en HTTPS, ou n’ouvrez les ports qu’en local.
Les clés d’API enregistrées sont chiffrées avec un secret à définir (API_KEY_SECRET), et la base entière peut l’être (STORAGE_ENCRYPTION_KEY).

Les limites à connaître

Un projet jeune et très actif : les versions se succèdent à un rythme soutenu (3.8.50, 3.8.52…). Faites une sauvegarde avant chaque mise à jour et fixez la version de l’image.
Le « gratuit » est fragile : l’estimation de 1,62 milliard de jetons gratuits par mois est un cumul d’offres de fournisseurs tiers, pas un crédit d’OmniRoute (le README le dit), et chacun garde ses limites et ses conditions.
Des chiffres qui varient : 370, 375 ou 352 fournisseurs selon la source, 14 ou 20 stratégies de répartition selon l’écran ou le README. Lisez-les comme des ordres de grandeur.
Les conditions des fournisseurs : connecter un abonnement ou un compte web via une passerelle peut ne pas être permis par le fournisseur. OmniRoute marque certains fournisseurs « tos: avoid » et les exclut du routage automatique par défaut (une option permet de les inclure). Lisez les conditions de chacun.
Un compte connecté peut être banni : la connexion « ChatGPT Web », qui passe par la session web d’un compte ChatGPT plutôt que par l’API, peut être bannie par OpenAI. Les fournisseurs « web » et les abonnements connectés par compte dépendent des règles de leur fournisseur, qui peut les bloquer sans préavis. Gardez un repli sur une clé d’API officielle et ne connectez pas un compte dont vous ne pouvez pas vous passer.
Des bandeaux de partenaires dans le tableau de bord (certains liens sont affiliés), que l’on peut fermer. Le README assure que le sponsoring n’influence pas l’ordre de routage.
Un projet qui a rejoint une société : le code reste open source et l’auto-hébergement est toujours possible, mais c’est un point à suivre.
Une prise en main longue : ligne de commande, MCP, compression, mémoire, protocole A2A… on n’a pas besoin de tout, mais le tableau de bord est dense.

OmniRoute face à OpenRouter et LiteLLM

OpenRouter est un service en ligne qui revend l’accès à de nombreux modèles derrière une seule API : vos requêtes passent par ses serveurs. LiteLLM est un autre proxy open source que l’on héberge soi-même. OmniRoute est plutôt du côté de LiteLLM : on l’héberge et on garde ses clés, avec un tableau de bord complet, des combos avec repli et la connexion d’abonnements par compte. Le dépôt publie son propre tableau comparatif avec ces alternatives : c’est un document du projet, que nous n’avons pas vérifié ligne par ligne. OmniRoute peut aussi utiliser OpenRouter comme fournisseur : les deux ne s’excluent pas.

Pour qui ?

Pour les développeurs, indépendants et petites agences qui utilisent plusieurs outils d’IA (assistant de code, automatisations, génération de contenu) et veulent une seule adresse et une seule clé par outil, un repli en cas de panne ou de quota, et un suivi centralisé de l’usage. Moins pour qui n’utilise qu’un seul fournisseur, ne veut aucune maintenance ou ne peut pas sécuriser un serveur.

En résumé

OmniRoute est une passerelle open source qui regroupe vos fournisseurs d’IA derrière une adresse compatible OpenAI, avec des combos de repli et un tableau de bord. C’est une bonne idée pour s’y retrouver quand les outils se multiplient, à condition de la sécuriser, de vérifier les conditions de ses fournisseurs et d’accepter un projet jeune qui évolue vite. Si vous voulez de l’aide pour l’installer et la maintenir sur votre serveur, parlez-nous de votre situation.

Découvrir OmniRoute

OmniRoute sur GitHub