Cours Ollama — modèles locaux et service local

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. distinguer Ollama exécuté sur sa machine de l'usage de modèles hébergés ;
2. repérer les différences d'installation, de stockage et de journaux entre macOS, Linux et Windows ;
3. inspecter les modèles présents et choisir une opération CLI selon son effet ;
4. expliquer le rôle d'un Modelfile et d'une API locale ;
5. repérer les risques liés aux téléchargements, aux données sensibles et à l'exposition réseau ;
6. commencer un diagnostic sans publier de journal ni modifier le système.

Prérequis

• Savoir ouvrir un terminal et lire une commande sans la lancer aveuglément.
• Connaître le système utilisé ; sur Linux, identifier sa distribution, la méthode d'installation et si Ollama tourne sous forme de service systemd.
• Comprendre que les modèles peuvent nécessiter plusieurs gigaoctets, voire des dizaines ou centaines de gigaoctets selon le modèle.
• Avoir accès aux documents officiels cités en fin de cours.
• Aucune connaissance d'un GPU particulier n'est supposée. Ollama peut utiliser le CPU ; le recours au GPU dépend du matériel, des pilotes et de la prise en charge documentée.

Parcours et chapitres

1. Comprendre le périmètre : local ou cloud

Ollama peut faire tourner un modèle sur un ordinateur ou servir d'interface vers des modèles cloud. Le fait qu'un client soit installé localement ne suffit donc pas à conclure qu'une requête donnée reste sur la machine : il faut aussi vérifier le modèle et le chemin API choisis.

La documentation d'Ollama déclare que ses modèles locaux ne lui transmettent pas les prompts et les données. Pour les modèles cloud, Ollama indique traiter les prompts et réponses pour rendre le service, sans les stocker ni les journaliser ni les employer à l'entraînement de ses modèles ; la FAQ signale aussi la collecte d'informations de compte et de métadonnées limitées d'usage. Ce sont des déclarations du fournisseur, pas une vérification indépendante. Ne jamais envoyer à un modèle cloud un secret, un ticket privé, un nom d'hôte ou des données d'infrastructure réelle sans autorisation et examen de confidentialité.

Un tag :cloud désigne un modèle hébergé dans Ollama cloud. Ces modèles n'ont pas besoin d'être téléchargés. Donc, ni le fait qu'une commande ne déclenche pas de téléchargement ni l'utilisation d'un client Ollama local ne prouve que le calcul reste local. Traiter explicitement tout modèle :cloud comme une requête distante.

L'API locale documentée écoute par défaut sur 127.0.0.1:11434 et ne demande pas d'authentification. Ne pas transformer cette écoute locale en accès réseau : une interface accessible au réseau sans contrôle d'accès adéquat pourrait permettre à d'autres clients d'utiliser le service et ses ressources.

2. Préparer l'installation par système

Consulter la page officielle du système avant d'installer ou de mettre à jour :

• macOS : Ollama demande macOS Sonoma 14 ou ultérieur. Le chemin conseillé est l'application téléchargée puis déposée dans Applications. Au premier lancement, l'application peut demander l'autorisation de créer le lien du CLI dans /usr/local/bin. Les Mac Apple Silicon disposent de la voie CPU/GPU Apple indiquée par Ollama ; les Mac x86 sont indiqués comme CPU seulement.
• Linux : la page Linux décrit un installateur, des archives manuelles et une configuration de service systemd. Elle ne fixe pas une version minimale universelle de distribution. Ces voies ne sont pas interchangeables : le service, ses droits et le stockage des modèles dépendent du mode retenu. Des étapes manuelles utilisent sudo.
• Windows : Ollama est une application native en arrière-plan. La documentation demande Windows 10 22H2 ou ultérieur, Home ou Pro. L'installateur par défaut agit dans le profil utilisateur et ne requiert pas le rôle Administrateur ; les binaires demandent au moins 4 Go, auxquels s'ajoute le stockage des modèles.

Sécurité et précautions :

• Une installation modifie le poste. Les pages officielles macOS et Windows donnent des parcours graphiques ; la page Linux documente aussi une commande curl | sh qui télécharge et exécute un script. Ce cours ne demande pas de l'exécuter. Avant toute installation Linux, lire la commande et le script source depuis le site officiel, confirmer la distribution, les privilèges, les fichiers modifiés et la stratégie de retour arrière.
• Ne pas lancer les exemples de désinstallation des pages officielles dans un exercice : ils suppriment l'application, les modèles ou des données locales.
• Prévoir l'espace disque du modèle avant de le récupérer. Les emplacements diffèrent selon l'OS et peuvent être personnalisés.

3. Distinguer release, application installée et documentation

Au 17 octobre 2026, le dépôt officiel publie v0.40.6 comme dernière release stable. La page de téléchargement propose les installations par plateforme, mais les références consultées ne donnent pas un numéro de version distinct pour chacun des installateurs.

Il faut donc distinguer :

• release vérifiée du projet : dernière release stable repérée lors de la vérification ;
• version installée : version effectivement présente sur un poste donné ;
• version documentée : périmètre des pages officielles consultées, qui peut évoluer sans correspondre à un binaire précis.

Sur la page Linux, ollama -v est donné pour vérifier la version après une installation manuelle et le lancement du serveur. Ne pas supposer que ce geste est identique dans toutes les voies GUI des autres systèmes ; vérifier la documentation correspondant à l'installation choisie.

4. Inspecter le CLI et comprendre les effets

La référence CLI documente notamment les opérations suivantes :

Les noms de modèles et tags sont propres à la bibliothèque Ollama et évoluent. N'en choisir aucun par supposition. Une commande run sur un modèle absent peut provoquer une récupération réseau ; la commande n'est pas un test hors ligne garanti. Un modèle :cloud est distant même s'il ne provoque aucun téléchargement.

ollama lsollama ps

• Contexte : Terminal de l'OS sur lequel Ollama est déjà installé ; aucun privilège administrateur attendu pour l'inspection CLI normale.
• Droits : utilisateur normal.
• Effet : lire la liste des modèles présents puis l'état du service. Ne lancer ces commandes que si Ollama est déjà installé et que le service est disponible ; sinon, arrêter l'exercice.
• Vérification : ollama ls montre les modèles présents ; ollama ps montre les modèles actuellement chargés, s'il y en a.
• Retour arrière : sans objet (lecture seule).
• Arrêt : ne pas poursuivre avec pull, run, stop ou rm sans avoir expliqué et accepté leur effet.

5. Modèles, matériel et ressources

Un modèle peut occuper une grande quantité d'espace disque et de mémoire. L'accélération GPU varie par OS, matériel, pilote et bibliothèque : la documentation distingue notamment les voies Apple, NVIDIA et AMD/ROCm, et fournit une matrice qui évolue. Vérifier la page officielle GPU au moment d'installer ou diagnostiquer un matériel ; ce cours ne garantit ni compatibilité ni performance.

ollama ps fournit un état de modèles chargés ; la FAQ décrit également la colonne processeur de cette sortie pour distinguer CPU, GPU ou utilisation partagée, lorsque cette information est fournie par le système.

6. Personnaliser un modèle avec un Modelfile

Un Modelfile décrit un modèle dérivé. FROM sélectionne le modèle de base ; SYSTEM définit un message système ; PARAMETER peut régler des paramètres pris en charge par le modèle. Les modèles peuvent aussi avoir un template et des capacités particulières. Consulter la référence pour la syntaxe à jour.

Exemple de fichier à lire et discuter, sans le construire :

FROM <nom-d'un-modele-deja-present>
SYSTEM Réponds en français et signale les incertitudes.

La création documentée utilise le nom de sortie et un chemin vers le fichier :

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

ollama create cours-demo -f Modelfile

• Contexte : terminal, dans le dossier contenant Modelfile ; aucun privilège administrateur attendu.
• Droits : utilisateur normal, droit d'écriture sur le stockage des modèles.
• Effet : crée un nouveau modèle local et consomme du stockage ; la base doit déjà exister localement pour éviter une récupération inattendue.
• Vérification : la commande réussit ; ollama ls montre ensuite le nom créé.
• Retour arrière : supprimer le modèle créé avec ollama rm cours-demo (commande destructive, nom à relire).
• Précaution : exercice facultatif uniquement après accord, confirmation que la base est locale et vérification de l'espace disque. Il n'est pas nécessaire au parcours principal.

7. API locale, sans exposer le service

Ollama documente l'API locale à http://localhost:11434/api et une compatibilité OpenAI sur http://localhost:11434/v1. Ces URL sont locales à la machine. Les requêtes cloud vers ollama.com sont différentes, nécessitent une clé et transmettent les données au service distant.

Exemple optionnel de requête à l'API locale :

curl --max-time 120 http://localhost:11434/api/generate \  -H 'Content-Type: application/json' \  -d '{"model":"<nom-local-vérifié>","prompt":"Explique les limites d’un exemple pédagogique.","stream":false}'

• Contexte : macOS ou Linux avec curl ; l'équivalent PowerShell est documenté par Ollama pour Windows. Le serveur local doit déjà tourner, et le nom doit avoir été confirmé comme modèle local présent.
• Droits : utilisateur normal ; aucune clé d'API pour l'API locale.
• Effet : envoie un prompt au serveur local et affiche sa réponse ; la génération utilise du CPU/GPU et peut prendre du temps.
• Vérification : réponse JSON du serveur local ; confirmer que le modèle n'est pas un modèle/tag :cloud. Une adresse localhost ne suffit pas à prouver que le modèle appelé est local. En cas d'erreur de connexion ou de modèle absent, arrêter plutôt que basculer vers le cloud.
• Retour arrière : sans objet (aucune modification ; le modèle reste chargé en mémoire un temps, ollama ps).
• Limite : ne pas exécuter si l'exercice requiert la confidentialité d'une donnée réelle ; employer seulement le prompt synthétique montré.

Ne jamais publier l'API sur le réseau pour suivre ce cours. Ne pas placer de clé cloud dans le navigateur, un dépôt Git, une URL ou un journal.

8. Configuration, stockage et confidentialité

La FAQ documente notamment :

• OLLAMA_HOST pour l'adresse d'écoute ;
• OLLAMA_MODELS pour déplacer le répertoire des modèles ;
• OLLAMA_NO_CLOUD=1 ou disable_ollama_cloud dans ~/.ollama/server.json pour désactiver les fonctions cloud.

Les méthodes de configuration varient selon le mode d'exécution :

• application macOS : variables définies par launchctl, puis redémarrage de l'application ;
• service Linux systemd : surcharge de l'unité par l'outil documenté, puis rechargement/redémarrage du service ; cela requiert normalement les droits d'administration ;
• application Windows : variables d'environnement de l'utilisateur, puis quitter et relancer l'application.

Ne pas modifier l'adresse d'écoute, l'emplacement des modèles ou la configuration cloud dans les exercices. Relever les valeurs existantes ne doit pas conduire à publier des chemins ou données personnelles.

9. Journaux et dépannage initial

Emplacements documentés :

• macOS : ~/.ollama/logs, avec notamment le journal du serveur ;
• Linux avec systemd : journaux de l'unité ollama, consultables avec journalctl ;
• Windows : %LOCALAPPDATA%\Ollama ; modèles et configuration se trouvent séparément sous %HOMEPATH%\.ollama.

Un journal peut contenir des chemins, noms de compte, erreurs ou informations sur les modèles. Le garder local, ne pas le verser dans MyITLibrary et ne pas le transmettre sans examiner et anonymiser son contenu.

10. Mise à jour et cycle de vérification

La FAQ indique la mise à jour GUI sur macOS/Windows et la réexécution de l'installateur officiel sur Linux. Une mise à jour modifie des binaires ; le cours ne l'exécute pas automatiquement. Avant de l'appliquer, confirmer OS, méthode d'installation, sauvegarde des configurations utiles, release cible et procédure de retour arrière.

Les liens et détails sont ceux consultés le 17 octobre 2026. Avant de réutiliser une commande dépendante d'une version :

1. ouvrir les pages officielles de l'OS et du sujet ;
2. vérifier la date de la dernière release et l'état de la documentation ;
3. distinguer cette release de la version installée ;
4. noter le changement pertinent et conserver la fiche en brouillon jusqu'à revalidation.

Exercices et vérifications de fin de cours

Les exercices 1 à 4 sont en lecture seule ou papier et ne requièrent pas de téléchargement.

1. Distinguer les services. Classer trois scénarios synthétiques : modèle local sur loopback, modèle cloud via Ollama local, API cloud directe. Pour chacun, identifier où la requête va et quelle documentation le justifie.
2. Cartographier une installation. Remplir un tableau des exigences, répertoires, méthodes d'installation et journaux pour les trois OS, en consultant les pages officielles.
3. Classer les commandes. Pour chaque commande de la section 4, marquer lecture seule, réseau, arrêt ou suppression ; justifier pourquoi ollama run ne doit être lancé qu'avec un modèle déjà présent et vérifié.
4. Lire un Modelfile. Annoter FROM, SYSTEM et PARAMETER sur l'exemple officiel ; ne pas créer de modèle.
5. API locale facultative. Si l'instance Ollama est déjà disponible, qu'un modèle local est confirmé et que Stéphane autorise l'exécution, lancer la requête synthétique de la section 7. Vérifier qu'elle vise localhost, que le modèle local est téléchargé et ne porte pas le tag :cloud, et que les fonctions cloud sont désactivées si une garantie locale stricte est nécessaire. Sinon, décrire le contrôle sans exécuter la requête.
6. Configuration sans changement. Pour chaque OS, indiquer la méthode officielle qui serait utilisée pour désactiver les fonctions cloud, sans modifier la configuration de la machine.

Critères de réussite

• Décrire sans confusion la différence entre modèle local et cloud.
• Identifier les commandes qui téléchargent, modifient ou suppriment.
• Expliquer pourquoi loopback n'est pas la même chose qu'une écoute réseau.
• Donner les emplacements de modèles et journaux propres à l'OS à partir des pages officielles.
• Citer la release vérifiée et sa date sans la confondre avec une version installée.