--- title: "Moteur de cadrage et plan de travail d'évaluation" description: "Le questionnaire de cadrage, les suggestions d'applicabilité en direct et la navigation dans le plan de travail d'évaluation." version: "fr" --- > Index de la documentation > Index complet de la documentation : https://docs.kliper.dev/fr/llms.txt > Utilisez ce fichier pour découvrir toutes les pages disponibles. # Moteur de cadrage et plan de travail d'évaluation ## Le questionnaire de cadrage Chaque évaluation embarque un **questionnaire de cadrage de 62 questions**, organisé en sections thématiques : Contexte, Évaluation, Type d'activité, Environnement métier, Canaux de transaction, Changements, Stockage des données, Transmission des données, SSL/TLS hérités, Réseau, Sans fil, Applications web, Synchronisation horaire et couverture des tiers. Le jeu de questions suit l'entretien de cadrage officiel du ROC PCI DSS v4 ; le compléter produit donc le récit de cadrage dont votre ROC a de toute façon besoin. ### Enregistrement - **Enregistrement automatique** : les réponses sont enregistrées automatiquement environ une seconde après la fin de la saisie. Un indicateur d'enregistrement dans le panneau affiche l'état courant. - **Enregistrer et continuer** : le bouton à la fin du questionnaire effectue un enregistrement explicite avant de vous faire passer à l'évaluation. Si l'enregistrement échoue, vous restez sur le questionnaire avec une erreur ; Kliper ne jette jamais silencieusement des réponses de cadrage. ### Suggestions d'applicabilité en direct Pendant que vous répondez, la carte **Analyse de cadrage** évalue vos réponses au regard des critères officiels d'éligibilité SAQ et suggère les contrôles susceptibles d'être **Non applicables** pour cet environnement. > **Note** > > Les suggestions sont **de simples suggestions**. Kliper ne modifie jamais une constatation de lui-même : chaque suggestion affiche sa provenance (quelle réponse l'a déclenchée, selon quelle règle) et attend que vous l'appliquiez ou la rejetiez. - **Appliquer** : passe le contrôle en Non applicable dans l'éditeur d'exigence, enregistré comme un N/A justifié avec la raison de cadrage attachée. Réversible à tout moment. - **Rejeter / Annuler** : masque une suggestion avec laquelle vous n'êtes pas d'accord ; les rejets persistent par évaluation. - **Conflits** : si vous avez déjà répondu différemment à un contrôle dans l'éditeur, la suggestion devient une entrée de conflit avec un lien **Ouvrir dans l'éditeur d'exigence**. Dans l'éditeur, un bandeau propose **Conserver votre constatation** ou **Accepter N/A** ; votre constatation enregistrée n'est jamais écrasée silencieusement. - **Pastille de saut** : lorsque de nouvelles suggestions apparaissent sous la ligne de flottaison, une pastille flottante les annonce et vous y emmène, pour que les résultats n'atterrissent jamais hors écran sans prévenir. - **Garde-fou de segmentation** : lorsque les réponses sur la segmentation réseau sont incomplètes ou ambiguës, le moteur **échoue en ouverture** : il retient les suggestions N/A au lieu de deviner une réduction de périmètre. La carte fait aussi apparaître une **indication de détermination SAQ** (à quel SAQ l'environnement correspondrait ; un contexte utile même sur les engagements ROC) et des **indices de périmètre** génériques pour les schémas d'environnement courants. ### N/A dans l'éditeur d'exigence Les contrôles passés en Non applicable via le cadrage affichent une puce **Cadrage** et un bandeau avec la raison enregistrée. Remarquer le contrôle applicable le rend à l'édition normale. Passer un contrôle en N/A (par cadrage ou manuellement) remplit aussi ses réponses de procédure de test vides avec « Non applicable. » ; le contenu saisi n'est jamais touché, et quitter N/A retire exactement le texte rempli automatiquement. --- ## Moteur de cadrage PCI DSS (visibilité des exigences) > **Note** > > Il s'agit du moteur de visibilité d'origine, qui masque purement et simplement des exigences. Le questionnaire et le flux de simples suggestions ci-dessus constituent l'expérience de cadrage principale ; les règles de visibilité ci-dessous restent actives pour les scénarios qu'elles couvrent. Toutes les exigences PCI DSS ne s'appliquent pas à tous les commerçants. Le **moteur de cadrage** ajuste automatiquement l'évaluation pour refléter l'environnement réel du commerçant en masquant les exigences non pertinentes et en marquant les champs correspondants comme Non applicables. ### Fonctionnement du cadrage Le moteur de cadrage évalue un ensemble de **règles de cadrage** au regard des réponses de l'évaluateur aux questions de cadrage. Chaque règle se compose de : 1. **Une condition** : un chemin de champ, un opérateur et une valeur attendue. 2. **Une action** : ce qu'il faut faire quand la condition est remplie (`hide_requirement`, `show_requirement` ou `set_na`). Lorsqu'un évaluateur répond à une question de cadrage (par ex. « L'entité utilise-t-elle des technologies sans fil ? »), le moteur évalue toutes les règles dont les conditions référencent ce champ. Les exigences qui sortent du périmètre sont retirées de la vue du plan de travail, et leurs champs sont automatiquement définis sur « Non applicable — Masqué par les règles de cadrage ». ### Opérateurs de condition pris en charge | Opérateur | Comportement | |---|---| | `equals` | La valeur du champ correspond exactement à la valeur attendue | | `not_equals` | La valeur du champ ne correspond pas | | `contains` | La valeur du champ (chaîne) contient la sous-chaîne attendue | | `not_contains` | La valeur du champ ne contient pas la sous-chaîne | | `exists` | Le champ a une valeur non vide | | `not_exists` | Le champ est vide, null ou indéfini | ### Règles de cadrage intégrées Kliper est livré avec des règles de cadrage dérivées du modèle de ROC officiel PCI DSS v4.0.1. Ces règles couvrent les scénarios de cadrage les plus courants : Technologie sans fil **Question de cadrage :** L'entité utilise-t-elle des technologies sans fil ? En cas de réponse **Non**, les exigences suivantes sont automatiquement masquées : | Exigence masquée | Description | |---|---| | 1.2.3 | Configuration des points d'accès sans fil | | 2.1.1 | Modification des paramètres par défaut des fournisseurs sans fil | | 4.1.1 | Chiffrement des transmissions sans fil | | 11.1 | Tests des points d'accès sans fil | | 11.2.1 | Processus de scan sans fil | | 11.2.2 | Déploiement d'IDS/IPS sans fil | Des sous-règles supplémentaires pour la méthode de scan sans fil (11.1.c) et la surveillance automatisée (11.1.d) sont évaluées indépendamment selon que ces techniques précises sont utilisées. Messagerie utilisateur **Question de cadrage :** L'entité transmet-elle des données de titulaires de carte via des technologies de messagerie utilisateur ? En cas de réponse **Non**, l'exigence **4.2.2** (sécurisation des technologies de messagerie utilisateur) est masquée. Statut de prestataire de services **Question de cadrage :** L'entité évaluée est-elle un prestataire de services ? En cas de réponse **Non**, l'exigence **12.9** (reconnaissance des responsabilités par le prestataire de services) est masquée. Solution P2PE **Question de cadrage :** L'entité utilise-t-elle une solution P2PE listée par le PCI ? En cas de réponse **Oui**, l'exigence **3.4** (rendre le PAN illisible) est masquée ; la solution P2PE traite cette exigence. Stockage des données de titulaires de carte **Question de cadrage :** L'entité stocke-t-elle des données de titulaires de carte ? En cas de réponse **Non**, l'exigence **3.1** (politiques de conservation des données de titulaires de carte) est masquée. Segmentation réseau **Question de cadrage :** L'entité utilise-t-elle la segmentation réseau pour réduire le périmètre PCI DSS ? En cas de réponse **Non**, l'exigence **6.1** (tests de segmentation) est masquée. ### Flux d'évaluation du cadrage ### Recadrage Le cadrage n'est pas définitif. Si l'évaluateur modifie une réponse de cadrage (par ex. passe « Utilise le sans fil ? » de Non à Oui), le moteur réévalue immédiatement toutes les règles. Les exigences précédemment masquées réapparaissent dans le plan de travail et leurs marqueurs N/A sont effacés. Aucune donnée d'évaluation n'est perdue lors du recadrage : les réponses saisies auparavant pour une exigence désormais masquée sont conservées et restaurées si l'exigence redevient visible. --- ## Plan de travail d'évaluation Le **plan de travail d'évaluation** est l'interface principale où les évaluateurs mènent leur évaluation. Il est conçu pour des sessions de travail longues et concentrées sur des exigences individuelles. ### Disposition Le plan de travail utilise une disposition en trois panneaux : | Panneau | Position | Finalité | |---|---|---| | **Arborescence des sections** | Gauche | Navigation hiérarchique dans toutes les sections et sous-exigences PCI DSS. Affiche le statut d'achèvement par section. | | **Panneau de question** | Centre | Les procédures de test, instructions de rapport, champs de réponse et sélection de constatation de l'exigence active. | | **Panneaux de contexte** | Droite (repliables) | Panneaux empilés et repliables pour Cortex AI, les pièces jointes, les messages, les collaborateurs, l'évaluation des écarts et la piste d'audit. | ### Modes d'affichage L'éditeur de sections propose trois modes de rendu, commutables depuis la barre supérieure : Vue moderne (par défaut) Une disposition épurée en cartes pour chaque sous-section ; la vue par défaut pour les nouveaux utilisateurs comme pour ceux qui reviennent. Optimisée pour répondre vite, avec champs de preuve en ligne et sélection de constatation. Vue PDF Un rendu de type document qui reflète la lecture de la section dans le ROC exporté ; pratique pour relire une section telle qu'elle apparaîtra dans le rapport final. Vue brouillon Un mode de rédaction allégé centré sur l'écriture de la justification de constatation de chaque exigence, avec un compteur des procédures de test déjà rédigées. Sélectionnable depuis le même contrôle de la barre supérieure (ou `?vmode=draft`). ### Présence en direct (statut en direct) Lorsque plusieurs évaluateurs travaillent sur la même évaluation, le **Statut en direct** de la barre supérieure indique qui est présent. Chaque utilisateur actif apparaît sous forme d'avatar avec son nom au survol, mis à jour en temps réel via le système de présence de la plateforme. Les engagements multi-évaluateurs deviennent ainsi visibles sans pointage manuel. ### Gérer les collaborateurs Ouvrez **Modifier l'évaluation** pour contrôler qui peut travailler sur une évaluation. Chaque ligne de collaborateur porte un **rôle** (Éditeur ou Lecteur) modifiable en ligne, plus un contrôle de retrait ; le **propriétaire** est épinglé avec une couronne. Ajoutez une personne en la sélectionnant et en choisissant un rôle. Les changements s'appliquent **immédiatement**, sans étape d'enregistrement distincte. ### Lier des preuves en ligne (saisie assistée `/`) Dans toute zone de texte de réponse d'évaluateur ou de preuve, tapez **`/`** pour ouvrir une saisie assistée de vos étiquettes de documents et de preuves. Utilisez les flèches pour naviguer et Entrée pour insérer ; vous pouvez ainsi référencer un fichier téléversé ou un document précis sans quitter le champ. ### Lignes de section compactes Lorsqu'un statut de constatation a été défini sur une exigence, sa ligne dans l'arborescence des sections **se replie en une seule puce de statut** affichant la constatation courante (En place, Non en place, Non applicable ou Non testé). Les quatre options n'apparaissent que lorsqu'aucune constatation n'est définie, ce qui réduit l'encombrement visuel sur les évaluations où la plupart des exigences sont terminées. ### Arborescence des sections (panneau gauche) L'arborescence des sections affiche les 12 exigences principales PCI DSS et leurs sous-sections dans une hiérarchie repliable. Chaque nœud indique : - **Numéro d'exigence** (par ex. 3.4.1) - **Indicateur d'achèvement** : statut visuel indiquant si l'exigence a reçu une réponse - **Visibilité de cadrage** : les exigences masquées par le moteur de cadrage n'apparaissent pas dans l'arborescence Cliquer sur un nœud charge cette exigence dans le panneau central. ### Panneau de question (centre) Pour chaque exigence, le panneau central présente : 1. **En-tête de l'exigence** Le numéro, le titre et le texte complet de l'exigence PCI DSS. 2. **Procédures de test** Chaque procédure de test définie dans le modèle de ROC pour cette exigence. Les procédures de test précisent ce que l'évaluateur doit examiner, qui interroger ou quoi observer. Chaque procédure dispose d'un champ de réponse structuré. 3. **Instructions de rapport** Les instructions de rapport du modèle de ROC : des consignes structurées sur ce que l'évaluateur doit documenter. Elles décrivent quels documents examiner, quel personnel interroger, quelles configurations inspecter et quoi rapporter. 4. **Étapes de validation (préfixe structuré)** Des champs de liste à sélection pour documenter : - **Documentation examinée** : lien vers les fichiers de preuve téléversés - **Échantillons prélevés** : méthodologie d'échantillonnage et sélections - **Personnel interrogé** : noms et rôles - **Évaluateur** : QSA principal ou associé - **Technologies critiques** : systèmes et composants examinés - **Paramètres examinés** : paramètres de configuration inspectés - **Méthodes** : procédures et approches de test utilisées - **Logiciels** : produits validés par le PCI SSC ou autres applications 5. **Constatation de l'évaluation** Une sélection du statut de constatation de l'exigence : - **En place** : l'exigence est pleinement satisfaite - **Non applicable** : l'exigence ne s'applique pas à l'environnement évalué - **Non testé** : l'exigence n'a pas été évaluée - **Non en place** : l'exigence n'est pas satisfaite Avec des indicateurs de méthode facultatifs : - **Contrôle compensatoire** : l'annexe C s'applique - **Approche personnalisée** : l'annexe E s'applique 6. **Description des constatations** Un champ de texte libre pour les constatations écrites de l'évaluateur. C'est le récit qui apparaît dans le ROC final. Cortex AI peut générer automatiquement un brouillon de ce champ à partir des procédures de test, des preuves téléversées et des réponses de l'évaluateur. ### Panneaux de contexte (côté droit) Le côté droit du plan de travail contient des panneaux repliables qui fournissent des informations contextuelles sans quitter l'exigence courante : Panneau Cortex AI Une interface de discussion pour interagir avec Cortex. L'évaluateur peut poser des questions sur l'exigence courante, demander des orientations PCI DSS ou déclencher le remplissage automatique de la description des constatations. Les réponses de Cortex sont contextualisées à l'exigence précise en cours de traitement. Voir le [guide Cortex AI](/fr/guides/cortex-ai) pour les détails. Panneau Pièces jointes Liste tous les fichiers de preuve téléversés pour l'évaluation courante, éventuellement filtrés par section. Chaque fichier affiche : - Nom et type de fichier - Date de téléversement et auteur - Statut de l'analyse antimalware (sain, en attente, en quarantaine) avec les résultats par moteur - Statut de validation IA (En attente, Complet, Partiel) - Étiquettes (associations d'exigences, étiquettes de documents) Les fichiers peuvent être téléversés, téléchargés, prévisualisés et supprimés depuis ce panneau. Panneau Messages Des **Messages** en fils de discussion, limités à une exigence (libellés « Messages » dans tout le produit). Les évaluateurs peuvent : - Publier des messages sur des exigences précises - @mentionner des membres de l'équipe (déclenche des notifications) - Consulter l'historique des messages et leurs horodatages Panneau Collaborateurs Affiche les membres de l'équipe affectés à l'évaluation et leurs rôles (**Éditeur** ou **Lecteur**, plus le **Propriétaire** épinglé). Montre la présence en direct : quels membres consultent actuellement l'évaluation. Panneau Piste d'audit Un journal chronologique de chaque changement apporté à l'exigence courante : qui a changé quoi, quand, et les valeurs avant/après. Utile pour la revue QA et pour répondre aux demandes du PCI Council. ### Progression du statut des réponses Chaque réponse d'évaluation progresse selon un cycle de vie de statuts défini : ``` En attente ──▶ Relue ──▶ Approuvée │ │ └──────────────┘ (peut revenir à En attente si des changements sont nécessaires) ``` - **En attente** : état initial. L'évaluateur travaille encore sur l'exigence. - **Relue** : la réponse a été relue par un pair ou un superviseur. - **Approuvée** : la réponse est finalisée et verrouillée pour inclusion dans le rapport ROC. ### Synchronisation des preuves documentaires Lorsque des fichiers sont téléversés dans une évaluation, Kliper les synchronise automatiquement dans le tableau **Preuves documentaires de la section 6.4**. Cela se fait de manière transparente : 1. Le fichier est téléversé avec des étiquettes facultatives (par ex. `doctag-DOCFW` pour une étiquette de documentation pare-feu). 2. La plateforme crée ou met à jour une ligne dans le tableau `docEvidence` de la réponse 6.4. 3. Chaque ligne contient : identifiant du fichier, étiquette de référence du document, nom du fichier, résumé de finalité généré par l'IA et date de téléversement. 4. Les lignes manuelles (saisies directement par l'évaluateur) sont conservées aux côtés des lignes générées automatiquement. Une action « Tout resynchroniser » permet de forcer la resynchronisation de tous les fichiers dans le tableau 6.4. ### Priorités des exigences Chaque exigence peut porter une **priorité** manuelle (Haute / Moyenne / Basse) définie depuis la barre d'outils Exigences ; votre propre lentille de tri pour « par quoi j'attaque en premier », indépendante du jalon de l'approche priorisée PCI affiché sur chaque contrôle. Filtrez la liste des exigences par priorité pour cibler une session de travail. ### Orientations issues du coffre Chaque carte de contrôle inclut un accordéon **Orientations** replié, entre les critères de l'exigence et la constatation ; un contenu de référence issu de la bibliothèque de travail d'un QSA en exercice, rendu tel quel (non généré par IA) : - **Finalité**, **Bonnes pratiques** et **Informations complémentaires** du contrôle. - **Orientations cloud** pour les environnements Azure et AWS lorsqu'elles existent. - **Modèles de réponse** : de vrais schémas de réponse de ROC avec un bouton de copie ; les espaces réservés `[CLIENT-NAME]` restent visibles pour que vous les remplissiez. Dans chaque procédure de test, un interrupteur **Comment tester** dans la colonne de référence révèle le matériel propre à la TP : catégorie et niveau de preuve, étiquettes de preuve attendues (avec définitions au survol ; les mêmes codes que suit la vue de couverture), plus les étapes de validation, les procédures d'échantillonnage et les questions d'évaluation. > **Note** > > Les orientations couvrent les 250 contrôles numérotés de PCI DSS v4.0.1. Les contrôles d'annexe (A1/A2) n'ont pas de source d'orientations et n'affichent simplement pas d'accordéon. --- ## Reprendre où vous vous étiez arrêté Le tableau de bord suit la dernière sous-section sur laquelle vous avez travaillé par évaluation et propose une reprise en un clic. ### Fonctionnement - **Suivi par évaluation** : lorsque vous ouvrez une exigence précise dans le plan de travail, la plateforme stocke l'identifiant de l'évaluation, celui de la sous-section et un libellé lisible dans le localStorage de votre navigateur. - **Carte de reprise du tableau de bord** : à votre prochaine visite du tableau de bord, une **carte Reprendre** apparaît avec le nom de l'évaluation, l'exigence précise sur laquelle vous avez travaillé en dernier et un bouton **Continuer**. - **Correspondance stricte** : la carte n'apparaît que lorsque le localStorage contient une correspondance confirmée pour une évaluation à laquelle vous avez encore accès. Il n'y a pas de repli arbitraire « en cours » : la carte affiche l'emplacement exact que vous avez quitté, ou ne s'affiche pas du tout. - **Par appareil** : comme le suivi utilise le localStorage, la position de reprise est propre au navigateur dans lequel vous travailliez. Changer d'appareil repart de zéro. ### Pourquoi c'est important Sur les engagements longs, les évaluateurs travaillent souvent en sessions courtes réparties sur plusieurs jours. La reprise supprime le moment « sur quelle exigence étais-je ? » au début de chaque session : le tableau de bord s'en souvient pour vous. --- ## Cartes compactes du hub d'évaluation Les cartes de statistiques en haut du hub d'évaluation (Total des exigences, Terminées, En cours, Non démarrées, etc.) utilisent une disposition compacte : - Marges internes, taille d'icône et taille de police réduites - Barres de progression plus serrées - Davantage de cartes visibles sans défilement Conçue pour faire tenir plus de contexte d'engagement à l'écran lors des points quotidiens. Source: https://docs.kliper.dev/fr/guides/scoping-and-workbench/index.mdx