Le programme — 160 h
Organisation
| Composante | Volume |
|---|
| Cours du soir — 6 modules | 120 h |
| Accompagnement et évaluations | 8 h |
| Week-end 1 — Préparation ISTQB CTFL v4.0 | 16 h |
| Week-end 2 — Préparation ISTQB CT-GenAI | 16 h |
| Total | 160 h |
12 semaines · 5 séances par semaine · 2 h par séance
Chaque séance : apport ciblé, démonstration, atelier pratique, revue
Teachizy accessible en continu : cours, quiz, exercices, remédiation
Une activité « IA en pratique » chaque semaine à partir de la semaine 2
Progression
| Semaines | Module | Heures |
|---|
| 1 | M1 — Ingénierie qualité | 10 h |
| 2 – 5 | M2 — Socle technique | 40 h |
| 6 – 9 | M3 — Automatisation des tests | 40 h |
| 10 | M4 — Intégration continue | 8 h |
| 10 – 11 | M5 — IA appliquée au test | 12 h |
| 12 | M6 — Projet Capstone | 10 h |
Week-end CTFL après la semaine 6 · Week-end CT-GenAI après la semaine 11.
Principe pédagogique — Aucune compétence avancée n'est abordée avant que le socle qui la conditionne ne soit validé. Chaque module se termine par une porte de validation ; en cas d'échec, un parcours de remédiation Teachizy est prescrit avant l'entrée dans le module suivant.
L'IA intervient dès la semaine 2 comme assistant de conception, d'analyse et de productivité. Chaque usage suit la même règle : l'apprenant produit d'abord, compare ensuite, valide toujours. L'IA n'est jamais un substitut au raisonnement, au code écrit à la main ou à la validation humaine.
M1 — Ingénierie qualité
Semaine 1 · 10 h
Compétences
Cycle de vie logiciel, agilité, DevOps, rôle du testeur dans une équipe moderne
Qualité produit, qualité processus, coût de la non-qualité
Niveaux et types de test, tests fonctionnels et non fonctionnels
Techniques boîte noire : partitions d'équivalence, valeurs limites, tables de décision, transitions d'état
Tests exploratoires, revues et tests statiques
Analyse des risques et priorisation
User stories, critères d'acceptation, stratégie et plan de test
Traçabilité, couverture, métriques, rapports d'anomalie avec Jira et Xray
Objectif opérationnel : recevoir une user story et déterminer ce qui doit réellement être testé, dans quel ordre et pourquoi.
IA en pratique
Transformer une exigence en propositions de scénarios, puis en écarter les inutiles
Critiquer des cas de test générés : omissions, hypothèses fausses, hallucinations
Améliorer un rapport d'anomalie sans inventer d'information
Livrable — Stratégie de test fondée sur les risques, cas de test, matrice de traçabilité, rapports d'anomalie.
Porte de validation — Quiz de 30 questions alignées CTFL v4.0 (seuil 70 %) et cas pratique de conception noté.
M2 — Socle technique
Semaines 2 à 5 · 40 h · le module le plus dense du parcours
Le rythme est calibré pour des débutants : chaque notion est manipulée avant d'être nommée.
Environnement de travail — 6 h
Terminal et système de fichiers
Node.js, npm, gestion des dépendances
Visual Studio Code
Git et GitHub : commits, branches, pull requests, revue de code
Variables d'environnement, .gitignore, gestion élémentaire des secrets
Technologies web — 8 h
HTML, CSS essentiel, structure d'une page
DOM, événements, DevTools
Sélecteurs CSS ; XPath en lecture seulement
Sélecteurs fondés sur les rôles, labels et attributs de test
Cycle navigateur – serveur – API, cookies, stockage local
JavaScript — 18 h
Variables, types, conditions, boucles, fonctions
Tableaux, objets, destructuring, JSON
Modules et gestion des erreurs
Programmation orientée objet : classes, ce qui est nécessaire au test
Asynchronisme : promesses, async / await — 6 h dédiées
Lecture, débogage et refactoring de code
TypeScript et données — 8 h
Types, interfaces, unions, fonctions typées, configuration
SQL essentiel : lire et vérifier des données
IA en pratique
Demander l'explication d'un code, puis vérifier sa validité en l'exécutant
Résoudre un exercice à la main, comparer avec la solution générée, argumenter les différences
Détecter les erreurs d'un code généré volontairement défectueux
Refactorer un script en justifiant chaque modification
Livrable — Dépôt GitHub structuré : exercices JavaScript/TypeScript, historique Git propre, une pull request revue par un pair.
Porte de validation — Kata de programmation asynchrone en TypeScript réalisé sans IA, en séance.
M3 — Automatisation des tests
Semaines 6 à 9 · 40 h
Tests d'API — 10 h
HTTP/HTTPS, méthodes, statuts, en-têtes, formats de données
REST et lecture d'une spécification OpenAPI
Authentification : clés d'API, JWT
Exploration avec Postman
Automatisation des tests d'API en TypeScript avec Playwright
Tests négatifs, validation des réponses et des données
Playwright — 20 h
Installation, configuration, structure d'un test
Localisateurs robustes, assertions web-first, auto-waiting
Hooks, fixtures, données de test
État d'authentification réutilisable
Interception réseau et mocking
Débogage : Trace Viewer, captures, vidéos, rapports
Multi-navigateurs, émulation, parallélisation, retries
Tests visuels
Réduction des tests instables
Architecture d'automatisation — 10 h
Organisation d'un projet : tests, pages, composants, fixtures, données, utilitaires, configuration
Page Object Model et objets composants : quand les utiliser, quand ne pas les utiliser
Fabriques de données, helpers métier
Séparation des responsabilités, duplication, maintenabilité, isolation des tests
IA en pratique
Générer un squelette de test à partir d'un scénario validé, puis le corriger
Repérer dans un test généré : sélecteurs fragiles, assertions faibles, attentes artificielles, tests inutiles, secrets exposés
Analyser une trace d'échec et proposer des causes
Mesurer temps gagné, erreurs introduites, qualité obtenue
Livrable — Suite de tests API et web en TypeScript/Playwright, architecturée, documentée, avec rapports.
Porte de validation — Ajout en séance, sans IA, de trois tests sur une fonctionnalité inconnue, avec revue de code.
M4 — Intégration continue
Semaine 10 · 8 h
Compétences
Principes CI/CD, YAML
GitHub Actions : workflows, jobs, steps, secrets, variables
Installation reproductible, exécution des tests sur pull request
Artefacts, conservation des rapports, exécution parallèle
Quality gate : bloquer une fusion sur échec de tests
Analyse et correction d'un pipeline en échec
Objectif opérationnel : un test qui ne s'exécute que sur son ordinateur n'a pas de valeur ; l'apprenant livre un pipeline qui s'exécute à chaque pull request.
Livrable — Pipeline GitHub Actions exécutant la suite du M3 avec rapports archivés.
Porte de validation — Diagnostic et correction d'un pipeline cassé, en séance.
M5 — IA appliquée au test
Semaines 10 à 11 · 12 h
Fondamentaux — 2 h
IA, apprentissage automatique, IA générative, modèles de langage
Tokens, contexte, température, non-déterminisme
Hallucinations, biais, limites
Du prompt au contexte — 3 h
Prompt engineering appliqué au test
Context engineering : fournir exigences, architecture, spécification d'API, tests existants et conventions
Cycle systématique : générer → relire → exécuter → vérifier
IA au service du testeur — 4 h
Analyse d'exigences et détection d'ambiguïtés
Génération et amélioration de cas de test, données synthétiques
Assistance à l'automatisation et analyse des échecs
Synthèse de résultats pour les parties prenantes
Évaluer une sortie : critères définis à l'avance, jeu de référence, répétition, validation humaine
Agents et outils — 2 h
Principe d'un agent outillé : le modèle reçoit des outils contrôlés (navigateur, dépôt, API)
Démonstration : exploration, génération et réparation de tests par agent avec Playwright
Règle : un agent n'a pas autorité ; le testeur conserve validation, traçabilité et décision
Sécurité et conformité — 1 h
Données personnelles, RGPD, minimisation
Propriété intellectuelle, AI Act, injection de prompt, fuite d'informations sensibles
Politique d'utilisation responsable
Livrable — Dossier d'expérimentation IA : cas d'usage, prompts, critères, résultats, risques, décisions humaines.
Porte de validation — Évaluation argumentée d'une sortie IA sur un jeu de référence fourni.
M6 — Projet Capstone
Semaine 12 · 10 h + soutenance
L'apprenant reçoit une application web réaliste, fournie avec son API documentée, et livre une démarche qualité complète.
Éléments attendus
Analyse des risques, stratégie et plan de test, matrice de traçabilité
Cas de test manuels et exploratoires
Tests d'API et tests web Playwright, architecturés
Pipeline GitHub Actions avec quality gate
Gestion des données et des secrets
Utilisation documentée de l'IA et évaluation d'au moins une sortie générée
Registre des risques et rapport qualité destiné aux parties prenantes
Soutenance devant jury. Le jury n'évalue pas seulement que les tests passent. Il demande : pourquoi ce scénario, pourquoi l'automatiser, pourquoi celui-ci reste manuel, pourquoi cette assertion, quelle partie a été générée par l'IA, comment elle a été vérifiée.
Règle d'évaluation : une solution simple, comprise et défendable obtient une meilleure note qu'une solution complexe, générée par l'IA et non maîtrisée.