Non, pas à lui seul — et la question vise le mauvais endroit. Qu’un éditeur entraîne son propre modèle est un fait sur sa structure de coûts, sa latence et ses options de déploiement, pas un indicateur de la qualité du résultat pour votre travail. Un « modèle d’AI vertical » signifie que l’éditeur a modifié les poids avec des données du domaine. Un « wrapper GPT » signifie qu’il ne l’a pas fait et qu’il a construit à la place des prompts, du retrieval, de l’outillage et un produit autour de l’API d’un tiers. Les deux descriptions recouvrent des produits qui fonctionnent et des produits qui ne fonctionnent pas.
Ce n’est pas un niveau de qualité, et ce n’est pas non plus un avantage défendable en soi. Des poids propriétaires ne certifient aucune exactitude, et un appel d’API ne la condamne pas. La question d’achat est plus étroite : que possède cet éditeur qu’un concurrent disposant de la même API key ne peut pas reconstruire en un trimestre — et cette réponse survit-elle à la prochaine sortie d’un modèle frontier ?
Quatre choses différentes derrière « notre propre modèle »
L’expression recouvre une échelle dont les barreaux sont séparés par un facteur d’environ 1000 en coût et en défendabilité.
- Ingénierie de prompt et de contexte. System prompts, définitions d’outils, schémas de sortie, stratégie de chunking. C’est un wrapper, et l’appeler modèle relève du marketing. C’est aussi de là que vient l’essentiel de l’écart de qualité observable entre deux produits bâtis sur le même modèle de base.
- Retrieval et embeddings maison. L’éditeur entraîne la couche de recherche, pas le générateur. Harvey a travaillé avec Voyage AI sur
voyage-law-2-harvey, un modèle d’embeddings affiné sur plus de 20 milliards de tokens de textes juridiques américains, avec une réduction annoncée de 25% des résultats de recherche non pertinents par rapport à des embeddings standard. - Post-entraînement sur des données de tâche propriétaires. Fine-tuning supervisé ou par renforcement au-dessus d’un modèle de base. C’est ce qu’est réellement, en 2026, presque tout « modèle conçu sur mesure » dans les logiciels d’ops.
- Pré-entraînement depuis zéro. Un nouveau modèle de base. Presque personne ne le fait dans les logiciels d’ops, et la seule tentative célèbre en explique la raison.
La leçon BloombergGPT
Bloomberg a pré-entraîné un modèle financier de 50 milliards de paramètres sur son propre corpus et l’a publié en mars 2023. Il a battu des modèles ouverts de taille comparable — GPT-NeoX, OPT, BLOOM — sur des tâches de NLP financier. Puis GPT-4, sans aucun accès aux données Bloomberg, l’a battu : des évaluations indépendantes publiées après la sortie de GPT-4 ont relevé 68,79% contre 43% sur FinQA en zero-shot, 76% contre 43% sur ConvFinQA, et un F1 de 83% contre 61% sur la reconnaissance d’entités nommées FIN3.
La lecture généralisable n’est pas « les modèles de domaine perdent ». C’est qu’un modèle de taille moyenne pré-entraîné sur des données de domaine gagne dans sa propre catégorie de poids et perd face à la sortie frontier suivante, et les sorties frontier arrivent plus vite qu’une campagne de pré-entraînement ne se rentabilise. Tout éditeur qui vous vend la taille de son corpus propriétaire décrit une position remise en jeu tous les quelques mois.
Harvey a gravi toute l’échelle en trois ans
Harvey est le cas le plus net parce que l’entreprise a occupé toutes les positions de ce débat :
- 2023 — modèle de jurisprudence affiné avec OpenAI après avoir jugé insuffisants le fine-tuning via API publique et le RAG simple. En tests aveugles, les avocats ont préféré le modèle affiné à GPT-4 dans 97% des cas.
- Mai 2025 — ajout des modèles Anthropic et Google, fin de la dépendance exclusive à OpenAI. Les raisons avancées par Harvey méritent d’être lues côté acheteur : routage par tâche parce qu’aucun modèle ne domine partout, redondance pour qu’une panne ou une limite de capacité d’un fournisseur soit reroutée plutôt que bloquante, et choix du modèle au niveau administrateur par workspace.
- 18 juin 2026 — annonce de sa propre série de modèles juridiques : des modèles open-source post-entraînés, construits avec Baseten, Fireworks AI, Applied Compute, Trajectory Labs et Nvidia, avec une performance annoncée proche des modèles frontier. Le cofondateur Gabe Pereyra a formulé l’objectif comme une capacité de niveau frontier sur toute la surface produit, à un prix abordable et avec une posture de sécurité solide.
Lisez ce dernier point attentivement. Le moteur déclaré est le prix et la posture de déploiement, pas un écart de capacité que le modèle généraliste n’aurait pas pu combler. C’est la version honnête de l’argument du modèle vertical, et c’est un argument différent de celui que la plupart des éditeurs présentent aux acheteurs.
Les chiffres qui tranchent
Résultats du Legal Agent Benchmark de Harvey publiés avec Fireworks, sur un échantillon de 100 tâches selon un standard strict de réussite intégrale, où chaque critère doit être satisfait :
| Configuration | Réussite intégrale | Coût |
|---|---|---|
| Claude Opus 4.7 (référence frontier fermée) | 14/100 | $954 |
| GLM 5.1 (modèle ouvert, seul) | 12/100 | $121 |
| Kimi K2.6 avec fine-tuning supervisé | 15/100 | $84 |
| GLM 5.1 en worker + Opus 4.7 en advisor | 18/100 | $368 |
Sur la métrique plus souple du score moyen, les quatre configurations convergent presque — GLM 5.1 à 0,8921, GPT-5.5 à 0,892, Opus 4.7 à 0,911. Trois choses ressortent de ce tableau. Le post-entraînement de domaine a acheté une réduction de coût d’environ 8x à parité quasi complète de score moyen. L’hybride a battu le modèle frontier sur la réussite intégrale à environ 39% de son coût. Et aucune configuration ne termine plus de 20 tâches sur 100 de bout en bout, ce qui indique que la catégorie est loin d’être résolue et que le marketing fondé sur le score moyen le masque.
Ce qu’un éditeur possède et que vous ne pouvez pas copier
Classez ces éléments au-dessus des poids dans votre évaluation :
- Les droits sur les données. La position de Gong repose sur des dizaines de milliards d’interactions commerciales capturées sur lesquelles l’entreprise détient des droits contractuels, et elle revendique une exactitude 3 fois supérieure à celle des systèmes standard sur ses trackers entraînés. Eightfold repose sur 1,6 milliard de profils de carrière et 1,6 million de compétences inférées. Ni l’un ni l’autre n’est reproductible avec une API key.
- L’infrastructure d’évaluation. Harvey a construit et publié BigLaw Bench et le Legal Agent Benchmark avec Snorkel AI. Un éditeur incapable de vous dire comment il sait qu’un changement de modèle a aidé vend une impression.
- Le workflow, les permissions et la surface d’audit. Ce dans quoi vos administrateurs travaillent, et qu’aucune sortie de modèle n’invalide.
Questions de diagnostic à poser à l’éditeur
- Quel modèle exécute cette fonctionnalité aujourd’hui, et lequel l’exécutait il y a six mois ? Pas de réponse signifie que la dérive de versions n’est pas maîtrisée et que votre référence d’exactitude n’est pas reproductible.
- Montrez une tâche où votre modèle bat le modèle frontier auquel vous avez accès — puis laissez-nous la rejouer sur nos documents. Un benchmark d’éditeur sur des données d’éditeur est un point de départ, pas une preuve.
- Nos données sont-elles dans votre jeu d’entraînement, et quelle est l’option de rétention zéro ? « Jeu de données propriétaire » désigne parfois vos propres inputs.
- Que se passe-t-il quand votre fournisseur retire un modèle ? La justification multi-modèle de Harvey nomme directement les pannes et les limites de capacité ; les éditeurs mono-fournisseur portent ce risque à votre place.
- Quel est le coût par tâche terminée à notre volume ? Le tableau ci-dessus en est la raison — le même résultat présente un écart de prix de 11x selon l’architecture.
- Réussite intégrale ou score moyen ? Exigez le chiffre au niveau du critère. Le score moyen est l’endroit où se cache le crédit partiel.
Points de vigilance, chacun avec sa parade
Un « modèle conçu sur mesure » qui est un system prompt. L’affirmation ne coûte rien. Parade : demandez par écrit quel barreau de l’échelle ci-dessus s’applique — prompt, embeddings, post-entraînement ou pré-entraînement — et faites entrer la réponse dans la description produit du contrat.
Un fine-tune figé sur une base mouvante. Un modèle post-entraîné sur une base de 2024 se dégrade en valeur relative à chaque sortie frontier. Parade : demandez la cadence de réentraînement et la date du checkpoint actuel, et faites-en une question de renouvellement.
Des revendications de modèle propriétaire utilisées comme verrouillage. Si les sorties n’existent qu’à l’intérieur de leur modèle, le coût de migration est le produit. Parade : exigez l’export en masse des sorties et des preuves sources dans un format que vous pouvez réingérer.
Acheter le récit du corpus plutôt que le corpus. Les éditeurs citent la taille du jeu de données sans dire s’ils détiennent les droits d’entraînement dessus. Parade : demandez le fondement des droits sur les données, pas le nombre de lignes.
Confondre grounding et entraînement. La plupart des problèmes d’exactitude en juridique et en GTM sont des échecs de retrieval, pas des problèmes de poids. Parade : travaillez ancrage vs hallucination en AI juridique et RAG avant d’accepter « nous avons entraîné notre propre modèle » comme réponse sur l’exactitude.
Quand cela compte vraiment
Cela compte quand vous avez une contrainte de déploiement que l’API ne satisfait pas : résidence des données dans une juridiction que le fournisseur ne dessert pas, une installation isolée ou souveraine, un plancher de latence pour une surface temps réel, ou un volume assez élevé pour qu’un facteur 8 sur le coût unitaire devienne une ligne budgétaire. Dans ces cas, un éditeur qui contrôle ses propres poids dispose d’options qu’un wrapper n’a pas, et vous devez les demander explicitement.
Cela ne compte pas pour une équipe de 40 personnes qui choisit un outil de revue de contrats ou de conversation intelligence. Faites tourner l’outil sur vos 20 derniers documents ou appels, notez le résultat par rapport à ce que votre équipe aurait produit, et achetez sur cette base. Les poids sont le problème d’ingénierie de l’éditeur. Pour le schéma plus large qui distingue un agent d’un lot de fonctionnalités, voyez ce qui fait d’une AI un agent pour les ops.