Lifecycle stage — Build
Chaque mois où vous livrez un produit construit sur OpenAI ou Anthropic, vous payez une taxe et vous capitalisez sur l'avantage de quelqu'un d'autre. L'API générique était le bon choix quand votre cas d'usage métier n'était pas prouvé ; c'est le mauvais choix dès que vous avez validé le cas d'usage et commencé à accumuler les données qui devraient être votre moat. Il s'agit de la phase ENGINEER de la Hyperion Lifecycle : une mission de fine-tuning sur mesure de 8 semaines qui produit un modèle domain-expert entraîné sur vos données propriétaires, évalué contre les API de frontière sur votre vraie tâche, et déployé sur une infrastructure que vous possédez. J'ai architecturé Auralink — 1,7 million de lignes de code, ~20 agents autonomes, peer-reviewed sur arXiv — sur des modèles open-weight parce que l'économie et la position de contrôle l'exigeaient. J'ai livré dix ventures IA où des modèles open fine-tunés battent les API de frontière sur la tâche métier. Ceci n'est pas une capacité théorique.
Votre économie unitaire se comprime avec chaque utilisateur. L'appel API générique coûtait 0,004 € par 1K tokens à votre lancement. L'usage a cru, la tarification a bougé, et votre coût blended par utilisateur actif est maintenant 3,2x celui que votre modèle initial supposait. Chaque nouvel utilisateur empire votre marge, ne l'améliore pas — l'inverse de ce qu'un business logiciel est censé faire. Sur votre trajectoire actuelle, la ligne API devient votre plus grande dépense unique dans les quatre trimestres, et vos seuls leviers sont throttler les utilisateurs ou augmenter les prix. Ni l'un ni l'autre n'est une stratégie de croissance.
Vos données métier construisent le moat de quelqu'un d'autre. Chaque requête que vos utilisateurs envoient à une API de frontière passe par l'infrastructure du fournisseur et, selon le palier, peut contribuer à l'entraînement futur. Même quand ce n'est pas le cas, vous ne capitalisez pas sur une capacité propriétaire — vous en louez une. Votre moat compétitif est censé être les données que personne d'autre n'a. Envoyer ces données à OpenAI ou Anthropic ne fortifie pas le moat, il le dilue. Dans les secteurs régulés — juridique, médical, industriel, financier — cela crée aussi des problèmes d'audit et de résidence que vous ne pouvez pas résoudre.
Vous n'avez aucun recours quand le fournisseur change les règles. OpenAI déprécie un modèle avec 90 jours de préavis et la qualité de votre production régresse du jour au lendemain. Anthropic change les rate limits et votre client entreprise heurte le throttling pendant la démo. La tarification bouge de 40 % et votre CFO pose des questions auxquelles vous ne pouvez pas répondre. Quand le fournisseur est le goulot d'étranglement, vous n'avez pas de réponse ingénierie — seulement une réponse procurement. C'est une position inconfortable pour toute entreprise dont le produit dépend de l'API fonctionnant exactement comme elle fonctionnait le trimestre dernier.
Votre équipe a lu les articles de blog et ne peut pas livrer le modèle. Vos ingénieurs ont regardé les tutoriels de fine-tuning, fait tourner du LoRA sur un toy dataset, posté une Hugging Face card et déclaré victoire. Ce qu'ils n'ont pas fait, c'est produire un modèle qui bat l'API sur le trafic de production avec une significativité statistique, tenu au même standard d'évaluation que l'incumbent. La distance entre « j'ai fine-tuné un modèle » et « j'ai livré un modèle qui gagne sur l'éval » est l'endroit où 95 % des équipes échouent. Ce n'est pas un problème de tutoriel ; c'est un problème de jugement.
La mission se déroule en quatre phases de deux semaines. Je travaille en embedded avec votre équipe ML — vos ingénieurs font le travail, j'apporte les décisions et la bibliothèque de patterns. Aucun travail ne se fait sur une infrastructure fournisseur que nous ne contrôlons pas. Vous possédez les données, les poids, le harnais d'évaluation et le déploiement à chaque étape.
Le modèle est aussi bon que les données et aussi mesurable que le harnais d'évaluation. J'audite votre corpus propriétaire pour la couverture, la qualité, la contamination et le licensing. Nous définissons les tâches d'évaluation qui correspondent à votre vraie charge de production — pas les benchmarks génériques. Nous construisons le harnais d'évaluation contre l'API de frontière incumbent d'abord, pour avoir une vraie baseline à battre. À la fin de la semaine deux, nous savons à quoi ressemble la victoire en chiffres.
Sélection du base model à travers les familles Llama 3, Mistral et Qwen selon votre profil de tâche — instruction-following, profondeur de raisonnement, longueur de contexte, coût d'inférence. Nous menons des expériences structurées — LoRA contre full fine-tune, ablations de data mix, ensembles de checkpoints — et nous évaluons chaque run contre la baseline de la semaine deux. La plupart des runs vont perdre. C'est attendu. L'objectif est de trouver la configuration qui gagne fiablement sur votre tâche, pas celle qui gagne sur un leaderboard.
Nous déployons l'inférence sur l'infrastructure sur laquelle vous la ferez tourner réellement — vos propres GPUs, un fournisseur dédié comme Together ou Fireworks, ou un déploiement on-premise pour les charges régulées. Nous optimisons pour l'enveloppe de latence et de coût que votre produit exige : quantization, stratégie de batching, gestion du KV cache, framework de serving. La sortie est un déploiement qui respecte votre SLA de production et un coût par requête qui bat l'API incumbent de la marge que le business case exigeait.
Sessions de travail avec votre équipe ML pour qu'elle soit propriétaire du harnais d'évaluation, du pipeline d'entraînement et du déploiement d'inférence. Je documente les décisions de jugement — pourquoi nous avons choisi ce base model, pourquoi nous avons rejeté ces data mixes, pourquoi nous avons accepté ce compromis de quantization. Quand je pars, votre équipe peut entraîner la prochaine version sans moi. Pas de retainer, pas de dépendance continue. Le modèle, les poids, le code, l'éval — tout à vous.
Entreprises et startups bien financées avec plus d'1 million d'appels API annuels sur les modèles de frontière et des données métier propriétaires dans un vertical défendable — juridique, médical, industriel, financier, scientifique. Équipes produit où le CAIO ou VP Engineering a déjà fait les calculs sur les coûts API à 3x-5x l'usage actuel et sait que le modèle ne survit pas. Secteurs régulés où la résidence des données, l'audit ou les contraintes IP rendent la dépendance aux API de frontière un passif. Ceci n'est pas pour les équipes sans données propriétaires — les fine-tunes génériques ne battent pas les API de frontière et ne devraient pas être tentés. Ce n'est pas non plus pour les équipes en dessous du seuil de volume d'appels où le CapEx ne passe pas le calcul de break-even ; le Readiness Audit est un meilleur point d'entrée.
Parce que nous le mesurons en semaine deux, avant que l'entraînement ne commence. Le harnais d'évaluation est construit contre la baseline API de frontière d'abord, pour que nous sachions exactement ce que la victoire exige. Si la baseline est déjà au plafond que votre tâche autorise, je vous le dirai en semaine deux et nous arrêtons — vous gardez le harnais d'éval et le diagnostic, et nous ne procédons pas à l'entraînement. En pratique, sur des tâches métier étroites avec de vraies données propriétaires, un modèle open bien entraîné gagne en qualité et domine en coût. Sur des tâches généralistes larges, les API de frontière sont encore devant et je le dirai.
Vous réentraînez. Parce que votre équipe est propriétaire du harnais d'éval et du pipeline d'entraînement, re-lancer la recette sur un nouveau base model est un exercice d'1-2 semaines, pas de 8 semaines. Les décisions de jugement documentées dans le journal de décisions se reportent. C'est l'avantage structurel de posséder les poids contre louer l'API — quand la technologie sous-jacente s'améliore, votre équipe capture l'amélioration sur votre calendrier, pas celui du fournisseur.
Généralement non pour l'entraînement, parfois oui pour l'inférence, selon votre profil de coût et votre posture réglementaire. L'entraînement pour 8 semaines tourne typiquement sur des H100 loués à environ 15-40 k€ au total, selon la taille du modèle et le nombre d'expériences. Les décisions d'inférence sont au cas par cas : Together ou Fireworks pour de l'inférence dédiée sans CapEx, vos propres GPUs pour un contrôle maximum et de la marge à fort volume, on-premise pour données régulées. Je construis le modèle de coût à travers les trois options en semaine six pour que la décision soit prise avec des chiffres, pas des hypothèses.
Si votre équipe a déjà livré un modèle fine-tuné qui a battu l'API de frontière sur une éval de production avec significativité statistique, vous n'en avez probablement pas besoin. La plupart des équipes ne l'ont pas fait — elles ont fait le travail de tutoriel mais pas le travail de jugement. J'apporte la reconnaissance de patterns issue de 8 déploiements en production : quel base model pour quel profil de tâche, quels data mixes aident fiablement contre lesquels semblent prometteurs et nuisent, quels paliers de quantization sont sûrs à quelle échelle. Votre équipe fait le travail ; je raccourcis la distance entre sa capacité actuelle et un modèle en production de plusieurs itérations.
L'entraînement se fait sur une infrastructure que vous approuvez, sous un data processing agreement qui correspond à vos exigences de conformité. Pour les charges régulées — médicales, juridiques, financières — nous utilisons des GPUs on-premise ou sovereign-cloud et je signe ce qui est requis. Votre corpus propriétaire ne touche jamais l'infrastructure d'un fournisseur de frontière pendant aucune phase de cette mission, ce qui fait partie du sujet. Le récit de résidence des données est un livrable, pas une pensée après coup.
Decouvrez d'autres services qui completent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.