---
title: L'architecture pragmatique de mes projets en production
date: !!timestamp '2026-03-05 15:00:00'
tags:
- architecture
- web
- infrastructure
---

Lorsqu'on lit certaines discussions entre développeurs ou architectes
logiciels, on pourrait croire que la moindre application web nécessite
aujourd'hui une infrastructure distribuée, un cluster Kubernetes et
plusieurs services cloud spécialisés.

Pourtant, de nombreux services web (y compris ceux qui accueillent
plusieurs milliers de visiteurs par jour) peuvent fonctionner
parfaitement avec une architecture beaucoup plus simple.

Voici un retour d'expérience sur l'infrastructure que j'utilise pour
mes projets en production, dont certains dépassent les 5000 visiteurs
quotidiens, et que j'ai également appliqué pendant des années lors
d'une compétition de sécurité informatique avec plus de 250
participants en présentiel.

<!-- more -->

# Contexte

Pendant longtemps, j'ai hébergé l'ensemble de mes projets directement
chez moi. Mes sites web, mes services, ma forge Git et même mon
infrastructure d'intégration continue tournaient sur de petites
machines ARM (principalement des Pine64).

Contrairement à ce que j'entends partout, cela fonctionnait très bien.

La principale raison pour laquelle j'ai arrêté n'est pas un problème
de puissance de calcul ou de fiabilité, mais simplement mon passage à
un mode de vie plus nomade. Une connexion résidentielle stable et
permanente devient difficile à garantir lorsque l'on se déplace
souvent.

J'ai donc déplacé la partie publique de mes services chez OVH, en
essayant de conserver la même philosophie : simplicité et pragmatisme.


# Une observation simple

Dans beaucoup de projets web modernes, l'architecture ressemble à
quelque chose comme ceci :

```
utilisateur → CDN → frontend → API → base de données
```

Chaque requête déclenche du calcul côté serveur, même lorsque le
contenu change très rarement.

Dans mon cas, plusieurs de mes sites ont une caractéristique
importante : **le contenu principal change une fois par jour.**

Prenons par exemple le [jeu quotidien
Yakazu](https://yakazu-gratuit.fr/) : pour la majorité des visiteurs,
la seule chose qui compte est **la grille du jour**, qui ne change
qu'une fois par jour.

Dans ces conditions, générer la page dynamiquement à chaque requête
n'a pas beaucoup de sens.

# Architecture retenue

La solution est donc très simple : le site est entièrement statique.

Chaque jour, un événement déclenche la CI qui :

1. génère la nouvelle grille ;
2. reconstruit le site ;
3. publie les fichiers statiques.

Ces fichiers sont ensuite servis directement par l'hébergement
statique fourni avec le nom de domaine chez OVH.

Oui, l'offre gratuite de 100 MB.

Cela donne donc une architecture très simple :

```
CI → génération du site → fichiers statiques → OVH
```

Tout le trafic est absorbé par l'infrastructure de l'hébergeur, ce
qui est exactement ce pour quoi elle est conçue.


# Frontend

Le site est construit avec SvelteKit.

Ce choix peut surprendre puisque je n'utilise pas du tout les
capacités serveur de ce framework. Mais il permet :

- de générer facilement un site statique (`@sveltejs/adapter-static`) ;
- d'avoir un routage propre ;
- de structurer le code proprement ;
- de construire des Progressive Web Apps.

Autrement dit : un framework moderne, mais sans dépendre d'un backend
permanent.

# Et quand il faut un backend ?

Certaines fonctionnalités nécessitent malgré tout un peu de logique
serveur.

Par exemple, les championnats organisés régulièrement doivent vérifier les
participations et enregistrer les résultats et les chronos.

Dans ce cas, je démarre un petit serveur backend séparé, qui ne reçoit
qu'un nombre très limité de requêtes.

L'architecture devient alors :

```
site statique → CORS → petit backend
```

Ce backend est volontairement minimal et ne traite que les actions
qui ne peuvent pas être réalisées côté client.

Le point important est que **la majorité du trafic ne le touche
jamais**.

# Résultat

Avec cette architecture :

- la quasi-totalité du trafic est servie sous forme de fichiers ;
- il n'y a quasiment pas de calcul côté serveur ;
- la surface de panne est très réduite.

Les problèmes que je rencontre sont presque toujours liés au pipeline
de génération :

- une image Docker qui n'est plus à jour ;
- un déclenchement CI qui échoue ;
- un oubli dans la génération des données (l'absence de grille de jeu par exemple).

Mais ces problèmes sont faciles à détecter et se corrigent
généralement en quelques minutes.

# Pourquoi faire simple ?

Avec un peu de recul, je me rends compte que cette approche suit
quelques principes simples :

1. **pré-calculer ce qui peut l'être** ;
2. **servir des fichiers plutôt que du calcul** ;
3. **réserver le backend aux cas réellement nécessaires**.

Ces principes permettent souvent d'absorber une charge importante
avec des ressources très modestes.

Pendant plus de dix ans, j'ai par exemple organisé un challenge de
sécurité informatique qui a fini par accueillir environ 300
participants simultanés, avec des machines très simples.

Le secret n'était pas la puissance du matériel, mais la conception du
système. Je vous laisse visionner ma [présentation de cette
infrastructure](https://youtube.com/watch?v=naFxBW5yoUA), avec les
tâtonnements, les erreurs et les contraintes qui l'ont façonné.

# Et les comptes utilisateurs, les paiements ?

Une "connexion" à un compte utilisateur n'a pas nécessairement besoin
d'une validation systématique par un backend (d'ailleurs la notion de
compte utilisateur n'a pas toujours de sens).

Une seule requête d'API peut faire l'authentification (que ce soit
la validation d'un paiement ou d'une adresse email, ...) puis on
stocke cette réponse dans le navigateur pour en faire usage dans
l'interface : maintenant ... ou même plus tard. Comme ça, inutile de
refaire une requête à l'API pour une information que l'on a déjà.

Non seulement cela réduit la charge du serveur, mais cela accroit
aussi la vitesse de chargement pour l'utilisateur qui voit ses données
sans appel réseau, et donc même hors ligne. Tout le monde est gagnant.

# Conclusion

L'infrastructure moderne propose de nombreux outils très puissants.
Mais il est parfois utile de se rappeler que beaucoup de problèmes
peuvent être résolus de manière beaucoup plus simple.

Avant d'ajouter une nouvelle couche technologique, il vaut souvent la
peine de se poser une question très simple :

**est-ce que ce contenu doit vraiment être généré à chaque requête ?**

Dans bien des cas, la réponse est non.
