Défis

DevOps Minimum Viable : Ce que Toute Startup Doit Avoir Avant d'Aller en Production

Par Marc Molas·20 février 2024·10 min de lecture

Vous n'avez pas besoin de Kubernetes. Vous n'avez probablement pas besoin de microservices. Vous n'avez certainement pas besoin d'une equipe SRE dediee a ce stade. Mais vous avez besoin d'une base DevOps. Sans elle, chaque deployment est une roulette russe et chaque incident en production devient un incendie a eteindre a 3 heures du matin.

J'ai vu des startups avec un produit solide et une vraie traction perdre des semaines faute d'un pipeline de CI/CD correct. Et j'en ai vu d'autres passer des mois a monter une infrastructure de grande entreprise alors qu'elles avaient 3 ingenieurs et 0 client payant. Les deux extremes sont des erreurs. Ce dont vous avez besoin, c'est le DevOps Minimum Viable.

La checklist du DevOps Minimum Viable

Voici les 8 elements que toute startup doit avoir avant de mettre un produit entre les mains d'utilisateurs reels. C'est non negotiable. S'il vous en manque un, vous accumulez de la dette operationnelle qui va vous exploser a la figure au pire moment possible.

1. Controle de version avec strategie de branching

Ca semble evident, mais le nombre de startups qui travaillent directement sur main sans strategie de branching est surprenant.

Vous avez deux options raisonnables :

Trunk-based development. Des branches courtes (heures, pas jours), des merges frequents sur main, des feature flags pour le code non termine. Ideal pour les petites equipes qui deploient plusieurs fois par jour.
Git Flow simplifie. Des branches de feature, une branche develop, des releases depuis main. Plus structure, utile quand vous avez besoin d'environnements de staging bien definis.

Pour la plupart des startups en phase initiale, le trunk-based avec feature flags est le bon choix. Moins d'overhead, moins de conflits de merge, des cycles plus rapides.

2. Pipeline de CI : lint, test, build sur chaque PR

Chaque pull request doit passer par un pipeline automatise avant que quiconque ne la review. Au minimum :

Linting. ESLint, Pylint, celui qui correspond a votre stack. Ce n'est pas de l'esthetique — c'est de la prevention de bugs.
Tests automatises. Des tests unitaires au minimum. Des tests d'integration si vous en avez. Le pipeline echoue si un test echoue. Sans exception.
Build. Si votre application compile, elle compile en CI. Une PR qui casse le build ne se merge pas. Point final.

Ca vous donne un filet de securite basique. Pas parfait, mais infiniment mieux que "ca marche sur ma machine".

3. Pipeline de CD : deployment automatise vers staging et production

Si vous faites des deployments manuels — SSH sur le serveur, git pull, npm run build, et priez — vous vivez dangereusement. Un pipeline de CD basique fait ceci :

Merge sur develop = deployment automatique vers staging.
Merge sur main (ou tag de release) = deployment automatique vers production.
Rollback accessible. Un bouton ou une commande pour revenir a la version precedente en moins de 5 minutes.

Le deployment doit etre un evenement ennuyeux. Si a chaque deployment en production toute l'equipe retient son souffle, vous avez un probleme de processus, pas de produit.

4. Monitoring de base : uptime, erreurs, temps de reponse

Vous n'avez pas besoin de dashboards avec 47 metriques. Vous avez besoin de savoir trois choses en permanence :

Votre application est-elle en ligne ? Monitoring d'uptime. Si elle tombe, vous le savez en quelques minutes, pas quand un utilisateur vous tweete.
Y a-t-il des erreurs ? Taux d'erreurs 5xx, exceptions non capturees. Des outils comme Sentry sont parfaits pour ca.
Est-elle rapide ? Temps de reponse de vos endpoints critiques. Si votre API passe de 200ms a 2 secondes, vous voulez le savoir avant que vos utilisateurs ne le remarquent.

Les options : Datadog si vous avez du budget, New Relic avec son tier gratuit, ou meme CloudWatch si vous etes sur AWS. L'important n'est pas l'outil — c'est que le monitoring existe et que les alertes arrivent la ou quelqu'un les voit.

5. Logging centralise et cherchable

console.log en production, ce n'est pas du logging. Des logs disperses sur 3 serveurs differents ne sont pas utiles quand vous avez un incident a 23 heures.

Vous avez besoin de logs centralises dans un endroit ou vous pouvez chercher. Les options :

ELK Stack (Elasticsearch, Logstash, Kibana). Puissant, mais necessite de la maintenance si vous l'hebergez vous-meme.
CloudWatch Logs si vous etes sur AWS. Facile a configurer, cherchable, integre.
Papertrail ou Logtail. Simples, pas chers, suffisants pour des startups en phase initiale.

La regle d'or : si un utilisateur vous signale une erreur, vous devriez pouvoir trouver le log correspondant en moins de 5 minutes.

6. Backup et recovery : sauvegardes de base de donnees avec restore teste

Avoir des sauvegardes ne compte pas si vous n'avez jamais teste leur restauration. Voici le minimum :

Sauvegardes automatiques quotidiennes de votre base de donnees. Si vous utilisez RDS ou Cloud SQL, c'est inclus de base.
Retention minimale de 7 jours. Idealement 30.
Restore teste. Au moins une fois par trimestre, restaurez une sauvegarde dans un environnement de test et verifiez que les donnees sont la. Si vous n'avez jamais teste votre restore, vous n'avez pas de sauvegardes — vous avez une illusion de securite.

7. Parite d'environnements : staging qui reflète production

Votre environnement de staging doit ressembler le plus possible a la production. Meme version de base de donnees, meme configuration serveur, memes variables d'environnement (avec des valeurs differentes, evidemment).

Si quelque chose fonctionne en staging mais plante en production, votre staging ne sert a rien. Les problemes les plus courants :

Versions differentes de dependances. Staging avec Node 18, production avec Node 16. Utilisez Docker ou au minimum un .nvmrc pour fixer les versions.
Base de donnees differente. Staging avec SQLite, production avec PostgreSQL. Non. Utilisez la meme base de donnees dans les deux environnements.
Donnees de test irrealistes. Votre staging a 10 enregistrements. Votre production en a 100 000. Les problemes de performance n'apparaissent pas avec 10 enregistrements.

8. Gestion des secrets : zero identifiant en dur dans le code

S'il y a une cle d'API, un mot de passe de base de donnees ou un token d'acces dans votre code source, vous avez un probleme de securite dont l'explosion n'est qu'une question de temps.

Le minimum :

Variables d'environnement pour tous les secrets. Jamais dans le code, jamais dans le repository.
.env dans .gitignore. Toujours. Sans exception.
Rotation des secrets. Si un secret fuite, vous devriez pouvoir le faire tourner en minutes, pas en heures.

Des outils comme AWS Secrets Manager, HashiCorp Vault ou meme le gestionnaire de secrets de GitHub Actions sont suffisants pour commencer.

Ce dont vous n'avez PAS besoin (pour l'instant)

Aussi important que ce dont vous avez besoin est ce dont vous n'avez pas besoin. Voici les pieges d'over-engineering les plus courants :

Kubernetes. A moins d'avoir une equipe de plus de 10 ingenieurs et de vrais besoins d'orchestration de conteneurs, Kubernetes est de la complexite qui ne vous apporte rien. Un simple ECS, Railway ou Fly.io est plus que suffisant.
Service mesh. Istio, Linkerd... des solutions a des problemes que vous n'avez pas avec 3 microservices (qui devraient probablement etre un monolithe).
Dashboards de metriques personnalises. Grafana avec 15 panneaux ne vous rend pas plus rapide. Les alertes basiques, si.
Multi-region failover. Si votre startup a 500 utilisateurs, vous n'avez pas besoin de redondance geographique. Vous avez besoin d'un bon uptime dans une seule region.

La regle : si vous ne pouvez pas expliquer en une phrase pourquoi vous avez besoin d'un outil ou d'une pratique, vous n'en avez probablement pas besoin.

Quand passer au niveau superieur

Le DevOps Minimum Viable n'est pas la destination — c'est le point de depart. Vous devriez commencer a investir dans une infrastructure plus robuste quand :

Vous avez des clients payants. Il y a desormais des SLAs implicites. Les temps d'arret coutent de l'argent reel.
Votre equipe depasse 5 ingenieurs. Plus de monde = plus besoin d'automatisation, de meilleurs environnements de developpement, des pipelines plus sophistiques.
Vous avez des exigences reglementaires. Si vous gerez des donnees de sante, financieres ou personnelles avec des exigences de conformite, votre infrastructure doit le refleter.

Outils par budget

Budget zero (free tier) : GitHub Actions pour le CI/CD, Vercel ou Railway pour l'hebergement, Sentry en version gratuite pour les erreurs, UptimeRobot pour le monitoring d'uptime. Ca vous couvre remarquablement bien jusqu'a vos premiers milliers d'utilisateurs.

Budget moyen (200-500 EUR/mois) : AWS avec Terraform pour l'infrastructure as code, GitHub Actions ou CircleCI pour le CI/CD, Datadog ou New Relic pour le monitoring, ELK manage ou CloudWatch pour les logs.

Budget enterprise (1 000+ EUR/mois) : Services manages d'AWS ou GCP, ECS ou EKS pour les conteneurs, Datadog en suite complete, PagerDuty pour la gestion d'incidents, Terraform Cloud pour la gestion d'etat.

Le profil dont vous avez besoin

Monter tout cela ne necessite pas une equipe DevOps. Ca necessite un ingenieur senior qui a deja fait ca. Quelqu'un qui sait faire la difference entre le necessaire et l'aspirationnel, qui peut configurer un pipeline de CI/CD en une journee — pas en un sprint — et qui comprend que l'infrastructure doit servir le produit, pas l'inverse.

Chez Conectia, nous avons des ingenieurs senior en DevOps et infrastructure qui ont monte exactement ce type de fondation pour des startups. Pas d'over-engineering, pas de solutions enterprise pour des problemes de startup. Le bon stack pour votre phase actuelle, configure pour scaler quand vous en aurez besoin.

Chaque ingenieur passe par notre processus de validation technique mene par des CTOs. Nous evaluons l'experience reelle en production, pas les certifications. Et ils sont disponibles en 72 heures.

Le DevOps Minimum Viable n'est pas glamour. Vous n'allez pas ecrire un post LinkedIn pour vanter votre pipeline de CI. Mais c'est la difference entre une startup qui peut iterer avec confiance et une qui a peur de deployer un vendredi.

Vous avez besoin d'un ingenieur DevOps senior qui pose les bases sans over-engineering ? Parlez a un CTO — une infrastructure adaptee a votre phase, prete en quelques jours.