Ollama n'est pas le produit : construire des applications Open-LLM prêtes pour la production

Des outils comme Ollama ont rendu l'expérimentation locale des LLM presque sans friction. Installez le runtime, tirez un modèle, envoyez une invite, et un assistant local répond en quelques secondes. C'est utile. C'est aussi la partie la plus facile du parcours.

Une démo en terminal n'est pas une application. Un modèle local n'est pas un produit. Une application Open-LLM productive nécessite une ingestion de données contrôlée, une récupération, des permissions, une évaluation, une journalisation, une abstraction de fournisseur, une discipline de déploiement et un flux de travail utilisateur qui résout un vrai problème métier.

La thèse centrale est simple : Ollama est un runtime, pas le produit. Le produit vit dans la couche applicative autour du modèle. Cette couche décide quels documents sont visibles, quels fragments sont récupérés, quelles invites sont utilisées, comment les réponses sont évaluées, comment les échecs sont journalisés et si le système peut être fiable au quotidien.

C'est là que l'IA locale devient intéressante pour les équipes qui construisent des assistants privés, des outils de connaissance internes, des fonctionnalités SaaS basées sur les LLM ou des copilotes de workflow d'entreprise. Le modèle peut tourner localement, mais la confidentialité, la fiabilité et la valeur métier n'existent que si le système complet est correctement conçu.

Ollama est un runtime, pas un produit

Ollama est excellent pour exécuter et servir des modèles ouverts localement. Il est particulièrement fort pour l'exploration, les workflows de développement, les POC et les équipes qui souhaitent tester le comportement des modèles sans s'engager immédiatement auprès d'un fournisseur cloud. Il expose l'interaction avec les modèles locaux via des API et des couches de compatibilité qui facilitent la connexion avec les outils existants de type OpenAI.

Cela ne signifie pas qu'Ollama résout le problème applicatif. Il ne sait pas automatiquement quels documents d'entreprise un utilisateur peut lire. Il ne crée pas d'isolation des locataires, de versionnage des documents, de pistes d'audit, d'attribution des sources, de jeux de données d'évaluation ou de workflows UI spécifiques au métier. Ces responsabilités restent dans l'architecture applicative.

• Ollama aide pour : l'exécution locale de modèles, l'expérimentation rapide, l'accès aux modèles via API, les POC hors ligne et la productivité des développeurs.
• Ollama ne résout pas par lui-même : le contrôle d'accès, la qualité du RAG, le cycle de vie des documents, les limites des locataires, l'évaluation, la journalisation d'audit, la surveillance, le comportement de repli ou la conception de workflows d'entreprise.
• L'erreur architecturale : traiter l'inférence locale comme si elle était déjà un produit IA sécurisé.

Le modèle est la partie la plus facile. La couche applicative est là où réside la valeur du produit.— Principe d'architecture

Démo, POC et production sont des étapes différentes

De nombreuses initiatives Open-LLM échouent parce que les équipes confondent une démo fonctionnelle avec une capacité de production. La différence n'est pas cosmétique. Chaque niveau de maturité a un objectif différent, un profil de risque différent et une exigence d'ingénierie différente.

Un POC peut être intentionnellement petit. La production ne peut pas être intentionnellement aveugle. Une fois que de vrais utilisateurs, des données privées, des décisions métier et des attentes de conformité entrent dans le système, l'architecture doit devenir explicite.

Où se situe le RAG

La génération augmentée par récupération est le pont le plus courant entre un modèle de langage et les connaissances métier privées. Le modèle ne connaît pas magiquement les documents internes, les contrats, les tickets, les spécifications produits ou les manuels d'exploitation. L'application doit récupérer le contexte pertinent avant de demander au modèle de répondre.

Un flux RAG pratique ressemble à ceci :

1. Les documents sont téléchargés ou synchronisés à partir de sources contrôlées.
2. Le texte est extrait, nettoyé et divisé en fragments.
3. Les fragments reçoivent des métadonnées telles que le locataire, le propriétaire, la version du document, l'URL source, le périmètre d'accès et l'horodatage.
4. Des embeddings sont générés pour chaque fragment.
5. Les vecteurs sont stockés dans pgvector, Qdrant ou une autre couche de récupération.
6. Au moment de la requête, l'application vérifie les permissions avant la récupération.
7. Les fragments pertinents sont récupérés par recherche de similarité et filtres de métadonnées.
8. Le constructeur d'invite injecte le contexte sélectionné dans la requête du modèle.
9. La réponse est générée avec des citations, des limites de confiance et un repli sans réponse lorsque la récupération est faible.

Le RAG réduit les hallucinations, mais ne les élimine pas. Une mauvaise stratégie de découpage, des métadonnées faibles, des filtres de permission manquants, des embeddings de faible qualité ou une récupération trop large peuvent toujours produire des réponses convaincantes mais erronées. Les systèmes RAG sérieux nécessitent des seuils, des citations, des journaux de récupération et une évaluation.

Une architecture pratique pour un LLM ouvert local

Un chemin de production réaliste ne nécessite pas d'infrastructure exotique. Pour de nombreuses équipes, une première architecture solide peut utiliser une pile web normale : Nuxt pour le frontend, une API Nitro ou Node, PostgreSQL comme système d'enregistrement, pgvector pour la récupération, Ollama comme runtime local, Prisma pour l'accès aux données et des workers en arrière-plan pour l'ingestion et les embeddings.

Question utilisateur | v
Interface utilisateur frontend | v
API / Backend | +--> Authentification +--> Vérification des permissions du locataire et du rôle | v
Couche de récupération | +--> Métadonnées PostgreSQL +--> Recherche vectorielle pgvector ou Qdrant +--> Seuil de similarité | v
Constructeur de prompt | +--> Prompt système +--> Morceaux récupérés +--> Références sources +--> Règles de non-réponse | v
Abstraction du fournisseur LLM | +--> Ollama / modèle local +--> Repli vers modèle cloud +--> Futur runtime auto-hébergé | v
Réponse avec sources | v
Journaux, traces, métriques, jeu de données d'évaluation

Cette architecture maintient le modèle remplaçable. Ollama peut être le premier runtime, mais le système ne doit pas être verrouillé sur un seul moteur d'inférence. Une architecture propre sépare le flux de travail utilisateur, la récupération, la construction du prompt, le fournisseur de modèle et l'observabilité.

• Frontend : Nuxt ou une autre interface web pour les flux de travail utilisateur authentifiés.
• Backend/API : Nitro, Node.js ou FastAPI pour l'orchestration, les permissions et le routage des fournisseurs.
• Base de données : PostgreSQL pour les documents, utilisateurs, locataires, rôles, prompts, journaux et métadonnées.
• Recherche vectorielle : pgvector pour une récupération intégrée simple ou Qdrant lorsque la recherche vectorielle devient un service dédié.
• Runtime du modèle : Ollama pour l'exécution locale, serveur llama.cpp pour un service léger, ou vLLM pour un service GPU à plus haut débit.
• Stockage : système de fichiers local ou stockage d'objets compatible S3 pour les fichiers téléchargés et les artefacts extraits.
• Workers : ingestion en arrière-plan, découpage, embedding, ré-indexation et traitement des versions de documents.
• Observabilité : journaux, métriques, traces de prompt, traces de récupération, suivi de latence et résultats d'évaluation.

La checklist de préparation à la production

La checklist suivante fait la différence entre une démo de modèle local et une application Open-LLM utilisable :

• Chaque document et morceau a un tenant_id.
• La récupération est bloquée jusqu'à ce que les permissions de l'utilisateur et du rôle soient vérifiées.
• Les documents incluent des métadonnées, la source, le propriétaire, la version, l'état du cycle de vie et la politique de conservation.
• La stratégie de découpage est documentée et testée sur des documents réels.
• La sélection du modèle d'embedding est explicite et versionnée.
• La configuration de l'index vectoriel est reproductible.
• Un seuil de similarité empêche l'utilisation aveugle d'un contexte faible.
• Les réponses incluent des citations de sources ou des références sources lorsque c'est possible.
• Un repli sans réponse est utilisé lorsque la confiance dans la récupération est trop faible.
• Les modèles de prompt sont versionnés et contrôlés par version.
• L'abstraction du fournisseur LLM est construite dès le départ.
• La sortie structurée est validée avant une utilisation en aval.
• Le jeu de données d'évaluation contient des questions réelles, des sources attendues et des réponses inacceptables.
• Les journaux de récupération montrent quels morceaux ont été utilisés pour chaque réponse.
• La latence, l'utilisation des tokens, la charge GPU/CPU et les taux d'erreur sont surveillés.
• Les règles de confidentialité et de conservation couvrent les téléchargements, le texte extrait, les morceaux, les embeddings, les prompts, les réponses et les journaux.
• Les chemins de déploiement, sauvegarde, restauration, rollback et incident sont documentés.

Cela se connecte directement avec Enterprise Delivery OS : une IA utile n'est pas seulement une décision de modèle. C'est une discipline de livraison, des preuves, des contrôles, des métriques et une propriété opérationnelle.

Abstraction du fournisseur : ne pas épouser un seul modèle

Les modèles locaux sont précieux pour les cas d'usage sensibles à la vie privée, les scénarios hors ligne, le contrôle des coûts et l'expérimentation interne. Les modèles cloud peuvent encore être plus performants pour le raisonnement difficile, le codage, la précision multilingue ou le travail multimodal. Une application de production ne doit traiter aucun modèle comme une infrastructure permanente.

Une abstraction du fournisseur permet au même flux de travail applicatif d'appeler Ollama, OpenAI, Gemini, Anthropic, Mistral, vLLM ou un autre point de terminaison auto-hébergé sans réécrire le produit. L'application décide du fournisseur en fonction du cas d'usage, de la sensibilité des données, de la latence, du coût et des exigences de qualité.

type LlmProvider = "ollama" | "openai" | "gemini" | "anthropic" | "vllm"; type ChatInput = { provider: LlmProvider; model: string; tenantId: string; userId: string; question: string; context: Array<{ chunkId: string; sourceTitle: string; text: string; }>;
}; async function chat(input: ChatInput) { await assertUserCanAccessContext(input.userId, input.context); const messages = buildRagMessages({ question: input.question, context: input.context, rules: [ "Answer only from provided context when possible.", "Cite source titles.", "Say when the context is insufficient." ] }); return llm.chat({ provider: input.provider, model: input.model, messages, trace: { tenantId: input.tenantId, userId: input.userId, promptVersion: "rag-v3.2" } });
}

L'idée clé n'est pas la syntaxe TypeScript. L'idée clé est la frontière. L'application possède les permissions, la récupération, les règles de prompt, le traçage et l'évaluation. Le fournisseur ne produit que la sortie du modèle.

pgvector vs Qdrant

Pour de nombreuses applications Open-LLM, la décision concernant le magasin vectoriel est simple au début : si PostgreSQL est déjà votre système d'enregistrement, pgvector est un bon point de départ. Il garde les métadonnées, les permissions, les enregistrements de documents et les vecteurs proches les uns des autres. Cela réduit la complexité opérationnelle.

Qdrant devient plus attractif lorsque la recherche vectorielle doit devenir un service dédié : échelle de récupération plus grande, filtrage avancé, indexation spécialisée, modèles de recherche hybrides ou mise à l'échelle indépendante de l'infrastructure de récupération.

Une règle pratique : commencez avec pgvector lorsque PostgreSQL possède déjà vos données métier et que l'échelle de récupération est modérée. Passez à Qdrant lorsque la recherche vectorielle devient une capacité produit à part entière.

Vérification de la réalité en matière de sécurité et de confidentialité

L'inférence locale ne signifie pas automatiquement une IA sécurisée. Cela signifie seulement que l'exécution du modèle peut avoir lieu localement. Le chemin complet des données compte toujours : fichiers téléchargés, texte extrait, morceaux, embeddings, journaux, invites, réponses, sauvegardes, accès développeur, outils d'administration et exportations analytiques.

Les embeddings méritent également de l'attention. Ils ne sont pas le document original, mais ils représentent toujours des informations dérivées de contenu sensible. Traitez-les comme faisant partie du chemin de données protégé, surtout lorsqu'ils sont liés à des métadonnées, des enregistrements sources, des requêtes utilisateur ou des identifiants de locataire.

• N'indexez pas les documents avant que les règles d'accès ne soient connues.
• Ne récupérez pas de morceaux sans filtres de locataire et de rôle.
• Ne journalisez pas les invites et réponses complètes sans règles de conservation.
• N'envoyez pas de contexte sensible à un modèle cloud à moins que la politique ne le permette.
• Ne supposez pas que local équivaut à conforme au RGPD ; la conformité dépend de la conception complète du traitement.
• Ne laissez pas les copies d'évaluation et de débogage devenir des ensembles de données fantômes non contrôlés.

C'est là que l'architecture SaaS multi-instance compte. Si les locataires, les rôles, la propriété des données et les limites opérationnelles sont faibles, l'ajout d'un LLM local peut amplifier le risque au lieu de le réduire.

L'évaluation n'est pas facultative

Une application Open-LLM en production a besoin d'une boucle d'évaluation. Sans elle, les équipes n'ont que des anecdotes. Quelques bonnes réponses de démonstration ne prouvent pas que la récupération fonctionne, que l'invite est stable ou que le modèle se comporte de manière sécurisée dans une utilisation réelle.

Un ensemble de données d'évaluation minimal devrait inclure des questions réelles d'utilisateurs, les documents sources attendus, les réponses inacceptables, les cas sans réponse et les tests de régression pour les échecs précédents. Chaque modification du découpage, des embeddings, des invites, du fournisseur de modèle ou du seuil de récupération devrait être testée par rapport à cet ensemble de données.

• Évaluation de la récupération : Le système a-t-il récupéré les bons morceaux sources ?
• Évaluation de la réponse : La réponse est-elle restée ancrée dans le contexte récupéré ?
• Évaluation de la sécurité : Le système a-t-il évité les divulgations interdites ou les données non autorisées ?
• Évaluation opérationnelle : La latence, le taux d'échec et le coût sont-ils restés dans des limites acceptables ?
• Évaluation de régression : Une mise à niveau du modèle ou de l'invite a-t-elle cassé un comportement auparavant correct ?

Le RAG réduit les hallucinations, mais il ne supprime pas le besoin d'évaluation. L'évaluation est la boucle de contrôle qui transforme un prototype astucieux en un produit en amélioration.

Discipline de déploiement : le modèle est un événement de version

Changer de modèle n'est pas une simple modification de configuration inoffensive. Cela peut changer le style de réponse, le comportement de raisonnement, la qualité de la langue, la latence, l'utilisation des jetons, la discipline de citation et les modes d'échec. En production, les mises à niveau de modèle doivent être traitées comme des événements de version.

Cela signifie versionner les invites, les modèles d'embedding, les paramètres de récupération, les identifiants de modèle, les routes de fournisseur et les résultats d'évaluation. Cela signifie également avoir une logique de retour arrière. Si un nouveau modèle provoque des réponses moins bien ancrées dans la récupération ou casse la sortie structurée, le système a besoin d'un chemin contrôlé pour revenir à la configuration connue comme bonne.

Cela correspond à la même logique de fonctionnement que Livraison et changement et l'architecture de plateforme prête pour l'IA : une livraison stable nécessite des contrôles reproductibles, pas des correctifs manuels héroïques.

Conclusion : la production commence là où la démo se termine

Ollama peut démarrer le voyage. Il rend l'exécution locale du modèle accessible et abaisse la barrière à l'expérimentation. C'est précieux. Mais l'application de production commence là où la démo se termine.

Le modèle n'est qu'un composant remplaçable. Le véritable produit est le système contrôlé qui l'entoure : ingestion, autorisations, récupération, prompts, routage des fournisseurs, évaluation, journaux, surveillance, déploiement, sauvegarde et flux de travail de l'utilisateur. C'est là que la confidentialité devient réelle, que la qualité devient mesurable et que la valeur commerciale devient reproductible.

Une application Open-LLM sérieuse se construit grâce à une discipline d'ingénierie, et non en exécutant un modèle local une seule fois. Ollama peut commencer le voyage, mais l'application de production commence là où la démo s'arrête.

Thème :

Ollama, Open LLM, RAG, pgvector, Qdrant, Local AI, LLMOps, Abstraction de fournisseurs, Architecture IA d'entreprise