CI/CD pour une petite équipe : le pipeline à avoir avant le lancement

Pour une petite équipe, le bon pipeline CI/CD est court et sans surprise. Chaque push construit l'application et lance les tests en une dizaine de minutes. Chaque fusion sur la branche principale déploie automatiquement sur une copie de préproduction. La production passe par une étape déclenchée à la main, avec un contrôle de santé et un retour arrière que vous avez déjà essayé au moins une fois. Le quota gratuit de GitHub Actions suffit en général (les 400 minutes gratuites de GitLab sont justes pour une équipe active), et cela mérite d'exister avant le lancement, pas après le premier déploiement raté.

CI et CD, simplement

L'intégration continue, selon Martin Fowler, consiste à ce que « chaque membre de l'équipe fusionne ses changements dans le code commun, avec ceux de ses collègues, au moins une fois par jour », chaque fusion étant vérifiée par un build automatique qui inclut les tests. Sa liste de pratiques reste la meilleure check-list : tout mettre sous contrôle de version, automatiser le build, faire en sorte que le build se teste lui-même, déclencher un build à chaque push sur la branche principale, réparer immédiatement un build cassé, garder un build rapide et automatiser le déploiement.

La livraison continue va un pas plus loin : chaque changement qui passe le pipeline est prêt à être déployé, et déployer devient un simple bouton ou une étape automatique, pas une soirée de manipulations. C'est ce qui rend réaliste un rythme de livraison hebdomadaire pour une petite équipe.

Le pipeline minimum, étape par étape

1. À chaque push : installer les dépendances depuis le fichier de verrouillage, lancer le linter et les tests unitaires, et construire l'artefact qui sera déployé (souvent une image de conteneur). Si une étape échoue, le build passe au rouge et le réparer passe en premier.
2. À chaque pull request : la même chose, plus un court test de bout en bout sur une copie de l'application en marche. Notre guide Playwright indique les trois tests à écrire d'abord.
3. À la fusion sur la branche principale : déployer en préproduction l'artefact exact qui a passé les tests, y lancer les migrations de base de données, et vérifier que l'application répond à son point de contrôle de santé.
4. En production : promouvoir ce même artefact, sans le reconstruire, pour que ce qui a été testé soit ce qui part. Lancer les migrations, attendre le contrôle de santé et garder la version précédente prête.
5. Retour arrière : une commande ou un bouton qui remet la version précédente. Essayez-le en préproduction avant d'en avoir besoin en production.

Fowler rappelle la règle de l'Extreme Programming d'un build de dix minutes, qu'il juge tout à fait raisonnable pour la plupart des projets. Prenez ces dix minutes comme un budget : au-delà, plus personne n'attend le résultat, et un build rouge devient facile à ignorer. Mettre les dépendances en cache et lancer en parallèle les tâches indépendantes suffit en général à rester bien en dessous sur un petit projet.

Protéger la production sans ralentir tout le monde

L'essentiel du risque d'un pipeline se trouve dans l'étape qui touche la production et dans les accès qu'elle détient. Quelques réglages suffisent :

• Un environnement protégé. Les environnements de déploiement de GitHub permettent d'exiger l'approbation de six personnes ou équipes au plus, d'ajouter un délai d'attente, de limiter les branches autorisées à déployer et de garder des secrets lisibles seulement par les tâches qui utilisent cet environnement. Vérifiez votre offre pour les dépôts privés : GitHub Pro et Team donnent les règles de branches de déploiement et les secrets d'environnement, mais les approbations obligatoires et les délais d'attente ne sont disponibles que pour les dépôts publics sur les offres Free, Pro et Team. À défaut, une tâche de déploiement en production déclenchée à la main et limitée à la branche principale donne la même étape volontaire.
• Le minimum de droits pour le jeton du pipeline. Le guide de sécurité de GitHub demande de s'assurer que le GITHUB_TOKEN ne reçoit que les permissions strictement nécessaires, avec par défaut un accès en lecture seule au contenu du dépôt, et davantage seulement pour les tâches qui en ont besoin.
• Des actions tierces épinglées. Le même guide recommande d'épingler les actions sur l'empreinte SHA complète d'un commit plutôt que sur un tag, car un tag peut être déplacé ou supprimé si un attaquant accède au dépôt de l'action.
• Aucun secret dans le dépôt. Clés et mots de passe vivent dans le coffre de secrets de l'outil de CI ou dans un gestionnaire de secrets, jamais dans un fichier versionné.

Combien ça coûte

Pour la plupart des petits produits, presque rien. GitHub Actions est gratuit pour les dépôts publics et les runners auto-hébergés ; pour les dépôts privés, GitHub Free inclut 2 000 minutes par mois et GitHub Team 3 000, avec 500 Mo et 2 Go de stockage d'artefacts. Sur GitLab.com, l'offre gratuite donne 400 minutes de calcul par mois, davantage sur les offres payantes.

Un exemple chiffré, hypothèses comprises : un pipeline de 6 minutes, lancé 10 fois par jour ouvré, sur 22 jours ouvrés, consomme 1 320 minutes par mois. Cela tient dans les 2 000 minutes de GitHub Free. La même équipe sur l'offre gratuite de GitLab épuiserait son quota en une semaine environ, et devrait ajouter un runner auto-hébergé ou passer à une offre payante. Le décompte réel dépend du type de runner et de ce qui tourne en parallèle : regardez la page d'utilisation après le premier mois.

Le mesurer avec les indicateurs DORA

Le programme de recherche DORA suit la livraison logicielle avec cinq indicateurs, répartis entre débit et instabilité :

• Délai de mise en production : le temps entre un commit et ce changement en production.
• Fréquence de déploiement : le nombre de déploiements sur une période.
• Temps de rétablissement après un déploiement raté : le temps pour se remettre d'un déploiement qui exige une intervention immédiate.
• Taux d'échec des changements : la part des déploiements qui exigent une intervention immédiate.
• Taux de déploiements correctifs : la part des déploiements non prévus, provoqués par un incident en production.

Pas besoin de tableau de bord pour commencer. Une note partagée avec la date de chaque déploiement en production, et s'il a demandé une correction, donne la fréquence de déploiement et le taux d'échec en deux minutes par semaine. Si le taux d'échec monte, il manque un test au pipeline ; si le délai s'allonge, c'est que le build ou la relecture prend trop de temps.

Les erreurs qui rendent un pipeline inutile

• Ignorer les tests instables. Un test qui échoue une fois sur dix apprend à tout le monde à relancer au lieu de lire. Réparez-le ou supprimez-le dans la semaine.
• Reconstruire pour la production. Un nouveau build au moment du déploiement n'est pas l'artefact que vous avez testé.
• Des étapes manuelles au milieu. Une migration ou un vidage de cache qu'il faut penser à faire sera l'étape oubliée.
• Aucune répétition du retour arrière. Votre premier retour arrière ne doit pas se faire en pleine panne.
• Un pipeline sans responsable. Comme tout code, il demande des mises à jour ; laissé de côté, il devient de la dette technique.

Questions fréquentes

GitHub Actions ou GitLab CI ?

Prenez celui qui se trouve là où vit déjà votre code. Les deux font tourner le pipeline décrit ici. Les différences pratiques pour une petite équipe sont les minutes incluses (2 000 par mois sur GitHub Free pour les dépôts privés, 400 sur l'offre gratuite de GitLab.com, soit environ sept jours ouvrés à une heure par jour) et les fonctions que chaque offre donne aux projets privés.

Combien de temps doit durer un pipeline CI ?

Visez une dizaine de minutes à chaque push, la règle que cite Martin Fowler. Les suites plus lentes, comme les longs tests de bout en bout, peuvent tourner à la fusion sur la branche principale ou la nuit plutôt qu'à chaque push.

Faut-il un environnement de préproduction ?

Pour la plupart des produits, oui. C'est là que les migrations, la configuration et l'étape de déploiement elle-même sont testées avant d'atteindre les utilisateurs. Il peut être petit et partager des services avec le développement, mais il doit être déployé par le même pipeline que la production.

Peut-on déployer en production automatiquement sans risque ?

Oui, une fois que vos tests sont fiables et que le retour arrière tient en une étape. Une approche courante consiste à commencer par un déploiement en production déclenché à la main, ou des approbations obligatoires si votre offre les propose, puis à l'automatiser quand le taux d'échec reste bas.

Sources

1. Continuous Integration, Martin Fowler, janvier 2024
2. DORA's software delivery metrics, DORA, janvier 2026
3. GitHub Actions billing, GitHub Docs, 2026
4. Managing environments for deployment, GitHub Docs, 2026
5. Secure use reference, GitHub Docs, 2026
6. Compute minutes, GitLab Docs, 2026
7. Deployments and environments, GitHub Docs, 2026