Quel modèle choisir

Trois façons d’intégrer un modèle

Le modèle, c’est le moteur sous une fonction d’IA : l’assistant qui répond à partir de vos documents, l’agent qui ouvre un billet, le classificateur qui trie les courriels entrants. Le logiciel autour (connexion, écrans, index de recherche, outils que l’agent peut utiliser, tests) est à peu près le même quel que soit le modèle. Ce qui change, c’est la façon de payer le modèle, qui l’exploite et ce que vous pouvez y modifier.

La plupart des projets devraient commencer par la première voie et n’en changer que s’il y a une raison. Ces raisons existent bel et bien, et mieux vaut les connaître avant de construire.

Les modèles de pointe par API

Un modèle de pointe est le modèle généraliste le plus performant qu’un fournisseur vend. Vous envoyez du texte (et souvent des images ou des fichiers) à une API et vous payez au jeton. Il n’y a aucun serveur à exploiter, le fournisseur améliore le modèle au fil du temps et vous pouvez avoir un prototype fonctionnel en quelques jours.

La première question de la plupart des clients porte sur leurs données. La réponse dépend du fournisseur et du forfait : lisez les conditions du produit exact que vous utilisez. OpenAI indique que les données envoyées à son API ne servent pas à entraîner ses modèles, sauf si vous y consentez, et que les journaux de surveillance des abus sont conservés jusqu’à 30 jours ^[1]. Anthropic indique que, par défaut, elle n’utilise pas les entrées ni les sorties de ses produits commerciaux, dont son API, pour entraîner ses modèles ^[2]. Les conditions de l’API Gemini de Google distinguent les forfaits : le contenu envoyé aux services gratuits peut servir à améliorer les produits de Google, alors que les requêtes et réponses des services payants ne le sont pas ^[3].

Les modèles de pointe lisent aussi beaucoup à la fois. Google indique une limite d’entrée de 1 048 576 jetons pour Gemini 2.5 Pro ^[4], assez pour plusieurs longs documents dans une seule requête. Une grande fenêtre de contexte est utile, mais elle ne remplace pas la recherche : tout envoyer chaque fois est lent, et vous payez chaque jeton.

• Le bon choix quand : vous voulez le meilleur raisonnement offert, votre trafic est modeste ou irrégulier, et les conditions du fournisseur conviennent à vos données.
• Attention à : une facture de jetons qui grandit avec l’usage, des modèles retirés selon le calendrier du fournisseur et des limites de débit aux heures de pointe.
• Prévoyez : un jeu d’évaluation que vous pouvez relancer quand le fournisseur publie une nouvelle version, pour qu’une mise à niveau soit un résultat de test plutôt qu’un acte de foi.

L’open source, exploité par vous

Les modèles à poids ouverts sont publiés pour que n’importe qui puisse les télécharger et les exploiter. Vous les servez sur des GPU loués chez un fournisseur infonuagique, ou sur un serveur GPU que vous achetez. Les données ne quittent jamais des serveurs que vous contrôlez, le modèle ne change jamais à moins que vous le changiez, et le coût mensuel, ce sont les serveurs plutôt que les jetons.

Ouvert ne veut pas dire sans condition. Lisez la licence du modèle et de la version exacts. La licence de Llama 3.1 de Meta, par exemple, exige une licence distincte de Meta pour un titulaire dont les produits comptaient plus de 700 millions d’utilisateurs actifs par mois à la date de publication, et demande d’afficher « Built with Llama » ^[5]. D’autres modèles à poids ouverts sont publiés sous la licence Apache 2.0, qui accorde une licence libre de redevances pour utiliser, modifier et distribuer l’œuvre ^[6]. Vos conseillers devraient lire la licence applicable avant la mise en production.

• Le bon choix quand : vos données doivent rester à un endroit que vous choisissez, votre trafic est assez régulier pour occuper un GPU, ou vous avez besoin d’un modèle qui ne changera pas sous vos pieds.
• Attention à : la facture de GPU ne baisse pas quand personne n’utilise le produit, et les meilleurs modèles ouverts demandent de gros GPU.
• Prévoyez : quelqu’un pour mettre à jour, surveiller et sécuriser l’infrastructure de service. C’est un serveur comme un autre, avec un modèle dessus.

Un modèle sur mesure

Un modèle sur mesure est un modèle modifié ou créé pour votre usage. Il y a trois niveaux, et l’écart d’effort entre eux est grand.

1. 01

   L’affinage

   Un modèle ouvert existant est entraîné davantage sur des exemples de la tâche : vos réponses au service client, votre format de rapport, vos étiquettes de classement. Il apprend un style et un savoir-faire, pas une bibliothèque de faits. C’est le niveau dont la plupart des projets sur mesure ont besoin.

2. 02

   Le préentraînement continu

   Un modèle existant lit un grand corpus de textes de votre domaine avant l’affinage, pour apprendre le vocabulaire et le contexte d’un champ spécialisé. Il faut beaucoup plus de textes et de temps GPU.

3. 03

   L’entraînement de zéro

   Un nouveau modèle, construit à partir de vos données et de données publiques. C’est de loin la voie la plus coûteuse et rarement la bonne pour une entreprise. Elle a du sens quand le modèle est lui-même le produit.

Quel que soit le niveau, ce qui décide de la qualité, ce sont les données et l’évaluation, pas l’entraînement. Un modèle sur mesure ne vaut que les exemples dont il a appris, et vous ne savez ce qu’il vaut que si vous le testez sur des questions qu’il n’a jamais vues. Le temps GPU d’entraînement est facturé d’avance, au coût, en dehors des étapes, parce qu’il est payé avant le travail qui l’utilise.

Le même assistant, de trois façons

Les trois exemples ci-dessous sont le même produit : une application web où le personnel interroge les documents de l’entreprise, et un agent qui peut chercher des renseignements et ouvrir un billet. Seule la voie du modèle change. Chacun montre la fourchette selon notre grille tarifaire d’aujourd’hui, le développement et le coût mensuel d’exploitation, chiffrés à l’ouverture de la page.

Comparez les coûts d’exploitation autant que les coûts de développement. Le coût d’un modèle de pointe suit l’usage : un mois tranquille coûte peu, un mois chargé, non. Un modèle servi coûte à peu près la même chose chaque mois. Si le coût mensuel de l’exemple de pointe, à votre trafic prévu, dépasse nettement le coût du service, c’est là que la voie open source commence à être rentable. Changez le trafic dans l’estimateur pour trouver ce point.

Ce qui reste pareil, quelle que soit la voie

Quel que soit le modèle choisi, l’essentiel du projet, c’est le logiciel autour, et cette partie ne change pas. Les documents doivent toujours être découpés, indexés et tenus à jour. Les outils de l’agent ont toujours besoin de permissions, pour qu’il puisse consulter une commande, mais pas la rembourser sans une personne. Les réponses doivent toujours montrer leurs sources, pour que le personnel puisse les vérifier. Et le tout a toujours besoin d’une évaluation avant chaque changement, de journaux qui montrent ce qu’on a demandé au modèle et ce qu’il a fait, et d’un moyen de l’arrêter.

C’est une bonne nouvelle pour la décision. Puisque le travail autour est commun, la voie est un choix plus petit qu’il n’y paraît, et vous pouvez la changer plus tard si l’application parle au modèle par sa propre mince couche. Choisissez la voie qui convient à vos données et à votre trafic aujourd’hui, et gardez la possibilité de bouger.

Comment décider

1. 01

   Commencez par les données

   Où peuvent-elles aller? Si vos conseillers ou les contrats de vos clients disent qu’elles ne doivent pas quitter vos serveurs ou votre pays, la voie open source ou sur mesure s’impose. Si les conditions d’une API payante sont acceptables, continuez.

2. 02

   Bâtissez l’évaluation en premier

   Écrivez de cinquante à quelques centaines de vraies questions avec de bonnes réponses. Chaque voie est mesurée sur le même jeu, et vous choisissez sur des preuves.

3. 03

   Faites un prototype sur un modèle de pointe

   C’est le moyen le plus rapide de savoir si la fonction est utile. Beaucoup de projets s’arrêtent là, avec raison.

4. 04

   Chiffrez l’exploitation au trafic réel

   Estimez un mois d’usage réel. Comparez les jetons à un serveur GPU. Le point de bascule dépend de votre volume, pas d’une règle empirique.

5. 05

   Essayez un modèle ouvert sur la même évaluation

   S’il obtient un score assez proche, vous gagnez le contrôle et une facture stable. Sinon, vous savez ce que vaut pour vous le modèle de pointe.

6. 06

   Envisagez le sur mesure en dernier

   N’affinez que si le modèle ouvert est proche sans y être, et que vous avez les exemples pour l’enseigner. N’entraînez de zéro que si le modèle est le produit.

Les erreurs que nous voyons

• Choisir un modèle avant d’écrire l’évaluation. Sans jeu de test, chaque modèle paraît bon en démonstration.
• Affiner pour enseigner des faits. Les faits changent; un modèle affiné doit être réentraîné pour les apprendre. La recherche augmentée se met à jour dès que le document change.
• Ignorer le coût d’exploitation. Un projet peu coûteux à construire peut coûter cher à exploiter, et l’inverse.
• S’appuyer si profondément sur les fonctions propres à un fournisseur que changer devient une réécriture. Une mince couche entre votre application et le modèle garde la voie comme une décision que vous pouvez revoir.
• Traiter une licence à poids ouverts comme si tout était permis. Chacune a ses propres conditions.

Nous construisons sur les trois voies et chiffrons chacune séparément : nous n’avons donc aucune raison d’en pousser une. Quand un modèle de pointe par son API est la bonne réponse la moins chère, ce qui arrive souvent, c’est ce que nous recommandons.