Maintenir et mettre à jour

Une machine qui tourne 24 h/24 et qui est joignable de l’extérieur n’est jamais « finie ». Elle vit, et comme tout ce qui vit, elle a besoin d’un peu d’entretien. La bonne nouvelle : 90 % se résume à deux réflexes, l’un automatique, l’autre mensuel. On va voir lesquels, et surtout comment mettre à jour sans rien casser.

L’OS : le système de base

Votre Ubuntu est la fondation. Deux niveaux d’entretien :

# Le geste de routine : rafraîchir la liste des paquets, puis installer les mises à jour
sudo apt update && sudo apt upgrade -y
# Faire le ménage des paquets devenus inutiles
sudo apt autoremove --purge

Pour la sécurité, vous avez déjà tout automatisé dans Réglages système avec unattended-upgrades : la machine applique seule les correctifs critiques. C’est le réflexe automatique dont on parlait.

Une fois tous les deux ans, une nouvelle version LTS d’Ubuntu sort. La dernière, Ubuntu 26.04, est sortie en avril 2026, et le passage depuis la 24.04 est ouvert depuis sa première version corrective, la 26.04.1 publiée fin août : Canonical attend toujours ce « .1 » avant de proposer la mise à niveau d’une LTS à l’autre. Rien d’urgent, la 24.04 reçoit ses correctifs de sécurité jusqu’en 2029. Le jour où vous vous lancez, sauvegardez d’abord (voir Git, GitHub & sauvegardes) et parcourez les notes de version.

# Termine d'abord les mises à jour en attente, redémarre si demandé
sudo apt update && sudo apt full-upgrade -y
# Puis lance la mise à niveau vers la LTS suivante (dans tmux si vous êtes en SSH)
sudo do-release-upgrade

Les dépendances : ce sur quoi vos projets reposent

C’est là que se cachent les surprises, parce qu’une dépendance qui change de version majeure peut casser un projet.

• Node (via nvm) : nvm install --lts installe la dernière LTS (Node 24 au 1er octobre 2026, Node 26 prévu en LTS le 28 octobre), nvm alias default la fixe par défaut. Gardez l’ancienne le temps de vérifier que vos projets tournent.
• Les paquets d’un projet : npm outdated montre ce qui est en retard, npm update met à jour dans les limites de votre package.json. Pour les versions majeures, lisez le changelog avant : c’est là que les ruptures arrivent.
• Le réflexe qui sauve : les lockfiles. Versionnez vos package-lock.json / requirements.txt. Ils garantissent que votre projet réinstalle exactement les mêmes versions, partout, et que rien ne bouge dans votre dos.

Les outils et les agents

Le reste de votre stack se met à jour proprement, chacun à sa façon :

• Docker : suit les mises à jour apt du système. Pensez à nettoyer ce qui s’accumule (voir plus bas).
• Ollama : relancez le script d’installation pour passer à la dernière version (curl -fsSL https://ollama.com/install.sh | sh). Et pour les modèles, un nouveau millésime se récupère avec ollama pull <modèle> : la version locale est remplacée. Pour repérer ceux qui valent la mise à jour, le classement des modèles locaux de Quelle IA est refait chaque semaine.
• Vos agents de code : Claude Code, installé par son script, se met à jour tout seul en arrière-plan, et claude update force la dernière version. OpenCode passe à la dernière avec opencode upgrade. Si vous aviez installé Claude Code avec npm, passez à l’installeur natif (curl -fsSL https://claude.ai/install.sh | bash), puis retirez l’ancienne copie avec npm uninstall -g @anthropic-ai/claude-code. Un agent à jour, c’est de nouvelles capacités gratuites.
• Tailscale et cloudflared : installés via leurs dépôts, ils se mettent à jour avec le système. Rien à faire de spécial.

L’espace disque : le piège silencieux

Les modèles, les images Docker et les vieux paquets remplissent un disque sans prévenir, et une machine pleine se met à planter de façon mystérieuse. Le ménage tient en trois commandes :

df -h                      # combien de place il reste
docker system prune -a     # vire images et conteneurs inutilisés
ollama rm <modèle>         # supprime un modèle que vous n'utilisez plus
sudo apt autoremove --purge # paquets orphelins

Savoir quand ça casse

Une machine qui travaille seule la nuit ne vous prévient que si vous l’avez programmée pour. Une panne coûte surtout par le temps qu’elle met à remonter jusqu’à vous. Les recommandations qui suivent viennent toutes d’incidents réels sur cette machine.

1. Un script qui en appelle un autre doit propager son code de retour

Le piège classique, et il est très répandu :

#!/bin/bash
set -uo pipefail
python3 import.py >> import.log 2>&1        # le code de retour part à la poubelle
systemctl --user restart mon-site || true   # dernière commande : renvoie toujours 0

Ce script rend toujours 0. L’import peut planter, systemd annonce un succès, et votre rapport hebdomadaire vous dit que tout va bien. C’est arrivé ici : une base est restée vide pendant une journée pendant que la sonde affichait vert.

La correction tient en deux lignes :

python3 import.py >> import.log 2>&1
rc=$?
systemctl --user restart mon-site || true
exit $rc

2. OnFailure : être prévenu à la seconde où ça tombe

systemd sait déclencher une unité quand une autre échoue. Vous écrivez un petit service qui vous envoie un message, et vous le branchez sur tout ce qui compte.

# ~/.config/systemd/user/mon-service.service.d/onfailure.conf
[Unit]
OnFailure=alerte@%n.service

Passez par un fichier de surcharge dans un dossier .d/ plutôt que d’éditer l’unité : ça marche même sur une unité liée depuis un dépôt, et le retrait consiste à supprimer un dossier.

3. Une sonde système, parce qu’aucune alerte d’unité ne voit la machine couler

Quand la RAM se remplit, aucune unité n’est « en échec ». C’est la machine elle-même qui se noie, et OnFailure ne peut rien voir. Il faut une sonde séparée, sur minuteur, qui regarde la mémoire disponible, les processus tués par le noyau, le swap et la charge, puis vous écrit au changement d’état pour ne pas répéter la même alerte toutes les cinq minutes.

Faites-vous aider par l’agent

C’est exactement le genre de corvée que votre agent adore. « Vérifie ce qui est à mettre à jour sur cette machine, résume-moi les changements importants, et propose un plan » : il liste les paquets en retard, lit les changelogs à votre place, et vous propose d’agir étape par étape. Vous gardez le doigt sur le bouton, lui fait le travail d’enquête.