CI/CD pour les projets PHP : GitHub Actions, GitLab CI et déploiement automatisé

Publié le — DevOps

La CI/CD (Intégration Continue / Déploiement Continu) automatise les tâches répétitives du développement : tests, analyse de code, sécurité et déploiement. Chaque commit est vérifié automatiquement avant d'atteindre la production. En 2026, GitHub Actions exécute plus de 6 millions de workflows par jour et GitLab CI reste la référence pour les équipes auto-hébergées. Ce guide couvre la mise en place d'un pipeline complet pour un projet PHP — qu'il s'agisse d'un site PrestaShop, d'une application Symfony ou d'un site WordPress.

Qu'est-ce qu'un pipeline CI/CD ?

Un pipeline CI/CD est une suite d'étapes automatisées qui se déclenchent à chaque push de code. L'objectif : détecter les problèmes le plus tôt possible et déployer en production avec confiance.

Pipeline CI/CD pour un projet PHP Schéma horizontal montrant les 5 étapes d'un pipeline CI/CD : Push (déclencheur), Build (Composer, npm), Test (PHPUnit, PHPStan, PHPCS), Sécurité (audit, SAST) et Deploy (rsync/SSH). Push git push Déclencheur push, PR, tag Build install Dépendances Composer, npm Test quality Qualité PHPUnit, PHPStan PHPCS, Rector Sécurité audit Vulnérabilités composer audit npm audit Deploy prod Production rsync / SSH Docker Chaque étape doit passer avant d'atteindre la suivante — un échec bloque le pipeline
Pipeline CI/CD PHP : du push au déploiement en production. Chaque étape valide le code avant la suivante.

GitHub Actions vs GitLab CI

Les deux plateformes couvrent les mêmes besoins mais avec des approches différentes :

  • GitHub Actions — Fichiers YAML dans .github/workflows/. Marketplace de +15 000 actions communautaires. Gratuit pour les repos publics, 2 000 minutes/mois pour les privés. Idéal si votre code est sur GitHub.
  • GitLab CI — Un seul fichier .gitlab-ci.yml avec des stages et jobs. Registre de conteneurs intégré, environnements de review, scanning de sécurité natif. Plus adapté aux équipes auto-hébergées ou qui utilisent GitLab comme plateforme complète (issues, wiki, CI, registre).

Structure d'un pipeline GitHub Actions

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install
      - run: vendor/bin/phpstan analyse
      - run: vendor/bin/phpcs

  tests:
    needs: quality
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          coverage: xdebug
      - run: composer install
      - run: vendor/bin/phpunit --coverage-text

Équivalent GitLab CI

# .gitlab-ci.yml
stages:
  - quality
  - test

phpstan:
  stage: quality
  image: php:8.3
  script:
    - composer install
    - vendor/bin/phpstan analyse

phpcs:
  stage: quality
  image: php:8.3
  script:
    - composer install
    - vendor/bin/phpcs

phpunit:
  stage: test
  image: php:8.3
  script:
    - composer install
    - vendor/bin/phpunit --coverage-text

Les outils de qualité PHP dans un pipeline

PHPStan — Analyse statique

PHPStan détecte les erreurs de type, les appels à des méthodes inexistantes, les variables non définies et les incohérences de code sans exécuter le code. Il s'exécute en quelques secondes et attrape des bugs qui ne seraient visibles qu'en production.

  • Niveau recommandé : 5 pour commencer, monter progressivement vers 8
  • Configuration : fichier phpstan.neon à la racine du projet
  • Dans le pipeline : le job échoue si PHPStan trouve une erreur → le merge est bloqué

PHPCS — Style de code

PHPCS (PHP_CodeSniffer) vérifie que le code respecte un standard de style : PSR-12, PSR-2 ou un standard personnalisé. Son compagnon PHPCBF corrige automatiquement les violations de style.

  • Standard recommandé : PSR-12 (inclut PSR-2 + PHP 7/8 rules)
  • Alternative : PHP-CS-Fixer (plus flexible, utilisé par Symfony)
  • Dans le pipeline : vérification automatique sur chaque PR

PHPUnit — Tests automatisés

Les tests unitaires vérifient que chaque composant fonctionne isolément. Un pipeline CI exécute les tests à chaque commit — une régression est détectée immédiatement, pas en production.

  • Couverture de code : activer xdebug pour mesurer le % de code testé
  • Rapport : --coverage-text dans le terminal ou --coverage-clover pour un rapport XML

Rector — Modernisation PHP

Rector analyse le code et propose des modernisations automatiques : migration vers PHP 8.3, amélioration de la qualité, suppression du code mort. En mode --dry-run dans la CI, il signale le code à moderniser sans le modifier.

Audit de sécurité dans le pipeline

Chaque dépendance PHP ou JavaScript peut contenir une vulnérabilité. L'audit automatisé à chaque push détecte les failles avant qu'elles n'atteignent la production :

  • composer audit — Vérifie les CVE connues sur les packages PHP. Intégré nativement à Composer depuis la version 2.4.
  • npm audit — Vérifie les vulnérabilités des packages JavaScript. Utiliser --audit-level=high pour ne bloquer que sur les failles critiques.
  • Semgrep / SonarQube — Analyse SAST (Static Application Security Testing) pour détecter les injections SQL, XSS et autres failles dans le code source.

Déploiement automatisé

Déploiement via rsync + SSH

L'approche la plus courante pour les projets PHP hébergés sur un serveur dédié ou mutualisé. Le pipeline construit les assets, installe les dépendances de production, puis synchronise les fichiers via SSH :

  1. composer install --no-dev — Dépendances PHP sans les outils de dev
  2. npm ci && npm run build — Assets front-end compilés
  3. rsync -avz --exclude-from='.rsync-exclude' — Transfert vers le serveur (exclut .git, tests, Docker, node_modules)

Les credentials (clé SSH, hostname, chemin) sont stockés dans les secrets chiffrés de GitHub/GitLab — jamais en clair dans le code.

Déploiement via Docker

Pour les projets containerisés, le pipeline construit l'image Docker, la pousse sur un registre (GitHub Packages, GitLab Container Registry, Docker Hub) et met à jour le conteneur en production :

  1. docker build -t mon-app:latest . — Construction de l'image
  2. docker push registry/mon-app:latest — Push vers le registre
  3. Mise à jour du conteneur en production (Docker Compose, Kubernetes, ECS)

Stratégies de déploiement

  • Déploiement sur push main — Chaque merge sur la branche principale déclenche un déploiement. Simple et adapté aux petits projets.
  • Déploiement sur tag — Un tag Git (v1.2.3) déclenche le déploiement. Plus de contrôle, adapté aux projets avec des releases planifiées.
  • Déploiement manuel — Un bouton dans l'interface CI (workflow_dispatch) permet de déclencher le déploiement à la demande.

Bonnes pratiques CI/CD en 2026

Optimisation du pipeline

  • Cache des dépendances — Composer et npm ne sont réinstallés que si le lockfile change. Gain : 30 secondes à 2 minutes par run.
  • Jobs parallèles — PHPStan, PHPCS et l'audit de sécurité s'exécutent en parallèle, pas en séquence.
  • Concurrency — Annuler automatiquement les workflows en cours quand un nouveau push arrive sur la même branche.

Sécurité du pipeline

  • Épingler les actions par SHA — uses: actions/checkout@abcdef123 au lieu de @v4. Empêche les attaques supply chain si un tag est compromis.
  • Permissions minimales — Restreindre le GITHUB_TOKEN aux permissions nécessaires (contents: read, pas write sauf pour le deploy).
  • Secrets chiffrés — Jamais de mots de passe, clés SSH ou tokens en clair dans les fichiers YAML.
  • Dependabot / Renovate — Mise à jour automatique des dépendances avec PR de sécurité.

Conventions de branche

  • main — Branche de production, protégée, merge uniquement via PR validée par la CI
  • develop — Branche d'intégration, la CI valide chaque push
  • feature/* — Branches de fonctionnalité, la CI valide chaque PR

Checklist CI/CD pour un projet PHP

Pipeline minimal (1h de setup)

  • PHPStan (analyse statique)
  • PHPCS (style PSR-12)
  • PHPUnit (tests)
  • Composer audit (sécurité PHP)

Pipeline complet

  • Tout le minimal +
  • npm audit (sécurité JS)
  • Rector dry-run (modernisation)
  • Build assets (Webpack/Vite)
  • Couverture de code
  • Déploiement automatisé (rsync ou Docker)
  • Concurrency + cache

Questions fréquentes

GitHub Actions ou GitLab CI : lequel choisir ?

Les deux sont d'excellentes solutions. GitHub Actions s'intègre naturellement si votre code est sur GitHub (marketplace de +15 000 actions, gratuit pour les repos publics). GitLab CI est plus adapté si vous utilisez GitLab (registre de conteneurs intégré, environnements de review, scanning de sécurité natif). Le choix dépend surtout de votre hébergement de code.

Quels outils de qualité PHP intégrer dans un pipeline CI ?

Les incontournables : PHPStan pour l'analyse statique (détecte les erreurs de type), PHPCS ou PHP-CS-Fixer pour le respect du style de code (PSR-12), PHPUnit pour les tests unitaires, et Composer audit pour les vulnérabilités des dépendances. Rector en dry-run est un bonus pour détecter le code à moderniser.

La CI/CD est-elle utile pour un petit projet ?

Oui. Même un site vitrine bénéficie d'un pipeline CI : PHPStan détecte les erreurs avant la mise en production, PHPCS maintient un code cohérent, et un déploiement automatisé élimine les erreurs de transfert FTP manuel. Le temps d'installation (1-2h) est rentabilisé dès le premier bug évité.

Comment sécuriser un pipeline CI/CD ?

Les bonnes pratiques : épingler les actions par SHA complet (pas par tag), stocker les credentials dans les secrets chiffrés (jamais en clair dans le code), appliquer les permissions minimales sur les tokens, utiliser OIDC au lieu de credentials statiques pour l'authentification cloud, et auditer régulièrement les dépendances du pipeline.

Top