La vérification contrôle si un produit est conforme à ses spécifications ; la validation contrôle s'il répond aux besoins réels des utilisateurs.
Les définitions courtes
Vérification : est-ce que le produit est conforme à ses spécifications ? Correspond-il à ce qui a été documenté, conçu et convenu ? Validation : est-ce que le produit répond aux vrais besoins des utilisateurs ? Résout-il le problème réel pour lequel il a été conçu ?Un produit peut passer la vérification mais échouer la validation : il fonctionne exactement comme spécifié, mais la spécification était fausse. Elle ne couvre pas ce dont les utilisateurs ont réellement besoin.
Un produit peut aussi passer la validation mais échouer la vérification. Les utilisateurs l'adorent, il fonctionne bien, mais il contient des fonctionnalités non documentées, des failles de sécurité, ou des comportements qui diffèrent de la spec.
Vérification : est-ce conforme à la spec
Les activités de vérification se font généralement sans exécuter le logiciel. La question : est-ce que ce qu'on a construit correspond à ce qui a été convenu ?
À quoi ressemble la vérification
Revues de documents : vérifier que le document d'exigences couvre toutes les fonctionnalités convenues, que la spec de design est cohérente avec ces exigences. Vérifier aussi que les cas de test les couvrent toutes. Revues de code : vérifier que le code correspond au document de design et que les patterns de sécurité des standards de codage sont respectés. Inspection : parcourir ensemble les exigences, le design et l'implémentation pour vérifier qu'ils s'alignent. Revue de prototype ou de maquette : vérifier que la maquette UI correspond aux user stories convenues.L'objectif
Trouver les défauts dans les documents et les designs avant que le logiciel soit construit ou testé. Corriger une exigence erronée sur papier coûte bien moins cher que de la corriger après 3 sprints de développement.
Validation : est-ce que ça résout le vrai problème
La validation se fait en exécutant le logiciel, généralement par des tests réels. La question : est-ce que ce produit fonctionne pour les personnes pour qui il a été conçu ?
À quoi ressemble la validation
Tests d'acceptation utilisateur (UAT) : de vrais utilisateurs testent le logiciel dans leurs conditions réelles. La question centrale est simple. Est-ce que ça fait ce dont j'avais besoin ? Tests système : tester le système complet par rapport aux exigences et aux objectifs des utilisateurs. L'ensemble fonctionne-t-il de bout en bout pour des cas d'usage réalistes ? Tests bêta : un sous-ensemble de vrais utilisateurs utilise le produit dans leur environnement réel. Cela révèle les lacunes que les tests basés sur la spec ont ratées, parce que la spec ne capturait pas l'usage réel. Tests d'utilisabilité : vérifier que les utilisateurs peuvent accomplir leurs objectifs avec l'interface. Techniquement correct ne veut pas dire utilisable.L'objectif
Confirmer que le logiciel apporte une vraie valeur. Une fonctionnalité peut être techniquement correcte et complètement inutile.
Un exemple concret
Imaginons une exigence :
"Le champ de recherche doit retourner des résultats en moins de 3 secondes."Question de vérification : l'implémentation correspond-elle à cette exigence ? On lance une recherche, on mesure le temps, on confirme qu'il est inférieur à 3 secondes. Succès. Question de validation : est-ce que ça résout le vrai problème de l'utilisateur ? On découvre que les utilisateurs cherchent dans des catalogues de produits immenses et que 3 secondes paraît inacceptablement lent quand Google retourne des résultats en 0,3 secondes. Même si la spec disait 3 secondes et que le code respecte ça, la validation échoue.
La spécification était fausse. La vérification n'a rien détecté. La validation a tout détecté.
C'est pourquoi on ne peut pas se reposer uniquement sur la vérification : la spec ne vaut que ce que valent les personnes qui l'ont rédigée.
Un autre exemple : la validation de formulaire
Exigence : "Le champ mot de passe ne doit pas accepter moins de 8 caractères."
Vérification : tester qu'un mot de passe de 7 caractères est refusé. C'est le cas. Validation : un vrai utilisateur essaie d'entrer son mot de passe habituel de 6 caractères et se fait refuser. Il tente d'en créer un nouveau de 8 caractères, mais le message d'erreur affiche simplement "Saisie invalide" sans explication. Il abandonne et ne s'inscrit pas. La validation échoue. Le produit n'aide pas les utilisateurs à accomplir leur objectif, qui est de s'inscrire.Le code était correct. L'exigence était trop étroite. Elle ne prenait pas en compte l'expérience utilisateur du message d'erreur.
Comment ils apparaissent dans un cycle de développement
| Phase | Activité | Vérification ou validation ? |
|---|---|---|
| Exigences | Revue des exigences : vérifier exhaustivité et cohérence | Vérification |
| Design | Walkthrough de design : vérifier que le design correspond aux exigences | Vérification |
| Développement | Revue de code : vérifier que le code correspond au design | Vérification |
| Tests | Tests unitaires : vérifier que les composants fonctionnent comme spécifié | Vérification |
| Tests | Tests d'intégration : vérifier que les modules fonctionnent ensemble | Vérification |
| Tests | Tests système : vérifier que le système complet répond aux exigences | Les deux |
| Tests | UAT : vérifier que les vrais utilisateurs atteignent leurs vrais objectifs | Validation |
| Release | Tests bêta : usage en conditions réelles | Validation |
La plupart de ce que font les ingénieurs QA au quotidien est un mélange des deux. Ils exécutent des tests par rapport aux exigences (vérification) tout en se demandant si la fonctionnalité fonctionne vraiment pour les vrais utilisateurs (validation).
Pourquoi cette distinction compte
Bugs issus de défauts de vérification : l'implémentation ne correspond pas à la spec. Un bouton ne fait pas ce que l'exigence dit qu'il devrait faire. Un calcul est faux. Un champ accepte des valeurs qu'il ne devrait pas. Bugs issus de défauts de validation : la spec était incomplète ou incorrecte. La fonctionnalité fonctionne telle que conçue mais échoue dans des scénarios utilisateurs réels. Messages d'erreur manquants, flux confus, performances techniquement acceptables mais pratiquement catastrophiques.Un bon QA détecte les deux. Les tests purement basés sur la spec détectent les défauts de vérification. Les tests exploratoires, les revues d'utilisabilité et l'UAT détectent les défauts de validation.
La version entretien
Si on te demande ça en entretien :
Vérification = "Est-ce qu'on construit le produit correctement ?" Conformité aux spécifications, typiquement statique (revues, walkthroughs) ou tests en début de phase par rapport aux exigences documentées. Validation = "Est-ce qu'on construit le bon produit ?" Confirmation que le logiciel répond aux besoins des utilisateurs, typiquement en exécutant le logiciel dans des conditions réalistes (UAT, tests bêta, tests d'utilisabilité).L'analogie classique : une carte peut être exacte, conforme au terrain réel, mais pointer vers la mauvaise destination. La vérification confirme la carte. La validation confirme qu'on se rend au bon endroit.
La plupart des équipes qui ont de bons tests de régression découvrent quand même des bugs en production. Souvent ce ne sont pas des défauts de vérification, ce sont des défauts de validation : la spec couvrait le bon comportement, pas le bon scénario utilisateur. Poser la question "est-ce que ça fonctionne pour un vrai utilisateur ?" en planification de sprint est le moment où elle coûte le moins cher. Avant que le code existe, ajuster une spec prend une heure. Après le déploiement, ça prend un sprint.
→ See also: Tests Boîte Noire vs Boîte Blanche: Un Guide Clair pour les Ingénieurs QA | Tests d'Acceptation: Ce que C'est, Qui les Fait et Comment | Qu'est-ce que le Test Manuel? Guide Complet pour 2026
