Qu’est-ce que la vérification logicielle ? Ce qu’elle contrôle — et ce qu’elle ne contrôle pas

La vérification logicielle désigne l’ensemble des contrôles visant à déterminer si un produit ou un résultat d’ingénierie est conforme aux exigences et spécifications qui lui sont applicables. La question pratique est : « a-t-il été construit conformément à ce qui a été défini ? ». Dans le cadre d’ingénierie des systèmes de la NASA, la vérification compare le produit à ses exigences ou spécifications ; cette distinction aide aussi à comprendre les programmes, composants et livrables logiciels. NASA : vérification de produit

La vérification n’est pas une activité unique qui se déroule nécessairement à la fin. Elle peut s’appliquer à différents livrables pendant le développement : une spécification peut être examinée au regard de besoins convenus auparavant, une conception au regard des exigences, et une implémentation au regard de la conception ou de critères techniques. Le référentiel doit être explicite : sans exigence identifiable, il est impossible d’indiquer clairement quelle condition a été contrôlée. L’enchaînement dépend du projet et ne doit pas être pris pour une recette universelle.

Vérifier ne revient pas non plus à déclarer que tous les logiciels sont corrects, sûrs ou utiles dans toutes les situations. Un contrôle apporte des éléments probants pour un périmètre défini, selon des critères et dans des conditions définis. Par exemple, l’examen d’un calcul particulier ne démontre pas automatiquement que toutes les fonctions, versions, données d’entrée ou tous les environnements se comportent correctement.

Les objets de vérification peuvent inclure les exigences, la conception, le code exécutable, les composants intégrés et la documentation associée, à condition qu’il existe des critères applicables auxquels les comparer. La page de la NASA décrit la vérification du produit final comme un contrôle de conformité aux exigences ou spécifications et souligne l’importance de maintenir une configuration de référence maîtrisée. La même logique s’applique au périmètre : chaque affirmation doit préciser l’élément et la version examinés. NASA : vérification de produit

Dans un exemple simple, une exigence pourrait indiquer qu’une application doit calculer un total à partir de quantités et de prix. La vérification peut contrôler que la formule implémentée correspond à la règle spécifiée et que le résultat concorde avec le résultat attendu pour les cas examinés. Si la règle elle-même est mal formulée — par exemple, si elle omet une remise nécessaire dans l’utilisation réelle —, le programme pourrait la respecter sans pour autant répondre au besoin. C’est pourquoi il ne faut pas traiter vérification et validation comme des synonymes.

La documentation compte également, car elle définit ce qui est considéré conforme et indique quelle activité a été menée. Un plan de vérification et de validation peut consigner les responsabilités, les documents applicables, les méthodes et les matrices reliant exigences et éléments probants. Le plan publié par la NASA distingue les méthodes de vérification et de validation, leur mise en œuvre et les matrices d’exigences. La traçabilité permet de repérer la couverture et les lacunes, mais une matrice complète ne prouve pas à elle seule que chaque résultat est correct. NASA : plan type de vérification et validation

La vérification peut combiner plusieurs formes d’examen. Un examen humain compare des documents ou des modifications à des critères définis ; une analyse peut rechercher des propriétés ou des incohérences sans exécuter le programme ; un essai observe le comportement du logiciel en l’exécutant dans des conditions choisies. Les informations du NIST sur ses formations à la vérification et validation des logiciels mettent en avant la documentation des éléments probants et l’emploi de techniques de ces deux types, même si ses exemples portent sur des feuilles de calcul de laboratoire et ne constituent pas une liste exhaustive applicable à tous les projets. NIST : formation à la vérification et validation des logiciels

Exemple de contrôle par rapport à une spécification

Supposons qu’une spécification exige qu’un système rejette une demande lorsqu’un champ obligatoire est absent. Un examen pourrait vérifier que l’exigence est définie et que la conception prévoit ce cas ; un essai pourrait envoyer une demande incomplète et comparer la réponse observée au résultat attendu. Chaque méthode répond à une question différente : l’examen porte sur les artefacts et le raisonnement, tandis que l’essai observe un comportement pour des entrées et des conditions précises.

Le simple fait d’exécuter des essais ne permet pas d’examiner toutes les entrées possibles. Le résultat dépend des cas sélectionnés, de la version testée et de l’environnement utilisé. Ainsi, « les essais ont réussi » signifie qu’aucun écart n’a été détecté dans les contrôles effectués, et non que l’absence de défauts a été démontrée. Les éléments probants sont plus faciles à interpréter si le lien entre exigence, critère d’acceptation, cas exécuté, résultat et version du produit est conservé.

Une pratique utile de consignation

Pour qu’une autre personne comprenne ce qui a été vérifié, il est utile de consigner l’élément et la version examinés, l’exigence associée, la méthode appliquée, les conditions pertinentes et le résultat. Lorsque les contrôles ou les audits comptent, cette trace permet d’expliquer le périmètre et d’examiner les modifications ultérieures. Le NIST présente la documentation des éléments probants et l’évaluation continue des logiciels comme des objectifs de ses ressources de formation destinées aux laboratoires ; le contenu précis de chaque registre doit être adapté au contexte. NIST : formation à la vérification et validation des logiciels

La vérification demande si le produit est conforme aux exigences ou spécifications définies. La validation demande s’il répond à l’usage prévu et aux besoins pertinents dans son contexte d’utilisation. La NASA exprime cette différence au moyen de deux questions : le produit a-t-il été réalisé correctement au regard de ce qui était spécifié, et répond-il à ce que le client souhaitait dans l’environnement d’utilisation ? NASA : vérification de produit

Le tableau résume la différence d’objectif décrite par la NASA ; il ne signifie pas que chaque activité utilise une méthode exclusive ni qu’une frontière stricte sépare les techniques. NASA : vérification de produit

Prenons une application qui calcule le coût d’une livraison. Si la spécification indique qu’elle doit additionner un tarif de base et un supplément, vérifier ce calcul relève de la vérification. Se demander si l’application prend en compte les besoins réels — par exemple, si le parcours permet d’indiquer la destination et le type de livraison proposé par le service — relève de la validation. Le premier contrôle peut réussir alors que le second révèle que la solution définie ne répond pas à l’usage attendu.

C’est pourquoi il ne suffit pas de dire qu’un produit « a été vérifié » sans préciser le référentiel et le périmètre. La validation ne remplace pas non plus tous les contrôles de conformité aux spécifications : les deux perspectives peuvent être nécessaires et complémentaires. Les processus décrits par la NASA distinguent leurs objectifs, tout en reconnaissant que certaines activités peuvent se ressembler dans la pratique. L’appellation dépend de la question posée, et pas seulement du fait que l’activité s’appelle essai ou examen.

Les éléments probants peuvent prendre la forme de résultats d’essais, d’observations issues d’examens, d’analyses consignées ou de matrices reliant exigences et contrôles. Ils ne prouvent pas tous la même chose : un résultat d’exécution étaye une observation pour des entrées et un environnement précis ; un examen peut consigner qu’un artefact a été évalué selon des critères. La conclusion ne doit pas aller au-delà des éléments disponibles ni s’étendre à des versions ou conditions qui n’ont pas été examinées.

La traçabilité aide à suivre le lien entre une exigence et l’activité destinée à la contrôler. Le plan type de la NASA propose une matrice de vérification des exigences et une matrice de validation, en plus de la documentation des méthodes et activités. Cette structure permet d’organiser les éléments probants ; elle ne garantit pas automatiquement que les exigences soient bien formulées, complètes ou représentatives des besoins des utilisateurs. NASA : plan type de vérification et validation

Par exemple, si une règle de calcul change, savoir quels exigences, composants et cas de contrôle lui sont associés permet d’examiner les conséquences de la modification. Mais un lien documentaire peut être obsolète ou ne pas couvrir un comportement important. La gestion des versions et l’examen des éléments probants restent nécessaires ; une liste de cases cochées n’est utile que si elle décrit des activités réelles, des résultats interprétables et l’artefact adéquat.

La vérification est une pratique délimitée, pas une preuve mathématique de perfection. Des défauts peuvent subsister parce que certains cas n’ont pas été examinés, que les critères étaient incomplets ou que l’environnement réel diffère de celui utilisé. Il est également possible de respecter à la lettre une spécification qui ne représente pas correctement le besoin. Une déclaration responsable précise donc ce qui a été examiné, selon quel référentiel et dans quelles conditions, au lieu d’affirmer que le logiciel est exempt d’erreurs.

Dans les projets à haut risque ou soumis à des exigences de contrôle, l’indépendance de l’examen peut être importante. Le glossaire du NIST décrit la vérification et validation indépendantes comme un examen, une analyse et des essais menés par une tierce partie objective pour évaluer à la fois la définition des exigences et la mise en œuvre des fonctions et exigences de sécurité. Cette description correspond à IV&V ; elle ne signifie pas que tout projet a nécessairement besoin d’une équipe externe ni que l’indépendance élimine les limites de couverture. NIST : glossaire de la vérification et validation indépendantes

Pour interpréter une affirmation de vérification ou planifier un contrôle, les questions suivantes permettent d’en préciser le périmètre :

• Quel produit, composant, document et quelle version ont été examinés ?
• Par rapport à quelle exigence, spécification ou quel critère la comparaison a-t-elle été faite ?
• Quelle méthode a été appliquée et dans quelles conditions ?
• Quels éléments probants ont été consignés, et quels cas ne couvrent-ils pas ?
• La question portait-elle sur la conformité à ce qui était spécifié ou sur l’adéquation à l’usage prévu ?

La norme ISO/IEC/IEEE 12207 propose un cadre de processus du cycle de vie logiciel, mais les sources réunies pour cet article ne comprennent pas le texte officiel de la norme. Ce glossaire n’attribue donc aucune exigence précise à cette norme et ne présente pas de recette normative. Les orientations exposées ici s’appuient principalement sur la documentation de la NASA concernant la vérification et la validation des produits et sur les ressources du NIST consacrées aux éléments probants et à l’IV&V ; les techniques spécifiques doivent être choisies selon le système, ses risques et les obligations applicables. NASA : vérification de produit NIST : IV&V