diff --git a/content/fr/post/pragmatic-architecture-for-productions/index.md b/content/fr/post/pragmatic-architecture-for-productions/index.md new file mode 100644 index 0000000..ac74e9e --- /dev/null +++ b/content/fr/post/pragmatic-architecture-for-productions/index.md @@ -0,0 +1,198 @@ +--- +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 2000 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. + + + +# 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 des 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 (le manque 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 +tatonnements, les erreurs et les contraintes qui l'on 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 +l'authentification du 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.