# Trois équipes, un seul environnement de recette : qui casse quoi et quand > Trois équipes déployant sur le même environnement de recette provoquent des conflits difficiles à tracer. Retour sur un cas concret et la règle d'usage adoptée ensuite. - Auteur : Clément Hadrot - Publié le : 2025-09-29 - Mis à jour le : 2025-09-29 - Catégorie : Tests - URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/trois-equipes-environnement-recette-partage/ ## L’essentiel - Un déploiement d'une équipe peut invalider le test en cours d'une autre sans avertissement - Un tableau de réservation simple suffit à éviter la majorité des conflits - Les données de test partagées doivent être réinitialisées selon une règle explicite Comment expliquer qu'un test validé la veille échoue le lendemain matin sans qu'aucun changement n'ait été apporté au code testé ? C'est la question qu'une équipe de développement web s'est posée en partageant un unique environnement de recette avec deux autres équipes, l'une travaillant sur le module de paiement, l'autre sur le module de gestion des stocks, la troisième sur le tunnel de commande lui-même. La réponse, une fois trouvée, était simple : un déploiement de la deuxième équipe, réalisé pendant la nuit pour tester une migration de base de données, avait réinitialisé une table de configuration partagée que la première équipe utilisait pour son propre scénario de test. Aucune des deux équipes n'avait connaissance du travail de l'autre, et l'environnement de recette, censé représenter fidèlement la production, s'est révélé être un terrain instable et imprévisible. ## Ce qu'un environnement partagé rend invisible Un environnement de recette unique donne l'illusion d'un espace stable, alors qu'il concentre en réalité les déploiements, les modifications de données et les redémarrages de service de plusieurs équipes indépendantes. Chaque équipe teste dans un contexte qu'elle ne maîtrise qu'en partie, sans visibilité sur ce que les autres y font au même moment. Un test qui échoue dans ces conditions déclenche une enquête qui commence presque toujours par la mauvaise hypothèse : chercher un bug dans le code fraîchement modifié, avant de découvrir que la cause vient d'un déploiement totalement extérieur. ## Le tableau de réservation, une solution à la fois simple et efficace La règle adoptée après cet incident ne repose sur aucun outil complexe : un tableau partagé, visible par les trois équipes, où chaque créneau de déploiement ou de session de test intensive se réserve à l'avance : | Créneau | Équipe | Action prévue | | --- | --- | --- | | Mardi 9h-11h | Paiement | Test du remboursement partiel | | Mardi 14h-15h | Stocks | Déploiement de la migration de table | | Mercredi 9h-12h | Tunnel de commande | Session de recette client | Un déploiement qui touche une table partagée par plusieurs modules doit désormais être annoncé au moins la veille, avec un message explicite dans le canal commun des trois équipes, précisant les tables concernées. ### Réinitialiser les données selon une règle explicite, pas au hasard Une seconde source de conflit venait de la réinitialisation des données de test elle-même : chaque équipe réimportait un jeu de données différent selon ses propres besoins, écrasant parfois celui préparé par une autre équipe pour un scénario en cours. La règle adoptée fixe désormais un jeu de données de référence commun, réinitialisé uniquement le lundi matin avant le début de la semaine de travail, via une commande WP-CLI partagée : ``` wp db import environnement-recette-reference.sql --path=/var/www/recette wp cache flush --path=/var/www/recette ``` Toute équipe ayant besoin d'un jeu de données spécifique en dehors de ce cycle doit désormais utiliser un environnement isolé temporaire plutôt que de modifier l'environnement partagé. > L'essentiel à retenir : Un déploiement d'une équipe peut invalider le test en cours d'une autre sans avertissement ; Un tableau de réservation simple suffit à éviter la majorité des conflits ; Les données de test partagées doivent être réinitialisées selon une règle explicite ## Ce que cette organisation ne résout pas complètement Le tableau de réservation réduit les conflits mais ne les élimine pas totalement : il repose sur la discipline de chaque équipe à consulter le tableau avant d'agir, ce qui reste une convention humaine et non une contrainte technique. Dans les faits, un petit nombre d'incidents subsiste encore, généralement liés à un créneau non réservé lors d'une urgence de dernière minute, mais leur fréquence a nettement diminué depuis la mise en place de cette règle. > Un environnement de recette partagé entre plusieurs équipes ressemble à une cuisine commune : chacun peut cuisiner, mais personne ne doit vider le réfrigérateur sans prévenir les autres. ### Une piste envisagée mais non retenue pour l'instant La création d'un environnement de recette distinct par équipe a été envisagée, mais écartée dans ce contexte précis en raison du coût d'infrastructure et de la nécessité, pour certains scénarios de test, de vérifier l'interaction réelle entre les trois modules développés séparément. Cette organisation par créneaux réservés reste donc un compromis assumé plutôt qu'une solution idéale. ## En résumé Trois équipes sur un seul environnement de recette produisent, sans coordination explicite, des échecs de test dont la cause réelle se trouve rarement dans le code testé lui-même. Un tableau de réservation simple et une règle claire de réinitialisation des données ont suffi, dans ce cas, à ramener la majorité des conflits à un niveau tolérable, sans investissement technique lourd.