Pilier 2 : CI/CD et monitoring pour builder solo (GitHub Actions, Sentry, uptime)

“Ça marche sur ma machine” : l’épitaphe de 1 000 projets

Vendredi soir, 22h. Vous venez de corriger un bug que 3 utilisateurs ont remonté. Le fix est simple : une condition manquante dans un handler. Vous commitez, vous poussez en prod à la main, vous fermez le laptop.

Samedi matin, 14 messages. Votre page d’accueil affiche une erreur 500. Votre fix a cassé autre chose. Vous ne le saviez pas parce que personne ne surveillait.

Je connais ce scénario. Je l’ai vécu. Plusieurs fois.

Quand vous êtes solo, il n’y a pas de collègue pour faire une code review. Pas de QA pour tester avant la mise en prod. Pas de DevOps pour configurer les alertes. C’est vous. Tout le temps. Et votre cerveau à 22h un vendredi n’est pas fiable.

Le réflexe naturel du builder solo : “Je suis seul, j’ai pas besoin de CI/CD, c’est pour les équipes.” C’est exactement l’inverse. Quand vous êtes seul, vous avez plus besoin d’automatisation. Parce qu’il n’y a personne pour rattraper vos erreurs.

Le déploiement manuel, c’est un anti-pattern. Pas parce que c’est lent, mais parce que c’est fragile. Chaque étape manuelle est une opportunité d’erreur. Et chaque erreur en prod est une erreur que vos utilisateurs paient.

Ce que Clean Architecture dit sur les frontières

Robert C. Martin a un concept qui s’applique parfaitement ici : les frontières architecturales.

Dans Clean Architecture, il explique que la frontière entre votre code et le monde extérieur mérite autant d’attention que la frontière entre vos modules internes. Le déploiement est une frontière. C’est le moment où votre code quitte votre machine et entre dans le monde réel.

La plupart des builders solo traitent le deploy comme un afterthought. Un git push suivi d’un SSH sur le serveur, un npm run build, un pm2 restart. Ou pire : un copier-coller FTP.

Le problème n’est pas la technique. C’est l’absence de contrat. Quand vous déployez manuellement, il n’y a aucune garantie que ce qui arrive en prod est testé, linté, fonctionnel. Vous dépendez de votre mémoire pour exécuter chaque étape dans le bon ordre.

Clean Architecture nous dit : formalisez vos frontières. Rendez-les explicites. Automatisez-les.

C’est exactement ce qu’un pipeline CI/CD fait. Il transforme une frontière implicite (“je pense avoir bien fait”) en une frontière explicite (“le pipeline a validé chaque étape avant de déployer”).

Le pipeline minimum viable

Je ne vais pas vous vendre un setup Kubernetes avec Terraform et ArgoCD. Vous êtes solo. Vous avez besoin du minimum qui vous protège. Voici les 4 étapes, dans l’ordre.

Étape 1 : Lint + format auto

Temps de setup : 15 minutes. Coût : 0€.

Premier filet de sécurité. Avant même de parler de tests, assurez-vous que votre code est cohérent.

Pour JavaScript/TypeScript : ESLint + Prettier. Pour Python : Ruff (qui remplace flake8, isort, et black en un seul outil). Pour Go : gofmt est déjà intégré.

Pourquoi c’est critique quand vous utilisez l’IA pour coder : l’IA génère du code avec un formatage inconsistant. Un fichier utilise des single quotes, le suivant des double quotes. Les imports sont dans un ordre aléatoire. Les indentations changent.

Le lint + format auto règle ça en une commande. Vous configurez une fois, et chaque fichier respecte les mêmes règles. Plus de bruit dans les diffs. Plus de discussions mentales “est-ce que je devrais mettre un point-virgule ici.”

Ajoutez un hook pre-commit avec Husky (JS) ou pre-commit (Python). Chaque commit est automatiquement formaté. Vous n’y pensez plus jamais.

Étape 2 : Tests auto à chaque push

Temps de setup : 30 minutes. Coût : 0€ (GitHub Actions offre 2 000 minutes/mois sur les repos publics, 500 sur les privés).

Créez un fichier .github/workflows/ci.yml. Le contenu est simple :

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test

C’est tout. À chaque push, GitHub exécute vos tests. Si un test échoue, vous le savez immédiatement. Pas le lendemain quand un utilisateur vous envoie un message.

L’article précédent sur les tests et TDD explique en détail quels tests écrire et comment. Si vous n’avez pas encore de tests, commencez par là. Le pipeline CI n’a de valeur que si vous avez des tests à exécuter.

Le point crucial : pas d’exceptions. Chaque push déclenche le pipeline. Pas de “c’est juste un fix rapide, pas besoin de tester.” C’est exactement ce fix rapide qui casse tout.

Étape 3 : Deploy auto sur merge to main

Temps de setup : 20 minutes. Coût : 0€ (les tiers gratuits de Vercel, Netlify et Railway sont largement suffisants pour commencer).

Le principe est simple : merge to main = deploy en production. Automatiquement. Sans intervention manuelle.

Avec Vercel ou Netlify, c’est natif. Vous connectez votre repo GitHub, et chaque push sur main déclenche un build et un déploiement. Zéro configuration YAML supplémentaire.

Pour une app backend, Railway ou Render offrent la même chose. Connectez le repo, définissez la commande de build et de start, c’est fini.

Le workflow devient :

1. Vous développez sur une branche
2. Vous ouvrez une PR (même si vous êtes seul, ça force une pause de réflexion)
3. Le CI passe (lint + tests)
4. Vous mergez
5. Le deploy se fait tout seul

Vous ne touchez jamais à la prod directement. Vous ne faites jamais de ssh sur un serveur pour git pull. Le déploiement est un processus reproductible, pas un acte de foi.

Étape 4 : Rollback en un clic

Temps de setup : 5 minutes. Coût : 0€.

Quand les choses cassent (et elles casseront), vous devez pouvoir revenir en arrière en secondes. Pas en heures.

Vercel et Netlify offrent le rollback instantané. Chaque déploiement est une version immuable. Un clic dans le dashboard, et vous êtes revenu au déploiement précédent. Le temps de downtime : moins de 30 secondes.

Pour une app sur Railway ou Render, le rollback est aussi disponible dans le dashboard. En dernier recours, un git revert sur votre commit problématique + push sur main déclenche un redéploiement automatique.

La clé : testez votre rollback avant d’en avoir besoin. Faites-le une fois, en conditions normales, pour savoir exactement quels boutons cliquer quand c’est la panique.

Surveiller la prod

Déployer automatiquement, c’est bien. Savoir ce qui se passe après, c’est mieux. Sans monitoring, vous êtes aveugle. Votre app peut planter en silence pendant des heures.

Sentry

Setup : 10 lignes de code. Coût : 0€ (le tier gratuit offre 5 000 événements/mois).

Sentry capture chaque erreur en production, en temps réel. Stack trace complète, contexte utilisateur, fréquence de l’erreur. Vous savez exactement ce qui a cassé, où, et pour combien d’utilisateurs.

L’installation est triviale. Pour un projet Next.js :

npx @sentry/wizard@latest -i nextjs

Pour un backend Node.js, c’est quelques lignes :

import * as Sentry from "@sentry/node";
Sentry.init({ dsn: "votre-dsn-sentry" });

Ce qui change quand vous avez Sentry : vous découvrez des bugs avant que vos utilisateurs ne les signalent. Vous voyez qu’une erreur est apparue 47 fois en 2 heures, pour 12 utilisateurs différents. Vous corrigez avant que quelqu’un n’ait le temps d’écrire un email.

Sans Sentry, ces 12 utilisateurs partent silencieusement. Vous ne saurez jamais pourquoi.

Uptime monitoring

Setup : 5 minutes. Coût : 0€ (BetterStack et UptimeRobot offrent des tiers gratuits généreux).

L’uptime monitoring fait une chose simple : il visite votre site toutes les X minutes et vérifie qu’il répond. Si votre site est down, vous recevez une alerte immédiate : email, SMS, Slack, Discord.

Pourquoi c’est indispensable : votre app peut être down et vous ne le savez pas. Votre hébergeur a un incident. Votre certificat SSL a expiré. Votre base de données est pleine. Sans monitoring, vous l’apprenez quand un utilisateur tweete que votre site ne marche plus.

BetterStack (ex-Better Uptime) est mon choix. L’interface est clean, les alertes sont fiables, et le tier gratuit couvre largement un projet solo. UptimeRobot est une alternative solide et éprouvée.

Configurez un check toutes les 2 minutes sur votre URL principale. Ajoutez une page de status publique si vous avez des utilisateurs qui dépendent de votre service. Ça prend 5 minutes et ça vous évite des heures de stress.

Analytics

Setup : 15 minutes. Coût : 0€ (PostHog offre 1M d’événements/mois gratuits, Plausible a un tier gratuit pour les petits sites).

Les analytics ne sont pas des vanity metrics. Elles vous disent ce que vos utilisateurs font réellement.

PostHog est mon outil de référence. C’est bien plus qu’un Google Analytics privacy-friendly. C’est un outil de product analytics : funnels, rétention, session replay, feature flags. Tout ce qu’il faut pour comprendre comment les gens utilisent votre produit.

Plausible est une alternative si vous voulez juste du trafic web simple, léger, respectueux de la vie privée.

Ce qui compte, c’est de mesurer les actions qui ont du sens pour votre business :

• Combien d’utilisateurs terminent votre onboarding ?
• Quel pourcentage utilise la feature que vous avez passé 3 semaines à construire ?
• Où est-ce que les gens décrochent dans votre funnel ?

Si personne n’utilise une feature, arrêtez de construire dessus. Les analytics vous donnent cette clarté. Sans elles, vous construisez à l’aveugle.

Comment l’IA vous aide à mettre tout ça en place

L’ironie est savoureuse : vous utilisez l’IA pour construire les garde-fous du code généré par l’IA.

Mais c’est exactement le bon usage. Claude Code peut générer votre fichier GitHub Actions en 30 secondes. Il connaît la syntaxe YAML, les actions disponibles, les bonnes pratiques. Vous décrivez votre stack, il génère le workflow.

Même chose pour la config Sentry. “Ajoute Sentry à mon projet Next.js avec le source maps upload”, et c’est fait. Proprement.

Le monitoring BetterStack ? Claude peut vous écrire un script qui configure vos checks via l’API.

La différence entre un builder qui utilise l’IA intelligemment et un qui fait du vibe coding, c’est exactement ça. L’un utilise l’IA pour construire l’infrastructure qui le protège. L’autre utilise l’IA pour empiler du code sans filet.

J’ai détaillé cette approche dans l’article sur comment j’ai construit un co-pilote IA. Le principe est le même : l’IA est un outil, pas un remplaçant. Et les meilleurs outils sont ceux qui vous empêchent de faire des bêtises.

En résumé

Étape	Outil	Temps setup	Coût
Lint + format	ESLint+Prettier / Ruff	15 min	Gratuit
Tests auto	GitHub Actions	30 min	Gratuit
Deploy auto	Vercel / Netlify / Railway	20 min	Gratuit
Rollback	Vercel / git revert	5 min	Gratuit
Error tracking	Sentry	10 min	Gratuit (5k events/mois)
Uptime	BetterStack / UptimeRobot	5 min	Gratuit
Analytics	PostHog / Plausible	15 min	Gratuit

Total : ~2 heures de setup. 0€. Et vous dormez tranquille.

En 2 heures, vous avez un pipeline qui lint, teste, déploie, surveille, et vous alerte. C’est le minimum. Mais c’est un minimum qui change tout.

Ce pipeline est le Pilier 2 du manifeste pour shipper du code IA en confiance. Le Pilier 1 couvrait les tests et le TDD. Le prochain, le Pilier 3, abordera la sécurité et l’hébergement, parce qu’un pipeline automatisé ne sert à rien si votre serveur est ouvert aux quatre vents.

Automatisez. Surveillez. Dormez.