# Changer de fournisseur CI en gardant vos scénarios de test intacts

> Changer de fournisseur d'intégration continue force souvent à réécrire toute la logique de test. Une séparation claire entre logique et configuration limite ce travail au strict minimum.

- Auteur : Clément Hadrot
- Publié le : 2026-07-28
- Mis à jour le : 2026-07-28
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/changer-fournisseur-ci-scenarios-tests-intacts/

## L’essentiel

- Séparer la logique de test de sa configuration de plateforme dès le départ
- Un script shell autonome se réexécute à l'identique quel que soit le fournisseur
- Ne réécrire que la couche fine de configuration, jamais les scénarios eux-mêmes

Quatre jours. C'est le temps qu'a finalement pris la migration complète d'un fournisseur d'intégration continue vers un autre, dans une agence qui redoutait plusieurs semaines de réécriture pour l'ensemble de ses projets, motivée par des raisons de coût d'infrastructure. Chaque étape de test aurait pu être décrite directement dans un fichier de configuration propriétaire, truffé d'options spécifiques à la plateforme d'origine ; ce n'était pas le cas, grâce à une décision d'architecture prise bien avant que la question du changement de fournisseur ne se pose.

Cette décision consistait à ne jamais écrire la logique de test directement dans le fichier de configuration de la plateforme, mais dans des scripts shell autonomes, appelés depuis cette configuration sans jamais dépendre de sa syntaxe propre.

## Le piège d'une logique de test dispersée dans la configuration

Un fichier de configuration de plateforme d'intégration continue propose souvent des fonctionnalités pratiques : mise en cache automatique des dépendances, matrices de versions, notifications intégrées. La tentation est grande d'y écrire directement chaque commande de test, chaque condition d'exécution, chaque variable d'environnement, ce qui fonctionne parfaitement tant qu'aucun changement de plateforme n'est envisagé. Le jour où ce changement survient, toute cette logique doit être traduite dans la syntaxe d'un système différent, souligné par des concepts qui ne se recouvrent pas toujours exactement.

## Extraire la logique dans des scripts autonomes

La méthode retenue consiste à réduire le fichier de configuration de la plateforme à son strict minimum : déclencher l'environnement, puis appeler un script shell qui contient toute la logique réelle, sans aucune référence à une variable ou une fonctionnalité propre à la plateforme :

```
#!/usr/bin/env bash
set -euo pipefail

composer install --no-interaction
vendor/bin/phpunit --testsuite=unitaires
vendor/bin/phpunit --testsuite=integration
npx playwright test
```

Ce script, nommé `scripts/executer-tests.sh` et versionné dans le dépôt aux côtés du code applicatif, ne connaît rien de la plateforme qui l'exécute. Il pourrait tout aussi bien être lancé sur un poste de développeur en local.

### Ce que le fichier de configuration de la plateforme conserve malgré tout

Certains éléments restent nécessairement propres à chaque plateforme et ne peuvent pas être extraits dans un script partagé : la définition de l'image de base, les règles de déclenchement selon la branche, la gestion du cache de dépendances entre exécutions. Ces éléments forment une couche fine et volontairement limitée :

```
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-php@v2
        with:
          php-version: '8.3'
      - run: bash scripts/executer-tests.sh
```

> L'essentiel à retenir : Séparer la logique de test de sa configuration de plateforme dès le départ ; Un script shell autonome se réexécute à l'identique quel que soit le fournisseur ; Ne réécrire que la couche fine de configuration, jamais les scénarios eux-mêmes

## Comparer l'effort de migration avec et sans cette séparation

| Approche | Ce qu'il faut réécrire lors d'un changement de fournisseur | Effort estimé |
| --- | --- | --- |
| Logique dans la configuration de plateforme | Chaque commande, condition et variable de test | Plusieurs semaines |
| Logique dans un script autonome | Uniquement la couche de déclenchement et de cache | Quelques jours |

### Ce qui a réellement demandé du travail pendant ces quatre jours

La migration n'a pas été instantanée pour autant. Le nouveau fournisseur gérait différemment la mise en cache des dépendances Composer, ce qui a nécessité un ajustement spécifique, et le format de rapport de résultats attendu par son interface différait de celui produit nativement par PHPUnit, imposant l'ajout d'une étape de conversion. Ces ajustements, bien réels, sont restés circonscrits à la couche de configuration, sans jamais toucher aux scripts de test eux-mêmes ni aux scénarios qu'ils contenaient.

> La configuration d'une plateforme d'intégration continue devrait pouvoir changer entièrement sans qu'un seul scénario de test n'ait besoin d'être touché. Si ce n'est pas le cas, la frontière entre logique et configuration a été mal tracée dès le départ.

## Anticiper cette séparation même sans projet de migration

Cette architecture ne se justifie pas uniquement par un changement de fournisseur déjà planifié. Elle facilite aussi l'exécution des mêmes tests en local, par un développeur qui n'a pas besoin d'attendre le retour de la pipeline distante pour vérifier son travail, ce qui constitue un bénéfice quotidien indépendant de toute question de fournisseur.

## En résumé

Séparer la logique de test, portée par des scripts autonomes versionnés avec le code, de sa configuration propre à chaque plateforme d'intégration continue réduit considérablement l'effort d'un changement de fournisseur. Le fichier de configuration se limite alors à un rôle de déclencheur, remplaçable en quelques jours plutôt qu'en plusieurs semaines, sans jamais remettre en cause les scénarios de test qui, eux, n'appartiennent à aucune plateforme en particulier.