DanLevy.net

Il est temps d’adopter les chaînes de connexion llm://

Simplifiez la configuration des modèles et des fournisseurs avec des URL llm://

Mise à jour : Cet article a donné naissance à un Internet-Draft pour le schéma d’URI llm:// ainsi qu’à un package npm llm-strings associé. L’implémentation est également disponible sur GitHub.

Vous vous souvenez de la bonne vieille époque où se connecter à une base de données signifiait jongler avec un fourre-tout de variables d’environnement ?

C’était une tour de configuration délicate. DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME… ou attendez, c’était DB_USERNAME ? C’est DB_PASS ou DB_PWD ? Cette fois, il faut les préfixes PG_* ? Et où diable faut-il mettre le délai d’expiration ?

Un château de cartes fragile, prêt à faire s’écrouler votre build de production parce que vous aviez oublié de mettre HOST en majuscules.

Puis quelqu’un a eu l’idée brillante d’utiliser simplement une URL¹ :

Terminal window
postgres://user:pass@host:5432/dbname

Une seule chaîne. Tout ce qu’il faut. Analysable partout. Portable. Oserais-je dire… élégante ?

Alors pourquoi traitons-nous les LLM comme si nous étions en 1999 ?

L’explosion des variables d’environnement

À l’heure actuelle, mon fichier .env ressemble à un cimetière de clés d’API abandonnées. OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY. Et ne me lancez même pas sur Azure : il vous faut un endpoint, un nom de déploiement, une version d’API et une clé, rien que pour dire « bonjour ».

Ce n’est pas seulement laid ; c’est une source de friction. Chaque fois que je veux changer de modèle ou tester un nouveau fournisseur, je réécris le code d’initialisation, je fouille la documentation pour retrouver les noms de paramètres propres à chacun, et j’ajoute trois lignes de plus à ma configuration d’environnement.

Et si on… volait empruntait simplement l’idée des URL de bases de données ?

Présentation des chaînes de connexion LLM

Imaginez configurer toute l’interface de votre modèle sur une seule ligne :

Terminal window
llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

Anatomie d’une chaîne de connexion LLM

les éléments d’une chaîne de connexion LLM

Le schéma est llm://. L’hôte est l’URL de base de l’API du fournisseur. Le chemin contient le nom du modèle. Et les paramètres de requête prennent en charge toutes les options d’exécution qui encombrent habituellement votre code.

Besoin d’authentification ? Parfait, ajoutez-la.

Comme avec postgres://, on peut intégrer l’authentification directement :

Terminal window
llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

Remarque : oui, placer des identifiants dans des URL peut poser un risque de sécurité si vous les collez dans des journaux publics. Mais les services de journalisation modernes savent plutôt bien nettoyer ces motifs — et, franchement, traitez-vous vraiment mieux votre fichier .env ? Vérifiez, assainissez et utilisez cette approche avec prudence.

De la résilience ? Pourquoi pas, bon sang.

De nombreuses bibliothèques de bases de données prennent en charge le basculement en round-robin en spécifiant plusieurs hôtes. Pourquoi nos agents IA n’auraient-ils pas droit à la même fiabilité ?

Terminal window
llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

Ce s dans llms:// n’est pas une coquille. Il indique le pluriel. Si primary.gpt reste bloqué, le client réessaie automatiquement avec backup.gpt. Aucune logique de routage complexe n’est nécessaire.

Une seule chaîne contient tout, de votre authentification à votre endpoint, en passant par vos hyperparamètres.

Formats alternatifs

Je ne suis pas marié à llm://. Le schéma choisi compte moins que le standard lui-même.

On peut imaginer un monde où nous utiliserions des schémas propres à chaque fournisseur pour gagner en concision, tout en conservant la structure standard :

Terminal window
ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

Quelle que soit la syntaxe exacte, les bénéfices fondamentaux sont indiscutables :

  1. Portabilité : copiez-collez toute votre configuration d’un script local vers un worker cloud.
  2. Compatible avec les CLI : transmettez un seul argument à vos scripts. my-agent --model "llm://..." est préférable à my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
  3. Indépendant du langage : tous les langages de programmation disposent d’un parseur d’URL robuste. Validation, analyse et assainissement sont offerts.
Le monde des bases de données a mis des décennies à comprendre ça.
Bonne nouvelle : selon les calendriers de l’IA, cela ne représente qu’environ un demi-an de vibes.

Le verdict

Nous n’avons pas besoin d’un énième standard de configuration complexe ni d’un nouveau fichier manifeste fondé sur YAML. Il nous suffit d’utiliser l’outil qui fonctionne pour le reste d’Internet depuis 30 ans.

Arrêtons de réinventer la roue et commençons à traiter nos connexions LLM avec le même respect que nos bases de données. Votre fichier .env — et votre santé mentale — vous remercieront.

un tiroir chaotique de variables d’environnement

Loading comments...