OpenAI ferme le fine-tuning : ma migration testée en 6 heures

Le mail est arrivé un jeudi de mai, entre deux alertes Datadog, et personne dans l'équipe ne l'a lu jusqu'au bout. Six semaines plus tard, un client me demande d'ajouter deux catégories à son classifieur de tickets — un gpt-4.1-mini fine-tuné qui tourne en production depuis dix-huit mois — et le job d'entraînement part en erreur. Pas une erreur de quota : une erreur de politique. OpenAI est en train de fermer sa plateforme de fine-tuning, par paliers, et le dernier claque le 6 janvier 2027. Cet article raconte la migration que j'ai faite derrière : ce que j'ai exporté, où je suis allé, ce que ça a coûté, et le run que j'ai raté en beauté.

Le sujet dépasse largement OpenAI. En six mois, trois des quatre grands fournisseurs d'API ont soit fermé, soit déprécié, soit jamais ouvert leur offre de personnalisation grand public. Si vous avez un modèle maison en prod — tri de mails, extraction de champs sur factures, qualification de leads, catégorisation de tickets — vous avez un compte à rebours et un choix à faire.

Ce qu'OpenAI a débranché, et le calendrier qui reste

La page de dépréciations d'OpenAI est explicite, et elle n'a pas fait la une. Trois dates, trois portes qui se ferment l'une après l'autre.

Traduction pour un dirigeant : à la date de publication de cet article, il reste 141 jours pour lancer un dernier entraînement chez OpenAI. Et la clause d'inférence n'est pas le filet de sécurité qu'elle a l'air d'être : un modèle fine-tuné est adossé à un modèle de base, et les modèles de base partent à la retraite à un rythme soutenu — les GPT-4o d'origine ont perdu le droit à de nouveaux entraînements dès le 31 mars 2026 côté Azure, avec un an de grâce sur les déploiements existants, d'après le calendrier de retraits publié par Microsoft. Votre classifieur ne s'arrêtera pas demain. Il s'arrêtera un jour que vous n'aurez pas choisi.

La documentation du reinforcement fine-tuning affiche désormais le même bandeau : « OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users. » Sur le forum développeurs, les réactions tiennent en une question qui revient en boucle :

« So if I have fine tuned models on gpt4.1 mini and openai deprecates it does this mean my model will never be used for inference? »

Étape 0 — vérifier que votre fine-tune sert encore à quelque chose

Avant de migrer, une question désagréable : est-ce que ce modèle mérite d'être sauvé ? Beaucoup de fine-tunes de 2024 ont été faits parce que les modèles de l'époque n'arrivaient pas à tenir un format JSON stable ou à respecter une taxonomie de vingt catégories. Ces deux problèmes ont largement disparu. Sur trois modèles maison que j'ai audités ce printemps, deux ont été remplacés par un prompt bien écrit avec sortie structurée et cache de prompt — coût de migration : zéro, gain de qualité : nul mais neutre.

Le test tient en une demi-journée. Vous prenez 200 exemples réels, vous les passez dans un petit modèle générique avec un prompt d'instruction propre, six à dix exemples few-shot, et un schéma de sortie contraint. Vous comparez à votre modèle fine-tuné. Si l'écart est inférieur à deux points sur votre métrique métier, arrêtez tout : vous venez d'économiser une migration. Le cache d'entrée fait le reste sur la facture — Mistral annonce 90 % d'économie sur les tokens d'entrée mis en cache, et les mesures indépendantes compilées par Galileo sur le caching en 2026 convergent vers 41 à 80 % de baisse de coût selon les fournisseurs. Nous avions détaillé ces leviers dans notre guide sur la facture de tokens qui explose.

Fine-tuning ou RAG : lequel choisir pour une PME

La règle que j'applique depuis deux ans n'a pas bougé : le RAG répond à « le modèle ne connaît pas mes données », le fine-tuning répond à « le modèle ne sait pas faire ma tâche ». Un assistant qui doit citer votre catalogue produit ou votre convention collective, c'est du RAG bien branché sur vos données internes. Un classifieur qui doit trancher entre onze catégories métier avec les conventions internes de votre SAV, qui tourne 25 000 fois par mois et doit répondre en moins d'une seconde, c'est du fine-tuning. Les deux ne s'opposent pas : notre modèle migré tourne à côté d'un index vectoriel, l'un fait le tri, l'autre va chercher le contexte.

Le troisième cas, celui qui justifie vraiment l'effort en 2026, c'est la compression. Vous avez un prompt de 6 000 tokens rempli d'exemples et de règles, appelé 800 fois par jour sur un modèle frontière. Un modèle de 8 milliards de paramètres entraîné sur les mêmes règles fait le même travail avec un prompt de 200 tokens. C'est notre cas, et c'est là que les chiffres deviennent violents.

Étape 1 — exfiltrer le dataset avant de perdre l'accès

Votre actif, ce n'est pas le modèle : c'est le JSONL qui l'a produit. Les poids ne sortiront jamais de chez OpenAI, le dataset si. Première commande, la liste des jobs :

curl https://api.openai.com/v1/fine_tuning/jobs?limit=50 \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Chaque job renvoie un training_file et un validation_file. On récupère le contenu fichier par fichier :

curl https://api.openai.com/v1/files/file-abc123/content \
  -H "Authorization: Bearer $OPENAI_API_KEY" -o train_2024.jsonl

C'est ici que j'ai pris ma première claque. Sur les cinq jobs du client, deux fichiers n'existaient plus : un ménage de comptes fait en 2025 par un prestataire parti depuis avait supprimé les fichiers sources. Il a fallu reconstruire 1 100 exemples à partir des logs applicatifs — la table qui stocke le ticket entrant et la catégorie finalement validée par un humain. Deux heures de SQL et de déduplication. Morale : sortez vos JSONL aujourd'hui, pas en décembre, et versionnez-les dans votre dépôt comme du code.

Profitez de l'export pour faire le ménage RGPD. Un dataset de tickets clients contient des noms, des adresses, des numéros de commande, parfois des IBAN. Tant qu'il dormait chez OpenAI, c'était un problème de sous-traitance documenté ; au moment où vous l'envoyez à un troisième fournisseur, c'est un nouveau transfert à qualifier. J'ai passé le corpus dans un script de pseudonymisation (regex sur emails, téléphones, IBAN, plus une passe NER) avant tout upload. Ça coûte une heure et ça évite une conversation pénible avec le DPO — les points de vigilance sont les mêmes que ceux détaillés dans notre analyse des mémoires d'agents IA face au RGPD.

Étape 2 — geler un jeu d'évaluation avant de toucher au modèle

Migrer un modèle sans harnais d'évaluation, c'est changer de moteur d'avion en vol sans altimètre. Avant le moindre entraînement, j'ai mis de côté 400 tickets réels, jamais vus par aucun modèle, annotés à la main par la responsable SAV — deux heures de son temps, le meilleur investissement du projet. Trois métriques, pas quinze : exactitude de la catégorie (correspondance exacte), F1 sur les quatre champs extraits (numéro de commande, montant, urgence, produit), et taux de sorties non parsables.

Le harnais tourne en une commande et compare quatre candidats côte à côte : le modèle OpenAI actuel, le même prompt sur un modèle générique, et les deux runs LoRA. Nous avons détaillé cette mécanique dans notre tuto sur les évals et les tests de non-régression — même logique ici, à ceci près qu'on ne compare pas deux prompts mais deux fournisseurs.

Un détail qui a son importance : gardez la distribution réelle. Mon premier jeu de test était équilibré, onze catégories à 36 exemples chacune. Résultat : des scores flatteurs et un modèle qui se plantait en prod sur les 43 % de tickets « facturation » qui font le gros du flux. Le jeu de test doit ressembler à votre lundi matin, pas à un jeu de données académique.

Combien coûte un fine-tuning de LLM en 2026 : les prix réels par plateforme

Voici l'état du marché au moment où j'écris, prix relevés sur les pages officielles. Attention à la lecture : les tarifs d'entraînement sont par million de tokens et par époque. Un dataset de 2 M de tokens entraîné sur 3 époques, c'est 6 M de tokens facturés.

Deux enseignements. Le premier : l'entraînement ne coûte plus rien. Un LoRA sur un modèle de 8B avec 4 M de tokens facturés, c'est moins de 2 $ chez Together — sauf que le minimum de facturation par job est de 4 $, donc vous paierez 4 $. Le second : le poste de coût s'est déplacé vers l'hébergement. Un endpoint dédié H100 à 6,49 $/h laissé allumé, c'est 4 673 $ par mois. J'ai vu une équipe payer ça pendant sept semaines pour 2 000 requêtes par jour. C'est le piège numéro un de la migration.

Étape 3 — choisir la route : cinq options, cinq profils

Together AI et Fireworks : la route par défaut

Si votre tâche est un classifieur, un extracteur ou un reformateur, et que votre modèle cible fait moins de 16 milliards de paramètres, arrêtez de chercher. L'API ressemble à celle d'OpenAI, le JSONL se convertit en dix lignes de Python, le job tourne en vingt minutes. Together est nettement moins cher que Fireworks sur les tranches intermédiaires : 1,50 $ contre 3,00 $ sur le 17-69B, 2,90 $ contre 6,00 $ sur le 70-100B. Fireworks garde l'avantage sur la latence en déploiement dédié.

Tinker : le contrôle sans l'infrastructure

Thinking Machines vend une abstraction élégante : quatre primitives (forward_backward, optim_step, sample, save_state), vous écrivez votre boucle d'entraînement, ils gèrent le cluster. C'est la seule offre managée qui vous rend les poids et vous laisse implémenter du RL maison. Les cas d'usage publiés sur leur page produit sont les plus parlants du marché : Glean revendique « 50% lower latency for search while using 25% fewer tokens » sur son agent Waldo, Chroma annonce que son subagent Context-1 « matched or beat several frontier models at a fraction of the cost and up to 10x the tokens/sec », et Lightning Rod Labs déclare un modèle clinique qui dépasse GPT-5 au score de Brier pour une fraction de la taille. Ce n'est pas de la magie : ce sont des tâches étroites, exactement le terrain où un petit modèle entraîné gagne.

Azure AI Foundry : rester chez OpenAI sans OpenAI

Contradiction apparente, réalité pratique : Microsoft continue de proposer du fine-tuning sur les modèles OpenAI alors qu'OpenAI ferme le sien. La mise à jour d'avril 2026 a ajouté l'entraînement « global » pour o4-mini depuis treize régions Azure, dont France Central, Germany West Central, Sweden Central et Switzerland North. Pour une PME française qui a besoin d'un modèle personnalisé et d'un hébergement européen, c'est l'option la moins dépaysante. Le bémol : vous restez sur un calendrier de retraits que vous ne maîtrisez pas, et le RFT est limité aux modèles de raisonnement.

Mistral Forge : pour les gros dossiers

Annoncé en mars 2026 au GTC, Forge couvre toute la chaîne — pré-entraînement, SFT, DPO, RLHF, distillation, génération de données synthétiques, évaluation — et vous rend un modèle déployable chez vous. Les premiers clients signés sont ASML, Ericsson et l'Agence spatiale européenne : ça vous situe le ticket d'entrée. Pour une PME de trente personnes, ce n'est pas la bonne porte. Pour une ETI industrielle avec vingt ans d'archives techniques et une contrainte de souveraineté, c'est aujourd'hui l'offre la plus complète en Europe — nous avions décrit ce virage dans notre article sur Mistral passé full-stack.

Détail à connaître avant de compter sur l'API publique de Mistral : la page de fine-tuning texte et vision comme la Classifier Factory sont désormais rangées dans la section « deprecated » de la documentation, avec la mention « no longer actively supported ». Les tarifs affichés — 1 $/M tokens d'entraînement, 2 $/mois de stockage par modèle, 4 $ minimum par job — restent visibles sur la page de prix, mais je ne construirais pas une roadmap dessus.

Self-host : Unsloth plus un H100 loué en France

La route la plus économique et la plus exigeante. Un QLoRA sur un modèle de 7 à 13B tient dans une après-midi sur une seule carte, pour quelques dollars de location. Louez chez Scaleway ou OVHcloud à 2,73–2,75 €/h et vos données ne quittent jamais l'Union — le raisonnement complet est dans notre guide Cloud Act, AI Act : où poser votre IA. Le coût caché, c'est vous : il faut quelqu'un qui sache lire une courbe de perte, diagnostiquer un tokenizer qui découpe mal le français, et maintenir un serveur d'inférence. Si cette personne n'existe pas dans l'équipe, prenez du managé.

Étape 4 — convertir le JSONL OpenAI vers le format cible

Bonne nouvelle : le format messages d'OpenAI est devenu le standard de fait. La conversion vers Together ou Tinker tient en quelques lignes. Trois pièges quand même.

import json

SYS = "Tu classes des tickets SAV. Reponds en JSON strict."

out = open("train_together.jsonl", "w", encoding="utf-8")
for line in open("train_2024.jsonl", encoding="utf-8"):
    ex = json.loads(line)
    msgs = [m for m in ex["messages"] if m["role"] != "system"]
    msgs.insert(0, {"role": "system", "content": SYS})
    out.write(json.dumps({"messages": msgs}, ensure_ascii=False) + "\n")
out.close()

Piège 1 — le prompt système. Beaucoup de datasets de 2024 contiennent un système différent par exemple, hérité de tests successifs. Normalisez-le : un seul système, court, identique partout. Mon premier run avait quatre variantes de système dans le corpus ; le modèle a appris à répondre différemment selon la formulation.

Piège 2 — les doublons. Un dataset de tickets contient toujours des quasi-doublons (relances, réponses automatiques). J'ai retiré 312 exemples sur 4 200 via un simple hash de la partie normalisée. L'exactitude a gagné un demi-point.

Piège 3 — les sorties non parsables. Si votre modèle OpenAI produisait du JSON via structured outputs, la contrainte venait du serveur, pas du modèle. Sur une plateforme open-weights, elle disparaît. Soit vous réactivez une grammaire contrainte côté serveur d'inférence, soit vous entraînez le modèle à produire un JSON propre — et vous ajoutez un validateur en sortie de toute façon. Sur 400 tickets de test, j'ai eu 6 sorties invalides au premier run, 0 après avoir ajouté la contrainte de grammaire.

Pour élargir le corpus sur les deux catégories sous-représentées, j'ai généré 180 exemples synthétiques à partir de tickets réels reformulés — travail confié à Claude, relu ligne à ligne par la responsable SAV, avec un taux de rejet de 22 %. C'est du travail humain, pas un bouton magique, et c'est ce qui a fait la différence sur les catégories rares.

Étape 5 — les hyperparamètres qui comptent (et le run que j'ai raté)

Trois réglages pèsent, le reste est du folklore. Le rang du LoRA, le nombre d'époques, le taux d'apprentissage.

Mon premier run : rang 64, 4 époques, taux d'apprentissage par défaut, sur les 3 800 exemples d'entraînement. Résultat : 88,6 % d'exactitude, en dessous du modèle OpenAI qu'il devait remplacer. Pire, en regardant la matrice de confusion, le modèle envoyait tout ce qui ressemblait de près ou de loin à une question de facture dans la catégorie dominante — celle qui pèse 43 % du corpus. Sur-apprentissage manuel de libellé : il avait appris la distribution, pas la tâche.

Deuxième run : rang 16, 2 époques, rééquilibrage par sous-échantillonnage de la catégorie dominante à 25 % du corpus, ajout des 180 exemples synthétiques sur les catégories rares. 93,4 %. Le troisième run, rang 32 sur le même corpus, n'a rien apporté (93,1 %) : j'ai gardé le rang 16, plus petit à servir. Coût cumulé des trois runs : 12 $, dont deux jobs facturés au minimum de 4 $.

La règle empirique que j'en tire, valable pour une tâche de classification ou d'extraction avec quelques milliers d'exemples : commencez à rang 16, deux époques, et n'augmentez que si la perte de validation stagne au-dessus de votre cible. Sur un corpus de moins de 1 000 exemples, restez à une ou deux époques — la note de Thinking Machines sur le LoRA rappelle que l'adaptateur par défaut est de rang 32 et que la capacité supplémentaire sert surtout aux tâches génératives longues, pas aux tâches discriminantes.

Étape 6 — servir le modèle sans se faire piéger par l'endpoint dédié

C'est ici que les migrations dérapent financièrement. Un modèle fine-tuné a besoin d'être servi, et deux modèles de facturation coexistent. Le serverless avec adaptateur LoRA : vous payez au token, l'infrastructure est partagée, la latence au premier appel peut monter si l'adaptateur doit être chargé. L'endpoint dédié : vous réservez une carte, vous payez à l'heure, la latence est stable — 6,49 $/h pour une H100 chez Together, 11,95 $/h pour une B200.

Le calcul de bascule est simple et il faut le faire avant, pas après. À 6,49 $/h, l'endpoint dédié coûte 4 673 $ par mois en continu. Si votre trafic est de 25 000 requêtes mensuelles à environ 1 500 tokens, vous êtes à 37 M de tokens — très loin du point d'équilibre. Restez en serverless. À l'inverse, si vous traitez 400 requêtes par minute en heure de pointe avec une contrainte de latence stricte, le dédié devient rentable et prévisible.

Troisième voie, celle que j'ai retenue pour ce client à cause de la clause de localisation dans son contrat : servir le modèle sur une instance louée en France. Une H100 Scaleway à 2,73 €/h, allumée 10 h par jour ouvré, revient à environ 600 € par mois — et fait tourner un modèle de 8B avec une marge confortable. Le compromis est assumé : pas de haute disponibilité multi-régions, un vrai travail d'exploitation, mais des données qui ne sortent pas de l'UE et une facture prévisible.

Résultats : ce que la migration a coûté et rapporté

Contexte du test : e-commerçant, 18 personnes, environ 25 000 tickets SAV par mois, classification en 11 catégories et extraction de 4 champs. Avant migration, un gpt-4.1-mini fine-tuné chez OpenAI, plus un modèle frontière en repli sur les cas ambigus. Après, un Qwen3-8B entraîné en LoRA rang 16, servi sur une instance en France.

Un point d'honnêteté sur le comparatif de coût : les 1 180 € mensuels incluaient le modèle frontière appelé en repli sur 12 % des tickets, et un prompt d'instruction de 1 900 tokens envoyé à chaque appel. Une partie de l'économie vient de la suppression de ce repli, rendue possible par le gain d'exactitude. La comparaison qui compte pour un dirigeant n'est pas « petit modèle contre gros modèle », c'est « chaîne complète avant contre chaîne complète après ».

Trois pièges juridiques avant de lancer l'entraînement

La distillation de sorties propriétaires. La tentation est évidente : faire produire 20 000 réponses parfaites par un modèle frontière et entraîner votre petit modèle dessus. Les conditions d'usage d'OpenAI interdisent d'utiliser les sorties pour développer des modèles concurrents, et cette clause n'est pas décorative — la maison a fermé des comptes pour distillation suspectée, et Elon Musk a reconnu en avril 2026 que xAI avait utilisé des données OpenAI pour entraîner ses propres modèles. Le débat juridique reste ouvert sur la notion de « modèle concurrent », mais pour un classifieur SAV interne le risque contractuel est réel et le jeu n'en vaut pas la chandelle. Relisez les conditions d'utilisation avant de générer votre corpus synthétique, et privilégiez des modèles dont la licence autorise explicitement la génération de données d'entraînement.

Le dataset comme traitement de données personnelles. Vos 4 000 tickets contiennent des données de clients identifiables. Les envoyer à une plateforme américaine, c'est un transfert hors UE à documenter dans votre registre. Pseudonymisez avant l'upload, tracez la finalité, et prévoyez la question qui arrive tôt ou tard : que se passe-t-il si un client exerce son droit à l'effacement sur des données qui ont servi à entraîner un modèle ? Réponse pratique en 2026 : vous ne « désentraînez » pas un modèle, vous purgez le dataset et vous reprogrammez un entraînement à la prochaine itération. Écrivez-le dans votre procédure avant qu'on vous le demande.

La documentation AI Act. Un classifieur de tickets n'est pas un système à haut risque, mais dès que le modèle sert à trier des candidatures, à noter des salariés ou à décider d'un accès à un service, vous changez de catégorie et l'entraînement maison devient un élément de dossier technique. Nos analyses des critères d'exemption publiés par Bruxelles donnent la grille de lecture.

Fine-tuning pour un cabinet comptable, un e-commerçant ou un support client : qui a vraiment besoin de ça

La question posée à l'envers est plus utile : quels profils gagnent à entraîner leur propre modèle en 2026 ?

Le support client à volume. Au-delà de 10 000 interactions mensuelles avec une taxonomie stable, le calcul est presque toujours favorable. C'est notre cas de test, et c'est le segment où les gains cumulent qualité, latence et coût.

L'extraction documentaire métier. Un cabinet comptable qui traite des liasses, des relevés et des factures fournisseurs avec des formats récurrents : un modèle entraîné sur 2 000 documents annotés bat n'importe quel prompt générique sur les champs pénibles (mentions manuscrites, tableaux mal découpés). À croiser avec notre panorama des outils d'extraction documentaire à 2 $ les 1 000 pages : si l'outil du marché fait 95 % du travail, n'entraînez rien.

Les métiers à vocabulaire fermé. Assurance, santé, industrie : les nomenclatures internes (codes garanties, références pièces, actes) sont exactement ce qu'un petit modèle apprend bien et qu'un modèle généraliste devine mal.

À l'inverse, trois profils devraient passer leur tour. Ceux dont le volume est inférieur à 2 000 requêtes par mois — l'économie ne couvrira jamais le temps humain. Ceux dont la tâche exige du raisonnement ouvert ou de la rédaction longue — le fine-tuning d'un 8B ne remplace pas un modèle frontière, il l'imite mal. Et ceux qui n'ont pas de données annotées : sans corpus étiqueté propre, il n'y a pas de projet, juste une envie.

Le contexte de marché va d'ailleurs dans le sens de la pluralité : le rapport State of AI Agents 2026 de Databricks, bâti sur l'activité de plus de 20 000 clients, relève que 78 % des entreprises font tourner au moins deux familles de modèles en production simultanément, et que seulement 19 % des organisations ont déployé des agents à l'échelle. Le modèle unique et universel n'existe pas dans les faits.

Notre verdict : ce que je ferais à votre place, cette semaine

La fermeture du fine-tuning chez OpenAI n'est pas un drame technique, c'est un rappel de gouvernance. Ce qui m'a coûté du temps dans cette migration, ce n'est ni l'entraînement (12 $, trois runs) ni le code (dix lignes de conversion) : c'est d'avoir perdu deux fichiers de dataset et d'avoir dû reconstruire un corpus depuis des logs. La leçon tient en une phrase : votre actif IA, c'est votre jeu de données annoté et votre harnais d'évaluation, jamais les poids d'un modèle chez un tiers.

Sur le fond, le fine-tuning a changé de nature. En 2024, on entraînait pour obtenir un comportement que les modèles ne savaient pas produire. En 2026, on entraîne pour compresser : remplacer un prompt de 6 000 tokens sur un modèle frontière par un modèle de 8B qui fait la même chose quatorze fois moins cher et quatre fois plus vite. C'est un exercice d'ingénierie de coût, pas un exercice de qualité. Ceux qui vendent le fine-tuning comme un moyen de « rendre l'IA plus intelligente sur votre métier » se trompent d'époque — sur les tâches ouvertes, le modèle frontière reste devant.

Trois actions concrètes, par ordre d'urgence. Un : exportez cette semaine tous vos JSONL d'entraînement depuis l'API OpenAI et versionnez-les — ça prend vingt minutes et ça vous protège de la seule perte irréversible. Deux : montez un jeu d'évaluation gelé de 200 à 400 exemples annotés à la main, avant toute décision de plateforme ; sans lui, vous ne saurez jamais si vous avez gagné ou perdu au change. Trois : lancez un run de comparaison à 4 $ chez un fournisseur LoRA managé, en parallèle d'un test « prompt seul avec cache » — dans un cas sur trois, le second gagne et vous venez d'annuler un projet inutile. Le reste, hyperparamètres et hébergement, se règle en une journée une fois ces trois points faits.

Les questions qu'on continue de se poser

Deux zones d'ombre subsistent, et je préfère les nommer plutôt que de faire semblant.

La première : combien de temps les modèles de base survivront-ils ? La clause d'inférence d'OpenAI protège vos modèles « until the base models are deprecated », et le rythme de retraits observé en 2026 laisse penser qu'un fine-tune de 2025 a une espérance de vie de dix-huit à trente mois. Personne, chez aucun fournisseur, ne s'engage sur une durée ferme. C'est un argument de plus pour les poids ouverts : un Qwen ou un GPT-OSS téléchargé, vous pourrez le servir en 2030 si vous en avez encore besoin.

La seconde : la pérennité des plateformes de fine-tuning elles-mêmes. Tinker a augmenté ses tarifs le 17 juillet 2026, Mistral a déprécié son API de personnalisation, OpenAI ferme la sienne. Rien ne garantit que Together ou Fireworks tiendront ces prix dans dix-huit mois. La seule architecture réellement réversible reste celle où vous détenez le dataset, l'adaptateur LoRA et une procédure d'entraînement reproductible en moins d'une journée. Si votre migration ne produit pas ces trois artefacts, vous n'avez pas migré : vous avez changé de propriétaire.