Une autre approche consiste à installer Whisper AI directement sur son propre serveur. Le traitement peut alors être réalisé localement, sans transmettre les enregistrements à une API de transcription externe. Avec un VPS, il devient ainsi possible de mettre en place une solution de transcription audio open source, automatisable et entièrement contrôlée depuis son environnement Linux.

Objectif

Dans ce tutoriel, nous allons voir comment installer Whisper AI sur un VPS et l’utiliser pour transformer automatiquement des fichiers audio ou vidéo en texte. Whisper est un modèle de reconnaissance automatique de la parole, ou ASR (Automatic Speech Recognition), publié par OpenAI sous licence MIT. Nous nous concentrerons sur deux implémentations particulièrement intéressantes pour un serveur fonctionnant principalement avec son processeur : faster-whisper, basé sur CTranslate2, et whisper.cpp, une implémentation C/C++ légère pouvant fonctionner sans environnement Python. À la fin du tutoriel, votre VPS KVM LWS pourra transcrire un fichier en français, produire une transcription texte et générer des sous-titres SRT. Nous verrons également comment traiter plusieurs fichiers automatiquement et surveiller les ressources consommées pendant l’inférence.

Pré-requis

Avant de commencer l’installation de Whisper AI sur votre VPS, assurez-vous de disposer des éléments suivants :

• un VPS KVM LWS sous Ubuntu 22.04/24.04 ou Debian avec un accès administrateur via SSH ;
• au moins 4 Go de RAM pour commencer confortablement avec des modèles légers ou intermédiaires ; davantage de mémoire est conseillé pour les modèles les plus volumineux ;
• une installation fonctionnelle de Python 3 si vous choisissez faster-whisper. À la date où nous rédigeons ce tutoriel, la documentation officielle de faster-whisper exige Python 3.9 ou supérieur.
• l’outil ffmpeg, notamment utile pour convertir les fichiers audio avant leur traitement avec whisper.cpp ;
• quelques connaissances de base des commandes Linux : connexion SSH, navigation entre les répertoires et installation de paquets.

Les VPS utilisés dans ce tutoriel ne nécessitent pas de GPU dédié. Nous privilégierons des configurations adaptées à l’inférence CPU et éviterons de reprendre des performances mesurées sur GPU comme référence pour un VPS.

Qu’est-ce que Whisper : présentation factuelle

Whisper est un système de reconnaissance automatique de la parole développé par OpenAI et publié en open source en septembre 2022. Il repose sur une architecture Transformer capable d’effectuer plusieurs tâches liées au traitement de la voix, notamment la transcription multilingue, l’identification de la langue et la traduction de la parole vers l’anglais. Le modèle original a été entraîné sur 680 000 heures de données audio et de transcriptions collectées sur Internet.

Le code de référence est distribué sous licence MIT, ce qui permet notamment une utilisation commerciale. Lorsqu’il est exécuté localement, Whisper ne nécessite pas de facturation à la minute : le coût correspond principalement aux ressources du serveur utilisé pour effectuer les calculs.

Pour une entreprise ou un créateur de contenu, l’auto-hébergement présente également un intérêt important : le fichier audio peut être traité directement sur le VPS, sans être envoyé à une API de transcription tierce.

Quels modèles Whisper sont disponibles ?

Le dépôt officiel d’OpenAI référence actuellement six tailles principales : tiny, base, small, medium, large et turbo. Le choix du modèle influence directement la consommation de ressources et la qualité attendue de la transcription. OpenAI précise également que les vitesses relatives publiées dans sa documentation ont été mesurées sur GPU A100 : elles ne doivent donc pas être transposées à un VPS fonctionnant uniquement sur CPU.

Les valeurs de mémoire indiquées proviennent de la documentation actuelle de whisper.cpp pour ses modèles GGML et ne doivent pas être assimilées aux besoins exacts de faster-whisper ou de l’implémentation PyTorch officielle.

Le modèle turbo est une version optimisée de large-v3 utilisant 809 millions de paramètres. OpenAI le présente comme plus rapide tout en limitant la dégradation de précision par rapport à large-v3. Il est toujours référencé dans le dépôt officiel en août 2026, et aucune annonce officielle d’un modèle « Whisper v4 » n’apparaît actuellement dans les annonces du projet.

Dans un contexte VPS sans GPU, la taille du modèle n’est cependant qu’une partie de l’équation. Le runtime utilisé pour exécuter Whisper joue lui aussi un rôle déterminant. C’est précisément ce que nous allons comparer dans la section suivante.

Choisir le bon runtime pour un VPS sans GPU

Installer Whisper AI ne consiste pas seulement à choisir un modèle comme small, medium ou turbo. Il faut également sélectionner le runtime, c’est-à-dire l’implémentation qui chargera le modèle et réalisera concrètement la transcription.

Sur un VPS sans GPU dédié, ce choix est particulièrement important. Les trois principales solutions n’ont pas les mêmes dépendances ni les mêmes besoins.

L’implémentation officielle openai-whisper repose notamment sur Python et PyTorch. Elle reste utile comme version de référence, mais nous utiliserons plutôt des runtimes spécifiquement intéressants pour un environnement serveur fonctionnant sur CPU.

faster-whisper réimplémente Whisper avec le moteur d’inférence CTranslate2. Il prend en charge la quantification 8 bits, y compris sur CPU, ce qui permet notamment de réduire l’empreinte mémoire dans certaines configurations. Son principal avantage dans ce tutoriel est de conserver un environnement Python, pratique pour intégrer ensuite la transcription dans un script, une application ou un workflow automatisé.

whisper.cpp, de son côté, fournit une implémentation en C/C++ et prend explicitement en charge l’inférence uniquement sur CPU. Le projet fonctionne sous Linux et propose également la quantification des modèles. Il constitue donc une alternative particulièrement intéressante lorsqu’on souhaite limiter les dépendances logicielles liées à Python.

Dans la suite de ce tutoriel, nous allons installer les deux solutions. Vous pourrez ainsi choisir faster-whisper pour sa souplesse côté Python ou whisper.cpp pour son approche légère orientée CPU.

Créer un snapshot LWS avant l’installation

Avant d’installer des dépendances Python ou de compiler whisper.cpp, il est recommandé de créer un snapshot de votre VPS. Celui-ci capture l’état du serveur à un instant donné et peut faciliter un retour à une configuration précédente en cas de problème pendant vos manipulations.

Depuis votre espace de gestion LWS :

• accédez au VPS concerné ;
• ouvrez la rubrique “Snapshots” ;

• renseignez un nom permettant d’identifier facilement le snapshot ;
• cliquez sur le bouton “Créer le snapshot”.

La gamme VPS KVM LWS permet actuellement de conserver jusqu’à 3 snapshots simultanés gratuits. Cette précaution est particulièrement utile avant une installation, une compilation ou une modification importante de l’environnement logiciel.

Un snapshot constitue toutefois un point de restauration et ne doit pas remplacer une véritable stratégie de sauvegarde de vos données.

Méthode 1 : Installer faster-whisper (Python)

Commençons par faster-whisper, la méthode la plus adaptée si vous souhaitez manipuler les transcriptions depuis Python. Nous allons isoler son installation dans un environnement virtuel, puis créer un premier script capable de transcrire automatiquement un fichier audio en français.

1. Installer les dépendances système

Connectez-vous à votre VPS en SSH avec un compte disposant des droits nécessaires, puis mettez à jour l’index des paquets :

apt update

Installez ensuite Python, pip, le module permettant de créer des environnements virtuels ainsi que ffmpeg :

apt install python3 python3-pip python3-venv ffmpeg -y

La documentation actuelle de faster-whisper précise que le runtime décode lui-même les fichiers audio avec PyAV, qui embarque les bibliothèques FFmpeg nécessaires. L’installation de la commande système ffmpeg n’est donc pas indispensable à faster-whisper seul. Nous l’installons néanmoins dès maintenant, car elle sera utile pour convertir les fichiers audio, notamment lors de la méthode avec whisper.cpp.

2. Vérifier la version de Python

Avant d’installer faster-whisper, vérifiez la version de Python 3 disponible sur votre VPS :

python3 --version

La documentation actuelle de faster-whisper exige Python 3.9 ou une version supérieure. Si la commande renvoie une version compatible, vous pouvez poursuivre directement l’installation.

Pour connaître également la version de pip, utilisez :

python3 -m pip --version

L’utilisation de python3 -m pip permet de s’assurer que le gestionnaire de paquets appelé correspond bien à l’installation de Python utilisée sur le VPS.

3. Créer un environnement virtuel (bonne pratique)

Il est fortement recommandé d’installer faster-whisper dans un environnement virtuel Python plutôt que directement dans l’environnement système du VPS. Cette méthode permet d’isoler ses bibliothèques et leurs versions des autres applications Python installées sur le serveur.

Créez un environnement appelé whisper-env :

python3 -m venv whisper-env

Activez-le ensuite :

source whisper-env/bin/activate

Une fois l’environnement activé, le début de votre invite de commande devrait généralement afficher son nom :

(whisper-env) root@vps:~#

Vous pouvez également vérifier quel interpréteur Python est utilisé :

which python

Le chemin retourné doit pointer vers le répertoire whisper-env.

Avant d’installer faster-whisper, vous pouvez mettre à jour pip dans cet environnement :

python -m pip install --upgrade pip

À partir de maintenant, les dépendances installées resteront isolées dans cet environnement virtuel. Lors d’une future connexion SSH, pensez donc à le réactiver avec :

source whisper-env/bin/activate

4. Installer faster-whisper

Une fois l’environnement virtuel actif, installez faster-whisper depuis PyPI :

python -m pip install faster-whisper

Il s’agit de la méthode d’installation actuellement recommandée. faster-whisper utilise CTranslate2 comme moteur d’inférence et prend en charge la quantification en INT8 sur CPU, configuration que nous allons utiliser sur notre VPS.

Une fois l’installation terminée, vous pouvez vérifier que le paquet est bien présent :

python -m pip show faster-whisper

La commande doit notamment afficher son nom et la version installée.

À ce stade, aucun modèle Whisper n’a nécessairement encore été téléchargé. Lorsque nous indiquerons une taille de modèle à WhisperModel, faster-whisper récupérera automatiquement le modèle CTranslate2 correspondant depuis Hugging Face Hub s’il n’est pas déjà disponible localement.

5. Premier test de transcription

Nous pouvons maintenant effectuer notre première transcription audio avec Whisper AI.

Pour commencer, placez un fichier appelé audio.mp3 dans votre répertoire de travail. Vous pouvez vérifier sa présence avec :

ls -lh audio.mp3

Créez ensuite un fichier Python nommé transcrire.py :

nano transcrire.py

Ajoutez le code suivant :

from faster_whisper import WhisperModel

model_size = "small"

model = WhisperModel(
    model_size,
    device="cpu",
    compute_type="int8"
)

segments, info = model.transcribe(
    "audio.mp3",
    beam_size=5
)

print(
    f"Langue détectée : {info.language} "
    f"(confiance : {info.language_probability:.2f})"
)

for segment in segments:
    print(
        f"[{segment.start:.2f}s -> {segment.end:.2f}s] "
        f"{segment.text}"
    )

Nous utilisons ici le modèle small, qui constitue un point de départ raisonnable pour tester l’installation avant d’expérimenter avec des modèles plus exigeants.

Le paramètre :

device="cpu"

indique explicitement que l’inférence doit être effectuée avec le processeur du VPS, tandis que :

compute_type="int8"

active le calcul INT8. Cette configuration CPU/INT8 est directement documentée par faster-whisper.

Dans cet exemple, nous ne renseignons volontairement pas language="fr". Whisper peut ainsi effectuer la détection de langue, ce qui nous permet de vérifier que le fichier français est correctement identifié.

Si vous savez que tous vos fichiers seront en français, vous pourrez ensuite imposer cette langue :

segments, info = model.transcribe(
    "audio.mp3",
    language="fr"
)

Enregistrez le fichier avec Ctrl + O, validez avec Entrée, puis quittez Nano avec Ctrl + X.

Lancez maintenant le script :

python transcrire.py

Lors du premier lancement, faster-whisper télécharge automatiquement le modèle correspondant à la taille indiquée lorsque celui-ci n’est pas encore disponible localement. Une connexion Internet est donc nécessaire pour cette première récupération.

Une fois le modèle chargé, le terminal devrait afficher la langue identifiée puis les différents segments de transcription avec leurs timestamps :

Langue détectée : fr (confiance : 0.99)
[0.00s -> 4.28s] Bonjour et bienvenue dans cet épisode.
[4.28s -> 8.74s] Aujourd'hui, nous allons parler d'hébergement web.

Les valeurs ci-dessus sont uniquement un exemple de format de sortie : la confiance, les timestamps et le texte dépendront évidemment de votre propre enregistrement.

Un détail important concerne le fonctionnement de faster-whisper : l’objet segments retourné par model.transcribe() est un générateur Python. La transcription est réellement exécutée lorsque ce générateur est parcouru, ce que réalise ici la boucle for segment in segments.

Méthode 2 : Installer whisper.cpp (C/C++, léger)

La deuxième méthode repose sur whisper.cpp, une implémentation de Whisper en C/C++ particulièrement intéressante pour un serveur fonctionnant principalement sur CPU. Le projet prend en charge Linux et fournit un exécutable en ligne de commande, whisper-cli, permettant d’effectuer des transcriptions sans avoir à maintenir un environnement Python pour l’exécution.

Cette solution convient donc bien à un VPS aux ressources limitées, mais aussi aux utilisateurs qui souhaitent intégrer la transcription dans des scripts Bash ou d’autres outils système.

Contrairement à la méthode avec faster-whisper, nous allons ici compiler le programme directement sur le VPS, puis télécharger séparément un modèle Whisper converti au format GGML.

1. Installer les outils de compilation

Commencez par installer les paquets nécessaires à la récupération et à la compilation de whisper.cpp :

apt update

Puis :

apt install build-essential cmake git ffmpeg -y

Ces différents outils ont chacun un rôle précis :

• build-essential fournit notamment le compilateur et les outils nécessaires à la compilation sous Linux ;
• cmake permet de configurer et construire la version actuelle de whisper.cpp ;
• git sert à récupérer le code source depuis son dépôt ;
• ffmpeg nous permettra de convertir les fichiers audio dans un format compatible avec la procédure utilisée dans ce tutoriel.

La documentation actuelle de whisper.cpp utilise CMake pour construire whisper-cli. Les anciennes procédures basées uniquement sur des commandes make ne doivent donc pas être utilisées comme méthode principale d’installation.

Vous pouvez vérifier que les principaux outils sont disponibles avec :

git --version
cmake --version
gcc --version
ffmpeg -version

Il n’est pas nécessaire d’installer CUDA pour suivre ce tutoriel. Nous compilons ici une version destinée à fonctionner avec le CPU du VPS.

2. Cloner et compiler whisper.cpp

Placez-vous dans le répertoire dans lequel vous souhaitez installer le programme, puis clonez le dépôt officiel :

git clone https://github.com/ggml-org/whisper.cpp.git

Accédez ensuite au dossier créé :

cd whisper.cpp

Configurez le projet avec CMake :

cmake -B build

Puis lancez la compilation :

cmake --build build -j --config Release

Cette procédure correspond au Quick Start actuel du projet whisper.cpp. Elle construit notamment l’exécutable whisper-cli, que nous utiliserons ensuite pour lancer nos transcriptions.

L’option -j permet à l’outil de compilation de paralléliser les tâches lorsque cela est possible. Comme cette opération peut solliciter plusieurs cœurs du serveur, il est normal d’observer temporairement une hausse de la charge CPU pendant la compilation.

Une fois l’opération terminée, vérifiez que l’exécutable a correctement été généré :

ls -lh build/bin/whisper-cli

Vous pouvez également afficher son aide :

./build/bin/whisper-cli -h

Si cette commande affiche les différentes options disponibles, whisper.cpp est correctement compilé.

À noter que le projet propose également des raccourcis tels que :

make -j small

Cependant, cette commande ne se contente pas de télécharger le modèle : le Makefile actuel télécharge le modèle demandé, lance la construction puis exécute celui-ci sur les fichiers d’exemple présents dans le projet. Pour un tutoriel plus clair et plus contrôlé, nous séparons donc compilation, téléchargement du modèle et transcription.

3. Télécharger un modèle

whisper.cpp n’utilise pas directement les fichiers PyTorch distribués par OpenAI. Il charge des modèles convertis dans un format GGML adapté à l’implémentation C/C++. Le projet fournit un script permettant de télécharger directement ces modèles préconvertis.

Pour commencer avec le modèle small, exécutez depuis le répertoire whisper.cpp :

sh ./models/download-ggml-model.sh small

Le fichier est alors enregistré dans le dossier models. Vous pouvez vérifier sa présence avec :

ls -lh models/ggml-small.bin

Au moment de la rédaction, whisper.cpp propose notamment les modèles multilingues suivants :

tiny
base
small
medium
large-v1
large-v2
large-v3
large-v3-turbo

Le modèle large-v3-turbo est bien le nom actuellement utilisé par whisper.cpp pour la variante Turbo. Le projet propose aussi plusieurs modèles quantifiés, par exemple large-v3-turbo-q5_0, dont les fichiers occupent moins d’espace disque et nécessitent moins de mémoire que leur équivalent non quantifié.

Pour une transcription en français, choisissez un modèle multilingue comme small plutôt qu’une variante portant le suffixe .en. La documentation du projet précise en effet que les modèles contenant .en dans leur nom sont destinés à l’anglais, tandis que les autres modèles de cette liste sont multilingues.

Pour un premier essai sur VPS, nous resterons sur :

sh ./models/download-ggml-model.sh small

Vous pourrez ensuite tester un autre modèle en fonction de la mémoire disponible, de la précision recherchée et du comportement réellement observé sur votre VPS. À titre indicatif, la documentation de whisper.cpp annonce environ 466 MiB sur disque et 852 Mo de mémoire pour small, contre environ 1,5 GiB sur disque et 2,1 Go de mémoire pour medium. Ces valeurs concernent le runtime whisper.cpp et ne constituent pas des mesures de vitesse de transcription.

Nous allons maintenant préparer notre fichier audio dans le format attendu avant de lancer la première transcription avec whisper.cpp.

4. Convertir un fichier audio au format attendu

Avant la transcription, nous allons convertir le fichier en WAV 16 bits, mono et 16 kHz. Le README principal de whisper.cpp recommande toujours ce format pour whisper-cli, même si l’aide actuelle de la commande mentionne également la prise en charge de fichiers FLAC, MP3 et OGG. Pour obtenir un fonctionnement reproductible sur VPS, la conversion préalable avec ffmpeg reste donc la méthode retenue dans ce tutoriel.

Depuis le dossier contenant votre fichier audio.mp3, exécutez :

ffmpeg -i audio.mp3 -ar 16000 -ac 1 -c:a pcm_s16le audio.wav

Dans cette commande, -ar 16000 fixe la fréquence d’échantillonnage à 16 kHz, -ac 1 produit une piste mono et -c:a pcm_s16le utilise un encodage PCM signé sur 16 bits. Il s’agit de la commande de conversion fournie dans la documentation officielle de whisper.cpp.

Vérifiez ensuite que le fichier a bien été créé :

ls -lh audio.wav

Vous disposez maintenant d’un fichier prêt à être utilisé pour notre premier test avec whisper.cpp.

5. Lancer la transcription

Depuis le répertoire whisper.cpp, lancez la transcription avec le modèle small téléchargé précédemment :

./build/bin/whisper-cli \
  -m models/ggml-small.bin \
  -f audio.wav \
  -l fr

L’option -m indique le modèle Whisper à charger, -f désigne le fichier audio et -l fr précise que la langue parlée est le français. Cette dernière option est importante : l’aide actuelle de whisper-cli permet de fournir explicitement une langue ou d’utiliser auto pour demander une détection automatique.

Si vous souhaitez tester cette détection, utilisez plutôt :

./build/bin/whisper-cli \
  -m models/ggml-small.bin \
  -f audio.wav \
  -l auto

Le terminal affiche progressivement les segments transcrits avec leurs timestamps. Le résultat exact dépend évidemment de l’enregistrement et du modèle sélectionné.

Nous disposons désormais de deux installations fonctionnelles de Whisper AI sur VPS. Voyons comment exploiter les timestamps produits pour créer directement des fichiers de sous-titres.

Générer des sous-titres au format SRT

Le format SRT (SubRip Subtitle) associe chaque portion de texte à un intervalle temporel. Il peut ensuite être importé dans de nombreux lecteurs et outils vidéo pour ajouter des sous-titres synchronisés, notamment à partir d’un podcast vidéo, d’un webinaire ou d’une interview.

Avec faster-whisper (script Python) :

Avec faster-whisper, nous pouvons construire le fichier SRT à partir des propriétés start, end et text de chaque segment retourné par la transcription. Ces informations sont exposées directement par l’objet Segment de faster-whisper.

Créez un nouveau fichier :

nano generer_srt.py

Ajoutez le script suivant :

from faster_whisper import WhisperModel


def format_timestamp(seconds):
    milliseconds = round(seconds * 1000)

    hours, remainder = divmod(milliseconds, 3_600_000)
    minutes, remainder = divmod(remainder, 60_000)
    seconds, milliseconds = divmod(remainder, 1000)

    return (
        f"{hours:02d}:{minutes:02d}:"
        f"{seconds:02d},{milliseconds:03d}"
    )


model = WhisperModel(
    "small",
    device="cpu",
    compute_type="int8"
)

segments, info = model.transcribe(
    "audio.mp3",
    language="fr"
)

with open("sous-titres.srt", "w", encoding="utf-8") as fichier_srt:
    for numero, segment in enumerate(segments, start=1):
        fichier_srt.write(f"{numero}\n")
        fichier_srt.write(
            f"{format_timestamp(segment.start)} --> "
            f"{format_timestamp(segment.end)}\n"
        )
        fichier_srt.write(f"{segment.text.strip()}\n\n")

print("Fichier sous-titres.srt généré avec succès.")

La configuration CPU avec compute_type="int8" est prise en charge officiellement par faster-whisper. Comme segments est un générateur, la transcription est effectivement exécutée lorsque la boucle parcourt les différents segments pour écrire le fichier SRT.

Exécutez le script :

python generer_srt.py

Vous devriez obtenir un fichier :

sous-titres.srt

Vous pouvez en afficher les premières lignes avec :

head -n 12 sous-titres.srt

Le résultat prendra cette forme :

1
00:00:00,000 --> 00:00:04,280
Bonjour et bienvenue dans cet épisode.

2
00:00:04,280 --> 00:00:08,740
Aujourd'hui, nous allons parler d'hébergement web.

Les phrases et timestamps ci-dessus servent uniquement d’exemple de structure SRT. Ils seront remplacés par ceux calculés à partir de votre propre fichier audio.

Avec whisper.cpp (option intégrée) :

Avec whisper.cpp, la génération d’un fichier SRT est plus directe : whisper-cli possède une option dédiée aux sous-titres SRT. Le code source actuel du projet confirme que -osrt est l’alias de --output-srt.

Depuis le répertoire whisper.cpp, exécutez :

./build/bin/whisper-cli \
  -m models/ggml-small.bin \
  -f audio.wav \
  -l fr \
  -osrt

La transcription est alors également enregistrée au format SRT.

Si vous souhaitez définir explicitement le nom du fichier de sortie, whisper-cli propose l’option -of, ou --output-file. Le chemin doit être fourni sans extension.

Par exemple :

./build/bin/whisper-cli \
  -m models/ggml-small.bin \
  -f audio.wav \
  -l fr \
  -osrt \
  -of sous-titres

Vous obtenez alors :

sous-titres.srt

Vous pouvez vérifier les premières lignes avec :

head -n 12 sous-titres.srt

Cette méthode est particulièrement pratique lorsque votre objectif principal consiste à générer rapidement des sous-titres sans développer de script Python supplémentaire.

Traiter plusieurs fichiers automatiquement : script batch

Une fois Whisper AI opérationnel, il est possible d’automatiser la transcription de plusieurs fichiers. C’est utile, par exemple, pour traiter une archive de podcasts, des enregistrements de réunions ou des fichiers audio déposés régulièrement sur le VPS.

Le premier script transcrire.py de ce tutoriel utilisait directement audio.mp3. Pour un traitement par lot, nous devons d’abord lui permettre de recevoir le chemin du fichier audio en argument.

Remplacez son contenu par :

import sys

from faster_whisper import WhisperModel


if len(sys.argv) != 2:
    print("Usage : python transcrire.py fichier_audio")
    sys.exit(1)

fichier_audio = sys.argv[1]

model = WhisperModel(
    "small",
    device="cpu",
    compute_type="int8"
)

segments, info = model.transcribe(
    fichier_audio,
    language="fr"
)

for segment in segments:
    print(segment.text.strip())

Vous pouvez désormais appeler le script avec n’importe quel fichier :

python transcrire.py podcast.mp3

Créez ensuite les dossiers qui accueilleront les fichiers :

mkdir -p /home/utilisateur/audios
mkdir -p /home/utilisateur/transcriptions

Puis créez transcrire_dossier.sh :

nano transcrire_dossier.sh

Ajoutez :

#!/bin/bash

shopt -s nullglob

for fichier in /home/utilisateur/audios/*.mp3; do
    nom=$(basename "$fichier" .mp3)

    /home/utilisateur/whisper-env/bin/python \
        /home/utilisateur/transcrire.py \
        "$fichier" \
        > "/home/utilisateur/transcriptions/${nom}.txt"
done

Adaptez /home/utilisateur/ au chemin réellement utilisé sur votre VPS.

Rendez ensuite le script exécutable :

chmod +x transcrire_dossier.sh

Puis lancez-le :

./transcrire_dossier.sh

Chaque fichier MP3 présent dans audios produit alors une transcription TXT portant le même nom dans le dossier transcriptions.

Nous utilisons volontairement le chemin complet vers :

/home/utilisateur/whisper-env/bin/python

Cette méthode évite de dépendre de l’activation manuelle de l’environnement virtuel Python, ce qui devient particulièrement important lorsqu’un script est lancé automatiquement par Cron.

Pour planifier, par exemple, une transcription chaque nuit, vous pouvez ensuite créer une tâche Cron. Le guide LWS consacré aux Cron Jobs détaille la syntaxe et la gestion de ces tâches sur Linux.

Vous pouvez consulter le tutoriel : automatiser vos transcriptions avec une tâche planifiée Cron.

Superviser les ressources pendant la transcription

La transcription audio par IA sollicite principalement le processeur et la mémoire lorsque Whisper fonctionne sans GPU. Plus le modèle choisi est volumineux, plus il est important de vérifier le comportement réel du serveur pendant les premiers traitements.

Le Panel KVM LWS permet de suivre depuis une interface graphique différentes ressources du VPS, notamment la charge CPU, la mémoire RAM et le trafic réseau. Cette supervision est déjà utilisée dans les tutoriels LWS consacrés aux VPS pour identifier rapidement une hausse de consommation.

Pendant une transcription, ouvrez donc la partie consacrée à la supervision des ressources dans votre Panel KVM et observez principalement :

• la charge CPU pendant le traitement ;
• la mémoire RAM utilisée ;
• l’évolution des ressources lorsque plusieurs fichiers sont traités successivement ;
• l’impact éventuel sur les autres services hébergés sur le même VPS.

Un CPU fortement sollicité pendant l’inférence n’indique pas nécessairement une anomalie. En revanche, si le serveur devient difficilement utilisable ou manque régulièrement de mémoire, commencez par tester un modèle Whisper plus léger avant d’augmenter les ressources du VPS.

Aucun temps de traitement précis n’est donné ici : il doit être mesuré sur la configuration CPU réelle du VPS KVM LWS utilisé.

Cas d’usage concrets sur un VPS LWS

Une fois la transcription Whisper automatisée, elle peut être intégrée à de nombreux workflows : création de contenus SEO à partir de podcasts, sous-titrage de vidéos, comptes-rendus confidentiels ou encore automatisations combinant Whisper avec d’autres outils hébergés sur le même VPS.

Transcription de podcasts pour le SEO

Une transcription de podcast peut servir de matière première pour créer un article de blog, une FAQ, un résumé ou des extraits destinés aux réseaux sociaux. Whisper produit d’abord le texte brut de l’épisode, qui doit ensuite être relue, corrigé et restructuré avant publication : une transcription automatique ne remplace pas le travail éditorial nécessaire à un contenu SEO de qualité.

Vous pouvez également combiner Whisper avec un LLM local pour résumer automatiquement vos transcriptions.

Un workflow peut ainsi suivre cette logique :

Podcast → Whisper → transcription texte → LLM local → résumé ou structure d’article → relecture humaine
→ publication

Cette approche permet d’exploiter plus facilement un même contenu audio sous plusieurs formats tout en conservant le traitement principal sur votre infrastructure.

Sous-titrage de vidéos et accessibilité

Les fichiers SRT générés avec Whisper AI peuvent également servir à créer des sous-titres synchronisés pour des interviews, tutoriels vidéo, webinaires ou podcasts filmés.

Les WCAG 2.2 prévoient notamment, avec le critère 1.2.2 de niveau A, des sous-titres pour les contenus audio préenregistrés présents dans un média synchronisé. Le W3C précise que ces sous-titres doivent transmettre non seulement les paroles, mais aussi les informations sonores nécessaires à la compréhension, comme l’identification d’un intervenant ou certains effets sonores significatifs.

Une transcription Whisper constitue donc une excellente base, mais elle doit être vérifiée et éventuellement complétée manuellement avant d’être considérée comme un véritable sous-titrage accessible.

Pour approfondir ce sujet, consultez le guide LWS expliquant comment les sous-titres générés contribuent aux critères d’accessibilité WCAG de votre site. Cet article détaille notamment l’accessibilité des contenus audio et vidéo.

Comptes-rendus de réunions confidentielles

Pour une entreprise, Whisper auto-hébergé peut aussi être utilisé pour transcrire des réunions internes, entretiens ou échanges contenant des informations sensibles.

Lorsque la transcription est entièrement réalisée sur votre propre VPS, il est possible d’éviter l’envoi du fichier audio à une API de transcription externe. Cette approche donne davantage de contrôle sur l’emplacement du fichier, le modèle utilisé et la suppression des données après traitement.

Il faut toutefois éviter de présenter l’auto-hébergement comme une garantie automatique de conformité au RGPD. L’entreprise reste responsable de la sécurité, des droits d’accès, des sauvegardes et de la durée de conservation des enregistrements et transcriptions. La CNIL rappelle notamment que les données personnelles ne doivent pas être conservées indéfiniment et que leur accès doit être protégé.

Pour des réunions sensibles, prévoyez donc une politique de conservation, des droits d’accès limités et une suppression des fichiers devenus inutiles.

Automatisation via n8n

Whisper peut enfin être intégré dans un workflow n8n auto-hébergé afin d’automatiser toute la chaîne de transcription.

Un scénario peut, par exemple, démarrer lorsqu’un fichier est reçu via un webhook. Le nœud Webhook de n8n est précisément conçu pour déclencher un workflow lorsqu’une requête arrive sur une URL dédiée.

Le workflow peut ensuite :

1. récupérer ou enregistrer le fichier audio ;
2. lancer le script faster-whisper ou la commande whisper-cli ;
3. récupérer la transcription produite ;
4. l’envoyer vers un autre traitement local ;
5. enregistrer le résultat ou déclencher une notification.

Sur une instance n8n auto-hébergée, le nœud Execute Command permet d’exécuter des commandes shell sur la machine qui héberge n8n. Il est toutefois classé parmi les nœuds pouvant être bloqués par défaut dans certaines configurations récentes pour des raisons de sécurité : vérifiez donc sa disponibilité avant de construire votre workflow.

Vous pouvez ainsi créer un pipeline entièrement automatisé du type :

Dépôt audio → n8n → Whisper AI → transcription → LLM local → résumé → archivage ou notification

Vérification du bon fonctionnement

Avant d’automatiser vos transcriptions Whisper AI, effectuez quelques contrôles simples pour vous assurer que l’installation fonctionne correctement.

Vérifiez les points suivants :

• le script faster-whisper transcrit correctement un fichier audio et détecte une langue cohérente ;
• whisper-cli se lance sans erreur et produit une transcription exploitable ;
• le fichier SRT contient des numéros de séquence, des timestamps et du texte ;
• le script batch génère bien un fichier .txt pour chaque audio traité ;
• la RAM du VPS reste suffisante pendant le chargement du modèle ;
• la charge CPU observée dans le Panel KVM LWS reste compatible avec les autres services hébergés sur le serveur. Le Panel permet notamment de suivre la consommation CPU et mémoire du VPS.

Pour vérifier rapidement un fichier SRT :

head -n 20 sous-titres.srt

Avec whisper.cpp, assurez-vous également que vos fichiers suivent le format recommandé par le projet, à savoir un WAV PCM 16 bits, mono et 16 kHz pour la procédure utilisée dans ce tutoriel.

Erreurs fréquentes et cas de blocage

Même avec une installation correcte, certaines erreurs peuvent apparaître selon la configuration du VPS, le modèle choisi ou l’environnement Python.

Pour diagnostiquer l’installation de faster-whisper, commencez par vérifier :

source whisper-env/bin/activate
python --version
python -m pip show faster-whisper

La version actuelle de faster-whisper nécessite Python 3.9 ou supérieur et s’installe avec pip. Elle utilise par ailleurs PyAV pour le décodage audio.

Pour whisper.cpp, contrôlez l’exécutable :

ls -lh build/bin/whisper-cli

Puis le modèle :

ls -lh models/ggml-small.bin

Si le problème concerne l’audio, reconvertissez-le :

ffmpeg -i audio.mp3 -ar 16000 -ac 1 -c:a pcm_s16le audio.wav

Cette conversion correspond à celle recommandée actuellement dans la documentation de whisper.cpp.

Enfin, ne cherchez pas à résoudre systématiquement un problème de lenteur en installant un modèle plus volumineux. Sur un VPS sans GPU, il est préférable de commencer petit, puis de comparer la qualité obtenue avec les ressources réellement disponibles.

Bonnes pratiques à suivre

Pour utiliser Whisper AI sur un VPS de manière régulière, quelques précautions permettent de conserver une installation plus stable et prévisible.

Commencez vos essais avec un modèle base ou small. Vous pourrez ensuite tester un modèle plus volumineux si la qualité obtenue ne répond pas à vos besoins. whisper.cpp propose également plusieurs modèles quantifiés, conçus notamment pour diminuer la taille du modèle et son empreinte mémoire.

Avec faster-whisper, conservez votre installation dans un environnement virtuel Python et utilisez compute_type="int8" lorsque vous souhaitez exploiter le mode CPU INT8 pris en charge par CTranslate2.

Pour whisper.cpp, conservez la conversion systématique vers un fichier :

WAV + PCM 16 bits + 16 kHz + mono

Vous réduirez ainsi les problèmes de compatibilité entre fichiers provenant de sources différentes. La documentation officielle de whisper.cpp recommande toujours cette préparation pour whisper-cli.

Pensez également à :

• créer un snapshot avant une mise à jour importante ;
• surveiller la RAM et le CPU lors des premiers traitements ;
• éviter de lancer simultanément plusieurs gros modèles sur un VPS déjà chargé ;
• conserver les fichiers audio sensibles uniquement pendant la durée réellement nécessaire ;
• tester vos scripts sur quelques fichiers avant de lancer une archive complète ;
• mesurer vous-même les performances avant de dimensionner un workflow de production.

Le Panel KVM LWS permet de suivre notamment le CPU, la RAM, le disque et l’activité réseau du VPS, ce qui facilite ces contrôles pendant les premiers traitements.

FAQ

Whisper AI est-il gratuit pour un usage commercial ?

Oui. Whisper AI est publié sous licence MIT, ce qui autorise un usage commercial. En auto-hébergement, vous ne payez pas la transcription à la minute, mais uniquement les ressources de votre serveur.

Peut-on utiliser Whisper AI sans GPU sur un VPS ?

Oui. faster-whisper et whisper.cpp peuvent fonctionner sur CPU sans GPU dédié. Sur un VPS, commencez avec un modèle léger comme base ou small pour limiter la consommation de ressources.

Quelle est la différence entre faster-whisper et whisper.cpp ?

faster-whisper s’appuie sur CTranslate2 et s’intègre facilement dans des scripts Python. whisper.cpp est une implémentation C/C++ plus légère, particulièrement adaptée à une utilisation en ligne de commande sur CPU.

Whisper transcrit-il bien le français ?

Oui. Les modèles multilingues de Whisper prennent en charge le français. La qualité varie toutefois selon le modèle utilisé, la qualité de l’enregistrement, le bruit ambiant et les conditions de prise de son.

Comment générer des sous-titres SRT avec Whisper ?

Avec faster-whisper, un script Python peut transformer les segments transcrits en fichier SRT. Avec whisper.cpp, l’option -osrt permet de générer directement les sous-titres.

Les enregistrements transcrits avec Whisper restent-ils confidentiels ?

Avec une installation locale sur votre VPS, les fichiers n’ont pas besoin d’être envoyés à une API de transcription tierce. La confidentialité dépend néanmoins de la sécurité du serveur, des droits d’accès et de votre politique de conservation.

Conclusion

Installer Whisper AI sur un VPS permet de disposer d’une solution de transcription audio auto-hébergée, sans dépendre systématiquement d’une API facturée à l’usage. Avec faster-whisper, vous profitez d’un environnement Python pratique pour créer des scripts et automatiser vos traitements. whisper.cpp constitue de son côté une alternative légère particulièrement adaptée à une exécution sur CPU. Dans les deux cas, commencez avec un modèle raisonnable comme small, mesurez la consommation réelle de votre serveur et augmentez progressivement les ressources si nécessaire. Vous pourrez ensuite générer des sous-titres SRT, traiter automatiquement des dossiers d’enregistrements ou intégrer Whisper à un workflow n8n ou à un LLM local. Pensez enfin à protéger vos fichiers audio, surveiller votre VPS et conserver uniquement les données réellement nécessaires.

Avec GitHub Actions, il est possible d’automatiser ce processus et de déclencher un déploiement automatique à chaque push sur la branche principale. Ce tutoriel vous guide pas à pas pour mettre en place un workflow YAML GitHub Actions capable de se connecter à un VPS LWS via SSH, récupérer le nouveau code et relancer l’application de façon plus fiable, plus rapide et plus sécurisée.

Objectif

L’objectif de ce guide est de vous aider à configurer un pipeline simple de CI/CD avec GitHub Actions pour déployer automatiquement votre site ou votre application sur un VPS Linux. À la fin du tutoriel, chaque modification envoyée sur la branche main de votre dépôt GitHub déclenchera un workflow de déploiement. Celui-ci se connectera à votre serveur avec une clé SSH dédiée, utilisera des secrets GitHub pour protéger les informations sensibles, exécutera les commandes nécessaires sur le VPS, puis redémarrera l’application. Le but n’est pas de remplacer un déploiement initial, mais d’automatiser les mises à jour d’un projet déjà installé une première fois sur le serveur. Vous gagnerez ainsi du temps, tout en réduisant les manipulations manuelles et les erreurs de mise en production.

Pré-requis

Avant de commencer, vous devez disposer :

• d’un dépôt GitHub contenant le code de votre site ou de votre application. Le dépôt peut être public ou privé : dans les deux cas, GitHub Actions pourra exécuter un workflow dès lors que celui-ci est correctement configuré dans le projet.
• Accès à un VPS Linux, idéalement un VPS KVM LWS, avec une connexion SSH fonctionnelle. Ce tutoriel part du principe que votre application a déjà été déployée manuellement au moins une fois. Autrement dit, le serveur doit déjà contenir le projet, cloné avec Git, par exemple dans un dossier comme /var/www/monsite.
• Il est aussi nécessaire d’avoir quelques bases en Git et en ligne de commande : savoir créer un commit, pousser du code avec git push, naviguer dans un terminal Linux et comprendre la notion de branche principale, généralement appelée main.
• Vous n’avez en revanche pas besoin de connaître GitHub Actions avant de lire ce guide. Les notions essentielles seront expliquées progressivement.

Qu’est-ce que GitHub Actions : en une explication claire

GitHub Actions est un outil d’intégration continue et de déploiement continu directement intégré à GitHub. Il permet d’automatiser des actions à partir d’événements qui se produisent dans un dépôt : un push, une pull request, la création d’un tag, ou encore une exécution planifiée à une date précise.

Dans le cadre de ce tutoriel, l’objectif est simple : lorsqu’un développeur pousse du code sur la branche main, GitHub lance automatiquement un workflow. Ce workflow se connecte ensuite au VPS en SSH, récupère la dernière version du code et redémarre l’application. Cette logique évite d’avoir à refaire les mêmes commandes à la main à chaque mise à jour.

Un workflow GitHub Actions est défini dans un fichier au format YAML. Ce fichier indique quand l’automatisation doit se déclencher, sur quelle machine elle doit s’exécuter, et quelles étapes doivent être réalisées. C’est ce fichier que nous allons créer plus loin dans ce tutoriel.

Voici le vocabulaire essentiel à connaître avant de passer à la configuration :

La force de GitHub Actions est son intégration native avec GitHub. Vous n’avez pas besoin d’installer un outil externe pour commencer. Il suffit d’ajouter un fichier dans le dépôt, puis de suivre les exécutions depuis l’onglet « Actions ».

Ce tutoriel couvre un cas précis : le déploiement automatique d’une application déjà hébergée sur un VPS, via une connexion SSH déclenchée à chaque push. Nous allons donc nous concentrer sur une approche simple, adaptée à un développeur qui gère son code sur GitHub et souhaite automatiser la mise en production sur son propre serveur.

En revanche, nous n’aborderons pas ici les pipelines complexes avec plusieurs environnements séparés, les runners auto-hébergés ou les stratégies avancées de tests automatisés. Pour comparer cette approche avec une solution auto-hébergée, vous pouvez aussi découvrir une alternative auto-hébergée avec GitLab CI/CD/.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Créer un snapshot LWS avant de commencer

Avant de connecter GitHub Actions à votre serveur, il est recommandé de créer un snapshot de votre VPS LWS. Cette étape est souvent négligée, mais elle apporte une sécurité importante lors de la mise en place d’un déploiement automatique.

Un snapshot correspond à une copie de l’état de votre serveur à un instant précis. Si une erreur de configuration provoque un problème lors du premier déploiement, vous pouvez revenir rapidement à une version stable du VPS, sans devoir tout réinstaller manuellement.

Depuis votre espace client, rendez-vous dans le LWS Panel KVM, puis dans la rubrique « Snapshots ».

Cliquez ensuite sur le bouton  « Créer un snapshot ».

Donnez-lui un nom explicite, par exemple avant-github-actions.

Cette précaution est particulièrement utile lorsque vous modifiez la façon dont votre serveur reçoit du code. Avec un workflow automatisé, une mauvaise commande dans le fichier YAML peut être exécutée à distance sur le VPS. Le snapshot vous permet donc de tester plus sereinement la configuration, surtout lors du premier essai.

Gardez toutefois en tête qu’un snapshot ne remplace pas une vraie stratégie de sauvegarde. Il s’agit ici d’un filet de sécurité temporaire avant de modifier votre processus de déploiement.

Générer une paire de clés SSH dédiée au déploiement

Pour que GitHub Actions puisse se connecter à votre VPS sans intervention manuelle, il faut utiliser une clé SSH. Cette clé permet au workflow de s’authentifier auprès du serveur sans saisir de mot de passe.

Il est fortement déconseillé de réutiliser votre clé SSH personnelle. Créer une clé SSH dédiée au déploiement limite les risques : si cette clé doit être révoquée plus tard, vous pourrez la supprimer sans impacter vos propres accès administrateur.

Dans cette étape, nous allons générer une nouvelle paire de clés, autoriser la clé publique sur le VPS, puis conserver la clé privée pour l’ajouter ensuite dans les secrets GitHub.

1. Générer la clé (depuis votre machine locale ou le VPS)

Depuis votre machine locale, ou directement depuis le VPS si vous préférez centraliser la configuration.

Lancez la commande suivante :

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/github_actions_deploy

Cette commande crée une paire de clés SSH avec l’algorithme ed25519, recommandé pour sa sécurité et sa légèreté. Le commentaire "github-actions-deploy" permet simplement d’identifier plus facilement l’usage de cette clé.

Lorsque le terminal demande une passphrase, appuyez deux fois sur “Entrée” pour la laisser vide. Dans un contexte classique, protéger une clé SSH par mot de passe est une bonne pratique. Mais ici, le workflow GitHub Actions doit pouvoir l’utiliser automatiquement, sans intervention humaine. Une passphrase bloquerait donc l’exécution du déploiement.

Deux fichiers sont créés :

• ~/.ssh/github_actions_deploy : la clé privée, à garder secrète ;
• ~/.ssh/github_actions_deploy.pub : la clé publique, à autoriser sur le VPS.

La clé privée ne devra jamais être ajoutée dans le dépôt Git.

2. Autoriser la clé publique sur le VPS

Une fois la clé générée, vous devez autoriser sa partie publique sur le VPS Linux. Cela permet au serveur de reconnaître la connexion initiée par GitHub Actions comme légitime.

La méthode la plus simple consiste à utiliser la commande ssh-copy-id :

ssh-copy-id -i ~/.ssh/github_actions_deploy.pub -p 22 utilisateur@IP_DU_VPS

Remplacez utilisateur par le nom de l’utilisateur SSH utilisé pour le déploiement, par exemple root ou un utilisateur dédié. Remplacez également IP_DU_VPS par l’adresse IP de votre serveur. Si votre port SSH n’est pas 22, adaptez la valeur après l’option -p.

Cette commande ajoute automatiquement le contenu de la clé publique dans le fichier ~/.ssh/authorized_keys de l’utilisateur distant.

Si ssh-copy-id n’est pas disponible sur votre système, vous pouvez copier manuellement le contenu du fichier .pub, puis l’ajouter dans ~/.ssh/authorized_keys sur le VPS. Veillez à ne copier que la clé publique, jamais la clé privée.

3. Conserver la clé privée pour l’étape suivante

La dernière étape consiste à récupérer le contenu de la clé privée SSH. C’est cette clé qui sera ajoutée dans les secrets GitHub afin que le workflow puisse se connecter au VPS pendant le déploiement.

Affichez le contenu de la clé privée avec la commande suivante :

cat ~/.ssh/github_actions_deploy

Copiez l’intégralité du résultat, y compris les lignes de début et de fin :

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

Cette clé privée doit être manipulée avec beaucoup de prudence. Elle donne accès au serveur pour l’utilisateur SSH configuré. Elle ne doit donc jamais être copiée dans un fichier du dépôt, envoyée par email, partagée dans un outil collaboratif ou committée, même temporairement.

Une fois la clé ajoutée dans les secrets GitHub, supprimez tout fichier temporaire qui aurait pu servir à la copier. Si vous pensez qu’elle a été exposée par erreur, révoquez-la immédiatement en supprimant la clé publique correspondante du fichier authorized_keys sur le VPS, puis générez une nouvelle paire de clés.

Configurer les secrets GitHub

Les secrets GitHub permettent de stocker des informations sensibles de manière sécurisée. Dans notre cas, ils serviront à transmettre au workflow les informations nécessaires pour se connecter au VPS LWS :

• adresse IP,
• utilisateur SSH,
• port de connexion et clé privée SSH.

L’intérêt des secrets est d’éviter d’inscrire ces données directement dans le fichier deploy.yml. Le workflow pourra les utiliser pendant son exécution, mais elles ne seront pas visibles en clair dans le dépôt.

Cette étape est essentielle pour sécuriser votre déploiement automatique avec GitHub Actions. Un fichier YAML peut être lu par toutes les personnes ayant accès au dépôt. Les identifiants, eux, doivent rester protégés.

1. Accéder aux réglages des secrets

Pour ajouter les secrets nécessaires, ouvrez le dépôt GitHub concerné, puis rendez-vous dans les paramètres du projet.

Rendez-vous dans la section : “Settings > Secrets and variables > Actions > New repository secret”.

GitHub permet de créer plusieurs types de variables. Ici, vous devez bien choisir les repository secrets, car ils seront associés uniquement à ce dépôt. C’est le bon choix pour un projet qui déploie une application précise vers un VPS précis.

Chaque secret est composé d’un nom et d’une valeur. Le nom sera utilisé dans le fichier YAML, tandis que la valeur restera masquée dans l’interface GitHub après enregistrement.

Avant de passer à la suite, préparez les informations suivantes :

• l’adresse IP du serveur,
• l’utilisateur SSH,
• le port SSH et le contenu complet de la clé privée générée précédemment.

2. Créer les secrets nécessaires

Créez maintenant les secrets utilisés par le workflow GitHub Actions. Les noms doivent être saisis avec exactitude, car ils seront appelés ensuite dans le fichier deploy.yml.

Le secret VPS_SSH_KEY doit contenir toute la clé privée, sans supprimer les lignes -----BEGIN OPENSSH PRIVATE KEY----- et -----END OPENSSH PRIVATE KEY-----. Une erreur de copie à ce niveau provoquera souvent une erreur de connexion du type Permission denied.

Une fois les secrets enregistrés, GitHub masque automatiquement leurs valeurs dans l’interface. Vous pourrez modifier ou supprimer un secret, mais vous ne pourrez pas relire sa valeur en clair. C’est un comportement normal, conçu pour protéger vos informations sensibles.

Créer le fichier de workflow

Nous avons maintenant un VPS accessible en SSH et des secrets GitHub prêts à être utilisés. Il reste à créer le fichier qui va décrire le comportement de GitHub Actions. Ce fichier s’appelle un workflow. Il indique à GitHub quand déclencher l’automatisation, sur quelle machine l’exécuter et quelles commandes lancer pour mettre à jour le site sur le serveur.

Dans notre exemple, le workflow se déclenchera à chaque push sur la branche main. Il se connectera ensuite au VPS LWS avec les secrets configurés précédemment, se placera dans le dossier du projet, récupérera la dernière version du code et relancera l’application.

1. Structure du dossier

GitHub Actions détecte automatiquement les workflows placés dans le dossier .github/workflows/ à la racine du dépôt. Si ce dossier n’existe pas encore dans votre projet, créez-le avec la commande suivante :

mkdir -p .github/workflows

La structure du dépôt doit ensuite ressembler à ceci :

mon-projet/
├── .github/
│   └── workflows/
│       └── deploy.yml
├── package.json
├── src/
└── README.md

Le nom du fichier est libre, mais il doit se terminer par l’extension .yml ou .yaml. Dans ce tutoriel, nous utiliserons deploy.yml, car son rôle est clair : gérer le déploiement automatique du projet.

Veillez à bien placer ce fichier dans .github/workflows/. S’il est créé ailleurs, GitHub ne le considérera pas comme un workflow et aucune automatisation ne sera déclenchée lors de vos prochains push.

2. Créer le fichier de déploiement

Créez maintenant le fichier .github/workflows/deploy.yml, puis ajoutez le contenu suivant :

name: Déploiement automatique VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Déployer sur le VPS via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USERNAME }}
          key: ${{ secrets.VPS_SSH_KEY }}
          port: ${{ secrets.VPS_PORT }}
          script: |
            cd /var/www/monsite
            git pull origin main
            npm ci --production
            pm2 restart monapp

Ce workflow est volontairement simple pour rester facile à comprendre.

Lorsqu’un push est effectué sur la branche main, GitHub lance un job nommé deploy. Ce job utilise une machine virtuelle Ubuntu fournie par GitHub, puis exécute une action SSH qui se connecte à votre VPS.

Les informations sensibles ne sont jamais écrites en clair dans le fichier. Elles sont appelées avec la syntaxe ${{ secrets.NOM_DU_SECRET }}. C’est cette syntaxe qui permet d’utiliser les secrets GitHub créés à l’étape précédente.

Vous devez adapter trois éléments à votre propre projet :

• le chemin /var/www/monsite, qui doit correspondre au dossier réel de votre application sur le VPS ;
• la commande npm ci --production, utile pour une application Node.js, mais à adapter pour une autre stack ;
• la commande pm2 restart monapp, qui doit correspondre au nom exact du processus géré par PM2.

Pour une application Next.js, cette logique peut servir de base afin d’automatiser le déploiement de votre application Next.js avec GitHub Actions. Pour une application PHP ou un site statique, les commandes exécutées dans script seront différentes, mais le principe reste le même : se connecter au serveur, récupérer le code, puis relancer ou rafraîchir le service nécessaire.

3. Explication ligne par ligne

Le fichier deploy.yml peut sembler technique au premier abord, mais chaque bloc a un rôle précis. Voici les principaux éléments à comprendre.

Le bloc le plus important est script, car c’est lui qui décrit réellement ce qui se passe sur le VPS. Dans notre exemple, le workflow commence par entrer dans le dossier du projet avec cd /var/www/monsite. Il récupère ensuite le dernier code disponible sur la branche main avec git pull origin main.

La commande npm ci --production installe les dépendances nécessaires en production pour une application Node.js. Elle peut être remplacée selon votre stack : composer install --no-dev pour un projet PHP, une commande de build pour un site statique, ou encore une commande Docker pour un projet conteneurisé.

Enfin, pm2 restart monapp redémarre l’application gérée par PM2. Avant d’utiliser cette ligne, vérifiez le nom exact du processus avec pm2 list ou pm2 status. Un mauvais nom de processus peut donner l’impression que le déploiement fonctionne, alors que l’application n’a pas réellement été relancée.

Ce fichier constitue une première base fonctionnelle. Vous pourrez ensuite l’améliorer avec des tests, des filtres de fichiers ou une stratégie Docker, mais il est préférable de commencer par un workflow simple et compréhensible avant d’ajouter des couches plus avancées.

Déclencher et vérifier le premier déploiement automatique

Votre fichier deploy.yml est maintenant prêt. Pour vérifier que le workflow GitHub Actions fonctionne correctement, il faut l’ajouter au dépôt, le pousser sur la branche main, puis observer son exécution depuis l’onglet Actions de GitHub.

Ce premier lancement est une étape importante. Il permet de valider à la fois la syntaxe du fichier YAML, la configuration des secrets GitHub, la connexion SSH au VPS, et les commandes exécutées côté serveur. Si une erreur apparaît, elle sera visible dans les logs du workflow.

1. Commit et push du workflow

Depuis votre machine locale, ajoutez le fichier de workflow à Git, créez un commit, puis envoyez-le sur la branche main :

git add .github/workflows/deploy.yml
git commit -m "Ajout du workflow de déploiement automatique"
git push origin main

Dès que le push est reçu par GitHub, le déclencheur défini dans le fichier deploy.yml s’active. Comme nous avons configuré :

on:
  push:
    branches: [main]

le workflow ne se lance que lorsqu’un changement est envoyé sur la branche main. Un push sur une autre branche ne déclenchera donc pas le déploiement automatique.

Après cette commande, GitHub doit normalement créer une nouvelle exécution du workflow. Si rien ne se passe, vérifiez d’abord que le fichier se trouve bien dans .github/workflows/ et que l’indentation du fichier YAML est correcte.

2. Suivre l’exécution dans l’onglet Actions

Pour suivre le déploiement, ouvrez votre dépôt GitHub, puis cliquez sur l’onglet « Actions ».

Vous devriez voir apparaître un workflow nommé « Déploiement automatique VPS », correspondant à la valeur définie dans la ligne name.

Cliquez sur l’exécution en cours pour afficher le détail du job deploy. GitHub affiche alors chaque étape du workflow, son état et sa durée. Si tout se déroule correctement, l’exécution se termine avec une coche verte.

Cette page est très utile pour confirmer que GitHub a bien déclenché le workflow après le push, que l’action SSH a pu se connecter au VPS, et que les commandes du bloc script ont été exécutées jusqu’au bout.

3. Lire les logs en cas d’échec

Si le workflow échoue, GitHub affiche une croix rouge sur l’exécution concernée. Cliquez sur le job, puis ouvrez l’étape en erreur pour lire les logs détaillés. Ces logs indiquent généralement à quel moment le déploiement s’est arrêté.

Une erreur de type Permission denied (publickey) indique souvent un problème de clé SSH : clé publique absente du fichier authorized_keys, mauvaise clé privée copiée dans le secret VPS_SSH_KEY, ou utilisateur SSH incorrect.

Une erreur liée à cd /var/www/monsite signifie généralement que le chemin du projet sur le VPS n’est pas le bon. Dans ce cas, connectez-vous manuellement au serveur en SSH et vérifiez l’emplacement exact de votre application.

Si l’erreur vient de npm ci, pm2 restart ou d’une autre commande du bloc script, le problème concerne probablement la stack applicative elle-même. Le workflow fonctionne peut-être correctement, mais la commande exécutée sur le serveur doit être adaptée à votre projet.

Les secrets GitHub peuvent apparaître sous la forme *** dans les logs. C’est normal : GitHub masque automatiquement les valeurs sensibles pour éviter leur exposition.

Superviser le déploiement côté VPS

Une fois le déploiement automatique GitHub Actions exécuté avec succès, il est important de vérifier que l’application fonctionne réellement côté serveur. Une coche verte dans l’onglet « Actions » confirme que le workflow est allé au bout, mais elle ne garantit pas toujours que le site répond correctement aux visiteurs.

La supervision côté VPS permet de contrôler l’état du processus, les logs applicatifs, la consommation de ressources et les éventuelles erreurs après redémarrage. Cette étape est particulièrement utile lors des premiers déploiements automatisés, lorsque vous ajustez encore les commandes du fichier deploy.yml.

L’objectif est simple : confirmer que le code a bien été mis à jour, que l’application a redémarré proprement, et que le serveur reste stable après le déploiement.

Avec PM2 (applications Node.js) :

Si votre application Node.js est gérée avec PM2, vous pouvez vérifier rapidement son état avec les commandes suivantes :

pm2 status
pm2 logs monapp --lines 20

La commande pm2 status affiche la liste des processus gérés par PM2, leur statut, leur consommation mémoire et leur durée d’exécution. Le processus concerné doit apparaître avec un état stable, généralement online.

La commande pm2 logs monapp --lines 20 permet de consulter les dernières lignes de logs de l’application. Remplacez monapp par le nom exact de votre processus. Cette vérification aide à repérer rapidement une erreur de démarrage, une dépendance manquante, un problème de variable d’environnement ou une exception déclenchée après la mise à jour du code.

Depuis le Panel KVM LWS :

En complément des commandes en ligne, le LWS Panel KVM permet de surveiller l’état général du VPS. Depuis la rubrique Supervision, vous pouvez suivre la charge CPU, l’utilisation de la RAM et l’activité du serveur au moment du déploiement.

Cette vue est utile pour identifier un comportement anormal après l’exécution du workflow. Par exemple, un build trop lourd peut provoquer un pic de mémoire, tandis qu’une application mal redémarrée peut générer une consommation CPU inhabituelle.

Si vous observez une hausse importante des ressources après chaque déploiement, revoyez les commandes exécutées dans le bloc script du workflow. Il peut être nécessaire d’optimiser l’installation des dépendances, de déplacer certaines étapes de build, ou de mieux encadrer le redémarrage de l’application.

Aller plus loin : variantes utiles

Le workflow présenté dans ce tutoriel constitue une base simple et efficace pour automatiser un déploiement sur VPS avec GitHub Actions. Une fois cette première version fonctionnelle, vous pouvez l’améliorer progressivement selon les besoins de votre projet.

Les variantes suivantes permettent de limiter les déclenchements inutiles, de sécuriser la mise en production avec des tests, ou d’adapter le déploiement à des projets plus complexes, notamment ceux qui utilisent Docker. L’idée n’est pas de tout ajouter dès le départ, mais de faire évoluer votre pipeline étape par étape, lorsque le besoin devient réel.

1. Restreindre le déploiement à certains fichiers modifiés

Par défaut, le workflow GitHub Actions se déclenche à chaque push sur la branche main. Cette configuration est simple, mais elle peut provoquer des déploiements inutiles. Par exemple, si vous modifiez uniquement un fichier de documentation, comme README.md, il n’est pas forcément nécessaire de relancer tout le processus de mise en production.

Pour éviter cela, vous pouvez ajouter un filtre avec paths-ignore. Il permet d’ignorer certains fichiers ou dossiers lors du déclenchement du workflow.

Voici un exemple :

on:
  push:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'

Avec cette configuration, un push qui modifie uniquement des fichiers Markdown ou des fichiers présents dans le dossier docs/ ne déclenchera pas le déploiement automatique. En revanche, si le commit contient une modification du code applicatif, le workflow sera exécuté normalement.

Cette variante est utile pour les projets actifs, où plusieurs types de changements cohabitent : documentation, configuration, code source, scripts ou fichiers de build. Elle permet de limiter les exécutions inutiles dans l’onglet « Actions », de réduire le temps consommé par les workflows et d’éviter des redémarrages serveur sans intérêt.

Il est aussi possible d’utiliser paths au lieu de paths-ignore pour déclencher le workflow uniquement lorsque certains fichiers changent. Par exemple, vous pouvez choisir de déployer seulement si le dossier src/, le fichier package.json ou un dossier applicatif précis est modifié. Le bon choix dépend de votre organisation de projet.

2. Ajouter une étape de test avant déploiement

Un workflow GitHub Actions plus robuste ne déploie pas immédiatement le code après un push. Il commence par exécuter des tests automatisés, puis lance le déploiement sur le VPS uniquement si ces tests réussissent. Cette approche limite le risque de mettre en production une version cassée de l’application.

Voici un exemple de workflow avec deux jobs : un job test, puis un job deploy.

name: Tests puis déploiement VPS

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  deploy:
    needs: [test]
    runs-on: ubuntu-latest

    steps:
      - name: Déployer sur le VPS via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USERNAME }}
          key: ${{ secrets.VPS_SSH_KEY }}
          port: ${{ secrets.VPS_PORT }}
          script: |
            cd /var/www/monsite
            git pull origin main
            npm ci --production
            pm2 restart monapp

Dans cet exemple, le job test récupère d’abord le code avec actions/checkout@v4, installe les dépendances avec npm ci, puis exécute les tests avec npm test.

La ligne importante est la suivante :

needs: [test]

Elle indique que le job deploy dépend du job test. Si les tests échouent, le déploiement ne sera pas lancé. Cette sécurité est particulièrement importante pour les projets collaboratifs, les applications avec de nombreuses dépendances ou les sites e-commerce où une erreur peut avoir un impact direct sur l’expérience utilisateur.

Vous pouvez adapter cette logique à votre stack. Pour un projet PHP, il peut s’agir de tests PHPUnit. Pour une application front-end, vous pouvez lancer un build ou des tests unitaires JavaScript. L’essentiel est de vérifier automatiquement que le code est dans un état acceptable avant de l’envoyer sur le VPS de production.

3. Déploiement via Docker plutôt que git pull direct

Le déploiement présenté jusqu’ici repose sur une logique simple : le VPS contient déjà le dépôt Git, et le workflow exécute un git pull pour récupérer la dernière version du code. Cette méthode est facile à comprendre et convient à de nombreux projets, notamment pour commencer avec GitHub Actions.

Pour des projets plus complexes, une approche avec Docker peut être plus robuste. Au lieu de mettre à jour directement le code sur le serveur, le workflow peut construire une image Docker, la publier dans un registre, puis demander au VPS de récupérer et relancer le conteneur correspondant.

Cette méthode présente plusieurs avantages. Elle permet de mieux maîtriser l’environnement d’exécution, de limiter les différences entre développement et production, et de rendre les déploiements plus reproductibles. Elle est particulièrement intéressante lorsque votre projet utilise plusieurs services, des dépendances système précises ou une configuration applicative avancée.

Dans ce cas, le workflow GitHub Actions ne se contente plus d’exécuter git pull. Il peut inclure des étapes comme :

• construire une image Docker ;
• pousser l’image vers un registre ;
• se connecter au VPS en SSH ;
• exécuter docker compose pull ;
• relancer les conteneurs avec docker compose up -d.

Cette variante dépasse le cadre de ce tutoriel, mais elle constitue une évolution naturelle si votre projet grandit. Pour approfondir cette approche, vous pouvez consulter un guide dédié afin de déployer vos applications conteneurisées avec Docker sur VPS.

Vérification du bon fonctionnement

Après la mise en place de votre déploiement automatique avec GitHub Actions, prenez le temps de vérifier chaque point important. Une automatisation fiable ne se limite pas à une première exécution réussie : elle doit être compréhensible, reproductible et facile à diagnostiquer en cas de problème.

Commencez par effectuer un petit changement dans votre projet, par exemple une modification mineure dans le code ou dans une page de test. Créez un commit, puis poussez-le sur la branche main. Le workflow doit apparaître automatiquement dans l’onglet « Actions » du dépôt GitHub.

Vérifiez ensuite les points suivants :

• un push sur la branche main déclenche bien le workflow ;
• le workflow apparaît dans l’onglet Actions avec le bon nom ;
• l’exécution se termine avec une coche verte ;
• aucune erreur de connexion SSH n’apparaît dans les logs ;
• les commandes du bloc script sont exécutées dans le bon dossier sur le VPS ;
• l’application reflète bien la dernière version du code ;
• le processus applicatif est bien redémarré, par exemple avec pm2 status ;
• les secrets GitHub ne sont jamais visibles en clair dans les logs ;
• le serveur reste stable après le déploiement, sans pic anormal de CPU ou de RAM.

Si tous ces points sont validés, votre pipeline de déploiement automatique est opérationnel. Vous pouvez maintenant pousser vos mises à jour depuis GitHub et laisser le workflow se charger des commandes répétitives sur le serveur.

Gardez toutefois une bonne habitude : surveillez les premières exécutions, surtout après une modification du fichier deploy.yml. Une petite erreur d’indentation, un mauvais chemin serveur ou une commande inadaptée peuvent bloquer le déploiement. Une fois le workflow stabilisé, il deviendra un véritable gain de temps dans votre routine de développement.

Erreurs fréquentes et cas de blocage

Même avec un workflow bien structuré, un premier déploiement GitHub Actions sur VPS peut échouer pour des raisons simples : clé mal copiée, mauvais chemin serveur, port SSH bloqué ou commande de redémarrage incorrecte. L’avantage de GitHub Actions est que chaque exécution produit des logs détaillés. Il faut donc les lire étape par étape, sans se limiter au message final d’échec.

Voici les erreurs les plus fréquentes et les solutions à vérifier en priorité.

Pour faciliter le diagnostic, commencez toujours par distinguer deux types de problèmes. Si l’erreur intervient avant l’exécution du bloc script, le souci vient probablement de la connexion SSH ou des secrets GitHub. Si l’erreur apparaît après la connexion au serveur, le problème vient plutôt des commandes exécutées sur le VPS.

Vous pouvez aussi tester manuellement chaque commande du bloc script en vous connectant au serveur en SSH. Par exemple :

cd /var/www/monsite
git pull origin main
npm ci --production
pm2 restart monapp

Si une commande échoue manuellement, elle échouera aussi dans GitHub Actions. Cette méthode permet souvent de résoudre rapidement les problèmes sans modifier inutilement le workflow.

Bonnes pratiques

Une fois le déploiement automatique opérationnel, il est important de sécuriser et de fiabiliser votre configuration. Un workflow qui fonctionne une première fois n’est pas forcément un workflow prêt pour la production à long terme. Quelques bonnes pratiques permettent de réduire les risques et d’améliorer la maintenance.

Utilisez toujours une clé SSH dédiée à l’automatisation. Cette clé ne doit servir qu’au workflow GitHub Actions. En cas de suspicion de compromission, vous pourrez la révoquer rapidement sans bloquer vos propres accès administrateur au serveur.

Évitez autant que possible d’utiliser le compte root pour le déploiement. Lorsque c’est possible, créez un utilisateur dédié avec uniquement les droits nécessaires au projet. Cette approche limite les conséquences en cas d’erreur dans le workflow ou d’exposition accidentelle d’un accès.

Ne stockez jamais d’identifiant, d’adresse IP sensible, de mot de passe ou de clé privée SSH directement dans le fichier deploy.yml. Toutes les données sensibles doivent passer par les secrets GitHub. Le fichier YAML doit rester lisible, mais jamais contenir d’informations confidentielles.

Ajoutez progressivement une étape de test avant le déploiement. Même un test simple, un lint ou une commande de build peut éviter de mettre en production une version cassée. Pour un projet professionnel, le couple tests automatisés + déploiement conditionnel devient rapidement indispensable.

Créez un snapshot LWS avant les changements importants du pipeline. C’est particulièrement utile lorsque vous modifiez le processus de build, le gestionnaire de processus, la configuration PM2, Docker ou les permissions serveur.

Surveillez régulièrement l’onglet “Actions” de GitHub. Un workflow peut échouer silencieusement si personne ne consulte les exécutions. Prenez l’habitude de vérifier les premiers déploiements après chaque modification du fichier YAML.

Enfin, documentez votre processus. Ajoutez dans le dépôt un court fichier expliquant le rôle du workflow, les secrets nécessaires, le chemin du projet sur le VPS et les commandes exécutées. Cette documentation sera précieuse si un autre développeur doit reprendre le projet.

FAQ

GitHub Actions est-il gratuit pour déployer sur un VPS personnel ?

Oui, GitHub Actions peut être utilisé pour déployer un site sur un VPS personnel. GitHub propose des minutes d’exécution incluses selon le type de compte et la visibilité du dépôt. Pour un petit projet, un workflow simple de déploiement SSH consomme généralement peu de ressources. Il faut toutefois surveiller l’usage si les workflows deviennent fréquents, longs ou complexes.

Quelle est la différence entre GitHub Actions et GitLab CI/CD ?

GitHub Actions est intégré à GitHub, tandis que GitLab CI/CD est intégré à GitLab. Les deux outils permettent d’automatiser des tests, des builds et des déploiements. Le choix dépend surtout de l’endroit où votre code est hébergé, de vos habitudes de travail et de votre besoin éventuel d’une solution auto-hébergée.

Comment sécuriser les identifiants utilisés dans un workflow GitHub Actions ?

Il faut utiliser les secrets GitHub pour stocker les informations sensibles : adresse du serveur, utilisateur SSH, port et clé privée SSH. Ces données ne doivent jamais être écrites directement dans le fichier YAML. Il est aussi recommandé d’utiliser une clé SSH dédiée au déploiement et un utilisateur serveur avec des permissions limitées.

Peut-on utiliser GitHub Actions pour déployer un site WordPress ?

Oui, il est possible d’utiliser GitHub Actions pour déployer un site WordPress, mais la méthode dépend de votre organisation. Vous pouvez automatiser le déploiement d’un thème, d’un plugin ou d’un projet versionné. En revanche, il faut faire attention aux fichiers générés par WordPress, aux médias, à la base de données et aux modifications réalisées directement depuis l’administration.

Que faire si le déploiement automatique échoue sans message d’erreur clair ?

Commencez par ouvrir l’onglet Actions, puis consultez les logs détaillés du job en erreur. Vérifiez ensuite la connexion SSH, les secrets GitHub, le chemin du projet sur le VPS et chaque commande du bloc script. Le plus efficace est souvent de se connecter manuellement au serveur et de rejouer les commandes une par une.

Faut-il un VPS pour utiliser GitHub Actions, ou existe-t-il des alternatives ?

Il n’est pas obligatoire d’avoir un VPS pour utiliser GitHub Actions. L’outil peut aussi servir à lancer des tests, construire un site statique, publier un paquet ou déployer vers d’autres plateformes. En revanche, pour déployer sur une infrastructure que vous contrôlez totalement, un VPS Linux reste une solution flexible, notamment grâce à l’accès SSH et aux droits d’administration.

Conclusion

Mettre en place un déploiement automatique avec GitHub Actions permet de gagner du temps, de réduire les erreurs humaines et de fiabiliser les mises en production. En configurant un workflow YAML, une clé SSH dédiée et des secrets GitHub, vous pouvez déclencher la mise à jour de votre site à chaque push sur la branche main, sans vous connecter manuellement au serveur. Cette approche reste simple à comprendre, tout en constituant une excellente première étape vers une vraie logique CI/CD. Avec un VPS KVM LWS, vous disposez d’un environnement flexible, d’un accès root, de snapshots et d’outils de supervision pour sécuriser votre pipeline. Une fois ce premier workflow stabilisé, vous pourrez l’enrichir avec des tests, des filtres de déclenchement ou un déploiement Docker.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vous avez une question, un retour d’expérience ou une difficulté avec GitHub Actions ? Partagez-la en commentaire : cela pourra aider d’autres lecteurs à sécuriser leur propre déploiement automatique.

Avec un VPS Linux, il devient possible d’héberger un modèle IA local grâce à Ollama, sans clé API obligatoire. L’approche ne transforme pas un VPS CPU en machine GPU haute performance, mais elle permet de créer une IA auto-hébergée, maîtrisée, utile pour des usages internes, des tests, de l’automatisation ou du traitement confidentiel.

Objectif

L’objectif de ce tutoriel est de vous guider pas à pas pour installer Ollama sur un VPS KVM LWS sous Ubuntu ou Debian, puis télécharger un modèle de langage open source adapté aux ressources disponibles. Vous apprendrez à vérifier la mémoire et l’espace disque, lancer un premier modèle depuis le terminal, utiliser l’API REST locale d’Ollama et comprendre les bonnes pratiques de sécurité avant toute exposition externe. Ollama propose une intégration locale via une API accessible par défaut sur localhost:11434, ce qui permet d’intégrer le modèle dans des scripts ou applications sans exposer directement le service sur Internet. En fin de parcours, votre VPS pourra exécuter un LLM local sans API cloud, avec une supervision depuis le Panel KVM LWS et une architecture pensée pour préserver la maîtrise des données.

Pré-requis

Avant de commencer :

• prévoyez un VPS KVM LWS avec accès root SSH, idéalement sous Ubuntu 22.04/24.04 ou Debian 11/12. Pour un petit modèle de 3 à 4 milliards de paramètres, 8 Go de RAM peuvent suffire. Pour un modèle 7B ou 8B, visez plutôt 16 Go de RAM afin d’éviter une saturation rapide.
• Gardez aussi au moins 10 à 20 Go d’espace disque libre, car les modèles peuvent occuper plusieurs gigaoctets. Les offres VPS KVM LWS mettent en avant un stockage SSD NVMe et des fonctions de sauvegarde, utiles pour ce type d’installation serveur.
• Enfin, gardez en tête qu’un VPS KVM standard fonctionne ici en inférence CPU, sans GPU dédié : les réponses seront donc plus lentes qu’avec une infrastructure IA spécialisée.

Pourquoi faire tourner un LLM sur son VPS : les cas d’usage réels

Déployer un LLM open source sur VPS répond à un besoin très concret : garder la main sur l’exécution du modèle, les données traitées et les coûts. Pour une entreprise, un indépendant ou une équipe technique, cette approche permet de tester des usages IA sans envoyer systématiquement les contenus vers une plateforme externe.

Cette solution est particulièrement pertinente pour résumer des documents internes, analyser des textes, assister un développeur, générer des brouillons, créer des réponses automatiques ou enrichir une application métier via une API IA locale. Ollama est disponible sur Linux et propose une API utilisable pour intégrer le modèle dans une application ou un workflow.

Il faut toutefois rester réaliste. Un VPS sans GPU ne fournit pas les mêmes performances qu’une API IA commerciale ou qu’un serveur équipé d’une carte graphique spécialisée. Les grands modèles, notamment les modèles 70B, ne sont généralement pas adaptés à une inférence CPU sur VPS classique.

Le bon choix consiste donc à privilégier des modèles plus légers, comme des modèles 3B, 4B, 7B ou 8B, selon la mémoire disponible. L’administrateur doit aussi gérer l’espace disque, les mises à jour d’Ollama, les modèles installés et la sécurité réseau. C’est le prix de l’IA auto-hébergée : plus de contrôle, mais aussi plus de responsabilité technique.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Comprendre Ollama : ce que c’est exactement

Ollama est un outil qui permet d’installer, de télécharger et d’exécuter facilement des modèles de langage open source sur une machine locale ou un serveur Linux. Dans le cadre de ce tutoriel, il sert d’intermédiaire entre votre VPS KVM LWS et le LLM AI open source que vous souhaitez utiliser. Au lieu de configurer manuellement un moteur d’inférence, les fichiers du modèle, les paramètres de lancement et l’accès API, Ollama simplifie l’ensemble avec quelques commandes.

Concrètement, Ollama permet de récupérer des modèles depuis sa bibliothèque officielle, puis de les lancer depuis le terminal avec une commande comme ollama run.

Sa documentation indique que l’API locale est exposée, après installation, sur l’URL de base http://localhost:11434/api. Cela signifie que le service répond localement sur le VPS, sans être automatiquement publié sur Internet.

Ollama propose aussi une API utilisable par des scripts, des applications ou des outils d’automatisation. Pour un administrateur VPS, c’est un point important : le modèle IA local peut être interrogé par un script Python, une application web, un workflow n8n ou un connecteur interne, sans passer par une API cloud payante.

Il faut toutefois bien comprendre ce qu’Ollama n’est pas. Ce n’est pas une interface graphique complète comme ChatGPT. Ce n’est pas non plus un service cloud managé, ni une plateforme d’entraînement ou de fine-tuning avancé. Ollama sert principalement à exécuter des modèles LLM localement, à les gérer plus simplement et à fournir une API REST locale exploitable dans vos projets. Pour une interface web, il faudra ajouter une solution complémentaire comme Open WebUI, que nous verrons plus loin.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Choisir le bon modèle selon les ressources du VPS

Le choix du modèle est l’étape la plus importante lorsque l’on veut déployer un LLM open source sur VPS. Un modèle trop lourd peut saturer la mémoire, ralentir fortement le serveur ou empêcher le service de démarrer correctement. Sur un VPS sans GPU dédié, il faut raisonner en priorité selon la RAM disponible, l’espace disque et le type d’usage attendu.

Les petits modèles sont adaptés aux tests, aux résumés simples, aux réponses courtes ou à l’automatisation légère. Les modèles 7B ou 8B offrent généralement de meilleurs résultats, mais demandent davantage de mémoire. Les modèles beaucoup plus volumineux, comme les modèles 24B, 30B ou 70B, doivent être abordés avec prudence sur une infrastructure CPU-only.

Parmi les modèles légers, Phi-3 Mini est intéressant pour un VPS de taille modeste : la fiche Ollama le présente comme un modèle de 3,8 milliards de paramètres, conçu pour rester léger. Gemma 3 propose également plusieurs tailles, dont des variantes compactes comme 1B et 4B, pensées pour des environnements aux ressources limitées.

Pour un VPS plus confortable, Mistral 7B reste un choix pertinent : la fiche Ollama indique qu’il s’agit d’un modèle 7B distribué sous licence Apache. Qwen 3 8B peut aussi être envisagé pour des usages plus polyvalents, notamment lorsque l’on recherche un modèle récent avec plusieurs variantes dans la famille Qwen.

Sur un VPS KVM LWS sans GPU, ne promettez pas des performances comparables à une plateforme IA cloud. L’inférence CPU fonctionne, mais elle est plus lente. Pour un usage confortable, mieux vaut commencer par un modèle raisonnable, mesurer la consommation réelle, puis augmenter progressivement la taille du modèle si les ressources le permettent.

Créer un snapshot LWS avant l’installation

Avant d’installer Ollama, créez un snapshot LWS de votre VPS. Cette étape est simple, mais elle peut vous éviter une restauration longue en cas de mauvaise manipulation, d’installation incomplète ou de manque d’espace disque pendant le téléchargement d’un modèle volumineux.

Un snapshot fige l’état du serveur à un instant donné. Vous pouvez ainsi revenir en arrière si le système devient instable, si un service ne démarre plus correctement ou si vous souhaitez annuler les modifications.

Sur la page des VPS KVM LWS, LWS indique que les offres incluent des sauvegardes quotidiennes et jusqu’à trois snapshots gratuits simultanés pour figer l’état du VPS.

Dans le Panel KVM LWS, ouvrez la gestion de votre VPS, rendez-vous dans la partie dédiée aux snapshots.

Puis créez un instantané avant de poursuivre. C’est une bonne pratique avant toute installation serveur significative.

Installer Ollama sur le VPS

L’installation d’Ollama sur un VPS Linux se fait depuis un terminal SSH avec un compte disposant des droits nécessaires. La méthode officielle pour Linux indiquée sur la page de téléchargement d’Ollama repose sur une commande curl qui récupère et exécute le script d’installation.

Avant de lancer cette commande, il faut toutefois vérifier deux points : l’espace disque disponible et la mémoire RAM. Ces contrôles évitent de télécharger un modèle trop lourd pour votre VPS. Les étapes suivantes vont donc commencer par les vérifications système, puis l’installation du service, le contrôle de systemd et le test de l’API locale.

1. Vérifier l’espace disque disponible

Avant d’installer Ollama sur votre VPS Linux, commencez par vérifier que le serveur dispose de suffisamment de ressources. Cette étape est importante, car un modèle LLM open source peut occuper plusieurs gigaoctets sur le disque et consommer une part importante de la mémoire vive pendant l’inférence.

Connectez-vous à votre VPS KVM LWS en SSH en utilisant vos accès root.

Puis exécutez les commandes suivantes :

df -h /
free -h

La commande df -h / affiche l’espace disque disponible sur la partition principale comme vous pouvez le voir sur la capture ci-dessous :

La commande free -h indique la quantité de RAM disponible et l’utilisation éventuelle du swap.

Pour un premier test avec un petit modèle, gardez au minimum 10 Go d’espace libre. Pour plusieurs modèles ou un modèle 7B/8B, prévoyez plutôt 20 Go ou plus.

Si votre VPS manque d’espace disque ou de mémoire, mieux vaut corriger le problème avant de poursuivre. Télécharger un modèle trop volumineux sur un serveur déjà presque plein peut provoquer des erreurs d’installation, ralentir le système ou rendre le VPS difficile à administrer.

2. Installer Ollama

Une fois les ressources vérifiées, vous pouvez installer Ollama. La méthode officielle pour Linux consiste à exécuter le script d’installation fourni depuis la page de téléchargement d’Ollama. Au moment de la vérification et de cette rédaction, la commande Linux officielle indiquée est la suivante :

curl -fsSL https://ollama.com/install.sh | sh

Cette commande télécharge le script d’installation et l’exécute sur le serveur. Sur un VPS Ubuntu ou Debian administré en root, elle permet d’installer Ollama directement depuis le terminal SSH. Si vous utilisez un utilisateur non root avec privilèges sudo, vérifiez que votre session dispose bien des droits nécessaires. Regardez le résultat de l’installation de Ollama sur notre VPS KVM LWS de test dans la capture ci-dessous :

Pendant l’installation, le script prépare les fichiers nécessaires au fonctionnement d’Ollama. Sur Linux, Ollama peut ensuite être géré comme un service système. C’est ce service qui permettra au LLM local de rester disponible sur le VPS, même après la fermeture de votre session SSH.

À ce stade, ne téléchargez pas encore de modèle. L’objectif est d’abord de confirmer que le service Ollama est correctement installé et actif.

3. Vérifier que le service est actif

Après l’installation, vérifiez que le service Ollama fonctionne correctement. Utilisez la commande suivante :

systemctl status ollama

Le retour attendu doit indiquer un service actif, avec une ligne proche de :

active (running)

Vous pouvez également contrôler la version installée avec :

ollama --version

Cette vérification est utile pour deux raisons. D’abord, elle confirme que le binaire Ollama est bien disponible depuis le terminal. Ensuite, elle vous permet de comparer la version installée avec la version stable publiée sur le site officiel si vous préparez une mise en production.

Si le service n’est pas actif, ne passez pas tout de suite à l’étape suivante. Relancez d’abord le service avec :

systemctl restart ollama

Puis vérifiez à nouveau son état :

systemctl status ollama

4. Vérifier que l’API répond localement

Ollama expose une API locale qui permet d’interagir avec les modèles depuis des scripts, des applications ou des outils externes. La documentation officielle indique que l’API d’Ollama est servie par défaut à l’adresse http://localhost:11434/api après installation.

Pour vérifier rapidement que le service répond sur votre VPS, lancez :

curl http://localhost:11434/

Si Ollama fonctionne correctement, vous devez obtenir un message de confirmation du type :

Ollama is running

Ce test est volontairement effectué sur localhost. Cela signifie que le service répond depuis le VPS lui-même, sans être exposé publiquement sur Internet. C’est le comportement recherché pour une première installation sécurisée : votre API IA locale reste accessible uniquement depuis le serveur.

Vous pouvez aussi vérifier la base API documentée avec :

curl http://localhost:11434/api/tags

Tant qu’aucun modèle n’a été téléchargé, la réponse peut être vide ou ne lister aucun modèle. C’est normal. Les modèles seront installés dans l’étape suivante avec la commande ollama pull.

Télécharger et lancer un premier modèle

Une fois Ollama installé sur votre VPS, l’étape suivante consiste à télécharger un premier modèle de langage open source. Ollama fonctionne avec une bibliothèque de modèles que vous pouvez récupérer depuis le terminal, sans configurer manuellement les fichiers du modèle. La documentation CLI d’Ollama indique notamment les commandes ollama pull pour télécharger un modèle, ollama run pour l’exécuter, ollama rm pour le supprimer et ollama ls pour lister les modèles locaux.

Pour ce tutoriel, nous utilisons Mistral comme exemple, car il s’agit d’un modèle 7B disponible dans la bibliothèque Ollama, avec une taille indiquée d’environ 4,4 Go pour le tag mistral:latest.

1. Télécharger un modèle (exemple : Mistral 3 8B)

Depuis votre session SSH, lancez la commande suivante :

ollama pull mistral

Cette commande télécharge le modèle Mistral sur votre VPS.

Selon la connexion réseau, l’espace disque disponible et la charge du serveur, l’opération peut prendre quelques minutes. Ollama indique que le modèle mistral:latest pèse environ 4,4 Go, ce qui confirme l’importance d’avoir vérifié l’espace disque avant cette étape. Une fois que tout est terminé, vous avez le message du succès.

Sur un VPS KVM LWS sans GPU dédié, ce modèle reste exploitable pour des tests et des usages non temps réel, mais il faut garder des attentes raisonnables. L’inférence CPU sera plus lente qu’avec une infrastructure équipée d’un GPU. Si votre VPS dispose de peu de RAM, commencez plutôt par un modèle plus léger, puis augmentez progressivement.

2. Lancer une session de chat interactive

Une fois le modèle téléchargé, vous pouvez lancer une session interactive avec :

ollama run mistral

La page officielle du modèle Mistral indique justement cette commande comme usage CLI pour l’exécuter avec Ollama. Après le chargement du modèle, le terminal affiche un prompt interactif. Vous pouvez alors saisir une demande en français, par exemple :

Réponds en français. Explique en 5 lignes ce qu’est un LLM open source.

Ollama génère ensuite une réponse directement dans le terminal, comme vous le voyez sur l’image ci-haut. Pour quitter la session, utilisez :

/bye

Cette première interaction permet de valider que le LLM local fonctionne réellement sur votre VPS. C’est aussi un bon moment pour ouvrir la supervision du Panel KVM LWS et observer la consommation CPU/RAM pendant la génération.

3. Commandes de gestion essentielles

Après vos premiers tests, quelques commandes permettent de gérer proprement vos modèles Ollama :

ollama list          # Lister les modèles installés et leur taille
ollama ps            # Voir les modèles actuellement chargés en mémoire
ollama pull phi3     # Télécharger un autre modèle sans le lancer
ollama rm mistral    # Supprimer un modèle pour libérer de l'espace disque
ollama stop mistral  # Décharger un modèle de la mémoire

La documentation CLI officielle mentionne notamment ollama pull, ollama rm et ollama ls pour télécharger, supprimer et lister les modèles. La FAQ Ollama indique aussi que ollama ps sert à voir les modèles chargés en mémoire, avec une colonne permettant d’identifier si le modèle tourne côté CPU ou GPU. Sur un VPS KVM LWS CPU-only, vous devez donc vous attendre à une exécution en mémoire système.

Enfin, ollama stop permet de décharger un modèle de la mémoire lorsqu’il n’est plus nécessaire. C’est une bonne habitude sur un VPS Linux : elle évite de conserver inutilement un modèle en RAM et limite les risques de saturation lors d’autres tâches serveur.

Utiliser l’API REST locale d’Ollama

L’un des grands intérêts d’Ollama sur VPS est de ne pas limiter l’usage du modèle au terminal. Une fois le service installé, vous pouvez interroger votre LLM AI open source depuis une application, un script, un outil d’automatisation ou un service interne. Ollama documente une API locale servie par défaut sur http://localhost:11434/api, utilisable notamment avec curl.

Cette approche est pratique pour transformer votre VPS Linux en brique IA privée. Par exemple, un script Python peut envoyer un texte à résumer, une application métier peut générer une réponse automatique, ou un workflow n8n peut appeler le modèle pour classer des contenus. Dans tous les cas, l’appel reste local au VPS tant que vous utilisez localhost.

Le point important est de bien distinguer deux usages. D’un côté, l’API native Ollama, avec des endpoints comme /api/generate ou /api/chat. De l’autre, l’endpoint compatible OpenAI, qui permet d’adapter certains scripts déjà conçus pour l’écosystème OpenAI en changeant l’URL de base. Cette compatibilité est utile, mais elle doit toujours être testée avec la version d’Ollama installée avant une mise en production.

1. Appel simple depuis le terminal

Pour tester l’API REST locale d’Ollama, vous pouvez envoyer une requête simple vers /api/generate. La documentation officielle donne ce type d’appel comme exemple d’utilisation de l’API locale.

curl http://localhost:11434/api/generate \
  -d '{
    "model": "mistral",
    "prompt": "Explique le swap Linux en 3 phrases.",
    "stream": false
  }'

Le paramètre "model" indique le modèle à utiliser. Il doit correspondre à un modèle déjà téléchargé avec ollama pull. Le paramètre "prompt" contient la demande envoyée au modèle IA local. Enfin, "stream": false demande à Ollama de retourner la réponse complète en une seule fois, ce qui simplifie la lecture dans le terminal ou dans un script.

Si le modèle n’est pas encore installé, Ollama ne pourra pas générer de réponse avec ce nom. Dans ce cas, vérifiez les modèles disponibles localement avec :

ollama list

Ce premier appel API permet de confirmer que votre LLM local sans API cloud peut être utilisé autrement que via ollama run.

2. Endpoint compatible OpenAI

Ollama propose aussi une compatibilité avec plusieurs endpoints au format OpenAI, dont /v1/chat/completions. La documentation officielle indique que cet endpoint prend en charge les chat completions, le streaming, le mode JSON, les sorties reproductibles, la vision, les outils et certains paramètres de raisonnement selon les modèles utilisés.

Cette compatibilité permet d’adapter un script existant en remplaçant principalement l’URL de base par celle d’Ollama. Voici un exemple simple avec Python et la bibliothèque requests :

import requests

response = requests.post(
    "http://localhost:11434/v1/chat/completions",
    json={
        "model": "mistral",
        "messages": [
            {
                "role": "user",
                "content": "Résume ce texte en 3 points : ..."
            }
        ],
        "stream": False
    },
    timeout=120
)

response.raise_for_status()
data = response.json()
print(data["choices"][0]["message"]["content"])

Dans cet exemple, l’application ne contacte pas une API externe : elle interroge votre VPS KVM LWS sur localhost. C’est précisément ce qui rend l’approche intéressante pour un projet qui traite des données sensibles ou qui veut éviter des coûts variables à chaque requête.

Avant de migrer un script complet, testez toujours les paramètres utilisés. Certains champs OpenAI peuvent ne pas se comporter exactement comme avec une API cloud, notamment selon le modèle, la version d’Ollama et les capacités activées. Pour un usage stable, commencez avec des requêtes simples, puis ajoutez progressivement le streaming, le mode JSON ou les outils si votre modèle les prend en charge.

Sécuriser l’accès à Ollama

La sécurité est un point central lorsque vous installez une IA open source auto-hébergée sur un VPS. Par défaut, l’usage local d’Ollama ne nécessite pas d’authentification lorsqu’il est appelé depuis http://localhost:11434. La documentation officielle précise qu’aucune authentification n’est requise pour accéder localement à l’API Ollama via cette adresse.

Ce comportement est adapté à une installation initiale : votre API IA locale reste disponible pour les scripts exécutés sur le VPS, sans être exposée directement sur Internet. Il ne faut donc pas ouvrir le port 11434 publiquement sans protection. Un LLM local peut recevoir des prompts sensibles, consommer fortement le CPU et être détourné si l’accès est mal sécurisé.

Si vous devez accéder à Ollama depuis l’extérieur, évitez d’exposer directement le service avec une configuration trop permissive. Préférez un reverse proxy Nginx avec HTTPS, authentification, restrictions IP ou mécanisme de clé API côté application. Vous pouvez aussi limiter l’accès à un VPN ou à un tunnel sécurisé. L’objectif est simple : ne jamais laisser une API de génération IA accessible librement sur l’IP publique de votre VPS.

Pendant les tests, surveillez aussi la consommation de ressources depuis le Panel KVM LWS. Au moment de l’interaction avec Ollama, nous avons effectivement constaté au pic comme le graphique ci-dessous :

Une génération longue peut utiliser fortement le CPU et augmenter la mémoire consommée. Cette supervision permet d’identifier rapidement un modèle trop lourd, une file de requêtes trop importante ou un risque de ralentissement général du serveur. Pour en savoir plus, découvrez comment sécuriser l’accès à votre API Ollama derrière un reverse proxy Nginx.

Option avancée — Open WebUI : interface graphique pour Ollama

L’utilisation d’Ollama en ligne de commande suffit pour tester un LLM AI open source ou l’intégrer dans un script. En revanche, si vous souhaitez offrir une interface plus simple à un utilisateur non technique, vous pouvez ajouter Open WebUI. Il s’agit d’une interface web auto-hébergée compatible avec Ollama et avec des API compatibles OpenAI. Le projet se présente comme une plateforme IA self-hosted, utilisable hors ligne, avec des fonctions comme la gestion de plusieurs modèles et le RAG.

La méthode Docker officielle expose l’interface sur le port 3000 du serveur, avec un volume persistant pour conserver les données de l’application. La documentation Open WebUI rappelle que le volume open-webui:/app/backend/data est important pour éviter la perte de données lors des redémarrages ou mises à jour.

docker pull ghcr.io/open-webui/open-webui:main

docker run -d \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Une fois le conteneur lancé, Open WebUI est disponible côté serveur sur le port 3000. Si vous l’utilisez uniquement en local depuis le VPS, gardez l’accès restreint. Si vous souhaitez ouvrir l’interface depuis Internet, placez-la derrière un reverse proxy Nginx, activez le HTTPS, ajoutez une authentification et évitez toute exposition directe non protégée.

Attention également à la connexion entre Open WebUI et Ollama. Si Ollama tourne sur l’hôte Linux et Open WebUI dans un conteneur Docker, localhost ne désigne pas toujours le même environnement. La documentation Open WebUI signale que le conteneur peut ne pas atteindre Ollama sur 127.0.0.1:11434 et mentionne l’usage de --network=host comme solution dans certains cas, avec un port d’accès qui peut alors changer.

Pour une installation de production, évitez les tags trop mouvants si vous souhaitez stabiliser votre environnement. Open WebUI recommande de pouvoir épingler une version précise plutôt que d’utiliser uniquement un tag flottant comme main.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Cas d’usage concrets sur un VPS LWS

Un LLM open source sur VPS devient intéressant dès que vous avez besoin d’automatiser des traitements IA tout en gardant la maîtrise du serveur :

• Le premier cas d’usage concerne les documents confidentiels : contrats, rapports internes, comptes rendus, cahiers des charges ou notes techniques. Plutôt que d’envoyer ces contenus vers une API externe, vous pouvez les traiter sur votre propre VPS, avec un modèle local adapté au volume et à la sensibilité des données.
• Le deuxième cas d’usage est l’automatisation via API REST. Ollama peut être appelé depuis un script Python, une application Node.js, une tâche cron ou un outil d’automatisation. L’intérêt est de générer des résumés, classer des textes, reformuler des contenus, préparer des brouillons ou enrichir une base interne sans coût à chaque requête. Les intégrations n8n documentent d’ailleurs un nœud Ollama permettant d’utiliser un modèle local dans des workflows d’automatisation.
• Troisième cas : connecter votre LLM local Ollama à WordPress 7.0 dans une logique de provider IA local. Dans ce scénario, WordPress ou une extension métier peut déléguer certaines tâches à l’API Ollama hébergée sur le même VPS ou sur un VPS privé. L’avantage est de garder les appels IA dans une infrastructure maîtrisée, sans dépendre systématiquement d’une clé API externe.

Enfin, un assistant de développement local peut être utile pour travailler sur du code propriétaire. Des outils comme Continue documentent l’usage de modèles auto-hébergés et expliquent que, lorsqu’une API est compatible OpenAI, il est souvent possible de configurer un provider OpenAI en changeant l’URL de base vers le serveur concerné. Pour un développeur, cela permet d’obtenir une assistance au codage, des explications ou des résumés sans envoyer automatiquement le code vers un service cloud tiers.

Vérification du bon fonctionnement

Après l’installation, le téléchargement du modèle et les premiers tests, prenez le temps de vérifier que votre IA open source auto-hébergée fonctionne correctement. Cette étape permet d’identifier rapidement une erreur de service, un modèle absent, une API inaccessible ou un problème de ressources.

Commencez par contrôler le service :

systemctl status ollama

Le service doit être indiqué comme active (running). Vérifiez ensuite que l’API répond localement :

curl http://localhost:11434/

Le message attendu est :

Ollama is running

Listez ensuite les modèles installés :

ollama list

Vous devez retrouver le modèle téléchargé, par exemple Mistral, avec sa taille. Lancez enfin une session interactive :

ollama run mistral

Posez une question simple en français et vérifiez que le modèle répond correctement. Pendant cette génération, ouvrez la supervision du Panel KVM LWS. Un pic CPU peut apparaître : c’est normal, car l’inférence CPU mobilise fortement les ressources pendant la génération. Si la RAM est saturée ou si le serveur devient difficile à utiliser, le modèle choisi est probablement trop lourd pour votre VPS.

Erreurs fréquentes et cas de blocage

L’installation d’un modèle IA local sur VPS reste accessible, mais certains blocages sont fréquents. La plupart proviennent d’un modèle trop volumineux, d’un mauvais nom de tag, d’un service arrêté ou d’une exposition réseau mal comprise.

En cas de doute, commencez toujours par revenir aux tests simples : service actif, API locale joignable, modèle visible avec ollama list, puis test interactif avec ollama run. Cette méthode évite de chercher trop vite un problème applicatif alors que la cause vient souvent d’un modèle absent ou d’un service non démarré. Et pour sécuriser votre instance, il faut configurer le swap pour éviter les erreurs mémoire pendant l’inférence.

Bonnes pratiques

Une fois votre LLM AI open source installé sur le VPS, l’objectif est de conserver un environnement stable, sécurisé et facile à maintenir. La première bonne pratique consiste à surveiller régulièrement l’espace disque. Les modèles peuvent peser plusieurs gigaoctets chacun, et il est facile d’accumuler des versions inutilisées après plusieurs tests. Pour faire le point, utilisez :

ollama list

Si un modèle n’est plus utile, supprimez-le proprement :

ollama rm nom-du-modele

Surveillez aussi la mémoire RAM et la charge CPU depuis le Panel KVM LWS. Si le serveur utilise constamment le swap ou devient très lent pendant l’inférence, cela signifie généralement que le modèle est trop lourd pour les ressources disponibles. Dans ce cas, passez à un modèle plus petit avant d’envisager une montée en gamme.

Côté sécurité, ne publiez jamais le port 11434 directement sur l’IP publique de votre VPS. Ollama indique que l’API locale ne nécessite pas d’authentification lorsqu’elle est appelée depuis http://localhost:11434, ce qui est adapté à un usage local mais dangereux si le service est exposé sans protection. Pour un accès externe, privilégiez un reverse proxy Nginx, le HTTPS, une authentification et, si possible, des restrictions IP.

Avant de tester un nouveau modèle volumineux, créez un snapshot LWS. Cette précaution permet de revenir rapidement à un état stable si le téléchargement remplit le disque, si une dépendance pose problème ou si la configuration doit être annulée.

Enfin, vérifiez régulièrement votre version d’Ollama :

ollama --version

Les outils IA évoluent vite. Des mises à jour peuvent améliorer la compatibilité des modèles, la stabilité de l’API ou les performances d’inférence CPU. Pour un usage de production, évitez toutefois de modifier votre environnement sans test préalable.

FAQ

Peut-on faire tourner un LLM open source sur un VPS sans GPU ?
Oui, il est possible de faire tourner un LLM open source sur un VPS sans GPU, mais avec des performances plus modestes qu’une infrastructure équipée d’une carte graphique. Sur un VPS CPU-only, il faut privilégier des modèles légers, par exemple des modèles 3B, 4B, 7B ou 8B selon la RAM disponible.

Quelle est la différence entre Ollama et une API IA comme OpenAI ?
Une API IA cloud est hébergée par un fournisseur externe et facturée selon l’usage ou l’abonnement. Ollama, lui, exécute le modèle localement sur votre serveur. Vous gardez la maîtrise de l’environnement, mais vous devez gérer les ressources, les mises à jour, la sécurité et les modèles installés.

Quels modèles Ollama fonctionnent sur un VPS avec 8 Go de RAM ?
Avec 8 Go de RAM, il est préférable de commencer par des modèles compacts comme Phi-3 Mini, Gemma 3 4B ou d’autres modèles de petite taille disponibles dans la bibliothèque Ollama. Les modèles 7B ou 8B peuvent être trop lourds selon les autres services actifs sur le VPS.

Ollama expose-t-il l’IA publiquement sur Internet par défaut ?
Non. Ollama documente une API locale accessible par défaut sur http://localhost:11434/api, ce qui signifie qu’elle répond depuis la machine locale. La FAQ Ollama précise également que le service se lie par défaut à 127.0.0.1 sur le port 11434.

Comment connecter Ollama à une interface graphique sur mon VPS ?
Vous pouvez installer une interface comme Open WebUI, qui fournit une interface web compatible avec Ollama. Pour un accès depuis Internet, il faut impérativement sécuriser l’interface avec HTTPS, authentification et reverse proxy.

L’utilisation d’Ollama sur VPS est-elle conforme au RGPD ?
Ollama peut aider à limiter les transferts de données vers des services IA externes, car les prompts et réponses restent sur votre infrastructure si tout est configuré localement. Cela ne garantit pas automatiquement la conformité RGPD : vous devez aussi sécuriser le VPS, gérer les accès, documenter les traitements et respecter les obligations applicables aux données personnelles.

Conclusion

Déployer un LLM AI open source sur un VPS permet de créer une solution d’IA auto-hébergée, utile pour réduire la dépendance aux API cloud, mieux maîtriser les données et expérimenter des traitements IA sans coût à chaque requête. Avec Ollama, l’installation reste accessible : un service local, quelques commandes, un modèle adapté aux ressources du serveur et une API REST exploitable dans vos scripts ou applications. La clé est de rester réaliste : sur un VPS sans GPU, privilégiez les modèles légers, surveillez la RAM, gardez le port 11434 privé et sécurisez tout accès externe.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Pour héberger ce type d’environnement, un VPS KVM LWS offre l’accès root, la supervision, les snapshots et les ressources nécessaires pour tester puis exploiter votre propre modèle IA local. Et si vous avez des questions, des ajouts ou des suggestions, n’hésitez pas à nous écrire dans la section Commentaires.

En vérifiant l’état du serveur avec la commande free -h, on constate parfois qu’aucun swap n’est configuré. Dans d’autres cas, le swap VPS Linux existe déjà, mais il est utilisé en permanence alors que de la RAM semble encore disponible. Cette situation indique souvent une configuration mémoire inadaptée à un serveur en production. Bien configuré, le swap Linux permet d’absorber certains pics de charge et de limiter les interruptions brutales.

Objectif

L’objectif de ce tutoriel est de vous montrer comment créer un fichier swap sur un VPS Linux, l’activer correctement, puis le rendre persistant après redémarrage. La procédure présentée s’adresse principalement aux serveurs sous Debian et Ubuntu, deux distributions très utilisées pour l’hébergement de sites web, d’applications ou de services en ligne. Nous verrons comment créer le fichier swap avec fallocate, comment le sécuriser avec les bonnes permissions, puis comment l’activer avec mkswap et swapon. Vous apprendrez aussi à modifier le fichier /etc/fstab afin que le swap reste actif après chaque redémarrage du VPS. Enfin, nous aborderons l’optimisation de deux paramètres importants du noyau Linux : vm.swappiness et vm.vfs_cache_pressure. Ces réglages permettent de mieux contrôler l’utilisation du swap et d’adapter le comportement mémoire à un serveur VPS en production.

Pré-requis

Avant de suivre ce guide, vous devez :

• disposer d’un VPS Linux sous Debian 11/12 ou Ubuntu 22.04/24.04, avec un accès SSH root ou un utilisateur autorisé à utiliser sudo. Sur un VPS KVM LWS, les identifiants de connexion sont généralement transmis dans l’email de confirmation de commande, ce qui permet d’administrer rapidement le serveur en ligne de commande,
• connaître les bases de la ligne de commande Linux : vous connecter en SSH, exécuter une commande, lire un résultat dans le terminal et modifier un fichier avec un éditeur comme nano,
• Aucune compétence avancée en administration système n’est nécessaire, mais chaque commande doit être exécutée avec attention, notamment lors de la modification de fichiers système comme /etc/fstab,
• vérifier l’espace disque disponible avant de créer un fichier swap.

Comprendre le swap Linux : ce que c’est réellement

Le swap Linux est un espace situé sur le disque que le noyau peut utiliser lorsque la mémoire RAM disponible devient insuffisante. Concrètement, Linux déplace certaines pages mémoire peu utilisées vers le swap afin de libérer de la RAM pour les processus les plus actifs.

Sur un VPS Linux, ce mécanisme peut éviter qu’un service soit interrompu brutalement lors d’un pic de consommation mémoire. Par exemple, un site WordPress, une application Node.js, un processus PHP-FPM ou une base de données peuvent consommer plus de RAM que prévu pendant une mise à jour, un trafic important ou une tâche lourde. Sans fichier swap, le noyau Linux peut alors tuer un processus pour protéger le système. C’est ce qui provoque souvent une erreur OOM.

Le swap agit donc comme une réserve de secours. Il donne au système une marge supplémentaire lorsque la RAM physique arrive à saturation. Cette marge peut suffire à stabiliser un serveur pendant un pic ponctuel, à éviter l’arrêt d’un service critique ou à laisser le temps à l’administrateur d’identifier la cause du problème.

Il ne faut cependant pas confondre swap et RAM physique. La RAM est conçue pour des accès extrêmement rapides, tandis que le swap repose sur le disque. Même avec un disque SSD NVMe, le swap reste beaucoup plus lent. Un serveur qui utilise constamment son swap n’est donc pas réellement optimisé : il manque probablement de mémoire vive.

Dans le cadre d’un swap VPS Linux, l’objectif n’est pas de transformer le disque en RAM, mais de réduire les risques de crash lors de pics temporaires. Si le swap est sollicité en permanence, il faut envisager une optimisation applicative ou une montée en gamme vers un VPS disposant de plus de RAM.

Deux formes de swap sous Linux

Sous Linux, le swap peut être configuré de deux manières principales : sous forme de fichier swap ou sous forme de partition swap. Les deux méthodes poursuivent le même objectif : fournir au système un espace disque utilisable lorsque la RAM disponible devient insuffisante. En revanche, elles ne présentent pas la même souplesse, surtout dans le contexte d’un VPS Linux déjà installé.

Sur un VPS KVM LWS, la méthode la plus adaptée est généralement le fichier swap. Elle ne nécessite pas de repartitionner le disque, ne demande pas de réinstallation du système et peut être ajustée plus facilement si vos besoins évoluent. Vous pouvez créer un fichier de 2 Go, le remplacer plus tard par un fichier de 4 Go, ou le supprimer si nécessaire.

La partition swap, elle, est plutôt prévue au moment de l’installation initiale d’un système. Sur un serveur déjà en production, la modifier peut être plus risqué, car cela touche à la structure du disque. Pour un administrateur VPS qui souhaite une solution rapide, propre et réversible, le fichier swap Linux est donc la méthode à privilégier.

Ce que le swap n’est pas

Le swap VPS Linux est utile, mais il ne doit pas être mal interprété. Il ne s’agit pas d’un remplacement de la RAM physique. La RAM reste beaucoup plus rapide que le disque, même lorsque le VPS utilise un stockage SSD NVMe. Lorsqu’un serveur commence à utiliser intensivement son swap, les performances peuvent donc se dégrader : les pages mémoire doivent être lues et écrites sur le disque, ce qui ralentit les traitements.

Le swap n’est pas non plus une solution durable à un manque chronique de mémoire. Si votre serveur utilise constamment son fichier swap, cela signifie souvent que les applications installées consomment plus de RAM que le VPS ne peut en fournir. Dans ce cas, il faut analyser les processus actifs, optimiser les services ou envisager une offre avec davantage de mémoire.

Enfin, le swap ne protège pas absolument contre toutes les erreurs OOM. Il réduit les risques lors de pics ponctuels, mais il ne peut pas compenser une saturation permanente. Il doit être vu comme un filet de sécurité mémoire, pas comme une extension magique de la RAM.

Une bonne configuration consiste donc à créer un swap raisonnable, à ajuster vm.swappiness, puis à surveiller régulièrement la mémoire. Si le swap reste fortement utilisé pendant plusieurs jours, le vrai problème n’est probablement pas la configuration : c’est le dimensionnement du VPS.

Vérifier l’état actuel de la mémoire et du swap

Avant de créer un fichier swap, il faut toujours commencer par vérifier l’état actuel de la mémoire RAM, du swap et de l’espace disque disponible. Cette étape permet d’éviter deux erreurs fréquentes : créer un swap inutile alors qu’il existe déjà, ou créer un fichier trop volumineux sur une partition presque pleine.

Sur un VPS Linux, le diagnostic repose principalement sur trois commandes simples :

• free -h pour afficher l’utilisation de la RAM et du swap ;
• swapon --show pour vérifier si un swap est actif ;
• df -h / pour contrôler l’espace disque disponible sur la partition principale.

Ces commandes doivent être exécutées en SSH, avec un utilisateur disposant des droits nécessaires. Elles ne modifient rien sur le serveur : elles servent uniquement à observer l’état actuel du système avant de passer à la configuration.

1. Afficher l’utilisation de la RAM et du swap

La première commande à utiliser est free -h. Elle affiche l’état de la mémoire RAM et du swap dans un format lisible, avec des unités comme MiB ou GiB.

free -h

Exemple de sortie typique sur un VPS Linux sans swap configuré :

               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       856Mi       124Mi        12Mi       982Mi       852Mi
Swap:             0B          0B          0B

Dans cet exemple, la ligne Swap affiche 0B. Cela signifie qu’aucun swap n’est disponible sur le serveur. Si la RAM vient à manquer, le noyau Linux n’aura donc pas d’espace de secours sur le disque. Le risque d’erreur OOM est alors plus élevé en cas de pic de charge.

Il faut aussi bien interpréter les colonnes de la ligne Mem. La colonne free indique uniquement la mémoire totalement libre, mais ce n’est pas toujours la valeur la plus importante. Sous Linux, une partie de la RAM est utilisée comme cache disque afin d’améliorer les performances. Cette mémoire peut être récupérée si une application en a besoin.

La colonne la plus utile est donc souvent available. Elle indique la mémoire réellement disponible pour de nouveaux processus, en tenant compte de la mémoire libre et du cache récupérable. Une valeur free faible n’est donc pas forcément inquiétante si la valeur available reste confortable.

2. Vérifier si un swap est déjà configuré

Après avoir consulté l’état global de la mémoire avec free -h, il est utile de vérifier plus précisément si un swap Linux est déjà actif sur le VPS. Pour cela, utilisez la commande suivante :

swapon --show

Si aucun résultat ne s’affiche, cela signifie qu’aucun fichier swap ni aucune partition swap n’est actuellement activé sur le serveur.

Exemple de résultat vide :

swapon --show

Dans ce cas, la commande revient simplement à la ligne suivante sans afficher de tableau. C’est le comportement attendu lorsque le VPS Linux ne dispose pas encore de swap actif.

Si un swap est configuré, la commande affiche généralement plusieurs informations : le chemin du fichier ou de la partition, le type de swap, sa taille, son niveau d’utilisation et sa priorité.

Exemple :

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

3. Vérifier l’espace disque disponible avant de créer le swap

Avant de créer un fichier swap, vous devez vérifier que la partition principale dispose de suffisamment d’espace disque libre. Un fichier swap occupe réellement de l’espace sur le disque. Par exemple, un swap de 2 Go réduit d’autant l’espace disponible pour le système, les sites web, les bases de données, les logs et les sauvegardes locales.

Pour contrôler l’espace disponible sur la partition racine, utilisez :

df -h /

Exemple de sortie :

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   12G   26G  32% /

Dans cet exemple, la colonne Avail indique qu’il reste 26 Go disponibles sur la partition /. Il est donc possible de créer un fichier swap de 2 Go sans risque immédiat.

En revanche, si la partition est déjà utilisée à plus de 85 % ou 90 %, évitez de créer un swap volumineux sans nettoyage préalable. Un disque saturé peut provoquer d’autres problèmes : impossibilité d’écrire des logs, erreurs applicatives, échec des mises à jour ou blocage de certains services.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Créer un fichier swap

Une fois l’état de la RAM, du swap et du disque vérifié, vous pouvez passer à la création du fichier swap. Cette méthode est particulièrement adaptée à un VPS Linux, car elle ne nécessite pas de modifier les partitions existantes.

Le principe est simple : vous créez un fichier dédié, vous limitez ses permissions, vous le formatez comme espace de swap, puis vous l’activez. Ensuite, vous pourrez le rendre persistant au redémarrage dans le fichier /etc/fstab.

Dans ce guide, nous allons créer un fichier nommé /swapfile. C’est un nom courant, simple à identifier et facile à maintenir. Vous pouvez choisir un autre chemin, mais il est conseillé de rester sur une convention claire pour éviter les erreurs lors des futures interventions.

1. Créer le fichier avec fallocate

La méthode la plus simple pour créer un fichier swap Linux consiste à utiliser la commande fallocate. Elle permet de réserver rapidement un fichier de la taille souhaitée.

Pour créer un swap de 2 Go, exécutez :

sudo fallocate -l 2G /swapfile

Cette commande crée un fichier nommé /swapfile à la racine du système. L’option -l 2G indique la taille souhaitée, ici 2 Go.

Vous pouvez vérifier que le fichier a bien été créé avec :

ls -lh /swapfile

Exemple de résultat :

-rw-r--r-- 1 root root 2.0G Jun 10 14:22 /swapfile

À ce stade, le fichier existe, mais il n’est pas encore sécurisé, formaté ni activé comme swap. Les étapes suivantes sont donc indispensables.

Si fallocate n’est pas disponible ou si le système de fichiers ne le prend pas en charge, utilisez dd comme alternative :

sudo dd if=/dev/zero of=/swapfile bs=1024 count=2097152

Quelle taille choisir ?

La taille idéale du swap VPS Linux dépend de la quantité de RAM physique, du type d’applications hébergées et du niveau de sécurité souhaité contre les pics mémoire. Il n’existe pas de règle universelle, mais les repères suivants conviennent à de nombreux usages sur serveur.

Pour un VPS Linux avec 2 Go de RAM, un fichier swap de 2 Go constitue souvent un bon point de départ. Vous pouvez monter à 4 Go si le serveur exécute des tâches ponctuellement gourmandes, comme des builds applicatifs, des traitements d’images, des sauvegardes compressées ou des opérations de maintenance lourdes.

Attention toutefois à ne pas surdimensionner le swap. Un fichier swap très volumineux ne remplace pas une vraie montée en RAM. Si le serveur utilise constamment plusieurs gigaoctets de swap, les performances seront fortement dégradées. Dans ce cas, il vaut mieux analyser les processus actifs ou envisager un VPS KVM LWS avec davantage de mémoire.

2. Sécuriser les permissions du fichier swap

Avant d’activer le fichier swap, il est indispensable de corriger ses permissions. Par défaut, après sa création avec fallocate, le fichier peut être lisible par d’autres utilisateurs du système. Or, un fichier swap Linux peut contenir temporairement des fragments de mémoire issus de processus actifs. Il doit donc être strictement réservé à l’utilisateur root.

Appliquez les permissions suivantes :

sudo chmod 600 /swapfile

Cette commande donne les droits de lecture et d’écriture uniquement à root. Aucun autre utilisateur du serveur ne peut lire ou modifier le fichier.

Vous pouvez vérifier les permissions avec :

ls -lh /swapfile

Le résultat attendu doit ressembler à ceci :

-rw------- 1 root root 2.0G Jun 10 14:22 /swapfile

Les permissions -rw------- indiquent que seul root peut accéder au fichier. Cette étape est importante pour la sécurité, mais aussi pour le bon fonctionnement du swap VPS Linux. Si les permissions sont trop ouvertes, par exemple en 0644, le noyau Linux peut refuser d’activer le swap et afficher une erreur du type :

swapon: /swapfile: insecure permissions 0644, 0600 suggested.

Dans ce cas, il suffit de relancer :

sudo chmod 600 /swapfile

Puis de reprendre la procédure d’activation.

3. Formater le fichier en espace de swap

Le fichier /swapfile existe désormais et ses permissions sont correctes, mais il ne peut pas encore être utilisé comme swap Linux. Il faut d’abord le formater avec la commande mkswap.

Exécutez :

sudo mkswap /swapfile

Cette commande prépare le fichier pour qu’il soit reconnu par le noyau comme un espace de swap valide.

Exemple de sortie possible :

Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=2f4b7d9e-2d91-4b84-91c7-9e8d2c8f2b31

Le système indique ici que le fichier a bien été configuré comme swap. L’UUID affiché peut être différent sur votre serveur : c’est normal, il est généré automatiquement.

Cette étape est obligatoire. Si vous tentez d’activer le fichier avec swapon sans avoir exécuté mkswap, vous risquez d’obtenir une erreur comme :

swapon: /swapfile: read swap header failed

Dans ce cas, relancez simplement :

sudo mkswap /swapfile

Puis continuez avec l’activation du swap.

4. Activer le swap

Une fois le fichier créé, sécurisé et formaté, vous pouvez activer le swap avec la commande swapon.

Exécutez :

sudo swapon /swapfile

La commande ne retourne généralement aucun message si tout s’est bien passé. C’est un comportement normal sous Linux : l’absence d’erreur signifie que le fichier swap a été activé correctement.

À partir de ce moment, le noyau peut utiliser /swapfile comme espace mémoire secondaire lorsque la RAM devient insuffisante. Le serveur dispose donc d’une marge supplémentaire pour absorber certains pics de charge et limiter les risques d’erreur OOM.

Avant d’aller plus loin, il faut vérifier que le swap est bien actif.

5. Vérifier que le swap est actif

Pour confirmer que le swap VPS Linux est bien activé, utilisez d’abord :

swapon --show

Vous devriez obtenir un résultat similaire :

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

Ce tableau confirme que le fichier /swapfile est reconnu comme espace de swap. La colonne SIZE indique sa taille totale, ici 2 Go. La colonne USED indique la quantité actuellement utilisée. Juste après l’activation, elle peut afficher 0B, ce qui est normal si la RAM disponible est suffisante.

Vous pouvez également vérifier avec :

free -h

Exemple de résultat après activation :

               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       870Mi       110Mi        12Mi       980Mi       830Mi
Swap:          2.0Gi          0B       2.0Gi

La ligne Swap affiche maintenant une valeur non nulle. Cela signifie que le fichier swap est bien opérationnel.

À ce stade, le VPS Linux dispose d’un swap actif, mais uniquement pour la session système en cours. Pour éviter de devoir relancer manuellement swapon /swapfile après chaque redémarrage, il faut maintenant rendre cette configuration persistante.

Rendre le swap persistant au redémarrage

À ce stade, le fichier swap est actif, mais uniquement pour la session en cours. Cela signifie qu’il fonctionne tant que le VPS Linux reste démarré. En revanche, après un redémarrage du serveur, le système ne réactivera pas automatiquement /swapfile si aucune entrée n’a été ajoutée dans le fichier /etc/fstab.

Le fichier /etc/fstab sert à indiquer au système quels volumes, partitions ou espaces spéciaux doivent être montés ou activés au démarrage. Pour rendre le swap VPS Linux persistant, il faut donc y ajouter une ligne spécifique.

Cette étape doit être réalisée avec attention. Une erreur dans /etc/fstab peut provoquer des problèmes au démarrage du serveur. C’est pourquoi il est recommandé de sauvegarder le fichier avant toute modification.

1. Sauvegarder /etc/fstab avant modification

Avant de modifier /etc/fstab, créez une copie de sauvegarde. Cette précaution permet de restaurer le fichier d’origine en cas d’erreur de saisie ou de mauvaise manipulation.

Exécutez la commande suivante :

sudo cp /etc/fstab /etc/fstab.bak

Cette commande crée une sauvegarde nommée /etc/fstab.bak. Elle ne modifie pas la configuration actuelle du serveur.

Vous pouvez vérifier que la sauvegarde existe avec :

ls -lh /etc/fstab.bak

Exemple de résultat :

-rw-r--r-- 1 root root 625 Jun 10 14:35 /etc/fstab.bak

Cette sauvegarde est particulièrement utile avant toute intervention sur un fichier système sensible. Sur un VPS en production, il est également conseillé de créer un snapshot depuis le panel d’administration avant de modifier une configuration liée au démarrage.

En cas de problème, cette copie vous permettra de comparer les deux fichiers ou de restaurer rapidement la version précédente.

2. Ajouter le swap dans /etc/fstab

Pour que le fichier swap soit automatiquement activé à chaque démarrage du VPS Linux, ajoutez la ligne suivante à la fin du fichier /etc/fstab :

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Cette commande ajoute l’entrée nécessaire sans ouvrir manuellement le fichier. Le point important est l’option -a utilisée avec tee. Elle signifie append, c’est-à-dire “ajouter à la fin du fichier”.

Sans cette option, vous pourriez écraser le contenu existant de /etc/fstab, ce qui serait problématique. Le fichier contient souvent des informations essentielles sur la partition racine, les volumes montés et d’autres éléments nécessaires au bon démarrage du système.

La ligne ajoutée signifie :

• /swapfile : chemin du fichier swap ;
• none : aucun point de montage classique n’est nécessaire ;
• swap : type d’espace utilisé ;
• sw : option standard pour activer le swap ;
• 0 0 : options liées à la sauvegarde et à la vérification du système de fichiers, inutiles ici.

Grâce à cette configuration, le swap Linux sera automatiquement pris en compte lors des prochains redémarrages.

3. Vérifier le contenu ajouté

Après avoir modifié /etc/fstab, vérifiez toujours que la ligne a bien été ajoutée. Utilisez par exemple :

tail -3 /etc/fstab

Vous devriez voir apparaître une ligne similaire à celle-ci :

/swapfile none swap sw 0 0

Si cette ligne est présente, la configuration de persistance est correcte.

Vous pouvez également afficher tout le fichier avec :

cat /etc/fstab

Vérifiez que le contenu existant n’a pas été supprimé et que la ligne du swap se trouve bien en plus des autres entrées. Cette vérification est importante, car une mauvaise modification de /etc/fstab peut empêcher un VPS Linux de redémarrer normalement.

Pour tester la configuration sans redémarrer immédiatement, vous pouvez désactiver puis réactiver le swap :

sudo swapoff /swapfile
sudo swapon /swapfile

Ensuite, contrôlez à nouveau l’état du swap VPS Linux :

swapon --show
free -h

Si /swapfile apparaît bien dans swapon --show et que la ligne Swap est visible dans free -h, votre configuration est opérationnelle. Le fichier swap est maintenant actif et persistant après redémarrage.

Optimiser les paramètres noyau : swappiness et vfs_cache_pressure

Une fois le swap VPS Linux créé, activé et rendu persistant, il est important d’ajuster le comportement du noyau Linux. Par défaut, certains paramètres mémoire sont pensés pour un usage généraliste. Ils peuvent convenir à un poste de travail, mais ne sont pas toujours adaptés à un serveur VPS en production.

Deux réglages sont particulièrement utiles :

• vm.swappiness : il contrôle la tendance du système à utiliser le swap ;
• vm.vfs_cache_pressure : il influence la manière dont Linux conserve ou libère certains caches liés au système de fichiers.

Ces paramètres ne changent pas la quantité de RAM disponible. En revanche, ils permettent d’optimiser la façon dont le noyau arbitre entre mémoire vive, cache disque et fichier swap. Sur un VPS hébergeant un site web, une base de données ou une application, ce réglage peut améliorer la stabilité et limiter l’usage prématuré du swap.

1. vm.swappiness : contrôler l’agressivité du swap

Le paramètre vm.swappiness indique au noyau Linux à quel point il doit utiliser le swap plutôt que de conserver les données en RAM. Plus la valeur est élevée, plus le système aura tendance à déplacer des pages mémoire vers le swap. Plus elle est basse, plus Linux cherchera à conserver les données en RAM aussi longtemps que possible.

Sur de nombreuses distributions Linux, la valeur par défaut est souvent 60. Ce réglage peut être pertinent pour un usage polyvalent, mais il est généralement trop agressif pour un serveur VPS. Sur un serveur en production, on préfère que le swap serve de filet de sécurité, et non qu’il soit utilisé trop tôt.

Pour un VPS Linux, une valeur de 10 est souvent recommandée. Elle permet de limiter l’utilisation du swap aux situations où la pression mémoire devient réellement importante.

Pour consulter la valeur actuelle de vm.swappiness, utilisez :

cat /proc/sys/vm/swappiness

Pour appliquer immédiatement une valeur de 10, exécutez :

sudo sysctl vm.swappiness=10

Vérifiez ensuite que la modification est bien prise en compte :

cat /proc/sys/vm/swappiness

Vous devriez obtenir :

10

Cette modification est immédiate, mais elle n’est pas encore persistante après redémarrage. Pour conserver ce réglage, ajoutez-le dans /etc/sysctl.conf :

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

À partir de là, le VPS Linux utilisera une configuration plus adaptée à un contexte serveur. Le fichier swap restera disponible, mais le noyau évitera de l’utiliser trop tôt tant que la RAM physique peut encore absorber la charge.

2. vm.vfs_cache_pressure : contrôler la libération du cache inode/dentry

Le paramètre vm.vfs_cache_pressure contrôle la manière dont le noyau Linux libère certains caches liés au système de fichiers, notamment les inodes et les dentries. Ces éléments permettent au système de retrouver plus rapidement les informations sur les fichiers et les répertoires.

Par défaut, la valeur est souvent fixée à 100. Cela signifie que le noyau applique un comportement équilibré pour libérer ce cache. Sur un VPS Linux qui accède fréquemment à de nombreux fichiers, comme un serveur WordPress, un hébergement PHP ou une application avec beaucoup de fichiers statiques, réduire légèrement cette valeur peut aider à conserver plus longtemps ces informations en cache.

Une valeur de 50 est généralement utilisée pour inciter le système à libérer moins rapidement ce cache. Cela peut améliorer les performances dans certains contextes, car le serveur évite de relire trop souvent les mêmes informations sur le disque.

Pour appliquer immédiatement ce réglage, utilisez :

sudo sysctl vm.vfs_cache_pressure=50

Puis vérifiez la valeur active :

cat /proc/sys/vm/vfs_cache_pressure

Vous devriez obtenir :

50

Comme pour vm.swappiness, cette modification disparaîtra après redémarrage si elle n’est pas enregistrée dans /etc/sysctl.conf. Pour la rendre persistante, exécutez :

echo 'vm.vfs_cache_pressure=50' | sudo tee -a /etc/sysctl.conf

Ce réglage ne doit pas être considéré comme une solution miracle. Il permet d’affiner le comportement mémoire du noyau, mais il doit rester cohérent avec l’usage réel du serveur. Si le VPS manque fortement de RAM, ce paramètre ne suffira pas à compenser un mauvais dimensionnement.

3. Appliquer toutes les modifications persistantes sans redémarrer

Après avoir ajouté vm.swappiness et vm.vfs_cache_pressure dans /etc/sysctl.conf, vous pouvez demander au système de relire ce fichier sans redémarrer le VPS Linux.

Exécutez :

sudo sysctl -p

Exemple de résultat attendu :

vm.swappiness = 10
vm.vfs_cache_pressure = 50

Cette sortie confirme que les deux paramètres ont bien été chargés par le noyau. Vous pouvez également vérifier chaque valeur avec :

cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Résultat attendu :

10
50

À ce stade, votre swap VPS Linux est non seulement actif et persistant, mais aussi associé à des paramètres mémoire plus adaptés à un serveur en production. Le système évitera d’utiliser trop agressivement le swap, tout en conservant un cache fichier plus efficace.

Surveiller l’utilisation de la mémoire et du swap

Après avoir créé et optimisé le swap VPS Linux, il est important de surveiller son comportement dans le temps. Un fichier swap correctement configuré ne doit pas être utilisé en permanence. Il doit surtout servir de filet de sécurité lorsque la RAM approche temporairement de la saturation.

La surveillance permet de répondre à plusieurs questions importantes : le serveur dispose-t-il encore de suffisamment de mémoire disponible ? Le swap est-il utilisé ponctuellement ou constamment ? Certains processus consomment-ils trop de RAM ? Le VPS doit-il être optimisé ou redimensionné ?

Sur un VPS Linux, vous pouvez effectuer ce suivi directement en ligne de commande avec free, swapon, watch, htop ou via l’analyse des processus. Ces outils permettent d’obtenir une vision rapide de l’état mémoire du serveur, sans installer de solution de supervision complexe.

1. Vue en temps réel

Pour surveiller la RAM et le swap en temps réel, vous pouvez combiner free -h et swapon --show avec la commande watch. Celle-ci relance automatiquement une commande à intervalle régulier.

Exécutez :

watch -n 1 'free -h && echo "---" && swapon --show'

Cette commande met à jour l’affichage toutes les secondes. La première partie affiche l’état de la mémoire RAM, puis la ligne --- sépare visuellement les résultats, et swapon --show affiche les informations détaillées sur le swap actif.

Vous obtenez ainsi une vue pratique pour observer le comportement du serveur pendant une opération lourde : mise à jour système, sauvegarde, import de base de données, build applicatif, pic de trafic ou traitement planifié.

Surveillez surtout trois éléments :

• la colonne available dans free -h, qui indique la mémoire réellement disponible ;
• la ligne Swap, qui montre si le swap commence à être utilisé ;
• la colonne USED de swapon --show, qui indique la quantité de swap consommée.

Si le swap VPS Linux reste à 0B ou augmente seulement pendant de courts pics, le comportement est généralement sain. En revanche, si le swap augmente régulièrement et ne redescend jamais, cela peut révéler un manque de RAM ou une application trop gourmande.

2. Identifier les processus qui utilisent le swap

Lorsque le swap est utilisé, il peut être utile d’identifier les processus responsables. Linux expose de nombreuses informations dans le répertoire /proc, notamment la quantité de swap utilisée par chaque processus.

La commande suivante affiche les 10 processus qui consomment le plus de swap :

for file in /proc/*/status; do
  awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file
done | sort -k 2 -n -r | head -10

Cette commande parcourt les fichiers status des processus actifs, extrait le nom du processus et la valeur VmSwap, puis trie les résultats pour afficher les plus gros consommateurs en premier.

Exemple de résultat possible :

mysqld 524288 kB
php-fpm8.2 131072 kB
node 65536 kB
apache2 32768 kB

Cette analyse est particulièrement utile sur un VPS Linux qui héberge plusieurs services : serveur web, base de données, moteur PHP, application Node.js, tâches cron ou outils de sauvegarde. Elle permet d’éviter une conclusion trop rapide. Le problème ne vient pas toujours du swap lui-même : il vient souvent d’un processus qui consomme trop de mémoire.

Si un processus apparaît systématiquement en tête, analysez sa configuration avant d’augmenter la taille du fichier swap. Par exemple, il peut être plus efficace d’ajuster les paramètres de PHP-FPM, de réduire la mémoire allouée à une base de données ou de désactiver une extension trop lourde.

3. Lecture via htop

L’outil htop offre une lecture plus visuelle de l’utilisation des ressources système. Il permet d’observer la RAM, le swap, la charge CPU et les processus actifs dans une interface interactive en terminal.

Si htop n’est pas encore installé, vous pouvez l’ajouter avec :

sudo apt update
sudo apt install htop -y

htop

En haut de l’écran, htop affiche généralement des barres dédiées au CPU, à la mémoire RAM et au swap. Vous pouvez ainsi voir rapidement si le fichier swap est utilisé et dans quelle proportion.

Pour obtenir une lecture plus précise, vous pouvez ajouter une colonne dédiée au swap par processus :

• appuyez sur F2 pour ouvrir les paramètres ;
• allez dans Columns ;
• ajoutez la colonne SWAP si elle est disponible ;
• sauvegardez la configuration avec F10.

Cette vue est pratique pour repérer les services qui utilisent beaucoup de mémoire. Elle permet aussi de vérifier si le serveur revient à un état normal après une opération lourde. Par exemple, si le swap augmente pendant une sauvegarde puis se stabilise ensuite, le comportement peut être acceptable. Si le swap reste élevé en permanence, il faut approfondir le diagnostic.

Sur un VPS en production, htop ne remplace pas une supervision longue durée, mais il reste très utile pour un contrôle immédiat en SSH. Il complète les commandes free -h, swapon --show et l’analyse des processus via /proc.

4. Supervision depuis le Panel KVM LWS

En complément des commandes exécutées en SSH, le Panel KVM LWS permet de suivre l’état général de votre VPS Linux depuis une interface graphique. C’est une solution pratique lorsque vous souhaitez vérifier rapidement si le serveur subit une pression mémoire, sans ouvrir immédiatement une session terminal.

Depuis le Panel KVM LWS, vous pouvez consulter les graphiques de performance liés aux ressources du VPS, notamment l’utilisation du CPU, de la RAM et du réseau. Selon la configuration disponible dans votre interface, ces graphiques permettent d’observer l’évolution des ressources sur différentes périodes, par exemple sur quelques heures, plusieurs jours ou plusieurs semaines.

Cette supervision est particulièrement utile pour repérer les tendances. Une commande comme free -h donne une photographie instantanée de l’état mémoire, tandis qu’un graphique permet de voir si la RAM se remplit progressivement, si les pics sont ponctuels ou si le serveur reste sous pression pendant de longues périodes.

Pour accéder aux informations de performance, rendez-vous dans votre espace client LWS, puis dans la gestion de votre VPS KVM. Recherchez ensuite la rubrique liée à la supervision, aux graphiques de performance ou aux ressources serveur. Pour aller plus loin, consultez notre guide pour surveiller les ressources système avec le Panel KVM LWS.

Diagnostiquer un VPS qui swappe trop

Un swap VPS Linux bien configuré doit rester un mécanisme de secours. Il est normal qu’il soit utilisé ponctuellement lors d’un pic de charge, par exemple pendant une sauvegarde, un import de base de données, un traitement d’images ou un build applicatif. En revanche, un swap utilisé en permanence doit attirer votre attention.

Lorsqu’un VPS swappe trop, le serveur peut devenir lent même si les services restent actifs. Les pages mémoire sont alors déplacées entre la RAM et le disque, ce qui augmente les temps d’accès. Même sur un stockage SSD NVMe, cette opération reste beaucoup plus lente qu’un accès direct à la mémoire vive.

Le diagnostic consiste donc à comprendre si le swap est utilisé :

• de manière ponctuelle, pendant une tâche temporaire ;
• de manière régulière, lors de pics de trafic ;
• de manière chronique, même lorsque le serveur semble peu sollicité.

Dans les deux premiers cas, un fichier swap correctement dimensionné peut remplir son rôle. Dans le troisième cas, le problème vient souvent d’un manque structurel de RAM, d’un service mal configuré ou d’une application trop gourmande.

Symptôme fréquent : le swap est utilisé alors que la RAM n’est pas pleinement saturée

Un cas fréquent consiste à voir du swap utilisé alors que la RAM semble encore disponible. Cela peut surprendre, mais ce comportement est souvent lié au paramètre vm.swappiness. Si sa valeur est trop élevée, le noyau Linux peut déplacer des pages mémoire vers le swap plus tôt que nécessaire.

Vous pouvez observer ce type de situation avec :

free -h

Exemple simplifié :

               total        used        free      shared  buff/cache   available
Mem:           2.0Gi       1.2Gi       300Mi        20Mi       500Mi       800Mi
Swap:          2.0Gi       500Mi       1.5Gi

Si vm.swappiness est encore à sa valeur par défaut, par exemple 60, vous pouvez appliquer une valeur plus adaptée à un serveur VPS, comme vu précédemment :

sudo sysctl vm.swappiness=10

Puis vérifiez :

cat /proc/sys/vm/swappiness

Si le résultat est bien 10, le noyau sera moins agressif dans son utilisation du swap Linux. Le swap restera disponible en cas de pression mémoire réelle, mais il sera moins sollicité lorsque la RAM peut encore absorber la charge.

Forcer la libération du swap (si la RAM est disponible)

Dans certains cas, vous pouvez vouloir vider le swap après un pic de charge terminé. Par exemple, une tâche lourde a consommé beaucoup de mémoire, le serveur a utilisé le swap, puis la charge est revenue à la normale. Si la RAM disponible est suffisante, il est possible de désactiver puis réactiver le swap pour forcer Linux à rapatrier son contenu en mémoire vive.

La commande est la suivante :

sudo swapoff -a && sudo swapon -a

Cette manipulation peut être utile ponctuellement, mais elle ne doit pas devenir une habitude. Si vous devez vider le swap régulièrement, c’est probablement le signe que le VPS Linux manque de RAM ou qu’un service doit être optimisé.

Quand le swap ne suffit plus : passer à une offre VPS supérieure

Le swap VPS Linux est utile pour absorber des pics ponctuels, mais il ne doit pas masquer un manque durable de RAM. Si votre serveur utilise son fichier swap tous les jours, ou si la courbe mémoire reste constamment élevée dans le Panel KVM LWS, le problème n’est probablement plus la configuration du swap.

Dans ce cas, augmenter la taille du swap peut même donner une fausse impression de sécurité. Le serveur disposera de plus d’espace disque utilisable comme mémoire secondaire, mais les performances resteront limitées. Plus le système utilise le swap, plus il dépend du disque, et plus les temps de réponse peuvent se dégrader.

Les signes d’un manque structurel de mémoire RAM sont généralement faciles à repérer :

• le swap reste utilisé même après les pics de charge ;
• la colonne available de free -h reste faible ;
• les services comme MySQL, MariaDB, PHP-FPM, Apache, Nginx ou Node.js consomment régulièrement beaucoup de mémoire ;
• des erreurs OOM apparaissent encore malgré la présence d’un swap ;
• les graphiques de supervision montrent une pression mémoire continue sur plusieurs jours.

Dans cette situation, la bonne solution consiste à optimiser les services lorsque c’est possible, puis à envisager une montée en gamme vers un VPS KVM LWS disposant de plus de RAM physique. Le swap restera utile comme sécurité, mais le serveur retrouvera de meilleures performances si les processus actifs peuvent fonctionner principalement en mémoire vive.

Modifier ou supprimer le fichier swap

La configuration d’un fichier swap Linux n’est pas figée. Vous pouvez l’agrandir, le réduire ou le supprimer selon l’évolution de votre VPS Linux. Cette souplesse est l’un des principaux avantages du fichier swap par rapport à une partition swap.

Par exemple, vous pouvez commencer avec un swap de 2 Go, puis passer à 4 Go si votre serveur héberge une application plus gourmande. À l’inverse, si vous migrez vers une offre avec plus de RAM, vous pouvez réduire la taille du swap ou le conserver uniquement comme filet de sécurité.

Avant toute modification, vérifiez toujours l’état actuel du swap :

swapon --show
free -h

Ces commandes permettent de confirmer le chemin du fichier swap, sa taille et son niveau d’utilisation. Par défaut, dans ce guide, le fichier utilisé est /swapfile.

Il est aussi recommandé de vérifier l’espace disque disponible avant d’agrandir le swap :

df -h /

Si la partition principale est presque pleine, évitez de créer un fichier swap plus volumineux. Un disque saturé peut provoquer des erreurs système, bloquer les mises à jour ou empêcher certains services d’écrire leurs fichiers temporaires.

Agrandir le swap existant

Pour agrandir un fichier swap existant, il faut d’abord le désactiver, recréer le fichier avec la nouvelle taille, lui appliquer les bonnes permissions, le reformater, puis le réactiver.

L’exemple suivant remplace le fichier actuel par un swap de 4 Go :

sudo swapoff /swapfile
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Chaque commande a un rôle précis :

• swapoff /swapfile désactive temporairement le swap ;
• fallocate -l 4G /swapfile recrée le fichier avec une taille de 4 Go ;
• chmod 600 /swapfile sécurise les permissions ;
• mkswap /swapfile formate le fichier comme espace de swap Linux ;
• swapon /swapfile réactive le swap.

Après l’opération, vérifiez le résultat :

swapon --show
free -h

Vous devriez voir /swapfile avec sa nouvelle taille.

L’entrée déjà présente dans /etc/fstab n’a normalement pas besoin d’être modifiée, car elle référence le chemin du fichier, et non sa taille :

/swapfile none swap sw 0 0

Tant que le fichier conserve le même chemin, le swap VPS Linux sera toujours activé automatiquement au redémarrage.

Supprimer le swap

Vous pouvez aussi supprimer le fichier swap si vous n’en avez plus besoin, par exemple après une montée en gamme vers un VPS avec davantage de RAM ou dans le cadre d’une réorganisation de la configuration système.

Commencez par désactiver le swap :

sudo swapoff /swapfile

sudo sed -i '/swapfile/d' /etc/fstab

Puis supprimez le fichier :

sudo rm /swapfile

Vérifiez ensuite que le swap n’est plus actif :

swapon --show
free -h

Si swapon --show ne retourne rien et que la ligne Swap de free -h affiche 0B, le fichier swap a bien été supprimé.

Cette suppression doit être réalisée uniquement si vous comprenez l’impact sur votre serveur. Sans swap, un VPS Linux disposera de moins de marge en cas de pic mémoire. Si la RAM est saturée, le noyau pourra tuer plus rapidement certains processus pour protéger le système.

Pour un serveur en production, il est souvent préférable de conserver un petit swap de sécurité, même lorsque la RAM semble suffisante.

Vérification du bon fonctionnement

Après avoir créé, activé et optimisé votre swap VPS Linux, il est important de vérifier que tout fonctionne correctement. Cette étape permet de confirmer que le fichier swap est bien actif, que les paramètres noyau sont appliqués et que la configuration restera en place après un redémarrage du serveur.

Commencez par vérifier la présence du swap avec :

swapon --show

Le résultat doit afficher une ligne similaire à celle-ci :

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

La présence de /swapfile confirme que le fichier swap Linux est bien reconnu par le système. La colonne SIZE indique la taille configurée, tandis que la colonne USED indique la quantité actuellement utilisée.

Vérifiez ensuite l’état global de la RAM et du swap :

free -h

La ligne Swap doit afficher une valeur non nulle :

Swap:          2.0Gi          0B       2.0Gi

Contrôlez ensuite les paramètres d’optimisation mémoire :

cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Le résultat attendu est :

10
50

Ces valeurs confirment que vm.swappiness et vm.vfs_cache_pressure sont bien configurés pour un usage serveur.

Enfin, redémarrez le VPS Linux pour valider la persistance :

sudo reboot

Reconnectez-vous en SSH, puis relancez :

swapon --show
free -h
cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Erreurs fréquentes et cas de blocage

Même si la procédure de création d’un fichier swap est relativement simple, certaines erreurs peuvent empêcher son activation ou sa persistance. La plupart sont liées aux permissions, à l’absence de formatage avec mkswap, à une mauvaise modification de /etc/fstab ou à une confusion entre manque ponctuel et manque chronique de RAM.

Le tableau suivant récapitule les problèmes les plus fréquents.

Si vous rencontrez un blocage, commencez toujours par revenir aux commandes de diagnostic :

free -h
swapon --show
df -h /
cat /proc/sys/vm/swappiness

En cas de doute après une modification de /etc/fstab, ne redémarrez pas immédiatement le serveur. Vérifiez d’abord que la ligne ajoutée est correcte :

tail -3 /etc/fstab

La ligne attendue est :

/swapfile none swap sw 0 0

Une erreur dans ce fichier peut rendre le démarrage plus difficile à diagnostiquer. C’est pourquoi la sauvegarde initiale de /etc/fstab et la création d’un snapshot VPS avant intervention sont de bonnes pratiques à conserver.

Bonnes pratiques

Pour tirer le meilleur parti d’un swap VPS Linux, il ne suffit pas de créer un fichier et de l’activer. Il faut aussi adopter quelques bonnes pratiques pour préserver la stabilité du serveur, éviter les mauvaises manipulations et repérer à temps les signes d’un manque de RAM.

Avant toute modification sensible, créez un snapshot depuis le Panel KVM LWS si cette option est disponible pour votre offre. C’est particulièrement recommandé avant de modifier /etc/fstab, car ce fichier intervient dans le démarrage du système. Vous pouvez également consulter le tutoriel LWS dédié à la sauvegarde automatique VPS pour créer un snapshot avant de modifier la configuration système.

Évitez de configurer vm.swappiness à 0 sur un serveur de production, sauf cas très spécifique. Une valeur trop basse peut réduire l’utilisation du swap, mais elle peut aussi augmenter le risque d’erreur OOM lors d’un pic mémoire brutal. Pour un VPS Linux, une valeur autour de 10 offre généralement un bon équilibre.

Surveillez régulièrement la RAM et le swap, surtout après une mise en production, une migration, une mise à jour applicative ou l’ajout d’un nouveau service. Le Panel KVM LWS peut servir de premier niveau de supervision, tandis que les commandes free -h, htop et swapon --show permettent d’approfondir le diagnostic en SSH. Pour compléter ce suivi, vous pouvez aussi vous appuyer sur les bonnes pratiques utilisées pour surveiller les ressources système avec le Panel KVM LWS.

Ne considérez pas le swap comme une solution permanente à un manque de mémoire. Si le swap est utilisé en permanence à un niveau élevé, par exemple plus de 50 % sur plusieurs jours, le VPS manque probablement de RAM physique. Dans ce cas, il vaut mieux optimiser les services actifs ou envisager une offre VPS KVM LWS plus adaptée.

Documentez enfin votre configuration. Un simple fichier de notes peut suffire :

sudo nano /root/README-swap.txt

Si votre serveur héberge des applications gourmandes, comme des containers Docker ou des builds applicatifs, pensez aussi à gérer la mémoire disponible pour vos containers Docker ou à dimensionner correctement la RAM avant les tâches lourdes. Le swap doit accompagner une bonne stratégie de ressources, pas la remplacer.

FAQ

Comment vérifier si mon VPS Linux a un swap configuré ?

Pour vérifier si un VPS Linux dispose d’un swap actif, utilisez la commande swapon --show.
Si aucune ligne ne s’affiche, aucun fichier swap ni aucune partition swap n’est activé.
Vous pouvez aussi utiliser free -h : si la ligne Swap affiche 0B, le serveur n’a pas de swap configuré.

Quelle taille de swap créer sur un VPS avec 2 Go de RAM ?

Pour un VPS Linux avec 2 Go de RAM, un fichier swap de 2 Go est généralement suffisant.
Vous pouvez monter à 4 Go si le serveur exécute des tâches ponctuellement lourdes.
Le swap reste toutefois un filet de sécurité : il ne remplace pas une vraie montée en RAM physique.

Pourquoi mon VPS utilise-t-il le swap alors que de la RAM est encore disponible ?

Ce comportement peut venir d’une valeur vm.swappiness trop élevée.
Avec une valeur par défaut comme 60, Linux peut utiliser le swap avant que la RAM soit réellement saturée.
Sur un serveur VPS, une valeur autour de 10 limite cette utilisation trop précoce.

Quelle valeur de swappiness utiliser sur un serveur Linux ?

Sur un serveur Linux, une valeur vm.swappiness=10 est généralement recommandée.
Elle permet de conserver le swap comme sécurité, sans l’utiliser trop agressivement.
Évitez 0 sauf cas spécifique, car cela peut augmenter le risque d’erreur OOM.

Le swap sur SSD NVMe est-il adapté pour un VPS LWS ?

Oui, le swap sur SSD NVMe est adapté sur un VPS LWS comme filet de sécurité.
Il peut absorber des pics ponctuels de consommation mémoire.
Mais même sur SSD NVMe, le swap reste plus lent que la RAM physique.

Comment savoir si mon VPS manque de RAM et a besoin d’une mise à niveau ?

Votre VPS Linux manque probablement de RAM si le swap est utilisé en permanence.
Des erreurs OOM, une mémoire available faible ou des ralentissements récurrents sont aussi des signaux d’alerte.
Dans ce cas, il faut optimiser les services ou passer à un VPS avec plus de RAM physique.

Conclusion

Configurer un swap VPS Linux est une étape simple, mais très utile pour améliorer la stabilité d’un serveur sous Debian ou Ubuntu. En créant un fichier swap, en le sécurisant avec les bonnes permissions, puis en le rendant persistant dans /etc/fstab, vous offrez au noyau Linux une marge de sécurité lorsque la RAM devient insuffisante. L’optimisation de vm.swappiness et de vm.vfs_cache_pressure permet ensuite d’adapter le comportement mémoire à un usage serveur, en évitant une utilisation trop agressive du swap. Mais le swap ne remplace jamais la RAM physique : s’il est utilisé en permanence, le VPS est probablement sous-dimensionné. La bonne approche consiste donc à créer, optimiser, puis surveiller régulièrement la mémoire avec free -h, htop, swapon --show et le Panel KVM LWS.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vous pourrez ainsi anticiper les saturations, limiter les erreurs OOM et décider au bon moment si une montée en gamme vers un VPS avec plus de RAM devient nécessaire. Et si vous avez des questions ou rencontrez des problèmes dans la gestion de votre VPS, n’hésitez pas à nous contacter dans la section Commentaires.

Si vous gérez un ou plusieurs sites WordPress avec un accès root, savoir mettre à jour WordPress manuellement sur VPS est une compétence essentielle. Cette méthode permet d’intervenir même lorsque l’interface d’administration n’est plus accessible, tout en sécurisant l’opération grâce à des sauvegardes, des vérifications préalables et une procédure claire.

Objectif

L’objectif de ce tutoriel est de vous guider pas à pas pour mettre à jour WordPress manuellement sur un VPS Linux à l’aide de la ligne de commande. Vous allez découvrir deux approches complémentaires : la méthode manuelle par remplacement des fichiers du core WordPress, puis la méthode avec WP-CLI, plus rapide lorsque cet outil est disponible sur le serveur. Nous verrons également comment préparer correctement l’intervention : vérifier le chemin d’installation, contrôler la version PHP, créer une sauvegarde complète, protéger la base de données et prévoir un retour arrière en cas de problème. À la fin de ce guide, vous saurez effectuer une mise à jour WordPress SSH de manière plus sûre, sans dépendre uniquement de l’interface graphique de WordPress.

Pré-requis

Avant de commencer, vous devez disposer d’un environnement adapté. Vous aurez besoin des éléments suivants :

• un VPS Linux, idéalement sous Ubuntu ou Debian ;
• un accès SSH root ou un utilisateur disposant des droits nécessaires ;
• une installation WordPress fonctionnelle sur le serveur ;
• le chemin du site WordPress, par exemple /var/www/monsite ;
• les informations de connexion à la base de données MySQL ou MariaDB ;
• quelques notions de base en ligne de commande Linux;
• faire une sauvegarde avant de démarrer la mise à jour;
• Connaître l’utilisateur utilisé par le serveur web;

Pourquoi mettre à jour WordPress manuellement plutôt que via wp-admin

Dans la majorité des cas, la mise à jour de WordPress peut être effectuée depuis le tableau de bord, via la section « Tableau de bord > Mises à jour ». Cette méthode reste la plus simple pour un utilisateur classique. Cependant, elle n’est pas toujours suffisante dans un contexte VPS, surtout lorsque vous gérez le serveur en autonomie.

La mise à jour WordPress sans wp-admin devient utile lorsque l’interface d’administration est inaccessible, instable ou bloquée par une erreur. Elle permet aussi de mieux contrôler les fichiers remplacés, les sauvegardes créées et les étapes de validation.

Ce tutoriel couvre deux méthodes principales.

• La première consiste à effectuer un wordpress core update manuel par remplacement des fichiers. Elle repose sur le téléchargement de la dernière version de WordPress, le remplacement des dossiers wp-admin et wp-includes, puis la mise à jour éventuelle de la base de données.
• La seconde méthode utilise WP-CLI, l’outil officiel permettant de gérer WordPress en ligne de commande. Elle est souvent plus rapide et réduit le risque d’erreur humaine, car les commandes wp core update et wp core update-db automatisent une grande partie du processus.

En revanche, ce guide ne traite pas de l’installation initiale de WP-CLI, ni de la mise à jour détaillée des thèmes et extensions. Ces opérations suivent une logique proche, mais elles méritent un traitement séparé. Pour une mise à jour classique depuis l’interface WordPress ou par FTP, vous pouvez vous référer à la méthode de mise à jour classique via wp-admin et FTP.

Vérifier les pré-requis techniques avant de commencer

Avant de lancer une mise à jour WordPress SSH, prenez quelques minutes pour vérifier l’environnement du serveur. Cette étape permet d’éviter les erreurs les plus courantes :

• mauvais chemin d’installation,
• version PHP incompatible,
• espace disque insuffisant ou version WordPress mal identifiée.

Toutes les commandes suivantes sont à exécuter depuis votre VPS Linux, en SSH. Adaptez systématiquement les chemins à votre propre installation. Dans les exemples, le site WordPress est supposé être installé dans le dossier suivant :

/var/www/monsite

1. Identifier le chemin d’installation WordPress

Pour mettre à jour WordPress manuellement sur VPS, vous devez d’abord connaître le dossier exact dans lequel WordPress est installé. Ce dossier contient notamment les répertoires wp-admin, wp-includes, wp-content et le fichier wp-config.php.

Si vous ne connaissez pas le chemin du site, vous pouvez rechercher le fichier wp-config.php sur le serveur :

find / -name "wp-config.php" 2>/dev/null

Exemple de résultat possible :

/var/www/monsite/wp-config.php

/var/www/monsite

Notez ce chemin avant de continuer. Une erreur de répertoire peut entraîner la modification du mauvais site, surtout si plusieurs installations WordPress sont hébergées sur le même serveur VPS.

2. Vérifier la version PHP active

WordPress dépend de PHP pour fonctionner. Avant une mise à jour du core, il est donc indispensable de vérifier la version PHP active sur le serveur. Une version trop ancienne peut provoquer des erreurs après la mise à jour, notamment avec certains thèmes, extensions ou versions majeures de WordPress.

Exécutez la commande suivante :

php -v

Vous obtiendrez un résultat similaire à celui-ci :

PHP 8.2.12 (cli) (built: Nov 24 2025 12:00:00)
Copyright (c) The PHP Group
Zend Engine v4.2.12

Cette commande indique la version PHP utilisée en ligne de commande. Attention toutefois : sur certains VPS, la version PHP utilisée par le terminal peut être différente de celle utilisée par Apache, Nginx ou PHP-FPM pour afficher le site. Si votre serveur utilise plusieurs versions de PHP, vérifiez également la configuration du vhost, de PHP-FPM ou de votre panel d’administration.

3. Vérifier l’espace disque disponible

Une mise à jour manuelle WordPress nécessite suffisamment d’espace disque pour télécharger l’archive, la décompresser, conserver temporairement les anciens dossiers et créer des sauvegardes. Si le disque est presque plein, la copie des fichiers peut échouer ou produire une installation incomplète.

Vérifiez l’espace disponible avec la commande suivante :

df -h

Exemple de résultat :

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   18G   20G  48% /
tmpfs           2.0G     0  2.0G   0% /tmp

La colonne importante est Avail, qui indique l’espace encore disponible. Vérifiez surtout la partition qui contient votre site WordPress, généralement /, /var ou /home selon la configuration du VPS.

Si l’espace disponible est faible, supprimez d’abord les anciennes archives inutiles, les sauvegardes obsolètes ou les fichiers temporaires. Ne commencez pas un wordpress core update manuel sur un serveur saturé : une copie interrompue peut rendre le site inaccessible.

4. Identifier la version WordPress actuellement installée

Avant de remplacer les fichiers du core, vérifiez la version WordPress actuellement installée. Cette information permet de savoir si la mise à jour est mineure ou majeure, et d’anticiper d’éventuels changements de compatibilité avec PHP, le thème ou certaines extensions.

Depuis le serveur, vous pouvez consulter le fichier version.php situé dans le dossier wp-includes :

grep "wp_version =" /var/www/monsite/wp-includes/version.php

Exemple de résultat :

$wp_version = '6.8.1';

Cette commande ne modifie rien sur le site. Elle lit simplement la valeur de version déclarée par WordPress. Si vous gérez plusieurs sites sur le même VPS, exécutez cette vérification dans chaque installation concernée.

Vous pouvez également obtenir cette information avec WP-CLI, si l’outil est déjà installé :

cd /var/www/monsite
wp core version

Créer un snapshot LWS et une sauvegarde complète avant toute manipulation

Avant de mettre à jour WordPress manuellement sur un VPS, la sauvegarde est une étape indispensable. Une mise à jour du core modifie des fichiers essentiels comme wp-admin, wp-includes et plusieurs fichiers PHP situés à la racine du site. Une erreur de commande, un mauvais chemin ou un conflit après mise à jour peut rendre le site inaccessible.

L’objectif est donc simple : pouvoir revenir rapidement à l’état précédent si la mise à jour échoue. Pour cela, combinez idéalement deux protections :

• un snapshot VPS, qui capture l’état complet du serveur ;
• une sauvegarde WordPress complète, incluant les fichiers et la base de données.

Le snapshot est très pratique en cas de problème global sur le serveur. La sauvegarde fichiers/base de données est plus précise si vous souhaitez restaurer uniquement le site concerné. Ces deux approches ne se remplacent pas : elles se complètent.

1. Snapshot LWS Panel KVM (recommandé en complément)

Si votre site est hébergé sur un VPS KVM LWS, commencez par créer un snapshot depuis le panel. Cette opération permet de conserver une image complète du VPS à un instant donné : système, fichiers, configuration serveur, sites web et bases de données.

Depuis votre espace client, rendez-vous dans la section « LWS Panel KVM > Snapshots > Créer un snapshot ».

Donnez un nom explicite à votre snapshot, par exemple « Snapshot_1« . Evidement, vous pouvez trouver une combinaison alphanumérique qui vous convient le mieux.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

2. Sauvegarde des fichiers WordPress

La première sauvegarde à créer concerne les fichiers WordPress. Elle doit inclure le core, le dossier wp-content, les thèmes, les extensions, les médias, le fichier wp-config.php et les éventuels fichiers personnalisés présents à la racine du site.

Dans cet exemple, le site est situé dans /var/www/monsite. Placez-vous dans le dossier parent :

cd /var/www

Créez ensuite une archive compressée du site :

tar -czvf monsite-backup-$(date +%F).tar.gz monsite/

Cette commande génère une archive nommée avec la date du jour, par exemple :

monsite-backup-2026-06-24.tar.gz

Vérifiez ensuite que le fichier a bien été créé :

ls -lh monsite-backup-*.tar.gz

Cette sauvegarde vous permettra de restaurer rapidement les fichiers si une erreur survient pendant le remplacement des fichiers WordPress. Elle est particulièrement importante pour protéger le dossier wp-content, qui contient les éléments spécifiques de votre site : thème actif, extensions, images, documents et personnalisations.

3. Sauvegarde de la base de données

La sauvegarde des fichiers ne suffit pas. WordPress stocke une grande partie du contenu du site dans sa base de données MySQL ou MariaDB : articles, pages, réglages, comptes utilisateurs, options du thème, paramètres des extensions et commandes WooCommerce le cas échéant.

Avant toute mise à jour WordPress manuelle, vous devez donc exporter la base de données associée au site.

Les identifiants de connexion se trouvent dans le fichier wp-config.php, situé à la racine de votre installation WordPress. Vous pouvez les consulter avec :

grep "DB_" /var/www/monsite/wp-config.php

Vous verrez notamment les constantes suivantes :

define( 'DB_NAME', 'nom_de_la_bdd' );
define( 'DB_USER', 'utilisateur_bdd' );
define( 'DB_PASSWORD', 'mot_de_passe' );
define( 'DB_HOST', 'localhost' );

mkdir -p /root/backups

Puis exportez la base de données avec mysqldump :

mysqldump --user=utilisateur_bdd --password=mot_de_passe nom_de_la_bdd \
  --single-transaction > /root/backups/monsite-bdd-$(date +%F).sql

L’option --single-transaction permet de réaliser une sauvegarde plus propre pour les bases utilisant InnoDB, sans verrouiller inutilement les tables pendant l’export.

Vérifiez ensuite que le fichier SQL a bien été généré :

ls -lh /root/backups/monsite-bdd-*.sql

Pour des raisons de sécurité, évitez autant que possible de laisser le mot de passe MySQL en clair dans l’historique Bash. Sur un serveur administré régulièrement, il est préférable d’utiliser un fichier .my.cnf protégé, afin d’exécuter mysqldump sans saisir le mot de passe directement dans la commande.

À ce stade, vous disposez de trois protections complémentaires : un snapshot VPS, une sauvegarde des fichiers WordPress et une sauvegarde de la base de données.

Méthode 1 : Mise à jour manuelle par remplacement de fichiers

La première méthode consiste à remplacer manuellement les fichiers du core WordPress depuis le terminal. C’est la méthode la plus universelle, car elle ne dépend pas de l’accès à wp-admin. Elle peut donc être utilisée lorsqu’une mise à jour automatique a échoué, lorsque l’administration WordPress est inaccessible ou lorsque vous souhaitez contrôler chaque étape.

Le principe est simple :

• télécharger la dernière archive WordPress ;
• décompresser les nouveaux fichiers ;
• remplacer les dossiers wp-admin et wp-includes ;
• fusionner prudemment wp-content sans écraser vos contenus ;
• copier les fichiers PHP de la racine ;
• corriger les permissions ;
• finaliser la mise à jour de la base de données si nécessaire.

Cette méthode demande de la rigueur. Vous devez toujours vérifier les chemins avant d’exécuter une commande de copie ou de suppression. Une erreur sur le dossier wp-content peut entraîner la perte de thèmes, extensions ou médias personnalisés. C’est pour cette raison que la sauvegarde réalisée à l’étape précédente est indispensable.

1. Télécharger la dernière version de WordPress

Commencez par vous placer dans un dossier temporaire. Cela évite de mélanger les fichiers d’installation avec les fichiers de votre site en production.

cd /tmp

Téléchargez ensuite la dernière version française de WordPress :

wget https://fr.wordpress.org/latest-fr_FR.zip

Cette archive contient les fichiers WordPress à jour en français. Si votre site utilise la version internationale en anglais, vous pouvez utiliser l’archive officielle correspondante :

wget https://wordpress.org/latest.zip

Dans le cadre d’un site français, l’URL fr.wordpress.org/latest-fr_FR.zip est généralement la plus adaptée. Elle permet de récupérer directement la version localisée de WordPress.

Après le téléchargement, vérifiez que le fichier est bien présent :

ls -lh latest-fr_FR.zip

Si la commande wget n’est pas installée sur votre VPS, vous pouvez l’ajouter avec le gestionnaire de paquets de votre distribution. Sur Debian ou Ubuntu :

apt update
apt install wget unzip -y

L’outil unzip sera également nécessaire à l’étape suivante pour décompresser l’archive.

2. Décompresser l’archive

Une fois l’archive téléchargée, décompressez-la dans le dossier temporaire :

unzip latest-fr_FR.zip

Cette commande crée un nouveau dossier nommé wordpress dans /tmp. Ce dossier contient les fichiers propres de la dernière version WordPress :

ls -lh /tmp/wordpress

Vous devez y retrouver les éléments principaux suivants :

wp-admin
wp-content
wp-includes
index.php
wp-config-sample.php
wp-login.php

La suite de la procédure consistera à préparer le site, activer temporairement le mode maintenance, puis remplacer les fichiers nécessaires sans écraser les éléments personnalisés.

3. Mettre le site en mode maintenance (optionnel mais recommandé)

Avant de remplacer les fichiers du core WordPress, il est préférable de placer temporairement le site en mode maintenance. Cette étape évite qu’un visiteur ou un administrateur interagisse avec le site pendant la copie des fichiers.

Placez-vous dans le dossier de votre installation WordPress :

cd /var/www/monsite

Créez ensuite le fichier .maintenance :

touch .maintenance
echo '<?php $upgrading = time(); ?>' > .maintenance

Ce fichier indique à WordPress qu’une opération de maintenance est en cours. Les visiteurs verront alors un message temporaire au lieu d’accéder à un site potentiellement instable pendant la mise à jour.

Cette étape est particulièrement recommandée si vous gérez :

• un site avec beaucoup de trafic ;
• une boutique WooCommerce ;
• un site avec formulaire de contact ou espace membre ;
• une installation WordPress utilisée par plusieurs administrateurs.

Le mode maintenance doit rester actif uniquement le temps du remplacement des fichiers. Une fois la mise à jour WordPress manuelle terminée, vous devrez supprimer ce fichier pour rendre le site de nouveau accessible.

4. Renommer les anciens dossiers core (au lieu de les supprimer directement)

La procédure manuelle de mise à jour consiste à remplacer les dossiers wp-admin et wp-includes. Ces deux dossiers font partie du core WordPress. Ils ne contiennent normalement pas vos médias, thèmes ou extensions personnalisés.

Par précaution, il est préférable de renommer les anciens dossiers plutôt que de les supprimer immédiatement. Cette méthode vous laisse une possibilité de retour arrière rapide si une erreur survient pendant la copie.

Depuis le dossier de votre site :

cd /var/www/monsite

Renommez les deux dossiers principaux :

mv wp-admin wp-admin-old
mv wp-includes wp-includes-old

Après cette opération, votre site ne peut plus fonctionner correctement tant que les nouveaux dossiers n’ont pas été copiés. C’est normal : vous êtes dans une phase intermédiaire de la mise à jour WordPress SSH.

Vous pouvez vérifier que les anciens dossiers ont bien été renommés avec :

ls -lh

Vous devez voir apparaître :

wp-admin-old
wp-includes-old

Ne renommez pas le dossier wp-content. Ce dossier contient les éléments spécifiques de votre site : plugins, thèmes, médias, traductions, caches et fichiers personnalisés. Il doit être conservé avec une attention particulière.

5. Copier les nouveaux dossiers core

Une fois les anciens dossiers renommés, vous pouvez copier les nouveaux dossiers wp-admin et wp-includes depuis l’archive WordPress décompressée dans /tmp/wordpress.

Exécutez les commandes suivantes :

cp -r /tmp/wordpress/wp-admin /var/www/monsite/
cp -r /tmp/wordpress/wp-includes /var/www/monsite/

Vérifiez ensuite que les nouveaux dossiers sont bien présents :

ls -lh /var/www/monsite/wp-admin
ls -lh /var/www/monsite/wp-includes

Si les dossiers sont vides ou absents, n’allez pas plus loin. Revenez à l’étape précédente, vérifiez le chemin /tmp/wordpress, puis relancez la copie.

Cette étape est simple, mais elle demande de la précision. Sur un VPS Linux, une commande exécutée dans le mauvais répertoire peut modifier une autre installation WordPress. Vérifiez toujours le chemin complet avant de copier ou supprimer des fichiers.

6. Fusionner le dossier wp-content (sans écraser les thèmes/plugins existants)

Le dossier wp-content est le point le plus sensible d’une mise à jour WordPress manuelle. Il contient les fichiers propres à votre site : thèmes, extensions, médias, traductions, fichiers de cache et personnalisations éventuelles.

Vous ne devez jamais supprimer entièrement ce dossier dans le cadre d’une mise à jour du core. L’objectif est seulement de fusionner les éventuels fichiers standards fournis par WordPress, sans écraser vos éléments existants.

Utilisez la commande suivante :

cp -rn /tmp/wordpress/wp-content/* /var/www/monsite/wp-content/

L’option importante est -n, qui signifie no-clobber. Elle empêche la commande de remplacer un fichier déjà présent dans le dossier de destination.

Concrètement, cette commande permet :

• d’ajouter les fichiers standards manquants ;
• de conserver vos plugins WordPress existants ;
• de conserver votre thème WordPress actif ;
• de ne pas écraser vos médias ;
• de limiter le risque de perte de fichiers personnalisés.

N’utilisez pas une commande comme celle-ci :

rm -rf /var/www/monsite/wp-content

Et évitez également une synchronisation destructrice du type :

rsync -av --delete /tmp/wordpress/wp-content/ /var/www/monsite/wp-content/

7. Copier les fichiers individuels de la racine

Après avoir remplacé les dossiers wp-admin et wp-includes, vous devez copier les fichiers WordPress situés à la racine de l’archive téléchargée. Ces fichiers font partie du core WordPress et doivent être mis à jour eux aussi.

Depuis votre VPS Linux, exécutez les commandes suivantes :

cp /tmp/wordpress/wp-*.php /var/www/monsite/
cp /tmp/wordpress/index.php /var/www/monsite/
cp /tmp/wordpress/xmlrpc.php /var/www/monsite/ 2>/dev/null

Le point de vigilance essentiel concerne le fichier wp-config.php. Ce fichier ne doit jamais être écrasé pendant une mise à jour WordPress manuelle. Il contient les informations sensibles du site :

• les identifiants de connexion à la base de données ;
• les clés de sécurité WordPress ;
• le préfixe des tables ;
• certaines constantes personnalisées ;
• des réglages propres à votre serveur ou à votre environnement.

L’archive WordPress contient un fichier nommé wp-config-sample.php, mais pas votre fichier wp-config.php personnalisé. Vous ne devez donc pas copier ce fichier exemple par-dessus votre configuration existante.

Après la copie, vérifiez que wp-config.php est toujours présent :

ls -lh /var/www/monsite/wp-config.php

Vous pouvez également contrôler rapidement son contenu sans l’afficher entièrement :

grep "DB_NAME" /var/www/monsite/wp-config.php

Si le fichier wp-config.php a été supprimé ou modifié par erreur, restaurez-le immédiatement depuis la sauvegarde WordPress créée avant l’intervention.

8. Corriger les permissions de fichiers

Après le remplacement des fichiers, il est important de vérifier les permissions WordPress. Des permissions incorrectes peuvent provoquer plusieurs problèmes : erreur 500, page blanche, impossibilité de téléverser des médias, échec des mises à jour futures ou blocage de certaines extensions.

Sur une configuration Debian ou Ubuntu classique avec Apache ou Nginx, l’utilisateur du serveur web est souvent www-data. Vous pouvez alors appliquer les commandes suivantes :

chown -R www-data:www-data /var/www/monsite
find /var/www/monsite -type d -exec chmod 755 {} \;
find /var/www/monsite -type f -exec chmod 644 {} \;

• 755 pour les dossiers ;
• 644 pour les fichiers.

Ces valeurs conviennent à de nombreuses installations WordPress, mais elles doivent être adaptées si votre serveur utilise une configuration spécifique. Par exemple, certains environnements utilisent un utilisateur différent, comme nginx, apache ou un utilisateur système dédié à chaque site.

Pour identifier l’utilisateur utilisé par le serveur web, vous pouvez consulter les processus actifs :

ps aux | grep -E 'apache|nginx|php-fpm'

Ne donnez pas des permissions trop larges comme 777 sur l’ensemble du site. Même si cela peut sembler résoudre un problème de droits à court terme, cette pratique affaiblit fortement la sécurité WordPress. Un site correctement administré sur VPS doit conserver des permissions strictes et cohérentes.

Une fois les permissions corrigées, vous pouvez poursuivre la finalisation de la mise à jour WordPress SSH.

9. Retirer le mode maintenance

Si vous avez activé le mode maintenance WordPress à l’étape 6.3, vous devez maintenant le désactiver. Pour cela, supprimez simplement le fichier .maintenance placé à la racine du site.

Exécutez la commande suivante :

rm /var/www/monsite/.maintenance

Vous pouvez ensuite vérifier que le fichier n’existe plus :

ls -la /var/www/monsite | grep maintenance

Si aucun résultat ne s’affiche, le fichier a bien été supprimé.

Cette étape est importante, car un fichier .maintenance oublié peut afficher un message de maintenance permanent aux visiteurs. C’est aussi l’une des causes fréquentes du message indiquant qu’une mise à jour WordPress a échoué ou qu’une opération est toujours en cours.

Après suppression, ouvrez le site dans un navigateur. Il est possible que WordPress vous demande encore de finaliser la mise à jour de la base de données. C’est normal si la nouvelle version du core introduit des changements dans la structure interne de WordPress.

10. Finaliser la mise à jour de la base de données

Une fois les fichiers remplacés, WordPress peut avoir besoin de mettre à jour sa base de données. Cette étape dépend de la version installée précédemment et de la version vers laquelle vous migrez.

Connectez-vous à l’administration WordPress :

https://monsite.fr/wp-admin/

Si une mise à jour de la base de données est nécessaire, WordPress affiche automatiquement un écran dédié. Il vous proposera de lancer la procédure via une URL de ce type :

https://monsite.fr/wp-admin/upgrade.php

Cliquez sur le bouton proposé pour finaliser l’opération. Cette étape met à jour les tables WordPress afin qu’elles correspondent à la nouvelle version du core WordPress.

Si vous ne pouvez pas accéder à wp-admin, vous pouvez tenter d’ouvrir directement l’URL upgrade.php dans le navigateur. Assurez-vous toutefois que le site répond correctement et que les permissions ont bien été corrigées.

Après la mise à jour de la base de données, reconnectez-vous au tableau de bord WordPress. Rendez-vous ensuite dans la section « Tableau de bord > Mises à jour ».

Vous pourrez y vérifier que WordPress indique bien la dernière version installée.

Cette étape marque la fin fonctionnelle du remplacement manuel des fichiers WordPress. Il reste toutefois une dernière opération importante : nettoyer les anciens dossiers uniquement après avoir confirmé que le site fonctionne correctement.

11. Nettoyer les anciens dossiers une fois la mise à jour validée

Une fois la mise à jour WordPress manuelle terminée, ne supprimez pas immédiatement les anciens dossiers si vous n’avez pas encore testé le site. Commencez par vérifier que le front-end fonctionne, que l’accès à wp-admin est possible et qu’aucune erreur visible ne s’affiche.

Lorsque tout est validé, vous pouvez supprimer les anciens dossiers renommés :

rm -rf /var/www/monsite/wp-admin-old
rm -rf /var/www/monsite/wp-includes-old

Vous pouvez également nettoyer les fichiers temporaires créés dans /tmp :

rm -rf /tmp/wordpress
rm -f /tmp/latest-fr_FR.zip

Ce nettoyage évite de conserver inutilement des fichiers obsolètes sur le serveur. Il réduit aussi les risques de confusion lors d’une prochaine intervention.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Méthode 2 : Mise à jour via WP-CLI (recommandée si disponible)

La deuxième méthode consiste à utiliser WP-CLI, l’interface en ligne de commande officielle de WordPress. Si l’outil est installé sur votre VPS, il simplifie fortement la procédure. Au lieu de télécharger manuellement l’archive, de remplacer les dossiers et de copier les fichiers un par un, vous pouvez lancer la mise à jour avec quelques commandes.

WP-CLI est particulièrement utile pour les administrateurs qui gèrent plusieurs sites WordPress sur le même serveur VPS. Il permet de vérifier la version installée, rechercher les mises à jour disponibles, exporter la base de données, mettre à jour le core et finaliser la base de données sans passer par l’interface graphique.

Cette méthode est souvent plus rapide et limite les erreurs humaines. Elle reste toutefois soumise aux mêmes règles de sécurité : avant toute commande de wp-cli mise à jour WordPress, créez un snapshot VPS, sauvegardez les fichiers importants et exportez la base de données.

Si WP-CLI n’est pas encore installé sur votre serveur, vous pouvez suivre le tutoriel LWS dédié pour installer WP-CLI sur votre VPS pour automatiser vos mises à jour.

1. Vérifier que WP-CLI est installé

Pour commencer, connectez-vous en SSH à votre VPS, puis vérifiez que WP-CLI est disponible avec la commande suivante :

wp --info

Si WP-CLI est installé, vous obtiendrez des informations sur l’environnement utilisé : version de WP-CLI, version PHP, système d’exploitation, chemin de l’exécutable et configuration chargée.

Exemple de retour possible :

OS:	Linux
Shell:	/bin/bash
PHP binary:	/usr/bin/php
PHP version:	8.2.12
WP-CLI version:	2.10.0

Dans ce cas, installez d’abord WP-CLI avant de poursuivre avec cette méthode. Vous pouvez aussi revenir à la méthode précédente par remplacement manuel des fichiers WordPress, qui fonctionne sans WP-CLI.

Sur un VPS, il est fréquent d’exécuter certaines commandes en root. WP-CLI peut alors demander l’option --allow-root. Utilisez-la avec prudence, uniquement si vous savez ce que vous faites :

wp --info --allow-root

2. Se placer dans le répertoire WordPress

Avant d’exécuter une commande WP-CLI, placez-vous dans le dossier de l’installation WordPress concernée. WP-CLI doit détecter le fichier wp-config.php pour savoir sur quel site agir.

Dans notre exemple :

cd /var/www/monsite

Vous pouvez ensuite vérifier que le fichier de configuration est bien présent :

ls -lh wp-config.php

Si le fichier existe, vous êtes normalement dans le bon répertoire. Si vous gérez plusieurs sites sur le même VPS WordPress, cette étape est essentielle. Une commande WP-CLI exécutée dans le mauvais dossier peut mettre à jour un autre site que celui prévu.

Pour confirmer que WP-CLI détecte correctement l’installation, vous pouvez lancer :

wp core version

Si vous êtes connecté en root et que WP-CLI le demande, utilisez :

wp core version --allow-root

Cette vérification confirme que WP-CLI communique bien avec votre installation WordPress avant de lancer une opération sensible.

3. Vérifier la version actuelle et la disponibilité d’une mise à jour

Avant de lancer une mise à jour WordPress avec WP-CLI, commencez par vérifier la version actuellement installée. Depuis le dossier du site, exécutez :

wp core version

Si vous utilisez WP-CLI en root, ajoutez l’option suivante :

wp core version --allow-root

Cette commande affiche uniquement le numéro de version du core WordPress installé. Elle permet de confirmer l’état de départ avant toute modification.

Vérifiez ensuite si une mise à jour est disponible :

wp core check-update

Si WordPress est déjà à jour, WP-CLI l’indiquera clairement. Si une nouvelle version est disponible, la commande affichera les informations principales : version proposée, type de mise à jour et URL du package.

Cette étape est utile pour éviter de lancer une opération inutile. Elle permet aussi d’identifier si vous passez vers une version majeure de WordPress, ce qui demande davantage de prudence. Dans ce cas, vérifiez la compatibilité de votre version PHP, de votre thème et de vos extensions avant de continuer.

Sur un VPS WordPress, cette vérification est particulièrement pratique si vous administrez plusieurs sites. Vous pouvez rapidement savoir quels sites nécessitent réellement une mise à jour.

4. Sauvegarder via WP-CLI (alternative aux commandes manuelles de la section 5)

WP-CLI permet également d’exporter la base de données WordPress en une seule commande. Cette méthode peut remplacer la commande mysqldump si WP-CLI est correctement configuré et si WordPress parvient à se connecter à la base de données.

Depuis le dossier du site, créez d’abord un répertoire de sauvegarde si nécessaire :

mkdir -p /root/backups

Exportez ensuite la base de données :

wp db export /root/backups/monsite-bdd-$(date +%F).sql

Avec l’option root si nécessaire :

wp db export /root/backups/monsite-bdd-$(date +%F).sql --allow-root

Cette commande génère un fichier .sql contenant les tables de votre site WordPress. Vérifiez que l’export a bien été créé :

ls -lh /root/backups/monsite-bdd-*.sql

Même avec WP-CLI, cette sauvegarde reste indispensable. Une mise à jour WordPress SSH peut modifier la structure de la base de données, notamment lors d’un changement de version important. Sans export préalable, un retour arrière propre devient beaucoup plus difficile.

Pour une sécurité maximale, conservez également la sauvegarde des fichiers WordPress et le snapshot VPS créés précédemment.

5. Lancer la mise à jour

Une fois les vérifications effectuées et la sauvegarde validée, vous pouvez lancer la mise à jour du core WordPress avec WP-CLI.

Depuis le dossier de votre site :

wp core update

Si vous exécutez la commande en root :

wp core update --allow-root

WP-CLI télécharge automatiquement la dernière version disponible, remplace les fichiers nécessaires et affiche un message de confirmation lorsque l’opération est terminée. Cette méthode évite de manipuler manuellement les dossiers wp-admin, wp-includes et les fichiers PHP de la racine.

Pendant l’exécution, ne fermez pas votre session SSH et n’interrompez pas la commande. Une coupure au mauvais moment peut laisser l’installation dans un état incomplet.

Si vous souhaitez mettre à jour vers une version précise, vous pouvez utiliser l’option --version :

wp core update --version=6.8.1

Cette option peut être utile dans un environnement de staging ou lors d’une intervention contrôlée. En production, privilégiez toujours une version stable compatible avec votre configuration PHP, votre thème et vos extensions.

6. Mettre à jour la base de données

Après la mise à jour des fichiers du core WordPress, il peut être nécessaire de mettre à jour la base de données. Avec WP-CLI, cette étape se fait directement en ligne de commande :

wp core update-db

Avec l’option root si nécessaire :

wp core update-db --allow-root

Cette commande applique les éventuelles modifications de structure ou de données attendues par la nouvelle version de WordPress. Elle remplace le passage manuel par l’écran /wp-admin/upgrade.php.

Si aucune mise à jour de base de données n’est nécessaire, WP-CLI l’indiquera. Dans le cas contraire, il exécutera l’opération et affichera un message de succès.

Cette étape est importante : un site peut sembler fonctionner après le remplacement des fichiers, mais rester incomplet si la base de données n’a pas été finalisée. Cela peut provoquer des erreurs dans le tableau de bord, des comportements incohérents ou des messages de mise à jour persistants.

Une fois cette commande exécutée, vous êtes proche de la fin de la mise à jour WordPress avec WP-CLI. Il reste à contrôler la version installée et à vérifier le bon fonctionnement du site.

7. Vérifier la version après mise à jour

Une fois la mise à jour WordPress avec WP-CLI terminée, vérifiez que la nouvelle version est bien active :

wp core version

Avec l’option root si nécessaire :

wp core version --allow-root

Comparez le numéro affiché avec la version attendue. Vous pouvez également relancer :

wp core check-update

Si WordPress indique qu’aucune mise à jour n’est disponible, le core WordPress est bien à jour. Cette vérification est simple, mais importante. Elle confirme que la commande wp core update s’est correctement appliquée et que le site utilise bien la version attendue.

Pour les administrateurs qui gèrent plusieurs sites sur le même VPS, cette commande peut aussi être intégrée dans un script Bash afin de contrôler rapidement toutes les installations WordPress présentes sur le serveur.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vérification du bon fonctionnement

Après avoir mis à jour WordPress manuellement sur VPS, ne vous contentez pas d’un simple message de succès dans le terminal. Vous devez vérifier que le site fonctionne réellement, côté visiteur comme côté administration.

Commencez par ouvrir le site en front-end. Vérifiez que la page d’accueil se charge correctement, sans erreur PHP, sans écran blanc et sans message de maintenance persistant. Testez ensuite plusieurs pages importantes : page d’accueil, articles récents, page contact, formulaire, espace membre ou pages stratégiques.

Connectez-vous ensuite à l’administration WordPress :

https://monsite.fr/wp-admin/

Dans le tableau de bord, vérifiez que l’accès est normal et qu’aucun message critique ne s’affiche. Rendez-vous dans la suite « Tableau de bord > Mises à jour » pour confirmer que WordPress reconnaît bien la nouvelle version.

Si vous utilisez WP-CLI, vous pouvez aussi confirmer la version en SSH :

cd /var/www/monsite
wp core version

Enfin, consultez les logs du serveur pour repérer d’éventuelles erreurs invisibles côté navigateur. Selon votre configuration, la commande peut ressembler à :

tail -f /var/log/php-fpm/error.log

ou :

tail -f /var/log/apache2/error.log

Adaptez le chemin des logs à votre configuration Apache, Nginx ou PHP-FPM. Cette vérification permet de détecter rapidement une extension incompatible, une fonction PHP obsolète ou un problème de permissions après la mise à jour WordPress SSH.

Erreurs fréquentes et cas de blocage

Même en suivant une procédure propre, une mise à jour WordPress manuelle peut rencontrer des blocages. Les causes les plus fréquentes sont liées aux permissions, aux extensions incompatibles, à un fichier .maintenance oublié ou à une mauvaise manipulation du dossier wp-content.

Le tableau ci-dessous résume les principaux cas à connaître.

Pour désactiver rapidement un plugin suspect sans accès à wp-admin, renommez son dossier :

cd /var/www/monsite
mv wp-content/plugins/plugin-suspect wp-content/plugins/plugin-suspect-off

Si le site redevient accessible, le plugin désactivé est probablement en cause. Vous pourrez ensuite le mettre à jour, le remplacer ou contacter son éditeur.

Pour supprimer un fichier .maintenance oublié :

rm /var/www/monsite/.maintenance

Pour corriger des permissions classiques sur Debian ou Ubuntu avec www-data :

chown -R www-data:www-data /var/www/monsite
find /var/www/monsite -type d -exec chmod 755 {} \;
find /var/www/monsite -type f -exec chmod 644 {} \;

L’objectif n’est pas de corriger au hasard, mais d’identifier la cause du blocage. Avant toute suppression importante, vérifiez toujours que votre sauvegarde WordPress et votre snapshot VPS sont disponibles.

Revenir en arrière en cas de problème (rollback)

Si la mise à jour WordPress manuelle provoque un problème bloquant, vous devez revenir à l’état précédent avec méthode. Le choix de la solution dépend du niveau de gravité : erreur limitée aux fichiers du core, site totalement inaccessible ou problème global sur le VPS.

La solution la plus rapide consiste à restaurer le snapshot LWS Panel KVM créé avant l’intervention. Depuis votre espace client, rendez-vous dans la section « LWS Panel KVM > Snapshots > Restaurer ».

Cette option restaure l’état complet du VPS au moment du snapshot. Elle est particulièrement utile si plusieurs fichiers, services ou configurations ont été modifiés par erreur. En revanche, elle restaure tout le serveur, pas seulement le site WordPress concerné.

Si vous avez seulement besoin de revenir aux anciens dossiers du core WordPress, et si vous ne les avez pas encore supprimés, vous pouvez restaurer wp-admin et wp-includes :

cd /var/www/monsite
rm -rf wp-admin wp-includes
mv wp-admin-old wp-admin
mv wp-includes-old wp-includes

Cette méthode peut suffire si le problème vient du remplacement des fichiers WordPress et que la base de données n’a pas été modifiée de manière bloquante.

Pour une restauration complète du site, restaurez les fichiers puis la base de données depuis les sauvegardes créées avant la mise à jour :

cd /var/www
rm -rf monsite
tar -xzvf monsite-backup-YYYY-MM-DD.tar.gz

Puis restaurez la base de données :

mysql --user=utilisateur_bdd --password=mot_de_passe nom_de_la_bdd < /root/backups/monsite-bdd-YYYY-MM-DD.sql

Remplacez YYYY-MM-DD, utilisateur_bdd, mot_de_passe et nom_de_la_bdd par vos propres valeurs.

Pour aller plus loin, vous pouvez consulter le tutoriel LWS dédié pour revenir à une version antérieure de WordPress en cas de problème.

Bonnes pratiques

Pour mettre à jour WordPress manuellement sur VPS dans de bonnes conditions, adoptez une méthode stable et reproductible. Une mise à jour réussie ne repose pas seulement sur les commandes exécutées, mais aussi sur la préparation, les sauvegardes et les contrôles réalisés avant et après l’intervention.

Commencez toujours par créer un snapshot VPS avant toute manipulation. Même si vous avez déjà exporté les fichiers et la base de données, le snapshot reste une sécurité rapide à restaurer en cas de problème global sur le serveur. Sur un environnement de production, cette précaution doit devenir systématique.

Testez aussi les mises à jour importantes sur un environnement de staging avant de les appliquer au site principal. C’est particulièrement recommandé pour les sites WooCommerce, les sites à fort trafic ou les installations qui utilisent de nombreuses extensions.

Avant chaque mise à jour WordPress SSH, vérifiez :

• la compatibilité de la version PHP ;
• l’espace disque disponible ;
• la présence d’une sauvegarde fichiers récente ;
• la présence d’un export SQL exploitable ;
• la compatibilité du thème et des plugins ;
• l’utilisateur réel du serveur web pour les permissions.

Privilégiez WP-CLI dès qu’il est disponible. Les commandes wp core update et wp core update-db réduisent les manipulations manuelles et limitent les risques d’erreur sur les dossiers sensibles. En revanche, même avec WP-CLI, ne supprimez jamais l’étape de sauvegarde.

Enfin, ne modifiez pas le dossier wp-content sans précaution. Ce dossier contient les éléments personnalisés du site. Dans une mise à jour manuelle WordPress, il doit être conservé, fusionné prudemment et jamais remplacé brutalement.

FAQ

Peut-on mettre à jour WordPress sans accès à wp-admin ?

Oui. Il est possible de mettre à jour WordPress sans wp-admin en passant par SSH sur un serveur VPS. Deux méthodes sont possibles : le remplacement manuel des fichiers du core WordPress ou l’utilisation de WP-CLI. Cette approche est utile lorsqu’une erreur PHP, un écran blanc ou une mise à jour interrompue bloque l’accès à l’administration.

Quelle est la différence entre la mise à jour manuelle par fichiers et WP-CLI ?

La méthode par fichiers consiste à télécharger WordPress, remplacer les dossiers wp-admin et wp-includes, puis copier les fichiers nécessaires à la racine. WP-CLI, lui, automatise une grande partie du processus avec des commandes comme wp core update et wp core update-db. La méthode WP-CLI est généralement plus rapide, mais elle nécessite que l’outil soit installé et fonctionnel sur le VPS.

Faut-il supprimer ou renommer les dossiers wp-admin et wp-includes lors d’une mise à jour manuelle ?

Il est préférable de les renommer temporairement plutôt que de les supprimer directement. Par exemple, vous pouvez renommer wp-admin en wp-admin-old et wp-includes en wp-includes-old. Cette précaution facilite un retour arrière rapide si la mise à jour WordPress manuelle échoue.

Comment revenir en arrière si la mise à jour manuelle de WordPress échoue ?

Vous pouvez restaurer le snapshot VPS créé avant l’intervention, remettre en place les anciens dossiers wp-admin et wp-includes, ou restaurer la sauvegarde complète des fichiers et de la base de données. Le choix dépend de la gravité du problème et des sauvegardes disponibles.

WP-CLI est-il disponible sur un VPS LWS ?

Un VPS LWS avec accès root permet d’installer et d’utiliser WP-CLI. Selon l’image système ou la configuration choisie, l’outil peut nécessiter une installation manuelle. Avant de suivre la méthode WP-CLI, vérifiez sa présence avec la commande wp --info.

Le dossier wp-content est-il affecté par une mise à jour manuelle de WordPress ?

Le dossier wp-content ne doit pas être remplacé entièrement. Il contient les thèmes, plugins, médias et fichiers personnalisés du site. Lors d’un wordpress core update manuel, il faut uniquement fusionner les fichiers nécessaires avec prudence, par exemple avec cp -rn, afin d’éviter d’écraser les contenus existants.

Conclusion

Savoir mettre à jour WordPress manuellement sur VPS permet de garder le contrôle lorsque l’interface wp-admin ne suffit plus. Avec une connexion SSH, vous pouvez remplacer les fichiers du core, corriger les permissions, finaliser la base de données et résoudre une mise à jour bloquée sans dépendre de l’interface graphique. La clé reste la préparation : vérification du serveur, snapshot VPS, sauvegarde des fichiers et export de la base de données. Pour les administrateurs réguliers, WP-CLI représente ensuite la méthode la plus rapide et la plus fiable pour maintenir WordPress à jour. En appliquant ces bonnes pratiques, vous réduisez les risques d’interruption, protégez vos données et sécurisez durablement vos sites WordPress hébergés sur un VPS Linux.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Vous avez déjà réalisé une mise à jour WordPress manuelle sur un VPS ou rencontré un blocage pendant l’opération ? Partagez votre retour d’expérience en commentaire : vos questions et astuces pourront aider d’autres administrateurs WordPress.

Dans ce contexte, choisir un VPS Linux devient une alternative solide pour héberger une application SaaS, un portfolio avancé, une plateforme e-commerce personnalisée ou une application full-stack basée sur Next.js.

Objectif

L’objectif de ce guide est de vous montrer comment déployer une application Next.js sur un VPS Linux en suivant une méthode claire, reproductible et adaptée à un environnement de production. Nous allons partir d’un serveur Ubuntu ou Debian, installer Node.js, préparer l’application avec le mode standalone, gérer le processus Node avec PM2, configurer Nginx comme reverse proxy, puis activer un certificat SSL Let’s Encrypt. À la fin du tutoriel, votre application sera accessible en HTTPS depuis un nom de domaine personnalisé. Elle pourra redémarrer automatiquement en cas de crash ou de reboot du serveur, ses logs seront consultables avec PM2, et les ressources du serveur pourront être surveillées depuis le LWS Panel KVM.

Pré-requis

Avant de commencer, vous devez :

• Disposer d’un VPS Linux prêt à être configuré. Ce guide s’adresse principalement aux utilisateurs d’un VPS KVM LWS sous Ubuntu 22.04, Ubuntu 24.04 ou Debian 12, avec un accès root en SSH. Les identifiants de connexion au serveur sont transmis après la livraison du VPS,
• Vous aurez également besoin d’un nom de domaine pointant vers l’adresse IP du VPS. Pour cela, créez ou modifiez un enregistrement DNS de type A depuis votre espace client, par exemple dans la section « LWS Panel > Noms de domaine > Zone DNS ». Les ports 22, 80 et 443 doivent être ouverts afin d’autoriser respectivement SSH, HTTP et HTTPS,
• Enfin, votre application Next.js doit être disponible dans un dépôt Git, par exemple GitHub, GitLab ou Gitea,
• Vous devez aussi être à l’aise avec les commandes de base Linux, l’utilisation de SSH, git clone, npm, ainsi que les notions essentielles de Next.js en production.

Pourquoi déployer Next.js sur VPS plutôt que Vercel

Vercel est une excellente plateforme pour démarrer rapidement avec Next.js, notamment parce qu’elle est conçue autour de ce framework. Elle simplifie le déploiement, l’intégration Git et la gestion des previews. Cependant, dès qu’un projet devient plus exigeant, un VPS Linux peut offrir davantage de liberté, de stabilité budgétaire et de contrôle technique.

Déployer Next.js sur un VPS permet notamment de maîtriser l’environnement d’exécution, d’installer ses propres services, d’héberger une base de données locale et de configurer finement Nginx, PM2, les certificats SSL, les logs ou les sauvegardes. Cette approche demande plus de configuration initiale, mais elle convient très bien aux développeurs qui veulent comprendre et contrôler leur infrastructure.

Ce tutoriel couvre le déploiement manuel de Next.js 15 en production avec Node.js, PM2, Nginx et Let’s Encrypt. Il se concentre sur une installation classique, sans couche d’orchestration supplémentaire.

Il ne couvre pas le déploiement via Docker. Pour cette approche, vous pouvez consulter le tutoriel dédié pour déployer Next.js dans un container Docker sur VPS. Si votre objectif principal est de quitter Vercel sans gérer manuellement toute la configuration serveur, l’alternative Coolify peut aussi être intéressante pour migrer de Vercel vers un VPS avec Coolify pour supprimer les timeouts.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Créer un snapshot LWS avant de commencer

Avant de modifier la configuration de votre serveur, il est fortement recommandé de créer un snapshot LWS. Un snapshot est une image instantanée de l’état de votre VPS KVM à un moment précis. En cas d’erreur de configuration, de mauvaise installation ou de problème pendant le déploiement, vous pouvez revenir rapidement à l’état précédent.

Cette précaution est particulièrement utile avant d’installer Node.js, PM2, Nginx ou Certbot. Elle permet de travailler plus sereinement, surtout si vous configurez votre premier environnement de production pour Next.js sur VPS Linux.

Depuis votre espace client, rendez-vous dans la section « LWS Panel KVM > Snapshots > Créer un snapshot ».

Donnez un nom explicite à votre snapshot, par exemple avant-deploiement-nextjs, puis lancez sa création.

Les VPS KVM LWS permettent de conserver plusieurs snapshots simultanés, ce qui est pratique pour sécuriser les grandes étapes de configuration serveur.

Installer Node.js sur le VPS

Une application Next.js fonctionne avec Node.js. Sur un VPS Linux, vous devez donc installer une version compatible avant de cloner et builder votre projet. La méthode recommandée ici consiste à utiliser nvm, pour Node Version Manager. Cet outil permet d’installer facilement une version LTS de Node.js, de la mettre à jour et de gérer plusieurs versions si nécessaire.

Connectez-vous d’abord à votre serveur en SSH avec votre utilisateur root ou un utilisateur disposant des droits nécessaires, puis installez nvm :

# Installer nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

# Recharger le shell
source ~/.bashrc

# Installer la version LTS de Node.js
nvm install --lts

# Vérifier les versions installées
node --version
npm --version

La commande nvm install --lts installe la version Long Term Support de Node.js. C’est généralement le meilleur choix pour un serveur de production, car cette version bénéficie d’un support plus stable dans le temps.

Une fois Node.js et npm disponibles, installez PM2 globalement. PM2 servira ensuite à maintenir votre application Next.js active en production, même après un crash ou un redémarrage du serveur.

npm install -g pm2

pm2 --version

Préparer l’application Next.js pour la production

Avant de copier ou de lancer votre projet sur le serveur, il faut vérifier que votre application Next.js est prête pour un déploiement en production. L’objectif est de générer un build optimisé, plus léger et plus simple à exécuter sur un VPS Linux.

Dans ce tutoriel, nous allons utiliser le mode standalone de Next.js. Ce mode produit un dossier autonome contenant uniquement les fichiers nécessaires à l’exécution de l’application. Il est particulièrement adapté à un déploiement avec Node.js, PM2 et Nginx.

1. Activer le mode output: ‘standalone’ dans next.config.js

Le mode standalone se configure directement dans le fichier next.config.js ou next.config.ts de votre projet. Il permet à Next.js de générer un dossier .next/standalone/ contenant un fichier server.js et les dépendances nécessaires à l’exécution de l’application.

Dans votre projet local, ouvrez le fichier de configuration Next.js et ajoutez l’option suivante :

// next.config.js
const nextConfig = {
  output: 'standalone',
};

export default nextConfig;

Si votre projet utilise encore une syntaxe CommonJS, la configuration peut ressembler à ceci :

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};

module.exports = nextConfig;

.next/standalone/server.js

Concrètement, cela rend le déploiement plus propre, plus prévisible et mieux adapté à une gestion en production avec PM2.

2. Variables d’environnement

Les variables d’environnement permettent de stocker les informations sensibles ou spécifiques à votre environnement de production : URL de base de données, clé secrète d’authentification, jetons API, URL publique de l’application ou paramètres SMTP. Sur un VPS Linux, elles doivent être gérées avec soin, car elles conditionnent le bon fonctionnement et la sécurité de votre application Next.js.

La règle principale est simple : ne commitez jamais vos fichiers .env dans votre dépôt Git. Un fichier comme .env.production doit être créé directement sur le serveur, ou bien ses valeurs doivent être définies dans la configuration PM2.

Attention également aux variables préfixées par NEXT_PUBLIC_. Dans Next.js, ces variables sont exposées côté navigateur. Elles peuvent donc être lues par les visiteurs de votre site. Il ne faut jamais y placer de secrets, de mots de passe, de clés privées ou d’identifiants de base de données.