Terrain d'entraînement QA : des sandbox UI et API pour s'exercer à l'automatisation
La meilleure façon d'apprendre l'automatisation des tests est de la pointer sur quelque chose de réel et un peu cassé. Voici huit sandbox gratuits — quatre UI, quatre API — chacun avec une mission précise, et une méthode qui transforme le fait de cliquer partout en un entraînement qu'un recruteur regardera vraiment.
L'entraînement le plus rapide ne demande aucun téléchargement ni serveur de démo instable — il tourne dans cet onglet. Commencez ici, puis emmenez ces automatismes vers les vrais sandbox ci-dessous.
Chaque liste de « sites pour s'entraîner à l'automatisation » est la même vingtaine de liens avec une phrase chacun, et la moitié renvoie une 404. Les liens ne sont pas le plus dur — savoir quoi faire une fois arrivé, si. Cette page est donc courte en sites et longue en missions : huit sandbox réellement en ligne, chacun avec une tâche précise et un moyen de la corser une fois qu'elle devient facile.
S'entraîner pour que ça compte
Ouvrir un site de démo et cliquer partout, ce n'est pas s'entraîner. Ces quatre gestes transforment ça en quelque chose de montrable :
- 01Une cible, une compétence
Sauter d'un site à l'autre donne l'impression d'avancer et n'apprend rien. Choisissez un seul sandbox et une seule compétence — attentes robustes, la boucle CRUD, la pagination — et restez-y jusqu'à la maîtrise.
- 02Le plan avant le code
Le sandbox ne vous dira pas ce que « correct » veut dire — c'est à vous de décider. Un paragraphe : ce que vous allez vérifier, ce que vous choisissez de ne pas vérifier, avant la première ligne d'automatisation.
- 03Automatisez le cas d'erreur
N'importe qui automatise la connexion qui marche. Les points se gagnent sur l'utilisateur bloqué, le 404, le token manquant, le panier vide. Le « happy path » seul est la première raison de rejet d'un test technique.
- 04Livrez-le avec un README
Un test au vert sur votre machine ne prouve rien à un recruteur. Poussez-le dans un dépôt public avec un README qui dit ce qu'il couvre et comment le lancer — là, c'est une pièce de portfolio.
Sandbox UI
Automatisation du navigateur — les parcours, les éléments piégeux, les données à l'écran. Commencez par SauceDemo pour un parcours complet et propre, puis passez à The Internet dès que vous voulez corriger l'instabilité plutôt que d'en écrire davantage.
SauceDemo
saucedemo.comUne boutique e-commerce factice (Swag Labs) avec six identifiants — dont certains volontairement cassés. La cible par défaut pour débuter.
Le parcours UI de bout en bout que tout entretien d'automatisation attend — se connecter, ajouter au panier, payer — et votre premier aperçu d'une cible qui se comporte mal exprès.
Your missionAutomatisez tout l'achat en un seul test : connectez-vous en standard_user, ajoutez deux articles nommés, vérifiez le compteur du panier, terminez le paiement et vérifiez la confirmation. Puis relancez le même test en problem_user et locked_out_user — votre travail est de faire dire à chaque échec pourquoi, pas juste de passer au rouge.
Rendez-le piloté par les données. Lisez les identifiants depuis une liste, bouclez le test de connexion sur chacun, et vérifiez le résultat attendu par utilisateur. C'est la différence entre un script et une suite.
Open saucedemo.com ↗
The Internet
the-internet.herokuapp.comUne cinquantaine de pages isolées, chacune un comportement UI piégeux — chargement dynamique, iframes, alertes JS, upload de fichier, contenu qui bouge. La salle de muscu des sélecteurs.
Attente robuste et stratégie de sélecteurs. C'est là que naissent et se corrigent les tests instables. Rien ici n'est un « parcours » ; chaque page est une expérience contrôlée sur une seule chose qui casse les scripts.
Your missionFaites Dynamic Loading → Example 2 sans un seul sleep codé en dur — attendez l'élément, pas l'horloge. Puis acceptez et rejetez une alerte JavaScript, et lisez une valeur dans une iframe (les exemples Frames). Si votre test contient sleep(3), vous n'avez pas fini.
Les pages Challenging DOM et Shifting Content existent pour punir les sélecteurs fragiles. Écrivez des sélecteurs qui survivent à un id qui change à chaque chargement — relatifs, basés sur le texte ou le rôle, jamais un XPath absolu copié.
Open the-internet.herokuapp.com ↗
BooksToScrape
books.toscrape.comUne librairie factice — 1 000 livres sur 50 pages, avec prix, notes et stock. Un catalogue statique qui ne change jamais.
Pagination, extraction et validation de données. Le catalogue ne bouge jamais : c'est l'endroit calme pour apprendre à parcourir de nombreuses pages et à vérifier des données structurées, pas juste « ça s'est chargé ».
Your missionParcourez les 50 pages, collectez le titre, le prix et la note de chaque livre, et vérifiez trois choses : le total est exactement 1 000, aucun prix n'est à £0.00, et chaque note est l'une de One–Five. Transformez « ça s'est chargé » en « les données sont correctes ».
Level it upSon site jumeau quotes.toscrape.com ajoute une connexion et une variante à défilement infini — refaites la même extraction sur un contenu qui arrive au défilement plutôt qu'à la pagination.
Automation Exercise
automationexercise.comUn vrai site e-commerce complet — inscription, recherche, panier, paiement — qui publie aussi une liste documentée d'endpoints d'API de test pour le même domaine.
Le pont. Un seul site où vous automatisez un parcours UI et appelez un endpoint REST sur les mêmes données — exactement le travail d'un SDET sur les deux couches.
Your missionInscrivez un nouveau compte via l'UI (email jetable), puis confirmez-le avec l'API /verifyLogin de sa liste d'API. L'UI crée l'état ; l'API le vérifie. Ce contrôle sur deux couches est une vraie habitude de niveau senior.
Sa liste d'API fournit des endpoints qui devraient échouer — mauvaise méthode, paramètre manquant. Appelez-les exprès et vérifiez la réponse d'erreur. Le test d'API négatif, c'est là que les points se gagnent.
Open automationexercise.com ↗Sandbox API
Pas de navigateur, juste des requêtes et des réponses. Descendez la liste — sans auth, puis une clé, puis un CRUD complet avec token, puis un contrat à lire. En échauffement, httpbin.org renvoie ce que vous envoyez : le moyen le plus rapide de voir les en-têtes, les codes de statut et les schémas d'authentification isolément avant de vérifier quoi que ce soit.
JSONPlaceholder
jsonplaceholder.typicode.comL'API REST factice sans friction — posts, commentaires, utilisateurs. Sans clé, sans connexion, réponse immédiate. Votre premier test d'API sans obstacle.
Requête et réponse, codes de statut et vérifications du corps JSON — appris avant que quoi que ce soit ne demande une authentification.
Your missionFaites un GET /posts/1 et vérifiez que le statut est 200 et que le corps contient userId, title et body. Puis faites un POST d'un nouveau post et vérifiez que vous obtenez 201 avec les champs renvoyés. Deux requêtes, et vous comprenez la forme de tout test REST.
Il simule les écritures — un POST renvoie 201 mais rien n'est persisté. Remarquez-le. Connaître la différence entre une API bouchonnée et une API avec état est exactement le piège que ce site vous apprend gratuitement.
Open jsonplaceholder.typicode.com ↗
ReqRes
reqres.inUne API REST factice hébergée avec des utilisateurs réalistes, de la pagination et des délais volontaires. Depuis sa refonte de 2025, chaque requête demande une clé d'API gratuite.
REST réaliste plus votre premier en-tête d'authentification. L'exigence de clé est une fonctionnalité, pas un défaut — c'est l'introduction la plus douce possible à l'envoi d'identifiants avec une requête.
Your missionRécupérez la clé gratuite, puis envoyez-la dans un en-tête x-api-key sur GET /api/users?page=2. Vérifiez que page, per_page et la longueur du tableau data concordent. Puis appelez /api/users/23 et vérifiez un 404 — le cas « introuvable » que la plupart oublient.
Le paramètre ?delay= le fait répondre lentement exprès — servez-vous-en pour prouver que la gestion de vos timeouts est réelle, pas juste chanceuse. (Un 401 signifie que votre en-tête de clé manque ; vérifiez ça d'abord.)
Restful Booker
restful-booker.herokuapp.comUne API de réservation CRUD conçue pour les tests — authentification par token, dix réservations pré-remplies, et, selon l'auteur, « truffée de bugs ». Réinitialisée toutes les dix minutes.
Le cycle de vie complet d'une API : s'authentifier, créer, lire, mettre à jour, supprimer — et trouver des bugs plantés. Ce qui se rapproche le plus, gratuitement, d'un vrai énoncé de test d'API.
Your missionFaites un POST sur /auth pour un token, créez une réservation, puis récupérez-la et vérifiez que chaque champ a survécu à l'aller-retour. Mettez-la à jour avec PUT (nécessite le token) et supprimez-la. Cette boucle créer → vérifier → mettre à jour → supprimer est la colonne vertébrale de l'automatisation d'API.
Les bugs plantés sont le but. Essayez un PATCH qui ne change qu'un champ, ou une mise à jour sans token, et voyez si l'API fait ce qu'il faut. Rédigez ce que vous trouvez comme un vrai rapport de bug — /apidoc est votre contrat.
Swagger Petstore
petstore.swagger.ioLa démo OpenAPI canonique — une API d'animalerie avec un contrat Swagger complet et interactif, lisible et exécutable dans le navigateur.
Lire une spécification. Le vrai travail d'API part d'un document OpenAPI/Swagger, pas d'un tutoriel — et chaque spec que vous croiserez ressemble à celle-ci.
Your missionAvant tout code, lisez le contrat : trouvez POST /pet, notez son schéma de requête exact et les codes de statut documentés. Puis automatisez « ajouter un animal, le récupérer par id, vérifier que le nom et le statut correspondent ». Vous avez testé contre la spec — c'est à ça que sert un contrat.
Envoyez exprès une requête qui casse le schéma — un champ requis manquant, un mauvais enum — et vérifiez que l'API la rejette avec l'erreur documentée. Le test de contrat est une compétence senior, et c'est ici qu'on la répète.
Open petstore.swagger.io ↗Puis faites-en une preuve, pas un exercice
Un test qui passe sur votre portable ne convainc personne. La dernière étape est toujours la même : mettez un projet fini — cas d'erreur couverts, README écrit — dans un dépôt public, et soyez prêt à défendre chaque choix. C'est ce que teste vraiment un test technique à la maison, et c'est ce vers quoi tend le parcours. Quand vous savez défendre une suite SauceDemo et un projet CRUD Restful Booker, vous êtes prêt pour les questions d'entretien d'automatisation.
Questions fréquentes
Quel est le meilleur site pour s'entraîner à l'automatisation QA quand on débute ?
Commencez par SauceDemo pour un parcours UI et JSONPlaceholder pour votre premier test d'API — les deux sont stables et ne demandent presque aucune configuration. Passez à The Internet dès votre premier test instable, car le corriger est la vraie compétence. Ou sautez la configuration et commencez dans le Locator Lab.
Comment s'entraîner au test d'API sans construire de backend ?
Utilisez une API sandbox publique. JSONPlaceholder ne demande aucune auth ; ReqRes ajoute une seule clé d'API gratuite pour apprendre à envoyer un en-tête d'identification ; Restful Booker offre un CRUD complet avec token et des bugs plantés à trouver ; et le Swagger Petstore permet de s'exercer à lire un contrat OpenAPI avant de tester contre lui. httpbin.org est un bon échauffement — il renvoie ce que vous envoyez, pour voir en-têtes et codes de statut isolément.
Ces sites d'entraînement QA sont-ils gratuits ?
Oui, les huit sont gratuits. Une nuance : ReqRes exige désormais une clé d'API gratuite à chaque requête depuis sa refonte de 2025 — inscrivez-vous, puis envoyez-la dans un en-tête x-api-key. Les autres ne demandent aucun compte. Ce sont des serveurs de démo tiers : considérez une panne occasionnelle comme normale et n'entrez jamais un vrai mot de passe dedans.
Puis-je mettre un projet d'entraînement sur mon CV ou mon portfolio ?
Oui — et vous devriez, mais seulement s'il dépasse le script « happy path ». Choisissez un sandbox, couvrez les cas d'erreur, et poussez-le dans un dépôt public avec un README qui dit ce qu'il couvre et comment le lancer. C'est la différence entre « j'ai fait un tuto » et une pièce de portfolio. Notre guide des tests techniques montre la grille sur laquelle les relecteurs notent.
Faut-il s'entraîner avec Selenium, Cypress ou Playwright ?
Le sandbox s'en moque — choisissez l'outil que vous savez expliquer sous questions. Les relecteurs pèsent votre conception de test bien plus que le choix du framework. Si vous hésitez, Playwright offre la mise en route la plus douce pour un premier projet ; quel que soit votre choix, écrivez une ligne de README expliquant pourquoi.
Combien de temps avant que m'entraîner ici me rende prêt pour les entretiens ?
Il n'y a pas de chiffre honnête — ça dépend d'où vous partez et de votre rigueur. Ce qui est fiable, c'est la forme : une poignée de projets finis couvrant chacun les cas d'erreur battent des mois de tutos à moitié faits. Une bonne suite SauceDemo et un projet CRUD Restful Booker, tous deux avec README, sont un signal plus fort que cinquante scripts éparpillés.