La question qu'on me pose le plus souvent quand je parle de notre stack : « mais comment tu fais pour maintenir 15 produits en parallèle seul ? ». La réponse courte : on ne maintient pas 15 stacks — on maintient une infrastructure commune que 15 produits partagent. Et cette infrastructure est largement automatisée.
Voici comment fonctionne le DevOps de Domaine du Net de l'intérieur.
🔁 Le pipeline comme unité de base
Chaque projet a un fichier .gitlab-ci.yml qui définit les étapes de validation et de déploiement. Ce fichier suit toujours la même structure : lint, typecheck, tests, build, déploiement. Les étapes sont exécutées dans des runners Docker, sur notre infrastructure Scaleway.
Ce qui nous a permis de standardiser : la configuration partagée. On maintient un package @domainedunet/config qui exporte la configuration ESLint, Prettier et TypeScript commune à tous les projets. Chaque repo l'installe et en hérite — quand on met à jour une règle de lint, elle se propage sur l'ensemble des projets via un bump de dépendance, sans modifier 15 fichiers de config manuellement.
Même logique pour les hooks Git pré-push : chaque repo installe les hooks via le package config, qui lance lint + typecheck avant toute tentative de push. Un pipeline ne peut pas recevoir du code qui casse la compilation — le développeur (ou l'agent IA) est bloqué localement avant.
🛡 Les garde-fous qu'on ne négocie pas
Coverage ≥ 90%. Depuis quelques semaines, Vitest est configuré avec des seuils de couverture obligatoires sur tous les repos : statements, branches, functions, lines à 90% minimum. Un test qui passe en dessous du seuil fait échouer le pipeline. Ce n'est pas une contrainte bureaucratique — c'est ce qui nous permet de faire merger du code généré par des agents IA avec une certaine confiance.
Preview avant merge. Chaque branche ouvre un environnement de preview sur Netlify (pour les frontends) ou sur un sous-domaine dédié (pour les APIs). Les merge requests ne sont pas validées sur la base du code seul, mais sur la base d'un comportement observé dans un environnement réel.
Branches protégées. main ne reçoit jamais de push direct — ni de moi, ni des agents. Tout passe par une branche, une merge request, une CI verte. C'est la règle que les agents suivent systématiquement, et qui nous a sauvés plusieurs fois quand un agent avait produit du code correct syntaxiquement mais incorrect fonctionnellement.
🤖 Le rôle des agents dans le pipeline
Les agents IA (Claude Code, Liz notre runner VPS) interviennent dans le workflow de plusieurs façons :
- Ils créent les branches et les MR après avoir implémenté une feature ou un fix.
- Ils corrigent les erreurs de CI automatiquement : si un pipeline échoue sur une erreur de lint ou de type, l'agent relit le log, corrige, repousse.
- Ils monitorent les pipelines en cours et signalent les échecs dans notre channel de chat interne.
- Ils déploient sur validation : quand une MR est approuvée et que le pipeline est vert, le merge peut être déclenché par l'agent.
Ce qui est essentiel : les agents ne bypassent jamais les vérifications. Ils ne font pas de git push --force, ne passent pas --no-verify, n'approuvent pas leurs propres MRs. Ce sont les mêmes règles qu'un développeur humain, appliquées de façon encore plus stricte parce que personne n'est là pour intervenir manuellement à 3h du matin.
🏗 L'infrastructure sous-jacente
Tout tourne sur Scaleway en France : VPS pour les backends Docker, Object Storage pour les assets, une instance dédiée pour les runners CI. On a commencé sur Heroku — la migration est en cours (voir notre article sur le sujet à venir). Le choix Scaleway est à la fois économique et politique : données hébergées en France, facturation prévisible, pas de dépendance à un acteur américain pour des services critiques.
Le reverse proxy est Caddy — auto-HTTPS, configuration déclarative simple, reload sans downtime. Docker Compose pour les services sur chaque machine. Pas de Kubernetes pour l'instant : le gain en résilience ne justifie pas la complexité pour notre taille actuelle.
Et si vous avez le même problème ?
Si vous pilotez plusieurs produits ou projets avec une équipe technique réduite, et que vos déploiements sont encore manuels (FTP, SSH à la main, scripts bash maison), DevOps expose les pipelines, outils de monitoring et patterns qu'on a mis en place — adaptables à vos projets.
À très vite, Julien