Remarques sur la partie "Gestion des applications"

[Metazel]

Voici les éléments relevés à challenger :

• objet "Application" Proposition de reformulation : "Dans le domaine informatique, une application, également appelée applicatif, appli ou app, désigne un programme, ou un ensemble logiciel, utilisé directement pour effectuer une tâche spécifique ou un ensemble de tâches liées dans un domaine formant un tout...."

Ensemble des champs que je pense nécessaires en cas de sollicitation du service : le nom de l'application et le ministère responsable.

Champs "statut" : on avait revu la liste, mais elle ne semble pas reprise. Ce qui avait été demandé était de ne garder que les valeurs suivantes "En construction", "En production", "En cours de retrait", "Décommissionnée". Et je ne le mettrais pas en obligatoire (car les sources n'auront pas forcément ce type d'information) PS : le cycle de vie d'une application passe généralement dans les stades suivants... plus ou moins à vision opérationnelle : application nouvelle (ajout), déployée, services ouverts, en maintenance, en retrait (service arrêté temporairement ou définitivement), supprimée (décommissionnée ou remplacée)

Remarque: la solution se veut opensource donc agnostique du contexte d'entreprise. Il faut à mon sens supprimer les particularisme de notre structure. Propositions : Ministère responsable => Organisation responsable

Identifiants externes : les gérer dans une table lié a l'objet (source / id / Label / [valeur locale, si transformation])

Organisation projet : je la garderais car cela permet de savoir comment l'application à été réalisée

Sensibilité : l'impact se situe essentiellement sur l'information de classification, non? il vaut mieux avoir l'exhaustivité d'une recherche sur les applications mais ne pas savoir si l'une d'entre elles est sensible.

Type application : le bureau de pilotage le décrit. A mon sens, c'est utile pour comprendre le fonctionnement de l'application, prendre des décisions de transformation de SI et de technologies a adopter ou voir si on a une cohérence dans les solutions utilisées (ex. valorisation de la données => outils spécifiques / site web => solutions maitrisées chez nous) ... mais ça rentre, selon moi, en conflit avec l'objet qui liste les composants de l'application.

Zone d'urbanisation : c'est essentiellement utile pour maitriser la couverture applicative vis a vis du fonctionnel de l'entreprise. De plus, je ne le vois pas comme un simple champ dans Application, mais un vrai objet "Urbanisation" (domaines fonctionnels, sous-domaines) lié à l'Application

Conformité : un objet "Conformité" avec sa nature, son statut, sa date qui acte le statut, sa date prévisionnelle de fin de validité de statut

devops : peut être basculé sur l'identification d'un service de CI/CD "forge dnum", "forge dso", "forge spécifique/externe"

• objet Rôle rôle : cette liste est liée a la gestion de projet / application dans le contexte de son entreprise (il faut donc que ce soit une table paramétrable dans la solution) Chez nous, on a des projets menés en mode agile/traditionnels/"hybride". Donc je verrais "chef de projet/responsable solution/PO", "MOA", "architecte", "MOE/partenaire de réalisation", "AQSSI", ("partenaire pour l'audit/QA"), "Hébergeur", "exploitant", "support fonctionnel/technique" ... a débattre.

Rq : rajouter un moyen de savoir si le rôle est toujours valide. Maitriser la sécurité autour du rôle (le désenrôlement se fait mal dans notre structure, il faut donc gérer un rafraichissement régulier de son statut)

• objet Acteur RIO : propre a notre organisation. Pareil que pour Application, je propose de la lier a un objet "Identifiants externes". Le RIO est l'id unique pour un agent du MI. actif : il faut potentiellement gérer la suppression de l'information dès que celui-ci n'admet plus de rôles dans le SI. Type d'acteur : mettre plutôt sa "fonction" dans l'organisation? Cela diffère d'un rôle pour une application (se poser la question de l'usage... est-ce utile pour le BRM, pour les bureaux de pilotages?)

• objet Conformité Niveau de conformité : faire générique ex. pour l'homologation => complête / partielle / dispensée / non passée

• objet type Conformité Pourquoi un surtypage? Une conformité peut-elle inclure plusieurs type de conformités au meme moment?

[ymlesaux]

Objet Application: Proposition de reformulation : "Dans le domaine informatique, une application, également appelée applicatif, appli ou app, désigne un programme, ou un ensemble logiciel, utilisé directement pour effectuer une tâche spécifique ou un ensemble de tâches liées dans un domaine formant un tout...." Je préfère conserver la citation originale, mais on peut enrichir derrière, sur le même principe que ce que j'ai fait pour décrire la nature récursive de l'objet.

[ymlesaux]

Objet Application: Champs "statut" : on avait revu la liste, mais elle ne semble pas reprise. Ce qui avait été demandé était de ne garder que les valeurs suivantes "En construction", "En production", "En cours de retrait", "Décommissionnée". Et je ne le mettrais pas en obligatoire (car les sources n'auront pas forcément ce type d'information) PS : le cycle de vie d'une application passe généralement dans les stades suivants... plus ou moins à vision opérationnelle : application nouvelle (ajout), déployée, services ouverts, en maintenance, en retrait (service arrêté temporairement ou définitivement), supprimée (décommissionnée ou remplacée) Les données d'énumération utilisées dans toutes ces spécifications sont issues du code "Clean-Refacto". Quelle source pour la liste corrigée ? En tout cas, il faut que les valeurs fassent sens, mais restent maintenables. Donc, pour chaque valeur proposée, il faudra associer une définition.

[ymlesaux]

Objet Application: Ministère responsable => Organisation responsable D'accord sur le renommage du champ, mais impact à gérer sur la version en cours.

[ymlesaux]

Objet Application: Identifiants externes : les gérer dans une table lié a l'objet (source / id / Label / [valeur locale, si transformation]) Si l'on parle de la donnée "lien vers les identifiants", c'est bien ce qui est proposé, mais qui n'est pas implémenté aujourd'hui. Sinon, merci de préciser.

[ymlesaux]

Objet Application: Organisation projet : je la garderais car cela permet de savoir comment l'application à été réalisée Je ne comprends pas l'intérêt de cette information. De plus, que porte-t-elle si l'application est réalisée en V, mais que ses évolutions sont réalisées en mode agile ? (ou l'inverse) ?

[ymlesaux]

Objet Application: Sensibilité : l'impact se situe essentiellement sur l'information de classification, non? il vaut mieux avoir l'exhaustivité d'une recherche sur les applications mais ne pas savoir si l'une d'entre elles est sensible L'utilisation de cette information peut être multiple. Elle correspond, normalement, à l'importance du SI par rapport aux processus soutenus. Cette information peut être utilisée dans le cadre de priorisation d'évolutions, ou une analyse d'impact, ... La confidentialité (NP, DR) fait normalement référence aux données utilisées plutôt qu'à la sensibilité de l'application. Je peux déployer une même application en zone NP et en zone DR pour traiter des données différentes (exemple de SUADEO dans le cadre des JO2024). Par contre, je ne comprends pas la phrase "il vaut mieux avoir l'exhaustivité d'une recherche".

[ymlesaux]

Objet Application: -Type application : le bureau de pilotage le décrit. A mon sens, c'est utile pour comprendre le fonctionnement de l'application, prendre des décisions de transformation de SI et de technologies a adopter ou voir si on a une cohérence dans les solutions utilisées (ex. valorisation de la données => outils spécifiques / site web => solutions maitrisées chez nous) ... mais ça rentre, selon moi, en conflit avec l'objet qui liste les composants de l'application. C'est une information que j'ai souvent vu modélisée, mais rarement renseignée de façon utilisable ... De tête, elle fait partie du metamodèle de base de HOPEX. Donc, pourquoi avoir cette donnée, mais les valeurs possibles doivent être réfléchies; Les valeurs renseignées aujourd'hui me semblent assez disparates. La remarque sur les composants de l'application (sous-applications) est juste à ce titre. Si CANEL2 est une application, elle dispose de deux sous applications: un microservice et un site internet. Quel est alors le type de CANEL2 ? Besoin vraiment de réflexion sur l'usage de cette donnée avant de finaliser.

[ymlesaux]

Objet Application: Zone d'urbanisation : c'est essentiellement utile pour maitriser la couverture applicative vis a vis du fonctionnel de l'entreprise. De plus, je ne le vois pas comme un simple champ dans Application, mais un vrai objet "Urbanisation" (domaines fonctionnels, sous-domaines) lié à l'Application Cette information est, aujourd'hui, un champ de la table Application ... Ma proposition de l'externaliser (cela signifie définir un objet distinct "Zone Urbanisme" et une table d'association avec les applications) va dans ton sens. Le fait de sortir aussi la table de liens vient de discussions sur la pertinence d'une analyse par POS (Plan d'Occupation du Sol); une alternative peut être aussi de structurer les SI par Capacité; enfin, il m'est arrivé pour un compte, de gérer en simultané deux POS distincts. Donc, je maintiens la proposition.

[ymlesaux]

Objets Conformité et Type Conformité Niveau de conformité : faire générique ex. pour l'homologation => complète / partielle / dispensée / non passée Pourquoi un surtypage? Une conformité peut-elle inclure plusieurs type de conformités au même moment? Je relie ces deux retours. Le "Surtypage" est une façon de couvrir les éventuelles variations de contraintes réglementaires. En faisant cette dissociation, nous sommes structurellement à l'abri de l'ajout d'une nouvelle réglementation. Pour le niveau de conformité, si l'on prend une approche générique, il faudra compléter dans le commentaire (type d'homologation accordée par exemple). De plus, dans le cas du RGAA, nous pouvons avoir des niveaux différents qu'il est intéressant de tracer. Par exemple, au MINARM, nous considérions que 80% de conformité était suffisant pour mettre en production, mais cela ne signifiait pas que nous devions nous en contenter ... Avoir une information de ce niveau de finesse peut être intéressant pour préparer des budgets de mise en conformité ... Donc, le niveau de conformité demande encore des échanges.

[ymlesaux]

Objet Application: devops : peut être basculé sur l'identification d'un service de CI/CD "forge dnum", "forge dso", "forge spécifique/externe" Pour retravailler ce concept, il va falloir passer par les "5 pourquoi". Que cherche-t-on avec cet objet ? simplement identifier l'usage d'édition ? ou alors valider que dans la chaine d'édition, nous avons bien des tests unitaires ? etc ...

[ymlesaux]

Objet Rôle rôle : cette liste est liée a la gestion de projet / application dans le contexte de son entreprise (il faut donc que ce soit une table paramétrable dans la solution) Chez nous, on a des projets menés en mode agile/traditionnels/"hybride". Donc je verrais "chef de projet/responsable solution/PO", "MOA", "architecte", "MOE/partenaire de réalisation", "AQSSI", ("partenaire pour l'audit/QA"), "Hébergeur", "exploitant", "support fonctionnel/technique" ... a débattre. La table de paramétrage est bien la solution qui est utilisée systématiquement pour gérer les ENUM (merci Django), donc pas de soucis sur ce point. Pour durcir la liste, ce serait intéressant de poser des définitions pour chaque rôle.

[ymlesaux]

Objet Rôle rajouter un moyen de savoir si le rôle est toujours valide. Maitriser la sécurité autour du rôle (le désenrôlement se fait mal dans notre structure, il faut donc gérer un rafraichissement régulier de son statut) La table Acteur actuelle contient un champ "actif", qui est plutôt à porter par le rôle. Une stratégie possible est de mettre une date d'échéance par principe, ce qui amènera à rafraichir périodiquement les données. A discuter

[Metazel]

Par contre, je ne comprends pas la phrase "il vaut mieux avoir l'exhaustivité d'une recherche". Statut sensibilité Ce que je voulais dire c'est de ne pas brider les recherches sur une Application pour avoir la liste totales applications, mais plutôt de ne proposer la connaissance du champs sensibilité qu'a certains profils d'utilisateur (architecte, acteur SSI, ...)

[ymlesaux]

Objet Acteur RIO : propre a notre organisation. Pareil que pour Application, je propose de la lier a un objet "Identifiants externes". Le RIO est l'id unique pour un agent du MI. L'externaliser signifie qu'un acteur pourrait avoir plusieurs identifiants, donc pourquoi pas mais à challenger avec charge de réalisation et gestion. Mais reste toujours la question du pourquoi stocker cette information ? Pour un acteur, nous disposons de son adresse de messagerie, qui est une clé de partage simple avec la console DSO. Si l'identification via Passage2 nous fournit l'adresse de messagerie (à confirmer), en quoi avons-nous besoin du RIO ?

[ymlesaux]

Objet Acteur actif : il faut potentiellement gérer la suppression de l'information dès que celui-ci n'admet plus de rôles dans le SI. Peu favorable à ce champ. Il me semble plus intéressant de faire porter l'information par le rôle. Comme évoqué plus haut pour l'objet Rôle: ajout d'une date d'échéance obligatoire, qui serait contrainte par règle de gestion (date inférieure ou égale à J+365), de façon à forcer le rafraichissement par organisation. Lorsqu'un acteur n'a plus de responsabilité active, nous pourrions l'anonymiser, en conservant son entité de rattachement. A échanger avant report dans le corps de la spécification.

[ymlesaux]

Objet Acteur Type d'acteur : mettre plutôt sa "fonction" dans l'organisation? Cela diffère d'un rôle pour une application (se poser la question de l'usage... est-ce utile pour le BRM, pour les bureaux de pilotages?) C'est bien le problème que me pose cette donnée: est-elle la base d'un référentiel d'organisation du MIOM (qui fait quoi) ? Quel usage dans le cadre d'un référentiel d'entreprise ? Proposition: supprimer cette donnée !

[ymlesaux]

Mardi 23/05/2023 - 15h29 Reprise de cette issue massive en plusieurs unitaires.