Retour de version Ollama en pratique : 3 étapes clés ignorées par 90 % des développeurs

Vous cliquez sur la notification de mise à jour Ollama, version 0.6.8 — la latence API passe de 200 ms à 5 secondes, la mémoire double, et même ollama run llama3.2 se fige. Sur GitHub Issue #10652, des dizaines d’utilisateurs se plaignent : « Après la mise à jour, le système est inutilisable, et l’officiel ne propose pas le téléchargement des anciennes versions. »

La réponse officielle est claire : seule la dernière version est supportée, le retour de version n’est pas prévu pour l’instant.

Ce piège fait si mal qu’une sauvegarde complète précède désormais chaque mise à jour. Cet article partage trois méthodes de retour (binaire, gestionnaire de paquets, Docker), des scripts d’automatisation, la configuration multi-versions, et tous les pièges rencontrés.

Pourquoi un retour de version ? Analyse des cas réels

Mettre à jour un logiciel devrait être une bonne nouvelle — nouvelles fonctions, performances, corrections de bugs. Mais une mise à jour Ollama peut parfois ressembler à une mauvaise « surprise ».

Trois risques : performance, compatibilité, stabilité

Les trois situations les plus fréquentes :

Chute soudaine des performances. Des utilisateurs signalent qu’après une mise à jour, la vitesse d’inférence passe de 50 tokens/s à moins de 10. La mémoire double sans raison apparente : un modèle de 4 Go en consomme soudain 8. Votre application ralentit, l’utilisateur attend une demi-minute pour une réponse — personne ne supporte ça.

Incompatibilité API. Plus insidieux. Vous mettez à jour Ollama sans toucher au code, et les appels API échouent. Nom de paramètre modifié, format de réponse changé, ou endpoint supprimé. Sur un projet, après mise à jour, le paramètre timeout de api/generate a cessé de fonctionner, interrompant toutes les tâches longues. Le comportement par défaut avait changé dans la nouvelle version.

Instabilité système. Le pire. Redémarrages intempestifs, échec de chargement des modèles, logs illisibles. Une fois, le service Ollama quittait toutes les demi-heures, repartait un moment, puis replantait. Deux jours de débogage pour identifier une fuite mémoire dans la nouvelle version.

GitHub Issue #10652 : la voix des utilisateurs

Cette issue, créée le 2025-05-10, compte déjà plus de 100 participants. Titre direct : « Ability to downgrade » (possibilité de rétrograder).

La description du créateur : « Après la mise à jour vers 0.6.8, le système est quasi inutilisable. Inférence trop lente, timeouts API fréquents. J’ai essayé toutes les configurations, rien n’y fait. Je veux revenir à la version précédente, mais l’officiel ne propose que la dernière. »

Un commentaire est encore plus direct : « Trois jours à chercher le problème — c’était un bug connu de la nouvelle version. L’officiel ne l’a pas corrigé. Deux semaines d’attente, bug toujours là. Mon projet est bloqué. »

Ce n’est pas un cas isolé. Reddit et les forums regorgent de témoignages similaires. Certains ont suspendu le développement ; d’autres figent une ancienne version par peur.

Limites officielles : dernière version uniquement

La page de téléchargement Ollama n’affiche que la dernière version. GitHub Releases contient l’historique, mais la doc officielle n’explique pas le retour. Homebrew et APT installent aussi la dernière par défaut.

« Ne pas mettre à jour, alors ? » Parfois la mise à jour est imposée : dépendances système, autre outil, ou clic accidentel (mon cas). Quand le problème apparaît, il est souvent trop tard.

Même avec l’ancien installateur, le retour comporte des risques : perte de modèles ? conflit de config ? service qui ne démarre pas ?

Maîtriser un retour de version fiable peut vraiment sauver la mise. Voyons trois méthodes principales en détail.

Retour de version en pratique : trois méthodes comparées

En bref : chaque méthode a ses forces ; le choix dépend de votre déploiement et de votre budget temps.

Comparaison : durée, difficulté, cas d’usage

Personnellement, Docker est le plus serein. Sans conteneurs, le remplacement binaire reste rapide. Détail de chaque méthode ci-dessous.

Méthode 1 : remplacement binaire (le plus rapide, manuel)

Remplace directement l’exécutable Ollama. Avantage : rapidité. Inconvénient : sauvegarde et validation à votre charge.

Étape 1 : arrêter le service

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

# macOS/Linux
ollama stop
# Si la commande ci-dessus ne suffit pas
sudo systemctl stop ollama  # Linux
# ou tuer le processus
pkill -9 ollama

Si le service ne s’arrête pas, vérifiez les processus résiduels :

ps aux | grep ollama
lsof -i :11434  # occupation du port

Étape 2 : sauvegarder l’installation actuelle

Ne sautez surtout pas cette étape. Sans sauvegarde, un échec de retour peut être catastrophique.

# Sauvegarde du binaire
sudo cp /usr/local/bin/ollama ~/ollama-backup-current

# Sauvegarde config et modèles (répertoire potentiellement énorme)
# ~/.ollama peut contenir des dizaines de Go
cp -r ~/.ollama ~/.ollama-backup-$(date +%Y%m%d)

Vérifiez la taille avant sauvegarde. Une fois, ~/.ollama faisait plus de 40 Go — nettoyage urgent des anciens modèles.

du -sh ~/.ollama  # taille
# Si trop gros, supprimez les modèles inutilisés
ollama list
ollama rm unused-model-name

Étape 3 : télécharger la version cible

Sur GitHub Releases :

# Page GitHub Releases
https://github.com/ollama/ollama/releases

# Exemple : version 0.1.30
# macOS (Intel)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin -o ollama-v0.1.30

# macOS (Apple Silicon)
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-darwin-arm64 -o ollama-v0.1.30

# Linux
curl -L https://github.com/ollama/ollama/releases/download/v0.1.30/ollama-linux-amd64 -o ollama-v0.1.30

Attention au nom de fichier selon l’OS. Un mauvais binaire provoque des erreurs immédiates.

Étape 4 : remplacer le binaire

chmod +x ollama-v0.1.30
sudo mv ollama-v0.1.30 /usr/local/bin/ollama

# En cas de problème de permissions
sudo rm /usr/local/bin/ollama
sudo cp ollama-v0.1.30 /usr/local/bin/ollama
sudo chmod +x /usr/local/bin/ollama

Étape 5 : valider le retour

ollama --version
# Attendu : ollama version 0.1.30 (ou votre version cible)

ollama serve

curl http://localhost:11434/api/version
# Attendu : {"version":"0.1.30"}

ollama run llama3.2 "Hello, test"

Si version, API et inférence sont OK, c’est gagné. Sinon, restaurez :

sudo mv ~/ollama-backup-current /usr/local/bin/ollama
ollama serve

Méthode 2 : gestionnaire de paquets (stable, Homebrew/APT)

Avec Homebrew (macOS) ou APT (Ubuntu), le gestionnaire gère versions et dépendances.

Homebrew (macOS)

brew uninstall ollama

# Installer une version précise (ex. 0.1.30)
brew search ollama

brew install [email protected]  # si disponible

brew pin ollama

ollama --version

Homebrew gère mal parfois les anciennes versions — elles manquent dans le dépôt. Passez alors à la méthode 1.

APT (Ubuntu/Debian)

apt-cache policy ollama

sudo apt-get install ollama=0.1.30-1

sudo apt-mark hold ollama

ollama --version

APT conserve souvent plusieurs versions — plus fiable que Homebrew.

Méthode 3 : conteneur Docker (le plus sûr, isolation totale)

Avec Docker, le retour consiste à changer l’image.

Tirer une image versionnée

docker ps | grep ollama

docker stop ollama-container
docker rm ollama-container

docker pull ollama/ollama:0.1.30

docker run -d \
  --name ollama-container \
  -v ~/.ollama:/root/.ollama \
  -p 11434:11434 \
  ollama/ollama:0.1.30

docker exec ollama-container ollama --version

Verrouiller la version avec docker-compose

Modifiez docker-compose.yml :

services:
  ollama:
    image: ollama/ollama:0.1.30  # version figée, pas latest
    volumes:
      - ~/.ollama:/root/.ollama
    ports:
      - "11434:11434"

Puis redéployez :

docker-compose down
docker-compose up -d

Les modèles restent dans ~/.ollama sur l’hôte ; changer de conteneur ne touche pas aux données. Vous pouvez même exécuter plusieurs versions Ollama en parallèle (voir plus bas).

Scripts de retour automatisé et contrôle de santé

Le retour manuel fonctionne, mais répéter les commandes invite aux erreurs. Voici une suite de scripts pour retour, validation et surveillance.

Script de retour en un clic (ollama-rollback.sh)

Arrêt, sauvegarde, téléchargement, remplacement, validation — avec restauration automatique en cas d’échec.

#!/bin/bash
# ollama-rollback.sh - Script de retour de version Ollama en un clic
# Usage: ./ollama-rollback.sh <numéro de version cible>

TARGET_VERSION=$1
BACKUP_DIR=~/.ollama-backups
OLLAMA_BIN=/usr/local/bin/ollama

if [ -z "$TARGET_VERSION" ]; then
  echo "Erreur: veuillez spécifier la version cible"
  echo "Usage: ./ollama-rollback.sh <version>"
  exit 1
fi

echo "=== Début du retour Ollama vers la version $TARGET_VERSION ==="

# Étape 1: arrêter le service
echo "[1/5] Arrêt du service Ollama..."
ollama stop || pkill -9 ollama
sleep 2

# Étape 2: sauvegarder
BACKUP_NAME="ollama-backup-$(date +%Y%m%d-%H%M%S)"
echo "[2/5] Sauvegarde vers $BACKUP_DIR/$BACKUP_NAME..."
mkdir -p $BACKUP_DIR
cp $OLLAMA_BIN $BACKUP_DIR/$BACKUP_NAME/ollama-bin
cp -r ~/.ollama $BACKUP_DIR/$BACKUP_NAME/ollama-data

# Étape 3: télécharger
echo "[3/5] Téléchargement Ollama $TARGET_VERSION..."
OS_TYPE=$(uname -s)
ARCH=$(uname -m)

if [ "$OS_TYPE" = "Darwin" ]; then
  if [ "$ARCH" = "arm64" ]; then
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin-arm64"
  else
    DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-darwin"
  fi
else
  DOWNLOAD_URL="https://github.com/ollama/ollama/releases/download/v${TARGET_VERSION}/ollama-linux-${ARCH}"
fi

curl -L $DOWNLOAD_URL -o /tmp/ollama-$TARGET_VERSION || {
  echo "Échec du téléchargement! Restauration..."
  cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  exit 1
}

# Étape 4: remplacer
echo "[4/5] Remplacement du binaire..."
chmod +x /tmp/ollama-$TARGET_VERSION
sudo mv /tmp/ollama-$TARGET_VERSION $OLLAMA_BIN

# Étape 5: valider
echo "[5/5] Validation..."
ollama serve
sleep 3

INSTALLED_VERSION=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ "$INSTALLED_VERSION" = "$TARGET_VERSION" ]; then
  echo "✓ Retour réussi! Version actuelle: $INSTALLED_VERSION"
  echo "Sauvegarde: $BACKUP_DIR/$BACKUP_NAME"
else
  echo "✗ Échec de validation! Restauration..."
  sudo cp $BACKUP_DIR/$BACKUP_NAME/ollama-bin $OLLAMA_BIN
  ollama serve
  exit 1
fi

Utilisation :

chmod +x ollama-rollback.sh
./ollama-rollback.sh 0.1.30

Le script affiche la progression à chaque étape. Échec de téléchargement ou mauvaise version → restauration automatique.

Script de contrôle de santé (health-check.sh)

Après retour, la version seule ne suffit pas — vérifiez que le service tourne vraiment. Quatre dimensions : version, service, API, modèle.

#!/bin/bash
# health-check.sh - Contrôle de santé du service Ollama

echo "=== Contrôle de santé Ollama ==="

# 1. Version
VERSION=$(ollama --version 2>&1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$VERSION" ]; then
  echo "✓ Version: $VERSION"
else
  echo "✗ Échec vérification version"
  exit 1
fi

# 2. État du service
SERVICE_PID=$(pgrep -f "ollama serve")
if [ -n "$SERVICE_PID" ]; then
  echo "✓ Service actif (PID: $SERVICE_PID)"
else
  echo "✗ Service arrêté"
  ollama serve
  sleep 3
fi

# 3. Réponse API
API_RESPONSE=$(curl -s -w "%{http_code}" http://localhost:11434/api/version -o /tmp/api-test.json)
if [ "$API_RESPONSE" = "200" ]; then
  echo "✓ API OK"
else
  echo "✗ API anormale (HTTP $API_RESPONSE)"
  exit 1
fi

# 4. Test modèle
TEST_MODEL=$(ollama list | head -2 | tail -1 | awk '{print $1}')
if [ -z "$TEST_MODEL" ]; then
  echo "⚠ Aucun modèle installé"
else
  echo "Modèle testé: $TEST_MODEL"
  ollama run $TEST_MODEL "Say hello" --verbose > /tmp/model-test.log 2>&1
  if grep -q "hello" /tmp/model-test.log; then
    echo "✓ Inférence OK"
  else
    echo "✗ Échec inférence"
    cat /tmp/model-test.log
    exit 1
  fi
fi

echo ""
echo "=== Contrôle terminé ==="

Sortie typique :

=== Contrôle de santé Ollama ===
✓ Version: 0.1.30
✓ Service actif (PID: 12345)
✓ API OK
Modèle testé: llama3.2:latest
✓ Inférence OK

=== Contrôle terminé ===

Toute anomalie arrête le script et aide au diagnostic.

Script de comparaison de performance

Comparez les performances avant/après retour : latence et mémoire.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

#!/bin/bash
# performance-check.sh - Benchmark de performance

echo "=== Test de performance ==="

echo "Test latence API..."
START=$(date +%s%N)
curl -X POST http://localhost:11434/api/generate \
  -d '{"model":"llama3.2","prompt":"Hello","stream":false}' \
  -H "Content-Type: application/json" > /tmp/perf-test.json 2>&1
END=$(date +%s%N)
RESPONSE_TIME=$((($END - $START) / 1000000))

echo "Latence API: ${RESPONSE_TIME}ms"

MEMORY_USAGE=$(ps aux | grep ollama | grep -v grep | awk '{print $4}')
MEMORY_MB=$(ps aux | grep ollama | grep -v grep | awk '{print $6}')

echo "Mémoire: ${MEMORY_USAGE}% (${MEMORY_MB}KB)"

echo "$(date): version=$(ollama --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'), réponse=${RESPONSE_TIME}ms, mémoire=${MEMORY_MB}KB" >> ~/.ollama-performance.log

echo ""
echo "Données enregistrées dans ~/.ollama-performance.log"
echo "Comparez avant/après retour pour confirmer la reprise des performances"

Après un retour, la latence est passée de 5000 ms à 200 ms et la mémoire de 80 % à 35 % — preuve concrète que le retour a fonctionné.

Ces scripts sont disponibles sur GitHub. Combinés à la coexistence multi-versions, la gestion des versions peut être largement automatisée.

Coexistence multi-versions : configuration et stratégie

Parfois vous devez exécuter plusieurs versions de modèles : environnement de dev sur une version de test, production sur une version stable. Ollama ne le permet pas nativement, mais on peut contourner.

Trois approches comparées

Approche 1 : tags pour distinguer les versions

Ollama permet de taguer les modèles :

ollama create myproject-llama3.2:v1.0 -f Modelfile-v1.0
ollama create myproject-llama3.2:v2.0 -f Modelfile-v2.0

ollama list
# Exemple :
# myproject-llama3.2:v1.0    4.7 GB   2026-05-10
# myproject-llama3.2:v2.0    4.7 GB   2026-05-14

ollama run myproject-llama3.2:v1.0 "votre prompt"
ollama run myproject-llama3.2:v2.0 "votre prompt"

Limite : une seule version chargée à la fois. Pour du parallèle, utilisez les approches suivantes.

Approche 2 : instances multiples (ports différents)

Chaque instance écoute sur un port distinct :

ollama serve

OLLAMA_HOST=0.0.0.0:11435 ollama serve &

curl http://localhost:11434/api/version
curl http://localhost:11435/api/version

curl http://localhost:11435/api/generate \
  -d '{"model":"llama3.2","prompt":"test"}'

Flexible, mais la mémoire double si chaque instance charge un gros modèle. Gestion manuelle des ports par version.

Approche 3 : conteneurs Docker multiples

Pour une vraie isolation, Docker est le plus fiable :

# docker-compose.yml
version: '3'
services:
  ollama-stable:
    image: ollama/ollama:0.1.30
    container_name: ollama-stable
    volumes:
      - ./data-stable:/root/.ollama
    ports:
      - "11434:11434"

  ollama-dev:
    image: ollama/ollama:0.6.8
    container_name: ollama-dev
    volumes:
      - ./data-dev:/root/.ollama
    ports:
      - "11435:11434"

Déploiement :

docker-compose up -d
docker-compose ps

curl http://localhost:11434/api/version  # stable (0.1.30)
curl http://localhost:11435/api/version  # dev (0.6.8)

Répertoires data-stable et data-dev séparés — modèles indépendants. Llama3.2 dans un conteneur, Mistral dans l’autre, sans conflit.

Stratégie de gestion : nommage, verrouillage, nettoyage

Sans discipline, les modèles s’accumulent et le disque explose.

Convention de nommage :

myproject-llama3.2:prod-v1.0
myproject-llama3.2:dev-v2.0
myproject-mistral:test-v0.1

# À éviter
test-model-1
test-model-2

Verrouillage de version :

brew pin ollama
sudo apt-mark hold ollama

image: ollama/ollama:0.1.30
# Évitez image: ollama/ollama:latest

Nettoyage régulier :

ollama list

ollama rm myproject-llama3.2:test-v0.5
ollama rm myproject-llama3.2:dev-v1.2

for model in $(ollama list | grep "test-" | awk '{print $1}'); do
  ollama rm $model
done

Issues GitHub : limites officielles et contournements

Les issues #2109 et #11196 discutent de la non-prise en charge native. Position officielle : un processus Ollama ne charge qu’une instance de modèle à la fois. Multi-version = tags, ou plusieurs processus/conteneurs.

Un commentaire résume bien : « La limite officielle complique la gestion, mais les contournements communautaires marchent. Docker multi-conteneurs est le plus sûr — un peu plus de config, isolation réelle. »

En production, Docker multi-conteneurs reste mon choix : stabilité et isolation maximales.

Dépannage et bonnes pratiques

Quelques pièges reviennent souvent. Voici un guide de dépannage.

Problèmes courants

Permissions

Le plus fréquent après remplacement du binaire : oubli des droits d’exécution.

# Symptôme : "Permission denied"
sudo chmod +x /usr/local/bin/ollama

sudo chown -R $(whoami) ~/.ollama

Un premier retour bloqué ici : fichier remplacé mais sans chmod +x sur le téléchargement curl.

Échec de démarrage

Port occupé ou processus résiduel :

# Symptôme : "Address already in use"
lsof -i :11434
kill -9 <PID>
sudo systemctl restart ollama  # Linux

Parfois l’ancien processus tourne encore en arrière-plan. pkill -9 ollama puis redémarrage.

Erreur de chargement de modèle

Fichier corrompu ou incompatibilité de version :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

ollama show model-name
ollama pull model-name --force

ollama rm model-name
ollama pull model-name

Un modèle a échoué après retour — fichier modifié par accident. Re-téléchargement nécessaire. D’où l’importance de sauvegarder ~/.ollama.

Conflit de configuration

Paramètres de la nouvelle version incompatibles avec l’ancien binaire :

rm ~/.ollama/ollama.db
ollama serve

ollama pull model-name

Config avec paramètres que l’ancienne version ne parse pas → crash. Supprimer ollama.db et régénérer règle souvent le cas.

Quatre règles d’or

Règle 1 : figer la version

Avant toute mise à jour, verrouillez la version actuelle pour savoir où revenir.

brew pin ollama
sudo apt-mark hold ollama
image: ollama/ollama:0.1.30

Règle 2 : tester avant la production

Testez le retour en dev avec health-check.sh avant la prod.

./ollama-rollback.sh 0.1.30
./health-check.sh
./performance-check.sh

Règle 3 : documenter chaque retour

Notez date, versions, motif, résultat.

echo "Retour: $(date) - de 0.6.8 vers 0.1.30, motif: chute de performance" >> ~/.ollama-rollback-log.txt

cat >> ~/.ollama-rollback-log.txt << EOF
Date : 2026-05-14
Version source : 0.6.8
Version cible : 0.1.30
Motif : latence API de 200 ms à 5000 ms après mise à jour
Résultat : succès, retour à 200 ms
Note : sauvegarde ~/.ollama-backups/ollama-backup-20260514
EOF

Règle 4 : sauvegardes régulières

Sauvegardez ~/.ollama régulièrement — volumineux mais vital.

cp ~/.ollama/ollama.db ~/.ollama-backup.db

tar -czf ~/.ollama-backup-$(date +%Y%m%d).tar.gz ~/.ollama

ls -t ~/.ollama-backup-*.tar.gz | tail -n +6 | xargs rm -f

Outils recommandés

• ollama-rollback.sh : retour en un clic, restauration auto
• health-check.sh : contrôle sur quatre dimensions
• cleanup_models.sh : nettoyage batch (voir Partie 2)

Avec ces scripts, la gestion des versions devient quasi automatique.

Conclusion

L’essentiel tient en trois étapes : sauvegarder, revenir, valider.

La sauvegarde est la plus ignorée — et la plus critique. Sauvegarder ~/.ollama avant retour a déjà évité une journée entière de reconfiguration.

La méthode dépend du déploiement : Docker (changement d’image), installation manuelle (binaire). Suivez les étapes dans l’ordre.

Ne sautez pas la validation : health-check.sh pour version, service, API et modèle. Une bonne version affichée ne garantit pas un service sain.

Trois actions immédiates :

1. Testez le retour en dev — téléchargez les scripts, lancez health-check.sh. Ne attendez pas la panne.

2. Conservez les trois scripts — ollama-rollback.sh, health-check.sh, performance-check.sh.

3. Verrouillez votre version stable — brew pin, apt-mark hold, ou tag Docker. Évitez les mises à jour accidentelles.

La gestion des versions semble secondaire — jusqu’au jour où elle bloque tout le projet. Maîtriser ce flux évite la panique.

Cet article est la Partie 3 de la série Ollama LLM local. Partie 1 : bases. Partie 2 : gestion des modèles. Ici : retour de version et coexistence. Partie 4 : réglage Modelfile pour plus de vitesse, stabilité et économie.

Si cet article vous a été utile, partagez-le. Questions en commentaire — j’y répondrai autant que possible.