Quand deux personnes font tout tourner : un pipeline simple qui fonctionne vraiment

Vous faites partie d'une équipe de deux personnes qui construit un produit numérique. Peut-être une application web de gestion de stocks, ou un service API pour des partenaires. L'équipe est petite, le budget serré, et l'objectif est d'avoir quelque chose d'utilisable en semaines, pas en mois. À ce stade, la première question n'est pas à propos des pipelines ou du CI/CD. C'est : "Quand les gens commenceront à utiliser cette appli, comment leur envoyer une nouvelle version sans me connecter au serveur à chaque fois ?"

Dans une petite startup, les processus manuels semblent naturels. Vous copiez un fichier en SCP sur le serveur, vous vous connectez en SSH pour redémarrer le service, ou vous copiez-collez une requête SQL. Ça marche pour les premières livraisons. Mais après trois ou quatre fois, les fissures apparaissent. Vous oubliez une étape. Vous copiez le mauvais fichier. Vous sautez une migration. Et si vous avez plus d'un environnement — par exemple, un staging pour les tests et une production pour les vrais utilisateurs — vous devez vous souvenir de la séquence exacte pour chacun, en espérant que rien ne passe à travers.

C'est là qu'un pipeline simple entre en jeu. Pas comme un projet grandiose, mais comme un outil qui exécute les mêmes étapes à chaque modification de votre code. Vous commencez avec un fichier de configuration dans votre dépôt qui définit trois étapes : build, test et déploiement. Le build transforme votre code en un artefact exécutable. Le test exécute des vérifications automatisées — par exemple, si une nouvelle fonctionnalité casse une ancienne. Le déploiement envoie l'artefact sur le serveur cible.

À quoi ressemble un pipeline simple

Pour une petite startup, l'outil n'a pas besoin d'être compliqué. GitHub Actions, GitLab CI, ou le CI intégré de votre fournisseur cloud conviennent parfaitement. Ce qui compte, c'est que le pipeline s'exécute automatiquement lorsque vous poussez sur une branche spécifique. Par exemple, pousser sur main déclenche le build, le test et le déploiement en staging. Si tout passe, vous déployez en production d'un clic ou d'une commande.

Voici un exemple concret. Imaginez une application web Node.js hébergée sur un petit VPS. Votre fichier de pipeline pourrait ressembler à ceci :

Voici un aperçu visuel du pipeline :

Voici à quoi ressemble la configuration du pipeline en pratique :

name: Simple Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build
      - run: |
          rsync -avz --delete dist/ user@staging-server:/var/www/app/
          ssh user@staging-server 'systemctl restart myapp'

• Sur push vers main : installer les dépendances, exécuter les tests, builder l'appli, copier l'artefact sur le serveur de staging, redémarrer le service.
• Sur déclenchement manuel ou tag : répéter les mêmes étapes mais déployer en production.

C'est tout. Pas de Kubernetes, pas d'orchestration de conteneurs, pas de portes d'approbation multi-niveaux. Juste trois étapes qui s'exécutent de manière cohérente à chaque fois.

L'ownership total signifie que vous assumez la douleur

L'ownership total signifie que vous et votre coéquipier avez l'entière responsabilité de ce pipeline. Pas d'équipe DevOps séparée. Pas de long processus d'approbation. Vous écrivez le pipeline, vous l'exécutez, et vous le réparez quand il casse. Cela semble être beaucoup de pression, mais c'est en fait un avantage. Vous savez exactement comment votre application est livrée. Vous savez ce qui peut mal tourner. Et vous savez comment le réparer parce que vous l'avez construit vous-même.

Quand quelque chose échoue — et ça échouera — vous n'attendez pas qu'une autre équipe réponde. Vous regardez les logs, identifiez l'étape qui a cassé, et la réparez. Cette expérience pratique est inestimable. Elle vous enseigne les fondamentaux de la livraison d'une manière qu'aucun livre ou cours ne peut reproduire.

Une observabilité basique sans l'obsession des tableaux de bord

Vous devez savoir si votre pipeline a réussi ou échoué, et si c'est un échec, à quelle étape. La plupart des outils de pipeline fournissent déjà des logs et des notifications. C'est suffisant pour l'instant. Vous n'avez pas besoin d'une stack d'observabilité complète avec des tableaux de bord, des alertes et du tracing distribué.

Ajoutez une ou deux métriques simples à votre application elle-même. Suivez le nombre de requêtes entrantes, le taux d'erreur et le temps de réponse moyen. Ces trois chiffres vous indiquent si une nouvelle version fonctionne normalement après le déploiement. Si le taux d'erreur grimpe ou que le temps de réponse augmente, vous savez que quelque chose ne va pas. Vous pouvez consulter les logs du pipeline pour voir ce qui a changé, et faire un rollback si nécessaire.

La chose que les petites équipes oublient

La documentation. Pas celle, longue et détaillée, que personne ne lit. Juste une courte note sur le fonctionnement du pipeline, que faire en cas d'échec, et comment revenir à une version précédente. Écrivez-la tant que c'est encore frais dans votre esprit. Cette note devient cruciale quand vous êtes injoignable — dans un avion, malade, ou en vacances — et que quelque chose tourne mal. Elle aide aussi quand votre équipe grandit et qu'une nouvelle personne doit comprendre le processus de livraison.

Un simple fichier Markdown dans votre dépôt fait l'affaire. Incluez :

• La branche qui déclenche le déploiement vers chaque environnement
• Les commandes pour effectuer un rollback manuel
• Où trouver les logs quand une étape échoue
• Qui contacter si vous êtes tous les deux indisponibles

Quand ce modèle cesse de fonctionner

Ce pipeline simple ne conviendra pas éternellement. À mesure que votre équipe grandit, que votre application se complexifie et que votre base d'utilisateurs s'élargit, vous aurez besoin de plus de structure. Vous pourriez avoir besoin d'exécutions de tests en parallèle, d'étapes de migration de base de données, de portes d'approbation pour la conformité, ou de stratégies de déploiement comme le blue-green ou les canary releases. Vous pourriez devoir séparer le build, le test et le déploiement en différentes étapes avec des responsabilités distinctes.

Mais pour une petite startup qui doit aller vite, commencer avec un pipeline simple et un ownership total est la bonne décision. Vous apprenez les bases de la livraison sans être submergé par des outils complexes. Vous construisez une fondation qui peut évoluer avec vos besoins. Et vous évitez le piège du sur-engineering avant d'avoir un produit que les gens utilisent réellement.

Checklist pratique pour votre premier pipeline

• Définissez trois étapes : build, test, déploiement
• Choisissez un outil CI (GitHub Actions, GitLab CI, ou intégré au fournisseur cloud)
• Configurez le pipeline pour se déclencher sur push vers main
• Ajoutez une étape de déploiement manuel pour la production
• Loggez le nombre de requêtes, le taux d'erreur et le temps de réponse dans votre appli
• Rédigez un document d'une page sur la procédure de rollback
• Testez le pipeline en le cassant volontairement et en le réparant

L'essentiel à retenir

Un pipeline simple construit par les personnes qui possèdent le code est meilleur qu'un système complexe géré par quelqu'un d'autre. Commencez petit, assumez le processus, et laissez la fondation grandir avec votre produit. Vous en apprendrez plus sur la livraison dans votre premier mois d'exploitation d'un pipeline qu'en une année de lecture à ce sujet.