DevOps & Stabilisation · Scaleup SaaS · Seul Ops
Reprise après sinistreet transformation DevOps.
La crise
Le client est une scaleup SaaS en forte croissance, hébergée sur un serveur bare metal OVH, avec une seule personne Ops — moi. La plateforme faisait face à une double crise.
Niveau infrastructure :
- Un développeur avait supprimé la base de données de production. Le dump de sauvegarde quotidien était stocké sur le même serveur. Toute la donnée de la plateforme a été perdue — une matinée entière d'activité utilisateurs.
- Un seul serveur bare metal hébergeait les 3 environnements et les bases de données, sans isolation. Une panne de 12 heures sur la non-prod n'avait par chance pas touché la production — cette fois.
- Aucune documentation. L'infrastructure avait été montée par un prestataire précédent, parti sans laisser de trace.
Niveau équipe :
- Le lead dev se connectait manuellement au serveur, faisait un
git pullet relançait avecnode. Chaque mise en production était un risque. - Merge conflicts chroniques — aucun workflow Git structuré.
- Fréquence de déploiement : 1 fois toutes les 2 semaines, à la main, avec stress maximal.
- Confiance du métier envers la tech : au plus bas.
Reconstruction de l'infrastructure
J'ai choisi de repartir de zéro plutôt que de patcher l'existant — reconstruire proprement coûtait moins cher à terme que maintenir du legacy fragile.
- Passage de 1 serveur bare metal à 5 serveurs avec réplication de la production
- Stratégie de sauvegarde isolée — les backups ne sont plus jamais sur le même serveur que la donnée
- Stack monitoring complète (Grafana, Prometheus) pour détecter les anomalies avant qu'elles ne deviennent des incidents
- CDN Cloudflare pour le WAF et la gestion DNS
Migration OVH → AWS
Une fois la plateforme stabilisée sur OVH, j'ai planifié et exécuté la migration complète vers AWS :
- 800 utilisateurs migrés, 100 Go de fichiers, base de données de 10 Go
- Fenêtre de migration effective : 30 minutes un soir
- 1 incident mineur détecté une semaine après (fichiers stockés localement dans un conteneur suite à une manipulation dev) — la quasi-totalité des données récupérée
Transformation DevOps de l'équipe
Une infrastructure stable ne sert à rien sans des pratiques qui la maintiennent stable. Programme en 3 volets, adapté à une équipe très junior (2 alternants, 3 juniors, 1 lead dev) :
CI/CD systématique
Pipelines Bitbucket et GitHub Actions : les développeurs déploient sans risque de casser la production. Aucune mise en production manuelle.
Git Flow structuré
Introduction du Git Flow pour éliminer les merge conflicts chroniques et structurer la gestion des branches. Adapté aux contraintes business du client.
Formation et documentation
Accompagnement patient de l'équipe à leur niveau, sans jargon. Runbooks rédigés. L'équipe sait comment tout fonctionne — et pourquoi.
Le résultat
| Métrique | Avant | Après |
|---|---|---|
| Perte de données | Oui (DB prod supprimée, backups non isolés) | Zéro sous ma supervision |
| Fréquence de déploiement | 1 fois / 2 semaines, à la main | 5–6 fois / semaine, automatisé |
| Facteur d'amélioration | — | ×10 à ×12 |
| Sérénité de l'équipe | Stress à chaque MEP | Déploiements sereins, en confiance |
| Documentation infra | Inexistante | Complète, maintenue en interne |
| Confiance métier/tech | Au plus bas | Restaurée |
Plus important : l'équipe n'avait plus besoin de moi pour déployer. C'est ça, construire, former, partir.
Plateforme instable ? Équipe bloquée ?
Audit, stabilisation, transformation DevOps — intervention rapide possible.
Démarrer un projet →