Pour choisir un modèle parmi les familles GPT, Claude, Gemini ou Mistral, comparez des versions précises sur votre tâche métier. Un classement général ne permet pas de déduire la qualité d’une extraction documentaire, d’un assistant interne ou d’un agent connecté à vos outils. Les catalogues évoluent : ce guide propose une méthode de décision plutôt qu’un palmarès ou des tarifs supposés permanents.
Définir ce que vous attendez du système
Décrivez l’entrée, le résultat attendu et les erreurs qui rendent ce résultat inutilisable. Une réponse agréable à lire peut être incorrecte. Une sortie valide au format JSON peut contenir une valeur inventée. La recette doit porter sur le résultat et ses conséquences.
Pour un premier test, conservez un corpus représentatif du processus : demandes courantes, exceptions, sources incomplètes et cas qui doivent être transmis à une personne. Consignez la version du modèle, les paramètres disponibles, les instructions et la date du test.
Construire une comparaison utile
| Critère | Question à poser | Élément à conserver |
|---|---|---|
| Qualité métier | Le résultat satisfait-il les critères de recette ? | Cas d’essai et annotation du résultat |
| Fiabilité des preuves | La réponse correspond-elle aux sources autorisées ? | Extrait cité et document d’origine |
| Actions | Le système utilise-t-il seulement les outils permis ? | Journal des appels et validations |
| Latence | Le parcours reste-t-il utilisable dans les conditions prévues ? | Distribution des durées, pas seulement une moyenne |
| Coût complet | Quel est le coût d’une tâche acceptée ? | Appels, reprises, infrastructure et relecture |
| Données | Le traitement respecte-t-il le périmètre convenu ? | Contrat, architecture et règles d’accès |
Appliquez les mêmes critères à chaque candidat. L’objectif n’est pas d’obtenir une note flatteuse, mais de comprendre les cas dans lesquels le modèle échoue et le coût des protections nécessaires.
Séparer le modèle de l’architecture
Un système documentaire comprend aussi la collecte des sources, la recherche, les droits d’accès et l’affichage des références. Une comparaison qui change simultanément ces éléments ne permet pas d’attribuer le résultat au seul modèle.
Pour les agents, distinguez les étapes définies à l’avance des décisions laissées au modèle. Anthropic présente cette distinction entre workflows et agents dans son guide de construction de systèmes agentiques. Notre recommandation de cadrage est de choisir l’autonomie minimale qui résout le besoin et de tester les conditions d’arrêt.
Traiter le prix comme une hypothèse datée
Vérifiez les tarifs directement chez le fournisseur pour la version et le mode d’accès retenus. Notez les conditions de cache, de traitement différé et les limites éventuelles. Le budget d’un service doit aussi intégrer les reprises, l’observabilité et le temps humain.
Un modèle moins coûteux par appel n’est pas nécessairement moins coûteux par tâche réussie. Mesurez ce rapport sur votre corpus. Si le volume prévu varie fortement, présentez plusieurs hypothèses pour que le choix reste compréhensible.
Préparer le changement de version
Le jeu de recette doit pouvoir être rejoué avant une mise à jour. Conservez les résultats des versions précédentes et décidez quels écarts sont acceptables. Une amélioration générale peut s’accompagner d’une régression sur une tâche particulière.
La disponibilité d’un modèle dépend aussi de son contrat et de son mode de déploiement. Vérifiez les conditions de retrait et de remplacement. Pour les modèles téléchargeables, examinez la licence, la fiche et les ressources nécessaires ; les model cards aident à repérer les informations à collecter.
Décider avec votre équipe
Faites relire les résultats par les utilisateurs du processus. La décision doit préciser les tâches autorisées, la supervision et la personne chargée de suivre la qualité en production. Le comparatif entre modèles ouverts et services propriétaires complète le choix d’hébergement. Nous pouvons cadrer une architecture de LLM privé à partir de ces contraintes.
À RETENIR
- Comparer des versions identifiées, à une date donnée.
- Utiliser les mêmes cas et critères pour tous les candidats.
- Mesurer le coût d’une tâche acceptée et ses échecs.
- Rejouer l’évaluation avant tout changement de version.
LE CONSEIL À APPLIQUER Demandez que chaque démonstration fournisse les entrées testées, les sorties et les critères d’évaluation. Votre équipe pourra ainsi reproduire les résultats et juger leur pertinence pour le projet.