Votre équipe utilise ChatGPT au feeling, vous avez 14 prompts éparpillés dans des Notion et personne ne sait exactement ce que le modèle fait de vos données clients. Est-ce que basculer vers un LLM open source règle ces problèmes ou est-ce qu’on crée juste une couche de complexité supplémentaire ?
Basculer vers l’open source change l’architecture de votre stack. Selon le rapport Databricks (2024) portant sur plus de 10 000 clients, 76% des entreprises utilisant des LLM ont déjà choisi des modèles open source, souvent en complément des alternatives propriétaires. La plupart ne l’ont pas annoncé sur LinkedIn. Elles l’ont juste fait.
Pourquoi 76% des équipes data ont déjà bifurqué vers l’open source
Fin 2024, le même rapport Databricks signalait une autre donnée : le ratio expérimentation/production est passé de 16 pour 1 à 5 pour 1 en moins de 14 mois. Les entreprises ne testent plus, elles déploient. Et quand on déploie à volume, le coût par token commence à peser.
Un marketing manager qui fait tourner 50 000 résumés de leads par mois via l’API OpenAI paie entre $0,60 et $15 pour 1 million de tokens selon le modèle choisi. Héberger Llama 3.1 70B sur une instance GPU dédiée ramène ce coût à quelques centimes par million de tokens passé le seuil d’amortissement. CloudZero a mesuré que la dépense IA mensuelle moyenne des équipes a bondi de $63 000 en 2024 à $85 500 en 2025, soit +36% en un an. À cette trajectoire, le ROI du self-hosting s’accélère.
Le coût reste un angle d’entrée. Ce qui pousse le basculement open source dans les stacks martech, c’est le contrôle sur trois dimensions que les API propriétaires ne donnent pas : les données, le comportement réel du modèle et, moins visible, la gouvernance des outputs.
Ce que vous récupérez vraiment : données, comportement, gouvernance
Quand un context window reçoit vos données CRM pour segmenter une audience, ces données transitent par les serveurs d’un tiers. Contrats DPA mis à part, la plupart des équipes marketing ne savent pas précisément comment ces données sont traitées. Avec un modèle open source déployé sur votre infrastructure, le flux ne sort pas du périmètre. Cela change concrètement ce qu’on peut mettre dans le system prompt : numéros de contrats, historiques d’achat, scores de propension.
Le deuxième levier, plus insidieux, c’est le fine-tuning. Intuit l’a documenté publiquement : leur modèle Llama fine-tuné sur des données finance propriétaires surpasse les alternatives closed-source sur leurs tâches spécifiques. Pour un martech stack, ça signifie entraîner un modèle sur vos verbatims clients et votre tonalité éditoriale, vos règles de scoring incluses. Un Custom GPT se limite au prompt engineering habillé en fine-tuning, sans accès réel au modèle.
La gouvernance des outputs, enfin. Déployer un modèle open source permet d’auditer les logs et de tracer chaque appel. Les règles de filtrage ne dépendent plus des conditions d’utilisation changeantes d’un fournisseur. Pour les équipes qui gèrent des campagnes réglementées (finance, santé, assurance), c’est souvent le critère décisif.
Les cinq points de friction concrets dans votre stack
Un passage à l’open source ne se décrète pas depuis Notion. Les cinq points de contact réels dans un stack martech :
- L’orchestration des appels : vos outils actuels (n8n, Make, Zapier) appellent des API REST. Llama.cpp, Ollama ou vLLM exposent le même format OpenAI-compatible, donc la migration est souvent moins douloureuse qu’anticipé. La latence locale reste toutefois supérieure aux API mutualisées sur les requêtes single-user.
- Le RAG et les embeddings : si votre pipeline RAG utilise text-embedding-ada-002, remplacer par nomic-embed-text ou bge-m3 change les dimensions vectorielles. Votre base de données vectorielle (Pinecone, Qdrant, Weaviate) doit être réindexée.
- Le tool use et les agents : Mistral 7B et Llama 3.1 8B suivent les instructions function calling mais les modèles plus petits ont tendance à halluciner les paramètres sur des schémas complexes. Tester sur vos cas d’usage réels avant de remplacer un modèle frontier.
- Le coût GPU vs économies d’API : le seuil de rentabilité du self-hosting est atteint autour de 2 à 5 millions de tokens par jour selon les benchmarks 2025. En dessous, une API économique comme DeepSeek V3 à $0,14/million de tokens d’input bat le self-hosting pur.
- La maintenance du modèle : les modèles open source évoluent vite (Llama 3.1 → 3.2 → 3.3 en moins de 6 mois). Chaque mise à jour nécessite une validation que le comportement du modèle n’a pas dérivé sur vos cas d’usage, surtout si vous avez fine-tuné.
Le rapport State of the Stack 2025 de MarTech le confirme : 65,7% des équipes citent l’intégration des données comme principal obstacle dans leur stack. L’open source ne simplifie pas ce problème, il le déplace au niveau infra.
L’objection légitime : et si on n’a pas d’ingé ML ?
Déployer vLLM sur une instance A100 et le connecter à un load balancer demande des compétences que la plupart des équipes marketing n’ont pas en interne. La maintenance des pipelines de fine-tuning s’ajoute si vous avez customisé le modèle. La vraie bifurcation ? La maturité. À quel moment ça a du sens d’y investir du temps d’ingénierie réel.
« When The 2024 MarTech Replacement Survey was done less than six months ago, almost no one [2%] was saying they were replacing their apps with homegrown apps. In The State of the Stack Survey, commercial software still has a pretty big advantage, close to 60%, but homegrown solutions, near 25%, that’s a big, big change. » Mike Pastore, MarTech (2025)
Un provider d’inférence open source managé (Together AI, Fireworks AI, Groq) résout une partie du problème : vous appelez des modèles open source via une API, sans gérer l’infrastructure. Les coûts sont inférieurs aux API propriétaires sur les volumes moyens, avec le contrôle sur le choix du modèle. Le déploiement peut parfois se faire dans votre région cloud selon le provider.
Ce que ça change pour la stratégie prompt et l’industrialisation
Votre stack de prompts change de nature quand le modèle est sous votre contrôle. Avec une API propriétaire, un changement de version (GPT-4 → GPT-4o → GPT-5) peut casser des comportements sans notification préalable. Vous gérez l’instabilité du fournisseur. Avec un modèle open source épinglé à une version précise, le comportement est reproductible jusqu’à ce que vous décidiez de le changer.
Cela rend les system prompts plus fiables comme couche de gouvernance. Une équipe qui industrialise 20 cas d’usage différents (génération de contenu, scoring, extraction d’entités, résumé de call, enrichissement CRM) peut versionner ses prompts dans un dépôt Git et tester chaque combinaison modèle/prompt avant de pousser en production. Ce workflow existe avec les API propriétaires mais chaque changement de version du fournisseur peut le faire dérailler.
En pratique, les équipes qui atteignent cette maturité décrivent le même pattern : un modèle propriétaire pour les tâches de raisonnement complexe (Claude Opus 4.6, GPT-5), un modèle open source pour les tâches répétitives à volume (classification, extraction d’entités et reformatage léger). Le stack devient hybride, avec plusieurs fournisseurs selon les cas d’usage.
Deux scénarios pour prendre la décision cette semaine
Sous 50 millions de tokens par mois, sans ingénieur ML disponible : restez sur des API mais diversifiez. DeepSeek V3 ou Mistral Medium comme alternative à OpenAI sur vos tâches de volume. La courbe d’apprentissage est courte, les économies immédiates.
Au-dessus de 100 millions de tokens par mois, avec des données clients réglementées ou un besoin de fine-tuning : l’architecture open source managée mérite un test. Un cas d’usage isolé, 30 jours de mesure, et une décision franche à l’issue. Pas de migration en bloc.
Dans votre stack, quel est le workflow où vous payez le plus cher pour le moins de contrôle ?
