Je construis des infrastructures qui tiennent en production.

Une infrastructure montée à la main ne se reproduit pas. Le serveur qui tourne depuis deux ans, personne ne sait exactement ce qu'il y a dessus — et le jour où il faut le remonter, la seule documentation fiable est le serveur lui-même.

Toute l'infra décrite en code : Terraform pour le provisionnement des VMs, des réseaux et des règles de filtrage, avec un state distant versionné et verrouillé. Ansible prend le relais pour la configuration — utilisateurs, SSH, durcissement, installation des services en rôles réutilisables. Le tout déclenché par GitHub Actions, avec un `plan` relu avant chaque `apply`.

Séparation stricte entre ce qui crée la ressource et ce qui la configure : Terraform ne fait pas de configuration système, Ansible ne crée pas de VM. C'est ce qui permet de reconstruire une machine à l'identique sans rejouer toute la chaîne, et de garder un state lisible quand plusieurs personnes travaillent sur la même infra.

Une infrastructure reconstructible de zéro en une commande, supervisée par Prometheus et lisible dans Grafana, avec des déploiements applicatifs conteneurisés et des accès SSH gérés côté code plutôt qu'à la main sur chaque machine.

Une plateforme utilisée quotidiennement par des milliers d'écoles, d'entreprises et d'étudiants, en architecture microservices. Chaque minute d'indisponibilité se voit immédiatement côté clients, et les incidents arrivent rarement aux heures ouvrées.

Administration et maintenance de l'infrastructure de production : environnements Linux, déploiement Docker des services, administration des bases PostgreSQL, configuration et maintenance des pipelines CI/CD. Monitoring en place pour détecter la dérive avant l'alerte utilisateur.

Traiter chaque incident jusqu'à la cause, pas jusqu'au redémarrage. Un service qu'on relance sans comprendre retombe la semaine suivante, à un moment moins pratique. À cette échelle, le temps passé sur le post-mortem est toujours rentable comparé au temps passé à éteindre deux fois le même feu.

Une production tenue à +3 000 utilisateurs actifs/jour, des déploiements outillés plutôt que manuels, et de la saisie humaine supprimée par des automatisations Python (scraping, traitement asynchrone, intégration d'APIs tierces).

Un produit publié sur l'App Store et Google Play, avec des utilisateurs qui travaillent à 3 h du matin. L'infrastructure devait tenir sans équipe d'exploitation derrière, sur un budget de startup.

Un VPS Ubuntu administré de bout en bout : accès SSH par clé uniquement, firewall n'exposant que le strict nécessaire, nginx en reverse proxy avec certificats SSL renouvelés automatiquement, zones DNS gérées à la main. Les services (API, base de données, reverse proxy) tournent en Docker Compose, avec des environnements dev et prod réellement séparés.

Docker Compose plutôt qu'un orchestrateur. Pour une stack de trois services sur une machine, Kubernetes aurait ajouté une couche d'exploitation que personne n'aurait maintenue. La complexité de l'infra doit rester proportionnée à l'équipe qui va vivre avec, pas au CV de celui qui la monte.

Une production stable derrière une application publiée sur les deux stores, avec supervision de la disponibilité des services et remontée d'alertes — et une stack qu'on redéploie sur une machine neuve sans archéologie.

Un organisme de formation qui suit des centaines d'apprenants, avec des données personnelles et des obligations de conformité — et aucune visibilité sur ce qui se passe réellement sur le serveur quand quelque chose casse.

Déploiement Cloud via Docker sur VPS Linux, pipelines CI/CD avec tests automatisés avant chaque mise en production, centralisation des logs applicatifs et système, et remontée d'alertes en production. Côté accès, un RBAC vérifié côté API, par ressource.

Les logs centralisés dès le premier déploiement, pas après le premier incident. Sur une plateforme qui manipule de la donnée personnelle, ne pas pouvoir reconstituer ce qui s'est passé est un problème de conformité autant qu'un problème d'exploitation — et c'est toujours moins cher à installer avant qu'après.

Plateforme livrée en Docker avec pipelines CI/CD et tests automatisés, journalisation exploitable et alertes en place — les incidents se diagnostiquent sur les logs, pas sur des captures d'écran d'utilisateurs.

Les apprenants posent leurs questions le soir, quand plus personne n'est disponible. Un chatbot générique branché sur un modèle public répond à côté du programme — et pire, invente des contenus que l'établissement n'a jamais enseignés.

Un moteur RAG côté back Node.js : les modules de formation sont découpés, indexés, et chaque réponse est ancrée dans ce corpus avec ses sources. Front Next.js, données en PostgreSQL, le tout conteneurisé et déployé sur un VPS Linux administré de bout en bout.

Tout tourne sur l'infrastructure du client, pas sur un service tiers. Des contenus pédagogiques et des questions d'apprenants, ça ne part pas chez un hébergeur qu'on ne maîtrise pas — c'est une contrainte RGPD autant qu'une contrainte d'exploitation, et elle a structuré le choix d'architecture avant le choix du modèle.

Produit déployé en démonstration chez des établissements, avec un catalogue chargeable par école et des données qui restent dans l'infra du client. C'est le projet où j'ai réalisé que la partie hébergement m'intéressait plus que la partie applicative.

Un restaurant qui prend des commandes sur trois canaux à la fois, gère ses réservations sur un cahier et découvre ses chiffres à la fin du mois. Rien n'est consolidé, donc rien n'est pilotable.

Une application métier web : prise de commande, réservations, menu, codes promo, stocks, et un tableau de bord qui agrège le chiffre d'affaires, le panier moyen et les meilleures ventes. Back Node.js, données en PostgreSQL, déploiement Docker sur un serveur Linux avec sauvegardes de la base.

L'écran principal est pensé pour le coup de feu, pas pour une réunion : les commandes en cours priment sur les graphiques, qui restent consultables plus bas. Et côté exploitation, la sauvegarde de la base a été traitée avant la première mise en service — pour ce client, perdre une journée de commandes n'est pas un incident technique, c'est une journée de caisse.

Commandes, réservations et stocks centralisés dans un seul outil, avec un suivi du CA en continu, sur une stack conteneurisée qu'on redéploie sans intervention manuelle.