Tests de qualité logicielle : QA vs QC vs tests expliqués

Les personnes qui recherchent des tests de qualité logicielle s’interrogent généralement sur trois métiers différents à la fois. L’assurance qualité (QA) façonne le processus pour que moins de bugs soient créés, le contrôle qualité (QC) examine le produit que votre équipe a construit pour y trouver des problèmes, et les tests sont le travail concret qui fournit l’essentiel des preuves du QC.

Confondre ces trois métiers coûte cher au moment de constituer l’équipe d’un projet. Une entreprise dont le processus est fragile risque de recruter quelqu’un qui se contente d’exécuter des cas de test, tandis qu’une startup qui manque de testeurs peut payer un consultant pour repenser son flux de travail. Dans les deux cas, le budget part dans le mauvais type d’aide.

Ce guide explique la QA, le QC et les tests en termes simples, à partir des définitions officielles de l’ISTQB, l’organisme qui certifie les testeurs logiciels à l’échelle internationale. Vous verrez aussi comment ces métiers s’articulent dans un vrai projet et quelles questions poser avant de recruter. Si vous préférez confier les trois à un seul partenaire, notre équipe d’assurance qualité dédiée fonctionne ainsi.

Pourquoi les tests de qualité logicielle recouvrent-ils en réalité trois métiers différents ?

Chacun des trois métiers répond à une question différente. La QA se demande si l’équipe travaille d’une manière qui produit un bon logiciel, et le QC décide si cette version précise est prête à être livrée. Les tests cherchent où le produit casse et rassemblent les preuves dont le QC a besoin pour trancher.

L’assurance qualité prévient les défauts dans le processus

Le glossaire de l’ISTQB définit l’assurance qualité comme des « activités visant à donner confiance dans le fait que les exigences de qualité seront satisfaites ». Concrètement, la QA met en place des habitudes de travail qui préviennent les bugs, que les testeurs appellent des défauts.

Au quotidien, le travail de QA consiste surtout à planifier et à s’accorder sur des règles. Un spécialiste QA relit la description écrite de chaque fonctionnalité et s’assure qu’elle est assez claire pour être développée et testée. Une partie du travail consiste à définir ce que « terminé » veut dire, ce qui est testé avant chaque mise en production et comment les problèmes sont signalés et suivis. Quand un bug atteint malgré tout les utilisateurs, la QA cherche la faille du processus qui l’a laissé passer.

Le contrôle qualité trouve les défauts dans le produit

Le contrôle qualité, c’est le volet vérification. Le glossaire de l’ISTQB décrit le QC comme des « activités destinées à évaluer la qualité d’un composant ou d’un système ». Autrement dit, le QC compare ce que votre équipe a réellement construit avec ce que vous aviez prévu de construire.

Le QC intervient dès qu’il y a quelque chose à inspecter, par exemple un seul écran, une nouvelle fonctionnalité ou une version complète. Les testeurs divisent ce travail en deux parties, appelées vérification et validation :

• Vérification : le produit correspond-il au plan écrit ?
• Validation : les vrais utilisateurs obtiennent-ils du produit ce dont ils ont besoin ?

Les tests sont le principal moyen d’assurer le contrôle qualité

Tester, c’est utiliser délibérément le logiciel pour trouver les problèmes avant vos clients. Le syllabus de l’ISTQB indique que les tests et la QA « ne sont pas la même chose » et qualifie les tests de « forme majeure de contrôle qualité ». En d’autres termes, les tests sont une partie du QC, et le QC travaille aux côtés de la QA.

Dans les tests manuels, une personne parcourt l’application comme le ferait un client. Cette approche concrète repère les écrans déroutants et les comportements étranges que les vérifications scriptées ont tendance à manquer. Les tests automatisés utilisent de petits programmes pour répéter rapidement les mêmes étapes sur chaque nouvelle version. Les deux approches livrent le même résultat : des preuves sur le fonctionnement actuel du produit.

QA vs QC vs tests en un coup d’œil

QA vs QC vs tests se résume à trois centres d’attention : le processus, le produit et les vérifications concrètes entre les deux.

L’ISTQB ajoute que la QA « relève de la responsabilité de tous les membres d’un projet ». Aucun recrutement ni aucun prestataire ne peut donc porter la qualité à lui seul.

Comment le processus d’assurance qualité logicielle s’articule-t-il avec les tests ?

Dans une équipe bien organisée, la QA, le QC et les tests fonctionnent en boucle. La QA fixe les règles, les tests rassemblent les preuves et le QC transforme les résultats en décision de mise en production. Après chaque lancement, l’équipe analyse ce qui n’a pas fonctionné et ajuste le plan pour le cycle suivant. Faire tourner cette boucle d’une version à l’autre, c’est le rôle du processus d’assurance qualité logicielle, et notre guide du processus QA en détaille chaque étape.

Comment nous avons réparti QA, QC et tests pour DrAnsay

Nous avons mis en place les trois métiers de zéro pour DrAnsay, une plateforme allemande d’ordonnances en ligne qui compte 700 000 patients. Au départ, DrAnsay n’avait pas d’équipe QA interne, et des bugs récurrents continuaient d’atteindre les patients pendant qu’ils commandaient leurs ordonnances.

Voici comment le travail s’est réparti entre QA, tests et QC :

• Assurance qualité : nous avons commencé par explorer les applications web et mobile, puis transformé nos constats en plan de test. Nos ingénieurs ont aussi relu les documents de fonctionnalités et les maquettes avant le développement, afin que les lacunes apparaissent avant la moindre ligne de code. Les cas de test, les plans de revérification des fonctionnalités existantes et le suivi des bugs ont été regroupés dans un seul outil, Qase.io, pour que tout le monde ait la même vision.
• Tests : nos ingénieurs ont parcouru à la main le parcours de commande d’ordonnances sur le web et sur mobile. Nous avons également écrit plus de 40 tests automatisés avec Playwright, un outil d’automatisation de navigateur très répandu, pour les parcours utilisateur les plus importants. Ces tests s’exécutent chaque jour et envoient leurs résultats sur le canal Slack de l’équipe.
• Contrôle qualité : les résultats indiquaient à l’équipe DrAnsay ce qui devait être corrigé avant que chaque nouvelle version puisse être mise en ligne.

Nous avons signalé plus de 150 bugs, et plus de 60 d’entre eux n’ont jamais atteint la production. Les commandes de DrAnsay ont augmenté de 15 %, et les paniers abandonnés ont baissé de 18 %.

Une seule campagne de tests juste avant le lancement trouve les bugs trop tard. C’est pourquoi nous impliquons la QA dès les premières descriptions de fonctionnalités et continuons de vérifier à travers toutes les étapes du test logiciel.

Que se passe-t-il quand la QA ou le QC échoue ?

Deux pannes majeures de 2025 illustrent la différence entre une faille de processus et un défaut non détecté.

Cloudflare est un fournisseur réseau sur lequel de nombreux sites web s’appuient pour leur vitesse et leur sécurité. Le 18 novembre 2025, l’entreprise a connu sa pire panne depuis 2019, selon ses propres termes. Une modification des permissions d’une base de données a fait doubler la taille d’un fichier de configuration interne. Le programme qui le charge avait une limite de 200 entrées et a planté dès que la version surdimensionnée s’est propagée sur le réseau. La correction de Cloudflare est un changement de processus : l’entreprise prévoit de contrôler les fichiers créés par ses propres systèmes aussi strictement que les données saisies par les utilisateurs. Cette panne est une leçon de QA, car la faille se trouvait dans les règles qui définissent ce qui est inspecté.

En octobre 2025, une défaillance majeure a touché une région américaine d’Amazon Web Services (AWS), la plateforme cloud qui fait tourner de nombreuses applications. AWS a attribué la cause à ce que son rapport appelle une condition de concurrence latente. Ce terme désigne un bug de synchronisation caché qui n’apparaît que lorsque deux processus automatisés mettent à jour les mêmes enregistrements en même temps. Parmi les correctifs d’AWS figure une suite de tests supplémentaire, c’est-à-dire un nouvel ensemble de vérifications reproductibles, pour l’un des systèmes de reprise de l’entreprise. La panne d’AWS est une leçon de QC, puisqu’un défaut a échappé aux garde-fous déjà en place.

Vos propres incidents peuvent être classés de la même façon. Après tout bug sérieux, demandez-vous si le processus a laissé passer le risque ou si les vérifications ont manqué le défaut. La réponse vous indique si votre QA, votre QC ou les deux sont à revoir.

L’ingénierie de la qualité remplace-t-elle la QA ?

Non, l’ingénierie de la qualité (QE) est une façon plus large d’organiser les trois mêmes métiers. Le terme QE apparaît souvent dans les offres d’emploi et les propositions commerciales des prestataires. Le glossaire de l’ISTQB décrit l’ingénierie de la qualité comme un ensemble de pratiques dans lesquelles « les parties prenantes partagent la responsabilité conjointe » de la qualité. Les parties prenantes désignent ici toutes les personnes qui ont leur mot à dire sur le logiciel, des développeurs et testeurs jusqu’aux product owners.

L’idée découle du principe de la QA selon lequel la qualité est l’affaire de toute l’équipe. Dans une organisation QE, les développeurs écrivent des vérifications automatisées pour leur propre code, les testeurs contribuent tôt à la conception des fonctionnalités et les product owners s’accordent sur ce qui doit être validé avant la mise en production. La QA, le QC et les tests existent toujours au sein de la QE, donc les définitions données plus haut dans ce guide restent valables.

Qui recrutez-vous quand vous recrutez un ingénieur QA ?

Les intitulés de poste ajoutent à la confusion. D’après notre expérience, l’« ingénieur QA » type consacre l’essentiel de sa semaine au travail concret : écrire des cas de test, exécuter les vérifications et signaler les bugs. Le travail de processus occupe le reste du temps, et sa part augmente généralement avec l’ancienneté. Une personne recrutée sous ce titre couvre donc une bonne partie du QC, mais seulement une partie de la QA.

Une mission limitée aux tests peut pourtant être exactement le bon choix. Pour Chesapeake Technology, nous testons SonarWiz, un logiciel de bureau que plus de 4 000 organisations utilisent pour cartographier les fonds marins. Le client disposait déjà de ses propres cas de test, si bien que nos ingénieurs se sont concentrés sur leur exécution. SonarWiz est un produit complexe qui lit plus de 60 formats de données sonar. La première mission a fait remonter à elle seule plus de 50 bugs, dont une petite erreur de métadonnées qui décalait les coordonnées de la carte de plusieurs milliers de kilomètres.

Les prestataires ne sont pas toujours précis dans leurs étiquettes non plus, nous compris. Notre étude de cas présente le projet réalisé pour Elsewhen, un cabinet londonien de conseil en produits numériques, comme un audit QA. En pratique, nous avons testé un site web repensé sous l’angle de la fonctionnalité, du rendu visuel, de l’accessibilité, de la visibilité dans les moteurs de recherche et de la vitesse. Parmi les bugs signalés, 41 % concernaient la cohérence du design et 20 % touchaient les utilisateurs en situation de handicap. Chaque vérification portait sur le produit lui-même : selon les définitions de l’ISTQB, le projet relevait donc du QC.

Avant de confier des tests de qualité logicielle à une personne ou à un prestataire, posez quelques questions directes :

• Allez-vous examiner nos exigences et notre processus de mise en production, ou seulement tester ce que nous vous transmettons ?
• Qui écrit les cas de test, et qui les tient à jour ?
• Comment les résultats des tests parviennent-ils à nos développeurs, et qui décide si une version est livrée ?
• Qu’est-ce qui change dans notre processus si le même type de bug revient sans cesse ?

Les réponses vous montrent si vous achetez de la QA, du QC, des tests ou un mélange des trois.

Les bons termes fixent les bonnes attentes

Connaître la différence entre QA, QC et tests vous indique ce que vous pouvez attendre d’une nouvelle recrue, d’un prestataire ou d’un audit de la manière dont votre équipe travaille. Quand vous cherchez des services de tests de qualité logicielle, vérifiez trois points :

• Un processus qui prévient les défauts
• Des vérifications qui attrapent les bugs qui passent entre les mailles
• Des revues régulières qui transforment chaque bug manqué en correction durable

Chez QAwerk, une seule équipe couvre à la fois le volet processus et les tests concrets, vous n’avez donc pas à coordonner plusieurs prestataires. Pour savoir si votre projet a besoin de plus de QA, de QC ou de tests, parlez à nos ingénieurs QA.

FAQ

Quelle est la différence entre QA, QC et tests ?

Dans les tests de qualité logicielle, la QA, le QC et les tests sont trois métiers liés. Imaginez la cuisine d’un restaurant : la QA, ce sont les recettes et les règles d’hygiène qui évitent de préparer de mauvais plats, le QC est la décision du chef sur chaque assiette, bonne ou non à servir, et les tests sont la dégustation qui guide le chef. La QA prévient les défauts, tandis que le QC et les tests les trouvent.

Les tests font-ils partie de la QA ou du QC ?

Les tests relèvent du contrôle qualité. Selon l’ISTQB, l’organisme international qui certifie les testeurs, les tests sont une forme majeure de QC. Examiner le logiciel lui-même, c’est précisément la raison d’être du QC. La QA travaille un niveau au-dessus et décide quand les tests ont lieu, quelle quantité suffit et ce qui change quand les mêmes bugs reviennent sans cesse.

Un ingénieur QA fait-il de l’assurance qualité ou des tests ?

La plupart des ingénieurs QA font les deux, dans des proportions différentes. Dans une équipe type, les profils juniors et intermédiaires consacrent l’essentiel de leur temps aux tests concrets. Les ingénieurs seniors et les responsables QA prennent en charge davantage de travail de processus, comme la revue des exigences fonctionnelles et la définition des critères de mise en production. Les intitulés varient beaucoup, alors lisez les missions décrites dans une offre d’emploi ou une proposition de prestataire pour connaître la répartition réelle.

Une seule équipe peut-elle gérer à la fois la QA et le QC ?

Oui, et pour les petites et moyennes entreprises, une seule équipe est souvent l’organisation la plus simple. Les personnes qui testent chaque version voient aussi d’où viennent les bugs, elles peuvent donc corriger le processus sous-jacent sans passage de relais entre prestataires. Avant de signer, vérifiez que le périmètre convenu couvre le travail de planification et de revue en plus de l’exécution des tests.

Les petites équipes ont-elles besoin d’un processus QA distinct ?

Une petite équipe a besoin d’un processus QA léger. Trois habitudes couvrent généralement l’essentiel : un plan de test court, un seul endroit partagé pour suivre les bugs et une règle claire sur ce qui doit être validé avant chaque mise en production. Sans cette routine, les tests se résument à cliquer au hasard, et les mêmes problèmes reviennent à chaque nouvelle version.