Module 2 — GitHub, GitLab, Bitbucket : CI native, webhooks et API

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes

---

Les trois grandes plateformes

	GitHub	GitLab	Bitbucket
CI/CD native	GitHub Actions (.github/workflows/*.yml)	GitLab CI/CD (.gitlab-ci.yml)	Bitbucket Pipelines (bitbucket-pipelines.yml)
Registre de conteneurs intégré	GitHub Container Registry (ghcr.io)	GitLab Container Registry	— (nécessite un registre externe)
Auto-hébergeable	Non (sauf GitHub Enterprise Server, payant)	Oui (édition Community gratuite)	Non
Points forts historiques	Écosystème le plus large, Actions Marketplace	CI/CD la plus intégrée « out of the box », suivi d’incidents intégré	Intégration native avec Jira et Trello (Atlassian)

Ce site et tous ses dépôts compagnons sont hébergés sur GitHub (compte Julionores) — la section suivante interroge donc l’API réelle de ce compte plutôt que de décrire GitHub en théorie.

GitHub Actions : CI native, vérifiée en direct

$ gh workflow list --repo Julionores/junior-tsafack-formation
Deploy to AWS S3    active    329698182

$ gh run list --repo Julionores/junior-tsafack-formation --limit 5
completed  success  fix: remplace la note de veille...           Deploy to AWS S3  main  push
completed  success  feat: ajoute une note de veille sur ChatGPT  Deploy to AWS S3  main  push
completed  success  feat: enrichit le cours cybersecurite...     Deploy to AWS S3  main  push
completed  success  docs: remplace le README generique...       Deploy to AWS S3  main  push
completed  success  fix: replie la navigation laterale...        Deploy to AWS S3  main  push

Ces 5 lignes correspondent aux 5 derniers commits réels poussés sur ce dépôt pendant la rédaction de ce site — chacun a déclenché le pipeline de déploiement, et chacun a réussi. Aucune donnée fictive : c’est l’état réel du compte au moment de l’écriture.

Puisque GitHub Actions est natif, aucun webhook manuel n’est nécessaire pour connecter le dépôt à sa CI — contrairement à Jenkins (voir plus bas), où un webhook doit être configuré explicitement. On le vérifie : la liste des webhooks configurés sur ce dépôt est vide, alors que la CI fonctionne parfaitement.

$ gh api repos/Julionores/junior-tsafack-formation/hooks
[]

Une vraie limite du plan gratuit, découverte en le testant

En tentant d’interroger la protection de branche du dépôt (une fonctionnalité qui empêche de pousser directement sur main sans revue) :

$ gh api repos/Julionores/junior-tsafack-formation/branches/main/protection
{
  "message": "Upgrade to GitHub Pro or make this repository public to enable this feature.",
  "status": "403"
}

C’est une limite réelle et documentée de GitHub : la protection de branche sur un dépôt privé nécessite un abonnement payant (GitHub Pro/Team/Enterprise) ou de rendre le dépôt public. Sur un dépôt public, cette fonctionnalité est gratuite. C’est un vrai arbitrage à connaître avant de choisir la visibilité d’un dépôt professionnel : un dépôt privé sans plan payant ne peut pas empêcher un push direct sur sa branche principale au niveau de la plateforme (seul un hook côté serveur ou une convention d’équipe protège alors main).

GitLab CI/CD : la même idée, une syntaxe différente

GitLab intègre CI/CD et gestion du dépôt dans un seul produit, avec une configuration légèrement plus verbeuse mais très lisible :

.gitlab-ci.yml

stages:
  - test
  - build
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

build:
  stage: build
  script:
    - python -m build
  artifacts:
    paths:
      - dist/

deploy:
  stage: deploy
  script:
    - echo "Déploiement vers la production"
  only:
    - main

La structure stages + un bloc par job (chacun rattaché à un stage via stage:) est l’équivalent direct des jobs: de GitHub Actions vus dans le cours CI/CD — les concepts (étapes séquentielles, artefacts transmis d’une étape à l’autre, déclenchement conditionnel par branche) sont les mêmes, seule la syntaxe change.

Bitbucket Pipelines : la même idée, orientée équipes Atlassian

bitbucket-pipelines.yml

pipelines:
  default:
    - step:
        name: Tests
        image: python:3.12
        script:
          - pip install -r requirements.txt
          - pytest
  branches:
    main:
      - step:
          name: Déploiement
          script:
            - echo "Déploiement vers la production"

Bitbucket vise avant tout les équipes déjà investies dans l’écosystème Atlassian (Jira pour le suivi des tickets, Confluence pour la documentation) — son intérêt principal est l’intégration fluide entre un ticket Jira, une branche, une pull request et son pipeline, plutôt qu’une fonctionnalité CI/CD unique aux autres plateformes.

Comment choisir

• Écosystème open source, Actions Marketplace, projet public → GitHub.
• Besoin d’auto-hébergement, ou CI/CD + gestion de projet + registre tout-en-un → GitLab.
• Équipe déjà sur Jira/Confluence → Bitbucket.

Dans les trois cas, les concepts appris dans le cours CI/CD de ce site (pipeline, étapes, artefacts, secrets, environnements) se transposent directement — seule la syntaxe YAML change d’une plateforme à l’autre.

Prochaine étape

Infrastructure as Code : Terraform et CloudFormation