Installer une IA locale, c'est 20 % du travail : les 80 % qui suivent

REP. 01 — Le malentendu du « on l’a installé, c’est fait »

J’entends la même phrase presque chaque semaine : « on a installé Ollama, on a chargé un modèle, ça tourne, c’est bon ». Et j’entends aussi, trois à six mois plus tard, la même déception : « on ne s’en sert plus », « le modèle hallucinait trop, on a désactivé », « on s’est fait avoir par une faille qu’on a lue après coup ».

Le malentendu est tenace, et il est double.

Premier malentendu : l’installation serait l’équivalent d’un déploiement applicatif classique — un serveur, un service, et basta. Non. L’écosystème d’une IA locale n’est pas un produit figé. C’est un empilement de couches mouvantes : un moteur d’inférence (llama.cpp, vLLM, ou Ollama qui s’appuie dessus), un modèle téléchargé depuis Hugging Face, des dépendances système, un pilote GPU, un index vectoriel pour la recherche documentaire, souvent une couche RAG complète par-dessus.

Deuxième malentendu : « local » serait par nature plus sûr. C’est souvent vrai au moment de l’installation. Six mois plus tard, sans suivi, l’écart se réduit, puis s’inverse.

C’est pour cela que je propose systématiquement, après la mise en service, un suivi mensuel. Pas par attachement commercial à un contrat de maintenance — par expérience de ce qui se passe quand il n’y en a pas.

REP. 02 — Ce qui dérive silencieusement

Quatre familles de problèmes apparaissent, toujours dans le même ordre, quand une installation locale n’est plus suivie.

La dérive sécuritaire. Ollama publie plusieurs releases par semaine en moyenne, avec des pics lors de correctifs de sécurité — ReleaseAlert en recensait environ 641 fin août 2026. Derrière cette cadence, plusieurs vulnérabilités critiques ont été rendues publiques et corrigées : CVE-2024-37032 « Probllama » (exécution de code à distance, découverte par Wiz Research) ; CVE-2026-7482 « Bleeding Llama », notée CVSS 9.1, qui permettait à un attaquant non authentifié de lire la mémoire du processus Ollama — clés d’API, variables d’environnement, conversations d’autres utilisateurs. Côté llama.cpp, plusieurs advisories de heap overflow ont été publiés en 2026, dont GHSA-3p4r-fq3f-q74v (mars 2026, qui corrigeait un bypass d’un patch antérieur sur le parseur GGUF), CVE-2026-27940 (CVSS 7.8, integer overflow dans gguf_init_from_file_impl) et CVE-2026-70638 (CVSS 7.8, integer overflow dans le wrapper JNI LLaMA-Android, builds b1886 à b7445). Sans mise à jour régulière, l’installation accumule ces failles en silence.

La dérive d’exposition. Ollama expose par défaut un serveur HTTP sur le port 11434, longtemps sans authentification. Selon un comptage FuzzingLabs publié en 2026, on recensait environ 270 000 instances Ollama accessibles depuis Internet — dont une fraction significative sans aucune protection. Beaucoup sont des postes de développement, mais beaucoup aussi sont des machines « oubliées » derrière une redirection NAT ou un pare-feu mal configuré. Une installation correctement sécurisée ne le reste pas si on ne vérifie pas, six mois plus tard, qu’aucun port n’a été ouvert pour « tester » et jamais refermé.

La dérive des modèles. L’écosystème open weights bouge vite — Llama 4 Maverick (Meta, avril 2025, toujours modèle phare de la famille Llama 4), Muse Glimmer (Meta Superintelligence Lab, août 2026, 30B, retour de Meta à l’open weights via Hugging Face), Qwen 3.x (Alibaba, plusieurs itérations courant 2026), Gemma 4 (Google, avril 2026, Apache 2.0, jusqu’à 31B), Mistral, DeepSeek V3, et plus récemment Hunyuan HY4 preview (Tencent, 770B/49B actifs, fin août 2026). Trois conséquences : un modèle jugé correct à l’installation peut devenir médiocre face à un nouveau venu ; un modèle fine-tuné déployé en juin peut être remplacé par une meilleure variante en septembre ; le format GGUF lui-même évolue — un modèle téléchargé peut exiger une version de llama.cpp plus récente que celle en production.

La dérive de qualité métier. La plus insidieuse, et la moins technique. Sans suivi, les utilisateurs constatent une régression — « ça marchait bien avant, maintenant ça invente » — sans pouvoir dire pourquoi. La cause peut être un changement de version du modèle, une mise à jour d’Ollama qui modifie le format du prompt par défaut, une dérive des documents indexés, ou une accumulation de prompts mal cadrés jamais revus. Sans relevé des erreurs, sans boucle de retour structurée, on ne sait pas où corriger.

Coûts cachés en parallèle : électricité d’une machine GPU sous-optimisée, stockage qui gonfle de modèles jamais supprimés, bande passante gaspillée en retéléchargements, temps humain à débugger des régressions qu’une veille aurait évitées.

REP. 03 — Le socle minimal : mises à jour et hygiène opérationnelle

Le premier niveau de suivi, c’est l’hygiène de base. Sans elle, rien d’autre ne tient.

Concrètement, sur chaque machine que je maintiens :

• Mises à jour planifiées d’Ollama, avec lecture des release notes et advisories de sécurité avant bascule. Plusieurs releases par semaine en moyenne, c’est gérable — mais cela suppose une procédure rodée, pas un apt upgrade lancé à la main quand un utilisateur se plaint.
• Veille CVE sur Ollama, llama.cpp et les bibliothèques sous-jacentes (GGML, dépendances Go, CUDA, ROCm). Les advisories GitHub Security de llama.cpp ont publié plusieurs heap overflows critiques en 2026 — celui de mars 2026 (GHSA-3p4r-fq3f-q74v) corrigeait un bypass d’un patch antérieur.
• Mises à jour des pilotes GPU. NVIDIA publie des bulletins de sécurité trimestriels pour ses pilotes. Une machine IA avec un pilote non à jour tourne, mais tourne avec des failles connues.
• Rotation des modèles : supprimer les modèles téléchargés pour essai et jamais utilisés (le répertoire ~/.ollama/models gonfle vite), tenir un catalogue de ce qui sert vraiment.
• Vérification du durcissement réseau : Ollama n’écoute-t-il que sur localhost ? Le port est-il ouvert dans un pare-feu ? Y a-t-il un reverse-proxy avec authentification si un accès distant est légitime ?
• Sauvegardes de la configuration — pas seulement des modèles : les Modelfile, les prompts système, les paramètres de contexte.

C’est le minimum. Sans cela, l’installation locale est un service comme un autre livré en mode « best effort », avec l’inertie en plus.

REP. 04 — La couche métier : fine-tuning, RAG, évaluation continue

Une fois le socle stabilisé, le vrai travail métier commence.

Fine-tuning et adaptation. Beaucoup d’organisations arrivent avec un modèle généraliste, constatent qu’il rate les cas spécifiques, et demandent un fine-tuning. Ce n’est pas anodin : il faut constituer un jeu de données annotées (souvent des centaines, parfois des milliers d’exemples), choisir une méthode (LoRA, QLoRA, full fine-tuning selon le matériel), entraîner, évaluer, comparer au modèle de base, et garder une trace de chaque version. Sans cette trace, on ne sait pas pourquoi le modèle répond mieux aujourd’hui qu’il y a trois mois — ou inversement.

Indexation et re-indexation RAG. Si l’installation sert à de la recherche documentaire, l’index vectoriel n’est pas un artefact statique. Les corpus vivent (nouveaux dossiers, mises à jour de jurisprudence, modifications de procédures), et les modèles d’embedding eux-mêmes évoluent. Changer de modèle d’embedding sans ré-indexer toute la base, c’est comparer des vecteurs de dimensions différentes — ça ne fonctionne pas, ou ça fonctionne par hasard sur certains chunks et pas d’autres. Cette dette, parfois appelée retrieval debt, s’accumule en silence et ne se voit que quand la qualité de réponse baisse.

Évaluation continue. C’est la brique la moins technique et la plus souvent négligée. Un suivi sérieux inclut un petit jeu de tests de référence — une dizaine de questions types, avec la réponse attendue — passé régulièrement contre le modèle en production. C’est ce qui permet de dire « la qualité a baissé de 15 % entre juin et août, voici les prompts qui régressent, voici le changement de version qui en est la cause probable ». Sans ce jeu de tests, on parle au feeling, et on finit par désactiver l’outil faute d’avoir pu objectiver la régression.

Gouvernance des prompts. Les prompts système et les templates utilisés au quotidien vivent aussi : un collaborateur en modifie un, le versionnant à peine, et trois mois plus tard personne ne sait ce qui est en production. Un suivi minimal inclut un dépôt versionné (Git suffit) des prompts, des configurations de modèle, et des règles d’usage — pas pour faire bureaucratique, mais pour pouvoir revenir en arrière et expliquer un comportement.

REP. 05 — Le suivi au long cours : ce que ça change concrètement

Je propose, après chaque installation, un suivi mensuel — parce que c’est le rythme qui matche à la fois la cadence des releases, la fréquence des CVE et la vitesse d’évolution des usages côté métier. Voici, concrètement, ce que ce suivi change.

Côté sécurité : les CVE sont détectés et appliqués avant qu’un incident ne se produise, pas après la lecture d’un article de blog qui commence à dater. La surface d’exposition est vérifiée à chaque revue — pas une fois pour toutes à l’installation.

Côté qualité : les régressions sont identifiées par un jeu de tests objectif, pas par l’humeur d’un utilisateur. Un changement de modèle est évalué avant déploiement, pas imposé par la lecture d’un fil Twitter enthousiaste.

Côté coût : l’inventaire des modèles évite l’accumulation de gigaoctets téléchargés jamais utilisés ; les pilotes et les versions logicielles restent dans des configurations supportées, ce qui évite les migrations forcées en urgence.

Côté usage : un point mensuel avec les utilisateurs fait remonter ce qui marche et ce qui ne marche pas. Beaucoup d’organisations installent une IA locale, l’utilisent deux semaines, puis la laissent dormir. Le suivi crée un rendez-vous qui force l’usage à rester vivant — ou à être arrêté proprement si l’usage ne décolle pas.

Côté conformité : pour les structures soumises à des obligations (RGPD, secret professionnel, hébergement de données de santé), la traçabilité des versions logicielles, des modèles chargés, des prompts utilisés, est un élément de preuve en cas d’audit. Sans suivi, cette trace n’existe pas.

Ce qui est important : un suivi mensuel n’est pas un contrat captif. Si l’organisation préfère internaliser, je documente tout de manière à ce qu’elle puisse reprendre la main. Mon intérêt n’est pas de vendre du temps, c’est que l’installation reste utile et saine. Une IA locale qui dort dans un placard est une IA locale qui n’a servi à rien — ni sur le plan opérationnel, ni sur le plan de la conformité affichée.

Ce qui suit reflète ma pratique ; d’autres prestataires structureront leur suivi différemment. L’important est que ces questions soient traitées quelque part, par quelqu’un — pas qu’elles le soient par moi.

FAQ

On a installé Ollama et un modèle en interne. Pourquoi payer un suivi ?

Parce qu’Ollama publie plusieurs releases par semaine en moyenne et que plusieurs CVE critiques ont été rendues publiques sur Ollama comme sur llama.cpp en 2024 et 2026. Sans veille et sans procédure de mise à jour, l’installation dérive en quelques mois — c’est mécanique, pas catastrophiste.

Le suivi est-il obligatoire, ou peut-on s’en passer ?

Techniquement rien n’est obligatoire. Pratiquement, l’expérience montre qu’une installation locale non suivie finit par être délaissée, exposée à des failles connues, ou déconnectée des usages réels. Le suivi est un choix opérationnel, pas une dépendance.

Que se passe-t-il si on arrête le suivi après quelques mois ?

Rien ne casse dans l’instant. La dérive est lente : qualité qui baisse sans qu’on sache pourquoi, modèle devenu obsolète, faille connue non corrigée, port ouvert oublié. C’est typiquement 6 à 12 mois plus tard que les conséquences deviennent visibles — quand un audit, un incident ou un changement d’équipe force à reprendre l’installation à froid.

Le suivi inclut-il la mise à jour des modèles, ou seulement du logiciel ?

Les deux. Mettre à jour Ollama sans réévaluer le modèle qui tourne dessus, c’est risquer une régression silencieuse. Le suivi inclut la veille des sorties de modèles pertinents pour le cas d’usage, leur évaluation sur le jeu de tests de référence, et la bascule quand un modèle apporte vraiment quelque chose.

Est-ce qu’un finetuning ou un RAG change la donne sur le suivi ?

Au contraire, ça l’augmente. Un modèle fine-tuné doit être versionné, évalué, et son jeu d’entraînement doit rester reproductible. Un RAG doit être ré-indexé régulièrement, et son modèle d’embedding doit être géré comme une dépendance à part entière. Plus la couche métier est riche, plus le suivi est rentable.

Et si on préfère internaliser le suivi ?

C’est tout à fait possible, et c’est même souhaitable quand l’organisation a la compétence. Je documente l’ensemble de l’installation (Modelfiles, scripts de mise à jour, tests, procédures) pour qu’elle puisse être tenue à jour en interne. Mon rôle dans la durée, c’est d’apporter la veille et l’expérience de plusieurs installations, pas de verrouiller la machine.

---

Cet article décrit les enjeux types d’un suivi post-installation. Il ne décrit pas un client nommé et ne remplace ni un audit de sécurité, ni une analyse spécifique de votre installation.

Sources

• Ollama — Releases GitHub : https://github.com/ollama/ollama/releases
• ReleaseAlert — fréquence des releases Ollama : https://releasealert.dev/github/ollama/ollama
• Wiz Research — CVE-2024-37032 « Probllama » (RCE Ollama) : https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032
• Cyera Research — CVE-2026-7482 « Bleeding Llama » (CVSS 9.1, fuite mémoire non authentifiée) : https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama
• Oligo Security — série de vulnérabilités Ollama : https://www.oligo.security/blog/more-models-more-probllms
• GitHub Security Advisory — GHSA-3p4r-fq3f-q74v (heap overflow llama.cpp, mars 2026) : https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-3p4r-fq3f-q74v
• llama.cpp — page Security Advisories : https://github.com/ggml-org/llama.cpp/security/advisories/
• FuzzingLabs — instances Ollama exposées sur Internet (≈270 000) : https://fuzzinglabs.com/ollama-vulnerable-instances/
• Tian Pan — « Retrieval Debt : Why Your RAG Pipeline Degrades Silently Over Time » : https://tianpan.co/blog/2026/04/18/retrieval-debt-rag-pipeline-silent-degradation
• Documentation Ollama (site officiel) : https://ollama.com/