Canevas 2 — Dossier de validation client / Cahier de recette¶
1. Objet du document¶
1.1 Finalité du dossier de validation¶
Cette partie précise l’objectif du dossier de validation.
Le dossier de validation décrit la manière dont le client vérifiera que le système livré répond bien au besoin exprimé dans le cahier des charges. Il ne s’agit pas seulement d’une liste de tests, mais d’un document contractuel et opérationnel qui définit les conditions d’acceptation du système.
Il permet d’éviter que la validation soit improvisée en fin de projet. Les critères de validation doivent être connus dès le début afin que le fournisseur puisse concevoir, développer et tester le système en cohérence avec les attentes du client.
Exemple :
Le présent document a pour objectif de définir la stratégie, les scénarios, les moyens, les procédures et les critères permettant de valider que le système livré répond aux besoins exprimés dans le cahier des charges. Il constitue la référence pour la recette client et l’acceptation finale du système.
1.2 Positionnement dans le cycle en V¶
Cette partie situe le dossier de validation dans le cycle en V.
Le dossier de validation est le pendant du cahier des charges sur la branche droite du cycle en V. Il s’appuie sur l’expression du besoin et permet, en fin de projet, de vérifier que le système livré satisfait bien les attentes du client.
Il est donc fortement lié :
Cahier des charges / expression du besoin
↔
Dossier de validation / cahier de recette
La validation ne doit pas être confondue avec les tests internes du fournisseur. Les tests unitaires, les tests d’intégration et les tests système vérifient que le produit est correctement construit. La validation client vérifie que le bon produit a été construit.
Exemple :
Le dossier de validation est établi à partir du cahier des charges et des exigences client. Il définit les essais et observations permettant de prononcer l’acceptation, l’acceptation sous réserve ou le refus de la solution livrée.
1.3 Responsabilité de rédaction et de validation¶
Cette partie précise qui rédige, qui contribue et qui approuve le dossier.
Le dossier de validation est idéalement rédigé par le client ou la maîtrise d’ouvrage, avec l’aide éventuelle du fournisseur pour préciser les moyens de test, les contraintes techniques et les conditions de réalisation. Dans certains projets, il peut être co-rédigé par le client et le fournisseur, mais il doit rester validé par le client, car il exprime les critères d’acceptation.
Exemple :
Rédaction principale : client / maîtrise d’ouvrage
Contribution : utilisateurs, exploitation, maintenance, sécurité, fournisseur
Validation : client / responsable métier / responsable projet
Exécution : client, fournisseur ou équipe mixte selon les essais
Approbation finale : client / autorité désignée pour la recette
1.4 Différence entre vérification et validation¶
Cette partie rappelle la distinction essentielle entre vérification et validation.
La vérification répond à la question :
Le système est-il conforme aux spécifications ?
La validation répond à la question :
Le système répond-il au besoin réel du client ?
Cette distinction est importante, car un système peut être conforme aux spécifications détaillées tout en ne répondant pas correctement au besoin opérationnel initial, si ce besoin a été mal exprimé, mal interprété ou insuffisamment validé.
Exemple :
Une fonction de transmission de données peut être techniquement conforme à la spécification, mais être insuffisante pour l’utilisateur si la fréquence d’envoi ne permet pas une supervision réellement exploitable. La validation doit donc vérifier l’adéquation au besoin d’usage, et pas seulement la conformité technique.
2. Références et documents applicables¶
2.1 Documents d’entrée¶
Cette partie liste les documents qui servent de base au dossier de validation.
Le dossier de validation doit s’appuyer sur des documents identifiés, versionnés et approuvés. Cela permet d’éviter qu’un test de validation soit basé sur une exigence obsolète ou ambiguë.
Exemples de documents d’entrée :
- Cahier des charges / expression du besoin
- Spécification système
- Spécification fonctionnelle globale
- Spécification fonctionnelle détaillée
- Dossier des modes nominal, dégradé, maintenance et secours
- Dossier d’architecture système
- Dossier d’interfaces
- Contraintes réglementaires ou normatives
- Exigences de sécurité, sûreté ou cybersécurité
- Contrat ou commande client
2.2 Documents de référence¶
Cette partie liste les documents utiles mais non nécessairement contractuels.
Il peut s’agir de normes, guides internes, anciennes procédures, plans d’installation, manuels d’exploitation ou retours d’expérience issus de systèmes similaires.
Exemple :
- Procédures d’exploitation existantes
- Manuel utilisateur d’un système précédent
- Rapport d’incident ou de retour d’expérience
- Normes internes de recette
- Procédure qualité projet
- Référentiel documentaire du client
2.3 Versions applicables¶
Cette partie précise les versions des documents utilisés.
Lors d’une validation, il est indispensable de savoir à quelle version du cahier des charges, de la spécification ou de l’architecture le système est comparé.
Exemple :
Cahier des charges : CDC-PRJ-001, version 1.3, approuvé le 12/04/2026
Spécification système : SYS-SPEC-001, version 2.1, approuvée le 03/05/2026
Dossier des modes de fonctionnement : SYS-MODES-001, version 1.0, approuvé le 16/05/2026
3. Périmètre de la validation¶
3.1 Éléments couverts par la validation¶
Cette partie précise ce qui sera effectivement validé.
Le périmètre doit couvrir les éléments livrés au client et les fonctions considérées comme nécessaires à l’acceptation du système.
Exemples :
- équipement matériel ;
- logiciel embarqué ;
- application serveur ;
- interface opérateur ;
- interface administrateur ;
- réseau de communication ;
- stockage local ;
- remontée des données ;
- gestion des alarmes ;
- procédures de maintenance ;
- sauvegarde et restauration ;
- documentation utilisateur et maintenance.
Exemple rédigé :
La validation couvre le fonctionnement de l’équipement embarqué, ses interactions avec le serveur applicatif, l’affichage des états sur l’interface opérateur, la génération des alarmes, la conservation locale des données en cas de perte de communication et la restitution des données après rétablissement du réseau.
3.2 Éléments exclus de la validation¶
Cette partie précise ce qui ne sera pas validé dans le cadre de ce dossier.
Cette section est très importante pour éviter des désaccords en fin de projet. Certains éléments peuvent être hors périmètre parce qu’ils relèvent d’un tiers, d’une autre phase projet, d’un autre contrat ou d’une validation réglementaire spécifique.
Exemples :
- validation du réseau Internet fourni par le client ;
- certification réglementaire externe ;
- validation d’un équipement tiers non fourni par le fournisseur ;
- tests de charge au-delà du nombre d’utilisateurs contractuellement prévu ;
- validation en environnement réel si seule une recette plateforme est prévue ;
- cybersécurité offensive avancée si non prévue au contrat.
Exemple rédigé :
La validation ne couvre pas la qualification du réseau Internet du site client. Les essais de communication seront réalisés sur le réseau mis à disposition pour la recette, sous réserve que celui-ci respecte les prérequis définis dans le dossier d’infrastructure.
3.3 Niveaux de validation¶
Cette partie décrit les différents niveaux de validation prévus.
Selon le type de projet, il peut y avoir plusieurs validations successives : validation sur banc, validation en plateforme d’intégration, validation sur site pilote, validation en production.
Exemples de niveaux :
- validation documentaire ;
- validation sur maquette ;
- validation sur banc de test ;
- validation en plateforme d’intégration ;
- validation sur site pilote ;
- validation en environnement opérationnel ;
- recette provisoire ;
- recette définitive.
Exemple rédigé :
La validation sera réalisée en deux étapes. Une première validation sera effectuée sur plateforme d’intégration afin de vérifier les fonctions principales et les modes dégradés. Une seconde validation sera effectuée sur site pilote afin de confirmer le comportement du système dans son environnement réel d’exploitation.
4. Stratégie générale de validation¶
4.1 Principe de validation¶
Cette partie décrit la logique générale retenue pour valider le système.
La stratégie peut combiner plusieurs méthodes : essais fonctionnels, observation en fonctionnement, simulation de défauts, vérification documentaire, inspection physique, analyse de logs, tests de reprise, démonstration opérateur.
Exemple :
La validation repose sur l’exécution de scénarios représentatifs du fonctionnement réel du système. Chaque scénario est associé à une ou plusieurs exigences client et donne lieu à l’observation d’un résultat attendu. La validation est prononcée lorsque les critères d’acceptation sont satisfaits et qu’aucune anomalie bloquante n’est ouverte.
4.2 Validation par scénario¶
Cette partie précise que la validation est organisée autour de scénarios.
Un scénario de validation doit représenter une situation significative pour le client : démarrage, fonctionnement normal, perte réseau, panne capteur, mode maintenance, restauration après incident, etc.
Exemples de scénarios :
- démarrage complet du système ;
- acquisition et affichage des mesures ;
- génération d’une alarme sur seuil ;
- perte de communication avec le serveur ;
- fonctionnement local en mode dégradé ;
- retour de communication et resynchronisation ;
- passage en mode maintenance ;
- sauvegarde et restauration de la configuration ;
- consultation des historiques ;
- arrêt contrôlé du système.
4.3 Validation par exigence¶
Cette partie explique comment chaque exigence sera couverte par un ou plusieurs essais.
Une exigence importante ne doit pas rester sans test associé. La validation doit donc inclure une matrice de traçabilité entre les exigences et les scénarios de validation.
Exemple :
Exigence : SYS-COM-004
Le système doit conserver localement les données en cas de perte de communication serveur.
Scénario associé : VAL-COM-002
Simulation d’une perte réseau de 30 minutes et vérification de la conservation locale des données.
Critère de succès :
Toutes les données acquises pendant la coupure sont transmises au serveur après rétablissement de la communication.
4.4 Validation documentaire¶
Cette partie décrit les documents qui doivent être présents, complets et acceptables pour permettre la recette.
La validation ne porte pas uniquement sur le système technique. Elle porte aussi sur les livrables documentaires nécessaires à l’exploitation, la maintenance, l’installation ou la formation.
Exemples de documents à vérifier :
- manuel utilisateur ;
- manuel administrateur ;
- manuel de maintenance ;
- dossier d’installation ;
- dossier de configuration livrée ;
- rapport de tests fournisseur ;
- dossier de sauvegarde et restauration ;
- dossier d’architecture ;
- liste des versions logicielles et matérielles livrées.
4.5 Validation progressive¶
Cette partie précise si la validation est réalisée en une seule fois ou progressivement.
Pour les systèmes complexes, il est souvent préférable de procéder par étapes, afin de ne pas découvrir en fin de projet des anomalies bloquantes sur des fonctions de base.
Exemple :
La validation sera conduite progressivement. Les fonctions de base seront validées en premier lieu : alimentation, démarrage, communication, acquisition des données et affichage des états. Les fonctions avancées, notamment les modes dégradés, les reprises après incident et les procédures de maintenance, seront validées dans un second temps.
5. Environnement de validation¶
5.1 Description générale de l’environnement¶
Cette partie décrit l’environnement dans lequel les essais de validation seront réalisés.
L’environnement de validation doit être représentatif de l’environnement réel d’exploitation, ou les écarts doivent être clairement identifiés et acceptés.
Exemples d’environnements :
- banc de test fournisseur ;
- plateforme d’intégration client ;
- salle de recette ;
- site pilote ;
- environnement de préproduction ;
- environnement de production sous conditions contrôlées.
Exemple rédigé :
Les essais de validation seront réalisés sur une plateforme représentative comprenant un équipement embarqué, un serveur applicatif de test, une base de données dédiée, une interface opérateur et un réseau local isolé.
5.2 Configuration matérielle¶
Cette partie décrit les matériels utilisés pendant la validation.
Il faut identifier les équipements testés, leurs versions, leurs numéros de série, leurs configurations et les éventuels équipements de simulation.
Exemples :
- équipement embarqué version matérielle HW-2.1 ;
- carte électronique principale ;
- module de communication ;
- alimentation ;
- capteurs réels ou simulés ;
- actionneurs réels ou charges simulées ;
- banc de test ;
- PC opérateur ;
- serveur de validation ;
- routeur ou switch réseau.
5.3 Configuration logicielle¶
Cette partie décrit les logiciels utilisés pendant la validation.
Les versions doivent être précisément identifiées. Cela est indispensable pour pouvoir reproduire un essai ou interpréter une anomalie.
Exemples :
- firmware embarqué version 1.4.2 ;
- application serveur version 2.0.0 ;
- interface web version 2.0.0 ;
- base de données version 15 ;
- système d’exploitation du serveur ;
- scripts de déploiement ;
- outils de diagnostic ;
- outils de simulation.
5.4 Configuration réseau¶
Cette partie décrit le réseau utilisé pour la validation.
Elle doit préciser les connexions, les adresses IP, les VLAN éventuels, les règles de filtrage, les accès distants, les limitations et les moyens de simulation de perte réseau.
Exemple :
Réseau de validation :
- équipement embarqué : 192.168.10.20
- serveur applicatif : 192.168.10.10
- poste opérateur : 192.168.10.30
- protocole applicatif : HTTPS / MQTT / Modbus TCP
- accès Internet : désactivé pendant certains essais
- simulation de coupure réseau : déconnexion physique ou règle pare-feu temporaire
5.5 Données de test¶
Cette partie décrit les données utilisées pour les essais.
Les données doivent être suffisamment représentatives pour valider les comportements attendus : cas nominal, valeurs limites, erreurs, données absentes, données incohérentes, données historiques.
Exemples :
- configuration nominale ;
- seuils d’alarme ;
- profils de mesures simulées ;
- historique d’événements ;
- comptes utilisateurs ;
- jeux de données de reprise après coupure ;
- fichiers de configuration volontairement erronés.
5.6 Écarts avec l’environnement réel¶
Cette partie identifie les différences entre l’environnement de validation et l’environnement final.
Ces écarts doivent être explicités, car ils peuvent limiter la portée des résultats.
Exemple :
La validation est réalisée avec des charges simulées en lieu et place des actionneurs réels. Les résultats permettent de valider la logique de commande, mais ne constituent pas une validation complète du comportement électromécanique en charge réelle.
6. Moyens et équipements de validation¶
6.1 Moyens matériels¶
Cette partie liste les équipements nécessaires à l’exécution des essais.
Exemples :
- banc de test ;
- alimentation stabilisée ;
- multimètre ;
- oscilloscope ;
- analyseur logique ;
- simulateur de capteurs ;
- charge électronique ;
- switch réseau ;
- routeur ;
- PC de supervision ;
- serveur de test ;
- dispositif de coupure réseau ;
- outillage de maintenance.
6.2 Moyens logiciels¶
Cette partie liste les logiciels nécessaires.
Exemples :
- outil de configuration ;
- interface opérateur ;
- outil de simulation ;
- outil de diagnostic ;
- outil de lecture des logs ;
- outil de requête base de données ;
- outil de capture réseau ;
- scripts d’injection de données ;
- scripts de sauvegarde et restauration.
6.3 Moyens humains¶
Cette partie précise les rôles nécessaires pendant la validation.
La validation peut nécessiter la présence du client, du fournisseur, d’un exploitant, d’un technicien de maintenance, d’un administrateur système ou d’un responsable qualité.
Exemple :
Responsable de validation : pilote l’exécution des essais.
Représentant client : constate les résultats et prononce l’acceptation.
Représentant fournisseur : assiste techniquement et analyse les anomalies.
Exploitant : vérifie la conformité aux usages opérationnels.
Technicien maintenance : vérifie les procédures de diagnostic et d’intervention.
6.4 Moyens de preuve¶
Cette partie décrit les éléments qui permettront de prouver qu’un essai a été réalisé et réussi.
Exemples :
- fiche de test signée ;
- capture d’écran ;
- fichier de logs ;
- export de base de données ;
- mesure instrumentée ;
- rapport automatique ;
- photographie de l’installation ;
- enregistrement vidéo ;
- procès-verbal d’essai.
Exemple rédigé :
Pour chaque scénario de validation, les résultats seront consignés dans une fiche de test. Les preuves associées pourront inclure des captures d’écran, des extraits de journaux système, des mesures électriques ou des exports de données.
7. Critères d’entrée en validation¶
7.1 Conditions préalables générales¶
Cette partie définit les conditions minimales à satisfaire avant de démarrer la validation.
La validation ne doit pas commencer si le système est instable, incomplet ou si les documents nécessaires sont absents.
Exemples :
- système installé dans l’environnement de validation ;
- versions matérielles et logicielles identifiées ;
- configuration de test chargée ;
- moyens de test disponibles ;
- procédures de validation approuvées ;
- utilisateurs de test créés ;
- accès réseau opérationnels ;
- sauvegarde initiale réalisée ;
- anomalies bloquantes préalablement corrigées.
7.2 Documents nécessaires avant validation¶
Cette partie liste les documents qui doivent être disponibles avant la recette.
Exemples :
- cahier des charges approuvé ;
- spécification système approuvée ;
- dossier d’architecture approuvé ;
- plan de vérification fournisseur ;
- rapports de tests unitaires ;
- rapports de tests d’intégration ;
- manuel utilisateur provisoire ;
- manuel maintenance provisoire ;
- dossier de configuration livrée.
7.3 État des tests fournisseur¶
Cette partie précise le niveau de vérification interne attendu avant la validation client.
La validation client ne doit pas remplacer les tests fournisseur. Elle doit intervenir après que le fournisseur a lui-même vérifié le système.
Exemple :
La validation client ne pourra démarrer que si les tests unitaires, les tests d’intégration et les tests système fournisseur ont été exécutés avec succès, ou si les anomalies restantes ont été acceptées comme non bloquantes par le client.
7.4 Gestion des anomalies ouvertes avant validation¶
Cette partie précise comment traiter les anomalies déjà connues.
Certaines anomalies mineures peuvent être acceptées pour démarrer la validation. En revanche, les anomalies bloquantes doivent généralement être corrigées avant recette.
Exemple :
Anomalie bloquante : empêche le démarrage de la validation.
Anomalie majeure : peut empêcher un scénario critique.
Anomalie mineure : peut être acceptée sous réserve.
Anomalie cosmétique : n’empêche pas la validation.
8. Scénarios de validation nominale¶
8.1 Démarrage du système¶
Cette partie décrit les essais permettant de vérifier que le système démarre correctement.
Objectif :
Vérifier que le système passe d’un état arrêté à un état opérationnel sans erreur bloquante.
Exemple de scénario :
1. Alimenter l’équipement.
2. Démarrer le serveur applicatif.
3. Lancer l’interface opérateur.
4. Vérifier que l’équipement s’initialise.
5. Vérifier que la communication avec le serveur est établie.
6. Vérifier que l’état affiché est cohérent.
Résultat attendu :
- aucune erreur bloquante n’est générée ;
- l’équipement passe en mode nominal ;
- l’interface opérateur affiche l’état connecté ;
- les premières données sont visibles dans l’application.
8.2 Fonctionnement nominal¶
Cette partie décrit la validation du fonctionnement courant.
Objectif :
Vérifier que les fonctions principales sont actives et cohérentes en fonctionnement normal.
Exemples de points à vérifier :
- acquisition des mesures ;
- affichage des états ;
- mise à jour périodique des données ;
- absence d’alarme injustifiée ;
- cohérence des valeurs affichées ;
- horodatage correct ;
- stockage des événements ;
- consultation des historiques.
8.3 Acquisition et traitement des données¶
Cette partie vérifie que les données sont correctement acquises, traitées, stockées et affichées.
Exemple :
Exigence associée :
Le système doit acquérir la tension batterie toutes les 10 secondes.
Essai :
Injecter une tension connue ou simulée, attendre plusieurs cycles d’acquisition, vérifier l’affichage, le stockage et l’horodatage.
Résultat attendu :
La valeur affichée correspond à la valeur injectée dans la tolérance définie. Les mesures sont enregistrées avec un horodatage cohérent.
8.4 Commandes et actions opérateur¶
Cette partie valide les actions que l’utilisateur peut réaliser depuis l’interface ou les commandes prévues.
Exemples :
- acquitter une alarme ;
- lancer un diagnostic ;
- modifier un seuil autorisé ;
- demander un redémarrage contrôlé ;
- passer en mode maintenance ;
- exporter un rapport.
Point d’attention :
Chaque commande doit être vérifiée non seulement en cas nominal, mais aussi avec les droits utilisateurs appropriés. Une commande critique ne doit pas être accessible à un utilisateur non autorisé.
8.5 Communication avec les systèmes externes¶
Cette partie valide les échanges avec les serveurs, équipements tiers ou applications externes.
Exemples :
- transmission des mesures vers un serveur ;
- réception d’une configuration ;
- synchronisation horaire ;
- remontée d’alarmes ;
- échange avec une supervision externe ;
- export de données vers un outil tiers.
8.6 Interface utilisateur¶
Cette partie valide que l’interface permet effectivement à l’utilisateur d’exploiter le système.
Il ne s’agit pas uniquement de vérifier que les écrans s’affichent, mais aussi qu’ils sont compréhensibles et exploitables.
Exemples de critères :
- les états sont visibles et compréhensibles ;
- les alarmes sont clairement identifiées ;
- les informations critiques sont accessibles rapidement ;
- les messages d’erreur sont interprétables ;
- les actions sensibles demandent une confirmation ;
- les droits utilisateurs sont respectés.
9. Scénarios de validation des modes dégradés¶
9.1 Perte de communication réseau¶
Cette partie valide le comportement du système lorsqu’il ne peut plus communiquer avec le serveur ou un système externe.
Objectif :
Vérifier que le système reste dans un état maîtrisé, conserve les données nécessaires et informe l’utilisateur.
Exemple de scénario :
1. Démarrer le système en mode nominal.
2. Vérifier que les données sont transmises au serveur.
3. Couper la liaison réseau.
4. Maintenir la coupure pendant 30 minutes.
5. Vérifier le comportement local de l’équipement.
6. Rétablir la liaison réseau.
7. Vérifier la retransmission des données stockées.
Résultat attendu :
- une alarme de perte de communication est générée ;
- les fonctions locales critiques restent actives ;
- les données sont conservées localement ;
- après retour réseau, les données sont transmises au serveur ;
- l’alarme est clôturée ou passe dans un état historisé.
9.2 Indisponibilité d’un capteur¶
Cette partie valide le comportement du système en cas de capteur absent, incohérent ou défaillant.
Exemple :
Débrancher ou simuler l’indisponibilité d’un capteur de température.
Vérifier que le système détecte l’anomalie.
Vérifier qu’une alarme est générée.
Vérifier que les fonctions dépendant de cette mesure passent dans un état sûr.
9.3 Défaut d’actionneur ou de sortie¶
Cette partie valide le comportement en cas d’impossibilité d’exécuter une commande.
Exemple :
Si le système commande la fermeture d’un relais mais ne détecte pas le retour d’état attendu, il doit générer une alarme, empêcher l’enchaînement d’actions dangereuses et informer l’opérateur.
9.4 Saturation du stockage local¶
Cette partie valide ce qui se passe lorsque le stockage local atteint une limite.
Ce cas est souvent oublié alors qu’il est important pour les systèmes embarqués communicants.
Points à vérifier :
- génération d’une alarme avant saturation complète ;
- politique d’écrasement ou de blocage ;
- conservation prioritaire des données critiques ;
- absence de plantage logiciel ;
- retour à la normale après libération d’espace.
9.5 Perte de synchronisation horaire¶
Cette partie valide le comportement lorsque le système ne peut plus synchroniser son horloge.
Exemple :
En cas de perte de synchronisation horaire, le système doit continuer à fonctionner localement, signaler l’anomalie et marquer les données avec une indication permettant d’identifier une incertitude d’horodatage.
9.6 Redémarrage après incident¶
Cette partie valide la capacité du système à redémarrer proprement après une coupure d’alimentation, un redémarrage logiciel ou une erreur interne.
Exemples de points à vérifier :
- conservation de la configuration ;
- absence de corruption des données ;
- reprise de la communication ;
- génération éventuelle d’un événement de redémarrage ;
- retour au mode nominal si les conditions sont satisfaites.
10. Scénarios de validation du mode maintenance¶
10.1 Passage en mode maintenance¶
Cette partie valide que le mode maintenance est accessible uniquement dans les conditions prévues.
Exemples de critères :
- accès réservé aux utilisateurs autorisés ;
- confirmation avant passage en maintenance ;
- journalisation de l’opération ;
- indication claire de l’état maintenance ;
- inhibition contrôlée des fonctions concernées.
10.2 Fonctions disponibles en maintenance¶
Cette partie vérifie les fonctions spécifiques à la maintenance.
Exemples :
- lecture des journaux ;
- test des entrées/sorties ;
- diagnostic de communication ;
- consultation des versions logicielles ;
- export de configuration ;
- remplacement d’un module ;
- réinitialisation contrôlée.
10.3 Inhibition temporaire d’alarmes¶
Cette partie valide la gestion des alarmes pendant les opérations de maintenance.
Point important :
L’inhibition d’alarmes doit être maîtrisée, limitée dans le temps si nécessaire, visible pour l’opérateur et journalisée.
Exemple :
Lorsqu’une alarme est inhibée pendant une intervention, le système doit afficher explicitement l’état d’inhibition et conserver dans les journaux l’identité de l’utilisateur, l’heure de début, l’heure de fin et le motif de l’inhibition.
10.4 Retour au mode nominal après maintenance¶
Cette partie valide que le système peut revenir correctement en fonctionnement normal.
Exemples de points à vérifier :
- réactivation des alarmes inhibées ;
- vérification de la configuration ;
- effacement ou historisation des états temporaires ;
- retour à l’acquisition normale ;
- communication active avec le serveur ;
- absence d’anomalie résiduelle.
11. Scénarios de validation de l’infrastructure¶
11.1 Serveur applicatif¶
Cette partie valide que le serveur applicatif fonctionne conformément aux attentes.
Exemples de points à vérifier :
- démarrage automatique ou documenté ;
- disponibilité de l’application ;
- communication avec les équipements ;
- accès des utilisateurs autorisés ;
- gestion des erreurs ;
- journalisation ;
- redémarrage contrôlé.
11.2 Base de données¶
Cette partie valide le stockage, la consultation et la cohérence des données.
Exemples :
- création des enregistrements ;
- horodatage ;
- consultation des historiques ;
- export de données ;
- absence de doublons critiques ;
- intégrité après redémarrage ;
- comportement en cas d’indisponibilité temporaire.
11.3 Réseau et accès¶
Cette partie valide les conditions d’accès au système.
Exemples :
- accès depuis le poste opérateur ;
- filtrage réseau ;
- accès distant si prévu ;
- séparation entre environnement de test et production ;
- comportement en cas de coupure réseau ;
- vérification des ports et protocoles nécessaires.
11.4 Sauvegarde¶
Cette partie valide que les sauvegardes prévues sont effectivement réalisées.
Exemples de critères :
- sauvegarde automatique planifiée ;
- sauvegarde manuelle possible ;
- présence des fichiers attendus ;
- journalisation de la sauvegarde ;
- alerte en cas d’échec ;
- conservation sur la durée prévue.
11.5 Restauration¶
Cette partie est essentielle : une sauvegarde non testée ne prouve rien.
Exemple de scénario :
1. Réaliser une sauvegarde complète.
2. Supprimer ou altérer une configuration de test.
3. Restaurer la sauvegarde.
4. Vérifier le retour de la configuration.
5. Vérifier la cohérence des données restaurées.
6. Vérifier que l’application redémarre correctement.
Résultat attendu :
- la restauration est possible ;
- les données critiques sont récupérées ;
- le système redémarre dans un état cohérent ;
- la procédure est documentée et reproductible.
11.6 Supervision et logs¶
Cette partie valide que le système fournit les informations nécessaires à l’exploitation et au diagnostic.
Exemples :
- logs applicatifs ;
- logs système ;
- traces de communication ;
- événements d’administration ;
- alarmes techniques ;
- export ou consultation des journaux ;
- horodatage cohérent ;
- niveau de détail suffisant.
12. Scénarios de validation de la sécurité et de la cybersécurité¶
12.1 Gestion des comptes utilisateurs¶
Cette partie valide la création, modification, désactivation et suppression des comptes.
Exemples :
- création d’un utilisateur opérateur ;
- création d’un utilisateur administrateur ;
- désactivation d’un compte ;
- refus d’accès d’un compte désactivé ;
- modification d’un mot de passe ;
- journalisation des actions d’administration.
12.2 Gestion des droits¶
Cette partie vérifie que chaque profil utilisateur accède uniquement aux fonctions autorisées.
Exemple :
Un opérateur peut consulter les états et acquitter certaines alarmes.
Un technicien peut accéder aux fonctions de diagnostic.
Un administrateur peut gérer les utilisateurs et la configuration.
Un utilisateur non autorisé ne peut pas modifier les seuils critiques.
12.3 Authentification¶
Cette partie valide le mécanisme d’authentification.
Exemples de points à vérifier :
- accès refusé avec un mot de passe incorrect ;
- verrouillage ou temporisation après plusieurs échecs ;
- expiration de session ;
- déconnexion explicite ;
- politique de mot de passe si applicable.
12.4 Journalisation des actions sensibles¶
Cette partie vérifie que les actions importantes sont tracées.
Exemples d’actions à journaliser :
- connexion utilisateur ;
- échec de connexion ;
- modification de configuration ;
- passage en mode maintenance ;
- inhibition d’alarme ;
- redémarrage système ;
- restauration de sauvegarde ;
- mise à jour logicielle.
12.5 Mise à jour logicielle¶
Cette partie valide les conditions de mise à jour du logiciel ou du firmware.
Exemples de critères :
- version identifiée avant mise à jour ;
- contrôle du paquet de mise à jour ;
- procédure documentée ;
- retour arrière possible si prévu ;
- journalisation de l’opération ;
- vérification du fonctionnement après mise à jour.
13. Critères de succès, d’échec et d’acceptation¶
13.1 Critères de succès d’un test¶
Cette partie définit ce qui permet de considérer qu’un test est réussi.
Un test doit être jugé sur la base d’un résultat attendu préalablement défini, et non sur une appréciation subjective.
Exemple :
Un test est considéré comme réussi si :
- toutes les étapes prévues ont été exécutées ;
- le résultat observé correspond au résultat attendu ;
- aucune anomalie bloquante ou majeure n’a été détectée ;
- les preuves attendues ont été collectées ;
- la fiche de test est renseignée.
13.2 Critères d’échec¶
Cette partie définit les situations dans lesquelles un test est considéré comme échoué.
Exemples :
- résultat attendu non obtenu ;
- système bloqué ;
- perte ou corruption de données ;
- comportement dangereux ou non maîtrisé ;
- alarme absente alors qu’elle est attendue ;
- accès autorisé à un utilisateur non habilité ;
- impossibilité de reproduire ou d’observer le résultat.
13.3 Classification des anomalies¶
Cette partie définit les niveaux d’anomalies.
Exemple :
Bloquante :
Empêche la poursuite de la validation ou l’utilisation d’une fonction critique.
Majeure :
Affecte une fonction importante mais permet éventuellement de poursuivre certains essais.
Mineure :
N’affecte pas une fonction essentielle mais doit être corrigée.
Cosmétique :
Concerne la présentation, le libellé ou un détail d’ergonomie sans impact fonctionnel significatif.
13.4 Conditions d’acceptation globale¶
Cette partie définit les conditions permettant au client d’accepter le système.
Exemple :
Le système pourra être accepté si :
- tous les scénarios critiques sont réussis ;
- aucune anomalie bloquante n’est ouverte ;
- les anomalies majeures restantes sont acceptées par le client avec un plan de correction ;
- les livrables documentaires obligatoires sont fournis ;
- les procédures d’exploitation et de maintenance sont disponibles ;
- le rapport de validation est approuvé.
13.5 Acceptation sous réserve¶
Cette partie précise les conditions dans lesquelles le client peut accepter le système malgré certaines réserves.
Exemple :
Le système peut être accepté sous réserve si les anomalies restantes ne compromettent ni la sécurité, ni l’exploitation principale, ni la maintenance du système, et si un plan de correction daté est accepté par les parties.
14. Fiches de validation¶
14.1 Structure d’une fiche de validation¶
Cette partie définit le format standard d’une fiche de test ou de validation.
Modèle de fiche :
Identifiant du test :
Titre :
Version du test :
Exigence(s) couverte(s) :
Niveau : validation client / recette / système
Objectif :
Préconditions :
Configuration testée :
Moyens nécessaires :
Données d’entrée :
Procédure :
Résultat attendu :
Résultat obtenu :
Preuves collectées :
Statut : OK / KO / Bloqué / Non applicable
Anomalies associées :
Commentaires :
Exécutant :
Témoin client :
Date :
Signature ou approbation :
14.2 Identifiant du test¶
Cette partie précise la règle d’identification des tests.
Une identification claire permet de relier les tests aux exigences, aux anomalies et aux rapports.
Exemple :
VAL-NOM-001 : validation du démarrage nominal
VAL-COM-002 : validation de la perte de communication serveur
VAL-MAINT-003 : validation du passage en mode maintenance
VAL-INFRA-004 : validation de la restauration de sauvegarde
14.3 Objectif du test¶
Cette partie explique ce que le test cherche à démontrer.
L’objectif doit être clair, court et relié à une exigence ou à un besoin.
Exemple :
Vérifier que l’équipement conserve localement les données acquises pendant une perte de communication serveur et les retransmet automatiquement après rétablissement du réseau.
14.4 Préconditions¶
Cette partie décrit les conditions nécessaires avant d’exécuter le test.
Exemples :
- système installé et alimenté ;
- équipement en mode nominal ;
- utilisateur connecté avec le profil requis ;
- configuration de test chargée ;
- serveur applicatif accessible ;
- sauvegarde initiale réalisée ;
- absence d’anomalie bloquante.
14.5 Procédure d’essai¶
Cette partie décrit les étapes à exécuter.
Les étapes doivent être suffisamment précises pour que le test soit reproductible par une autre personne.
Exemple :
1. Vérifier que l’équipement est connecté au serveur.
2. Vérifier que les mesures sont visibles dans l’interface.
3. Couper la liaison réseau.
4. Maintenir la coupure pendant 30 minutes.
5. Vérifier que l’équipement continue l’acquisition locale.
6. Rétablir la liaison réseau.
7. Vérifier la retransmission des données.
8. Consulter l’historique et les logs.
14.6 Résultat attendu¶
Cette partie décrit précisément ce qui doit être observé pour considérer le test réussi.
Exemple :
- une alarme de perte réseau est générée ;
- les données continuent à être acquises localement ;
- aucune donnée n’est perdue pendant la coupure ;
- les données sont retransmises au retour réseau ;
- l’événement est historisé ;
- l’interface affiche le retour à l’état nominal.
14.7 Preuves collectées¶
Cette partie précise les éléments à conserver.
Exemples :
- capture d’écran de l’alarme ;
- export des données acquises ;
- extrait des logs embarqués ;
- extrait des logs serveur ;
- horodatage de la coupure réseau ;
- horodatage du rétablissement ;
- fiche de test signée.
15. Matrice de traçabilité exigences / validation¶
15.1 Objectif de la matrice¶
Cette partie explique le rôle de la matrice de traçabilité.
La matrice permet de vérifier que chaque exigence importante du cahier des charges ou de la spécification système est couverte par au moins un scénario de validation.
Elle permet aussi d’identifier :
- les exigences non testées ;
- les tests sans exigence associée ;
- les exigences partiellement couvertes ;
- les exigences couvertes uniquement par analyse documentaire ;
- les exigences nécessitant une validation sur site réel.
15.2 Structure de la matrice¶
Cette partie définit les colonnes de la matrice.
Exemple de structure :
ID exigence
Libellé de l’exigence
Document source
Criticité
Scénario de validation associé
Fiche de test associée
Méthode de validation
Statut
Résultat
Commentaire
15.3 Exemple de matrice¶
ID exigence : SYS-COM-004
Libellé : Le système doit conserver localement les données en cas de perte de communication serveur.
Document source : Spécification système
Criticité : élevée
Scénario : VAL-COM-002
Méthode : essai par simulation de coupure réseau
Statut : à exécuter / réussi / échoué
Résultat : données retransmises après retour réseau
Commentaire : vérifier aussi le cas d’une coupure supérieure à 24 h si requis
15.4 Couverture minimale attendue¶
Cette partie définit le niveau de couverture attendu.
Exemple :
Toutes les exigences critiques doivent être couvertes par au moins un essai de validation.
Les exigences importantes doivent être couvertes par essai, démonstration ou inspection.
Les exigences documentaires peuvent être couvertes par revue documentaire.
Les exigences non vérifiables doivent être reformulées ou justifiées.
16. Gestion des anomalies pendant la validation¶
16.1 Déclaration d’une anomalie¶
Cette partie décrit comment une anomalie est déclarée.
Informations minimales :
- identifiant de l’anomalie ;
- date ;
- test concerné ;
- version du système ;
- description du problème ;
- résultat attendu ;
- résultat obtenu ;
- gravité ;
- reproductibilité ;
- preuves associées ;
- responsable d’analyse ;
- statut.
16.2 Analyse d’une anomalie¶
Cette partie décrit comment les anomalies sont analysées.
L’analyse doit permettre de distinguer :
- défaut réel du système ;
- erreur de procédure de test ;
- mauvaise configuration ;
- exigence ambiguë ;
- comportement attendu mais mal compris ;
- limitation connue et acceptée.
16.3 Correction et contre-validation¶
Cette partie précise comment une correction est validée.
Lorsqu’une anomalie est corrigée, le test concerné doit être rejoué. Il peut aussi être nécessaire de rejouer des tests de non-régression.
Exemple :
Après correction d’une anomalie affectant la perte réseau, les tests de coupure réseau, de stockage local, de retransmission et de consultation des historiques devront être rejoués afin de vérifier la correction et l’absence d’effet de bord.
16.4 Suivi des réserves¶
Cette partie décrit le suivi des anomalies acceptées sous réserve.
Exemple :
Réserve :
L’export PDF des rapports présente une erreur de mise en page mineure.
Décision :
Accepté sous réserve, car la fonction principale d’export est opérationnelle.
Action corrective :
Correction prévue en version 1.0.1 avant le 30/09/2026.
17. Rapport de validation¶
17.1 Objet du rapport¶
Cette partie définit le contenu du rapport final de validation.
Le rapport de validation synthétise les essais réalisés, les résultats obtenus, les anomalies détectées et la décision proposée.
Exemple :
Le rapport de validation présente les résultats de la campagne de recette et permet de statuer sur l’acceptation, l’acceptation sous réserve ou le refus du système livré.
17.2 Contenu du rapport¶
Structure recommandée :
1. Rappel du périmètre validé
2. Références des documents applicables
3. Configuration testée
4. Liste des scénarios exécutés
5. Résultats par scénario
6. Synthèse des anomalies
7. Exigences non couvertes ou partiellement couvertes
8. Réserves éventuelles
9. Conclusion
10. Proposition de décision
11. Annexes de preuves
17.3 Synthèse des résultats¶
Cette partie donne une vision globale de la campagne.
Exemple :
Nombre de tests prévus : 48
Nombre de tests exécutés : 46
Nombre de tests réussis : 43
Nombre de tests échoués : 3
Nombre de tests non exécutés : 2
Anomalies bloquantes : 0
Anomalies majeures : 1
Anomalies mineures : 4
Anomalies cosmétiques : 3
17.4 Décision proposée¶
Cette partie propose une décision.
Exemples :
- acceptation sans réserve ;
- acceptation sous réserve ;
- refus de recette ;
- recette partielle ;
- recette reportée ;
- demande de correction avant nouvelle validation.
18. Procès-verbal de recette¶
18.1 Objet du procès-verbal¶
Cette partie précise le rôle du procès-verbal de recette.
Le procès-verbal est le document formel par lequel le client acte la décision de recette.
18.2 Informations minimales¶
Contenu recommandé :
- identification du projet ;
- identification du système livré ;
- versions matérielles et logicielles ;
- date de recette ;
- lieu de recette ;
- participants ;
- documents applicables ;
- synthèse des essais ;
- anomalies ouvertes ;
- réserves éventuelles ;
- décision de recette ;
- engagements de correction ;
- signatures.
18.3 Décision de recette¶
Cette partie formalise la décision.
Exemple :
Décision :
☐ Recette acceptée sans réserve
☐ Recette acceptée avec réserves
☐ Recette refusée
☐ Recette partielle
☐ Recette reportée
Commentaires :
[Décrire les réserves, corrections attendues ou conditions complémentaires.]
18.4 Signature et engagement¶
Cette partie précise les signataires.
Exemple :
Pour le client :
Nom :
Fonction :
Date :
Signature :
Pour le fournisseur :
Nom :
Fonction :
Date :
Signature :
19. Annexes¶
19.1 Liste des exigences validées¶
Cette annexe peut reprendre la liste complète des exigences couvertes par la validation.
Elle permet de vérifier que les exigences critiques ont bien été prises en compte.
19.2 Liste des scénarios de validation¶
Cette annexe liste tous les scénarios, avec leur statut.
Exemple :
VAL-NOM-001 : démarrage nominal — OK
VAL-NOM-002 : acquisition des mesures — OK
VAL-COM-001 : communication serveur — OK
VAL-COM-002 : perte réseau — OK avec réserve
VAL-MAINT-001 : passage en maintenance — OK
VAL-INFRA-001 : sauvegarde — OK
VAL-INFRA-002 : restauration — KO
19.3 Liste des anomalies¶
Cette annexe reprend les anomalies détectées pendant la validation.
Exemple :
AN-001 : restauration incomplète de la configuration — majeure — ouverte
AN-002 : libellé d’alarme ambigu — mineure — ouverte
AN-003 : mauvais alignement d’un tableau — cosmétique — acceptée
19.4 Preuves de validation¶
Cette annexe regroupe ou référence les preuves collectées.
Exemples :
- captures d’écran ;
- fichiers de logs ;
- exports de données ;
- rapports automatiques ;
- photographies ;
- mesures instrumentées ;
- fichiers de configuration ;
- vidéos d’essai si nécessaire.
19.5 Glossaire¶
Cette annexe définit les termes utilisés dans le dossier.
Exemples :
Validation :
Confirmation que le système répond au besoin exprimé par le client.
Vérification :
Confirmation que le système est conforme aux spécifications.
Recette :
Acte formel par lequel le client accepte ou refuse la livraison.
Réserve :
Point non bloquant accepté temporairement sous condition de correction.
Anomalie bloquante :
Anomalie empêchant l’utilisation ou la validation d’une fonction essentielle.
Updated by Redmine Admin 3 months ago · 1 revisions