Construire ou acheter n’est pas une question binaire. Il existe cinq voies : l’API d’un modèle de pointe, un modèle à poids ouverts sur un endpoint managé, un modèle à poids ouverts affiné, un modèle entraîné de zéro, et l’option que la plupart des équipes oublient — ne pas le résoudre avec un LLM du tout. Trois prismes seulement tranchent entre elles : le coût au volume projeté, le plafond de capacité qu’exige la tâche et l’exposition réglementaire. Pour la plupart des organisations, la réponse pratique consiste à commencer par acheter, à construire une couche d’abstraction dès le premier jour et à ne rouvrir la question du build qu’une fois des données d’usage réelles disponibles.
Cinq voies, pas deux
Le cadrage habituel du débat produit de mauvaises décisions parce qu’il masque trois options intermédiaires — précisément là où se trouve l’essentiel de la valeur.
| Voie | Ce que cela signifie en pratique | Quand elle convient |
|---|---|---|
| API de modèle de pointe | Appels à un fournisseur commercial, aucune infrastructure propre | Tâche large, volume modéré, équipe sans expertise ML |
| Modèle à poids ouverts managé | Poids ouverts sur l’endpoint d’un fournisseur d’infrastructure | Besoin de contrôle des versions et de coût prévisible |
| Modèle ouvert affiné | Entraînement complémentaire sur vos données pour une tâche étroite | Tâche étroite et répétitive, bien au-delà de dix mille exemples annotés |
| Modèle entraîné de zéro | Entraînement complet, équipe de recherche dédiée | Presque jamais. Uniquement si le modèle est lui-même le produit |
| Pas de LLM du tout | Règles, recherche, modèle statistique classique | Quand la tâche est déterministe et entièrement spécifiable |
Les trois prismes qui tranchent
Le coût au volume projeté. Pas le volume d’aujourd’hui, mais celui que vous visez dans un an. Le calcul rapide : unités de travail par mois multipliées par le coût unitaire sur la voie « acheter », face au coût fixe d’ingénierie et d’infrastructure de la voie « construire ». Nous exposons la méthode dans notre article sur le coût total de possession d’une fonctionnalité LLM.
Le plafond de capacité. Si la tâche exige un raisonnement en plusieurs étapes, une langue rare ou une connaissance générale du monde, un petit modèle affiné n’y arrivera pas, quel que soit l’entraînement. Si la tâche est une classification en sept catégories, un modèle de pointe est du gaspillage.
L’exposition réglementaire. Lorsque les données doivent rester dans une juridiction ou un réseau fermé, les voies « acheter » se referment aussitôt. C’est le seul prisme capable d’éliminer purement et simplement une voie, raison pour laquelle il doit être vérifié en premier et non en dernier. Le rapport entre types de données et autorisations est détaillé dans notre article sur la classification des données d’entreprise avant qu’elles n’atteignent un LLM.
Quand l’affinage est réellement rentable
L’affinage est la voie que la plupart des équipes choisissent trop tôt. Il devient utile lorsque toutes les conditions suivantes sont réunies ensemble, et non certaines d’entre elles :
- La tâche est étroite, répétitive et bien définie, et elle ne change pas chaque trimestre.
- Vous disposez de plusieurs milliers d’exemples annotés de bonne qualité, issus de votre propre production et non d’un corpus générique.
- Le coût ou la latence de l’API est réellement devenu la contrainte structurante, et non une préoccupation théorique.
- Quelqu’un dans l’équipe maintiendra le modèle, mesurera la dérive et réentraînera lorsque la distribution se déplacera.
Si une seule condition manque, l’affinage ajoute un coût de maintenance permanent sans le restituer. Le schéma qui fonctionne est l’inverse : rester sur une API, collecter systématiquement les données de production et revenir à la question après environ quatre-vingt-dix jours d’usage réel, quand on dispose de chiffres plutôt que d’estimations.
La couche d’abstraction : la seule décision à prendre tout de suite
Vous n’avez pas besoin de choisir une voie dès le premier jour, mais vous devez décider de ne pas vous engager. Une fine couche d’abstraction entre votre code et le fournisseur de modèle est l’assurance la moins chère du projet :
| Ce que contient la couche | Pourquoi c’est important |
|---|---|
| Une interface unique pour les appels au modèle | Changer de fournisseur devient la modification d’un seul fichier, pas une réécriture |
| Un routage par type de tâche | Permet d’envoyer les tâches bon marché vers un modèle bon marché sans toucher à la logique |
| Une journalisation uniforme de l’entrée, de la sortie et du coût | Sans elle, aucune donnée pour décider dans trois mois |
| Une validation des sorties | Permet de changer de modèle sans changer le contrat de sortie |
Les coûts qui ne figurent pas dans le tableur
Une comparaison construire/acheter menée dans un tableur tend à opposer prix de licence et coût de calcul, en manquant trois coûts qui décident réellement de l’issue : le délai de mise sur le marché, le coût d’opportunité d’une équipe qui construit au lieu de vendre, et la maintenance sur plusieurs années. Les publications parues jusqu’en 2026 rapportent que les organisations ayant développé une capacité IA sur mesure sans l’avoir d’abord confrontée à une option prête à l’emploi ont perdu un temps considérable avant de découvrir que la direction était mauvaise.
De l’autre côté, acheter indéfiniment crée une dépendance à un fournisseur unique et prive l’organisation de la capacité d’améliorer ce qui la distingue. L’équilibre pratique est presque toujours hybride : acheter le socle, construire au-dessus la couche où réside l’avantage concurrentiel — les données, la recherche, les règles métier et l’interface — et non le modèle lui-même.
La séquence recommandée
- Définir l’unité de travail et le critère de réussite avant de choisir la moindre technologie.
- Vérifier le prisme réglementaire. S’il élimine des voies, tout le reste devient sans objet.
- Réaliser une preuve de concept sur une option prête à l’emploi même si vous êtes convaincu que vous construirez. C’est peu coûteux et cela crée une référence.
- Construire la couche d’abstraction et la journalisation dès le premier jour.
- Revenir à la décision après quatre-vingt-dix jours avec un coût unitaire réel, un taux de réussite et une distribution des tâches.
Cet accompagnement, de la définition de l’unité de travail jusqu’au choix de la voie, relève précisément de nos domaines d’expertise.
Questions fréquentes
Quelle est la différence pratique entre l’affinage et la recherche dans une base de connaissances ?
La recherche ajoute de l’information à jour dans le prompt au moment de l’exécution ; l’affinage modifie le comportement du modèle lui-même. Pour une connaissance organisationnelle qui évolue, la recherche est presque toujours le bon choix. L’affinage convient aux changements de style, de format ou à une tâche étroite, pas à l’injection de faits.
Combien d’exemples annotés l’affinage exige-t-il réellement ?
L’ordre de grandeur admis est de plusieurs milliers d’exemples de qualité pour une tâche étroite. Le facteur déterminant n’est pas la quantité mais la qualité et la représentativité : mille exemples propres issus de votre propre production valent mieux que des dizaines de milliers d’exemples synthétiques.
Une couche d’abstraction n’ajoute-t-elle pas une complexité inutile ?
Une couche fine qui se contente d’unifier l’appel, la journalisation et la validation coûte quelques jours de développement. Le coût de son absence apparaît le jour où vous devez changer de fournisseur, router les tâches bon marché vers un modèle bon marché, ou expliquer d’où vient une facture.
Quand entraîner un modèle de zéro est-il justifié ?
Presque jamais, sauf si le modèle est lui-même le produit que vous vendez, ou si vous détenez des données propriétaires uniques par leur volume dans un domaine que les modèles généraux ne couvrent pas. Pour la plupart des organisations, le coût dépasse le bénéfice de plusieurs ordres de grandeur.
Comment savoir qu’il est temps de passer de l’achat à la construction ?
Lorsque trois conditions sont réunies ensemble : le coût mensuel de l’achat a dépassé le coût annuel d’ingénierie et de maintenance de l’alternative, la tâche s’est stabilisée et ne change plus, et vous disposez de données de production suffisantes pour entraîner et mesurer. Deux sur trois ne suffisent pas.