FR 2948788 A1 20110204 FR 0955352 A 20090730 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. 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. 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 au moins un espace de données apte à être associé à une application, ledit espace de données comportant : - Au moins une entité organisationnelle apte à être référencée dans au moins un autre espace de données et comprenant une pluralité de premiers composants ; - Au moins une entité opérationnelle comprenant une pluralité de deuxièmes composants ; les premiers et deuxièmes composants é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. Comme on va le voir en détail par la suite, l'activation/désactivation de composants au sein d'un même espace de données permet de choisir les composants qui seront utilisés dans une entité pour une application don- née, et ce sans codage. Par ailleurs le référencement d'une entité organisationnelle dans un autre espace de données permet l'utilisation transverse d'une entité organisationnelle dans plusieurs espaces de données. 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 est apte à être référencée dans au moins un autre espace de données. Cela permet une utilisation transverse d'une entité opérationnelle dans plusieurs espaces de données. - Une pluralité d'espaces de données est apte à être associé à une application. Cela permet de simplifier la gestion d'une application, car on peut la découper de façon logique en autant d'espaces que l'on désire. - Le système de gestion d'applications comporte un dispositif de référencement d'une entité dans un espace de données, ledit dispositif comprenant au moins une première référence à ladite entité et une deuxième référence audit espace de données associé. Cela permet le paramétrage et la propagation des entités dans les espaces de données. - Le système de gestion d'applications comporte un premier dispositif d'activation des composants d'une entité. Le dispositif d'activation permet de rendre visible un composant d'une entité et donc de le rendre accessible pour une application donnée. - Le système de gestion d'applications comporte un dispositif de propagation automatique d'une définition d'un composant d'une entité dans une autre entité dans lequel il se trouve également. Cela permet de maintenir la cohérence des données dans le système. - Le système de gestion d'applications comporte un dispositif de transmission 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. 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 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. - Le système de gestion d'applications comporte un dispositif de redéfinition des composants des entités organisationnelle et opérationnelle d'un espace de données par rapport aux composants hérités d'un espace commun de données. Cela permet de spécifier les composants et champs des entités d'un espace de données si nécessaire par rapport à l'espace commun. - 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 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. 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. - 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é. 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 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. 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. - 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 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. 2 est un schéma simplifié d'un groupe de tables utilisées par le système de gestion d'applications de la Fig. 1 selon un mode de réalisation non limitatif ; - la Fig. 3 est un schéma simplifié d'une pluralité d'espaces de don-nées, d'une entité organisationnelle et de plusieurs entités opérationnelles, 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. 1 ; - la Fig. 4 est un schéma détaillé d'un premier espace de données de la Fig. 3, selon un exemple non limitatif ; - la Fig. 5 est un schéma détaillé d'un deuxième espace de données de la Fig. 3, selon un exemple non limitatif ; - la Fig. 6 est un schéma simplifié d'un groupe de tables utilisées par le système de gestion d'applications de la Fig. 1 dans le cadre de l'application prise comme exemple non limitatif de la Fig. 3 ; et - la Fig. 7 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. 1. 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 et 2. 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 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 est apte à être référencée dans au moins un autre espace de données D. 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. 1, 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 physique de données 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 sous format texte, 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 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, 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 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. 2: - 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. 8 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 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 - 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. 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 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. 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. Dans la suite de la description, on prend l'exemple non limitatif d'une application APP1 illustrée sur les Fig. 3 à 6. Sur la Fig. 3 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. Par ailleurs, tel qu'illustré sur la Fig. 4, 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 - deux entités �Demande � EO_D11, EO_D12 qui sont des sous-demandes ; - une entité � Tâche � EO_Tl ; - 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. 5 : 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. 15 • 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 20 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) 25 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é 30 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 35 gérer des données libres • Unité intervenant : 1) Titre : champ10 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 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 �) 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 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) 19) DemandeMère - liste 20) Type - liste • Entité � Tâche � 1) Type tâche - liste 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 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. 3: - 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. 4 : - 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 D12, EO T31, EO_T32, EO T3, comprenant chacune une pluralité de deuxièmes composants Cp2 ; les premiers et deuxièmes composants CO, 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 ou non à une ou plusieurs entités organisationnelles ST. • Le deuxième espace de données D2, tel qu'illustré sur la Fig. 5 : - 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. 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 ; et - Activer une procédure de traitement paramétrable en fonction d'un type d'entité opérationnelle. Les opérations sont décrites ci-dessous. Définition d'un espace de données commun Dc 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 transverses35 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. 6 - 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 espace de données D (qui. hérite de l'espace commun de 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 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. 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 : - 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. 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. 6 : - un premier sous-répertoire sous le répertoire LIB, ayant pour dénomination le nom de codification CODd_D2 du nouvel espace créé 20 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. 25 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 d'application SYS comporte un dispositif de recherche (non illustré sur les 30 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 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 ; - 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érencement d'une entité organisationnelle ST dans un espace de 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 Tlnk35 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 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 D1, on aura ainsi dans la table d'espace Tlnk, une ligne comprenant une référence à l'entité organisationnelle ITV1 de l'espace D1, associées à la ligne codification du champ de l'espace D1. 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_D1 CODd_D1 LIB_D1 ITV1 CODd_D2 LIB_D2 ST_D2 CODd_D2 LIB_D2 ITV225 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 espace 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. 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 COD_D2 LIB_D2 EO_T6 Redéfinition. des..çomposants d'un.. espace.. de données..D..par rapport. aux ~omposants hérités ' p . e.onnés Oç 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 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. 6 pour l'espace D2 : - Cinq tables de libellés TABI pour définir respectivement les libellés des 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 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. 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), 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çtiyation/désaçtivation.des.çomposants d'une.entité, 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 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 CO, 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 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 D1, le projet EO_P1 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 D1 : 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 1 8) Planning - onglet 1 9) Criticité - liste dynamique 1 10) Domaine technique û liste 1 dynamique 11) Délai û champ 1 12) Service û liste 1 13) Client - liste 1 14) Responsable û liste 1 15) Affectation unité intervenant 1 16) Affectation entité 1 organisationnelle 17) plan de charge 1 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 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é. Paramétrage.libre.e nouveaux.çomposants ÿp1, ÿp2 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 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 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. Défini.une..base.de définition..e.règles..assoçiées.à.des omposants Qp1., ç.p.dne entité.S.EQ 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. 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 à chaque fois qu'un composant CO, 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 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 remplissant tout simplement la table Tbdr. 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 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. Les niveaux et droits sont définis ci-dessous. Définition des premiers. niveaux d'accréditations N1 Dans un mode de réalisation non limitatif, cinq premiers niveaux d'accréditations N1 sont définis. - N1 P = Personnel - N1 S = Service - N1 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 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 N1 S 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éfinition des deuxièmes niveaux d'accréditations N2 .......................................................................... ......................... 10 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 15 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. 20 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 25 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 N1, à savoir : 30 - N2P = Personnel - N2S = Service - N2SF = Service fils - N2G = Général 35 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'oeuvre - la maîtrise d'ouvrage - des profils métiers différents etc. • Définition des droits R ......................................... Dans un mode de réalisation non limitatif, cinq droits R attribuables sur des actions A (lecture, écriture, création, suppression, administration) sont 10 définis et qui sont applicables à chaque niveau d'accréditations N1, 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 15 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 20 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. 25 - 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). 30 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. 35 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 �. 325 Exemple 2 : une unité intervenant ayant les droits de lecture au niveau N1S 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. 20 Ainsi, pour la définition des premiers N1 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 pour : 25 - 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é intervenant. 30 - Choisir les accréditations N1, 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 de données D, une entité ST, EO, un composant Cpt , Cp2. 35 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 N1 les droits associés RL, RE, RC, RS, RA, chaque niveau d'accréditations N1 é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. 7, dans une représentation logique. Dans un mode de réalisation non limitatif, le dispositif d'accréditations Ta est une table. Ainsi, grâce à cette table d'accréditations Ta à plusieurs dimensions, les premiers et deuxième niveaux d'accréditations N1, 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 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. On notera que les accréditations N1, N2 décrites ci-dessus sont définies par espace de données D. Dans ce cas, les accréditations N1, 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 N1, 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 N1, 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). Définir des. droits d'accessibilité attribués à des composants d'une entité � Demande � en fonction d'un état d'avancement Ste et d'un rôle Ro d'une 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'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 �. 30 - 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 35 destinataire (service qui réalise la Demande) de l'entité � Demande � ; ou - le service de l'unité intervenant connectée est le service 25 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 Code VAL écrans Cpt, Cp2 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 15 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é SteO Etat Initial Stel 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ôlel [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 (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 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 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..propgain..utomatigue.DlO d'une.éfiniion..'un.omposant d'une entité dans une autre25 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 CO, 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 Cp- 1, Cp2, des pointeurs sur une entité origine ST, EO, cette dernière comprenant une définition des composants Cp- 1, 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..e traitement... paramétrable..9.n..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. • 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. Dupliguer une entité.opérationnell 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 CO, 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 CO, 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 CO, 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 des composants 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 de transmission Rt de composants desdites entités ST, EO 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. 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 de transmission 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 25 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 30 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, 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 également 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écurrent). Ainsi, dans un exemple non limitatif, pour une application relative à 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 projet, par exemple lorsqu'il y a un développement d'outils informatiques à effectuer ; 5 - la production dont les unités intervenants travaillent en mode événementiel, par exemple lorsqu'il y a un problème de flux de don-né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 informatiques 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. REVENDICATIONS1- Système (SYS) de gestion d'applications (APP), caractérisé en ce qu'il 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 (Cp1) ; - Au moins une entité opérationnelle (EO) comprenant une pluralité de deuxièmes composants (Cp2) ; les premiers et deuxièmes composants (Cp1, 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. 2- Système (SYS) de gestion d'applications (APP) selon la revendication 1, selon lequel une entité opérationnelle (EO) est apte à être référencée dans au moins un autre espace de données (D). 3- Système (SYS) de gestion d'applications (APP) selon la revendication 1 ou la revendication 2, selon lequel une pluralité d'espaces de données (D) sont aptes à êtres associés à une application (APP). 4- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il 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é. 5- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un premier dispositif d'activation (Tact1) des composants d'une entité (ST, EO). 6- Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif de propagation automatique (DICO) d'une définition d'un composant (Cp1, Cp2) d'une entité (ST, EO) dans une autre entité(ST, EO) dans lequel il se trouve également. 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 transmission (Rt) de composants desdites entités (ST, EO) 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. 8- 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). 9- 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). 10-Système (SYS) de gestion d'applications (APP) selon l'une quelconque des revendications précédentes, selon lequel il comporte un dispositif de redéfinition (Tdef) des composants (Cp1, Cp2) des entités organisationnelle et opérationnelle d'un espace de données (D) par rapport aux composants hérités d'un espace commun de données (Dc). 11-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 (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 (N1, N2) et ladite pluralité de droits (R) étant aptes à êtres combinés entre eux. 12-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. 13-Système (SYS) de gestion d'applications (APP) selon les revendications précédentes 9 et 11, ou 9 et 12, 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). 14-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). 15-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). 16-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). 17-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). 18-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. 19-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).