--- term: 'CI/CD (Intégration et Livraison Continues)' seoTitle: 'Qu''est-ce que la CI/CD ? Intégration et livraison continues expliquées' headline: 'Qu''est-ce que la CI/CD (intégration et livraison continues) ?' slug: ci-cd category: cloud-architecture shortDefinition: 'La CI/CD est une pratique qui automatise le build, les tests et la mise en production du code, pour que chaque changement avance par petites étapes.' relatedTerms: - no-ops-development - containerization - kubernetes - backend-boilerplate-code - cloud-code-serverless-functions contrastsWith: - no-ops-development faq: - question: 'Que signifie CI/CD ?' answer: 'Continuous Integration et Continuous Delivery — intégration continue et livraison continue — avec une ambiguïté intégrée que tout praticien devrait connaître : le "CD" peut aussi désigner le déploiement continu (continuous deployment). La livraison conserve une approbation humaine avant la production ; le déploiement la supprime. Quand quelqu''un dit "nous faisons de la CI/CD", la question utile est toujours : quel CD ?' - question: 'Qu''est-ce que l''intégration continue ?' answer: 'La pratique qui consiste à fusionner fréquemment de petits changements dans une branche principale partagée — au moins une fois par jour selon la définition canonique — chaque merge déclenchant un build et une série de tests automatisés. L''enjeu, c''est un retour rapide : les problèmes d''intégration apparaissent quelques minutes après leur création, et non des semaines plus tard dans la cohue d''une release.' - question: 'Quelle est la différence entre livraison continue et déploiement continu ?' answer: 'Une étape d''approbation manuelle. En livraison continue, chaque changement est automatiquement construit, testé et maintenu prêt à livrer, mais c''est un humain qui décide quand la production est réellement mise à jour. En déploiement continu, il n''y a aucune barrière : chaque changement qui passe le pipeline part en production automatiquement, et seul un test en échec l''arrête.' - question: 'Qu''est-ce qu''un pipeline CI/CD ?' answer: 'Le workflow automatisé qu''un changement parcourt du commit à la production : déclenchement par le code source, build, tests automatisés, livraison vers un environnement de staging, puis déploiement. Chaque étape doit réussir avant que la suivante ne démarre ; le pipeline agit donc comme une barrière de qualité que chaque changement franchit de la même manière — pas de cas particuliers, pas d''héroïsme de déploiement.' - question: 'Que sont les métriques DORA ?' answer: 'La mesure de référence de la performance de livraison, issue du programme de recherche DORA : fréquence de déploiement, délai de mise en œuvre des changements, taux d''échec des changements, temps de rétablissement après un déploiement raté et — ajouté plus récemment — taux de reprise des déploiements. Le résultat phare de la recherche : vitesse et stabilité ne sont pas un trade-off, les meilleures équipes excellent sur les deux.' - question: 'La CI/CD est-elle la même chose que DevOps ?' answer: 'Non — DevOps est la culture plus large qui unifie développement et opérations ; la CI/CD en est la colonne vertébrale d''automatisation. Vous pouvez adopter l''outillage CI/CD sans la culture (cela aide moins que prévu) et prêcher la culture sans l''automatisation (cela change moins que promis). Les deux pratiques se renforcent mutuellement, mais elles ne désignent pas la même chose.' - question: 'Quels tests s''exécutent dans un pipeline CI/CD ?' answer: 'Ils s''organisent en couches, selon leur vitesse : tests unitaires et analyse statique à chaque commit, parce qu''ils sont rapides ; tests d''intégration qui vérifient les composants face à de vraies dépendances ; tests end-to-end, tests de performance et scans de sécurité dans des étapes ultérieures ou planifiées, parce qu''ils sont lents. La règle de conception : plus le retour est rapide, plus l''étape est précoce.' - question: 'Les petites équipes ont-elles besoin de CI/CD ?' answer: 'Elles ont davantage besoin de la pratique que de la plomberie. Même une équipe de deux personnes gagne à exécuter des tests automatisés sur chaque changement et à déployer en une seule commande — c''est déjà de la CI/CD sur le fond. Ce que les petites équipes doivent éviter, c''est d''exploiter une infrastructure de pipeline lourde ; les runners hébergés ou les plateformes avec déploiement intégré réduisent la pratique à de la configuration.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Continuous Integration — Martin Fowler (updated 2024)' url: 'https://martinfowler.com/articles/continuousIntegration.html' - name: 'Continuous Delivery — Martin Fowler' url: 'https://martinfowler.com/bliki/ContinuousDelivery.html' - name: 'DORA metrics guide (dora.dev)' url: 'https://dora.dev/guides/dora-metrics-four-keys/' - name: 'CI/CD (Wikipedia)' url: 'https://en.wikipedia.org/wiki/CI/CD' cta: title: 'Le déploiement sans la plomberie du pipeline' text: 'Back4app réduit à presque rien la moitié livraison de la CI/CD : les fonctions Cloud Code se déploient en une commande CLI ou directement depuis un dépôt Git, avec la base de données, l''authentification et les API déjà en ligne. Gardez vos tests ; oubliez la ferme de runners.' linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-16' translationKey: ci-cd --- **La CI/CD est une pratique qui automatise le build, les tests et la mise en production du code, pour que chaque changement avance par petites étapes.** Le sigle condense deux idées — l'intégration continue (fusionner et vérifier en permanence) et la livraison continue (garder chaque changement prêt à livrer) — plus une ambiguïté célèbre : le second "D" peut aussi désigner le *déploiement* continu, où seul un test en échec sépare un commit de la production. ## Points clés | Question | Réponse | | --- | --- | | Ce que c'est | Une automatisation qui transforme le "jour de release" en non-événement permanent | | CI | Fusionner de petits changements chaque jour ; chaque merge lance build et tests | | Les deux CD | La livraison garde une approbation humaine avant la production ; le déploiement la supprime | | Pourquoi ça marche | Les petits changements échouent petit ; un retour rapide attrape les bugs en quelques minutes | | Comment la mesurer | Les cinq métriques DORA — vitesse et stabilité progressent ensemble | ## À quoi ressemble concrètement un pipeline Toute la pratique tient dans un fichier de configuration — l'artefact que chaque page "la CI/CD expliquée" décrit et que presque aucune ne montre : ```yaml # pipeline.yml — l'automatisation qui remplace le "jour du déploiement" on: push to main jobs: build: steps: - checkout - run: npm ci && npm run build test: needs: build steps: - run: npm test # unitaires + intégration, à chaque commit - run: npm run lint # analyse statique deploy: needs: test approval: manual # supprimez cette ligne → déploiement continu steps: - run: npm run deploy ``` Quelques minutes après cette dernière étape, tous les clients appellent déjà la nouvelle version du backend — et c'est tout l'intérêt : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Seconds after `b4a deploy`, every client is calling the new version const version = await Parse.Cloud.run('version'); console.log(`API version: ${version}`); // no pipeline YAML, no runners ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final function = ParseCloudFunction('version'); final response = await function.execute(); if (response.success) { print('API version: ${response.result}'); // fresh from the deploy } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK ParseCloud.callFunction("version") { result in if case .success(let version) = result { print("API version: \(version)") // fresh from the deploy } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK ParseCloud.callFunctionInBackground("version", hashMapOf()) { version, e -> if (e == null) Log.d("API", "version: $version") // fresh from the deploy } ``` ## CI vs. livraison continue vs. déploiement continu | Dimension | Intégration continue | Livraison continue | Déploiement continu | | --- | --- | --- | --- | | Périmètre | Merge + build + tests | …plus des artefacts toujours prêts à livrer | …plus une mise en production automatique | | Déclencheur | Chaque commit sur la branche principale | Chaque build réussi | Chaque build réussi | | Barrière humaine | Aucune (les tests font office de barrière) | **Oui — une approbation de release** | **Aucune** | | Mise à jour de la production | Quand quelqu'un publie une release | Quand quelqu'un clique | En continu | | Idéal pour | Tout le monde | Releases réglementées, lancements calés sur le marketing | Backends web, SaaS, suites de tests de haute confiance | ```mermaid flowchart LR accTitle: Un pipeline CI/CD accDescr: Les commits déclenchent des étapes automatisées de build et de tests ; les changements validés arrivent en staging, puis franchissent soit une barrière d'approbation manuelle en livraison continue, soit aucune barrière en déploiement continu, jusqu'à la production. A[Commit] --> B[Build] --> C[Tests automatisés] --> D[Staging] D --> E{Approbation manuelle ?} E -- "oui — livraison continue" --> F[Production] E -- "aucune barrière — déploiement continu" --> F ``` L'historique tient en une phrase : [l'article de référence de Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html) a défini la CI en 2000, le livre *Continuous Delivery* de 2010 l'a étendue au processus de release, et DevOps a fait du duo sa colonne vertébrale d'automatisation. Une mise en garde de Fowler reste d'actualité : faire tourner un serveur de build sur des feature branches à longue durée de vie, c'est de la "semi-intégration" — la vraie CI suppose que la branche principale intègre le travail de chacun au moins une fois par jour. ## Le pipeline, étape par étape - **Source.** Un commit ou un merge déclenche tout. Jamais de build manuel — si ce n'est pas déclenché, ce n'est pas de la CI. - **Build.** Compiler, résoudre les dépendances, produire l'artefact (bundle, image de conteneur) que toutes les étapes suivantes réutilisent — construire une fois, promouvoir partout. - **Tests.** Les vérifications rapides d'abord : tests unitaires et lint à chaque commit ; tests d'intégration face à de vraies dépendances ensuite ; tests end-to-end, de performance et scans de sécurité dans des exécutions ultérieures ou planifiées. La vitesse du retour décide de l'ordre des étapes. - **Livraison.** L'artefact arrive dans un environnement de staging proche de la production. En livraison continue, il attend là — prêt à livrer — un feu vert humain. - **Déploiement.** La production. Les pipelines matures déploient progressivement — une tranche canary ou un environnement blue/green parallèle — pour qu'un mauvais changement se règle par un rollback circonscrit, pas par une panne. ## La mesurer : les métriques DORA "Livrons-nous bien ?" a une réponse standard : les [cinq métriques du programme de recherche DORA](https://dora.dev/guides/dora-metrics-four-keys/) — fréquence de déploiement, délai de mise en œuvre des changements, taux d'échec des changements, temps de rétablissement après un déploiement raté et taux de reprise des déploiements. Le résultat le plus cité de la recherche : le trade-off classique entre vitesse et stabilité est faux. Les équipes qui déploient le plus souvent sont aussi celles qui cassent le moins, parce que de petits changements fréquents sont individuellement peu risqués et rapides à diagnostiquer. Si votre travail sur le pipeline ne fait bouger aucune des cinq, c'est de la plomberie, pas du progrès. ## Cas d'usage courants - **Backends web et API** — le terrain naturel du déploiement continu intégral : volume de changements élevé, rollback instantané, aucune étape d'installation. - **Applications mobiles** — CI plus *livraison* continue : les pipelines construisent, testent et préparent chaque changement, tandis que la revue des stores impose par nature une barrière à la mise en ligne finale. - **Équipes qui dépassent le déployeur unique** — le pipeline remplace la seule personne qui "sait faire une release" par un processus que tout le monde peut exécuter. - **Environnements réglementés** — la barrière d'approbation devient une feature : automatisation complète jusqu'à la ligne, décision humaine auditable au moment de la franchir. - **Projets open-source** — chaque pull request construite et testée automatiquement, c'est la CI qui sert de porte d'entrée au projet. ## Devriez-vous garder une barrière avant la production ? Matrice de décision | Choisissez le déploiement continu quand… | Gardez la barrière de livraison quand… | | --- | --- | | La suite de tests est assez fiable pour la production | La couverture de tests est encore en train de gagner cette confiance | | Le rollback tient en une commande | Le rollback est un projet | | Les utilisateurs attendent des mises à jour invisibles et constantes | Les releases suivent des dates marketing ou contractuelles | | Le produit est un backend web ou un SaaS | Le produit passe par la revue des stores d'applications | | Les défaillances restent maîtrisées derrière des feature flags | Une mauvaise release a des conséquences réglementaires | Le séquencement honnête : méritez le déploiement continu en pratiquant la livraison continue — automatisez tout jusqu'à la barrière, surveillez le taux d'échec, puis retirez la barrière quand elle ne sert plus à rien. ## Limites et trade-offs - **Le pipeline est du code qui vous appartient.** Runners, YAML, caches, secrets — tout cela demande de la maintenance, et à partir d'une certaine taille d'équipe le pipeline devient un produit à part entière, avec sa propre astreinte. - **Les tests instables empoisonnent tout.** Une suite qui échoue au hasard apprend aux gens à cliquer sur "retry", ce qui retransforme en silence le déploiement continu en déploiement manuel avec des étapes en plus. - **La culture est un prérequis, pas un sous-produit.** Petits merges, développement sur la branche principale et correction immédiate des builds rouges sont des habitudes ; acheter un pipeline ne les installe pas. - **La vitesse sans observabilité, c'est un pari.** Déployer en permanence n'est sûr que si vous voyez les défaillances vite — le monitoring et l'alerting font partie de la pratique, ce ne sont pas des options. - **Le dernier kilomètre varie.** Bases de données, migrations et services stateful résistent au "il suffit de redéployer" ; le pipeline a besoin de stratégies (migrations expand-contract, feature flags) qu'aucun YAML n'écrit à votre place. ## La CI/CD sur Back4app Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Son effet sur la CI/CD est une soustraction côté livraison : Cloud Code se déploie en une commande CLI ou directement depuis un dépôt Git, et le backend standard — base de données, authentification, API — n'apparaît jamais dans votre pipeline, puisqu'il n'y a rien à construire ni à livrer. Il reste la moitié que vous devriez garder : vos tests, exécutés à chaque commit, devant une étape de déploiement qui ne fait plus qu'une ligne.