Automatiser des tâches web sans créer un script fragile

Quand j’ai écrit la première version de cet article, je présentais une extension Firefox basée sur Selenium IDE. L’idée reste valable : une tâche répétée dans un navigateur mérite parfois d’être automatisée. L’outil et la méthode ont changé.

Je commence maintenant par une question simple : cette action doit-elle vraiment passer par un navigateur ?

Chercher une API avant de piloter une page

Une API est généralement plus stable qu’une suite de clics. Si le service permet d’exporter un rapport, créer une ressource ou mettre à jour un enregistrement par API, je choisis cette voie.

J’utilise le navigateur lorsque je teste le parcours réel d’un utilisateur ou quand aucune interface programmée n’existe. Je vérifie aussi les conditions d’utilisation du service. Automatiser la création de faux comptes, l’envoi de messages non sollicités ou le contournement d’une limite reste une mauvaise utilisation, même si le script fonctionne.

Choisir Playwright ou Selenium

Pour un nouveau projet JavaScript ou TypeScript, Playwright constitue souvent un bon point de départ. Ses locators peuvent cibler un rôle, un libellé ou un texte visible. Ses actions attendent aussi que l’élément soit prêt avant de cliquer.

Selenium WebDriver reste pertinent pour une base existante, plusieurs langages ou une infrastructure Selenium Grid déjà en place. Selenium IDE existe encore pour enregistrer un premier scénario, mais je transforme ensuite ce scénario en code lisible et versionné.

Écrire un scénario qui résiste mieux

Voici un test Playwright volontairement court pour un environnement de test :

 1import { test, expect } from "@playwright/test";
 2
 3test("exporte un rapport", async ({ page }) => {
 4  await page.goto(process.env.APP_URL!);
 5
 6  await page.getByLabel("Adresse e-mail").fill(process.env.TEST_EMAIL!);
 7  await page.getByLabel("Mot de passe").fill(process.env.TEST_PASSWORD!);
 8  await page.getByRole("button", { name: "Se connecter" }).click();
 9
10  await expect(page.getByRole("heading", { name: "Rapports" })).toBeVisible();
11
12  const download = page.waitForEvent("download");
13  await page.getByRole("button", { name: "Exporter" }).click();
14  await download;
15});

Je n’utilise pas de position comme « le troisième bouton ». Je cible ce que l’utilisateur voit. La documentation des locators Playwright recommande aussi de privilégier les rôles et les libellés.

Les identifiants restent dans des secrets, jamais dans le dépôt. Le compte de test possède uniquement les droits nécessaires.

Planifier sans perdre le contrôle

Un test peut être lancé à chaque changement dans la CI. Une tâche métier peut suivre un calendrier, à condition qu’elle soit idempotente et qu’un nouvel essai ne crée pas de doublon.

GitHub Actions peut exécuter un workflow sur événement, manuellement ou selon un horaire. Pour une tâche importante, je garde un déclenchement manuel et j’enregistre le résultat : date, entrée traitée, sortie produite et erreur éventuelle.

Les contrôles qui comptent

Avant de laisser une automatisation tourner seule, je vérifie :

1. qu’elle peut être relancée sans conséquence indésirable ;
2. qu’elle échoue clairement si la page ou les données ont changé ;
3. qu’elle limite ses droits et protège ses secrets ;
4. qu’elle produit des journaux utiles ;
5. qu’une personne sait comment l’arrêter et la reprendre.

Le temps gagné vient rarement du premier enregistrement de clics. Il vient d’un petit script compréhensible, surveillé et assez fiable pour ne pas réclamer une réparation chaque semaine.