Vérification, validation et certification

La vérification détermine si une sortie satisfait ses entrées et exigences spécifiées. Elle peut s'appuyer sur une revue, une analyse, une inspection, une démonstration ou un essai. La méthode choisie doit être adaptée à l'affirmation : une inspection visuelle ne peut pas vérifier un comportement temporel, tandis qu'un essai fonctionnel peut ne pas démontrer une contrainte interne de conception.

Une preuve de vérification devrait identifier :

• l'exigence ou la propriété examinée ;
• la configuration du système et l'environnement d'essai ;
• la procédure, les entrées et les critères d'acceptation ;
• le résultat observé et toute déviation ;
• l'identité et la version de l'enregistrement produit.

La validation concerne l'usage prévu. Un système peut être parfaitement conforme à une spécification incomplète ou inadaptée et néanmoins échouer en exploitation. La validation exige donc des scénarios, utilisateurs, interfaces, conditions environnementales et hypothèses représentatifs.

En pratique, la validation révèle souvent des lacunes que les essais de composants isolés ne peuvent pas mettre en évidence : règles opérationnelles ambiguës, interactions inattendues, modes dégradés insuffisants ou hypothèses incorrectes sur le comportement humain.

Une évaluation indépendante examine l'adéquation des processus, argumentaires et preuves sans prendre la responsabilité de la conception. La certification ou l'autorisation utilise ensuite le cadre institutionnel et réglementaire applicable pour déterminer si la démonstration requise a été apportée.

L'indépendance ne supprime pas le besoin de dialogue technique. Elle modifie la responsabilité et le poids probatoire de la conclusion.

Une preuve n'est valable que pour la configuration qu'elle examine réellement. Version logicielle, variante matérielle, jeu de paramètres, moyens d'essai, baseline d'exigences et anomalies connues peuvent tous affecter son applicabilité.

C'est pourquoi la gestion de configuration ne peut pas se réduire au nommage des fichiers. Un rapport parfaitement archivé mais rattaché à la mauvaise baseline reste la mauvaise preuve.

• exigences impossibles à tester objectivement ;
• liens de traçabilité créés sans revue sémantique ;
• résultats d'essais détachés de leur configuration ;
• anomalies closes administrativement sans justification technique ;
• argumentaires recopiés qui ne correspondent plus à la conception actuelle ;
• preuves de certification assemblées uniquement en fin de projet.

Le remède durable consiste à construire la chaîne de preuves tout au long du développement et à traiter les incohérences comme des défauts techniques plutôt que comme des problèmes de mise en forme.