CI/CD pour startup : par où commencer sans ingénieur DevOps ?

Mettre en place un pipeline CI/CD quand on est CTO solo ou fondateur technique, ça fait peur. Entre les tutoriels qui supposent une infra déjà en place, les configs YAML incompréhensibles et les dizaines d'outils qui se concurrencent, on comprend vite pourquoi la plupart des startups françaises déploient encore à la main.

Pourtant, dans ma pratique d'accompagnement de startups en France — de Paris à Bordeaux en passant par Montpellier — la mise en place d'un pipeline minimal prend rarement plus d'une journée. Et le gain en sérénité est immédiat.

Cet article est un guide pratique. Pas de théorie inutile : des étapes concrètes, du code qui fonctionne, et les erreurs à éviter.

Pourquoi le CI/CD fait peur (et à tort)

CI/CD signifie Continuous Integration / Continuous Delivery. Derrière ces termes, l'idée est simple : chaque fois que vous poussez du code, il est automatiquement testé puis déployé. C'est tout.

Sans CI/CD, le déploiement est manuel. Vous vous connectez au serveur, vous tirez le code, vous redémarrez le service, vous croisez les doigts. Ce process prend du temps, génère des erreurs, et décourage les déploiements fréquents — ce qui crée des releases massives et risquées.

Les 3 briques minimales

Pas besoin de Kubernetes pour commencer. Voici les 3 outils qui couvrent 90 % des besoins d'une startup early-stage.

Brique 1 : GitHub Actions

GitHub Actions est le moteur qui déclenche votre pipeline. À chaque push sur main, il lance une séquence d'étapes : tests, build, déploiement. Gratuit jusqu'à 2 000 minutes/mois, il s'intègre nativement avec votre dépôt — pas de compte supplémentaire.

Brique 2 : Docker

Docker empaquette votre application avec toutes ses dépendances dans une image portable. L'image tourne de la même façon sur votre machine, en CI, et en production. Terminé les *"ça marchait chez moi"*.

Brique 3 : Un hébergeur compatible

Pour commencer, un VPS simple suffit : DigitalOcean, OVHcloud, Scaleway (solution française) ou Hetzner. Comptez 6 à 20 €/mois. Si vous êtes déjà sur AWS, ECS ou App Runner s'intègrent parfaitement.

Exemple concret : un pipeline en 50 lignes

Voici un pipeline réel que j'utilise pour des startups. Volontairement minimal et fonctionnel.

Le Dockerfile (Next.js, multi-stage)

# Étape 1 : dépendances
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

# Étape 2 : build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Étape 3 : image de production (minimale)
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
EXPOSE 3000
CMD ["node", "server.js"]

Le pipeline GitHub Actions

# .github/workflows/deploy.yml
name: CI/CD

on:
  push:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  test:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  deploy:
    name: Deploy
    needs: test          # deploy seulement si les tests passent
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Login to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

      - name: Deploy on VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            docker pull ghcr.io/${{ github.repository }}:latest
            docker stop app 2>/dev/null || true
            docker rm   app 2>/dev/null || true
            docker run -d \
              --name app \
              --restart unless-stopped \
              -p 3000:3000 \
              --env-file /home/deploy/.env \
              ghcr.io/${{ github.repository }}:latest
            sleep 5
            curl -sf http://localhost:3000/api/health

Ce pipeline fait 3 choses en séquence :

1. 1.Lance les tests — si ça échoue, tout s'arrête ici
2. 2.Build l'image Docker et la pousse sur GitHub Container Registry (gratuit)
3. 3.Se connecte en SSH au VPS, tire la nouvelle image et redémarre le conteneur

Les secrets (VPS_HOST, VPS_USER, VPS_SSH_KEY) se configurent dans Settings → Secrets and variables → Actions de votre dépôt GitHub. Le GITHUB_TOKEN est injecté automatiquement.

Les erreurs classiques à éviter

1. Déployer en production sans staging

Le pipeline ci-dessus déploie directement en production. C'est acceptable pour un MVP, mais dès que vous avez des utilisateurs réels, ajoutez un environnement de staging :

• ▸Branch main → déploiement automatique sur staging
• ▸Tag v1.2.3 → déploiement manuel (ou automatique) en production

2. Ne pas avoir de healthcheck

Un pipeline qui déploie sans vérifier que l'application répond, c'est inutile. Ajoutez un endpoint GET /api/health dans votre app, et vérifiez-le après chaque déploiement (déjà inclus dans le script ci-dessus via curl -sf ...).

3. Mettre des secrets dans le code

Ne committez jamais de clés API, mots de passe ou tokens. Utilisez les secrets GitHub pour le CI, et un fichier .env sur le serveur pour le runtime. Pour des besoins plus avancés : AWS Secrets Manager, Doppler ou HashiCorp Vault.

4. Ignorer les logs après le déploiement

Ajoutez au minimum Sentry (gratuit jusqu'à 5 000 events/mois) pour capturer les erreurs de production. Sans visibilité post-déploiement, vous découvrirez les bugs quand vos utilisateurs se plaindront — pas avant.

Quand faire appel à un freelance DevOps ?

Ce pipeline minimal couvre les besoins d'un MVP. Mais certaines situations justifient l'intervention d'un freelance DevOps :

• ▸Votre trafic grandit et le VPS ne suffit plus — migration Kubernetes ou ECS avec auto-scaling
• ▸Plusieurs environnements (dev, staging, prod) et la gestion devient chronophage
• ▸Exigences de conformité — ISO 27001, SOC 2, RGPD strict
• ▸Votre équipe perd du temps sur les déploiements au lieu de builder le produit

J'accompagne des startups basées à Paris, Lyon, Montpellier et en remote dans toute la France. Une session de diagnostic de 30 minutes — gratuite — suffit souvent pour identifier les points de blocage.

Conclusion

Le CI/CD n'est pas l'apanage des grandes équipes. Avec GitHub Actions, Docker et un VPS à 10 €/mois, vous pouvez avoir un pipeline fonctionnel en quelques heures. Commencez simple — tests, build, deploy — et ajoutez la complexité au fur et à mesure que votre produit grandit.

Et si votre situation est plus complexe ou que vous voulez aller plus vite : parlons-en.

Voir aussi : Combien coûte un freelance DevOps en France en 2025 ?