Formulaires conditionnels dans les applications métier : logique de formulaire dépendante du contexte pour Solution Builder

Pour Solution Builder, cela signifie que les règles métier peuvent être directement intégrées dans la structure du formulaire. Les utilisateurs n'ont pas à décider eux-mêmes quelles parties d'un processus s'appliquent à leur cas. C'est le formulaire qui prend en compte les conditions définies pour le processus concerné.

Objectif des formulaires conditionnels

Les formulaires conditionnels sont particulièrement utiles lorsque certaines informations ne sont requises que sous certaines conditions. Ils permettent de limiter le nombre de champs affichés en fonction du cas d'utilisation et d'éviter les questions qui ne sont pas pertinentes pour le processus concerné.

Il n'est par exemple pas nécessaire de poser des questions sur les transferts internationaux de données s'il n'y a pas de transfert international. Les champs relatifs à la remontée d'un incident ne sont pas obligatoires si l'incident ne répond pas aux critères de risque prévus à cet effet. Les sections d'autorisation supplémentaires peuvent rester masquées si le cas en question ne nécessite aucune autorisation supplémentaire.

Ce qui est donc déterminant, c'est que les informations soient consultées lorsque les conditions requises pour leur Nécessité sont disponibles.

Cela peut s'avérer particulièrement utile lorsqu'une application doit prendre en charge différents scénarios, pays, rôles, classifications de risques ou exigences réglementaires au sein d'un processus unique.

Dans le cas d'un Répertoire des activités de traitement Par exemple, des questions différentes concernant les transferts de données peuvent s'afficher en fonction du pays sélectionné. Dans le cadre d’un processus d’AIPD, des domaines de risque supplémentaires peuvent s’afficher lorsque des données sensibles sont concernées. En cas de signalement d’incident, les étapes d’escalade peuvent dépendre de la gravité de l’incident, tandis que dans le cadre d’une évaluation SMSI, des questions de sécurité supplémentaires peuvent être prévues pour les systèmes classés comme critiques.

Dans le cadre d'une évaluation des fournisseurs, des vérifications supplémentaires peuvent également s'avérer nécessaires lorsque le prestataire de services données à caractère personnel est traité ou est établi en dehors de l'UE.

Le formulaire se limite ainsi aux informations pertinentes pour chaque cas, mais peut également prendre en compte des exigences supplémentaires dès lors que les conditions requises sont remplies.

Implications pratiques pour les processus métier

Les formulaires conditionnels ne servent pas uniquement à rendre un formulaire plus clair. Leur importance réside avant tout dans la structuration des processus métier.

Si les champs non pertinents ne s’affichent pas, les utilisateurs ont moins de questions à vérifier et à traiter. Cela peut simplifier le traitement et réduire le risque que des informations soient fournies dans des rubriques qui ne sont pas pertinentes pour le cas concret.

La qualité des données peut également en bénéficier, car les utilisateurs sont moins enclins à saisir des informations inexactes ou aléatoires simplement parce qu’un champ est visible. Parallèlement, des informations supplémentaires peuvent être demandées dès qu’une règle métier définie l’exige.

Pour ConformitéDans le cadre des processus, cela peut s'avérer particulièrement pertinent lorsque les exigences en matière de documentation dépendent des circonstances propres à chaque cas. Des sections supplémentaires peuvent s'afficher lorsque les conditions définies sont remplies, plutôt que de présenter toutes les exigences envisageables dès le début du processus.

Du point de vue de la gestion d'une application, les formulaires conditionnels permettent en outre de représenter différents cas de figure au sein d'un même formulaire, sans avoir à créer un formulaire distinct pour chaque scénario.

Cela est important car les applications métier peuvent devenir inutilement complexes lorsque toutes les informations potentiellement nécessaires sont demandées dès le début d'un processus. Les formulaires conditionnels permettent en revanche de s'adapter au contexte métier spécifique.

Principe de base de la logique des formulaires

Le principe de base d'une section de formulaire conditionnelle peut être décrit par une règle simple :

Une section n'apparaît que si une condition définie est remplie.

La condition repose sur des informations déjà disponibles pour l'élément concerné. Le Solution Builder définit le champ à vérifier, le critère applicable ainsi que la valeur ou l'état qui entraîne l'affichage de la section correspondante.

Voici quelques exemples de règles métier typiques :

• La section consacrée à Évaluation de l'impact du transfert s'affiche lorsque le pays de destination se trouve en dehors de l'UE.
• Une étape d'autorisation supplémentaire s'affiche lorsque le risque est jugé élevé.
• La section consacrée à la sécurité des fournisseurs s'affiche lorsqu'un prestataire externe est impliqué.
• Une justification de la durée de conservation s'affiche lorsque la durée de conservation prévue dépasse la durée standard.
• La section consacrée au signalement d'un incident s'affiche lorsque l'incident est susceptible d'avoir des répercussions sur concernés a des personnes.

L'utilisateur n'a pas besoin de connaître la règle sous-jacente. Le formulaire affiche la section correspondante dès que la condition définie est remplie.

Traduire les règles métier en logique de formulaire

Les Solution Builders partent généralement d'une exigence métier et non des détails techniques de mise en œuvre. Les formulaires conditionnels s'inscrivent dans cette approche, car il faut d'abord déterminer dans quelles conditions une section spécifique du formulaire est nécessaire.

On peut donc partir de la question suivante :

Dans quelles circonstances cette section doit-elle être visible ?

La règle métier qui en découle peut ensuite être traduite en une condition au sein du formulaire.

Ainsi, une section ne peut par exemple s'afficher que si une activité de traitement porte sur des catégories particulières de données à caractère personnel, si un système a été classé comme essentiel à l'activité, si un prestataire de services sélectionné est établi dans un pays tiers ou si la nature de la demande correspond à une demande de suppression.

De cette manière, les connaissances relatives au processus peuvent être intégrées au comportement du formulaire, sans que les utilisateurs aient à déterminer eux-mêmes quelles parties du formulaire sont pertinentes pour leur cas particulier.

Conditions allant au-delà des simples décisions « oui » ou « non »

Les formulaires conditionnels ne se limitent pas à des choix binaires. En fonction de la logique de formulaire disponible, les conditions peuvent également vérifier si des champs sont vides ou renseignés, si une valeur sélectionnée correspond à une option donnée, si une valeur numérique est supérieure ou inférieure à un seuil, si un texte contient certains éléments ou si une date est antérieure ou postérieure à une autre date.

Cela permet de répondre à différents besoins métier.

Une section « audit » peut par exemple s'afficher lorsque la date limite de la prochaine vérification est dépassée. Une section « escalade » peut devenir pertinente lorsque le nombre de personnes concernées dépasse un seuil défini. Une section « mesures correctives » peut s'afficher lorsqu'un contrôle a été jugé inefficace.

Ce même principe peut s'appliquer aux processus de justification ou d'exception. Une section de justification peut s'avérer nécessaire lorsque les informations requises ne sont pas disponibles. Une section relative à l'autorisation d'exception peut être indiquée lorsqu'une mesure prévue s'écarte du processus standard prévu.

Le formulaire ne sert donc pas uniquement à saisir des informations. Sa structure peut s'adapter aux informations déjà disponibles pour chaque transaction.

Logique conditionnelle basée sur des champs de référence

La nouvelle fonctionnalité relative aux champs de recherche étend cette approche aux informations issues d'enregistrements liés.

Un champ de référence établit une relation entre un élément et un autre. Une activité de traitement peut, par exemple, être associée à un système, un fournisseur, un pays, une entité organisationnelle ou un contrôle.

Les formulaires conditionnels peuvent prendre en compte ces relations pour déterminer les sections à afficher. Le formulaire peut ainsi réagir non seulement aux informations saisies directement par l'utilisateur, mais aussi aux données déjà disponibles pour un objet associé.

Si, par exemple, un utilisateur sélectionne un fournisseur, la fiche fournisseur correspondante peut déjà contenir des informations sur son emplacement, sa classification en matière de risques et le type de service proposé. Ces informations peuvent ensuite être utilisées pour déterminer si des sections supplémentaires sont nécessaires.

Si une classification des risques du fournisseur existe déjà, l'utilisateur n'a pas besoin de saisir à nouveau cette information uniquement pour le formulaire actuel. L'utilisation des informations existantes issues d'ensembles de données associés permet ainsi d'éviter les demandes redondantes et contribue à une utilisation plus cohérente des données existantes.

Utilisation dans le registre des activités de traitement

Dans une solution RoPA, un utilisateur peut, par exemple, sélectionner le pays dans lequel une Traitement a lieu. Si le pays sélectionné déclenche des exigences supplémentaires liées aux transferts, conformément aux règles définies dans l'application, des questions supplémentaires concernant les garanties et les évaluations de transfert peuvent s'afficher.

Si les conditions requises ne sont pas remplies, ces sections restent masquées.

Cela permet de prendre en compte différentes situations de traitement au sein d'un même formulaire, sans que chaque utilisateur ne soit obligé de répondre à toutes les questions relatives aux transferts de données, quelle que soit la situation concrète.

Utilisation dans la gestion des fournisseurs

Les formulaires conditionnels peuvent également être utilisés dans la gestion des fournisseurs.

Si un utilisateur sélectionne un prestataire déjà classé au sein de l'application, des sections supplémentaires de diligence raisonnable peuvent s'afficher si celui-ci est classé comme « critique ». En l'absence d'une telle classification, ces sections ne doivent pas nécessairement faire partie du contrôle standard.

La portée de l'examen peut ainsi s'appuyer sur les informations déjà disponibles concernant le prestataire de services en question.

Application dans la gouvernance de l'IA

Ce même principe peut s'appliquer aux processus de gouvernance de l'IA.

Lorsqu'un outil d'IA est sélectionné, des sections supplémentaires consacrées à la gouvernance peuvent s'afficher si cet outil est utilisé pour prendre des décisions ayant des conséquences importantes ou données à caractère personnel traitées. Si les conditions définies pour une documentation plus approfondie des risques ne sont pas remplies, ces sections peuvent rester masquées.

Les formulaires conditionnels permettent ainsi d'adapter les exigences en matière de documentation en fonction des caractéristiques de chaque cas d'utilisation de l'IA.

Application dans les processus du SMSI

Dans une solution SMSI, un système peut être associé à un processus métier spécifique. Si ce processus est classé comme critique, des exigences supplémentaires en matière de contrôles peuvent s'afficher dans le formulaire.

Si le processus ne répond pas aux critères correspondants, l'évaluation par défaut peut rester inchangée.

Cela permet de déterminer les exigences de contrôle applicables en fonction de la classification fonctionnelle d'un processus métier, sans que les utilisateurs aient à définir eux-mêmes l'étendue du contrôle requis.

Gestion des valeurs dans les sections masquées

Les Solution Builders doivent également tenir compte de la manière dont sont traitées les informations déjà saisies dans une section qui sera masquée par la suite.

Si un utilisateur modifie une donnée et que la condition requise pour l'affichage d'une section n'est plus remplie par la suite, les valeurs contenues dans cette section sont conservées dans un premier temps, tant que l'utilisateur continue à modifier l'élément. Ainsi, les données ne sont pas supprimées immédiatement à la suite d'une modification effectuée pendant le processus d'édition.

Toutefois, si l'élément est enregistré alors que la section reste masquée, les valeurs qu'il contient sont supprimées. Le champ d'identification principal est conservé.

Ce comportement est pertinent pour le modèle de données sous-jacent, car les informations qui ne relèvent plus du scénario d'utilisation actuel ne sont pas conservées de manière permanente au seul motif qu'elles ont été saisies lors d'une phase antérieure du processus.

Lors de la conception de formulaires conditionnels, il convient donc de tenir compte de ce comportement, en particulier lorsque les utilisateurs ont la possibilité de modifier a posteriori les options qu'ils ont sélectionnées auparavant.

Conception fondée sur des règles techniques

Lors de la conception de formulaires conditionnels, il est souvent judicieux de partir non pas des champs existants, mais des règles métier sous-jacentes.

Il convient notamment de vérifier :

• Quels sont les cas qui nécessitent une procédure différente ?
• Quelles sont les informations qui ne sont requises que sous certaines conditions ?
• Quelles sont les questions qui ne présentent pas d'intérêt pour une grande partie des utilisateurs ?
• Quelles sont les exigences qui varient en fonction du pays, du risque, du rôle, de la catégorie, du système, du fournisseur ou du statut ?
• Quels tronçons ne deviennent pertinents qu'une fois qu'un certain seuil est atteint ?

Ces règles permettent ensuite de définir la structure du formulaire et la logique de conditions correspondante.

La logique conditionnelle ne doit pas servir uniquement à masquer le plus grand nombre possible de champs. Le lien entre les informations fournies par l'utilisateur et le comportement du formulaire qui en résulte doit rester compréhensible. L'objectif est de structurer la complexité métier existante conformément aux règles métier applicables.

Cas d'utilisation typiques

Les formulaires conditionnels peuvent notamment être utilisés dans les domaines de la gouvernance, des risques, Conformité-, protection des données, sécurité, Audit- et aux processus de gestion opérationnelle, dans la mesure où l'étendue des informations requises dépend du contexte particulier.

Les cas d'utilisation typiques sont les suivants :

• exigences spécifiques à chaque pays dans le Répertoire des activités de traitement,
• Évaluations d'impact des transferts,
• Logique de déclenchement de l'AIPD,
• Escalade des incidents,
• Due diligence fournisseur,
• Classification des cas d'utilisation de l'IA,
• Applicabilité des contrôles du SMSI,
• Exigences relatives à Audit-justificatifs,
• Plans de gestion des risques,
• les étapes de validation et d'approbation, ainsi que
• Processus d'exception.

Le principe commun consiste à afficher les sections en fonction des besoins spécifiques de chaque cas, plutôt que de présenter à chaque utilisateur l'ensemble des champs potentiellement pertinents.

Les formulaires conditionnels dans le cadre de la conception de la solution

Sans logique conditionnelle, les Solution Builders peuvent être amenés à créer des formulaires volumineux, comportant notamment des sections qui ne s'appliquent qu'à des cas particuliers. Les utilisateurs doivent alors déterminer eux-mêmes quelles parties du formulaire s'appliquent à leur situation.

Les formulaires conditionnels permettent de transférer cette différenciation vers l'application. Le formulaire peut reproduire la logique du processus et afficher des demandes d'informations supplémentaires dès que les conditions requises sont remplies.

Cela peut notamment être le cas dans les situations suivantes : Conformité-être pertinentes pour certaines applications. Conformité- Les procédures comportent souvent des exigences qui ne s'appliquent que sous certaines conditions. Si toutes les exigences potentielles sont présentées simultanément, les formulaires peuvent devenir très volumineux, alors que seule une partie d'entre elles s'applique au cas concret.

Les formulaires conditionnels permettent d'opérer une différenciation en conséquence. Des informations supplémentaires sont demandées lorsque la condition définie est remplie. En revanche, les sections non pertinentes ne figurent pas dans le formulaire actuel.

Classification pratique

Les formulaires conditionnels permettent aux développeurs de solutions de structurer les applications métier en fonction des circonstances propres à chaque cas particulier. Leur intérêt pratique réside notamment dans la possibilité de lier le comportement d'un formulaire à des règles métier et à des informations déjà présentes dans l'application.

Cela permet de réduire le nombre de champs superflus, d'éviter les demandes en double, d'assurer une plus grande cohérence dans la saisie des données et de prendre en charge différentes variantes de processus au sein d'un même formulaire.

Il convient notamment de prendre en compte la définition des conditions sous-jacentes, l'utilisation des informations issues d'ensembles de données liés, ainsi que le traitement des valeurs lorsque des sections conditionnelles sont masquées. Si ces aspects sont pris en compte dès la conception, les formulaires conditionnels peuvent contribuer à créer des processus métier et Conformité- Représenter les exigences de manière structurée au sein d'une application.