Changer de modèle.
Garder le résultat attendu.

Ce qui change au-delà du nom

Instructions, formats structurés, appels d’outils, longueur de contexte, coût et délai de réponse peuvent différer. Un connecteur compatible ne garantit pas un comportement équivalent. Documentez le modèle exact, les paramètres et la configuration qui produisent aujourd’hui le résultat de référence.

Comparer sur les mêmes cas

Constituez un ensemble d’entrées autorisées représentant les usages ordinaires et les exceptions connues. Rejouez-les sur les deux configurations. Observez les erreurs de fond, les champs mal formés, les actions proposées et les questions sans réponse. Gardez une partie des cas hors des ajustements pour vérifier que l’amélioration ne concerne pas seulement les exemples travaillés.

Le guide OpenAI de sélection de modèle propose de définir d’abord le niveau de qualité nécessaire, puis d’optimiser coût et latence en le conservant. Cette logique ne donne pas un vainqueur universel : elle dépend de la tâche et de ses contraintes.

Chronométrer la bonne attente

La première information affichée, la réponse complète et le résultat accepté sont trois instants différents. Un débit élevé peut masquer un démarrage lent. Un modèle plus rapide peut aussi demander une correction humaine supplémentaire. Mesurez le parcours qui compte pour votre utilisateur, avec une charge représentative.

Préparer la bascule et le retour

• Versionner les consignes, schémas de sortie et réglages.
• Vérifier les données transmises et les conditions du fournisseur retenu.
• Tester un déploiement limité avant de remplacer tous les usages.
• Conserver une configuration précédente utilisable, si sa disponibilité le permet.
• Définir le signal qui déclenche un retour ou une intervention.

Si l’ancienne version disparaît, un simple bouton de retour n’existe plus. Il faut prévoir une route de continuité réaliste : autre modèle validé, réduction de fonctionnalité ou traitement manuel. L’indépendance se prépare aussi dans ces scénarios.