Sommaire
Le bon modèle d’IA est celui qui réussit vos tâches réelles au coût et au niveau de confidentialité acceptables, pas celui qui domine un classement. Testez deux ou trois modèles sur 30 à 100 exemples tirés de votre activité, vérifiez contrat et région de traitement et prévoyez une architecture qui permet d’en changer.
Les classements de modèles d’IA changent tous les trimestres. Si je vous recommandais aujourd’hui un modèle précis, cette page serait fausse dans six mois. Je préfère vous donner les critères que j’utilise pour choisir, la méthode de test et l’architecture qui permet de changer de modèle sans refaire l’application. Les mentions de produits ci-dessous sont datées : vérifiez-les au moment de votre projet.
Les huit critères qui comptent vraiment
| Critère | La question à poser | Comment le vérifier |
|---|---|---|
| Qualité sur vos tâches | Le modèle réussit-il vos cas réels ? | Jeu de test de 30 à 100 exemples de votre activité |
| Coût par tâche | Combien coûte un document traité, une réponse produite ? | Grille tarifaire du fournisseur × volume mesuré pendant le test |
| Rapidité | La réponse arrive-t-elle assez vite pour l’usage ? | Temps de réponse mesuré dans des conditions réelles |
| Confidentialité | Les données envoyées servent-elles à entraîner le modèle ? | Contrat, conditions d’utilisation de l’API, contrat de sous-traitance |
| Région de traitement | Où les données sont-elles traitées et stockées ? | Options de région du fournisseur, liste des sous-traitants |
| Taille du contexte | Le modèle peut-il lire un document long en une fois ? | Documentation technique, test sur vos plus gros documents |
| Stabilité | Combien de temps cette version sera-t-elle disponible ? | Politique de dépréciation publiée par le fournisseur |
| Réversibilité | Peut-on changer de fournisseur sans tout réécrire ? | Architecture de l’application (voir plus bas) |
Le premier critère pèse plus que tous les autres. Un modèle brillant sur les tests publics peut se tromper sur votre vocabulaire métier, vos formats de bons de commande ou vos abréviations internes.
Tester sur vos propres données
C’est l’étape que l’on saute le plus souvent et celle qui évite le plus d’erreurs. La méthode que j’applique :
- Constituer un jeu de test : 30 à 100 exemples réels, représentatifs, y compris les cas difficiles (documents mal scannés, demandes ambiguës). Les données sont pseudonymisées si elles contiennent des informations personnelles.
- Définir la bonne réponse pour chaque exemple, avec la personne qui fait la tâche aujourd’hui.
- Faire passer deux ou trois modèles sur le même jeu, avec la même consigne.
- Noter : taux de réponses correctes, erreurs graves, temps de réponse, coût total du test.
- Garder ce jeu de test. Il servira à revalider en quelques heures chaque nouvelle version de modèle.
Un écart de quelques points de qualité peut justifier un coût plus élevé si l’erreur coûte cher. À l’inverse, un modèle deux fois moins cher et à peine moins précis est souvent le bon choix pour du tri à fort volume.
Confidentialité, contrat et région : vérifier noir sur blanc
Avant de retenir un modèle, je lis trois documents : les conditions d’utilisation de l’API, le contrat de sous-traitance (DPA) et la liste des sous-traitants ultérieurs. Les points à vérifier :
- la réutilisation pour l’entraînement : à titre d’exemple, OpenAI indique que les données envoyées via son API et ses offres professionnelles ne servent pas à entraîner ses modèles, sauf accord explicite du client (page consultée le 27 octobre 2026) ;
- la région : le même fournisseur propose, depuis février 2025, un traitement des requêtes API en Europe pour les clients éligibles, à activer à la création d’un projet (même source, même date de relevé) ;
- la durée de conservation des requêtes et des réponses chez le fournisseur ;
- le droit applicable au fournisseur, qui compte autant que la localisation des serveurs.
Ces conditions évoluent. Revérifiez-les à chaque renouvellement. Le tri des données que l’on peut envoyer est détaillé dans quelles données confier à une IA.
Modèle propriétaire via API ou modèle ouvert hébergé
| Modèle propriétaire via API | Modèle ouvert hébergé par vous ou un hébergeur | |
|---|---|---|
| Mise en route | Rapide | Plus longue (serveur, déploiement) |
| Coût | À l’usage, prévisible si le volume l’est | Coût fixe de serveur, rentable à fort volume |
| Données | Envoyées au fournisseur, selon son contrat | Restent dans l’infrastructure choisie |
| Maintenance | Assurée par le fournisseur | À votre charge ou celle du prestataire |
| Qualité | Souvent la plus élevée sur les tâches complexes | Suffisante pour beaucoup de tâches ciblées |
Pour une première version, je pars le plus souvent d’un modèle propriétaire via API, avec réutilisation désactivée et région adaptée. Ma stack habituelle s’appuie sur OpenAI, mais le choix se fait projet par projet, sur la base des tests. Un modèle ouvert hébergé se justifie quand les données sont très sensibles ou que le volume rend l’usage à la requête trop coûteux.
Une architecture qui permet de changer de modèle
Le modèle d’aujourd’hui ne sera pas celui de dans deux ans. L’application doit donc :
- isoler les appels à l’IA dans une couche dédiée, pour que le reste du code ne dépende pas d’un fournisseur ;
- stocker les consignes (prompts) comme des réglages versionnés, pas éparpillées dans le code ;
- journaliser les entrées, les sorties et les coûts, pour comparer deux modèles sur des données réelles ;
- prévoir un repli : si un fournisseur est indisponible, la tâche passe en traitement manuel ou vers un second modèle.
Quand il ne faut pas choisir de modèle du tout
Si votre besoin est couvert par un logiciel du marché qui intègre déjà l’IA (votre CRM, votre outil de support, votre suite bureautique), commencez par là. Choisir un modèle n’a de sens que si vous construisez une fonction sur-mesure : traitement de vos documents, automatisation d’un processus propre à votre entreprise, assistant branché sur vos données. Et si une règle simple suffit, pas besoin d’IA.
Par où commencer
Le choix du modèle fait partie du cadrage de toute intégration d’IA : je constitue le jeu de test avec vos équipes, je compare les modèles et je vous remets les résultats chiffrés avant le développement. Le budget d’ensemble est détaillé dans combien coûte l’intégration de l’IA et l’estimateur donne une fourchette pour un outil métier avec IA intégrée.
Questions fréquentes
Faut-il choisir le modèle le plus puissant du marché ?
Rarement. Pour classer des e-mails, extraire des champs d’une facture ou résumer une demande, un modèle plus petit donne souvent un résultat équivalent, plus vite et pour beaucoup moins cher. Le modèle le plus puissant se réserve aux tâches où vos tests montrent un vrai écart de qualité.
Un modèle open source est-il plus sûr pour nos données ?
Il peut l’être si vous l’hébergez vous-même ou chez un hébergeur de confiance, car les données ne quittent pas votre infrastructure. En contrepartie, vous prenez en charge l’hébergement, les mises à jour et la sécurité du serveur. Un modèle propriétaire via API, avec un bon contrat et une région européenne, est souvent plus simple pour une première version.
Combien de temps un modèle reste-t-il pertinent ?
Les fournisseurs publient de nouvelles versions plusieurs fois par an et retirent les anciennes. Comptez sur un changement de version au moins une fois par an, d’où l’intérêt de garder votre jeu de test pour revalider rapidement.
Peut-on utiliser plusieurs modèles dans la même application ?
Oui et c’est souvent judicieux : un modèle économique pour le tri et l’extraction, un modèle plus capable pour la rédaction ou l’analyse complexe. L’application choisit le modèle selon la tâche.