Pourquoi votre entreprise devrait envisager des LLMs on-premise en 2025

Au cours des 18 derniers mois, le paysage réglementaire en Amérique latine a changé de manière spectaculaire. L'Argentine a avancé dans la mise en œuvre de sa Loi sur la Protection des Données Personnelles, le Brésil a renforcé la LGPD avec des amendes cumulées dépassant déjà 50 millions de R$, et le Mexique a mis à jour sa Loi Fédérale sur la Protection des Données avec des directives spécifiques pour l'intelligence artificielle. La Colombie et le Chili suivent le même chemin.

Pour une entreprise de 200 personnes dans le secteur financier ou de la santé, cela a des implications directes : chaque fois qu'un employé colle des données clients dans ChatGPT ou que votre système envoie des informations sensibles à l'API d'OpenAI, vous violez potentiellement les réglementations locales. Ce n'est pas de la paranoïa — c'est le cadre juridique actuel.

Le problème n'est pas que les API d'OpenAI, Anthropic ou Google soient insécurisées. Le problème est que vous ne contrôlez pas où les données sont traitées, qui y accède, ou comment elles sont conservées. Et pour un régulateur, c'est suffisant pour considérer qu'il s'agit d'un transfert international de données non autorisé.

La tendance est claire : la souveraineté des données est passée d'une préoccupation de conformité à une exigence opérationnelle. Les entreprises qui ne s'adaptent pas perdront des contrats, feront face à des amendes, ou seront simplement exclues des appels d'offres publics et privés.

Quand on dit 'on-premise', beaucoup de CTO imaginent un rack de serveurs dans le sous-sol du bureau avec un administrateur système qui change des disques durs à 3 heures du matin. Cette image est dépassée.

On-premise en 2025 a trois modalités réelles. Premièrement : cloud privé avec isolation — un VPC dédié sur AWS, GCP ou Azure avec des politiques réseau qui garantissent que les données ne quittent jamais la région. Deuxièmement : bare metal dans un datacenter local — des serveurs dédiés dans un datacenter comme Equinix, EdgeUno ou DataCenter Paraguay, où vous avez le contrôle physique du matériel. Troisièmement : votre propre matériel — des GPU dans votre infrastructure existante, idéal pour les grandes entreprises qui ont déjà de la capacité de calcul.

Ce qui compte dans les trois cas est identique : les données ne franchissent jamais un périmètre que vous ne contrôlez pas. Vous décidez quel modèle tourne, quels logs sont conservés, qui a accès, et combien de temps l'information est retenue. C'est la vraie souveraineté des données, pas du marketing.

Un détail que beaucoup négligent : on-premise ne signifie pas déconnecté. Vous pouvez avoir un déploiement on-premise qui se met à jour périodiquement avec de nouveaux modèles, rapporte des métriques d'utilisation (sans données sensibles) à un tableau de bord central, et se met à l'échelle automatiquement en fonction de la demande. L'expérience utilisateur peut être identique à l'utilisation d'une API externe.

L'écosystème des modèles open-source a explosé en 2024-2025. On ne parle plus de modèles médiocres qui donnent des réponses génériques — il existe des options qui rivalisent sérieusement avec les modèles fermés sur des tâches spécifiques.

Llama 3.1 405B de Meta est le plus impressionnant en termes de capacité générale. Pour la plupart des tâches d'entreprise — résumé de documents, classification, extraction d'entités, génération de rapports — il rivalise avec GPT-4. La version 70B est excellente pour la production sur du matériel plus accessible, et la version 8B est étonnamment capable pour des tâches simples avec une latence minimale.

Mistral Large et Mixtral 8x22B sont des options européennes avec d'excellentes performances en espagnol et en portugais, ce qui est crucial pour le marché latino-américain. Qwen 2.5 d'Alibaba a surpris tout le monde avec sa capacité multilingue et son efficacité sur du matériel limité. Et DeepSeek V3 a démontré qu'une performance de niveau frontière peut être atteinte avec des architectures plus efficaces.

Le point clé est que pour 80 % des cas d'usage en entreprise — qui ne nécessitent pas de raisonnement frontière complexe — ces modèles sont plus que suffisants. Et vous pouvez les faire tourner sur votre propre infrastructure sans payer par token.

Faisons les calculs avec un cas réel. Une entreprise de services financiers avec 150 employés qui utilise des LLMs pour analyser des documents juridiques, générer des rapports de conformité et assister le service client.

Avec des API externes (GPT-4o) : elle traite environ 2 millions de tokens en entrée et 500K tokens en sortie par jour. Aux prix actuels d'OpenAI, cela représente environ 25 USD/jour en entrée et 7,50 USD en sortie. Environ 975 USD/mois. Ça semble bon marché, non ? Mais ajoutez : 200 USD/mois en outils d'orchestration, 150 USD en logging et monitoring externes, et le coût caché de la latence variable qui affecte l'expérience utilisateur. Total réel : ~1 400 USD/mois.

Avec on-premise (Llama 3.1 70B sur 2x NVIDIA A100) : la location de GPU coûte environ 3 500 USD/mois. Ajoutez 500 USD pour l'infrastructure de support (réseau, stockage, énergie) et 300 USD pour la maintenance. Total : ~4 300 USD/mois. Mais ce coût est fixe — peu importe que vous traitiez 2M ou 20M de tokens.

Le point d'équilibre se situe à environ 6-8 millions de tokens quotidiens. Si votre entreprise va augmenter son utilisation de l'IA (et elles le font toutes), l'on-premise devient moins cher en 6-12 mois. De plus, vous éliminez la dépendance à des prix qui changent sans préavis — OpenAI a déjà augmenté et baissé ses prix plusieurs fois.

Il y a un troisième coût que personne ne met dans le tableur : le coût d'un incident de données. Une violation de données clients traitées via une API externe peut coûter des millions en amendes et en dommage réputationnel. L'on-premise réduit drastiquement ce risque.

Fintech et banque : les banques et fintechs de la région utilisent déjà des LLMs pour l'analyse du risque de crédit, la détection de fraude en temps réel et le reporting réglementaire automatisé. Une banque de taille moyenne en Argentine qui a implémenté Llama 3 on-premise pour l'analyse des demandes de crédit a réduit le temps d'évaluation de 48 heures à 15 minutes, en traitant les données de la BCRA, Veraz et la documentation interne sans que rien ne quitte son réseau. Le régulateur l'a approuvé précisément parce que les données n'ont jamais quitté le périmètre.

Santé : les hôpitaux et assureurs santé traitent des dossiers médicaux, des résultats de laboratoire et des images médicales contenant des données extrêmement sensibles. Un réseau de cliniques en Uruguay a implémenté Mistral pour générer des résumés de dossiers médicaux et des alertes d'interactions médicamenteuses. Tout tourne sur un cluster dédié dans leur datacenter, en conformité avec les lois locales de protection des données de santé.

Juridique : les cabinets d'avocats et les directions juridiques gèrent des contrats, des litiges et de la documentation confidentielle. Un grand cabinet d'avocats à Buenos Aires utilise Llama 3 pour réviser des contrats et détecter des clauses problématiques. Ils traitent plus de 500 contrats par mois sans qu'un seul octet ne quitte leur infrastructure.

Énergie et mines : des entreprises avec des opérations dans des endroits isolés où la connectivité est intermittente. L'on-premise garantit que les modèles continuent de fonctionner même si la liaison internet tombe.

Soyons concrets sur le stack. Pour un déploiement en production de Llama 3.1 70B, il vous faut au minimum 2x NVIDIA A100 80GB ou équivalent (les H100 sont meilleures mais plus chères et plus difficiles à obtenir dans la région). Pour le modèle 8B, un seul A10G ou même une RTX 4090 suffit.

Au niveau de l'inférence, nous utilisons vLLM comme serveur d'inférence — c'est le standard de facto pour servir des LLMs en production. Il supporte le batching continu, PagedAttention pour une utilisation efficace de la mémoire, et est compatible avec l'API OpenAI, ce qui facilite la migration. Comme alternative, TGI de HuggingFace est également solide.

Pour l'orchestration, LangChain ou LlamaIndex si vous avez besoin de RAG (Retrieval-Augmented Generation), qui est le cas d'usage d'entreprise le plus courant. Le vector store peut être Qdrant, Weaviate ou pgvector si vous utilisez déjà PostgreSQL.

Monitoring avec Prometheus + Grafana pour les métriques d'inférence (latence, débit, utilisation GPU, profondeur de file d'attente). LangSmith ou Langfuse pour l'observabilité des chaînes LLM — traces, évaluation de la qualité, détection d'hallucinations.

Tout cela tourne sur Kubernetes (EKS, GKE ou k3s on-premise) avec des Helm charts que nous maintenons et versionnons. L'équipe interne reçoit une documentation complète et une formation pour exploiter le cluster.

Je serai direct : pour beaucoup d'entreprises, l'on-premise est une mauvaise idée. Et une partie de notre travail est de vous le dire quand c'est le cas.

Si votre entreprise a moins de 50 personnes et n'est pas dans un secteur réglementé, les API externes sont presque toujours la meilleure option. Le coût d'infrastructure, la charge de maintenance et la vitesse d'itération que vous perdez ne le justifient pas. Utilisez GPT-4o ou Claude via leurs API, implémentez des contrôles DLP (Data Loss Prevention) basiques, et c'est bon.

Si votre cas d'usage est expérimental — vous testez si l'IA peut améliorer un processus mais vous n'avez pas encore de volume réel — commencez par les API. Validez le cas d'usage, mesurez le ROI, et quand vous êtes certain que ça marche et que le volume le justifie, migrez vers l'on-premise.

Si vous n'avez pas d'équipe infrastructure (même une seule personne) capable de surveiller le déploiement, ne passez pas en on-premise sans contrat de support. Les modèles ont besoin de mises à jour, les GPU ont besoin de surveillance, et les pipelines ont besoin de maintenance.

Cela n'a pas non plus de sens si votre cas d'usage nécessite constamment le dernier modèle frontière. Si vous avez toujours besoin de la dernière version de GPT ou Claude dès sa sortie, l'on-premise vous laissera toujours un pas en arrière. Mais soyons honnêtes : la plupart des cas d'usage d'entreprise n'ont pas besoin du modèle frontière.

La réalité est que la plupart de nos clients finissent avec une architecture hybride. Ce n'est pas tout on-premise ou tout API — c'est une combinaison intelligente basée sur le type de données et le cas d'usage.

Le schéma que nous implémentons le plus souvent : les données sensibles (informations clients, données financières, dossiers médicaux) sont traitées exclusivement avec le modèle on-premise. Les données non sensibles (contenu marketing, analyse de tendances publiques, génération de documentation interne générique) passent par les API externes où la latence est plus faible et les modèles plus puissants.

Cela nécessite un routeur intelligent qui classifie les requêtes par sensibilité et les dirige vers le modèle approprié. Ça semble complexe, mais avec une bonne architecture de gateway, ça se résout en une semaine d'implémentation.

L'avantage est clair : vous respectez les réglementations là où ça compte, vous tirez parti de la puissance des modèles fermés là où vous le pouvez, et vous optimisez les coûts. L'un de nos clients dans le secteur de l'assurance a réduit ses dépenses totales en IA de 40 % avec cette approche tout en améliorant sa posture de conformité.

Si vous évaluez le passage à l'on-premise, voici le processus que nous suivons avec chaque client. Ce n'est pas un argumentaire commercial — c'est la méthodologie que nous utilisons réellement.

Semaines 1-2 : Diagnostic. Nous auditons vos flux de données actuels, identifions quelles informations sont réglementées, cartographions les cas d'usage IA existants et potentiels, et évaluons votre infrastructure. Nous livrons un document de faisabilité avec des recommandations claires.

Semaines 3-4 : Preuve de concept. Nous mettons en place un déploiement dans un environnement de staging avec des données anonymisées. Nous testons le modèle sélectionné avec vos cas d'usage réels et mesurons la performance, la latence et la qualité des réponses par rapport à l'API que vous utilisez actuellement.

Semaines 5-8 : Déploiement en production. Nous configurons le stack complet — inférence, RAG si applicable, monitoring, alertes, sauvegardes et politiques de sécurité. Nous intégrons avec vos systèmes existants via une API compatible OpenAI.

Semaines 9-12 : Transfert et stabilisation. Nous formons votre équipe, documentons tout et fournissons un support actif pendant que le système se stabilise en production.

Après le déploiement, nous proposons un contrat de support continu qui inclut les mises à jour de modèles, le monitoring proactif et du conseil pour de nouveaux cas d'usage. Mais l'important est que si vous décidez de vous séparer de nous, vous avez tout ce qu'il faut pour opérer en autonomie. Le code, la configuration et les connaissances sont à vous.

Ce n'est pas 'devrais-je passer en on-premise ?' La bonne question est : 'que se passe-t-il avec mes données quand je les envoie à une API externe, et puis-je vivre avec cette réponse ?'

Si la réponse est 'je ne suis pas sûr', vous devez investiguer. Si la réponse est 'je ne peux pas me permettre ce risque', vous avez besoin d'un plan. Et si la réponse est 'mon régulateur va me poser la question', vous devez agir maintenant.

Les modèles open-source ont atteint un niveau de maturité qui rend l'on-premise viable pour les entreprises de taille moyenne. Le matériel est accessible. Le stack technique est mature. Et la réglementation ne va faire que se renforcer. Les entreprises qui bougent maintenant auront un vrai avantage compétitif — pas seulement en conformité, mais dans la capacité à personnaliser et contrôler leurs modèles d'IA.

Si vous souhaitez évaluer votre cas spécifique, écrivez-nous à bonjour@orionis.consulting. Nous offrons une évaluation initiale sans frais où nous vous dirons honnêtement si l'on-premise a du sens pour votre entreprise ou si vous êtes mieux avec des API externes. Notre engagement est de vous donner la meilleure recommandation, même si cela signifie que nous ne travaillons pas ensemble.