TLDR
L’assurance qualité logicielle vise à prévenir les défauts en maîtrisant les processus de développement, de test et de livraison. Un audit évalue ce dispositif plutôt que le logiciel lui-même : référentiel, plan d’assurance qualité, couverture des tests, traçabilité, conformité et gestion des anomalies. Il identifie les écarts, mesure leur criticité et débouche sur un plan d'action priorisé.
Pour identifier les écarts et prioriser les actions, commencez par auditer votre dispositif qualité.
Introduction
L’assurance qualité logicielle regroupe les processus et contrôles destinés à garantir qu’un logiciel respecte les exigences de qualité définies tout au long de son cycle de développement.
Disposer de tests automatisés, d’un plan de test et d’un suivi des anomalies ne suffit pas à prouver l’efficacité de la QA. Encore faut-il vérifier la couverture des risques, la traçabilité des exigences et les preuves associées aux contrôles.
C’est l’objet de l’audit qualité logiciel : confronter les pratiques prévues aux pratiques réelles pour identifier les écarts et les actions prioritaires. Il ne remplace ni les tests, qui détectent les défauts, ni le débogage, qui consiste à rechercher leur cause puis à les corriger.
Qu'est-ce qu'un audit de qualité logicielle ?
Un audit de qualité logicielle évalue les processus, responsabilités, pratiques et preuves qui composent le dispositif d’assurance qualité. Contrairement au test, il ne recherche pas directement des défauts dans le logiciel.
L’audit qualité peut être conduit par un auditeur interne indépendant des activités examinées, un client, un cabinet spécialisé ou un organisme tiers. Il s’appuie sur un référentiel et des preuves vérifiables.
Il produit une grille renseignée, des écarts classés par criticité et un rapport d'audit servant de base au plan d’action.
Les différents types d'audit de qualité logicielle
Un audit peut être classé selon son objet ou selon la relation entre l’auditeur et l’organisation auditée.
Dans les secteurs réglementés, l’IEC 62304 encadre le cycle de vie des logiciels de dispositifs médicaux, en complément des exigences de management de la qualité de l’ISO 13485. Dans l’automobile, l’ISO 26262 et ASPICE couvrent respectivement la sécurité fonctionnelle et l’évaluation des processus.
L’ISO/IEC 25010 fournit un modèle de caractéristiques pour évaluer la qualité d’un produit logiciel.
Cinq signaux qui déclenchent un audit
1. Les régressions se répètent
Des fonctionnalités déjà validées cassent après les livraisons. Ces régressions peuvent révéler une couverture mal répartie, des tests de non-régression fragiles ou des contrôles incapables d’intercepter certains défauts avant leur arrivée en production.
2. Les délais de livraison dérivent
Les validations s’allongent et les anomalies apparaissent tardivement. Ces retards peuvent signaler des tests trop lents, des environnements instables ou une gestion des défauts qui ne suit plus le rythme de développement.
3. L'équipe ou le prestataire change
Un changement d’équipe expose les dépendances aux connaissances individuelles. L’audit qualité vérifie alors si processus, responsabilités, exigences et preuves sont suffisamment documentés pour maintenir la continuité du dispositif malgré le changement d’interlocuteurs.
4. Une certification ou une due diligence approche
Une certification, une acquisition ou une due diligence exige des éléments vérifiables. L’audit permet d’identifier en amont les écarts de conformité et de réunir les preuves nécessaires pour démontrer la maîtrise des processus.
5. Le produit connaît une croissance rapide
Applications, équipes et livraisons changent d’échelle. L’audit détermine si le périmètre du dispositif QA, ses ressources et ses contrôles suivent cette croissance ou si la maturité des pratiques devient insuffisante.
La méthode en 7 étapes
Un audit exploitable cadre le périmètre, réunit les preuves, qualifie les écarts et les transforme en actions suivies.
Étape 1 : cadrer le périmètre et le référentiel
Définissez le périmètre : applications, environnements, équipes et période. Le contrôle couvre les étapes incluses dans le périmètre, des exigences à la maintenance.
Choisissez ensuite le référentiel : IEEE 730 pour l’assurance qualité logicielle, IEEE 1028 pour les revues et audits, ISO 9001 pour le management de la qualité, ISO/IEC 25010 pour la qualité du produit, CMMI et TMMi pour la maturité des processus.
La grille d'audit associe chaque critère à une preuve attendue et à un éventuel écart. En secteur réglementé, lorsqu’un référentiel exige une activité documentée, l’absence de preuve peut constituer une non-conformité.
Question d’audit : le périmètre, le référentiel et les preuves attendues permettent-ils d’établir chaque constat objectivement ?
Étape 2 : auditer le plan d'assurance qualité
Le plan d'assurance qualité (PAQ) précise :
- objectifs et périmètre ;
- rôles et responsabilités ;
- processus et référentiels ;
- vérification et validation ;
- gestion des anomalies et changements ;
- documentation, mesures et reporting.
Le PAQ organise l’assurance qualité du projet. Le plan de test définit les tests : périmètre, niveaux, responsabilités, environnements, calendrier et critères d’entrée et de sortie.
Le responsable qualité ou QA Lead répond du PAQ. L’audit contrôle sa date de révision, son historique et sa cohérence avec les pratiques. Un PAQ obsolète ne décrit plus le dispositif réel.
Question d’audit : le PAQ et le plan de test sont-ils à jour, cohérents entre eux et appliqués par les équipes ?
Étape 3 : auditer le dispositif de test
L’audit examine les tests unitaires, d’intégration, système, d’acceptation et tests de bout en bout, ainsi que la couverture du code, des exigences, des risques et des parcours utilisateurs.
Les tests de performance, tests de sécurité, d’accessibilité et tests de compatibilité navigateurs et mobiles sont contrôlés selon les exigences du produit.
L’audit vérifie aussi s’il est pertinent de passer du test manuel à l'automatisation. Les contrôles répétables se prêtent à l’automatisation ; les tests manuels ou exploratoires restent utiles lorsque l’analyse humaine est nécessaire.
L’audit mesure la durée de non-régression, le taux d’automatisation, le coût de maintenance, les tests flaky ou désactivés, ainsi que la stabilité des environnements et des données. La qualité du code n’est examinée que si elle affecte la testabilité ou la maintenance.
Trois questions à poser pendant l’audit
- Quels risques ne sont couverts par aucun test pertinent ?
- Quels tests sont instables, désactivés ou inutilement automatisés ?
- Quel effort l’équipe consacre-t-elle à maintenir la suite ?
Ces constats permettent d’évaluer si l’outillage soutient réellement la stratégie de test.
Question d’audit : les tests couvrent-ils les bons risques, au bon niveau et avec un mode d’exécution adapté ?
Étape 4 : auditer la traçabilité et les anomalies
La traçabilité suit la chaîne :
exigence → cas de test → résultat → anomalie → correction → nouveau test
Un tiers doit pouvoir reproduire le test grâce aux prérequis, données, étapes et résultats attendus. L’audit contrôle aussi la sévérité, la priorité, le délai de correction et le taux de réouverture des anomalies. Une analyse de cause racine est recherchée pour les défauts critiques ou récurrents.
Question d’audit : peut-on retracer chaque anomalie, justifier sa priorité et démontrer que les causes des défauts critiques sont traitées ?
Étape 5 : auditer l'intégration au cycle et à l'équipe
Dans la CI/CD, les quality gates bloquent une livraison lorsqu’un critère défini échoue. Des tests continus dans un pipeline permettent d’exécuter les contrôles au fil des changements. Leur intégration CI/CD rapproche la validation du développement et de la livraison.
L’audit examine également la culture qualité : revue de code, TDD et Definition of Done. L’ingénieur assurance qualité contribue à la stratégie de test, à l’analyse des résultats et à l’amélioration des pratiques.
Question d’audit : les contrôles qualité sont-ils intégrés au cycle et capables de bloquer une livraison qui ne respecte pas les critères définis ?
Étape 6 : chiffrer le coût de la non-qualité
Le coût de la qualité distingue les dépenses de prévention et d’évaluation des coûts liés aux défaillances.
Détecter un défaut tôt limite les reprises, tandis qu’une détection tardive peut mobiliser davantage d’équipes et retarder la livraison. Les coûts invisibles comprennent notamment la perte de productivité et les interruptions de service.
Le 19 juillet 2024, une mise à jour défectueuse de CrowdStrike a provoqué des crashs sur des systèmes Windows. L’entreprise a ensuite renforcé ses tests, ses contrôles de validation et le déploiement progressif.
Question d’audit : les défauts sont-ils détectés assez tôt pour limiter leur coût et leur impact sur les utilisateurs et les opérations ?
Étape 7 : restituer, prioriser et suivre
Le rapport d'audit distingue le constat, fondé sur une preuve, de la recommandation. Les écarts sont classés par criticité, puis placés dans une matrice impact/effort.
Chaque action reçoit un responsable, une échéance et un indicateur. Le plan d'action peut suivre la couverture des exigences, le taux de réussite des tests, les défauts critiques, les réouvertures, la durée de non-régression, les délais de correction et les incidents en production.
Ces indicateurs orientent les décisions. Une hausse des défauts critiques après livraison doit conduire à revoir les contrôles ou les critères de passage en production.
Question d’audit : les KPI permettent-ils de vérifier que les actions réduisent réellement les défauts, les délais et les incidents ?
Ce qu'un audit trouve, dans 9 cas sur 10
Un audit révèle souvent moins un manque de tests qu’un écart entre le dispositif prévu et son fonctionnement réel.
Ces constats doivent être confrontés au contexte des équipes QA, au niveau de criticité du produit et aux exigences applicables. L’audit apporte ce qu’une simple checklist ne fournit pas : la preuve et la hiérarchisation. Il distingue ainsi un écart mineur d’un constat susceptible d’affecter la qualité, la conformité ou la livraison.
Livrables, durée et personnes à mobiliser
L’audit produit quatre livrables : un rapport de constats, une grille d'audit renseignée, un plan d'action priorisé et un tableau de bord destiné au suivi des écarts.
Sa durée dépend du périmètre. Quelques jours peuvent suffire pour une application et une équipe ; plusieurs semaines peuvent être nécessaires pour un portefeuille complet. Le nombre d’environnements, la maturité documentaire, les contraintes réglementaires et l’accessibilité des preuves font varier cette durée.
Pour un audit ciblé sur une application, la mobilisation peut être estimée ainsi :
Ces volumes correspondent au temps de mobilisation des interlocuteurs, et non à la durée totale de réalisation de l’audit. Ils doivent être adaptés à la taille du périmètre, au nombre d’équipes et à la disponibilité des preuves.
Les outils
Les outils ne remplacent ni le référentiel ni la méthode d’audit. Ils facilitent la collecte des preuves, la traçabilité et l’analyse du dispositif. Lorsque le volume de tests augmente, passer l'automatisation à l'échelle suppose aussi de maîtriser leur exécution et leur maintenance.
Les solutions de gestion des tests et ALM centralisent exigences, cas de test, résultats et anomalies. Le choix des outils de test QA dépend notamment du périmètre et des technologies utilisées. Pour les applications web, les frameworks d'automatisation web structurent l’exécution et la maintenance des scénarios automatisés.
Les outils d’automatisation et de maintenance permettent d’exécuter les tests de manière répétable et de suivre leur stabilité. Dans ce cadre, Thunders permet notamment de créer des tests auto adaptatifs afin de limiter la maintenance liée aux évolutions de l’application.
Les fonctions de traçabilité et de reporting relient exigences, tests et anomalies, puis fournissent les indicateurs nécessaires au suivi du plan d'action.
Le choix de l’outillage doit rester cohérent avec la maturité de l’équipe et les constats de l’audit. Un outil supplémentaire ne corrige pas à lui seul un processus incomplet, une traçabilité défaillante ou des critères de validation mal définis.
Checklist pour l'audit de qualité logicielle
1. Périmètre et référentiel
- Définissez les applications, environnements, équipes et périodes à auditer.
- Sélectionnez les normes et référentiels applicables à votre contexte.
- Associez chaque critère de la grille d'audit à une preuve.
2. Plan d'assurance qualité
- Vérifiez la date de révision du plan d'assurance qualité.
- Comparez les processus documentés avec les pratiques réellement appliquées.
- Contrôlez les responsabilités et preuves prévues dans le PAQ.
3. Dispositif de test
- Répartissez les tests par niveau et par risque produit.
- Identifiez les tests instables, désactivés ou coûteux à maintenir.
- Vérifiez la couverture des principales exigences non fonctionnelles.
4. Traçabilité et anomalies
- Reliez chaque exigence à ses tests et résultats associés.
- Vérifiez la reproductibilité et la criticité des anomalies enregistrées.
- Mesurez les délais de correction et les taux de réouverture.
5. Cycle de développement et équipe
- Vérifiez l'intégration des contrôles qualité dans le cycle.
- Contrôlez les règles de blocage appliquées dans la CI/CD.
- Examinez les revues de code et la Definition of Done.
6. Coût de la non-qualité
- Identifiez les coûts liés aux défauts internes et externes.
- Intégrez retards, incidents et mobilisation des équipes au calcul.
- Reliez les principaux coûts aux écarts qui les provoquent.
7. Restitution et suivi
- Classez chaque écart selon son risque et sa criticité.
- Transformez les recommandations en actions attribuées et datées.
- Suivez leur réalisation avec des indicateurs définis à l'avance.
