FR 2964770 A1 20120316 FR 1057298 A 20100914 1 PROCEDE DE TRAITEMENT D'UNE DEMANDE FAITE PAR UN UTILISATEUR DANS UN MOTEUR DE FLUX DE TRAVAUX ET SYSTEME D'INFORMATION DANS LEQUEL UNE DEMANDE EST TRAITEE DOMAINE TECHNIQUE La présente invention concerne un procédé de traitement d'une demande faite par un utilisateur dans un moteur de flux de travaux d'un système d'information. La présente invention concerne également un système d'information comportant au moins un moteur de flux de travaux dans lequel un utilisateur peut faire une Io demande. Dans ce document, on appelle « moteur de flux de travaux » un moteur de « workflow ». On appelle « workflow » la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier (aussi appelé processus opérationnel ou bien 15 procédure d'entreprise). De façon plus pratique, le terme « workflow » décrit le circuit de validation, les tâches à accomplir entre les différents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche. Les moteurs de « workflow » permettent également la transmission automatique de documents entre les personnes ou les 20 demandes de droit. Le terme « workflow » peut également être désigné en français par les termes de « gestion de processus », « automatisation de processus », « processus métier », « processus d'entreprise », « suivi de travaux ». Dans la suite, l'anglicisme « workflow » sera remplacé par le terme « flux de 25 travaux ». ETAT DE LA TECHNIQUE ANTERIEUR De nombreuses entreprises utilisent des moteurs de flux de travaux, notamment pour que les personnes en lien avec l'entreprise puissent y effectuer leurs demandes. Par exemple, lorsqu'une personne de l'entreprise veut effectuer une demande de 2 congés, un droit d'accès à des documents ou à des applications du système d'information, elle peut faire sa demande dans un moteur de flux de travaux qui va envoyer sa demande aux personnes de l'entreprise qui sont habilitées à y répondre. Pour cela, chaque moteur de flux de travaux implémente généralement sa propre politique. En d'autres termes, chaque moteur de flux de travaux comporte son propre système d'autorisation qui va déterminer pour chaque demande faite par un utilisateur si l'utilisateur est autorisé à faire cette demande et qui peut répondre à sa demande. Toutefois, la multiplicité des moteurs de travaux rend difficile la visibilité des droits d'une personne donnée. En outre, lorsque des règles de séparation des pouvoirs doivent être appliquées, elles sont difficiles à mettre en oeuvre lorsque l'on passe d'un moteur de flux de travaux à un autre. Par ailleurs, la multiplicité des moteurs de flux de travaux rend la mise en place des politiques de l'entreprise lourde à mettre en oeuvre. EXPOSE DE L'INVENTION L'invention vise à remédier aux inconvénients de l'état de la technique en proposant un procédé de traitement d'une demande dans un moteur de flux de travaux qui soit plus simple à mettre en oeuvre et qui offre une meilleure visibilité globale des droits des utilisateurs. Pour ce faire, est proposé selon un premier aspect de l'invention, un procédé de traitement d'au moins une demande faite par un utilisateur dans un moteur de flux de travaux d'un système d'information comportant une pluralité de moteurs de flux de travaux, les moteurs de flux de travaux étant tous aptes à communiquer avec un même système d'autorisation centralisé, le procédé comportant au moins les étapes suivantes : une étape d'envoi par le moteur de flux de travaux d'une première requête au système d'autorisation centralisé dans laquelle le moteur de flux de travaux demande au système d'autorisation centralisé si l'utilisateur est autorisé à faire cette demande, 3 - une étape d'envoi par le système d'autorisation centralisé d'une première réponse au moteur de flux de travaux dans laquelle le système d'autorisation centralisé indique si l'utilisateur est autorisé ou non à faire cette demande. Ainsi, le procédé permet de réaliser une indirection depuis chaque moteur de flux de travaux vers un système d'autorisation centralisé, qui est externe aux moteurs de flux de travaux et indépendant de ces moteurs de flux de travaux. Ainsi chaque moteur de flux de travaux n'implémente plus sa propre politique, mais chaque moteur de flux de travaux réalise une indirection vers le système d'autorisation centralisé qui implémente une politique commune à tous les moteurs de flux de travaux du système d'information. Le procédé peut également présenter une ou plusieurs des caractéristiques ci-dessous, considérées individuellement ou selon toutes les combinaisons techniquement possibles. Selon un mode de réalisation non limitatif, lorsque la première réponse indique que l'utilisateur est autorisé à faire cette demande, le procédé comporte en outre les étapes suivantes : - une étape d'envoi par le moteur de flux de travaux d'une deuxième requête au système d'autorisation centralisé dans laquelle le moteur de flux de travaux demande au système d'autorisation centralisé quelles sont les personnes autorisées à répondre à la demande de l'utilisateur ; - une étape d'envoi par le système d'autorisation centralisé d'une deuxième réponse au moteur de flux de travaux, la deuxième réponse contenant une liste de personnes autorisées à répondre à la demande de l'utilisateur ; - une étape d'envoi par le moteur de flux de travaux de la demande de l'utilisateur à des moyens de consultation consultables par les personnes de la liste de personnes autorisées à répondre à la demande de l'utilisateur. Ainsi, c'est le système d'autorisation centralisé qui élabore de manière centralisée les réponses que lui posent les moteurs de flux de travaux. Pour cela, le système d'autorisation centralisé communique avec un système de gestion de politique pour décider si lui-même autorise ou refuse les demandes des utilisateurs en fonction des 4 règles contenues dans la politique. La décision et/ou ces règles peuvent s'appuyer, par exemple, sur des informations contenues dans un annuaire d'identité. Selon un mode de réalisation non limitatif, lorsque le moteur de flux de travaux a reçu au moins une réponse utilisateur d'une des personnes de la liste de personne autorisées à répondre à la demande de l'utilisateur, la réponse utilisateur comprenant une autorisation de la demande ou une interdiction de la demande, le procédé comporte en outre l'étape suivante : une étape d'envoi par le moteur de flux de travaux de la réponse utilisateur à une interface utilisateur consultable par l'utilisateur. Ainsi, l'utilisateur sait si sa demande a été acceptée ou non. L'interface utilisateur peut par exemple envoyer un email à l'utilisateur pour l'avertir de la réponse utilisateur. L'interface utilisateur peut également être une interface du moteur de flux de travaux à laquelle l'utilisateur peut accéder. Selon un mode de réalisation non limitatif, la demande faite par l'utilisateur dans le 15 moteur de flux de travaux est une demande de rôle ou de permission. On appelle « rôle » un regroupement de permissions ou d'autre rôles (qui sont désignés comme rôles inclus), selon l'usage dans les politiques d'accès conformes au modèle « RBAC » (Role Based Access Control). On appelle « permission » un droit ou une habilitation d'effectuer une action sur un 20 élément du système d'information. Par exemple : lire le fichier COMPTA.XLS, se connecter au site Intranet de l'entreprise, ... Selon un mode de réalisation non limitatif, le système d'autorisation centralisé détermine si l'utilisateur est autorisé ou non à faire sa demande en recherchant dans un système de gestion de politique si l'utilisateur possède la permission de faire la 25 demande. Ainsi, préalablement à toute demande, des permissions et des rôles sont créés dans le système de gestion de politique et par la suite, lorsqu'une demande est effectuée, le système d'autorisation centralisé recherche, si l'utilisateur qui a fait la demande avait la permission de faire cette demande. II est ainsi plus facile d'avoir une visibilité globale sur les demandes qu'ont le droit d'effectuer les utilisateurs. En outre, il est plus facile de gérer de façon globale les incompatibilités entre les demandes. Selon un mode de réalisation non limitatif, la première requête comporte en outre des paramètres de contexte limitant la demande. 5 Ainsi, la demande peut être limitée ou précisée grâce à ces paramètres de contexte. Selon un mode de réalisation non limitatif, le système d'autorisation centralisé détermine la liste de personnes autorisées à répondre à la demande de l'utilisateur en recherchant dans un système de gestion de politique quelles sont les personnes qui possèdent la permission de valider la demande. Selon un mode de réalisation non limitatif, la deuxième requête comporte en outre des paramètres de contexte limitant la demande. Un deuxième aspect de l'invention concerne un système d'information comportant : - une pluralité de moteur de flux de travaux, - un système d'autorisation centralisé, les moteurs de flux de travaux étant 15 aptes à communiquer avec ce système d'autorisation centralisé, au moins un des moteurs de flux de travaux étant apte à : - recevoir une demande d'un utilisateur, - envoyer une première requête au système d'autorisation centralisé dans laquelle le moteur de flux de travaux demande si l'utilisateur est autorisé à faire cette 20 demande, le système d'autorisation centralisé étant apte à envoyer une première réponse audit au moins un moteur de flux de travaux dans laquelle le système d'autorisation indique si l'utilisateur est autorisé ou non à faire cette demande. Dans ce système d'information, chaque moteur de flux de travaux n'utilise donc plus 25 son propre système d'autorisation, mais tous les moteurs de flux de travaux utilisent le même système d'autorisation centralisé, ce qui permet de simplifier la gestion des 6 droits des utilisateurs, et ce qui permet d'avoir une gestion des droits cohérente d'un moteur de flux de travaux à l'autre. Le système d'information peut également présenter une ou plusieurs des caractéristiques ci-dessous, considérées individuellement ou selon toutes les combinaisons techniquement possibles. Selon un mode de réalisation non limitatif, ledit au moins un moteur de flux de travaux est en outre apte à : - envoyer une deuxième requête au système d'autorisation centralisé dans laquelle ledit au moins un moteur de flux de travaux demande au système d'autorisation centralisé quelles sont les personnes autorisées à répondre à la demande de l'utilisateur, le système d'autorisation centralisé étant apte à envoyer une deuxième réponse audit au moins un moteur de flux de travaux, la deuxième réponse contenant une liste de personnes autorisées à répondre à la demande de l'utilisateur, ledit au moins un moteur de flux de travaux étant apte à envoyer la demande de l'utilisateur à des moyens de consultation consultables par les personnes de la liste de personnes autorisées à répondre à la demande de l'utilisateur. Ainsi, le système d'autorisation centralisé identifie les personnes qui peuvent valider ou refuser la demande de l'utilisateur. Pour cela, le système d'autorisation centralisé communique avec un système de gestion de politique centralisé qui est apte à traiter toutes les demandes de droits des utilisateurs. Ainsi, quel que soit le moteur de flux de travaux qui reçoit une demande d'un utilisateur, le même système de gestion de politique identifie les personnes qui peuvent valider ou refuser la demande. Selon un mode de réalisation non limitatif, ledit au moins un moteur de flux de travaux est apte à recevoir une réponse utilisateur, la réponse utilisateur comprenant une autorisation de la demande ou une interdiction de la demande. Ainsi, une fois que le moteur de flux de travaux a envoyé la demande de l'utilisateur à des moyens de consultation consultables par les personnes qui peuvent valider ou 7 refuser la demande, ces personnes peuvent envoyer leur réponse, par exemple par email, au moteur de travaux. Selon un mode de réalisation non limitatif, ledit au moins un moteur de flux de travaux est en outre apte à envoyer la réponse utilisateur à une interface consultable par l'utilisateur. Ainsi, l'utilisateur est informé de la réponse utilisateur qui a été faite par au moins une des personnes de la liste de personnes autorisées à répondre à la demande de l'utilisateur. Selon un mode de réalisation non limitatif, la demande faite par l'utilisateur dans le 10 moteur de flux de travaux est une demande de rôle ou de permission. Selon un mode de réalisation non limitatif, le système d'autorisation centralisé est apte à communiquer avec un système de gestion de politiques centralisé. BREVES DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la 15 description détaillée qui suit, en référence aux figures annexées, qui illustrent : - La figure 1, une représentation schématique d'un système d'information selon un mode de réalisation de l'invention ; - La figure 2, une représentation schématique des étapes d'un procédé selon un mode de réalisation de l'invention. 20 Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de références identiques sur l'ensemble des figures. DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION La figure 1 représente un système d'information 1 selon un mode de réalisation de l'invention. Ce système d'information 1 comporte plusieurs moteurs de flux de 25 travaux, par exemple trois moteurs de flux de travaux 10, 11, 12. Le système d'information comporte également un système d'autorisation centralisé 13 et un système de gestion de politique 14. Le système de gestion de politique 14 permet de stocker et d'administrer la politique. Le système d'autorisation centralisé 8 13, face à une requête, consulte la politique, et prend une décision, en fonction des règles de la politique. Chaque moteur de flux de travaux 10, 11, 12 comporte une interface d'entrée 101, 111, 121 qui permet à un utilisateur de faire une demande D, notamment une 5 demande de droit. Chaque moteur de flux de travaux 10, 11, 12 comporte des moyens de transmission 102, 112, 122 permettant à chaque moteur de flux de travaux 10, 11, 12 de faire des requêtes au système d'autorisation 13. Le système d'autorisation 13 comporte des moyens de réception 131 aptes à 10 recevoir les requêtes des moteurs de flux de travaux 10, 11, 12. Le système d'autorisation 13 comporte également des moyens de traitement 132 aptes à traiter les requêtes issues des différents moteurs de flux de travaux 10, 11, 12. Pour cela, le système d'autorisation 13 peut s'appuyer sur un annuaire d'identité 15. On notera que ce mode de réalisation n'est pas limitatif et que selon un autre 15 mode de réalisation, le système de gestion de politique peut également s'appuyer sur l'annuaire d'identité 15. Le système d'autorisation 13 comporte également des moyens d'envoi aptes à envoyer aux moteurs de flux de travaux 10, 11, 12 des réponses aux requêtes que les moteurs de flux de travaux ont fait. 20 Le système d'autorisation 13 comporte des moyens de communication 133 lui permettant de communiquer avec le système de gestion de politique 14. Chaque moteur de flux de travaux 10, 11, 12 comporte également des moyens de réception 103, 113, 123 aptes à recevoir les réponses du système d'autorisation centralisé 13. 25 Chaque moteur de flux de travaux 10, 11, 12 comporte également des moyens de consultation 104, 114, 124 consultables, ainsi qu'une interface utilisateur 105, 115, 125 consultable par l'utilisateur. 9 Chaque moteur de flux de travaux 10, 11, 12 peut également comporter une interface d'entrée 107, 117, 127 permettant d'entrer des informations dans chaque moteur de flux de travaux 10, 11, 12. Chaque moteur de flux de travaux 10, 11, 12 comporte également des moyens d'écriture 106, 116, 126 permettant l'écriture de rôles et permission dans le système de gestion de politique 14. Un procédé de traitement d'une demande d'un utilisateur mis en oeuvre dans le système d'information de la figure 1 va maintenant être décrit en référence à la figure 2. Préalablement à toute demande, au niveau du système de gestion de la politique, un administrateur de la politique 141 va créer des permissions, qui peuvent être associées à des paramètres de contexte. Par exemple, l'administrateur de politique 141 va créer une première permission « demander des congés » qu'il va associer si besoin à des paramètres de contexte. Un premier paramètre de contexte associé à cette permission peut par exemple être « la date et le type de congés » et un deuxième paramètre de contexte peut par exemple être « l'utilisateur concerné par la demande ». L'administrateur de politique 141 pourra également créer une deuxième permission qui sera « valider des congés ». Cette permission pourra également être associée à des paramètres de contexte comme par exemple « date et type de congés » et « utilisateurs concernés par la demande ». L'administrateur de politique 141 va ensuite assigner ces permissions aux personnes concernées. Par exemple, dans le cas d'une demande de congés, l'administrateur de politique peut assigner le droit de demander des congés à tous les employés en CDD et CDI. De même, l'administrateur de politique peut assigner la permission « valider des congés » à tous les managers, avec le paramètre de contexte « chaque manager ne peut valider les congés que des personnes de son équipe ». Pour savoir quelles sont les personnes dans chaque équipe de chaque manager, l'administrateur de politique 141 peut s'appuyer sur l'annuaire d'identité 14. Initialement un utilisateur U effectue une demande D dans un des moteurs de flux de travaux, par exemple dans le moteur de flux de travaux 10. Dans cette demande D, l'utilisateur U peut par exemple demander des droits pour une personne P de 10 l'entreprise. La personne P pour laquelle l'utilisateur demande des droits peut être l'utilisateur lui-même, ou bien une autre personne. Les droits que l'utilisateur demande pour une personne P peuvent être par exemple: - des rôles comme par exemple « Administrateur des serveurs Web », « Gestionnaire des factures des clients France », ... De manière générale, un rôle peut être une fonction ou une mission pour l'utilisateur. - des permissions comme par exemple le droit d'accéder à une ressource, le droit de modifier une ressource, le droit de prendre des congés à telle période.... Afin de clarifier la description de l'invention, nous supposons dans le cas présent que l'utilisateur effectue une demande de congés pour lui-même. L'utilisateur U, se connecte à l'interface utilisateur du moteur de flux de travaux 10 et démarre un nouveau processus de "demande de congés". Pour cela, l'utilisateur U indique au moteur de flux de travaux qu'il effectue une demande D de congés, pour lui-même. Lors d'une première étape 201, le moteur de flux de travaux 10 envoie une première requête R1 au système d'autorisation 13 dans laquelle le moteur de flux de travaux 10 demande si l'utilisateur U est autorisé à faire cette demande D. Pour cela, le moteur de flux de travaux 10 envoie la première requête R1 à l'aide des moyens de transmission 102 et le système d'autorisation 13 reçoit la première requête R1 à l'aide des moyens de réception 131. Lors d'une deuxième étape 202, le système d'autorisation 13 détermine ensuite, à l'aide des moyens de calcul 132, si l'utilisateur U a le droit de faire la demande D pour la personne P, en l'occurrence lui-même. Pour cela, les moyens de calcul 132 s'appuient sur les permissions créées au préalable par l'administrateur de politique 141 dans le système de gestion de politique. Le système d'autorisation 13 doit donc répondre à la première requête R1 suivante posée par le moteur de flux de travaux 10 : 2964770 n - l'utilisateur U possède-t-il la permission "DEMANDE DE CONGES" avec le contexte utilisateurs = « pour lui-même ». Par exemple, si l'utilisateur U est un intérimaire et que sa demande D est une demande de congés pour lui-même, il se peut qu'il ne soit pas autorisé à faire cette 5 demande. De même si l'utilisateur U est une personne d'une entreprise et qu'il demande de supprimer des congés pour une autre personne de l'entreprise, il se peut qu'il ne soit pas autorisé à faire cette demande. Lors d'une troisième étape 203, le système d'autorisation 13 centralisé envoie une 10 première réponse B1 au moteur de flux de travaux 10. La première réponse B1 indique si l'utilisateur U est autorisé ou non à faire la demande D. Le procédé peut ensuite comporter une quatrième étape 204 au cours de laquelle le moteur de flux de travaux 10 envoie la réponse B1 à l'utilisateur U1 grâce à l'interface utilisateur 105. Au cours de cette étape 204, le moteur de flux de travaux 15 10 peut également demander à l'utilisateur U de limiter sa demande en fonction de paramètres de contexte renvoyés à l'étape précédente. Par exemple, dans le cas d'une demande de congés, l'utilisateur U peut avoir l'autorisation de demander uniquement des congés pour l'année en cours. Dans ce cas, le moteur de flux de travaux peut lui demander de limiter sa demande de congés à l'année en cours. 20 Le procédé peut également comporter une cinquième étape 205 au cours de laquelle le moteur de flux de travaux 10 enregistre la réponse B1 et éventuellement la demande D de l'utilisateur. Par exemple, dans le cas d'une demande de congés, le moteur de flux de travaux peut enregistrer que l'utilisateur U demande pour lui-même des congés pour la période du 3 au 10 septembre 2010. 25 Si la réponse B1 indique que l'utilisateur U n'avait pas le droit de faire la demande D, le procédé peut s'arrêter à ce stade. Si la réponse B1 indique que l'utilisateur U est autorisé à faire la demande D, le procédé peut comporter une sixième étape 206 au cours de laquelle le moteur de flux de travaux 10 envoie une deuxième requête R2 au système d'autorisation 13 dans laquelle le moteur de flux de travaux 10 demande au système d'autorisation 13 12 la liste des personnes qui peuvent valider la demande D d'attribution de rôle ou de permission. Pour cela, le moteur de flux de travaux 10 envoie la deuxième requête R2 à l'aide des moyens de transmission 102 et le système d'autorisation 13 reçoit la deuxième requête R2 à l'aide des moyens de réception 131. Par exemple, dans le cas d'une demande de congés payés de l'utilisateur U pour lui-même pour la période du 3 au 10 septembre, le moteur de workflow 10 demande au système d'autorisation 13 dans la deuxième requête R2 quels sont les titulaires de la permission "VALIDER LES CONGES", avec les paramètres de contexte Congés = "RTT du 3 au 10 Sept 2010" et Utilisateur = "U".Lors d'une septième étape 207, le système d'autorisation 13 détermine ensuite, à l'aide des moyens de calcul 132, la liste des personnes qui peuvent valider ou refuser la demande D de l'utilisateur. Pour cela, les moyens de calcul 132 s'appuient sur les permissions qui ont été créées au préalable dans le système de gestion de politique 14 par l'administrateur de politique 141. Le procédé peut ensuite comporter une huitième étape 208 au cours de laquelle le système d'autorisation 13 envoie une deuxième réponse B2 au moteur de flux de travaux 10, la deuxième réponse B2 contenant la liste des personnes qui peuvent valider ou refuser la demande de l'utilisateur. Par exemple, dans le cas d'une demande de congés de l'utilisateur U pour lui-même du 3 au 10 septembre, le système d'autorisation 13 peut renvoyer dans sa réponse B2 au moteur de flux de travaux 10: les personnes autorisées à valider cette demande D sont l'utilisateur J, le MANAGER de U, et S, qui est à la directrice des ressources humaines. On pourrait également envisager que si, la demande de congés concernait non pas des congés payés, mais des RTT, la deuxième requête B2 aurait indiqué seulement J. Le procédé peut ensuite comporter une neuvième étape 209 au cours de laquelle le moteur de flux de travaux 10 envoie la demande de l'utilisateur aux personnes de la liste de personne qui figurent dans la réponse B2 grâce à des moyens de 13 consultation 104 consultables par ces personnes. Ces moyens de consultation 104 peuvent par exemple être des emails envoyés aux personnes de la liste de personnes contenue dans B2. Une des personnes la liste de personnes peut alors se connecter au moteur de flux de travaux 10 via l'interface d'entrée 107 afin de s'attribuer la tâche et d'accepter ou de refuser la demande D de l'utilisateur. L'acceptation ou le refus de la demande D de l'utilisateur est appelé « réponse utilisateur ». Le procédé peut ensuite comporter une dixième étape 210 au cours de laquelle le moteur de flux de travaux envoie la réponse utilisateur à l'utilisateur U1 grâce à l'interface utilisateur 105. Le procédé peut également comporter une onzième étape 211 au cours de laquelle le moteur de flux de travaux 10 enregistre la deuxième réponse B2 dans le système de gestion de politique 14. Cette onzième étape 211 a notamment lieu lorsque l'utilisateur demandait un rôle ou une permission pour une personne P. Dans ce cas, lorsque le rôle ou la permission a été accepté, le moteur de flux de travaux enregistre ce rôle ou cette permission dans le système de gestion de politiques. Ainsi, par exemple, lorsque l'utilisateur U demande le droit d'avoir accès à une imprimante couleur et que la réponse utilisateur indique qu'il est autorisé à avoir accès à cette imprimante couleur, le moteur de flux de travaux enregistre cette permission dans le système de gestion de politique, de sorte que, par la suite, à chaque fois que l'utilisateur veut imprimer en couleur, il a accès à l'imprimante couleur. REVENDICATIONS1. Procédé de traitement d'au moins une demande (D) faite par un utilisateur (U) dans un moteur de flux de travaux (10) d'un système d'information (1) comprenant une pluralité de moteurs de flux de travaux (10, 11, 12), les moteurs de flux de travaux (10, 11, 12) étant tous aptes à communiquer avec un même système d'autorisation centralisé (13), le procédé comportant au moins les étapes suivantes : - une étape (201) d'envoi par le moteur de flux de travaux (10) d'une première requête (R1) au système d'autorisation centralisé (13) dans laquelle le moteur de flux de travaux (10) demande au système d'autorisation centralisé (13) si l'utilisateur (U) est autorisé à faire cette demande (D), - une étape (203) d'envoi par le système d'autorisation centralisé (13) d'une première réponse (B1) au moteur de flux de travaux (10) dans laquelle le système d'autorisation centralisé (13) indique si l'utilisateur (U) est autorisé ou non à faire cette demande (D). 2. Procédé de traitement selon la revendication précédente, caractérisé en ce que, lorsque la première réponse (B1) indique que l'utilisateur (U) est autorisé à faire cette demande (D), le procédé comporte en outre les étapes suivantes - une étape d'envoi (206) par le moteur de flux de travaux (10) d'une deuxième requête (R2) au système d'autorisation centralisé (13) dans laquelle le moteur de flux de travaux (10) demande au système d'autorisation centralisé (13) quelles sont les personnes autorisées à répondre à la demande (D) de l'utilisateur (U); - une étape d'envoi (208) par le système d'autorisation centralisé (13) d'une deuxième réponse (B2) au moteur de flux de travaux (10), la deuxième réponse (B2) contenant une liste de personnes autorisées à répondre à la demande (D) de l'utilisateur (U); - une étape (209) d'envoi par moteur de flux de travaux (10) de la demande (D) de l'utilisateur (U) à des moyens de consultation (107) 15 consultables par les personnes de la liste de personnes autorisées à répondre à la demande (D) de l'utilisateur (U). 3. Procédé de traitement selon la revendication précédente, caractérisé en ce que, lorsque le moteur de flux de travaux (10) a reçu au moins une réponse utilisateur (U) d'une des personnes de la liste de personne autorisées à répondre à la demande (D) de l'utilisateur (U), la réponse utilisateur comprenant une autorisation de la demande ou une interdiction de la demande, le procédé comporte en outre l'étape suivante : - une étape (210) d'envoi par le moteur de flux de travaux (10) de la réponse utilisateur à une interface utilisateur (105) consultable par l'utilisateur (U). 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la demande (D) faite par l'utilisateur (U) dans le moteur de flux de travaux (10) est une demande de rôle ou de permission. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le système d'autorisation centralisé (13) détermine si l'utilisateur est autorisé ou non à faire sa demande en recherchant dans un système de gestion de politique (14) si l'utilisateur (U) possède la permission de faire la demande (D). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la première requête (R1) comporte en outre des paramètres de contexte limitant la demande (D). 7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que le système d'autorisation centralisé (13) détermine la liste de personnes autorisées à répondre à la demande (D) de l'utilisateur (U) en recherchant dans un système de gestion de politique (14) quelles sont les personnes qui possèdent la permission de valider la demande (D). 16 8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que la deuxième requête (R2) comporte en outre des paramètres de contexte limitant la demande (D). 9. Système d'information (1) comportant : - une pluralité de moteurs de flux de travaux (10, 11, 12), - un système d'autorisation centralisé (13), les moteurs de flux de travaux (10, 11, 12) étant aptes à communiquer avec ce système d'autorisation centralisé (13), au moins un des moteurs de flux de travaux (10) étant apte à : - recevoir une demande (D) d'un utilisateur (U), - envoyer une première requête (R1) au système d'autorisation centralisé (13) dans laquelle le moteur de flux de travaux (10) demande si l'utilisateur (U) est autorisé à faire cette demande (D), le système d'autorisation centralisé (13) étant apte à envoyer une première réponse (B1) audit au moins un moteur de flux de travaux (10) dans laquelle le système d'autorisation centralisé (13) indique si l'utilisateur (U) est autorisé ou non à faire cette demande (D). 10. Système d'information (1) selon la revendication précédente, caractérisé en ce que ledit au moins un moteur de flux de travaux (10) est en outre apte à : - envoyer une deuxième requête (R2) au système d'autorisation centralisé (13) dans laquelle ledit au moins un moteur de flux de travaux (10) demande au système d'autorisation centralisé (13) quelles sont les personnes autorisées à répondre à la demande (D) de l'utilisateur (U), le système d'autorisation centralisé (13) étant apte à envoyer une deuxième réponse (B2) audit au moins un moteur de flux de travaux (10), la deuxième réponse (B2) contenant une liste de personnes autorisées à répondre à la demande (D) de l'utilisateur (U), ledit au moins un moteur de flux de travaux (10) étant apte à envoyer la demande (D) de l'utilisateur (U) à des moyens de consultation (104) consultables par les personnes de la liste de personnes autorisées à répondre à la demande (D) de l'utilisateur (U). 11. Système d'information (1) selon la revendication précédente, caractérisé en ce que ledit au moins un moteur de flux de travaux (10) est apte à recevoir une réponse utilisateur, la réponse utilisateur comprenant une autorisation de la demande (D) ou une interdiction de la demande (D). 12. Système d'information (1) selon la revendication précédente, caractérisé en ce que ledit au moins un moteur de flux de travaux (10) est en outre apte à envoyer la réponse utilisateur à une interface utilisateur (105) consultable par l'utilisateur (U). 13. Système d'information selon l'une quelconque des revendications 9 à 12, caractérisé en ce que la demande (D) faite par l'utilisateur dans ledit au moins un moteur de flux de travaux (10) est une demande de rôle ou de permission. 14. Système d'information selon l'une quelconque des revendications 9 à 13, caractérisé en ce que le système d'autorisation centralisé (13) est apte à communiquer avec un système de gestion de politiques centralisé (14).15