> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atconseil.info/llms.txt
> Use this file to discover all available pages before exploring further.
# Réaffectation en masse
> Réaffecter le testeur ou la configuration de tout un plan, d'une suite et ses enfants, ou une valeur remplacée par une autre — avec un récapitulatif d'impact complet avant toute écriture.
Azure DevOps sait assigner des testeurs au niveau d'une suite, mais **l'action ne cascade pas vers les suites enfants**. Sur un plan de 172 suites portant 296 test points, réaffecter un testeur impose d'ouvrir jusqu'à 172 suites à la main.
L'import CSV et la grille d'édition en masse n'aident pas davantage : ils modifient des **champs du work item Cas de test**, alors que le testeur et la configuration appartiennent au **test point**. Aucun contournement natif n'existe.
L'onglet **Réaffectation en masse** comble ce trou. Il parcourt le plan, montre ce qui s'y trouve réellement, et applique le changement en une passe.
## Cinq étapes
Choisissez un plan, ou jusqu'à dix à la fois. Un champ de recherche filtre la liste déjà chargée, sur le nom du plan, l'itération ou un identifiant exact. Le filtre **masque, il ne désélectionne jamais** — un plan sélectionné que la recherche cache reste sélectionné, et le compteur continue d'afficher le total réel.
Testeurs et configurations côte à côte, triés par volume. Chaque ligne indique son nombre de points, combien d'entre eux portent déjà un résultat d'exécution, et sa part du périmètre. Une configuration pesant moins de 2 % des points est marquée **résiduelle** — le plus souvent un héritage à normaliser. **Non assigné** est une ligne à part entière, pas une absence.
Rien n'est mis en cache. L'inventaire est reconstruit à chaque analyse et porte l'horodatage de sa lecture, parce qu'agir sur une vue périmée est le vrai risque ici.
Choisissez quoi réaffecter — **testeur** ou **configuration** — puis l'un des trois modes :
* **Remplacer partout** — une ou plusieurs valeurs actuelles remplacées par une autre
* **Tout le périmètre** — chaque point ne portant pas déjà la valeur cible
* **Une suite et ses enfants** — récursivement, à n'importe quelle profondeur
Les suites s'affichent en arborescence, avec repli et dépli, et une recherche par nom qui garde un résultat visible avec ses ancêtres. Une suite ne portant aucun point apparaît quand même comme branche, pour que ses descendants restent atteignables.
Points concernés, suites touchées, points déjà exécutés, cas ignorés et nombre d'appels API estimé — plus l'opération en langage clair et l'endpoint exact qui sera appelé. Le bouton d'application reste désactivé tant que l'impact est nul.
C'est ici que vous choisissez le sort des points portant déjà un résultat, et que vous pouvez exporter l'état antérieur en CSV.
Combien de points ont été réaffectés sur combien, la durée, et chaque échec avec son code HTTP et une cause en clair. Un bouton de reprise ne rejoue **que** les échecs.
## Testeur et configuration ne sont pas la même opération
C'est le passage à lire deux fois.
| | Testeur | Configuration |
| ------------------------------------ | --------------------------------------------------- | ------------------------------------------------------------- |
| Ce qui se passe | Le test point est conservé, seul son testeur change | Les affectations du cas de test sont réécrites |
| Résultat d'exécution | **Préservé** | Azure DevOps peut recréer le point, **emportant le résultat** |
| « Inclure les points déjà exécutés » | *Le résultat reste attaché au point* | *Le résultat sera perdu* |
Les présenter comme un seul mécanisme serait la manière la plus simple de faire perdre son historique d'exécution à quelqu'un ; l'interface les tient donc visiblement séparés.
**L'opération est irréversible.** Azure DevOps ne propose aucune annulation et TestPulse ne conserve aucun état antérieur — une décision délibérée, énoncée à l'écran au-dessus du bouton d'application. L'export CSV de l'état antérieur est la trace à garder. Voir [Lecture seule par défaut](/fr/concepts/read-only).
## Deux comportements qui surprennent
**Un cas de test portant déjà la configuration cible est ignoré, jamais fusionné.** Le fusionner supprimerait l'une de ses affectations. Les cas ignorés sont listés avec leur suite et leur identifiant, et exportables en CSV.
**Un échec partiel est un résultat valide, pas un état corrompu.** Rien n'est annulé : les points déjà réaffectés le restent. C'est voulu — une annulation supposerait un état antérieur que TestPulse ne conserve délibérément pas.
## Permissions
La réaffectation en masse utilise le scope **`vso.test_write`** que le Coverage Builder déclare déjà — aucune nouvelle permission n'est demandée. Un **403** sur une suite est presque toujours une ACL de chemin d'itération plutôt qu'un scope manquant ; le rapport nomme la suite pour que vous puissiez vérifier.
## À lire ensuite
Où TestPulse écrit, et ce qu'il ne touche jamais.
Chaque scope et ce qu'il alimente exactement.