Alias, latest et versions figées

Les trois façons de référencer un modèle

Le champ model de votre requête accepte trois conventions de nommage pour désigner ce qui est, en apparence, le même modèle. Ce n’est pas une subtilité de documentation : selon la convention retenue, votre application recevra soit exactement le même modèle à chaque appel pendant des mois, soit une version susceptible de changer sans que vous en soyez averti. La plupart des régressions inexpliquées en production — « nos réponses sont devenues plus longues, personne n’a rien touché » — viennent de là.

Alias simple

L’alias simple utilise le nom de base du modèle, sans suffixe :

{
  "model": "grok-4.20"
}

Cette écriture désigne la dernière version stable du modèle. xAI peut faire évoluer la version sous-jacente à tout moment, et vous ne le saurez qu’en observant vos propres sorties. C’est précisément la souplesse que l’on recherche en développement et en prototypage : vous travaillez toujours avec la meilleure version disponible sans avoir à mettre à jour quoi que ce soit. Tant que vous itérez sur vos prompts, que vous explorez les capacités du modèle et que la reproductibilité exacte des réponses ne conditionne rien, cette convention est la bonne.

Alias latest

L’alias latest pointe vers la version la plus avancée, celle qui n’a pas encore été stabilisée :

{
  "model": "grok-4.20-latest"
}

Ce que vous obtenez ici peut changer fréquemment et embarquer des modifications encore en cours de validation. C’est un outil d’évaluation, utile pour éprouver les prochaines versions avant qu’elles ne deviennent l’alias par défaut, mesurer un gain de qualité ou de performance, et préparer votre migration en connaissance de cause.

Sa place est en environnement de test, jamais en production. Un changement peut survenir du jour au lendemain, modifier le comportement de vos prompts et se propager à vos utilisateurs sans le moindre préavis — vous n’aurez ni ligne de commit ni ticket à incriminer pour comprendre ce qui s’est passé.

Version figée

La version figée inclut une date dans l’identifiant :

{
  "model": "grok-4.20-0309"
}

Le suffixe -0309 correspond à la date de publication, ici le 9 mars. Cette version ne bouge plus : tant qu’elle est dans l’état actif, le modèle qui répond aujourd’hui est celui qui répondra dans six mois. C’est la seule option défendable en production, pour quatre raisons qui se tiennent. Le comportement de votre application devient reproductible, ce qui rend vos tests d’intégration et de régression durablement valides. Aucune mise à jour silencieuse ne peut vous surprendre. Le moment de la migration devient une décision d’équipe, planifiée, et non un événement subi. Et quand un comportement change malgré tout, vous savez que la cause est chez vous.

Une convention par environnement

La bonne pratique ne consiste pas à choisir entre les trois, mais à les affecter chacune à son environnement :

import os

ENVIRONNEMENT = os.getenv("APP_ENV", "development")

MODELE = {
    "development": "grok-4.20",         # Alias simple : derniere stable
    "staging": "grok-4.20-latest",      # Latest : tester les nouveautes
    "production": "grok-4.20-0309",     # Version figee : stabilite maximale
}[ENVIRONNEMENT]

Lisez ce dictionnaire comme un dispositif de veille automatique. Votre staging tourne en permanence sur latest : si une évolution à venir casse un de vos prompts, vos tests d’intégration l’apprennent avant vos utilisateurs. Votre production reste sur une version figée pendant ce temps. Vous découvrez les changements en amont sans jamais les subir en aval.

Passer d’une version figée à la suivante

Quand une nouvelle version figée paraît — disons grok-4.20-0612 — la bascule mérite une procédure plutôt qu’un simple changement de chaîne de caractères. Vous déployez d’abord la nouvelle version en staging via l’alias latest, vous y exécutez votre suite de tests de prompts, puis vous comparez les résultats obtenus avec ceux de la version actuellement en production. Si la comparaison est satisfaisante, vous mettez à jour la configuration de production, vous monitorez les métriques pendant 48 h — qualité des réponses, taux de satisfaction, coût — et vous validez la migration ou revenez à la version précédente.

L’étape de comparaison est le cœur du dispositif, et elle suppose que vous ayez conservé les sorties de la version en place : sans cette référence, « comparer » se réduit à une impression. La phase d’observation, elle, inclut délibérément le coût. Une version plus récente peut être plus bavarde, générer davantage de tokens de sortie et alourdir votre facture de plusieurs pourcents à qualité perçue égale. Quarante-huit heures suffisent généralement à le voir, et le retour à la version précédente reste alors une simple ligne de configuration.

Points clés à retenir

• Alias simple (grok-4.20) : dernière version stable, pour le développement
• Alias latest (grok-4.20-latest) : version bleeding edge, pour les tests uniquement
• Version figée (grok-4.20-0309) : immuable, la seule option recommandée en production
• Utilisez des conventions différentes par environnement (dev/staging/prod)
• Planifiez un processus de migration structuré lors du passage d’une version figée à une autre