CA2769614A1 - Systeme de gestion d'applications - Google Patents

Abstract

La présente invention concerne un système (SYS) de gestion d'applications. Elle se caractérise en ce que le procédé comporte : - des objets comprenant un ou plusieurs composants (Cp) prédéfinis et pré-assemblés, lesdits objets formant : - un modèle générique d'organisation (MGO) composé d'entités organisationnelles logiques (ST) aptes à être liées entre elles; - un modèle générique de gestion (MGG) composé d'entités opérationnelles logiques (EO) aptes à être liées entre elles; - un modèle générique de pilotage (MGP) composé d'outils d'analyse de données (OA); - un modèle générique (MGS) d'écrans et de cinématique (SCR) pour une interface utilisateur; - une base de données physique unique prédéfinie (DB1) comprenant les données correspondant auxdits objets; - un ensemble de tables et de fichiers (G_TAB) caractérisant les possibilités d'activations et de personnalisation des objets et caractérisant les traitements, les flux et les règles associés aux objets; - des outils d'identification (ID_T) des activations possibles d'objets liés à une activation initiale d'un objet; - des outils de gestion (MG_T) permettant la construction de réseaux logiques comprenant des espaces de données, et des liens pré- assemblés activables et personnalisables, chaque espace de données pouvant être composé de l'ensemble des objets, ledit réseau étant intégré dans la base de données physique unique (DB1); - un objet connecteur (ML) mettant en uvre les modèles génériques, la base de données, l'ensemble de tables et de fichiers, lesdits outils d'identification et de gestion; - et en ce qu'il fournit des applications (APP) : - qui sont des instanciations du système de gestion d'applications (SYS), une instanciation représentant un jeu d'activation et un jeu de personnalisation particuliers; - qui évoluent par versions successives grâce à des extensions desdites instanciations à partir du système de gestion d'applications (SYS), de sorte à représenter des progiciels; - dont les écrans (SCR) se construisent à chaque sollicitation de l'utilisateur via l'interface utilisateur; - et en ce que le système de gestion d'applications (SYS) ainsi que les applications résultantes (APP) fonctionnent en totalité sur un serveur accessible via un navigateur internet.

Description

SYSTEME DE GESTION D'APPLICATIONS

DOMAINE TECHNIQUE DE L'INVENTION

La présente invention concerne un système de gestion d'applications.
ETAT DE LA TECHNIQUE

Un état de la technique connu de systèmes de gestion d'applications comporte une interface utilisateur pour gérer une pluralité d'applications, basées sur une pluralité de modules applicatifs, lesdits modules étant basés sur un langage de programmation informatique déclaratif, par exemple en C++TM ou en JAVATM. Pour chaque module applicatif, l'utilisateur doit déclarer, avec ledit langage de programmation informatique, des attributs, des fonctions, des liens avec les autres modules, des événements, qui lui sont associés. En général, ces applications se présentent sous la forme de progiciel dédié à un destinataire prédéterminé, par exemple à des comptables d'une entreprise. Il existe également des outils génériques qui permettent de construire des applications qui ont une destination prédéterminée également.

Un problème de cet état de la technique est que l'utilisateur est obligé
d'avoir des connaissances techniques informatiques pour créer et gérer les modules applicatifs. Par ailleurs, les progiciels sont toujours dédiés pour un destinataire spécifique.

OBJET DE L'INVENTION

La présente invention a pour but un système de gestion d'applications qui permettent de résoudre le problème énoncé ci-dessus.

Selon un premier objet de l'invention, ce but est atteint par un système de gestion d'applications, caractérisé en ce qu'il comporte :

- des objets comprenant un ou plusieurs composants prédéfinis et pré-assemblés, lesdits objets formant :
- un modèle générique d'organisation composé d'entités organisationnelles logiques aptes à être liées entre elles ;
- un modèle générique de gestion composé d'entités

2 opérationnelles logiques aptes à être liées entre elles - un modèle générique de pilotage composé d'outils d'analyse de données ;
- un modèle générique d'écrans et de cinématique pour une interface utilisateur ;

- une base de données physique unique prédéfinie comprenant les données correspondant auxdits objets ;

- un ensemble de tables et de fichiers caractérisant les possibilités d'activations et de personnalisation des objets et caractérisant les traitements, les flux et les règles associés aux objets ;

- des outils d'identification des activations possibles d'objets liés à une activation initiale d'un objet ;

- des outils de gestion permettant la construction de réseaux logiques comprenant des espaces de données, et des liens pré-assemblés activables et personnalisables, chaque espace de données pouvant être composé de l'ensemble des objets, ledit réseau étant intégré
dans la base de données physique unique ;

- un objet connecteur mettant en oeuvre les modèles génériques, la base de données, l'ensemble de tables et de fichiers, lesdits outils d'identification et de gestion ;

- et en ce qu'il fournit des applications - qui sont des instanciations du système de gestion d'applications, une instanciation représentant un jeu d'activation et un jeu de personnalisation particuliers ;

- qui évoluent par versions successives grâce à des extensions desdites instanciations à partir du système de gestion d'applications, de sorte à représenter des progiciels ;

- dont les écrans se construisent à chaque sollicitation de l'utilisateur via l'interface utilisateur ;

- et en ce que le système de gestion d'applications ainsi que les applications résultantes fonctionnent en totalité sur un serveur

3 accessible via un navigateur internet.

Selon des modes de réalisation non limitatifs, le système de gestion d'applications peut comporter en outre une ou plusieurs caractéristiques supplémentaires parmi les suivantes :

- Une entité opérationnelle et/ ou une entité organisationnelle et/ou un outil d'analyse est apte à être référencé de manière unique tout en étant utilisé
dans plusieurs espaces de données. Cela permet une utilisation transverse d'une entité opérationnelle, d'une entité organisationnelle, d'un outil d'analyse dans plusieurs espaces de données.

- Le référencement est sélectif selon un jeu d'activation de critères. Cela permet de propager les entités et les outils dans les espaces de données, de définir par espace le jeu d'activation et la personnalisation.
Cela optimise et simplifie la gestion des données partagées.

- Le système de gestion d'applications comporte des moyens de vérification de la cohérence en temps réel entre les objets à l'activation d'un objet. Cela permet de maintenir la cohérence des données dans le système.

- Une application peut utiliser plusieurs espaces de données et inversement un espace de données peut contenir plusieurs applications. Cela permet une grande souplesse dans l'urbanisation d'une application, de la plus simple à
la plus complexe. L'évolution d'une application est gérée beaucoup plus facilement par une adaptation de la répartition des entités dans les espaces et des choix du jeu d'activation.

- Le système de gestion d'applications comporte un dispositif d'import/export générique de composants desdites entités définis par filtrage à des systèmes externes de gestion de données aptes à coopérer avec le système de gestion d'applications de sorte à générer un flux générique qui est créé
avec les jeux d'activation et de personnalisation.
Cela permet un affichage de données choisies au niveau administrateur par paramétrage dans un format donné fonction des systèmes de gestions de données externe.

- Le système de gestion d'applications comporte un dispositif de

4 PCT/EP2010/061133 paramétrage libre de nouveaux composants dans une entité.
Cela permet de faire évoluer une entité.

- Le système de gestion d'applications comporte un espace commun de données, et en ce qu'un espace de données est apte à hériter des composants des entités organisationnelle et opérationnelle dudit espace commun de données.
Cela permet de définir une fois pour toute de certains composants et champs des entités si nécessaire. On a ainsi un gain en termes de coût de création et administration d'une application.

- L'espace commun de données hérite lui-même d'une instanciation initiale créée par défaut au lancement de l'objet connecteur. Cela permet au système de fonctionner en palliant par lui-même à des manques ou des incohérences de paramétrage.

- Le système de gestion d'applications comporte un dispositif d'accréditations comprenant :

- Une pluralité de premiers niveaux d'accréditations attribuables à une unité intervenant d'une entité organisationnelle ;

- Une pluralité de droits attribuables à des actions aptes à être effectuées par une unité intervenant;

- Une pluralité de deuxièmes niveaux d'accréditations attribuables à au moins un profil utilisateur auquel sont associés des unités intervenants ;

- Lesdits premiers et deuxièmes niveaux d'accréditations et ladite pluralité de droits étant aptes à êtres combinés entre eux.
Les niveaux d"accréditations permettent de se placer à différents niveaux dans une entité organisationnelle ; les droits permettent d'effectuer ou non certaines actions. La combinaison des deux permet d'avoir une attribution souple des accréditations et droits.

- Le dispositif d'accréditations est apte à attribuer un droit sur des actions associées à un espace de données, une entité, un composant.
Cela permet d'avoir une application fine des niveaux d'accréditations et de droits.

- Un espace de données hérite des accréditations et droits attribués à
l'espace de données commun en fonction d'un rôle attribué à une unité
intervenant d'une entité organisationnelle.
Cela permet selon l'entité organisationnelle d'hériter de tout ou partie des

5 droits d'un espace commun.

- Le système de gestion d'applications comporte un dispositif d'accessibilité
à des composants d'une entité opérationnelle en fonction d'un état d'avancement de l'entité opérationnelle et d'un rôle attribué à une unité
intervenant d'une entité organisationnelle, l'état d'avancement étant apte à
s'appliquer à plusieurs espaces en respectant les différentes instanciations.
Cela permet de bloquer la modification d'un composant par une unité
intervenant si un état n'est pas terminé par exemple. Donc cela permet de bien maîtriser l'avancement d'une entité opérationnelle, telle qu'une demande. La gestion multi-espaces permet une gestion enrichie du dispositif d'accessibilité.

- Le système de gestion d'applications comporte un dispositif de duplication d'une entité opérationnelle d'origine apte à utiliser une unité de redéfinition des composants de l'entité opérationnelle dupliquée par rapport à l'entité
opérationnelle d'origine.
Cela permet de recopier plusieurs fois une entité opérationnelle tout en gardant une souplesse dans la définition de la nouvelle entité recopiée.

- Le système de gestion d'applications comporte une base de définition de règles associée à des composants d'une entité de sorte à vérifier de sorte à
vérifier la cohérence en temps réel d'un écran.
Cela permet d'édicter des règles d'utilisation dans l'application gérée comme par exemple le changement automatique d'une étape dans le cycle de vie d'une entité opérationnelle telle qu'une entité Demande .

- Le système de gestion d'applications comporte une hiérarchie de niveaux associée à des entités opérationnelles dans laquelle :

- Une entité opérationnelle de premier niveau est apte à être rattachée directement à une entité organisationnelle ;

- Une entité opérationnelle de deuxième niveau est apte à être

6 rattachée directement à une entité opérationnelle de premier niveau ou à une entité organisationnelle ; et - Une entité opérationnelle de troisième niveau est apte à être rattachée directement à une entité opérationnelle de deuxième niveau et/ou entité organisationnelle.
Cela permet des référencements de plusieurs niveaux entre entités. La gestion d'une application est ainsi plus souple.

- Une entité opérationnelle de niveau inférieur au premier niveau est en outre apte à être rattachée directement à une autre entité opérationnelle de même niveau, chaque niveau d'un espace pouvant être rattaché à chaque niveau d'un autre espace.
Cela permet des référencements de plusieurs niveaux entre entités de même type. La gestion d'une application est ainsi plus souple. La gestion multi-espaces permet des couplages de hiérarchies et donc un couplage entre plusieurs entités différentes et personnalisées.

- Le système de gestion d'applications comporte en outre un deuxième dispositif d'activation d'une procédure de traitement paramétrable en fonction d'un type d'entité opérationnelle. Cela permet au niveau d'une entité
opérationnelle de conditionner les passages d'un processus à un autre, un processus comportant une pluralité d'étapes et de fonctions.

L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent.

BREVE DESCRIPTION DES FIGURES

Celles-ci ne sont présentées qu'à titre indicatif et nullement limitatif de l'invention.
- la Fig. 1 a représente schématiquement un serveur comportant le sys-tème de gestion d'applications comprenant une base de données unique, et un navigateur internet au moyen duquel un utilisateur ac-cède au système de gestion d'applications selon l'invention ;

7 - la Fig. 1 b représente schématiquement le système de gestion d'applications selon un mode de réalisation non limitatif de l'invention ;
- la Fig. 2 représente schématiquement un méta-modèle fourni par le système de gestion d'applications de la Fig. 1 b et comprenant un modèle générique organisationnel, un modèle générique de gestion, un modèle générique de pilotage et un modèle générique d'écrans et de cinématique ;
- la Fig. 3 représente schématiquement un objet connecteur du sys-tème de gestion d'application de la Fig. 1 b mettant en oeuvre les mo-dèles génériques, la base de données, des tables et de fichiers ca-ractérisant les possibilités d'activations et de personnalisation des ob-jets et caractérisant les traitements, les flux et les règles associés aux objets ;
- la Fig. 4 représente des outils de gestion du système de gestion d'application de la Fig. 1 b permettant la construction de réseaux lo-giques comprenant des espaces de données, et un exemple d'espaces de données ;
- la Fig. 5 représente schématiquement une distribution des modèles génériques de la Fig. 2 par espace de données ;
- la Fig. 6 est une représentation simplifiée d'un mode de réalisation non limitatif du système de gestion d'applications selon l'invention ;
- la Fig. 7 est un schéma simplifié d'un groupe de tables utilisées par le système de gestion d'applications de la Fig. 6 selon un mode de réa-lisation non limitatif ;
- la Fig. 8 est un schéma simplifié d'une pluralité d'espaces de don-nées, d'une entité organisationnelle et de plusieurs entités opération-nelles, lesdits espaces étant associés à une application selon un exemple non limitatif gérée par le système de gestion d'applications de la Fig. 6 ;
- la Fig. 9 est un schéma détaillé d'un premier espace de données de la Fig. 8, selon un exemple non limitatif ;

8 - la Fig. 10 est un schéma détaillé d'un deuxième espace de données de la Fig. 8, selon un exemple non limitatif ;
- la Fig. 11 est un schéma simplifié d'un groupe de tables utilisées par le système de gestion d'applications de la Fig. 6 dans le cadre de l'application prise comme exemple non limitatif de la Fig. 8 ; et - la Fig. 12 est un schéma simplifié d'un exemple non limitatif d'un dis-positif d'accréditations comprenant une table d'accréditations et de droits, ledit dispositif étant compris dans le système de gestion d'applications de la Fig. 6.

DESCRIPTION DETAILLEE DE L'INVENTION

Dans toutes les figures, les éléments communs portent les mêmes numéros de référence.

Le système de gestion d'applications SYS selon l'invention est décrit dans un mode de réalisation non limitatif aux Fig. 1 a, Fig. 1 b à la Fig. 6.

On notera que par gestion d'applications, on entend création, administration et utilisation d'applications.

Selon un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte tel qu'illustré à la Fig. 1 b :

- des objets comprenant un ou plusieurs composants Cp prédéfinis et pré-assemblés, lesdits objets formant :
- un modèle générique d'organisation MGO composé
d'entités organisationnelles logiques ST aptes à être liées entre elles ;
- un modèle générique de gestion MGG composé
d'entités opérationnelles logiques EO aptes à être liées entre elles ;
- un modèle générique de pilotage MGP composé d'outils d'analyse de données OA ;
- un modèle générique MGS d'écrans et de cinématique SCR pour une interface utilisateur UI ;

- une base de données physique unique prédéfinie DB1 comprenant

9 les données correspondant auxdits objets - un ensemble de tables et de fichiers G TAB caractérisant les possibilités d'activations et de personnalisation des objets et caractérisant les traitements, les flux et les règles associés aux objets ;

- des outils d'identification ID_T des activations possibles d'objets liés à
une activation initiale d'un objet ;

- des outils de gestion MG_T permettant la construction de réseaux logiques comprenant des espaces de données, et des liens pré-assemblés activables et personnalisables, chaque espace de données pouvant être composé de l'ensemble des objets, ledit réseau étant intégré dans la base de données physique unique ;

- un objet connecteur ML mettant en oeuvre les modèles génériques, la base de données, l'ensemble de tables et de fichiers, lesdits outils d'identification et de gestion ;

- et en ce qu'il fournit des applications APP

- qui sont des instanciations du système de gestion d'applications SYS, une instanciation INST représentant un jeu d'activation et un jeu de personnalisation particuliers ;

- qui évoluent par versions successives Ver grâce à des extensions desdites instanciations INST à partir du système de gestion d'applications SYS, de sorte à représenter des progiciels ;

- dont les écrans SCR se construisent à chaque sollicitation de l'utilisateur via l'interface utilisateur UI ;

- et en ce que le système de gestion d'applications SYS ainsi que les applications résultantes APP fonctionnent en totalité sur un serveur SRV accessible via un navigateur internet NAV_INT.

On entend par pré-assemblage, le fait d'activer les liens entre les objets génériques.

On entend par prédéfinie, le fait que la base de données soit créée et existe donc avant la création de n'importe quelle application. Elle comprend l'ensemble des zones de données pouvant être affichées sur les écrans SCR.

On entend par cinématique, l'enchaînement des écrans SCR.

5 Comme on peut le voir sur la Fig. 1 a, un serveur SRV comprend le système d'applications SYS et les applications qu'il fournit. Un utilisateur U
a accès au système de gestion d'application via le navigateur internet NAV_I NT.
Ainsi, en pratique tel qu'illustré sur la Fig. 1 a, du côté client, on a le

10 navigateur internet (plus particulièrement un navigateur web), et du côté
serveur SRV, on a :
- un serveur web SRVW comprenant les modèles génériques, l'ensemble de tables et de fichiers, les outils d'identification et de gestion et un objet connecteur ML ; et - un serveur de données SRVD comprenant la base de données physique unique DB1.

On notera que l'objet connecteur ML est formé de moyens logiciels et les moyens logiciels comportent au moins un produit programme d'ordinateur.

Comme on peut le voir sur la Fig. 2, le modèle générique d'organisation MGO, le modèle générique de gestion MGG, le modèle générique de pilotage MGP et le modèle générique MGS d'écrans et de cinématique SCR composent un modèle générique MOD appelé également méta-modèle.
Le modèle générique d'organisation MGO est composé d'entités organisationnelles logiques ST aptes à être liées entre elles et décrites plus loin.
Le modèle générique de gestion MGG est composé d'entités opérationnelles logiques EO aptes à être liées entre elles et décrites plus loin.
Le modèle générique de pilotage MGP est composé d'outils d'analyse de données OA décrits plus loin.

Comme on peut le voir sur la Fig. 3, l'objet connecteur ML mettent en oeuvre les modèles génériques MOD, la base de données DB1, l'ensemble

11 de tables et de fichiers G_TAB, lesdits outils d'identification ID_T et de gestion MG-T. Par ailleurs, l'objet connecteur ML mettent en oeuvre un dispositif d'accréditations Ta (décrit plus loin), les composants Cp des objets, et des processus automatisés (appelés workflow en anglais).

Comme on peut le voir sur la Fig. 4, des outils de gestion MG_T
permettent la répartition des applications par espaces de données D, c'est-à-dire la création de un ou plusieurs espaces de données par application APP.

Enfin, comme on peut le voir sur la Fig. 5, les modèles génériques de la Fig. 2, les données des objets sont distribués par espace de données, comme expliqué plus loin.

Selon un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte au moins un espace de données D apte à être associé à une application APP, ledit espace de données D comportant :
- Au moins une entité organisationnelle ST apte à être référencée dans au moins un autre espace de données D et comprenant une pluralité
de premiers composants Cpt ;
- Au moins une entité opérationnelle EO comprenant une pluralité de deuxièmes composants Cp2 ;
les premiers et deuxièmes composants Cpt, Cp2 étant aptes à être activés/désactivés par paramétrage au sein dudit espace de données D en fonction de l'application gérée.

Dans un mode de réalisation non limitatif, une entité opérationnelle EO et/ ou une entité organisationnelle ST et/ou un outil d'analyse OA est apte à être référencé de manière unique tout en étant utilisé dans plusieurs espaces de données D. On peut ainsi gérer les mêmes personnes par exemple sur des applications différentes.
Dans un mode de réalisation non limitatif, le référencement est sélectif selon un jeu de critères (non représenté sur les figures). Il est possible de voir une même organisation avec les mêmes personnes selon des critères d'affectation à chaque espace, d'activation ou non de données, une personnalisation de données et des droits d'accès et de gestion au niveau de chaque donnée.

12 Dans un mode de réalisation non limitatif, une pluralité d'espaces de données D sont aptes à êtres associées à une application.

On notera que le système de gestion d'applications SYS est apte à
être utilisé par des utilisateurs pour créer, administrer et utiliser des applications APP.
Ainsi un utilisateur de premier niveau U1 que l'on nommera également utilisateur administrateur pourra créer, administrer et utiliser une application APP, tandis qu'un utilisateur de deuxième niveau U2 que l'on nommera également utilisateur final pourra utiliser une application APP.

Tel qu'illustré sur la Fig. 6, le système de gestion d'application SYS
comporte en outre une interface utilisateur UI apte à permettre la création, l'administration et l'utilisation d'une application APP par un utilisateur U1 ou U2.
L'interface utilisateur UI est basée sur un modèle logique MOD comportant la pluralité d'objets (espace de données, entité organisationnelle, entité
opérationnelle, composants décrits plus loin), lesdits objets étant définis dans des tables, par exemple sous format texte ou XML, comme on va le voir plus loin, et les résultats de l'utilisation (saisies, calculs, etc.) de l'application APP étant inscrits dans une même base de données physique unique DB1.
Ainsi, comme on va le voir, le fait d'utiliser de simples tables TAB qui n'utilisent aucun langage de programmation permet d'éviter à tout utilisateur, qu'il soit administrateur ou final de développer une seule ligne de code ou encore d'avoir des connaissances informatiques pour déclarer les objets de l'application choisie. Grâce à ces tables qui vont permettre notamment d'activer/désactiver par paramétrage un objet au sein d'un même espace de données D, un utilisateur va pouvoir simplement créer, administrer et utiliser une application APP.

Dans un mode de réalisation non limitatif illustré à la Fig. 6, le système de gestion d'application SYS comporte ainsi un groupe de tables G_TAB qui permet de définir :
- au moins un espace de données D apte à être associé à une application APP, ledit espace de données D comportant :
- Au moins une entité organisationnelle ST apte à être référencée dans au moins un autre espace de données D et

13 comprenant une pluralité de premiers composants Cpt - Au moins une entité opérationnelle EO comprenant une pluralité de deuxièmes composants Cp2.

Le groupe de tables G_TAB permet à un utilisateur de définir les objets précités en fonction de l'application APP choisie.

Dans un exemple de réalisation non limitatif, les tables TAB du groupe de tables G_TAB sont réparties dans un système de fichiers REP structuré de la façon suivante tel qu'illustré sur la Fig. 7:
- Un répertoire ressources RESS comprenant :
- Un premier sous-répertoire de premier niveau de libellés LIB
comprenant des tables TABI relatives aux différents libellés des objets de l'application ;
- Des premiers sous-répertoires de deuxième niveau de langue FR, GB, etc.... relatif à la langue utilisée de l'application ;
- Un deuxième sous-répertoire de premier niveau écran SCR
comprenant les tables TABs relatives aux différents écrans des objets de l'application et en particulier aux différents composants de ces écrans ;
- Un troisième sous-répertoire design HTML comprenant les tables TABd relatives aux éléments de design utilisés pour un espace de données D, tels que la police utilisée dans les écrans, la couleur, l'emplacement des composants etc.
Ces répertoires servent à la personnalisation des objets par espace.
Cette personnalisation peut être prise en charge par tout utilisateur administrateur et ce sans connaissances techniques particulières.

On entend par espace de données D, un regroupement logique d'objets qui sont liés entre eux de manière logique par un ensemble de droits et d'attributions, d'actions, de règles d'affichage, et de paramétrage communs. Le paramétrage commun permet de définir la présence et les conditions d'utilisations des objets d'un espace de données D.
Autrement dit, comme on va le voir en détail ci-dessous, un espace de données D correspond à un ensemble de paramétrages :
- par activation de : composants permettant de définir des onglets, champs, listes etc. représentatifs d'écrans d'une application, tableaux

14 récapitulatifs, etc.
- par personnalisation de libellés - d'accréditations, de droits R, de rôle Ro.

On entend par entité organisationnelle ST, une entité (personne morale, département d'une personne morale etc.) représentative d'une pluralité d'unités intervenants ITV (personnes physiques). Une entité
organisationnelle ST permet de définir quelles sont les unités intervenants accessibles par une entité opérationnelle EO.
Une entité organisationnelle ST peut être hiérarchique. Ainsi, dans un mode de réalisation non limitatif, une entité organisationnelle ST comporte une autre entité organisationnelle ST_A appelée sous-entité organisationnelle.

On entend par entité opérationnelle EO, une entité représentative d'un projet, d'une demande ou d'une tâche effectuée par une ou plusieurs unités intervenants ITV.

Ainsi, dans des modes de réalisation non limitatifs, une entité
opérationnelle EO peut être :
- une entité de premier niveau EO_P
- une entité de deuxième niveau EO_D ;
- une entité de troisième niveau EO T.
Dans la suite de la description, on nommera également - l'entité opérationnelle de premier niveau EO_P une entité Projet , - l'entité opérationnelle de premier niveau EO_D une entité Demande , - l'entité opérationnelle de premier niveau EO_T une entité Tâche .

Une entité Projet est représentative d'un projet à mener par une ou plusieurs unités intervenants ITV. Une entité Demande est représentative d'une demande émanant d'une ou plusieurs unités intervenants ITV. Une entité Tâche est représentative d'une tâche à
effectuer par une ou plusieurs unités intervenants ITV.
Dans un mode de réalisation non limitatif, le système de gestion d'application SYS comporte une hiérarchie de niveaux associés à des entités opérationnelles EO dans laquelle :
- Une entité opérationnelle de premier niveau EO_P est apte à être rattachée directement à une entité organisationnelle ST quelle que soit le niveau hiérarchique de l'entité ST ;
- Une entité opérationnelle de deuxième niveau EO_D est apte à être rattachée directement à une entité opérationnelle de premier niveau ou à
une entité organisationnelle ST ; et 5 - Une entité opérationnelle de troisième niveau EO T est apte à être rattachée directement à une entité opérationnelle de deuxième niveau EO_D et/ou entité organisationnelle ST, chaque niveau d'un espace D
pouvant être rattaché à chaque niveau d'un autre espace D, c'est-à-dire qu'une entité opérationnelle d'un niveau d'un espace D peut être 10 rattachée à une entité opérationnelle d'un autre niveau d'un autre espace D.

Dans un mode de réalisation non limitatif, le rattachement entre une entité
opérationnelle EO et une entité organisationnelle ST s'effectue via des

15 pointeurs physiques entre l'entité EO et l'entité ST, et au niveau interface utilisateur via des éléments d'interface Ule appropriés.
On notera qu'il est possible d'associer une liste d'entités ST à une entité EO
quelle que soit le niveau de l'EO. Inversement on peut rattacher plusieurs entités EO quelles que soient leur niveau à plusieurs entités ST quelles que soit leur niveau également.

On détermine par convention que le troisième niveau est inférieur au deuxième niveau qui est inférieur au premier niveau.
Ainsi, une entité Projet peut regrouper un ensemble d'entités Demande et d'entités Tâches et une entité Demande peut regrouper un ensemble d'entités Tâches .
Dans un mode de réalisation non limitatif, le rattachement entre une entité
opérationnelle EO et une autre entité opérationnelle EO s'effectue via des pointeurs physiques entre les deux entités EO, et au niveau interface utilisateur via des éléments d'interface Ule appropriés.

Dans un mode de réalisation non limitatif, une entité opérationnelle EO de niveau inférieure au premier niveau EO_P est en outre apte à être rattachée directement à une autre entité opérationnelle EO de même niveau.
Ainsi, une entité Demande peut être rattachée directement à une autre entité Demande , et une entité Tâche peut être rattachée directement à une autre entité Tâche . Les entités ainsi rattachées seront appelées respectivement des sous-demandes et des sous-tâches.

16 Dans un exemple non limitatif, on utilise un champ TâcheMère dans la table physique associée à une entité EO_T.
Dans un exemple non limitatif, on utilise un champ DemandeMère dans la table physique associée à une entité EO_D.

Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte un espace commun de données Dc, et un espace de données D est apte à hériter des composants des entités organisationnelle et opérationnelle ST, EO dudit espace commun de données Dc. De la même manière, un espace de données D est apte à
hériter des composants des outils d'analyse de données OA et des écrans et de la cinématique SCR dudit espace commun de données Dc.

Par ailleurs, l'espace commun de données Dc hérite lui-même d'une instanciation initiale créée par défaut au lancement de l'objet connecteur ML.
Cette instanciation initiale permet de définir des composants par défaut.

Dans la suite de la description, on prend l'exemple non limitatif d'une application APP1 illustrée sur les Fig. 8 à 11.
Sur la Fig. 8 sont représentés l'application APP1 à laquelle sont associés - un espace commun de données Dc ;
- un premier espace de données D1 ; et - un deuxième espace de données D2, le premier espace Dl et le deuxième espace D2 héritant de l'espace commun de données Dc, ce dernier comprenant l'entité organisationnelle ST1 (héritage illustré par des cadres en pointillés sur les Figs. 4 et 5).
L'entité organisationnelle ST1 comprend une sous-entité organisationnelle ST_A à laquelle sont rattachées deux unités intervenants ITV1 et ITV2.

On notera que dans l'exemple pris, l'application APP1 utilise plusieurs espaces de données D. Cependant, inversement, un espace de données D
peut contenir plusieurs applications APP.

Par ailleurs, tel qu'illustré sur la Fig. 9, l'espace de données Dl comprend - une entité unité intervenant ITV1 ;
- une entité Projet EO_P1 à laquelle est rattachée - une entité Demande EO_D1 à laquelle sont rattachées

17 - deux entités Demande EO_D11, EO_D12 qui sont des sous-demandes ;
- une entité Tâche EO_T1 - deux entités Tâche EO_T2, EO_T3 rattachées à l'entité sous-Demande EO_D12 ; et - deux entités Tâche EO T31 et EO T32 rattachées à l'entité
Tâche EO_T3, qui sont des sous-tâches.

L'espace de données D2, quant à lui, comprend, tel qu'illustré sur la Fig. 10 - une entité unité intervenant ITV2 ;
- une entité Projet EO_P2 à laquelle est rattachée - une entité Demande EO_D2 à laquelle sont rattachées - deux entités Tâche EO T5 et EO T6.

Dans des modes de réalisation non limitatifs, les entités organisationnelles, unités intervenants, Projet , Demande , Tâche comportent les composants suivants Cpt, Cp2 avec les libellés associés.

= Entité organisationnelle 1) Titre entité : champ 2) Responsable : bouton permettant d'accéder à un écran 3) Adresse et données juridiques (RCS, Siret, APE,..): champs 4) Service : onglet permettant d'accéder à un écran (permet de définir que l'entité organisationnelle est un service et qu'elle peut être rattachée à une autre entité organisationnelle, devenant ainsi un service fils de l'entité organisationnelle de rattachement) 5) Client : onglet permettant d'accéder à un écran (permet de définir que l'entité organisationnelle est un client) 6) Fournisseur : onglet permettant d'accéder à un écran (permet de définir que l'entité organisationnelle est un fournisseur) 7) Plans de charge : onglet permettant d'accéder à un écran (permet d'accéder au plan de charge de l'entité organisationnelle pour visualiser les entités opérationnelles sur lesquelles l'entité
organisationnelle est affectée).
Dans un mode de réalisation non limitatif, l'affectation s'effectue par des pointeurs physiques entre les entités EO et les entités ST, et au niveau interface utilisateur, par des champs, onglets etc. appropriés.
8) Zones libres : onglet permettant d'accéder à un écran - permet de

18 gérer des données libres = Unité intervenant 1) Titre : champ 2) Nom, prénom : champs 3) Date arrivée, date départ : champs 4) Matricule, badge 5) Adresse, tel, fax, email : champs 6) Login/mot de passe : champs 7) Qualification : liste 8) Service de rattachement : liste 9) Compétence : onglet permettant d'accéder à un écran (permet d'accéder à la liste des connaissances de l'unité intervenant).
10) Plan de charges : onglet permettant d'accéder à un écran (permet d'accéder au plan de charges de l'unité intervenant pour visualiser les entités opérationnelles sur lesquelles il est affecté).
Dans un mode de réalisation non limitatif, l'affectation s'effectue par des pointeurs physiques entre les entités EO et les entités ST, et au niveau interface utilisateur par des champs, onglets etc. appropriés.
Dans un exemple non limitatif, un onglet d'affectation tel que décrit ci-dessous (avec dates et charges de l'unité intervenant sur l'entité EO) est utilisé.
11)Zones libres - onglet permettant d'accéder à un écran - permet de gérer des données libres = Entité Projet 1) Titre projet - champ 2) Code - champ 3) Type de projet - liste 4) Etat Ouvert/Fermé - champs 5) Date début - champ 6) Date Fin - champ 7) Statut - liste 8) Planning - onglet 9) Criticité - liste 10) Domaine technique - liste 11) Délai - champ 12) Service - liste

19 13) Client - liste 14) Responsable - liste 15) Affectation unité intervenant - onglet permettant d'accéder à un écran (permet de gérer les unités intervenant affectés sur l'entité
Projet et de leur attribuer une charge sur une période).
16) Affectation entité organisationnelle - onglet permettant d'accéder à
un écran (permet de gérer les entités organisationnelles affectées sur l'entité Projet et de leur attribuer une charge sur une période).
17) plan de charge - onglet permettant d'accéder à un écran (permet de gérer les unités intervenants affectés sur l'entité Projet et de leur attribuer une charge sur une période).
18) Planning - onglet permettant d'accéder à un écran (permet de visualiser le planning de l'entité Projet et des unités intervenants et/ou entités organisationnelles associées).
19) Zones libres - onglet permettant d'accéder à un écran - permet de gérer des données libres = Entité Demande 1) Statut - liste 2) Destinataire - liste 3) Budget - champ 4) Projet - liste des entités Projet disponibles 5) Date ouverture - champ 6) Date clôture - champ 7) Service destinataire - liste 8) Client - liste 9) Emetteur - liste 10) Service origine - liste 11) Affectation entité organisationnelle - onglet permettant d'accéder à
un écran (permet de gérer les entités organisationnelles affectées sur l'entité Demande et de leur attribuer une charge sur une période) 12) Affectation unité intervenant - onglet permettant d'accéder à un écran (permet de gérer les unités intervenant affectées sur l'entité
Demande et de leur attribuer une charge sur une période) 13) Planning - onglet permettant d'accéder à un écran (permet de visualiser le planning d'une entité Demande et des unités intervenants et/ou entités organisationnelles associées) 14) Solution - onglet permettant d'accéder à un écran (permet de gérer les solutions proposées et retenues, associées à l'entité
Demande ) 15) Suivi de frais - onglet permettant d'accéder à un écran (permet de gérer les frais associés à une entité Demande ) 5 16) Zones libres - onglet permettant d'accéder à un écran - permet de gérer des données libres 17) Stock informatique - liste (correspond à un regroupement hiérarchique d'entités Demande côté maîtrise d'oeuvre). Par exemple, on peut avoir un regroupement selon un premier niveau 10 hiérarchique par unité intervenant ITV et selon un deuxième niveau hiérarchique (dépendant du premier niveau) par version d'entités Demande .
18) Stock utilisateur - liste (correspond à un regroupement hiérarchique d'entités Demande côté maîtrise d'ouvrage) 15 19) DemandeMère - liste

20) Type - liste = Entité Tâche 1) Type tâche - liste 20 2) Code tâche - champ 3) Date début - champ 4) Date fin - champ 5) Ouvert - champ 6) Fermé - champ 7) Budget - champ 8) Projet - champ 9) Demande - champ 10)Affectation entité organisationnelle - onglet permettant d'accéder à un écran (permet de gérer les entités organisationnelles affectées sur l'entité Tâche et de leur attribuer une charge sur une période).
11) Affectation unité intervenant - onglet permettant d'accéder à un écran (permet de gérer les unités intervenant affectés sur l'entité Tâche et de leur attribuer une charge sur une période).
12) Charges - onglet permettant d'accéder à un écran (permet de gérer des éléments temporels de délais et charges associés à l'entité
Tâche ) 13) Zones libres - onglet permettant d'accéder à un écran - permet de gérer des données libres

21 14) TâcheMère - liste Les actions de création, utilisation et administration pouvant être effectuées par un utilisateur sont décrites ci-dessous.
= Création et administration d'une application APP

Lorsqu'un utilisateur de premier niveau U1 veut créer l'application APP1, à
partir de l'interface utilisateur UI, il va associer à l'application APP1 qu'il veut créer :

= L'espace commun de données Dc comprenant, tel qu'illustré sur la Fig. 8 :
- L'entité organisationnelle ST1 comprenant :
- une pluralité de premiers composants Cpt ; et - une structure administrative ST_A à laquelle sont rattachées deux unités intervenants ITV1, ITV2, comprenant également une pluralité de composants Cpt. Le premier espace de données D1, tel qu'illustré
sur la Fig. 9 - Qui hérite de l'entité organisationnelle ST1 de l'espace commun Dc ;
Et qui comprend :
- une première unité intervenant ITV1 redéfinie comprenant également des composants Cpt ;
- Neufs entités opérationnelles EO_P1, EO T1, EO_D1, EO_D11, EO_D 12, EO_T2, EO_T3, EO_D 12, EO_T31, EO_T32, EO_T3, comprenant chacune une pluralité de deuxièmes composants Cp2 ;
les premiers et deuxièmes composants Cpt, Cp2 étant activés/désactivés par paramétrage au sein dudit premier espace de données D1 en fonction de l'application créée APP1.

On notera que les entités organisationnelles ST représentent des regroupements logiques de personnes physiques (qui sont les unités intervenants). Un regroupement logique peut être dans des exemples non limitatifs une société, une direction, un groupe de projet, un GIE, une association, un comité de pilotage, un groupe qualité, etc.
Ainsi, un espace D comporte une ou plusieurs entités organisationnelles ST
ainsi qu'une ou plusieurs unités intervenants, ces dernières étant rattachées

22 ou non à une ou plusieurs entités organisationnelles ST.

= Le deuxième espace de données D2, tel qu'illustré sur la Fig. 10 - Qui hérite de l'entité organisationnelle ST1 de l'espace commun Dc ;
Et qui comprend :
- une deuxième unité intervenant ITV2 redéfinie comprenant également des composants Cpt;
- Quatre entités opérationnelles EO_P2, EO_D2, EO_T5, EO_T6 comprenant chacune une pluralité de deuxièmes composants Cp2 ;
les premiers et deuxièmes composants Cpt, Cp2 étant activés/désactivés par paramétrage au sein dudit deuxième espace de données D2 en fonction de l'application créée APP1.

Dans des modes de réalisation non limitatifs, les premiers et deuxièmes composants Cpt et Cp2 permettent de définir :
- Des champs, - Des libellés dont une partie peut être associée aux champs, - Des boutons, - Des listes déroulantes, - Des menus, - Des onglets, etc.
qui composent les écrans SCR de l'application représentatifs des entités ST, EO.

On notera que des contrôles, des règles de gestion, des éléments de traitement de procédure (appelé workflow en anglais), des éléments de gestion cachés liés à l'activation et surtout la désactivation appliqués à des composants Cpt, Cp2, etc. sont associés à ces composants Cpt, Cp2.
Ainsi, dans un exemple non limitatif, lorsqu'une application APP ne gère que des unités intervenants sans rattachement à une entité organisationnelle ST, un élément de gestion caché permet de rattacher ces unités intervenants à
une entité organisationnelle ST non activée afin de garder une cohérence dans les données.

On notera que le système de gestion d'application SYS comprend également des éléments d'interface Ule permettant de créer :
- Un espace de données D ;
- Une entité organisationnelle ST ; et - Une entité opérationnelle EO.

23 Ainsi, lors de la création et de l'administration de l'application APP1, un utilisateur de premier niveau U1 va pouvoir effectuer, dans des modes de réalisation non limitatifs, les opérations suivantes.
- Définir un espace de données commun Dc ;
- Définir un espace de données D (qui hérite de l'espace de données commun Dc) ;
- Définir des entités organisationnelles et opérationnelles - Référencer une entité organisationnelle ST dans un espace de données D;
- Référencer une entité opérationnelle EO dans un espace de données ;
- Redéfinir les composants d'un espace de données D par rapport aux composants hérités de l'espace commun de données Dc ;
- Activer/désactiver des composants Cpt, Cp2 au sein d'un même espace de données D ;
- Paramétrer librement de nouveaux composants Cpt, Cp2 - Définir une base de définition de règles associées à des composants Cpt, Cp2 ;
- Attribuer des premiers niveaux d'accréditations à une unité intervenant ITV d'une entité organisationnelle ST;
- Attribuer une pluralité de droits R attribuables à des actions A aptes à
être effectuées par une unité intervenant ITV;
- Attribuer des deuxièmes niveaux d'accréditations Accr2 attribuables à au moins un profil utilisateur auquel sont associés des unités intervenants ITV ;
- Définir des droits d'accessibilité à des composants d'une entité
Demande en fonction d'un état d'avancement et d'un rôle d'une unité
intervenant ;
- Propager automatiquement la définition d'un composant d'une entité
dans une autre ;
- Activer une procédure de traitement paramétrable en fonction d'un type d'entité opérationnelle ; et - Définir des outils d'analyse de données OA
Les opérations sont décrites ci-dessous.
,Définition.d'un.espaçe de données commun.Dc

24 On notera que les objets (et leur composants) contenus dans l'espace de données commun Dc sont visibles par tous les autres espaces de données D. On trouvera ainsi dans l'espace commun Dc, des objets transverses utilisables par tous les autres espaces de données D.
Dans un mode de réalisation non limitatif, pour définir un espace commun de données Dc, l'utilisateur administrateur U1 définira, tel qu'illustré sur la Fig. 11 :
- les libellés de l'espace commun Dc dans des tables TABI associées qui seront directement sous le répertoire LIB-FR du système de fichiers REP
décrit précédemment (dans le cas de libellés en français) ;
- les champs, boutons, listes, menus, onglets ... des écrans SCR relatifs à
cet espace commun Dc dans des tables TABs associées qui seront directement sous le répertoire SCR du système de fichiers REP décrit précédemment.

Ainsi, dans l'exemple de l'application APP1, on aura :
- quatre tables TABI pour les libellés des entités organisationnelles ST1, ST_A et des unités intervenants ITV1, ITV2 ;
- quatre tables TABs pour les champs des entités organisationnelles ST1, ST_A et des unités intervenants ITV1, ITV2.

,Définition..d'un espaçe..de données..D..(qui... érite..de l'espaçe..çomµ..
e données.Dç) Dans un mode de réalisation non limitatif, pour définir un espace de données D, l'utilisateur administrateur U1 effectue les opérations suivantes.
Au niveau de l'interface utilisateur UI, il utilise, dans un exemple non limitatif les éléments d'interface Ule suivants :
- un menu Espace qui fera apparaître un écran SCR correspondant affichant l'ensemble des espaces D existants (y compris l'espace commun Dc) ;
- un bouton sélectionner ou nouveau pour respectivement sélectionner un espace existant ou créer un espace D.
- un écran SCR suivant (suite à l'activation du bouton nouveau ) comprenant :
o un champ code pour entrer une codification CODd de l'espace D créé ;

o un champ libellé pour entrer le libellé LIBd de l'espace D
créé.

Sur cette action, dans un mode de réalisation non limitatif, une table 5 d'espace Tlnk est créée avec :
- la codification CODd de l'espace D créé ;
- le libellé LIBd de l'espace D créé.
On notera qu'il en est de même pour l'espace commun Dc.

10 Dans l'exemple de l'application APP1, on aura ainsi comme représentation logique de la table d'espace Tlnk :

Codification Libellé espace espace CODd_Dc LIBd_Dc CODd_D1 LIBd_D1 CODd D2 LIBd D2 Au niveau du système de fichier REP, l'utilisateur administrateur créera 15 - un premier sous-répertoire sous le répertoire LIB, ayant pour dénomination le nom de codification CODd du nouvel espace créé D;
- un deuxième sous-répertoire sous le répertoire SCR, ayant pour dénomination le nom de codification CODd du nouvel espace créé D.

20 Ainsi, dans le cadre de l'application APP1, pour créer l'espace D2, au niveau du système de fichier REP, l'utilisateur administrateur U1 créera, tel qu'illustré à la Fig. 11 :
- un premier sous-répertoire sous le répertoire LIB, ayant pour dénomination le nom de codification CODd_D2 du nouvel espace créé

25 D2 ;
- un deuxième sous-répertoire sous le répertoire SCR, ayant pour dénomination le nom de codification CODd_D2 du nouvel espace créé D.
On notera qu'un espace D est apte à hériter automatiquement des composants des entités organisationnelles et opérationnelles dudit espace commun de données Dc.
Ainsi, dans un mode de réalisation non limitatif, le système de gestion

26 d'application SYS comporte un dispositif de recherche (non illustré sur les Figs.) des composants d'un espace de données D dans les répertoires associés (créés ci-dessus) (lors de l'utilisation de l'application APP) et si aucun composant (c'est-à-dire tables associées TABs, TABI) n'est trouvé, le dispositif de recherche, recherche au niveau de l'espace commun lesdits composants. Dans un exemple non limitatif, le dispositif de recherche Treq est une requête REQ par exemple sous format SQLTM

Ainsi, les outils de gestion MG_T permettant la construction de réseaux logiques comprenant des espaces de données, comprennent notamment les éléments vus ci-dessus :
- L'interface utilisateur propre à la création d'un espace (menu Espace, boutons, écran vus ci-dessus) - La table d'espace Tlnk ;
- Les sous-répertoires LIB, LIB-FR, SCR ;
- Le dispositif de recherche cité ci-dessus ; et - Les tables TABI, TABs.

On notera que les liens sont activés à l'aide d'une entité écran (interface utilisateur) qui permet d'indiquer le niveau de départ dans le premier espace et le niveau d'arrivée dans le second espace.

On notera qu'un traitement est caractérisé par l'indication dans une table (Oui/Non) de l'activation d'un traitement décrit dans un fichier.
Un flux est caractérisé par une liste d'étapes avec des logiques d'enchainements dans un ou plusieurs espaces.
On peut associer traitements et flux de la même façon par l'indication dans une table de l'activation d'un traitement qui conditionne le flux au niveau d'une étape ou d'un enchainement d'étapes.
Définition_des_entités organisationnelles_et_ opérationnelles Dans des exemples non limitatifs, l'utilisateur utilise les éléments d'interface Ule suivant :
- pour définir une entité organisationnelle ST, un menu définition d'une entité organisationnelle dans l'écran SCR correspondant à l'espace créé D pour laquelle il définira les valeurs des composants Cpt qui sont actifs ;

27 - pour définir une entité opérationnelle EO, un menu définition d'une entité opérationnelle dans l'écran SCR correspondant à l'espace D
créé pour laquelle il définira les valeurs des composants Cp2 qui sont actifs.
L'utilisateur administrateur U1 peut ainsi utiliser ces éléments d'interface Ule pour créer les entités relatives à l'application APP1 et des écrans correspondant SCR auxdites entités créées pour lesquelles il définira les valeurs des composants Cpt, Cp2 qui sont actifs.
A cet effet, au niveau physique, les tables de libellés TABI et les tables des écrans TABs associées à chaque entité organisationnelle ST et opérationnelle EO seront créées.
La signification d'un composant actif est décrite plus loin dans la description.
Dans des modes de réalisation non limitatifs, l'interface utilisateur UI
comprend un élément d'interface Ule pour a chaque type d'entité
opérationnelle, soit pour une entité Projet , une entité Demande , et une entité Tâche .
,Référenc.ement...d'une... entité...organisationnelle. ST.
dans...un...espape... e données Afin d'établir un référencement d'une entité organisationnelle ST dans un espace de données D, dans un mode de réalisation non limitatif, le système de gestion d'application SYS comporte un dispositif de référencement Tlnk d'une entité ST, EO dans un espace de données D, ledit dispositif Tlnk comprenant au moins une première référence à ladite entité et une deuxième référence audit espace de données associé.
Dans un mode de réalisation non limitatif, le dispositif de référencement Tlnk est la table d'espace décrite précédemment comprenant une première référence à ladite entité associée à une deuxième référence audit espace de données, et cette deuxième référence est la codification CODd de l'espace D créé vue précédemment.

Dans l'exemple de l'application APP1 prise précédemment, pour l'espace commun Dc, on aura ainsi dans la table d'espace Tlnk :
- une ligne comprenant la référence ST1 et la ligne codification CODd_Dc

28 associée ;
- une ligne comprenant la référence ST_A et la ligne de codification CODd_Dc associée ; et - une ligne comprenant la référence ITV1 et la ligne de codification CODd Dc associée.

De la même manière, pour l'espace Dl, on aura ainsi dans la table d'espace Tlnk, une ligne comprenant une référence à l'entité organisationnelle ITV1 de l'espace Dl, associées à la ligne codification du champ de l'espace Dl.
De la même manière, pour l'espace D2, on aura ainsi dans la table d'espace Tlnk, une ligne comprenant une référence à l'entité organisationnelle ITV2 de l'espace D2, associées à la ligne codification du champ de l'espace D2.
On obtient ainsi la représentation logique du dispositif de référencement Tlnk suivante.

Codification Libellé espace Entités -espace référencées CODd_Dc LIB_Dc ST1 CODd_Dc LIB_Dc ST_A
CODd_Dc LIB_Dc ITV1 CODd_D1 LIB_D1 ST Dl CODd_D1 LIB_D1 ITV1 CODd_D2 LIB_D2 ST D2 CODd D2 LIB D2 ITV2 Ainsi, lorsque l'utilisateur créera une entité organisationnelle ou opérationnelle via les éléments d'interface Ule appropriés, la table d'espace sera automatiquement remplie.

Référencement.d'une.entité.opérationnelle EO dans un espaçe.de données Le même principe que décrit ci-dessus pour une entité organisationnelle ST
s'applique dans le cas d'une entité opérationnelle EO.

On obtient ainsi la représentation logique du dispositif de référencement Tlnk suivante pour l'application APP1 prise comme exemple non limitatif.

29 Codification Libellé espace Entités -espace référencées CODd_Dc LIB_Dc ST1 CODd_Dc LIB_Dc ST_A
CODd_Dc LIB_Dc ITV1 COD_D1 LIB_D1 ITV1 COD_D1 LIB_D1 EO_P1 COD_D1 LIB_D1 EO_D1 COD_D1 LIB_D1 EO_D11 COD_D1 LIB_D1 EO_D12 COD_D1 LIB_D1 EO_T1 COD_D1 LIB_D1 EO_T2 COD_D1 LIB_D1 EO_T3 COD_D1 LIB_D1 EO_T31 COD_D1 LIB_D1 EO_T32 COD_D2 LIB_D2 ITV2 COD_D2 LIB_D2 EO_P2 COD_D2 LIB_D2 EO_D2 COD_D2 LIB_D2 EO_T5 ,Redéfinition. des. çomposants d'un..espaçe de données D par rapport aux .composants hérités.de l'espaçe.çommun.de.données Dç

Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte un dispositif de redéfinition Tdef des composants Cpt, Cp2 des entités organisationnelle ST et opérationnelle EO
d'un espace de données D par rapport aux composants hérités d'un espace commun de données Dc.
Dans un exemple non limitatif, le dispositif de redéfinition Tdef est un ensemble de tables TABI, TABs associées audit espace D.

Au niveau du système de fichier REP, l'utilisateur administrateur U1 crée - Les tables TABI relatives aux libellés (à définir/redéfinir) des écrans de l'espace créé D dans le premier sous-répertoire sous le répertoire LIB, ayant pour dénomination le nom de codification CODd de l'espace créé

D;
- toutes les tables TABs relatives aux champs, boutons, listes, menus, onglets ... (à définir/redéfinir) des écrans SCR de l'espace créé D dans le deuxième sous-répertoire sous le répertoire SCR, ayant pour 5 dénomination le nom de codification CODd de l'espace créé D.

Ainsi, dans le cadre de l'application APP1 créée on aura le système de fichier REP illustré sur la Fig. 11 pour l'espace D2 :
- Cinq tables de libellés TABI pour définir respectivement les libellés des 10 entités ITV2, EO_P2, EO_D2, EO_T5 et EO_T6 - Cinq tables d'écrans TABs pour définir respectivement les écrans SCR
des entités ITV2, EO_P2, EO_D2, EO_T5 et EO_T6.

Dans l'exemple pris, tous les composants de l'espace D2 sont définis et 15 l'unité intervenant ITV2 a été redéfinie par rapport à celle définie dans l'espace commun Dc.

Le même principe s'applique pour l'espace D1.

20 On notera que dans le cas où un composant Cpt, Cp2 d'une entité
organisationnelle, opérationnelle permet d'accéder à un autre composant (exemple, cas d'un onglet, d'un bouton etc.), cet autre composant est également défini dans le système de fichier REP.
Ainsi, par exemple, dans le cas d'une entité Projet , les composants 15), 25 16), 17) et 18) permettent d'accéder à d'autres composants, dans l'exemple pris des composants représentatifs d'autres écrans, ces derniers étant également définis au moyen des tables TABI et TABs dans le système de fichiers REP.

Açtivation/désaçtivation.des.çomposants d'une.entité.

30 Après la définition/redéfinition des composants d'une entité, il faut les activer afin de choisir pour chaque entité définie quels composants utiliser.

Afin d'activer/désactiver par paramétrage les premiers composants Cpt d'une entité organisationnelle ST et les deuxièmes composants Cp2 d'une entité opérationnelle EO au sein d'un même espace de données D, dans un mode de réalisation non limitatif, le système de gestion d'application SYS
comporte un premier dispositif d'activation Tact1 des composants d'une

31 entité ST, EO.

A chaque entité est associé un premier dispositif d'activation Tact1 des composants de ladite entité ST, EO.
Dans un exemple de réalisation non limitatif, le premier dispositif d'activation Tact1 est également une table sous forme de fichier texte.
Ainsi, dans un exemple non limitatif, une table Tact1 comprendra l'ensemble des composants Cpt, Cp2 définis d'une entité ST, EO avec un drapeau d'activation à positionner à 1 ou 0 pour respectivement activer ou désactiver le composant associé.
On notera qu'une entité non paramétrée dans un espace de données D (qui n'a donc pas de table Tact1 correspondante) n'est pas visible dans cet espace D. Les données de cette entité proviendront des autres espaces D
dans lesquels l'entité est paramétrée.

Dans l'exemple de l'application APP1 prise précédemment, on aura ainsi - Pour l'espace commun Dc quatre tables Tact1 associés respectivement aux quatre objets ST1, ST A, ITV1, ITV2 ;
- Pour le premier espace D1, dix tables Tact1 associés respectivement aux dix objets définis (ITV1, EO_P1, EO_D1, EO_D11, EO_D12, EO T1, EO_T2, EO_T3, EO_T31, EO_T32) dans ledit espace D1 ; et - Pour le deuxième espace D2, cinq tables Tact1 associés respectivement aux cinq objets définis (ITV2, EO_P2, EO_D2, EO T5, EO_T6) dans ledit espace D2.

Ainsi, l'utilisateur administrateur U1 remplit tout simplement ces tables Tact1 afin d'activer/désactiver les composants par paramétrage, et positionne en face de chaque composant le drapeau associé.

Ainsi, dans l'interface utilisateur UI, les écrans SCR correspondant aux entités afficheront uniquement les composants Cpt, Cp2 activés.
Ainsi, lors de l'utilisation de l'application, les écrans n'afficheront que les composants des tables TABs qui ont été activés dans les tables Tact1.

On notera que comme vu précédemment (définition/redéfinition de composants), les composants Cpt, Cp2 accessibles via d'autres composants ont également des tables Tact1 associées.

On notera qu'un composant est activé/désactivé au sein d'un même espace

32 D. Ainsi, pour associer les tables d'activation Tact1 à un espace de données D voulu, une requête de recherche REQ est utilisée dans un mode de réalisation non limitatif. Cette requête REQ permet à partir de la référence d'une entité (vue précédemment) dans la table espace de données Tlnk d'avoir un accès direct à la table d'activation/désactivation des composants.
Ainsi, dans un exemple non limitatif, si une entité Projet comprend les composants Cp2 avec les libellés associés tels que décrits précédemment, on peut par exemple avoir dans le premier espace Dl, le projet EO_Pl avec tous les composants d'actifs et qui seront donc visibles (ou actifs) sur l'écran SCR correspondant, et dans le deuxième espace D2, le projet EO_P2 avec uniquement les composants 2) à 8) d'actifs et qui seront donc visibles (ou actifs) sur l'écran SCR correspondant.

On aura ainsi une représentation logique d'une table d'activation/désactivation Tact1 suivante pour l'exemple d'entité Projet ci-dessus.

Pour le domaine Dl Composant Drapeau 1) Titre projet - champ dynamique 1 2) Code - champ dynamique 1 3) Type de projet - liste dynamique 1 4) Etat Ouvert/Fermé - champs 1 5) Date début - champ dynamique 1 6) Date Fin - champ dynamique 1 7) Statut - liste dynamique 8) Planning - onglet 9) Criticité - liste dynamique 10) Domaine technique - liste 1 dynamique 11) Délai - champ 12) Service - liste 1 13) Client - liste 1 14) Responsable - liste 1 15 Affectation unité intervenant 1 16) Affectation entité 1 organisationnelle

33 17) plan de charge 18) Planning 1 Pour le domaine D2 :
Composant Drapeau 1) Titre projet - champ dynamique 0 2) Code - champ dynamique 1 3) Type de projet - liste dynamique 1 4) Etat Ouvert/Fermé - champs 1 5) Date début - champ dynamique 1 6) Date Fin - champ dynamique 1 7) Statut - liste dynamique 1 8) Planning - onglet 1 9) Criticité - liste dynamique 0 10) Domaine technique - liste 0 dynamique 11) Délai - champ 0 12) Service - liste 0 13) Client - liste 0 14) Responsable - liste 0 15 Affectation unité intervenant 0 16) Affectation entité 0 organisationnelle 17) plan de charge 0 18) Planning 0 Ainsi, ce paramétrage par espace de données D permet d'avoir une gestion de l'application APP1 très souple.

On notera que dans un mode de réalisation non limitatif, le système de gestion d'application SYS comporte en outre des moyens de vérification de la cohérence en temps réel entre les objets à l'activation ou la désactivation d'un objet.

L'activation d'une donnée implique la génération des tables ou items de tables nécessaires pour permettre les activations associées : activation des critères associés à la donnée, intégration de la donnée dans des entités

34 écrans ou des tableaux de synthèse. Lors de la désactivation d'une donnée obligatoire à la cohérence du système, ce dernier prend en charge en back office la gestion de cette donnée pour maintenir la cohérence sans impact sur l'application concernée.

On notera par ailleurs que dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte en outre un dispositif de qualification QUAL apte à de définir une entité organisationnelle ST même si elle n'est pas utilisée (elle est donc désactivée) dans l'application créée APP, afin de maintenir une cohérence de données.
L'entité organisationnelle ainsi qualifiée n'est donc pas visible par l'utilisateur, mais existe quand même.
La définition se fait au moyen des tables TABI et TABs vue précédemment mais qui ne seront pas accessibles par l'application APP. Dans ces tables TABI, TABs, au moins un composant (champ, onglet, menu, liste...) est défini, i.e. comporte une valeur par défaut, mais n'est pas visible par l'application APP i.e. n'est pas activé. Les autres composants non définis ne sont pas activés non plus.
Afin de maintenir la cohérence des données, lorsqu'une application APP
utilise des unités intervenants mais aucune entité organisationnelle, le dispositif de qualification QUAL effectue un rattachement logique des unités intervenants à l'entité organisationnelle ST définie ci-dessus par défaut.
Au niveau physique, un pointeur dans une unité intervenant vers l'entité
organisationnelle ST est utilisé.

Par ailleurs, on notera que les outils d'identification ID_T (cités plus haut) des activations possibles d'objets liés à une activation initiale d'un objet permettent de vérifier et d'activer automatiquement des objets et/ou composants qui sont liés à un objet et/ou composant activé par l'utilisateur, et que ce dernier a oublié d'activer. Ainsi, par exemple, le composant date début d'un objet Projet a été activé, mais pas le composant date fin par l'utilisateur. Les outils d'identification ID_T active alors automatiquement le composant date fin .

Paramétrage.libre.de nouveaux.çomposants. ppl.,. Pp2 Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte en outre un dispositif de paramétrage libre Tpf de nouveaux composants Cpt, Cp2 dans une entité ST, EO, dans un outil d'analyse OA ou dans un écran SCR.
5 Dans une variante de réalisation non limitative, ce dispositif de paramétrage est une pluralité de lignes vierges dans un dispositif d'activation Tact1 d'une entité ST, EO.
Cela permet d'obtenir une évolution des entités.
Ainsi dans l'exemple de l'application APP1 prise et du projet EO_P1, on peut 10 ajouter une ligne 19) affectation intervenants - onglet qui permet de gérer les intervenants affectés sur ledit projet EO_P1, ce qui correspond aux zones libres décrites précédemment. Il peut également exister un champ déjà défini mais qui n'avait pas été activé auparavant et qui sera activé à 1.

15 Définir une..base de définition..de.règles..associées à.des.composants p1, Çp2.d'uneentité.ST,..Eà

Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte en outre une base de définition de règles Tbdr associée à des composants Cpt, Cp2 d'une entité ST, EO de sorte à vérifier 20 la cohérence en temps réel d'un écran. Cela permet de définir des règles relatives, par exemple, à un enchaînement d'étapes dans une entité
Projet .

Dans un mode de réalisation non limitatif, la base de définition règles Tbdr est définie dans une table sous format texte. Cette table Tbdr sera vérifiée à
25 chaque fois qu'un composant Cpt, Cp2 est sollicité par un utilisateur administrateur U1 ou final U2 via l'interface utilisateur UI. Dans un mode de réalisation non limitatif, le langage utilisé de définition de règles est sous format texte.

Ainsi par exemple, dans l'exemple pris de l'application APP1, dans le 30 premier espace D1, on peut définir une règle sur un composant Cp2 Date Clôture d'une entité Demande EO_D11 selon laquelle si la date de clôture est définie, alors on peut passer à l'entité Demande EO_D12 suivante. Cela permet de maintenir une cohérence dans l'application APP1.
L'utilisateur administrateur U1 pourra définir une base de règles en

35 remplissant tout simplement la table Tbdr.

36 Attribution des niveaux d'accréditations N et des droits R

Afin d'effectuer les opérations d'attribution des niveaux d'accréditation N et des droits R, le système de gestion d'applications SYS comporte un dispositif d'accréditations Ta comprenant :
- Une pluralité de premiers niveaux d'accréditations Ni attribuables à une unité intervenant ITV d'une entité organisationnelle ST;
- Une pluralité de droits R attribuables à des actions A aptes à être effectuées par une unité intervenant ITV;
- Une pluralité de deuxièmes niveaux d'accréditations N2 attribuables à au moins un profil utilisateur PR auquel sont associés des unités intervenants ITV ;
- Lesdits premiers et deuxièmes niveaux d'accréditations Ni, N2 et ladite pluralité de droits R étant aptes à êtres combinés entre eux.
Les niveaux et droits sont définis ci-dessous.

= Définition.des.premiers iveaux.d'aççrédita.ions.N1.

Dans un mode de réalisation non limitatif, cinq premiers niveaux d'accréditations Ni sont définis.
- N1 P = Personnel - N1 S = Service - Ni SF = Service fils - N1 G = Général - Le niveau Ni P représente les accréditations relatives à une unité
intervenant connectée à une application APP.
On notera qu'une unité intervenant connectée est différente d'un utilisateur personne physique. L'unité intervenant connectée est le login/mot de passe reconnu par le système de gestion d'applications SYS et auquel des droits R ont été alloués.
Une unité intervenant connectée possède au niveau Ni P les accréditations sur les objets avec lesquels il possède un lien direct. Un lien direct existe quand il y a correspondance entre le mot de passe de l'unité intervenant connecté et l'unité intervenant qui est possesseur de l'objet.
Par exemple, le possesseur d'un objet Demande est l'émetteur de la Demande (tel que défini précédemment dans l'entité Demande en

37 tant que composant 9)), le possesseur d'un objet Projet est le responsable du Projet ((tel que défini précédemment dans l'entité
Projet en tant que composant 14)) etc.

- Le niveau 1\11S représente les accréditations relatives à une unité
intervenant connectée qui possède des droits R sur les objets gérés par l'entité organisationnelle et service de l'unité intervenant. Le service de l'unité intervenant est par exemple indiqué dans un composant de l'entité
organisationnelle service de l'unité intervenant (composant 8) défini précédemment).

- Le niveau N1 SF représente les accréditations relatives à une unité
intervenant connectée qui possède des droits R sur les objets gérés par l'entité organisationnelle et service fils du service de l'unité intervenant.
Une entité organisationnelle service fils est par exemple indiquée dans un composant de l'entité unité organisationnelle (composant 4) défini précédemment).

On notera que dans un mode de réalisation non limitatif, les accréditations allouées au niveau d'un service ne sont pas hérités par défaut par les services fils. De la même manière, les accréditations allouées au niveau d'un service fils ne sont pas donnés par défaut au service.

- Le niveau Ni G représente les accréditations relatives à une unité
intervenant connectée qui possède les droits R alloués à tous les objets gérés dans le système de gestion d'applications SYS.

= Déf.i.n.i..ti.....on... de.....s...
de.......ux...ièm......e.s...........nivea.....ux...
d.'..........accré...di....tat...ion.....s......N2 .......
Dans un mode de réalisation non limitatif, au moins un profil utilisateur PR
auquel sont associés des unités intervenants peut être associé à un espace de données D.
On notera qu'une unité intervenant peut appartenir à plusieurs profils utilisateurs PR.
Ainsi, l'utilisateur administrateur U1 peut créer des profils utilisateurs PR
et ensuite leur attribuer des unités intervenants le tout via des éléments d'interface Ule appropriés.

38 Par la suite, l'utilisateur administrateur U1 peut attribuer une pluralité de deuxièmes niveaux d'accréditations N2 à au moins un profil utilisateur PR
auquel sont associés des unités intervenants ITV via des éléments d'interface Ule appropriés.
Au niveau physique, à ce moment, la table d'accréditations Ta correspondant aux deuxièmes niveaux d'accréditations N2 pointera sur l'unité intervenant ITV et/ou le profil utilisateur PR associé.

On notera que les deuxièmes niveaux d'accréditations N2 sont définis de la même manière que les premiers niveaux d'accréditations Ni, à savoir :
- N2P = Personnel - N2S = Service - N2SF = Service fils - N2G = Général Dans des exemples non limitatifs on peut avoir des profils utilisateur PR
relatifs à :
- des chefs de projet - des responsables de service - des administrateurs - la maîtrise d'ceuvre - la maîtrise d'ouvrage - des profils métiers différents etc.

= Définition ... de.....s... dr....o..its....R
.........
Dans un mode de réalisation non limitatif, cinq droits R attribuables sur des actions A (lecture, écriture, création, suppression, administration) sont définis et qui sont applicables à chaque niveau d'accréditations Ni, N2.
- RL = Lecture : une unité intervenant connectée/un profil utilisateur connecté a accès aux objets uniquement en lecture.
- RE= Ecriture : une unité intervenant connectée/un profil utilisateur connecté a accès aux objets uniquement en écriture (modification seule sans possibilité de création ou suppression). On notera que dans un mode de réalisation non limitatif, le droit RE implique le droit RL.
- RC= Création : une unité intervenant connectée a accès aux objets en création. On notera que le droit RC n'englobe pas les droits RE et RL.
- RS= Suppression : une unité intervenant connectée/un profil utilisateur

39 connecté a accès aux objets en suppression. On notera que le droit RS
n'englobe pas les autres droits.
- RA= Administration : une unité intervenant connectée/un profil utilisateur connecté a accès aux objets en administration. Le droit RA englobe tous les droits RL, RE, RC et RS.
- RP = droit de modification des composants et des étapes d'une entité
Demande . une unité intervenant connectée/un profil utilisateur connecté a un statut de valideur (comme expliqué plus loin dans la description).
Les exemples non limitatifs suivants illustrent l'attribution des droits R
pour une unité intervenant ITV.
Exemple 1 : une unité intervenant ayant les seuls droits de création et de modification au niveau Ni P pour un objet Demande pourra créer une entité Demande et modifier les entités Demande dont il est émetteur.
Il ne pourra pas accéder aux demandes dont il n'est pas émetteur.
Dans un exemple non limitatif, comme vu précédemment, une entité
Demande comprend un champ Emetteur dans lequel l'utilisateur administrateur U1 peut entrer le nom de l'émetteur de l'entité Demande .
Exemple 2 : une unité intervenant ayant les droits de lecture au niveau N1 S
pour un objet Projet pourra consulter toutes les entités Projet du Service auquel il appartient.
Dans un exemple non limitatif, une entité Projet comprend un champ service dans lequel l'utilisateur administrateur U1 peut entrer le nom d'un Service qui est responsable de l'entité Projet .
Dans un exemple non limitatif, une unité intervenant est affectée à un service sur une période via un composant avenant unité intervenant (avec gestion des dates de validité des entités unités intervenants).
Exemple 3 : une unité intervenant ayant les droits de lecture au seul niveau N1 SF pour un objet Tâche pourra consulter les tâches des demandes rattachées à un des sous-services dépendants de son service.
Dans un exemple non limitatif, une unité intervenant est affectée à un service sur une période via un composant avenant unité intervenant (avec gestion des dates de validité des entités unités intervenants). Il sera automatiquement propagé aux sous-services de ce service.
Les mêmes exemples peuvent être pris pour un profil utilisateur PR.

Ainsi, pour la définition des premiers Ni et deuxièmes niveaux N2 d'accréditations, dans un mode de réalisation non limitatif, l'utilisateur administrateur U1 peut utiliser des éléments d'interface Ule appropriés 5 pour:
- choisir l'espace de données D ou Dc dans lequel il veut définir les niveaux d'accréditations.
- Puis, choisir le profil utilisateur PR ou une unité intervenant selon qu'il souhaite définir des accréditations pour un profil utilisateur ou une unité
10 intervenant.
- Choisir les accréditations Ni, N2 à donner et des droits associés R.

Dans un mode de réalisation non limitatif, le dispositif d'accréditations Ta est apte à attribuer un droit R sur des actions A associées à un espace 15 de données D, une entité ST, EO, un composant Cpt, Cp2.
Dans un mode de réalisation non limitatif, le dispositif d'accréditations Ta comporte une table associée à l'espace choisi D ou Dc, et à l'unité
intervenant ou le profil utilisateur choisi PR, dans laquelle :
On a pour chaque premier niveau d'accréditations Ni les droits associés RL, 20 RE, RC, RS, RA, chaque niveau d'accréditations Ni étant associé à une classe CLg, une classe CLg définissant une entité ou un composant sur lequel on veut attribuer un niveau et un droit, tel qu'illustré sur la Fig.
12, dans une représentation logique.
Dans un mode de réalisation non limitatif, le dispositif d'accréditations Ta est 25 une table. Ainsi, grâce à cette table d'accréditations Ta à plusieurs dimensions, les premiers et deuxième niveaux d'accréditations Ni, N2 et la pluralité de droits R peuvent être combinés entre eux.

On notera par ailleurs que la table d'accréditations Ta comporte une colonne 30 supplémentaire CLe comprenant la dénomination spécifique de chaque entité ou composant d'un espace donné D, alors que la colonne CLg comprend la dénomination générique pour chaque entité ou composant pour une application APP.

35 On notera que les accréditations Ni, N2 décrites ci-dessus sont définies par espace de données D. Dans ce cas, les accréditations Ni, N2 ne sont valides que dans l'espace où elles sont définies.
Dans un mode de réalisation non limitatif, on notera que les accréditations Ni, N2 définies pour l'espace de données commun Dc sont applicables pour tous les espaces D. Ainsi, un espace D hérite des accréditations données à
une unité intervenant/profil utilisateur dans l'espace commun Dc. Cela évite de devoir redonner des droits identiques dans tous les espaces de données D. On effectue ainsi une factorisation des droits.
Ainsi, les accréditations Ni, N2 gérées à la fois dans l'espace commun Dc et un espace D pour une unité intervenant/profil utilisateur entraînent un cumul des droits R attribuables à des actions (le droit maximal défini est celui retenu).
De.fi...n.ir....d....e.s ....
d...r..o.id.t..s..........acc..........essib.ilité ........ a....tt.r.ie a .b....u....s.......des ................. composants d une entité
.Ro d'une ...Demande..
.fonction..
.d.'.avancement..
. d.'.un..état.
.et..d.'.un..rôle.
. Ste..
. ...en..
.
.
.
.
.
.
.
...............................................................................
.................. .
unité intervenant Le système de gestion d'applications SYS comporte un dispositif d'accessibilité Tacc à des composants Cpt, Cp2 d'une entité opérationnelle EO en fonction d'un état d'avancement Ste de l'entité opérationnelle EO et d'un rôle Ro attribué à une unité intervenant ITV d'une entité
organisationnelle ST, l'état d'avancement Ste étant apte à s'appliquer à
plusieurs espaces D en respectant les différentes instanciations (c'est-à-dire en respectant les différents jeux d'activation et de personnalisation). On notera qu'un état d'avancement se situe dans un workflow cité plus haut.
L'unité intervenant connectée a des rôles Ro en fonction d'informations entrées dans le système de gestion d'applications SYS, soit par rapport à
l'organisation des unités intervenant, soit par rapport à une entité
Demande . On notera qu'une même unité intervenant peut avoir plusieurs rôles simultanément. On notera que le rôle Ro d'une unité
intervenant est automatiquement connu du système de gestion d'applications SYS en fonction des informations saisies par celle-ci (nom, prénom, login, mot de passe).

Dans des modes de réalisation non limitatifs, les rôles Ro attribuables à une unité intervenant sont :
- Aucun rôle : une entité Demande n'est pas visible par l'unité
intervenant - RoEM = Rôle Emetteur : l'émetteur d'une entité Demande est l'unité
intervenant connectée - RoRU = Rôle Responsable utilisateur =

- Si l'unité intervenant connectée est valideur ; ou - Si l'unité intervenant connectée est le responsable informatique, plus précisément, le responsable de l'entité
organisationnelle service destinataire, en charge de la réalisation de l'entité Demande ; ou - Si l'unité intervenant connectée est le responsable du service de l'émetteur de l'entité Demande ; ou - Si le service de l'unité intervenant connectée est le service de l'émetteur de l'entité Demande .
On notera qu'un valideur est une unité intervenant qui peut modifier les composants et étapes dans une entité Demande et qui appartient au service qui est à l'origine de cette Demande .

- Rol = Rôle responsable Informatique :
- Si l'unité intervenant connectée est valideur ; ou - Si l'unité intervenant connectée a le rôle Administrateur ; ou - Si l'unité intervenant connectée a le rôle Chef de Projet ; ou - Si l'unité intervenant connectée est le responsable du service destinataire (service qui réalise la Demande) de l'entité Demande ou - le service de l'unité intervenant connectée est le service destinataire (service qui réalise la Demande) de l'entité Demande .
- RoCU = Rôle Correspondant Utilisateur : si l'unité intervenant connectée est le responsable d'un composant stock utilisateur de l'entité
Demande . En pratique, cela correspond aux gestionnaires du stock des entités Demande côté MOA (maîtrise d'ouvrage), i.e, côté
donneur d'ordre.
- RoCI = Rôle Correspondant Informatique : si l'unité intervenant connectée est le responsable d'un composant stock informatique de l'entité Demande En pratique, cela correspond aux gestionnaires du stock des entités Demande côté MOE (maîtrise d'oeuvre), i.e. côté
réalisateur.
- RoCp = Rôle Chef de Projet : Si l'unité intervenant connectée est responsable de l'entité Projet auquel est rattaché l'entité
Demande RoRT = Rôle Administrateur : si le login de l'unité intervenant connectée est un login administrateur Dans des modes de réalisation non limitatifs, les états d'avancement Ste d'une entité Demande sont Etats de la Type Signification Demande Etat Supprimé SteO Demande supprimée Etat Initial Stel Demande en mode brouillon Etat Demandeur Ste2 Demande en cours de traitement côté Demandeur Etat Personnalisé Ste4 Etat que l'on peut personnaliser Etat Réalisateur Ste5 Demande en cours de traitement côté réalisateur Etat Terminé Ste8 Traitement de la Demande terminée Etat Rejeté Ste9 Traitement rejeté de la Demande Dans un mode de réalisation non limitatif, le dispositif d'accessibilité Tacc (qui confère la possibilité de modifier un composant) sur des composants d'une entité Demande en fonction d'un rôle Ro d'une unité intervenant et d'un état d'avancement Ste comporte :
1) Une table TCp de composants Cpt, Cp2 des écrans correspondant à
une entité Demande qui comprend - Les libellés LIB des composants ; et - Un code composant associé VAL ;
Ainsi, dans un exemple non limitatif, on aura une table TCp suivante associée à une entité Demande :

Libellés LIB des composants des écrans Code VAL
C 1,C 2 Statut 1 Destinataire 2 Budget 3 Projet 4 Date ouverture 5 Date clôture 6 Service destinataire 7 Client 8 Emetteur 9 Service origine A
Composants pour l'onglet Affectation B, ...
entité organisationnelle Composants pour l'onglet Affectation C, ...
unité intervenant Composants pour l'onglet Planning D, ...
Composants pour l'onglet Solution E, ...
Composants pour l'onglet Suivi de frais F, ...
Composants pour l'onglet Zones libres G, ...

2) Une table de paramétrage Tprm permettant de définir les composants Cpt, Cp2 d'une entité Demande qui sont accessibles en fonction du rôle Ro d'un utilisateur.
Ainsi, dans un exemple non limitatif, on aura une table Tprm suivante associée à une entité Demande :

Etats de la Type Zone modifiable Demande Etat Supprimé Ste0 Etat Initial Ste1 RoEM 147 ; ...
Etat Demandeur Ste2 Etat personnalisé Ste4 Etat Réalisateur Ste5 Etat Terminé Ste8 Etat Rejeté Ste9 La syntaxe de la zone modifiable est la suivante Rôle1 [Liste des composants Cpt, Cp2 accessibles pour ce rôle]
Rôle2[Liste des composants Cpt, Cp2 accessibles pour ce rôle] ;
Rôlen[Liste des composants Cpt, Cp2 accessibles pour ce rôle]
Ainsi, dans l'exemple explicatif pour l'étape Ste1, l'utilisateur qui a un rôle Emetteur a le droit de modifier les composants Statut, Service destinataire, et Projet.
On a ainsi une table de paramétrage Tprm par entité Demande .

Ainsi, l'utilisateur administrateur n'aura qu'à compléter ces tables TCp, Tprm 5 (ou tout autre table logique équivalente) pour déterminer les droits d'accessibilité sur des composants d'une entité opérationnelle EO, ici l'entité
Demande en fonction d'un rôle Ro d'un utilisateur.
Ainsi, par exemple, lorsqu'un utilisateur se positionnera sur le champ Emetteur de l'entité Demande correspondante, via l'élément 10 d'interface approprié Ule, le système de gestion d'applications SYS
vérifiera la table de paramétrage Tprm associée au rôle de l'unité intervenant connectée via une requête REQ par exemple.

Ainsi, grâce à la combinaison des accréditations, droits R et droits 15 d'accessibilité vus ci-dessus, on peut gérer de manière très fine les accès aux entités, composants d'une application APP.

,Dispositif de..propagation..automatique.Dl!~Qd'une.définition..d'un.çomposant d'une entité dans une autre ...................................................
Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte en outre un dispositif de propagation automatique DICO d'une définition d'un composant Cpt, Cp2 d'une entité
ST, EO, appelée entité origine, dans une autre entité, appelée entité cible ST, EO dans lequel il se trouve également.
Dans un exemple non limitatif, le dispositif de propagation automatique DICO comporte des pointeurs sur des composants Cp, Cp2 que l'on veut utiliser dans une autre entité. Ainsi, une entité ST, EO cible comporte à
l'endroit où doivent se trouver les composants Cpt, Cp2, des pointeurs sur une entité origine ST, EO, cette dernière comprenant une définition des composants Cpt, Cp2.
Ce dispositif de propagation peut être appliqué à une entité ST, EO dans son ensemble.
On effectue ainsi un lien inter-espaces entre composants Cpt, Cp2 et/ou entre entités ST, EO.

Açtiver. une..proçédure..de traitement..paramétrable..en.
fonçtion..d'un..type, d'entité.opérationnelle:.

Dans un mode de réalisation non limitatif, le système de gestion d'applications SYS comporte en outre un deuxième dispositif d'activation Tact2 d'une procédure de traitement paramétrable WF en fonction d'un type TY d'entité opérationnelle EO.
Ainsi, dans un exemple non limitatif, on associe un type TY à une entité
Demande . En fonction de ce type TY, on donne accès à des fonctions propres à cette entité Demande . Par exemple, pour un type donné, les fonctions accessibles sont les onglets Affectation unité intervenant et Onglet Planning tels que vus précédemment ; les autres fonctions onglets Solution , Suivi de frais et zones libres n'étant pas accessibles.
Dans un exemple non limitatif, le deuxième dispositif d'activation Tact2 est un fichier XML dans lequel on regarde le type TY d'entité opérationnelle EO
et selon ce type, on associe les fonctions voulues.
Par la suite, comme vu précédemment, selon les étapes d'une Demande et le rôle Ro de l'utilisateur, on a accès ou non à certains champs, listes, menus, onglets etc.

.D.éfin.it.i.o.n.d.'.o.ut.ils.d.'.ana.lv.s.e.d.e..Oo.n.né.es.OA
Les outils d'analyse de données OA permettent de suivre, grâce à un ensemble d'indicateurs, les actions en cours ou réalisées d'une entité
opérationnelle par exemple.
Ainsi, ces outils sont dans des exemples non limitatifs - Des tableaux de synthèse ;
- Des critères de recherche - Des arbres dynamiques de données qui s'affichent sur un écran - Des indicateurs ;
- Des statistiques ...
Un utilisateur administrateur va définir ces outils de la manière suivante Les outils sont activés soit à l'initiative de l'utilisateur administrateur par l'indication combinée dans une table et un ou plusieurs fichiers de l'activation soit de manière automatique par le système. Suite à l'activation de l'outil, d'autres activations peuvent être demandées. Une fois toutes les activations effectuées, il est possible de personnaliser en fonction des entités et données associées et activées. Par exemple, l'activation d'un statut d'entité permet d'activer des affichages dans l'arbre ou des modes de fonctionnement de l'interface utilisateur, ou l'accès à des entités écrans.

= Utilisation d'une application APP

Ainsi, lors de l'utilisation d'une application APP, un utilisateur de deuxième niveau U2 va pouvoir effectuer, dans un mode de réalisation non limitatif, les opérations suivantes.
- Dupliquer une entité opérationnelle EO.
- Transmettre des composants définis par filtrage à des systèmes de gestion externes.
Les opérations sont décrites en détail ci-après.
,Dupliquer une entité opérationnelle. EO,.

Dans un mode de réalisation non limitatif, le système de gestion d'application APP1 comporte un dispositif de duplication Rdp d'une entité
opérationnelle d'origine EOs apte à utiliser une unité de redéfinition Form des composants Cpt, Cp2 de l'entité opérationnelle dupliquée EOd par rapport à l'entité opérationnelle d'origine EOs.
Dans un exemple non limitatif, un utilisateur de l'application peut ainsi via des éléments d'interface appropriés Ule:
- choisir une duplication d'une entité opérationnelle d'origine EOs - choisir via l'unité de redéfinition Form les composants Cpt, Cp2 de l'entité opérationnelle d'origine EOs dont il veut recopier le contenu ;
- choisir via l'unité de redéfinition Form les composants Cpt, Cp2 de l'entité opérationnelle d'origine EOs dont il veut modifier le contenu - saisir le contenu des composants Cpt, Cp2 qu'il veut modifier.

L'entité dupliquée EOd comprend ainsi la structure des données de l'entité
d'origine Eos avec :
- des composants d'origine Cpt, Cp2 recopiés avec leur contenu d'origine - des composants d'origine Cpt, Cp2 recopiés avec un contenu différent saisi par l'utilisateur lors de la duplication.
Au niveau physique, dans un mode de réalisation non limitatif, les tables TABs et TABI de l'entité d'origine EOs qui a été dupliquée seront mise à
jour avec des lignes supplémentaires correspondant à un composant Cpt, Cp2 dupliqué dont le contenu a été modifié. Une ligne comprend ainsi un code COD_EOd correspondant à l'entité dupliquée EOd et le contenu saisi du composant Cpt, Cp2 modifié. L'entité dupliquée EOd comprend ainsi un pointeur sur les tables TABs et TABI de l'entité d'origine EOs.
Ainsi, permet de réduire le nombre de tables utilisées.
Transmettre/recevoir.des.omposants.définis..par.filtrage à des systèmes de ,gestion.externes..

Lorsqu'il utilise une application APP, un utilisateur final U2 peut afficher (via l'interface utilisateur UI) des composants d'entités ST, EO à l'aide de système de gestion de données externes à l'application.
A cet effet, le système de gestion d'application SYS comporte un dispositif d'import/export générique Rt de composants desdites entités ST, EO et/ou desdits outils OA définis par filtrage à des systèmes de gestion de données ED aptes à coopérer avec les systèmes SYS de gestion d'applications de sorte à générer un flux générique qui est créé avec les jeux d'activation et de personnalisation.
Ainsi, selon l'application choisie, le dispositif d'import/export Rt génère un flux dédié à ladite application, ledit flux pouvant être différent par rapport à
une autre application.

Dans un mode de réalisation non limitatif, le filtrage est effectué au moyen de table de filtrage Tf sous format texte, dans laquelle on définit les composants des entités que l'on veut afficher. Dans un exemple non limitatif, une table de filtrage Tf est associée par entité.
Dans un mode de réalisation non limitatif, le dispositif d'import/export Rt utilise l'appel d'une URL avec indication du nom de la table de filtrage Tf à
afficher.
Les systèmes de gestion de données externes ED sont dans des exemples non limitatifs, des graphes, des tableaux de bord, tout autre système susceptible de recevoir des données via un fichier csv ou XML par exemple etc.

Cela permet l'édition de données déterminées par filtrage et dans un format particulier des systèmes de gestion de données externes.

On notera que l'on peut également conditionner le filtrage des données avec un statut affecté à l'entité organisationnelle dans l'utilisateur de l'application APP. Ainsi, une entité organisationnelle peut avoir le statut de Client, Fournisseur, Payeur ou Service (ce dernier statut signifiant le Service qui est émetteur d'une demande).

Bien entendu, l'invention n'est pas limitée aux modes de réalisation décrits.
Ainsi, pour les entités opérationnelles, on peut par exemple ajouter un composant onglet Commentaires avec un écran approprié associé.
Ainsi, pour l'entité Demande , on peut avoir les composants supplémentaires suivants : Historique, Demandes liées, Suivi prévu, Suivi réel, Analyse, Tests, Recette, Etape de la Demande, Urgence, Description, Devis, Gains attendus ; Gains chiffrables, Date production, Date impérative, Date recette.
Ainsi, le processus de définition des droits d'accessibilité sur des composants d'une entité Demande en fonction d'un état d'avancement Ste et d'un rôle Ro pourrait être appliqué à une entité Projet ou Tâche .
Ainsi, selon les libellés associés, une entité opérationnelle de premier niveau peut être différente d'un Projet, une entité opérationnelle de deuxième niveau peut être différente d'une Demande, une entité opérationnelle de troisième niveau peut être différente d'une Tâche.

= Lancement d'une application.
Lorsqu'une application a été créée et paramétrée, un utilisateur l'utilise de la manière suivante.
Il se connecte au système de gestion d'application SYS via un écran initial de connexion SCR_INIT avec un login mot de passe. Le login mot de passe est représentatif d'une unité intervenant et de son rôle vus précédemment.
Selon son login mot de passe, une liste des espaces de données D sont proposés à l'utilisateur. Ce dernier choisit l'espace de données D dans lequel il souhaite travailler. Il peut définir un espace par défaut à la connexion. S'il ne peut choisir aucun espace, l'espace commun Dc est choisit par défaut.

A ce moment, l'objet connecteur ML mettent en oeuvre les modèles génériques, la base de données, l'ensemble de tables et de fichiers, lesdits outils d'identification et de gestion vus précédemment. Ainsi, l'application APP qui correspond à un jeu d'activation et de personnalisation 5 correspondant au login mot de passe est lancée.
Dans un mode de réalisation non limitatif, l'interface utilisateur UI affiche un arbre logique des objets de l'application. L'arbre logique affiche les entités organisationnelles ST et opérationnelles EO et leur rattachement (tels qu'illustrés aux Fig.9 et Fig. 10), les outils d'analyse OA etc.
10 A chaque sollicitation de l'utilisateur via l'interface utilisateur UI
(c'est-à-dire à chaque fois que l'utilisateur va cliquer sur un objet de l'arbre), l'écran correspondant se construit (il y a une recherche par l'objet connecteur ML
des tables et fichiers correspondant à l'activation et la personnalisation des composants de l'objet, et des données de l'objet à afficher dans les zones 15 de l'écran correspondant).
On notera que les accréditations correspondant à l'utilisateur sont vérifiées à
chaque fois qu'il y a une sollicitation et les objets, composants, etc.
auxquels l'utilisateur a le droit d'accéder s'affichent dans l'écran. Ainsi, un écran n'existe pas avant que l'utilisateur fasse appel à lui. On a ainsi une 20 construction en temps réel d'un écran.

Ainsi, grâce aux jeux d'activation et de personnalisation, on définit une instanciation INST du système de gestion d'application, une telle instanciation étant une application. De plus, à partir d'un jeu d'activation et 25 de personnalisation, et donc d'une instanciation, on peut définir une extension, c'est-à-dire un jeu complémentaire d'activation et de personnalisation. Par le jeu de différentes extensions, on obtient ainsi différentes versions d'une application, évoluant ainsi à l'instar d'un progiciel par versions successives.
30 Ainsi, grâce à l'invention, on obtient des progiciels qui sont définis par des utilisateurs qui ne sont pas informaticiens.
Ces progiciels sont génériques puisqu'ils peuvent servir pour toute sorte de destinataire. Seuls les différents jeux d'activation et de personnalisation permettront de définir une destination déterminée.

Ainsi, l'invention présente en outre les avantages suivants - Elle permet à n'importe quel utilisateur qui n'est pas informaticien de gérer une application et de la faire évoluer ;
- Elle permet un paramétrage simple d'une application grâce au groupe de tables G_TAB ;
- Elle permet de traiter des applications complexes ;
- Elle permet d'avoir une combinaison d'accréditations et de droits très souple ;
- Elle permet au sein d'un même référentiel (groupe de table G_TAB) de gérer non seulement les projets, demandes et tâches, mais éga-lement en même temps les ressources (entités organisationnelles, unités intervenants) travaillant pour ces projets, demandes et tâches ;
- Elle permet au sein d'un même référentiel (groupe de table G_TAB) de gérer des entités différentes d'un même groupe dans des modes de gestion différents (mode projet, mode événementiel, mode récur-rent). Ainsi, dans un exemple non limitatif, pour une application rela-tive à un groupe de direction des systèmes d'information DSI, on peut gérer des entités relatives à différents métiers tels que :
- les études dont les unités intervenants travaillent en mode pro-jet, par exemple lorsqu'il y a un développement d'outils informa-tiques à effectuer ;
- la production dont les unités intervenants travaillent en mode événementiel, par exemple lorsqu'il y a un problème de flux de données à régler dans un réseau informatique ;
- la maintenance dont les unités intervenants travaillent en mode récurrent, par exemple lorsqu'il faut maintenir des serveurs infor-matiques en état de bon fonctionnement ou encore s'occuper de la sécurité du réseau informatique.
- Elle permet d'avoir une conception logique d'une application grâce au découpage en espace de données logiques ;
- Elle permet d'avoir une base de données unique non sémantique dont les données seront caractérisée grâce aux différents jeux d'activation et de personnalisation vu précédemment ;

- Elle permet un affichage en temps réel d'un écran en fonction d'une analyse contextuelle (jeu d'activation et de personnalisation) ;
- Elle permet d'avoir une base de données unique qui gère différentes espaces et donc différentes applications, la base de données étant modifiées par les valeurs mises dans les tables et fichiers ; et - Elle permet d'avoir une base de données qui comporte différentes sémantiques grâce aux différents jeux d'activation et de personnalisa-tion associés à un espace de données ou à un ensemble d'espace de données.

Claims (18)

1- Système (SYS) de gestion d'applications (APP), caractérisé en ce qu'il comporte :

- des objets comprenant un ou plusieurs composants (Cp) prédéfinis et pré-assemblés, lesdits objets formant :
- un modèle générique d'organisation (MGO) composé d'entités organisationnelles logiques (ST) aptes à être liées entre elles ;
- un modèle générique de gestion (MGG) composé d'entités opérationnelles logiques (EO) aptes à être liées entre elles ;
- un modèle générique de pilotage (MGP) composé d'outils d'analyse de données (OA) ;
- un modèle générique (MGS) d'écrans et de cinématique (SCR) pour une interface utilisateur (UI) ;

- une base de données physique unique prédéfinie (DB1) comprenant les données correspondant auxdits objets ;

- un ensemble de tables et de fichiers (G_TAB) caractérisant les possibilités d'activations et de personnalisation des objets et caractérisant les traitements, les flux et les règles associés aux objets ;

- des outils d'identification (ID_T) des activations possibles d'objets liés à une activation initiale d'un objet ;

- des outils de gestion (MG_T) permettant la construction de réseaux logiques comprenant des espaces de données, et des liens pré-assemblés activables et personnalisables, chaque espace de données pouvant être composé de l'ensemble des objets, ledit réseau étant intégré dans la base de données physique unique (DB1) ;

- un objet connecteur (ML) mettant en uvre les modèles génériques, la base de données, l'ensemble de tables et de fichiers, lesdits outils d'identification et de gestion ;

- et en ce qu'il fournit des applications (APP) - qui sont des instanciations du système de gestion d'applications (SYS), une instanciation (INST) représentant un jeu d'activation et un jeu de personnalisation particuliers ;

- qui évoluent par versions successives grâce à des extensions desdites instanciations (INST) à partir du système de gestion d'applications (SYS), de sorte à représenter des progiciels ;

- dont les écrans (SCR) se construisent à chaque sollicitation de l'utilisateur via l'interface utilisateur (UI) ;

- et en ce que le système de gestion d'applications (SYS) ainsi que les applications résultantes (APP) fonctionnent en totalité sur un serveur (SRV) accessible via un navigateur internet (NAV_INT).

2- Système (SYS) de gestion d'applications (APP) selon la revendication 1, selon lequel une entité opérationnelle (EO) et/ ou une entité
organisationnelle (ST) et/ou un outil d'analyse (OA) est apte à être référencé de manière unique tout en étant utilisé dans plusieurs espaces de données (D).

3- Système (SYS) de gestion d'applications (APP) selon la revendication précédente, selon lequel le référencement est sélectif selon un jeu d'activation de critères.

4- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens de vérification de la cohérence en temps réel entre les objets à l'activation d'un objet.

5- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel une application (APP) peut utiliser plusieurs espaces de données (D) et inversement un espace de données (D) peut contenir plusieurs applications (APP).

6- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif d'import/export générique (Rt) de composants desdites entités (ST, EO, OA) définis par filtrage à des systèmes externes de gestion de données (ED) aptes à coopérer avec le système (SYS) de gestion d'applications de sorte à générer un flux générique qui est créé avec les jeux d'activation et de personnalisation.

7- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif de paramétrage libre (Tpf) de nouveaux composants (Cp1, Cp2) dans une entité (ST, EO).

8- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un espace commun de données (Dc), et en ce qu'un espace de données (D) est apte à hériter des composants des entités organisationnelle et opérationnelle (ST, EO) dudit espace commun de données (Dc).

9- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel l'espace commun de données hérite lui-même d'une instanciation initiale créée par défaut au lancement de l'objet connecteur (ML).

10-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif d'accréditations (Ta) comprenant :

- Une pluralité de premiers niveaux d'accréditations (N1) attribuables à
une unité intervenant (ITV) d'une entité organisationnelle (ST);

- Une pluralité de droits (R) attribuables à des actions (A) aptes à être effectuées par une unité intervenant (ITV);

- Une pluralité de deuxièmes niveaux d'accréditations (N2) attribuables à au moins un profil utilisateur (PR) auquel sont associés des unités intervenants (ITV) ;

- Lesdits premiers et deuxièmes niveaux d'accréditations (N1, N2) et ladite pluralité de droits (R) étant aptes à êtres combinés entre eux.

11-Système (SYS) de gestion d'applications (APP) selon la revendication précédente, selon lequel le dispositif d'accréditations (Ta) est apte à
attribuer un droit (R) sur des actions associées à un espace de données (D), une entité (ST, EO), un composant.

12-Système (SYS) de gestion d'applications (APP) selon les revendications précédentes 10 ou 11, selon lequel un espace de données (D) hérite des accréditations (N) et droits (R) attribués à
l'espace de données commun (Dc) en fonction d'un rôle (Ro) attribué
à une unité intervenant (ITV) d'une entité organisationnelle (ST).

13-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif d'accessibilité (Tacc) à des composants (Cp1, Cp2) d'une entité opérationnelle (EO) en fonction d'un état d'avancement (Ste) de l'entité opérationnelle (EO) et d'un rôle (Ro) attribué à une unité intervenant (ITV) d'une entité organisationnelle (ST), l'état d'avancement étant apte à s'appliquer à plusieurs espaces en respectant les différentes instanciations.

14-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif de duplication (Rdp) d'une entité opérationnelle d'origine (EO) apte à utiliser une unité de redéfinition (Form) des composants de l'entité opérationnelle dupliquée (EO) par rapport à l'entité
opérationnelle d'origine (EO).

15-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte une base de définition de règles (Tbdr) associée à des composants (Cp1, Cp2) d'une entité (ST, EO) de sorte à vérifier la cohérence en temps réel d'un écran.

16-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte une hiérarchie de niveaux associée à des entités opérationnelles (EO) dans laquelle :

- Une entité opérationnelle de premier niveau (EO_P) est apte à être rattachée directement à une entité organisationnelle (ST) ;

- Une entité opérationnelle de deuxième niveau (EO_D) est apte à être rattachée directement à une entité opérationnelle de premier niveau ou à une entité organisationnelle (ST) ; et - Une entité opérationnelle de troisième niveau (EO_T) est apte à être rattachée directement à une entité opérationnelle de deuxième niveau (EO_D) et/ou entité organisationnelle (ST).

17-Système (SYS) de gestion d'applications (APP) selon la revendication précédente, selon lequel une entité opérationnelle (EO) de niveau inférieure au premier niveau est en outre apte à être rattachée directement à une autre entité opérationnelle de même niveau, chaque niveau d'un espace pouvant être rattaché à chaque niveau d'un autre espace.

18-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte en outre un deuxième dispositif d'activation (Tact2) d'une procédure de traitement (WF) paramétrable en fonction d'un type (TY) d'entité
opérationnelle (EO).