Infrastructure d'un SaaS B2B
Mission freelance - infrastructure complète du MVP
2026 | Livré, en recette chez le client
Le client et le nom du produit ne sont pas publiés ici, le produit n'étant pas encore lancé. Tout ce qui suit décrit mon travail d'infrastructure, pas le sien.
Le contexte
Un éditeur avec un produit à construire et personne pour tenir la partie infrastructure.
La demande
Construire l'intégralité de l'infrastructure du MVP : provisionnement, configuration, pipelines de déploiement, supervision, sauvegardes, et la documentation qui permet à l'équipe de reprendre la main.
J'ai commencé par un document d'architecture technique, validé par le client avant la première ligne de configuration.
La contrainte
Le produit exécute des traitements Python longs, de l'ordre de plusieurs minutes, avec un accès au système de fichiers. Le tout-serverless était donc exclu.
Il fallait un frontend déployé en continu et un environnement persistant à côté, sans faire exploser ni la facture ni la charge d'exploitation d'une petite équipe. D'où une architecture hybride plutôt qu'un seul fournisseur.
L'architecture
Chaque brique a été choisie contre une alternative, et le choix est écrit dans le document d'architecture.
| Couche | Composant | Rôle |
|---|---|---|
| Frontend | Vercel | Next.js déployé à chaque merge, CDN mondial, SSL automatique, URL de préversion par pull request |
| Traitements | VPS Hetzner, Docker Compose | Workers Python pour des traitements longs, derrière un reverse proxy Nginx avec SSL Certbot |
| Données | PostgreSQL managé + pgvector | Base, authentification et vector store sur une seule plateforme, restauration à un instant donné sur 7 jours |
| Réseau | Tailscale | Administration par réseau privé. Aucun port SSH exposé sur l'Internet public |
| Supervision | New Relic décrit en Terraform | Tableaux de bord, conditions d'alerte NRQL, sondes synthétiques et canaux de notification versionnés |
| Sauvegardes | Rôle Ansible dédié | Sauvegardes planifiées sur volume séparé, procédure de restauration écrite et rejouable |
| Disponibilité | IP flottante Hetzner | Bascule vers un serveur de secours sans changement DNS |
| CI/CD | GitHub Actions | Neuf workflows : plan Terraform sur les changements d'infra, déploiement applicatif, contrôles de cohérence, synchronisation staging vers main |
Ce que j'ai livré
Une infrastructure que le client peut reconstruire, comprendre et exploiter sans moi.
Infrastructure décrite en Terraform
Serveurs, volumes, IP flottante, règles de pare-feu et clés SSH. L'environnement se reconstruit depuis le dépôt, sans clic dans une console.
Neuf rôles Ansible
Socle système, Docker, pare-feu, utilisateur de déploiement, volume de travail, réseau privé, agent de supervision, sauvegardes, IP flottante. Chaque rôle est rejouable sans effet de bord.
Observabilité en code
La supervision n'est pas configurée à la main dans une interface. Les tableaux de bord, les alertes NRQL et les sondes synthétiques sont versionnés avec le reste de l'infrastructure.
Pipelines et garde-fous
Le plan Terraform s'exécute sur toute modification d'infrastructure et doit être lu avant fusion. Des contrôles de cohérence bloquent les écarts entre le schéma de base et le code.
Secrets et accès
Chiffrement des variables sensibles avec Ansible Vault, rotation documentée, accès administrateur limité au réseau privé.
Onze runbooks
De la restauration de sauvegarde au plan de reprise, en passant par la gestion d'incident et la montée en charge. L'équipe peut exploiter sans moi.
Les runbooks
Une infrastructure que personne ne sait redémarrer n'est pas livrée. Onze procédures ont été écrites avec le reste, en voici huit.
Les objectifs du document d'architecture
Les cibles écrites et validées avec le client avant la construction. Le produit étant en recette, elles ne sont pas encore mesurées en production.
Déploiement
Moins de 5 min du push à la mise en ligne
Retour arrière
Moins de 2 min en cas d'incident
Alerte
Moins de 2 min après un incident de production
Sécurité
Aucun secret en clair, HTTPS partout, isolation par organisation
Où en est le projet
L'infrastructure du MVP est livrée et fonctionne. Le produit, lui, est encore en développement et en recette : il n'est pas ouvert au public.
Je préfère le dire plutôt que de laisser croire à une mise en production. Ce qui est terminé, c'est la partie dont j'étais responsable.
- Infrastructure reconstructible depuis le dépôt
- Supervision et alertes actives
- Sauvegardes planifiées et procédure de restauration écrite