Aller au contenu principal

Cas d'usage réels + FAQ complète

Résumé : le CI/CD n'est pas une théorie — c'est ce qui permet à Amazon de déployer toutes les quelques secondes et à Netflix de servir 250 millions d'abonnés sans interruption. Cette dernière leçon présente cinq cas d'usage documentés, explique quand le CI/CD n'est pas adapté, répond aux 14 questions les plus fréquentes, et vous guide vers votre prochaine étape.

1. Cas d'usage 1 — Amazon et le déploiement à la seconde​

L'enseignement le plus utile : beaucoup d'équipes veulent « faire comme Amazon » en installant un meilleur outil de CI. Mais la performance d'Amazon vient d'abord de son architecture découplée et de son organisation en équipes autonomes. Un excellent pipeline sur un monolithe où quinze équipes se coordonnent ne produira jamais ces chiffres.

2. Cas d'usage 2 — Etsy, le pionnier culturel​

Pourquoi ce cas compte plus que les chiffres d'Amazon : Etsy démontre que la transformation est d'abord culturelle. Faire déployer un nouvel arrivant dès le premier jour n'est pas une prouesse technique — c'est une déclaration sur la fiabilité du système et sur la confiance accordée aux personnes.

3. Cas d'usage 3 — Netflix et le chaos assumé​

4. Cas d'usage 4 — Une banque européenne en secteur régulé​

Ce cas est plus représentatif de ce que vous rencontrerez que les GAFAM.

L'enseignement essentiel : la conformité réglementaire n'est pas un obstacle au CI/CD. Elle interdit le déploiement continu, mais la livraison continue est parfaitement compatible — et produit même une traçabilité supérieure aux processus manuels qu'elle remplace. C'est un argument très utile face à un responsable conformité réticent.

5. Cas d'usage 5 — Une startup de cinq personnes​

C'est le cas d'usage le plus utile à retenir pour la majorité des lecteurs. Un pipeline de 40 lignes de YAML, gratuit, qui tourne en 4 minutes, apporte l'essentiel du bénéfice du CI/CD. La sophistication de Netflix résout des problèmes que vous n'avez probablement pas.

6. Quand le CI/CD complet n'est PAS la priorité​

À nuancer avec honnêteté : dans presque tous ces cas, l'intégration continue reste bénéfique. Ce qui doit être relativisé, c'est le déploiement continu et l'outillage sophistiqué. Un simple « à chaque pull request, on compile et on lance les tests » apporte une valeur immédiate dans quasiment tous les contextes.

7. Les 14 questions les plus fréquentes​

1. Combien de temps pour mettre en place un CI/CD ?

Cela dépend radicalement du point de départ :

  • Pipeline de base (build + tests à chaque pull request) sur un projet moderne : une demi-journée à deux jours.
  • Livraison continue complète (déploiement automatisé jusqu'à la recette, prêt pour la production) : deux à six semaines.
  • Transformation d'un legacy sans tests automatisés : plusieurs mois, et l'essentiel du travail consiste à écrire les tests, pas à configurer l'outil.

Le vrai coût n'est presque jamais l'outillage. C'est la couverture de tests, la rétrocompatibilité des migrations et la culture d'équipe.

2. Faut-il des tests automatisés pour faire du CI/CD ?

Pour la CI : oui, c'est la définition même — la validation automatique est le cœur de la pratique. Sans tests, vous avez juste une compilation automatique, ce qui est déjà utile mais très limité.

Pour le déploiement continu : c'est absolument non négociable. La suite de tests est le seul garde-fou, puisque aucun humain ne relira le résultat.

Bon point de départ si vous partez de zéro : ajoutez des tests sur les chemins critiques (authentification, paiement, création de compte) plutôt que de viser un pourcentage de couverture global.

3. Quelle couverture de tests viser ?

Méfiez-vous de la métrique de couverture. 90 % de couverture sur du code trivial vaut moins que 60 % sur les chemins critiques.

Repères pragmatiques :

  • Moins de 40 % : le pipeline ne protège pas grand-chose.
  • 60 à 80 % : zone de confort pour la plupart des équipes.
  • Plus de 90 % : souvent le signe qu'on teste des choses inutiles, sauf sur du logiciel critique.

Meilleure question à se poser : « si je casse volontairement une fonctionnalité importante, un test échoue-t-il ? ». C'est plus révélateur que n'importe quel pourcentage.

4. Mon pipeline prend 45 minutes, comment l'accélérer ?

Par ordre d'impact décroissant :

  1. Paralléliser les jobs — lint, tests unitaires et scan peuvent tourner simultanément.
  2. Mettre en cache les dépendances — node_modules, ~/.m2, ~/.cargo. Gain fréquent : plusieurs minutes.
  3. Mettre en cache les couches Docker — avec cache-from / cache-to.
  4. Découper les tests — répartir la suite sur plusieurs runners en parallèle (sharding).
  5. Réduire les tests end-to-end — ils dominent souvent le temps total. Voir la pyramide des tests en leçon 6.
  6. Ne pas tout exécuter à chaque fois — sur un monorepo, ne tester que les modules affectés (Nx, Turborepo, Bazel).
5. Où stocker mes secrets ?

Par ordre de qualité croissante :

  1. Jamais dans le code ou le fichier de pipeline.
  2. Coffre de secrets de la plateforme (GitHub Secrets, GitLab CI Variables) — minimum acceptable.
  3. Gestionnaire dédié (Vault, AWS Secrets Manager) avec rotation — bon.
  4. Identité fédérée OIDC — l'état de l'art : aucun secret de longue durée n'existe. Le pipeline présente un jeton signé, le cloud accorde des droits temporaires.

Si vous ne devez retenir qu'une chose : visez OIDC. C'est devenu accessible sur GitHub Actions, GitLab CI et les trois grands clouds.

6. Peut-on faire du CI/CD sur un monolithe ?

Oui, tout à fait. C'est même plus simple qu'avec des microservices sur certains aspects : un seul pipeline, un seul artefact, un seul déploiement à coordonner.

Les limites réelles d'un monolithe sont :

  • Pipeline plus lent — tout est reconstruit et retesté à chaque changement.
  • Rayon d'impact maximal — un bug quelque part affecte toute l'application.
  • Coordination des équipes — si quinze personnes poussent sur le même monolithe, les conflits augmentent.

Ne migrez pas vers les microservices « pour faire du CI/CD ». C'est une erreur coûteuse et fréquente. Améliorez d'abord votre CI/CD sur le monolithe.

7. CI/CD et base de données : comment gérer les migrations ?

C'est le point le plus délicat du CI/CD, et celui qui cause le plus d'incidents.

Règles essentielles :

  1. Les migrations sont du code versionné — Flyway, Liquibase, Alembic, Prisma Migrate.
  2. Toujours rétrocompatibles — la version précédente doit continuer à fonctionner après la migration, à cause du rolling update.
  3. Motif expand and contract — ajouter la nouvelle colonne, migrer les données, supprimer l'ancienne lors d'un déploiement ultérieur. Jamais tout d'un coup.
  4. Tester la migration sur des données réalistes — une copie anonymisée de la production, pas une base vide.
  5. Prévoir la marche arrière — ou concevoir la migration pour qu'elle n'ait pas besoin d'être annulée.

Voir la leçon 4 pour le détail du motif expand and contract.

8. Faut-il un ingénieur dédié au CI/CD ?

Selon la taille :

  • Moins de 10 développeurs : non. GitHub Actions ou GitLab CI, quelqu'un s'en occupe quelques heures par mois.
  • 10 à 50 développeurs : une personne y consacre 20 à 50 % de son temps.
  • Plus de 50 développeurs : une équipe plateforme dédiée devient rentable — elle fournit des pipelines réutilisables aux équipes produit.

Signal d'alerte : si vos développeurs passent plus de 10 % de leur temps à se battre avec la CI, l'investissement dans quelqu'un de dédié est déjà rentable.

9. CI/CD et DevOps, c'est pareil ?

Non. Le CI/CD est une pratique technique parmi celles du DevOps.

Le DevOps est bien plus large : culture de responsabilité partagée entre développement et exploitation, observabilité, gestion des incidents sans blâme, infrastructure as code, automatisation, boucles de retour rapides.

Formule utile : « le CI/CD est un pilier du DevOps, mais faire du CI/CD ne signifie pas faire du DevOps ». Une équipe peut avoir un excellent pipeline et conserver un mur infranchissable entre développeurs et exploitants.

10. Comment convaincre ma direction d'investir dans le CI/CD ?

Parlez en conséquences métier, pas en outils :

  • Temps de mise sur le marché — « nos concurrents livrent en 2 jours ce qu'on livre en 6 semaines ».
  • Coût des incidents — chiffrez le temps passé en pompiers le mois dernier.
  • Coût des retours arrière — combien a coûté le dernier déploiement raté ?
  • Rétention des talents — les bons ingénieurs quittent les organisations où déployer est une souffrance.
  • Références DORA — le livre Accelerate établit statistiquement le lien avec la rentabilité et la part de marché. C'est un argument qui porte auprès d'une direction.

Tactique efficace : mesurez vos quatre métriques DORA, présentez-les à côté des seuils « élite », et proposez un objectif chiffré à trois mois sur une seule métrique.

11. Le CI/CD coûte-t-il cher ?

Beaucoup moins qu'on ne le croit :

  • Projet open source sur GitHub : gratuit et illimité.
  • Petite équipe, dépôt privé : 0 à 50 € par mois — les quotas gratuits suffisent souvent.
  • Équipe moyenne (20 développeurs) : 100 à 500 € par mois de minutes de runners.
  • Grande organisation : de quelques milliers à quelques dizaines de milliers d'euros par mois, souvent optimisé avec des runners auto-hébergés.

À comparer avec quoi : le coût d'une seule journée d'incident en production dépasse fréquemment une année entière de facture de CI.

12. Que faire quand le pipeline est rouge sur la branche principale ?

C'est la priorité absolue de l'équipe, avant toute autre tâche. La règle canonique de l'intégration continue :

  1. Personne ne pousse de nouveau code sur une branche principale cassée.
  2. La personne qui a cassé répare ou annule son changement immédiatement.
  3. Si la réparation dépasse dix minutes, on annule le commit (git revert) et on répare tranquillement dans une branche.
  4. Un post-mortem léger si la cassure a duré longtemps.

Anti-modèle courant : laisser la branche principale rouge « parce qu'on sait pourquoi ». En quelques jours, l'équipe cesse de regarder le statut, et le pipeline ne protège plus rien.

13. Comment tester un pipeline localement ?

C'est une vraie faiblesse de tous les outils, à des degrés variés :

  • GitHub Actions : l'outil act exécute vos workflows localement dans Docker. Utile, mais imparfait — certaines fonctionnalités ne sont pas reproduites.
  • GitLab CI : gitlab-runner exec permet de lancer un job localement.
  • Jenkins : jenkinsfile-runner, ou plus souvent un serveur Jenkins de test.
  • Approche pragmatique et la plus répandue : une branche jetable nommée test-ci, sur laquelle on itère par petits commits jusqu'à ce que le pipeline passe. Peu élégant, mais efficace.

Bonne pratique de conception : mettez la logique réelle dans des scripts appelés par le pipeline. Vous testez alors le script localement, et le pipeline ne fait plus que l'appeler.

14. Par où commencer concrètement demain matin ?

Plan sur cinq jours, réaliste pour un projet existant :

  1. Jour 1 — Créez un pipeline minimal qui compile le projet à chaque pull request. Rien d'autre.
  2. Jour 2 — Ajoutez le linter et le formateur. Corrigez les avertissements existants.
  3. Jour 3 — Ajoutez les tests existants, même s'ils sont peu nombreux. Rendez le pipeline obligatoire pour fusionner.
  4. Jour 4 — Ajoutez le build de l'image Docker sur la branche principale, étiquetée avec le hash du commit.
  5. Jour 5 — Ajoutez le déploiement automatique vers l'environnement de recette.

Puis, semaine suivante : mesurez vos quatre métriques DORA pour avoir un point de départ. La livraison continue vers la production viendra ensuite, quand la confiance sera établie.

Le principe à retenir : commencez petit et utile, pas grand et parfait.

8. Ce que vous avez appris dans ce cours​

Vous avez désormais la culture CI/CD complète — celle attendue pour un entretien DevOps, pour dialoguer avec votre équipe, ou pour arbitrer un choix d'outillage.

9. Votre prochaine étape​

Piste 1 · Compléter votre culture DevOps​

Piste 2 · Passer à la pratique​

Piste 3 · Agir sur votre projet dès cette semaine​

Reprenez le plan sur cinq jours de la question 14 ci-dessus, et appliquez-le à un projet réel. Même un dépôt personnel suffit — l'important est de taper la première ligne de YAML.

10. Un dernier conseil​

Le meilleur pipeline est celui qui existe. Beaucoup d'équipes passent des mois à concevoir l'architecture de CI/CD idéale et n'en déploient jamais aucune. Un pipeline de vingt lignes qui compile et lance les tests à chaque pull request apporte immédiatement plus de valeur qu'un plan parfait resté dans un document.

Commencez ce soir, sur un projet à vous. Ajoutez un fichier .github/workflows/ci.yml, avec trois étapes. Regardez la coche verte apparaître. C'est comme ça que ça commence.

Retenir en 30 secondes​

  • Amazon déploie toutes les quelques secondes — grâce à son architecture et son organisation, pas seulement à ses outils.
  • Etsy montre que la transformation est d'abord culturelle : chaque nouvel employé déploie dès son premier jour.
  • Netflix automatise le canary avec Spinnaker et provoque volontairement des pannes (chaos engineering).
  • Une banque régulée ne peut pas faire de déploiement continu, mais la livraison continue améliore même sa traçabilité.
  • Une startup de cinq personnes obtient l'essentiel du bénéfice avec 40 lignes de YAML gratuit.
  • N'imitez pas Netflix si vous n'avez pas ses problèmes. La complexité doit répondre à un besoin réel.
  • Commencez petit : compiler et tester à chaque pull request. Le reste viendra.

Merci d'avoir suivi ce cours découverte CI/CD ! 🎉

Envie de continuer ? Retour à la table des matières ou passer au Cours Premium GitHub Actions.

Dernière étape : passez le quiz de fin de cours — cinq questions corrigées et expliquées, trois minutes, pour vérifier que l'essentiel est acquis.