Kubernetes, c’est l’Arlésienne de la tech : ça fait des années qu’on en parle, et les influenceurs « apprends ça pour percer en 2026 » continuent de le placer en haut de la liste des technos à maîtriser, le Graal à atteindre. Pourtant, pour ce blog, j’ai fait un choix que l’on pourrait qualifier aujourd’hui de « pas sexy » : un site statique généré via Hugo et déployé par une simple GitHub Action qui pousse les fichiers en FTP sur un hébergement mutualisé OVH.

C’est un choix qui peut surprendre, venant de quelqu’un qui a de l’expérience sur des infras plus lourdes. N’y voyez pas un manque d’ambition technique, mais plutôt un exercice de pragmatisme : avant de monter un cluster, la vraie question n’est pas « est-ce que je sais faire », mais « est-ce que mon besoin le justifie ».

Illustration : un blog n’a pas besoin de Kubernetes
Illustration générée par IA (ChatGPT / DALL·E).

Partir du besoin, pas de la solution

En bon rationnel, j’aime partir du besoin avant de chercher une solution. En juin, j’ai lancé mon activité freelance de conseil, pour proposer mon expérience de l’industrie et accompagner des projets avec une dimension humaine. J’aime apprendre, partager, enseigner : ce blog, c’est pour moi le support idéal pour le faire.

Je démarre dans mon activité, mes fonds ne sont pas illimités et mon temps non plus. Je préfère le passer à accompagner des équipes plutôt que de subir le stress d’alertes d’infrastructure tous les jours (croyez-moi, j’en ai déjà vécu avec NuCorder ).

Le blog est donc pensé au plus simple : un site statique. Du texte, quelques images, pas de backend, pas de base de données, pas de compte utilisateur. Le trafic reste modeste — largement en dessous de ce qui justifierait de réfléchir à la charge ou à la scalabilité.

L’enjeu, ici, n’est pas technique. Il est économique et humain.

Hugo : l’outil qui me correspond

Je suis développeur à la base, spécialisé sur Go et le DevOps depuis quelques années. J’ai pu contribuer à des projets open source tels que Buffalo , me familiariser avec la communauté Go et ses projets phares.

Dans ce contexte, j’ai découvert Hugo , un générateur de sites statiques clef en main et bénéficiant de deux caractéristiques de Go que j’apprécie depuis le début : la rapidité d’exécution et le packaging en un binaire unifié (ce qui est un bonheur absolu quand on a déjà déployé des langages non compilés en prod). En bonus, je connais le langage et je peux donc y apporter des correctifs au besoin.

Un site statique, c’est un peu moins flexible vu qu’on doit redéployer à chaque modification, mais c’est aussi un bon nombre d’avantages : pas de runtime applicatif à faire tourner, pas de base de données à sécuriser, beaucoup moins de dépendances à maintenir en production. Une fois déployé, la surface d’exploitation est minime.

Hugo est donc mon choix : j’ai choisi l’outil le plus efficace et économique, adapté à mon expérience.

Un déploiement qui tient en deux étapes

Le pipeline, je l’ai voulu aussi simple que le reste : une GitHub Action lance le build Hugo, puis pousse les fichiers générés en FTP vers l’hébergement mutualisé OVH. Rien d’exotique, juste ce qu’il faut.

yaml 
name: Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: '0.163.3'
          extended: true

      - name: Build
        run: hugo --minify

      - name: Deploy to OVH
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets.OVH_FTP_SERVER }}
          username: ${{ secrets.OVH_FTP_USERNAME }}
          password: ${{ secrets.OVH_FTP_PASSWORD }}
          protocol: ftp
          local-dir: ./public/
          server-dir: ${{ vars.OVH_FTP_REMOTE_DIR }}

Le workflow se déclenche à chaque push sur main. Je n’ai jamais eu à y retoucher depuis sa mise en place.

Ce que ça coûte vraiment

Un hébergement mutualisé chez OVH démarre à 3,95 €/mois. Un cluster Kubernetes managé , même réduit à l’os — deux petits nœuds pour conserver un minimum de redondance — tourne autour de 50 €/mois chez le même hébergeur. Chiffres constatés au moment où j’écris ces lignes (août 2026) : les tarifs cloud bougent vite, plutôt à la hausse ces derniers mois, avec la pression sur le prix du hardware.

Même constat chez AWS : leur control plane EKS est facturé à l’heure , qu’il y ait zéro ou dix nœuds actifs, ce qui pousse la facture minimale au-delà de 95 €/mois.

Dans les deux cas, je paierais pour une résilience et une scalabilité dont ce blog n’a tout simplement pas l’usage.

Ce que j’en retiens

Apprendre à manier de grosses technos reste gratifiant, et je continue de le faire — ce n’est pas une critique de Kubernetes en soi. Mais j’ai appris, au fil de mes expériences, que la compétence senior ne se mesure pas qu’à ce qu’on sait construire : elle se mesure aussi à ce qu’on choisit de ne pas construire. Côté décideurs, challenger le dimensionnement proposé par son équipe technique n’est pas de la méfiance : c’est du bon sens budgétaire.

Choisir simple ne veut pas dire choisir négligent : versionnez votre code, sauvegardez ce qui doit l’être ailleurs que sur le serveur — l’incendie qui a détruit le datacenter d’OVH à Strasbourg en 2021 nous l’a rappelé une fois pour toutes.

Votre infra vous coûte plus cher que ce dont vous avez besoin ?

Si cet article vous a fait repenser le dimensionnement de votre propre infra, ou si vous vous posez la question sans oser la trancher en interne, n’hésitez pas à m’en parler.

Parlons-en