+ {% if site.search_enabled != false %}
+ {% include components/search_footer.html %}
+ {% endif %}
+
+ {% if site.mermaid %}
+ {% include components/mermaid.html %}
+ {% endif %}
+
+
diff --git a/fr/index.md b/fr/index.md
new file mode 100644
index 0000000..c06f700
--- /dev/null
+++ b/fr/index.md
@@ -0,0 +1,74 @@
+---
+layout: default
+title: Accueil
+nav_order: 1
+description: "Playwright 101 : des récits utilisateurs aux tests automatisés"
+permalink: /fr/
+---
+
+## Atelier Playwright 101
+
+Des récits utilisateurs aux tests automatisés avec Playwright, GitHub Copilot et Azure DevOps
+{: .fs-6 .fw-300 }
+
+## Présentation de l'atelier
+
+Cet atelier pratique accompagne les spécialistes de l'assurance qualité dans le
+passage des tests manuels à l'automatisation du navigateur avec Playwright. Vous
+partirez de récits utilisateurs, les transformerez en cas de test structurés, puis
+implémenterez ces tests avec le cadre de tests de bout en bout libre de Microsoft.
+
+Vous utiliserez GitHub Copilot pour accélérer la rédaction des tests et découvrirez
+comment le développement assisté par l'IA s'intègre au travail de test. Au labo 04,
+choisissez GitHub Actions ou Azure DevOps pour exécuter en parallèle les suites
+fonctionnelle et d'accessibilité. Le labo 05 prolonge l'atelier avec des analyses
+d'accessibilité axe, l'examen des échecs et des vérifications manuelles.
+
+Aucune expérience préalable en automatisation n'est requise. Le parcours principal
+dure environ une heure avec l'un des deux labos CI. Prévoyez 20 minutes de plus
+pour le volet accessibilité.
+
+## Modules de l'atelier
+
+| Module | Titre | Durée | Description |
+| --- | --- | --- | --- |
+| Labo 00 | [Prérequis](labs/lab-00-prerequisites/) | Avant l'atelier | Préparer l'environnement |
+| Labo 01 | [Des récits utilisateurs aux cas de test](labs/lab-01-test-planning/) | 10 min | Relier les exigences aux tests |
+| Labo 02 | [Votre premier test Playwright](labs/lab-02-playwright-basics/) | 20 min | Rédiger des tests en pratique |
+| Labo 03 | [GitHub Copilot pour les tests](labs/lab-03-copilot-testing/) | 15 min | Générer des tests avec l'IA |
+| Labo 04 | [Pipeline CI/CD (GitHub Actions)](labs/lab-04-ci-pipeline/) | 15 min | Automatiser l'exécution des tests |
+| Labo 04 | [Pipeline CI/CD (Azure DevOps)](labs/lab-04-ci-pipeline-ado/) | 15 min | Automatiser l'exécution des tests |
+| Labo 05 | [Tests d'accessibilité](labs/lab-05-accessibility/) | 20 min (complément) | Analyses axe, résultats CI et vérifications manuelles |
+
+## Application cible
+
+Tous les labos utilisent la page de recherche Ontario.ca
+(`https://www.ontario.ca/search`) comme système à tester. Cette application React
+monopage publique propose un champ de recherche, des filtres, une pagination et des
+résultats dynamiques sans authentification ni accès particulier. Les participants
+utilisent le même environnement en ligne pour limiter la configuration nécessaire.
+
+Les tests ciblent la version anglaise du site. Gardez les valeurs de recherche,
+les libellés d'interface et les sélecteurs anglais dans le code, même lorsque vous
+suivez les consignes en français.
+
+## Démarrage rapide
+
+Clonez le dépôt, installez les dépendances et vérifiez votre environnement :
+
+```bash
+git clone https://github.com/devopsabcs-engineering/playwright-101.git
+cd playwright-101/playwright-tests
+npm install
+npx playwright install --with-deps chromium
+npx playwright test
+```
+
+La commande par défaut exécute uniquement les tests fonctionnels, y compris deux
+tests `@failure-demo` qui échouent volontairement. Exécutez
+`npm run test:accessibility` pour les analyses axe, puis
+`npx playwright show-report playwright-report/accessibility` pour consulter leur
+rapport. Le site en ligne peut changer ou présenter des problèmes d'accessibilité.
+Pour les problèmes de configuration, consultez les
+[prérequis](labs/lab-00-prerequisites/); pour les constats d'analyse, consultez le
+[labo 05](labs/lab-05-accessibility/).
diff --git a/fr/labs/lab-00-prerequisites/README.md b/fr/labs/lab-00-prerequisites/README.md
new file mode 100644
index 0000000..1085f22
--- /dev/null
+++ b/fr/labs/lab-00-prerequisites/README.md
@@ -0,0 +1,118 @@
+---
+layout: default
+title: "Labo 00 : Prérequis"
+nav_order: 2
+description: "Préparer votre environnement de développement pour l'atelier Playwright 101"
+permalink: /fr/labs/lab-00-prerequisites/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 15 minutes (à votre rythme) |
+| **Niveau** | Débutant |
+| **Type** | Configuration |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, votre environnement de développement sera configuré pour
+rédiger et exécuter des tests Playwright tout au long de l'atelier.
+
+## Prérequis
+
+* Un système Windows, macOS ou Linux
+* Un accès Internet
+* Un compte GitHub (l'offre gratuite suffit)
+
+## Exercices
+
+### Exercice 1 : Installer Node.js 20 ou une version ultérieure
+
+Téléchargez et installez Node.js 20 ou une version ultérieure à partir de
+[nodejs.org](https://nodejs.org). La version LTS (prise en charge à long terme)
+est recommandée. Vérifiez l'installation :
+
+```bash
+node --version
+```
+
+La sortie doit afficher `v20.x.x` ou une version ultérieure.
+
+### Exercice 2 : Installer Visual Studio Code
+
+Téléchargez et installez Visual Studio Code à partir de
+[code.visualstudio.com](https://code.visualstudio.com). Vous utiliserez cet éditeur
+pour rédiger vos tests et interagir avec GitHub Copilot.
+
+### Exercice 3 : Installer les extensions VS Code
+
+Ouvrez VS Code et installez les extensions suivantes à partir du catalogue :
+
+1. **Playwright Test for VS Code** permet d'exécuter et de déboguer les tests,
+ ainsi que de générer du code directement dans l'éditeur.
+2. **GitHub Copilot** permet la rédaction de tests assistée par l'IA au labo 03.
+
+> [!TIP]
+> Recherchez chaque extension par son nom dans le volet Extensions
+> (`Ctrl+Shift+X`), puis sélectionnez **Install** (Installer).
+
+### Exercice 4 : Cloner le dépôt
+
+Ouvrez un terminal et clonez le dépôt de l'atelier :
+
+```bash
+git clone https://github.com/devopsabcs-engineering/playwright-101.git
+```
+
+### Exercice 5 : Installer les dépendances
+
+Accédez au répertoire du projet de tests et installez les dépendances Node.js :
+
+```bash
+cd playwright-101/playwright-tests
+npm install
+```
+
+### Exercice 6 : Installer les navigateurs Playwright
+
+Playwright a besoin des exécutables de navigateur pour lancer les tests. Installez
+Chromium et ses dépendances système :
+
+```bash
+npx playwright install --with-deps chromium
+```
+
+### Exercice 7 : Vérifier la configuration
+
+Exécutez la suite fonctionnelle pour confirmer que les tests démarrent :
+
+```bash
+npx playwright test
+```
+
+La suite comprend sept scénarios normaux et deux tests `@failure-demo` qui échouent
+volontairement pour pratiquer le diagnostic. Pour vérifier uniquement les scénarios
+normaux :
+
+```bash
+npx playwright test --grep-invert @failure-demo
+```
+
+Les tests ciblent la version anglaise d'Ontario.ca. Conservez les chaînes anglaises
+dans le code. Le site en ligne peut évoluer; distinguez un problème de configuration
+d'un échec d'assertion avant de modifier l'environnement.
+
+## Point de vérification
+
+Les sept scénarios normaux démarrent sans erreur de dépendance ni de navigateur.
+Examinez tout échec lié au site en ligne et distinguez-le des deux démonstrations
+intentionnelles. En cas d'erreur de configuration, reprenez l'étape concernée.
+
+## Résumé
+
+Votre environnement comprend Node.js, VS Code avec les extensions requises et
+Chromium pour Playwright. Vous savez exécuter la suite et reconnaître les échecs
+intentionnels.
+
+## Étape suivante
+
+Passez au [labo 01 : Des récits utilisateurs aux cas de test](../lab-01-test-planning/).
diff --git a/fr/labs/lab-01-test-planning/README.md b/fr/labs/lab-01-test-planning/README.md
new file mode 100644
index 0000000..93c833b
--- /dev/null
+++ b/fr/labs/lab-01-test-planning/README.md
@@ -0,0 +1,121 @@
+---
+layout: default
+title: "Labo 01 : Des récits utilisateurs aux cas de test"
+nav_order: 3
+description: "Relier les récits utilisateurs et les critères d'acceptation à des scénarios testables"
+permalink: /fr/labs/lab-01-test-planning/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 10 minutes |
+| **Niveau** | Débutant |
+| **Type** | Concepts et démonstration |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, vous pourrez :
+
+* Relier les récits utilisateurs aux critères d'acceptation, puis aux cas de test
+* Dégager des scénarios testables à partir des exigences
+* Organiser les cas de test selon leur priorité et leur complexité
+
+## Prérequis
+
+* Avoir terminé le [labo 00 : Prérequis](../lab-00-prerequisites/)
+
+## Exercices
+
+### Exercice 1 : Lire le récit utilisateur
+
+Considérez ce récit utilisateur de ServiceOntario :
+
+> **En tant que** citoyen,
+> **je veux** rechercher des services gouvernementaux sur ontario.ca
+> **afin de** trouver rapidement les renseignements dont j'ai besoin.
+
+Ce récit décrit une fonction réelle d'ontario.ca. La suite de tests de l'atelier
+cible précisément cette fonction et fournit un exemple concret pour chaque test.
+
+### Exercice 2 : Définir les critères d'acceptation
+
+Les critères d'acceptation définissent ce qui rend un récit utilisateur terminé.
+À partir du récit ci-dessus, demandez-vous : « Quelles conditions doivent être
+remplies pour que cette fonction soit correcte? »
+
+| Nº | Critère d'acceptation |
+| --- | --- |
+| AC-1 | La recherche renvoie des résultats pertinents pour une requête donnée |
+| AC-2 | Les résultats peuvent être filtrés par sujet |
+| AC-3 | Les résultats peuvent être triés par date |
+| AC-4 | La pagination fonctionne pour les ensembles de résultats volumineux |
+| AC-5 | Une recherche vide ou incohérente affiche un message approprié |
+
+Chaque critère peut être vérifié indépendamment, ce qui en fait une bonne base
+pour un test automatisé.
+
+### Exercice 3 : Créer les scénarios de test
+
+Associez un scénario à chaque critère. Le tableau relie les critères aux tests
+réels dans `ontario-search.spec.ts`. Les noms restent en anglais pour vous permettre
+de les retrouver dans le fichier.
+
+| Critère d'acceptation | Scénario de test | Nom du test dans le fichier |
+| --- | --- | --- |
+| AC-1 : Résultats de recherche | Vérifier les résultats pour « driver licence » | `search for driver licence returns results` |
+| AC-2 : Filtre par sujet | Appliquer un filtre et vérifier la mise à jour des résultats | `filter by topic narrows results` |
+| AC-3 : Tri par date | Choisir « Updated date » et vérifier le rechargement | `sort results by updated date` |
+| AC-4 : Pagination | Passer à la page 2 et vérifier la page active | `pagination navigates to next page` |
+| AC-5 : Recherche sans résultat | Saisir une requête incohérente et vérifier « 0 results » | `search with no results shows empty state` |
+
+Deux autres tests complètent les scénarios normaux :
+
+* `navigate to Ontario.ca search page` vérifie le chargement et le titre de la page
+* `search input field is visible and functional` vérifie que le champ accepte
+ de nouvelles requêtes
+
+### Exercice 4 : Prioriser les scénarios de test
+
+Classez les scénarios selon leur risque et leur incidence sur les utilisateurs :
+
+1. **Résultats de recherche** : risque le plus élevé, fonction principale
+2. **Filtre par sujet** : risque élevé, principal moyen d'affiner la recherche
+3. **Tri par date** : risque moyen, moyen secondaire d'affiner les résultats
+4. **Pagination** : risque moyen, nécessaire pour les longues listes
+5. **Recherche sans résultat** : risque moindre, mais incidence sur la confiance
+6. **Navigation de base** : risque moindre, fondation rarement défaillante seule
+7. **Champ de recherche** : risque moindre, vérification de présence dans l'interface
+
+Ce classement vous aide à décider où investir en premier lors de la création ou
+de la maintenance d'une suite de tests.
+
+### Exercice 5 : Discussion
+
+Réfléchissez au passage des cas de test manuels à l'automatisation :
+
+* Les critères d'acceptation restent les mêmes pour un test manuel ou automatisé.
+* L'automatisation permet de répéter les mêmes assertions à chaque modification.
+* Les tests manuels restent utiles pour les scénarios exploratoires difficiles à coder.
+* Le tableau de l'exercice 3 devient votre liste de travaux d'automatisation.
+
+> [!NOTE]
+> En entreprise, des outils comme
+> [Azure Test Plans](https://learn.microsoft.com/fr-fr/azure/devops/test/overview)
+> assurent la traçabilité des exigences jusqu'aux résultats d'exécution.
+> La démarche pratiquée ici s'applique aussi à ce processus.
+
+## Point de vérification
+
+Vous disposez de cinq à sept scénarios issus du récit utilisateur, chacun associé
+à un critère d'acceptation et à un test nommé dans le fichier de spécification.
+
+## Résumé
+
+La planification est la base de l'automatisation. Vous avez transformé un récit
+utilisateur en critères d'acceptation, relié ces critères à des scénarios concrets
+et classé les scénarios selon le risque. Le prochain labo les met en pratique avec
+Playwright.
+
+## Étape suivante
+
+Passez au [labo 02 : Votre premier test Playwright](../lab-02-playwright-basics/).
diff --git a/fr/labs/lab-02-playwright-basics/README.md b/fr/labs/lab-02-playwright-basics/README.md
new file mode 100644
index 0000000..7c72682
--- /dev/null
+++ b/fr/labs/lab-02-playwright-basics/README.md
@@ -0,0 +1,255 @@
+---
+layout: default
+title: "Labo 02 : Votre premier test Playwright"
+nav_order: 4
+description: "Exécuter, explorer et modifier des tests Playwright en pratique"
+permalink: /fr/labs/lab-02-playwright-basics/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 20 minutes |
+| **Niveau** | Débutant |
+| **Type** | Pratique |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, vous pourrez :
+
+* Exécuter des tests Playwright existants en ligne de commande
+* Comprendre la structure des tests : `describe`, `test`, `expect`
+* Modifier le comportement des tests et ajouter des assertions
+* Enregistrer des interactions avec Playwright Codegen
+* Déboguer les échecs avec Trace Viewer
+
+## Prérequis
+
+* Avoir terminé le [labo 00 : Prérequis](../lab-00-prerequisites/)
+* Avoir consulté le [labo 01 : Des récits utilisateurs aux cas de test](../lab-01-test-planning/)
+
+## Exercices
+
+### Exercice 1 : Exécuter les tests fournis
+
+Depuis la racine du dépôt, ouvrez un terminal et accédez au projet de tests :
+
+```bash
+cd playwright-tests
+npx playwright test
+```
+
+La suite contient sept scénarios normaux et deux tests `@failure-demo` qui échouent
+volontairement. Pour vérifier les scénarios normaux sans ces démonstrations :
+
+```bash
+npx playwright test --grep-invert @failure-demo
+```
+
+La sortie indique les noms des tests et leur durée. En cas d'erreur de dépendance
+ou de navigateur, reprenez le labo 00. Examinez séparément les échecs liés au site
+en ligne, dont le contenu peut changer.
+
+### Exercice 2 : Explorer la structure des tests
+
+Ouvrez `tests/ontario-search.spec.ts` dans VS Code. Ce fichier contient les
+scénarios associés aux critères du labo 01.
+
+#### Importations et regroupement
+
+Chaque fichier importe les outils de test et peut utiliser `test.describe()`
+pour regrouper les scénarios liés :
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('Ontario.ca Search', () => {
+});
+```
+
+#### Configuration commune avec beforeEach
+
+Le hook `test.beforeEach()` s'exécute avant chaque test du groupe. Ici, il ajoute
+un témoin de langue pour éviter la page de sélection de langue :
+
+```typescript
+test.beforeEach(async ({ context }) => {
+ await context.addCookies([{
+ name: 'lang',
+ value: 'en',
+ domain: '.ontario.ca',
+ path: '/'
+ }]);
+});
+```
+
+Les tests ciblent la version anglaise. Ne traduisez pas la valeur du témoin,
+les sélecteurs ni le texte attendu dans les assertions.
+
+#### Cas de test individuels
+
+Chaque bloc `test()` cible un scénario. Remarquez la fonction `async` et la fixture
+`{ page }` obtenue par déstructuration :
+
+```typescript
+test('search for driver licence returns results', async ({ page }) => {
+ await page.goto('/search?query=driver+licence');
+ await page.waitForSelector('h4 a');
+ await expect(page.locator('h3').filter({ hasText: /results/ })).toBeVisible();
+ await expect(page.locator('h4 a').first()).toBeVisible();
+});
+```
+
+#### Stratégies de localisation
+
+Playwright propose plusieurs façons de trouver les éléments :
+
+| Stratégie | Exemple | Utilisation |
+| --- | --- | --- |
+| Sélecteur CSS | `page.locator('h4 a')` | Cibler une balise, une classe ou un identifiant |
+| Filtre avec expression régulière | `page.locator('h3').filter({ hasText: /results/ })` | Réduire les correspondances selon le texte |
+| Texte du libellé | `page.getByLabel('Updated date (new to old)')` | Trouver des champs accessibles |
+| Localisateur chaîné | `page.locator('label').filter({ hasText: /driving/i }).first()` | Combiner les stratégies pour plus de précision |
+
+#### Assertions
+
+Les assertions Playwright attendent automatiquement que la condition soit remplie :
+
+| Assertion | Objectif |
+| --- | --- |
+| `toHaveTitle(/ontario/i)` | Le titre correspond au motif |
+| `toBeVisible()` | L'élément est présent et visible |
+| `toContainText('2')` | L'élément contient le texte attendu |
+
+### Exercice 3 : Modifier un test
+
+Dans `tests/ontario-search.spec.ts`, remplacez la requête du test
+`search for driver licence returns results` par une recherche de carte Santé :
+
+```typescript
+test('search for health card returns results', async ({ page }) => {
+ await page.goto('/search?query=health+card');
+ await page.waitForSelector('h4 a');
+ await expect(page.locator('h3').filter({ hasText: /results/ })).toBeVisible();
+ await expect(page.locator('h4 a').first()).toBeVisible();
+});
+```
+
+Relancez les tests pour vérifier le scénario modifié :
+
+```bash
+npx playwright test
+```
+
+> [!TIP]
+> Seuls la requête et le nom du test changent. Les localisateurs et les assertions
+> restent identiques, car la structure de la page ne dépend pas des mots recherchés.
+
+### Exercice 4 : Ajouter une assertion
+
+Renforcez le test en vérifiant que le premier lien contient un texte pertinent.
+Ajoutez cette ligne avant le `});` final :
+
+```typescript
+await expect(page.locator('h4 a').first()).toContainText('health');
+```
+
+Le test vérifie maintenant l'affichage des résultats, la visibilité du premier lien
+et la pertinence de son texte. Relancez-le pour vérifier la nouvelle assertion.
+
+La précision constitue un compromis. Une assertion générale comme `toBeVisible`
+est stable, mais détecte moins de défauts. Une assertion ciblée comme
+`toContainText('health')` détecte plus de problèmes, mais peut échouer si le contenu
+change. Adaptez la précision à votre connaissance du contenu de la page.
+
+### Exercice 5 : Utiliser Codegen
+
+Playwright Codegen enregistre vos interactions et génère le code correspondant :
+
+```bash
+npm run codegen
+```
+
+Une fenêtre Chromium s'ouvre sur la recherche Ontario.ca. Effectuez ces actions :
+
+1. Cliquez dans le champ de recherche.
+2. Effacez le texte et saisissez « birth certificate ».
+3. Appuyez sur Entrée.
+4. Cliquez sur le premier résultat.
+
+Codegen écrit le code Playwright dans une autre fenêtre. Copiez-le dans un nouveau
+bloc de test pour voir comment les interactions deviennent des appels de
+localisateur et des assertions.
+
+> [!NOTE]
+> Le code généré est un point de départ. Examinez les localisateurs et améliorez
+> leur stabilité. Préférez `getByLabel()` ou `filter({ hasText })` aux sélecteurs
+> CSS fragiles lorsque cela convient.
+
+### Exercice 6 : Déboguer avec Trace Viewer
+
+Trace Viewer présente la chronologie des actions, les captures d'écran, les
+instantanés du DOM et les requêtes réseau. Provoquez un échec pour l'explorer.
+
+#### Provoquer un échec
+
+Dans le test `search for health card returns results`, ajoutez une assertion
+de titre qui ne peut pas correspondre :
+
+ ```typescript
+ await expect(page).toHaveTitle(/nonexistent title/i);
+ ```
+
+#### Enregistrer la trace
+
+Exécutez les tests avec les traces activées :
+
+ ```bash
+ npx playwright test --trace on
+ ```
+
+ Le test échoue et Playwright enregistre une trace.
+
+#### Examiner la trace
+
+Ouvrez Trace Viewer avec le chemin de la trace du test concerné :
+
+ ```bash
+ npx playwright show-trace test-results/*/trace.zip
+ ```
+
+ Si plusieurs traces existent ou si votre terminal ne développe pas `*`, remplacez
+ le motif par le chemin exact d'un fichier `trace.zip`.
+
+ Explorez la chronologie :
+
+* Chaque action présente une capture avant et après son exécution.
+* Sélectionnez une étape pour examiner l'instantané du DOM.
+* L'onglet Network affiche les appels API effectués pendant le test.
+* L'onglet Console affiche les messages du navigateur.
+
+#### Rétablir l'assertion
+
+Remplacez l'assertion incorrecte par celle du titre attendu :
+
+ ```typescript
+ await expect(page).toHaveTitle(/ontario/i);
+ ```
+
+Relancez `npx playwright test` et vérifiez que votre test modifié réussit.
+Les tests `@failure-demo` restent volontairement en échec.
+
+## Point de vérification
+
+Votre test modifié réussit avec la recherche « health card » et l'assertion
+`toContainText('health')`. Vous avez enregistré une interaction avec Codegen et
+examiné un échec avec Trace Viewer.
+
+## Résumé
+
+Playwright propose des assertions avec attente automatique, plusieurs stratégies
+de localisation et un outil visuel de diagnostic. Ces fonctions facilitent la
+rédaction, la maintenance et le débogage des tests sans pauses arbitraires.
+
+## Étape suivante
+
+Passez au [labo 03 : GitHub Copilot pour les tests](../lab-03-copilot-testing/).
diff --git a/fr/labs/lab-03-copilot-testing/README.md b/fr/labs/lab-03-copilot-testing/README.md
new file mode 100644
index 0000000..e2cd12d
--- /dev/null
+++ b/fr/labs/lab-03-copilot-testing/README.md
@@ -0,0 +1,175 @@
+---
+layout: default
+title: "Labo 03 : GitHub Copilot pour les tests"
+nav_order: 5
+description: "Accélérer la rédaction de tests Playwright avec GitHub Copilot"
+permalink: /fr/labs/lab-03-copilot-testing/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 15 minutes |
+| **Niveau** | Intermédiaire |
+| **Type** | Pratique |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, vous pourrez :
+
+* Utiliser les suggestions en ligne de GitHub Copilot pour écrire des tests
+* Générer des scénarios complets avec Copilot Chat
+* Appliquer la technique des deux requêtes : le contexte, puis la demande
+* Vérifier et améliorer le code généré par l'IA
+
+## Prérequis
+
+* Avoir terminé le labo 02 avec un test modifié qui réussit
+* Avoir installé et activé GitHub Copilot dans VS Code
+
+> [!NOTE]
+> Sans abonnement Copilot, utilisez les exemples de code manuels fournis.
+> Vous pouvez réaliser tous les exercices sans génération assistée.
+
+## Exercices
+
+### Exercice 1 : Générer à partir d'un commentaire
+
+Ouvrez `playwright-tests/tests/ontario-search.spec.ts`. À la fin du bloc `describe`,
+commencez un nouveau test par un commentaire descriptif :
+
+```typescript
+// Vérifier qu'un clic sur un résultat ouvre la bonne page
+```
+
+Si Copilot est actif, une suggestion apparaît après le commentaire. Examinez-la
+avant de l'accepter. Vérifiez les sélecteurs par rapport aux éléments réels, par
+exemple `h4 a` pour les liens des résultats.
+
+Sans Copilot, saisissez ce test après le commentaire :
+
+```typescript
+test('clicking a search result navigates to the correct page', async ({ page }) => {
+ await page.goto('/search?query=driver+licence');
+ await page.waitForSelector('h4 a');
+ const firstResult = page.locator('h4 a').first();
+ const resultText = await firstResult.textContent();
+ await firstResult.click();
+ await expect(page).not.toHaveURL(/\/search/);
+ await expect(page.locator('h1, h2').first()).toBeVisible();
+});
+```
+
+### Exercice 2 : Fournir le contexte à Copilot Chat
+
+Ouvrez Copilot Chat (`Ctrl+Shift+I`) et envoyez ce contexte avant de demander du code :
+
+```text
+Ce fichier teste ontario.ca/search avec Playwright. La page est une application
+React monopage avec un champ de recherche (#search-input-field), des cases à cocher
+pour les sujets, des boutons radio pour le tri et une pagination (.rc-pagination).
+Les tests ciblent la version anglaise du site : conserve les sélecteurs et les
+textes attendus en anglais.
+```
+
+Copilot dispose maintenant du contexte pour la demande suivante. Sans Copilot,
+utilisez cette description comme référence pour écrire le test.
+
+### Exercice 3 : Demander la génération d'un test
+
+Dans la même conversation, envoyez cette demande :
+
+```text
+Génère un test Playwright qui vérifie que le nombre de résultats diminue après
+l'application d'un filtre par sujet.
+```
+
+Copilot propose un test à partir des sélecteurs du contexte. Ajoutez le code dans
+le bloc `describe` de `ontario-search.spec.ts`.
+
+Sans Copilot, ajoutez ce test manuellement :
+
+```typescript
+test('topic filter decreases result count', async ({ page }) => {
+ await page.goto('/search?query=driver+licence');
+ await page.waitForSelector('h4 a');
+
+ const resultsHeader = page.locator('h3').filter({ hasText: /results/ });
+ const beforeText = await resultsHeader.textContent();
+ const beforeCount = parseInt(beforeText?.match(/\d+/)?.[0] ?? '0');
+
+ await page.locator('label').filter({ hasText: /driving/i }).first().click();
+ await page.locator('#filterSortApply').click();
+ await page.waitForSelector('h4 a');
+
+ const afterText = await resultsHeader.textContent();
+ const afterCount = parseInt(afterText?.match(/\d+/)?.[0] ?? '0');
+
+ expect(afterCount).toBeLessThan(beforeCount);
+});
+```
+
+### Exercice 4 : Vérifier le résultat
+
+Depuis la racine du dépôt, exécutez les tests :
+
+```bash
+cd playwright-tests
+npx playwright test
+```
+
+Examinez en particulier le nouveau test. Les deux tests `@failure-demo` échouent
+volontairement et ne constituent pas des défauts du code généré.
+
+Les problèmes courants du code généré comprennent :
+
+* Des sélecteurs qui ne correspondent pas au DOM réel
+* Des attentes manquantes avant d'interagir avec le contenu dynamique
+* Des assertions qui vérifient le mauvais élément ou la mauvaise propriété
+* Des valeurs fixes qui ne résistent pas aux changements de contenu
+
+### Exercice 5 : Améliorer le test
+
+Si le nouveau test échoue, apportez des corrections ciblées :
+
+1. Comparez les sélecteurs aux éléments réels avec les outils de développement
+ du navigateur (`F12`) sur Ontario.ca/search.
+2. Ajoutez les attentes nécessaires là où Copilot a supposé un rendu immédiat.
+3. Ajustez les assertions pour vérifier le comportement réel de la page.
+
+Relancez les tests après chaque correction :
+
+```bash
+npx playwright test
+```
+
+Continuez jusqu'à ce que le nouveau test réussisse. Distinguez toujours les échecs
+du site en ligne et les démonstrations intentionnelles.
+
+### Exercice 6 : Discussion
+
+Discutez de ces questions en équipe :
+
+* Dans quelles situations pouvez-vous utiliser le code de Copilot sans modification?
+* Quelles parties exigent le plus d'attention? Les sélecteurs, les attentes et les
+ assertions sont des sources fréquentes d'échec.
+* Comment le contexte de l'exercice 2 améliore-t-il le code par rapport à une
+ demande sans contexte?
+
+## Point de vérification
+
+Au moins un nouveau test généré par Copilot ou rédigé manuellement réussit aux
+côtés des scénarios existants. Vous pouvez expliquer ses sélecteurs, ses attentes
+et ses assertions, et distinguer les échecs `@failure-demo`.
+
+## Résumé
+
+GitHub Copilot accélère la rédaction en proposant du code et des scénarios complets.
+La technique des deux requêtes, contexte puis demande, améliore la pertinence des
+suggestions. Vérifiez toujours le DOM réel, le rendu dynamique et le comportement
+couvert par chaque assertion.
+
+## Étape suivante
+
+Passez au [labo 04 : Pipeline CI/CD (GitHub Actions)](../lab-04-ci-pipeline/) ou au
+[labo 04 : Pipeline CI/CD (Azure DevOps)](../lab-04-ci-pipeline-ado/), selon
+l'emplacement de votre dépôt.
diff --git a/fr/labs/lab-04-ci-pipeline-ado/README.md b/fr/labs/lab-04-ci-pipeline-ado/README.md
new file mode 100644
index 0000000..fc64109
--- /dev/null
+++ b/fr/labs/lab-04-ci-pipeline-ado/README.md
@@ -0,0 +1,191 @@
+---
+layout: default
+title: "Labo 04 : Pipeline CI/CD (Azure DevOps)"
+nav_order: 7
+description: "Exécuter en parallèle les tests Playwright fonctionnels et d'accessibilité avec Azure Pipelines"
+permalink: /fr/labs/lab-04-ci-pipeline-ado/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 15 minutes |
+| **Niveau** | Débutant |
+| **Type** | Démonstration et configuration |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, vous pourrez :
+
+* Comprendre les concepts CI/CD appliqués aux tests automatisés
+* Lire et modifier un pipeline YAML Azure DevOps
+* Exécuter les suites fonctionnelle et d'accessibilité dans des tâches matricielles indépendantes
+* Créer un pipeline Azure DevOps à partir d'un fichier YAML existant
+* Consulter les résultats et les artefacts dans Azure DevOps
+* Choisir les déclencheurs : push, demande de tirage ou planification
+
+## Prérequis
+
+* Avoir terminé le labo 03
+* Disposer d'une organisation et d'un projet Azure DevOps
+* Avoir le droit de pousser dans le dépôt Azure DevOps ou GitHub utilisé
+
+> [!NOTE]
+> Choisissez [GitHub Actions](../lab-04-ci-pipeline/) pour l'autre parcours CI.
+> Azure Pipelines peut aussi utiliser un dépôt GitHub.
+
+## Exercices
+
+### Exercice 1 : Examiner le pipeline
+
+Ouvrez [.azuredevops/pipelines/playwright-tests.yml](https://github.com/devopsabcs-engineering/playwright-101/blob/main/.azuredevops/pipelines/playwright-tests.yml)
+dans VS Code. Examinez cette matrice extraite du pipeline complet :
+
+```yaml
+jobs:
+ - job: Playwright
+ displayName: 'Playwright tests'
+ strategy:
+ maxParallel: 2
+ matrix:
+ Functional:
+ suite: 'functional'
+ junitPath: 'test-results/junit.xml'
+ reportPath: 'playwright-report'
+ resultsPath: 'test-results'
+ Accessibility:
+ suite: 'accessibility'
+ junitPath: 'test-results/accessibility/junit.xml'
+ reportPath: 'playwright-report/accessibility'
+ resultsPath: 'test-results/accessibility'
+```
+
+Chaque entrée s'exécute indépendamment sur un agent Ubuntu. `maxParallel: 2`
+autorise deux exécutions simultanées selon la capacité de votre organisation.
+Avec un seul emplacement disponible, les tâches se mettent en file d'attente.
+
+Lisez les étapes qui suivent la matrice dans le pipeline complet :
+
+* `UseNode@1` installe Node.js 20 et `npm install` installe les dépendances de test.
+* Playwright installe Chromium et ses dépendances système.
+* `npm run test:$(suite)` choisit la configuration fonctionnelle ou d'accessibilité.
+* `PLAYWRIGHT_SCREENSHOT: 'on'` capture chaque test; la configuration commune
+ enregistre les traces lors de la première nouvelle tentative.
+* `PublishTestResults@2` publie `$(junitPath)` sous le titre `Playwright $(suite)`.
+ Des tests en échec ou un rapport JUnit absent font échouer cette étape.
+* `PublishPipelineArtifact@1` publie les rapports et résultats propres à chaque
+ suite avec `condition: succeededOrFailed()`, afin de préserver les preuves
+ générées même après un échec.
+
+> [!IMPORTANT]
+> Le déclencheur YAML `pr` s'applique aux dépôts GitHub. Pour Azure Repos Git,
+> configurez une stratégie de validation de build sur `main` pour les PR.
+> La section `trigger` lance les builds lors des push vers `main` dans les deux cas.
+
+### Exercice 2 : Créer le pipeline dans Azure DevOps
+
+Si le pipeline n'existe pas encore dans votre projet :
+
+1. Ouvrez le projet et sélectionnez **Pipelines > New pipeline**.
+2. Choisissez l'emplacement du code, Azure Repos Git ou GitHub.
+3. Sélectionnez votre dépôt.
+4. Choisissez **Existing Azure Pipelines YAML file**.
+5. Sélectionnez la branche `main` et le chemin
+ `/.azuredevops/pipelines/playwright-tests.yml`.
+6. Examinez le YAML, puis sélectionnez **Run** pour enregistrer et lancer le pipeline.
+
+### Exercice 3 : Pousser une modification
+
+Ajoutez une instruction `console.log` à un test pour vérifier le déclenchement :
+
+```typescript
+test('navigate to Ontario.ca search page', async ({ page }) => {
+ console.log('CI pipeline verification');
+ await page.goto('/search?query=driver+licence');
+ await expect(page).toHaveTitle(/ontario/i);
+});
+```
+
+Créez un commit et poussez depuis la branche de votre élément de travail.
+Remplacez `1234` par l'identifiant du récit utilisateur ou du bogue, rattaché à
+une fonctionnalité (Feature) et à une épopée (Epic), puis ouvrez une PR vers `main` :
+
+```bash
+git add playwright-tests/tests/ontario-search.spec.ts
+git commit -m "test: verify parallel CI suites AB#1234"
+git push -u origin HEAD
+```
+
+### Exercice 4 : Suivre le pipeline
+
+1. Ouvrez votre projet Azure DevOps et sélectionnez **Pipelines**.
+2. Trouvez l'exécution déclenchée par votre PR, avec le déclencheur ou la stratégie
+ de branche appropriée.
+3. Consultez les tâches **Functional** et **Accessibility** ainsi que leurs journaux.
+
+Le pipeline installe Node.js, exécute les tests, publie leurs résultats et charge
+les artefacts. Chaque étape possède son propre journal.
+
+### Exercice 5 : Consulter les résultats
+
+Après l'exécution :
+
+1. Vérifiez le statut global : réussite en vert ou échec en rouge.
+2. Ouvrez **Tests** pour consulter les nombres, les durées et les détails des
+ échecs issus du rapport JUnit.
+3. Dans **Artifacts**, retrouvez les sorties des deux suites :
+
+| Suite | Rapport HTML | JUnit, captures et traces |
+| --- | --- | --- |
+| Fonctionnelle | `playwright-report-functional` | `test-results-functional` |
+| Accessibilité | `playwright-report-accessibility` | `test-results-accessibility` |
+
+### Exercice 6 : Ouvrir le rapport HTML
+
+1. Téléchargez et extrayez un artefact de rapport HTML.
+2. Depuis `playwright-tests`, exécutez `npx playwright show-report `
+ en remplaçant le paramètre par le répertoire extrait.
+3. Explorez les noms, les durées, les statuts et les captures de chaque test,
+ activées par `PLAYWRIGHT_SCREENSHOT=on` dans le pipeline.
+
+Ces rapports correspondent aux commandes locales `npm run test:functional` et
+`npm run test:accessibility`. Chaque rapport ne contient que sa propre suite.
+
+### Exercice 7 : Discussion
+
+Discutez de ces stratégies :
+
+* Ajouter une stratégie de validation de build sur `main` qui exige la réussite du
+ pipeline avant la fusion d'une PR pour limiter les régressions.
+* Ajouter un déclencheur `schedules` (`cron: '0 2 * * *'`) pour détecter la nuit
+ les changements du site ou des dépendances externes.
+* Étendre la matrice à Chromium, Firefox et WebKit pour vérifier la compatibilité,
+ en ajoutant les projets et les installations de navigateurs correspondants.
+
+## Point de vérification
+
+Les deux tâches terminent, l'onglet **Tests** contient des exécutions distinctes
+et les quatre artefacts sont disponibles lorsque les tests s'exécutent. Utilisez
+les preuves de la suite concernée pour diagnostiquer les échecs du site en ligne.
+
+Les tests fonctionnels `@failure-demo` échouent volontairement pour pratiquer le
+diagnostic. Ils peuvent rendre la tâche rouge même si les scénarios normaux
+réussissent. La tâche d'accessibilité doit terminer indépendamment.
+
+## Résumé
+
+Les pipelines CI/CD exécutent les tests à chaque modification sans intervention
+manuelle. Ils automatisent l'installation du navigateur, l'exécution et les
+rapports dans un environnement propre pour détecter les régressions.
+
+## Étape suivante
+
+Continuez avec le [labo 05 : Tests d'accessibilité](../lab-05-accessibility/) pour
+explorer axe, diagnostiquer les violations et pratiquer les vérifications manuelles.
+Ce complément facultatif de 20 minutes suit le parcours principal d'une heure.
+
+### Pour approfondir
+
+* [Documentation Playwright](https://playwright.dev)
+* [Microsoft Learn : tests de bout en bout avec Playwright](https://learn.microsoft.com/fr-fr/training/modules/build-with-playwright/)
+* [Documentation Azure Pipelines](https://learn.microsoft.com/fr-fr/azure/devops/pipelines/)
+* [Azure Test Plans](https://learn.microsoft.com/fr-fr/azure/devops/test/overview)
diff --git a/fr/labs/lab-04-ci-pipeline/README.md b/fr/labs/lab-04-ci-pipeline/README.md
new file mode 100644
index 0000000..504ae92
--- /dev/null
+++ b/fr/labs/lab-04-ci-pipeline/README.md
@@ -0,0 +1,181 @@
+---
+layout: default
+title: "Labo 04 : Pipeline CI/CD (GitHub Actions)"
+nav_order: 6
+description: "Exécuter en parallèle les tests Playwright fonctionnels et d'accessibilité avec GitHub Actions"
+permalink: /fr/labs/lab-04-ci-pipeline/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 15 minutes |
+| **Niveau** | Débutant |
+| **Type** | Démonstration et configuration |
+
+## Objectifs d'apprentissage
+
+À la fin de ce labo, vous pourrez :
+
+* Comprendre les concepts CI/CD appliqués aux tests automatisés
+* Lire et modifier un workflow GitHub Actions
+* Exécuter les suites fonctionnelle et d'accessibilité dans des tâches matricielles indépendantes
+* Consulter les résultats et les artefacts dans GitHub
+* Choisir les déclencheurs : push, demande de tirage ou planification
+
+## Prérequis
+
+* Avoir terminé le labo 03
+* Avoir le droit de pousser des modifications dans le dépôt GitHub
+
+## Exercices
+
+### Exercice 1 : Examiner le workflow
+
+Ouvrez [.github/workflows/playwright-tests.yml](https://github.com/devopsabcs-engineering/playwright-101/blob/main/.github/workflows/playwright-tests.yml)
+dans VS Code. Le workflow se déclenche lors des push et des demandes de tirage
+(PR) ciblant `main`. Il permet aussi une exécution manuelle avec **Run workflow**.
+Examinez cette matrice extraite du workflow complet :
+
+{% raw %}
+
+```yaml
+jobs:
+ test:
+ name: Playwright ${{ matrix.suite }}
+ runs-on: ubuntu-latest
+ strategy:
+ fail-fast: false
+ max-parallel: 2
+ matrix:
+ include:
+ - suite: functional
+ junitPath: test-results/junit.xml
+ reportPath: playwright-report
+ resultsPath: test-results
+ - suite: accessibility
+ junitPath: test-results/accessibility/junit.xml
+ reportPath: playwright-report/accessibility
+ resultsPath: test-results/accessibility
+```
+
+Chaque entrée dispose de son propre agent Ubuntu. `max-parallel: 2` autorise deux
+exécutions simultanées si la capacité est disponible. `fail-fast: false` permet
+à une suite de terminer même si l'autre échoue. Aucune suite ne dépend de l'autre.
+
+Lisez les étapes qui suivent la matrice dans le workflow complet :
+
+* La récupération du code et l'installation de Node.js 24 préparent chaque agent.
+* `npm ci` installe les dépendances verrouillées dans `playwright-tests`.
+* `npx playwright install --with-deps chromium` installe le navigateur.
+* `npm run test:${{ matrix.suite }}` choisit la configuration de la suite.
+* `PLAYWRIGHT_SCREENSHOT: 'on'` capture chaque test; la configuration commune
+ enregistre les traces lors de la première nouvelle tentative.
+* Le script de résumé lit `JUNIT_PATH` dans la matrice et publie les nombres et
+ les détails des tests dans le résumé de la tâche. Un fichier JUnit absent fait
+ échouer cette étape.
+* Les étapes de publication utilisent `if: always()` pour conserver le rapport
+ HTML, le XML JUnit, les captures et les traces même après un échec, si ces
+ fichiers ont été générés. Un chemin d'artefact absent fait échouer la publication.
+ Les artefacts sont conservés pendant 30 jours.
+
+{% endraw %}
+
+### Exercice 2 : Pousser une modification
+
+Ajoutez une instruction `console.log` à un test pour vérifier le déclenchement :
+
+```typescript
+test('navigate to Ontario.ca search page', async ({ page }) => {
+ console.log('CI pipeline verification');
+ await page.goto('/search?query=driver+licence');
+ await expect(page).toHaveTitle(/ontario/i);
+});
+```
+
+Créez un commit et poussez depuis la branche de votre élément de travail.
+Remplacez `1234` par l'identifiant du récit utilisateur ou du bogue, rattaché à
+une fonctionnalité (Feature) et à une épopée (Epic), puis ouvrez une PR vers `main` :
+
+```bash
+git add playwright-tests/tests/ontario-search.spec.ts
+git commit -m "test: verify parallel CI suites AB#1234"
+git push -u origin HEAD
+```
+
+Vous pouvez aussi sélectionner **Actions > Playwright Tests > Run workflow** pour
+exécuter le workflow sur `main` sans modifier un test, une fois le workflow fusionné.
+
+### Exercice 3 : Suivre le pipeline
+
+1. Ouvrez votre dépôt dans GitHub.
+2. Sélectionnez l'onglet **Actions**.
+3. Trouvez l'exécution déclenchée par votre PR ou votre lancement manuel.
+4. Vérifiez les tâches **Playwright functional** et **Playwright accessibility**.
+5. Ouvrez chaque tâche pour consulter ses étapes et ses journaux indépendamment.
+
+Le workflow récupère le code, installe les dépendances et le navigateur, exécute
+les tests et publie les artefacts. Chaque étape possède son propre journal.
+
+### Exercice 4 : Consulter les résultats
+
+Après l'exécution :
+
+1. Vérifiez le statut global : réussite en vert ou échec en rouge.
+2. Lisez le résumé de chaque tâche pour ses nombres de tests et ses échecs.
+3. Dans **Artifacts**, retrouvez les quatre artefacts propres aux suites :
+
+| Suite | Rapport HTML | JUnit, captures et traces |
+| --- | --- | --- |
+| Fonctionnelle | `playwright-report-functional` | `test-results-functional` |
+| Accessibilité | `playwright-report-accessibility` | `test-results-accessibility` |
+
+### Exercice 5 : Ouvrir le rapport HTML
+
+1. Téléchargez et extrayez un artefact de rapport HTML.
+2. Depuis `playwright-tests`, exécutez `npx playwright show-report `
+ en remplaçant le paramètre par le répertoire extrait.
+3. Explorez les noms, les durées, les statuts et les captures des tests en échec
+ lorsqu'elles sont configurées.
+
+Ces rapports correspondent aux commandes locales `npm run test:functional` et
+`npm run test:accessibility`. Chaque rapport ne contient que sa propre suite.
+
+### Exercice 6 : Discussion
+
+Discutez de ces stratégies :
+
+* Exiger les deux vérifications dans une règle de protection ou un ensemble de
+ règles sur `main`. Le workflow seul ne bloque pas les fusions.
+* Ajouter un déclencheur `schedule` nocturne pour détecter les changements du site externe.
+* Étendre la matrice à d'autres navigateurs après avoir ajouté leurs projets et
+ leurs étapes d'installation.
+
+## Point de vérification
+
+Les deux tâches terminent, chacune possède un résumé et les quatre artefacts
+sont disponibles lorsque les tests s'exécutent. En cas d'échec du site en ligne,
+identifiez la suite concernée et examinez son rapport au lieu de supposer que
+tous les tests doivent réussir.
+
+La suite fonctionnelle contient des tests `@failure-demo` volontairement en échec
+pour pratiquer le diagnostic. Ils peuvent rendre la tâche rouge même si les
+scénarios normaux réussissent. La tâche d'accessibilité doit terminer indépendamment.
+
+## Résumé
+
+Les pipelines CI/CD exécutent les tests à chaque modification sans intervention
+manuelle. Le workflow automatise l'installation du navigateur, les tests et les
+rapports dans un environnement propre pour détecter les régressions avant la production.
+
+## Étape suivante
+
+Continuez avec le [labo 05 : Tests d'accessibilité](../lab-05-accessibility/) pour
+explorer axe, diagnostiquer les violations et pratiquer les vérifications manuelles.
+Ce complément facultatif de 20 minutes suit le parcours principal d'une heure.
+
+### Pour approfondir
+
+* [Documentation Playwright](https://playwright.dev)
+* [Microsoft Learn : tests de bout en bout avec Playwright](https://learn.microsoft.com/fr-fr/training/modules/build-with-playwright/)
+* [Documentation GitHub Actions](https://docs.github.com/fr/actions)
+* [Azure Test Plans](https://learn.microsoft.com/fr-fr/azure/devops/test/overview)
diff --git a/fr/labs/lab-05-accessibility/README.md b/fr/labs/lab-05-accessibility/README.md
new file mode 100644
index 0000000..bf113a4
--- /dev/null
+++ b/fr/labs/lab-05-accessibility/README.md
@@ -0,0 +1,188 @@
+---
+layout: default
+title: "Labo 05 : Tests d'accessibilité"
+nav_order: 8
+description: "Exécuter des analyses axe avec Playwright, examiner les constats WCAG et comparer les résultats CI"
+permalink: /fr/labs/lab-05-accessibility/
+---
+
+| | |
+| --- | --- |
+| **Durée** | 20 minutes (complément à l'atelier d'une heure) |
+| **Niveau** | Débutant |
+| **Type** | Pratique et examen des rapports |
+
+## Objectifs d'apprentissage
+
+* Exécuter séparément les suites fonctionnelle et d'accessibilité
+* Analyser les états de page avec les règles axe associées aux WCAG 2.1, niveaux A et AA
+* Examiner les violations à partir des identifiants de règle, des éléments et des pièces jointes
+* Comparer les tâches CI indépendantes et reconnaître les vérifications manuelles nécessaires
+
+## Prérequis
+
+* Terminez le labo 02 et le parcours [GitHub Actions](../lab-04-ci-pipeline/) ou
+ [Azure DevOps](../lab-04-ci-pipeline-ado/) pour l'exercice CI.
+* Installez Node.js 20 ou une version ultérieure et Chromium avec les commandes ci-dessous.
+* Disposez d'un accès réseau à Ontario.ca. Aucun compte n'est requis pour les pages testées.
+
+> [!IMPORTANT]
+> Les analyses automatisées détectent certains problèmes, mais ne couvrent pas
+> toutes les exigences WCAG. Une analyse réussie ne prouve ni la conformité WCAG
+> ni la conformité juridique. Les vérifications au clavier, au lecteur d'écran,
+> au zoom et les autres tests manuels restent nécessaires.
+
+## Exercices
+
+### Exercice 1 : Exécuter la suite d'accessibilité
+
+Depuis la racine du dépôt :
+
+```bash
+cd playwright-tests
+npm ci
+npx playwright install --with-deps chromium
+npm run test:accessibility
+```
+
+Le projet inclut déjà `@axe-core/playwright`. La commande utilise
+[playwright.accessibility.config.ts](https://github.com/devopsabcs-engineering/playwright-101/blob/main/playwright-tests/playwright.accessibility.config.ts),
+qui reprend l'URL de base, le projet Chromium, les paramètres de capture et les
+traces de nouvelle tentative de la configuration fonctionnelle. Elle change le
+répertoire de tests, le délai maximal et les chemins de rapports.
+
+Comparez les deux suites :
+
+| Suite | Commande | Répertoire de tests | Rapport HTML | XML JUnit |
+| --- | --- | --- | --- | --- |
+| Fonctionnelle | `npm run test:functional` | `tests` | `playwright-report` | `test-results/junit.xml` |
+| Accessibilité | `npm run test:accessibility` | `accessibility-tests` | `playwright-report/accessibility` | `test-results/accessibility/junit.xml` |
+
+`npm test` et `npx playwright test` choisissent la configuration fonctionnelle par
+défaut; ils n'exécutent pas les deux suites. En local, lancez d'abord les tests
+fonctionnels, puis ceux d'accessibilité. Les sorties d'accessibilité se trouvent
+dans les répertoires de sortie fonctionnels; une exécution fonctionnelle ultérieure
+peut donc effacer les résultats d'accessibilité précédents. La CI évite ces
+collisions avec des agents distincts.
+
+### Exercice 2 : Lire l'analyse
+
+Ouvrez [ontario-accessibility.spec.ts](https://github.com/devopsabcs-engineering/playwright-101/blob/main/playwright-tests/accessibility-tests/ontario-accessibility.spec.ts).
+Repérez les trois scénarios :
+
+| État de page | Vérification avant l'analyse |
+| --- | --- |
+| Accueil anglais | Le titre de niveau 1 est visible |
+| Résultats de recherche présents | Le premier lien de résultat est visible |
+| Aucun résultat | Le titre contenant `0 results` est visible |
+
+Le témoin de langue anglaise évite la page de sélection de langue. Chaque assertion
+vérifie que l'état attendu est affiché avant l'analyse axe. Conservez ces valeurs
+anglaises dans les tests. L'analyse utilise la chaîne suivante :
+
+```typescript
+const results = await new AxeBuilder({ page })
+ .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
+ .analyze();
+```
+
+Ces étiquettes sélectionnent les règles pertinentes des WCAG 2.0 et 2.1, niveaux
+A et AA. Elles n'activent pas toutes les règles axe ni tous les critères WCAG.
+Le test joint le résultat JSON complet sous le nom `axe-results` avant de vérifier
+que la liste des violations est vide.
+
+### Exercice 3 : Examiner et classer les résultats
+
+Depuis `playwright-tests`, ouvrez le rapport HTML d'accessibilité :
+
+```bash
+npx playwright show-report playwright-report/accessibility
+```
+
+1. Choisissez un test et examinez son statut, sa capture et la pièce jointe
+ `axe-results`. Par défaut, les captures locales concernent les échecs; la CI
+ capture chaque test.
+2. Pour une violation, relevez l'identifiant de règle, l'incidence, le lien d'aide,
+ les sélecteurs `target` et le `failureSummary` dans l'assertion ou le JSON.
+3. Inspectez l'élément de la page. Distinguez un problème du site d'un échec de
+ navigation ou de préparation ayant empêché l'analyse.
+4. Examinez les résultats `incomplete` qui exigent un jugement humain. L'assertion
+ actuelle échoue sur `violations`, et non sur `incomplete`.
+5. Relancez un scénario pour vérifier le constat :
+
+```bash
+npm run test:accessibility -- --grep "populated search results"
+```
+
+Si l'analyse réussit, examinez `passes` et `incomplete`, puis décrivez une règle
+vérifiée. Ne provoquez pas artificiellement une erreur sur le site en ligne.
+
+Ontario.ca est un site public hors du contrôle de ce dépôt. Signalez les constats
+avec des étapes reproductibles et des preuves. Ne désactivez pas les règles et
+n'excluez pas les éléments concernés uniquement pour obtenir une réussite.
+Pour une application qui vous appartient, corrigez le balisage ou l'interaction
+à la source, puis répétez l'analyse.
+
+### Exercice 4 : Comparer les résultats CI en parallèle
+
+Ouvrez une exécution du labo 04 :
+
+* Dans GitHub Actions, examinez **Playwright functional**, **Playwright accessibility**
+ et leurs résumés. `fail-fast: false` empêche l'échec d'une tâche d'annuler l'autre.
+* Dans Azure DevOps, examinez **Functional**, **Accessibility** et l'onglet **Tests**
+ avec les exécutions distinctes `Playwright functional` et `Playwright accessibility`.
+ La capacité disponible détermine si les tâches démarrent simultanément.
+
+Les deux plateformes publient les mêmes noms d'artefacts :
+
+| Suite | Rapport HTML | Résultats bruts |
+| --- | --- | --- |
+| Fonctionnelle | `playwright-report-functional` | `test-results-functional` |
+| Accessibilité | `playwright-report-accessibility` | `test-results-accessibility` |
+
+Téléchargez et extrayez le rapport HTML d'accessibilité, puis exécutez
+`npx playwright show-report ` avec le chemin extrait.
+Vérifiez la pièce jointe axe. Les résultats bruts comprennent le XML JUnit, les
+captures et les traces lorsqu'ils ont été générés. Les traces sont enregistrées
+à la première nouvelle tentative; une réussite dès le premier essai n'en produit pas.
+
+Une réussite fonctionnelle et un échec d'accessibilité sont des constats indépendants.
+Les deux suites doivent réussir pour que la CI soit verte. Configurez séparément
+la protection de branche ou la stratégie de validation ADO pour bloquer les fusions.
+
+La suite fonctionnelle comprend des tests `@failure-demo` intentionnels.
+Distinguez-les des échecs réels; ils n'annulent pas la tâche d'accessibilité.
+
+### Exercice 5 : Ajouter une couverture manuelle
+
+Sur la page de recherche, notez le comportement attendu et observé pour ces contrôles :
+
+* Naviguez avec Tab et Maj+Tab. Vérifiez la visibilité du focus, l'ordre logique
+ et l'absence de pièges au clavier.
+* Lancez une recherche au clavier et vérifiez que vous pouvez atteindre les résultats.
+* Avec un lecteur d'écran, vérifiez le nom accessible du champ, les titres, les
+ régions et les annonces lors du changement des résultats.
+* Vérifiez le texte à 200 % de zoom et la redistribution sur une largeur de
+ 320 pixels CSS, souvent obtenue à 400 % sur une fenêtre de 1280 pixels.
+ Recherchez les pertes de contenu ou de commandes.
+
+Pour la traçabilité ADO, associez chaque critère d'acceptation à au moins un cas de
+test dans une suite statique sous un plan de test. Référencez l'identifiant AC,
+reliez le cas au récit utilisateur avec `Tests`, puis vérifiez le lien inverse
+`Tested By`. Appliquez l'étiquette `Agentic AI` au plan, à la suite et aux cas.
+Une exécution JUnit en CI ne crée pas à elle seule cette couverture des critères.
+
+## Point de vérification
+
+* Les trois scénarios s'exécutent, ou vous identifiez précisément le blocage
+ d'environnement ou de préparation de page.
+* Vous retrouvez le rapport HTML d'accessibilité, le XML JUnit et la pièce jointe axe.
+* Vous expliquez un résultat d'analyse et un contrôle exigeant une vérification manuelle.
+* Les deux suites CI publient des résultats indépendants, y compris les preuves d'échec.
+
+## Ressources
+
+* [Tests d'accessibilité Playwright](https://playwright.dev/docs/accessibility-testing)
+* [Intégration axe-core pour Playwright](https://www.npmjs.com/package/@axe-core/playwright)
+* [WCAG 2.1](https://www.w3.org/TR/WCAG21/)
+* [Vérifications rapides WAI](https://www.w3.org/WAI/test-evaluate/easy-checks/)
diff --git a/labs/lab-00-prerequisites/README.md b/labs/lab-00-prerequisites/README.md
index cfe7ee9..a8b7250 100644
--- a/labs/lab-00-prerequisites/README.md
+++ b/labs/lab-00-prerequisites/README.md
@@ -88,18 +88,28 @@ Run the test suite to confirm everything is configured correctly:
npx playwright test
```
-All tests should pass. A successful run produces output showing each test with a green
-checkmark.
+The suite includes seven normal scenarios and two intentional `@failure-demo`
+tests for practicing failure investigation. To check only the normal scenarios:
+
+```bash
+npx playwright test --grep-invert @failure-demo
+```
+
+Tests target the English version of Ontario.ca. Keep English strings in the code.
+The live site can change; distinguish setup errors from assertion failures before
+changing your environment.
## Verification Checkpoint
-All 7 Playwright tests pass in the terminal. If any test fails, review the exercises
-above and confirm each step completed successfully.
+The seven normal scenarios start without dependency or browser errors. Investigate
+any live-site failures separately from the two intentional demonstrations. For
+setup errors, revisit the relevant exercise above.
## Summary
-Your development environment is ready for the workshop. You have Node.js, VS Code
-with the required extensions, Playwright browsers, and a passing test suite.
+Your development environment includes Node.js, VS Code with the required
+extensions, and Chromium for Playwright. You can run the suite and recognize
+intentional failures.
## Next Steps
diff --git a/labs/lab-02-playwright-basics/README.md b/labs/lab-02-playwright-basics/README.md
index eca7967..05299ff 100644
--- a/labs/lab-02-playwright-basics/README.md
+++ b/labs/lab-02-playwright-basics/README.md
@@ -38,8 +38,15 @@ cd playwright-tests
npx playwright test
```
-All 7 tests should pass. The output shows each test name with a green checkmark and
-the total execution time. If any test fails, revisit Lab 00 to confirm your setup.
+The suite includes seven normal scenarios and two intentional `@failure-demo`
+tests. To check the normal scenarios without those demonstrations:
+
+```bash
+npx playwright test --grep-invert @failure-demo
+```
+
+The output shows test names and execution times. Revisit Lab 00 for dependency or
+browser errors; investigate live-site assertion failures separately.
### Exercise 2: Explore Test Structure
@@ -220,7 +227,8 @@ again:
await expect(page).toHaveTitle(/ontario/i);
```
-Run `npx playwright test` to confirm all tests pass.
+Run `npx playwright test` to confirm your modified test passes. The `@failure-demo`
+tests remain intentionally failing.
## Verification Checkpoint
diff --git a/labs/lab-04-ci-pipeline/README.md b/labs/lab-04-ci-pipeline/README.md
index a9294b2..5f89784 100644
--- a/labs/lab-04-ci-pipeline/README.md
+++ b/labs/lab-04-ci-pipeline/README.md
@@ -63,7 +63,7 @@ one suite finish even if the other fails. Neither suite depends on the other.
Read the steps below the matrix in the full workflow:
-* Checkout and Node.js 20 setup prepare each runner.
+* Checkout and Node.js 24 setup prepare each runner.
* `npm ci` installs locked dependencies in `playwright-tests`.
* `npx playwright install --with-deps chromium` installs the browser.
* `npm run test:${{ matrix.suite }}` selects the functional or accessibility config.