Il n’y a pas d’âge pour entreprendre. Et c’est vrai. Je l’avais déjà constaté en écoutant celles et ceux qui témoignaient sur Renacast, qu’anime @Nicolas, oui celui que vous lisez chaque jour sur mychromebook. A chaque écoute d’un nouvel épisode, je me disais « Et pourquoi pas moi ? » On peut avoir l’envie, mais encore faut-il avoir l’idée. Celle qui vous lance à créer une entreprise. Bref, à concrétiser une idée. C’est au détour d’une discussion et d’une demande de @Nicolas, et oui encore lui, que j’ai décidé de franchir le Rubicon. Pas de précipitation, pas de produit encore en vente, pas d’usines dans le Morvan, mais on est sur le chemin de la réalisation et mise en vente des produits. Sans vous dévoiler le projet en cours de développement, sachez que j’ai besoin d’un VPS soit un Virtual Private Server (ou Serveur Privé Virtuel en français).

Cet article raconte ma première installation d’un serveur dédié virtuel (VPS) de A à Z. Je l’écris pour toi qui n’as jamais touché à un serveur, qui te demandes si c’est compliqué, qui cherches un retour d’expérience honnête. Je n’avais aucune connaissance préalable il y a 48 heures avant de commencer la rédaction de cet article. J’avais juste un projet qui avait besoin d’un backend pour effectuer des opérations. Spoiler : ça s’est bien passé. Mais il y a eu des moments où j’ai cru tout casser.

Sommaire

Toggle

A retenir :

Récit d’une première mise en service d’un serveur virtuel sous Ubuntu 24.04 pour un backend de calcul, détaillant le passage de l’hébergement mutualisé à l’administration complète d’une instance cloud.

Pourquoi j’ai eu besoin d’un VPS

Le site existe déjà, hébergé chez o2switch sur un hébergement mutualisé classique. Cela suffit largement. Mais j’avais besoin d’une fonction de calcul puissante et permettant de répondre en quelques secondes à la demande. Concrètement, mon backend doit pouvoir tourner en permanence, et fait des appels à une API externe. Ce genre de chose ne tourne pas sur un espace mutualisé : il faut un environnement où je peux installer ce que je veux, lancer des services en arrière-plan, ouvrir des ports réseau. C’est exactement ce que propose un VPS.

Un VPS, en gros, c’est une machine Linux complète, virtualisée, qui m’appartient pendant que je paie l’abonnement. Je suis administrateur, je fais ce que je veux dessus. Ça me terrifiait un peu, parce que jusqu’ici je n’avais jamais rien administré d’autre qu’un panneau cPanel.

« Avec un VPS, tu es seul aux commandes. Personne ne va patcher tes failles à ta place. C’est à la fois grisant et angoissant. »

Choisir un hébergeur

J’ai comparé pas mal d’offres avant de choisir. Voici les 4 que j’ai sérieusement considérées :

OVH (français, Roubaix/Strasbourg/Gravelines)

Le poids lourd français. J’ai eu une mauvaise expérience avec OVH quand j’étais au Québec (un site qui ne démarrait jamais, support qui répondait en deux jours minimum avec beaucoup de relances), donc j’ai instinctivement écarté. Pas forcément justifié, leur offre actuelle est compétitive, mais on a tous nos blessures.

Hetzner (allemand, Falkenstein/Nuremberg/Helsinki)

Excellent rapport qualité/prix, hyper réputé dans la communauté tech. Mais les serveurs sont en Allemagne ou Finlande, et je voulais que mes données restent en France pour une question de transparence avec mes futurs clients (RGPD oblige).

Infomaniak (suisse)

Bonne réputation, datacenters Suisse et France, mais leur offre VPS commence à 29 €/mois. Trop cher pour démarrer un projet sans (presque) de certitude de revenus. Normal, je doute un peu, même si j’y crois.

Scaleway (français, Paris/Amsterdam/Varsovie)

Anciennement Online.net (Iliad), 100 % français. Datacenters à Paris, prix très compétitifs (à partir de 7 € HT/mois pour la config dont j’avais besoin), interface moderne, bonne réputation. C’est ce que j’ai choisi.

Le choix final

J’ai pris le VPS-START-2-S à 6,99 € HT/mois : 2 vCPU, 2 Go de RAM, 30 Go de SSD, hébergé à Paris. Largement assez pour un backend et une marge confortable pour grossir.

Hébergeur	Localisation	Prix de départ	Choix
OVH	France	~6 €/mois	Mauvaise expérience
Hetzner	Allemagne / Finlande	~5 €/mois	Pas en France
Infomaniak	Suisse / France	29 €/mois	Trop cher pour démarrer
Scaleway	Paris	6,99 € HT/mois	★ Choisi

Préparer le terrain avant la commande

Avant même de payer, il y a quelques préparatifs malins à faire. J’aurais aimé qu’on me les explique avant que je découvre tout sur le tas.

Créer une adresse email dédiée

J’ai créé une adresse xxxx.xxxx@chaptime.fr (sur mon hébergement existant). Tous les emails de l’hébergeur (factures, alertes, renouvellement de certificat SSL…) y arriveront. C’est super pratique pour ne pas mélanger ça avec ses emails perso, et pour passer le compte à quelqu’un d’autre plus tard si besoin.

Créer un compte Google dédié à l’infra

J’ai aussi créé un compte Google séparé (xxxxx.xxxxxx@gmail.com) pour me connecter à des services tiers. Cela sépare bien les usages, c’est plus propre.

Générer une paire de clés SSH

C’est l’étape qui m’a fait le plus douter. Je ne savais pas du tout ce que c’était. En réalité, c’est très simple : tu génères deux fichiers cryptographiques sur ton ordi. Le « public » tu le donnes au serveur (ça ne craint rien si quelqu’un le lit). Le « privé » tu le gardes secret, c’est ce qui prouve que c’est toi quand tu te connectes.

Sur mon Chromebook, j’ai activé Linux dans les paramètres ChromeOS, ouvert un terminal, et tapé :

ssh-keygen -t ed25519 -C "xxx.xxxx@chaptime.fr"

Le terminal m’a posé deux questions : où enregistrer (j’ai laissé par défaut, ~/.ssh/id_edxxxxx, mais j’ai préféré le renommer chaptime_prod) et la « passphrase » (un mot de passe qui chiffre la clé privée, au cas où quelqu’un mettrait la main dessus). J’ai mis une passphrase forte, que j’ai immédiatement archivée dans mon gestionnaire de mots de passe.

« Conseil capital : ta clé privée SSH, c’est la clé de ta maison. Si tu la perds, tu n’entreras plus jamais. Si quelqu’un d’autre la trouve, il peut tout faire. Sauvegarde-la sur clé USB rangée dans un tiroir. »

Commander le VPS

Sur Scaleway, j’ai choisi l’offre, la localisation Paris, l’OS Ubuntu 24.04 LTS (la dernière version stable avec 5 ans de support de sécurité), donné un nom à mon serveur (chaptime-prod), et déposé ma clé SSH publique. Petite anecdote au passage : au moment de valider la commande, je suis tombé sur un bug Scaleway. Le bouton « Valider et payer » affichait systématiquement une erreur sur les CGV alors que j’avais bien coché la case. J’ai cru que je faisais quelque chose de travers. Relu, refait, refait encore. J’ai même essayé en navigation privée. Toujours bloqué.

J’ai ouvert un ticket support en mode « je suis poli mais désespéré« . Le support de Scaleway m’a répondu deux fois dans la journée : c’était bien un bug de leur côté, ils investiguaient. Ils m’ont donné l’URL de leur page d’incident pour suivre la résolution. Le lendemain matin, le bug était résolu, j’ai pu valider. Total facturé : 6,09 € HT (prorata du mois en cours). Vingt minutes plus tard, je recevais un email de confirmation avec l’IP de mon serveur.

« Quand tu fais quelque chose pour la première fois, tu présumes que toute erreur vient de toi. C’est rarement le cas. Avant de te taper la tête contre les murs pendant deux heures, ouvre un ticket support. »

Première connexion : le moment magique

Avec l’IP en main, je suis retourné dans mon terminal Linux, et j’ai tapé :

ssh -i ~/.ssh/chaptime_prod root@104.168.xx.xxx

Décodage : ssh, c’est le programme qui se connecte à un serveur distant en mode terminal. -i ~/.ssh/chaptime_prod, c’est le chemin vers ma clé privée. root@104.168.xx.xxx, c’est l’utilisateur (« root » = administrateur sur Linux) suivi de l’IP du serveur.

Le terminal m’a posé deux questions : la première, parce qu’il ne connaissait pas encore l’identité du serveur (j’ai répondu « yes » pour accepter), et la deuxième, c’était ma passphrase (le mot de passe de ma clé privée). Trois secondes plus tard, j’étais à l’intérieur. Le prompt avait changé : root@chaptime-prod:~#. Je tapais des commandes qui s’exécutaient sur un serveur à Paris pendant que je buvais mon café dans le Morvan.

« C’est beau d’écrire « ls » et de voir s’afficher la liste des fichiers d’une machine qui n’est pas la tienne, à 350 km de distance, dans un datacenter parisien. »

Aparté : la géolocalisation des IPs

Mon IP commençait par 104.168, ce qui m’a fait paniquer une seconde : ça ressemble à une IP nord-américaine. J’ai bien vérifié dans la console Scaleway, le serveur était bien à Paris. Pour confirmer, j’ai utilisé un service de géolocalisation IP :

curl https://ipapi.co/104.168.xx.xxx/json/

Le résultat confirmait : Paris, Île-de-France, France, fuseau Europe/Paris, code postal 75001. Les blocs d’IP sont historiques, certains « américains » ont été rachetés par des hébergeurs européens. Ce qui compte, c’est le serveur physique, pas le préfixe de l’IP.

Sécuriser dès le début

Première chose à faire en arrivant sur un serveur frais : la mise à jour. Toujours. Si vous posez la question à @Didier sur Discord, c’est la première commande qu’il vous demandera de taper dans le terminal Linux de votre Chromebook, si une appli fonctionne mal.

apt update && apt upgrade -y

Cette commande va chercher la liste des paquets à mettre à jour (apt update), puis applique tous les correctifs (apt upgrade -y, le -y c’est pour répondre « oui » à toutes les questions). Sur mon serveur, ça a installé un nouveau noyau Linux et plein d’autres choses. Cinq minutes après, il fallait redémarrer pour activer le nouveau noyau :

reboot

Le redémarrage coupe ta connexion SSH, mais le serveur revient en moins d’une minute. Tu te reconnectes, et tu es sur la version la plus à jour de l’OS. C’est la base : ne JAMAIS commencer à installer des choses sur un serveur sans avoir d’abord appliqué tous les correctifs de sécurité.

Installer mon backend

Ici, l’expérience varie complètement selon ce que tu veux faire tourner. Dans mon cas, j’avais préparé un script d’installation qui fait tout en une commande : créer quelques dossiers et installer plein de paquets. Créer un utilisateur dédié pour mon backend, déployer le code, configurer le service système, etc.

J’ai d’abord transféré mon code (un fichier .zip de quelques dizaines de Ko) depuis mon ordi vers le serveur :

scp -i ~/.ssh/chaptime_prod ~/chaptime-backend.zip root@104.168.10.xx.xxx:/root/

Puis dans le SSH du serveur, j’ai dézipé et lancé le script :

cd /root
unzip chaptime-backend.zip
cd chaptime-backend
bash scripts/install.sh

Dix minutes plus tard, tout était installé. Mon backend était déployé dans /opt/chaptime-backend, géré par systemd (le système de services de Linux), prêt à démarrer.

Pointer le nom de domaine et activer le HTTPS

Mon serveur tournait, mais il était accessible uniquement via son IP. Je voulais y accéder via api.chaptime.fr. Pour ça, il a fallu modifier la zone DNS de mon domaine. Chez o2switch (mon registraire), je suis allé dans « Éditeur de zone DNS » du cPanel, j’ai cherché l’enregistrement de type A pour api.chaptime.fr, et j’ai remplacé l’IP qui était là par celle de mon nouveau VPS. La propagation DNS a été quasi instantanée (moins d’une minute). Pour vérifier que la propagation avait bien fonctionné, j’ai testé depuis mon serveur :

dig api.chaptime.fr +short

Et j’ai vu apparaître mon IP. Magique. Ensuite, le certificat HTTPS gratuit avec Let’s Encrypt :

certbot --nginx -d api.chaptime.fr

Quelques questions interactives (mon email pour les alertes de renouvellement, l’acceptation des conditions générales), et 30 secondes plus tard, mon API était accessible en HTTPS avec un certificat valide. Et le mieux : Let’s Encrypt renouvelle automatiquement tous les 60 jours, sans rien faire de mon côté.

Les bugs qu’on n’avait pas vu venir

À ce stade, tout devrait marcher. Sauf qu’évidemment, quand j’ai testé mon API avec curl https://api.chaptime.fr/health, j’ai reçu une erreur 301 (redirection en boucle) au lieu de la réponse JSON attendue.

Investigation : certbot avait modifié ma config nginx d’une façon un peu particulière, et il y avait un conflit entre deux blocs de configuration. J’ai dû reconstruire le fichier de configuration nginx à la main, puis débugger encore deux ou trois petites erreurs (une syntaxe HTTP/2 différente sur Ubuntu 24.04, des directives SSL en doublon…). Au total, j’ai passé environ 20 minutes à débugger ces histoires de config nginx. Dans le bon ordre, c’est rapide.

« Les tutoriels sur internet montrent toujours le « happy path ». La réalité, c’est qu’il y a toujours un truc qui ne marche pas comme prévu. Accepte-le, c’est normal. »

Le moment de gloire

Une fois les bugs réglés, j’ai retapé la commande de test :

curl https://api.chaptime.fr/health

Et j’ai vu :

{"status":"ok","version":"1.0.0","queue":{"pending":0,"size":0}}

Ce JSON tout simple, c’était la preuve que ma chaîne complète fonctionnait : le DNS qui résout vers la bonne IP, nginx qui écoute en HTTPS sur le port 443, le reverse-proxy qui passe la requête à mon backend, qui répond. Toute cette infrastructure était à moi, tournait 24/7 dans un data-center parisien, et m’a coûté environ 7 € pour le mois en cours. J’ai eu un grand sourire. Et pu finir de boire un bon café !

Et maintenant ?

Avoir un VPS qui tourne, c’est génial. Mais ce n’est pas une boîte qu’on installe et qu’on oublie. Il faut s’en occuper un peu, comme on s’occupe de sa voiture : vidange, contrôle technique, vérification des feux.

Concrètement :

• Surveiller les emails de l’hébergeur (factures, alertes de sécurité, maintenance planifiée)
• Faire les mises à jour de sécurité au moins une fois par semaine (apt update && apt upgrade)
• Vérifier de temps en temps les logs : pas d’activité bizarre ? Pas de tentatives de connexion suspectes ?
• S’assurer que les sauvegardes fonctionnent (parce qu’un VPS, ça peut planter, et l’hébergeur ne fait pas forcément de backup automatique)

J’ai prévu un document séparé, « Maintenance d’un VPS« , qui détaille tout ça avec des checklists pratiques. Que je me garde pour moi (parce que c’est devenu mon doudou de débutant).

Ce que je retiens

Si tu hésites à te lancer dans un VPS parce que tu te sens illégitime techniquement, voilà ce que je te dirais :

Premièrement, c’est moins compliqué qu’on le croit. Les hébergeurs modernes ont des interfaces propres, les outils Linux sont bien documentés, les forums sont pleins de gens qui ont eu les mêmes problèmes que toi.

Deuxièmement, c’est plus compliqué qu’on le dit dans les tutoriels « Installez un VPS en 5 minutes !« . Il y a toujours un truc qui ne se passe pas comme prévu. Tu vas paniquer une ou deux fois. C’est normal.

Troisièmement, n’aie pas peur d’écrire des questions à un assistant ou à un forum. Pour cette installation, j’ai eu un coup de main d’un assistant IA (Claude pour ne pas le nommer) qui m’a guidé étape par étape. Sans lui, j’aurais probablement abandonné à la première erreur de config nginx. Il n’y a aucune honte à demander.

Quatrièmement, sauvegarde tout. Tes clés SSH, tes mots de passe, ta configuration. Avoir une copie de tout ce qui a été fait, c’est ce qui te permet de dormir tranquille.

Et dernièrement, savoure le moment où tu vois ton API répondre depuis ton serveur. C’est un petit miracle qu’on tient pour acquis dans ce métier, mais quand on le fait pour la première fois, ça reste impressionnant.

« Hier matin, je n’avais jamais touché un VPS. Aujourd’hui, j’ai un serveur en production hébergé en France, sécurisé, avec un certificat HTTPS automatique, qui répond à mes requêtes. Si moi j’ai pu le faire, toi aussi. »

Une question ? Un blocage ? Rejoins le forum Discord mychromebook, Didier, Nicolas et moi-même y répondons régulièrement. Comme d’autres utilisateurs de Chromebook.

FAQ (Foire Aux Questions)

Pourquoi choisir un VPS plutôt qu’un hébergement mutualisé ?

Le VPS offre une liberté totale d’installation et permet de faire tourner des processus en arrière-plan ou des API gourmandes en calcul, ce que le mutualisé interdit.

Qu’est-ce qu’une clé SSH et pourquoi est-ce important ?

C’est un couple de fichiers cryptographiques qui remplace le mot de passe. C’est la méthode la plus sûre pour s’identifier sur son serveur et empêcher les intrusions.

Quelle est la première commande à taper sur un nouveau serveur ?

Il faut impérativement mettre à jour le système avec apt update && apt upgrade -y pour corriger immédiatement les failles de sécurité.