Une extension WordPress qui expose une route REST consommée par un service de facturation interne peut évoluer sans que personne ne pense à prévenir l’équipe qui consomme cette route. Le jour où un champ change de nom ou de type, la panne se découvre en production, rarement avant.
Pact répond à ce problème avec une approche originale : plutôt que de figer un schéma unique côté fournisseur, il fait générer le contrat par le consommateur lui-même, à partir de ce dont il a réellement besoin, puis le fait vérifier automatiquement contre l’implémentation réelle du fournisseur. Ce billet ne traite pas le figeage manuel d’un schéma REST via un fichier séparé, qui répond à une logique différente.
Étape 1 : le consommateur décrit ce qu’il attend
Côté consommateur, un test Pact simule l’appel réel et enregistre l’interaction attendue : la requête envoyée et la réponse espérée. Ce test tourne contre un faux serveur fourni par Pact, pas contre le vrai fournisseur :
$builder = new \PhpPact\Consumer\InteractionBuilder( $config );
$builder
->given( 'une commande avec l\'identifiant 42 existe' )
->uponReceiving( 'une demande de détail de commande' )
->with( new Request( 'GET', '/wp-json/facturation/v1/commandes/42' ) )
->willRespondWith( new Response( 200, [], [
'id' => 42,
'montant_total' => 89.90,
'statut' => 'payee',
] ) );
L’exécution de ce test génère un fichier JSON, le contrat Pact, qui décrit précisément cette interaction attendue. Ce fichier devient la source de vérité partagée entre les deux équipes, remplaçant les échanges informels sur ce que l’API est censée renvoyer.
Étape 2 : le fournisseur vérifie ce contrat contre sa vraie implémentation
Côté fournisseur, un test dédié charge le contrat généré à l’étape précédente et rejoue chaque interaction décrite contre le vrai code de l’API, pas contre un faux serveur cette fois :
$verifier = new \PhpPact\Standalone\ProviderVerifier\VerifierProcess( $config );
$config->setProviderBaseUrl( 'http://localhost:8080' );
$config->setPactUrls( [ 'contracts/consommateur-facturation.json' ] );
$verifier->verify();
Si le fournisseur a modifié le format de sa réponse, la vérification échoue immédiatement, en indiquant précisément quelle interaction attendue par le consommateur n’est plus honorée. Le fournisseur découvre ainsi une rupture de contrat avant de déployer, plutôt que le consommateur en production.
Le broker Pact : partager les contrats entre équipes
Sur un projet où plusieurs services consomment la même API, un broker Pact centralise les contrats publiés par chaque consommateur, et permet au fournisseur de vérifier son implémentation contre l’ensemble des contrats existants en une seule exécution, sans avoir à connaître à l’avance chaque consommateur individuellement :
- Chaque consommateur publie son contrat vers le broker après chaque exécution de ses propres tests.
- Le fournisseur récupère automatiquement tous les contrats publiés le concernant avant de lancer sa vérification.
- Le broker conserve un historique, utile pour savoir quelle version d’un service dépend de quelle version d’une interaction précise.
Ce que Pact ne couvre pas
Pact vérifie la forme et le contenu structurel d’une interaction, pas le comportement métier complet du fournisseur. Un contrat qui attend un statut « payée » ne garantit pas que la logique de paiement fonctionne réellement ; il garantit seulement que, dans ce scénario donné, la réponse a la forme attendue par le consommateur.
Un contrat Pact protège contre une rupture de forme entre deux services ; il ne remplace jamais un test métier qui vérifie que le comportement réel produit le bon résultat.
Quand cette approche vaut l’investissement
Pact demande une coordination entre deux équipes distinctes, ce qui n’a de sens que lorsque plusieurs services indépendants communiquent réellement entre eux, avec des cycles de déploiement différents. Sur un projet où le consommateur et le fournisseur sont déployés ensemble par la même équipe, un test d’intégration classique reste plus simple à maintenir.
En résumé
Pact déplace la responsabilité de la définition d’un contrat vers le consommateur, qui exprime ce dont il a réellement besoin, puis fait vérifier automatiquement ce contrat contre l’implémentation réelle du fournisseur. Cette approche détecte une rupture de forme entre deux services avant qu’elle n’atteigne la production, à condition que les deux équipes concernées jouent réellement le jeu de la publication et de la vérification régulières.
