FR 2963461 A1 20120203 FR 1003148 A 20100727 DISPOSITIF ET PROCEDE D'ADAPTATION DYNAMIQUE D'UN SYSTEME COMPLEXE A DIFFERENTS CONTEXTES D'UTILISATION DU SYSTEME COMPLEXE La présente invention concerne un dispositif d'adaptation dynamique d'un système complexe à différents contextes d'utilisation dudit système complexe. L'invention s'applique notamment à des systèmes d'information complexes basés sur une architecture orientée services, mise en oeuvre par exemple à l'aide de services web. De manière générale, l'invention s'applique dans le domaine des systèmes adaptables, de plus en plus présents dans l'informatique ambiante ou ubiquitaire. Un système complexe peut être défini comme un système, composé de sous-systèmes qui interagissent entre eux et qui sont en interaction éventuelle avec des utilisateurs humains ou d'autres systèmes externes. Un système complexe est généralement utilisé sur un ensemble d'ordinateurs interconnectés entre eux par un réseau informatique. La notion d'ordinateur a été profondément modifiée avec l'essor de l'informatique ambiante : elle inclut désormais de nombreux types d'objets électroniques qui sont : - intelligents, c'est-à-dire contenant un processeur embarqué ; - communicants ; - disséminés dans un environnement d'utilisateurs ; - recueillant ou fournissant des informations pertinentes pour eux même. Les systèmes complexes comportent un grand nombre d'entités entretenant entre elles de nombreuses interactions et prenant en compte de nombreuses informations pour réaliser une opération complexe de façon plus ou moins automatique. Lesdites informations ne sont pas forcément toutes connues lors de la conception du système. Certaines informations peuvent être inconnues ou imprédictibles lors de la conception du système et par la suite, leur prise en compte par le système lors de son fonctionnement n'est pas réalisable ou partiellement réalisable. Dans les deux cas, cela peut conduire à des comportements inattendus, voir imprévisibles du système pour son utilisateur, au fur et à mesure de l'occurrence et de l'évolution de ces informations dans le temps. De tels comportements peuvent avoir des conséquences très négatives en termes humains, sociaux ou économiques. Les opérations complexes mises en oeuvre par les systèmes complexes sont généralement critiques pour des organisations utilisant les systèmes complexes. De telles opérations reposent de plus en plus sur des processus métiers automatisables. Les processus métier permettent notamment de décrire des échanges entre les différents sous systèmes et les utilisateurs du système complexe, et notamment en termes d'activités. Les activités peuvent avoir un ordre donné et un but organisationnel donné. Les processus métiers sont généralement mis au point lors de la conception du système, par des personnes ayant une grande expérience et expertise dans un ou plusieurs domaines métiers ayant attrait à l'organisation. De tels processus métiers sont mis en oeuvre de plus en plus souvent par des terminaux mobiles comme des téléphones, des assistants personnels numériques. Les caractéristiques techniques de ces terminaux, comme leur puissance, leur capacité mémoire, peuvent avoir une influence sur le bon déroulement des opérations et par la suite des processus. D'autres informations sur les utilisateurs de ces terminaux, comme leurs compétences, identités, endroits, leur environnement physique comme la météorologie, la température, le bruit peuvent aussi impacter le bon déroulement des opérations et des processus. De telles informations sont appelées informations de contexte et forment un contexte. De façon générale, le contexte comporte toute information décrivant la situation de l'utilisateur, du système et de son environnement physique, pouvant avoir un impact sur le comportement du système complexe. Les domaines d'application des systèmes complexes sont divers. Par exemple, dans le domaine des télécommunications, ils peuvent être mis en oeuvre pour améliorer la qualité de services fournis, par exemple à travers une gestion de la congestion du réseau de télécommunication et de la mobilité de ses utilisateurs. Des exemples d'informations de contexte pour le domaine des télécommunications peuvent être : une bande passante du réseau, une position de ces utilisateurs. Dans le domaine aéroportuaire, des systèmes complexes peuvent être mis en oeuvre dans le cadre d'applications de gestion de crises en utilisant des informations recueillies notamment par des caméras, des satellites, des détecteurs de fumée. Des exemples de contextes pour le domaine aéroportuaire peuvent être : un bagage abandonné, une température d'un bâtiment qui augmente rapidement, une activité suspecte d'un passager. Les informations de contexte peuvent évoluer rapidement et de façon imprévisible. Pour une gestion de crises par exemple, un contexte tel que « bagage suspect » peut évoluer vers un contexte « explosion », la température qui augmente peut évoluer vers un contexte « incendie », l'activité suspecte d'un passager peut évoluer vers une attaque terroriste. De telles informations de contexte sont très peu prédictibles tant dans leur évolution que dans leur impact sur le comportement du système complexe de gestion de crises. Par exemple, un comportement d'un système complexe peut être initialement une première interaction, configuration ou composition de sous systèmes et services, une première ressource qui exécute une première activité, ou encore une deuxième activité à exécuter à un moment donné. Les impacts de changements de contexte sur le comportement du système sont variés : ils peuvent se traduire par une nouvelle interaction, configuration ou composition de sous systèmes et services, un changement de la ressource exécutant l'activité, ou encore un remplacement d'une activité par une autre plus urgente. Une bonne gestion de crises nécessite une compréhension rapide du contexte de la crise, une anticipation de son impact sur le comportement du système complexe et la mise en oeuvre de moyens adéquats pour gérer la crise en propageant son impact à travers les couches métiers et techniques du système complexe. Les processus métiers permettent de décrire différents comportements du système complexe d'un point de vue métier lors de sa conception. L'architecture et le code informatique du système complexe permettent de décrire son comportement d'un point de vue technique lors de son exécution. Le nombre et l'ordre d'occurrence de ces informations de contexte peuvent augmenter rapidement et devenir ingérables et impossibles à prévoir lors d'une conception du système par la modélisation de ses processus métiers. Les comportements décrits au niveau métier peuvent par la suite ne pas satisfaire toutes les informations de contexte pouvant intervenir lors de du fonctionnement du système complexe. Les développeurs de tels systèmes complexes doivent mettre à jour l'architecture et le code informatique du système pour que le système complexe intègre un nouveau comportement. De telles mises à jour sont généralement couteuses en terme de temps de calcul. De plus, tout retard dans leur mise en oeuvre peut avoir des conséquences lourdes dans le cas de systèmes complexes critiques tel que des systèmes de gestion de crises. La réalisation et la gestion de tels systèmes complexes peuvent notamment se heurter aux problèmes suivants : - une complexité liée à une explosion combinatoire des configurations possibles du système en fonction des changements du contexte ; - une impossibilité de gérer l'impact d'un changement dynamique du 10 contexte sur différents processus métiers gérés par le système complexe ; - une impossibilité de répercuter automatiquement un changement dynamique de contexte sur des processus métier, sur l'architecture du système complexe ainsi que sur les couches techniques d'un système 15 complexe. Une configuration d'un système est une disposition ou un arrangement de parties composant le système. Une configuration est définie par un choix d'options ou de variantes fournies par le système. Dans le domaine des réseaux informatiques, une configuration est une topologie donnée du 20 réseau. Dans le domaine de l'ingénierie des processus métier, une configuration est un processus métier construit à partir d'un ensemble de tâches participant ou données. Une idée de la complexité à gérer peut être donnée à travers une formule mathématique calculant un nombre de configurations possibles d'un système 25 complexe, composé d'un nombre entier n de sous systèmes en fonction d'un nombre m de changements de contexte : m x En n! (1000) P-1 p!x(n - p)! où m représente également un nombre entier maximum d'informations contextuelles, et p est un nombre entier variant de un à n. 30 En prenant l'exemple d'un aéroport, plusieurs types de crises peuvent se produire dans un aéroport telles que : un incendie, une explosion, une attaque terroriste, une attaque chimique. La gestion de telles crises dans un aéroport peut faire intervenir plusieurs systèmes et acteurs humains appartenant à des organisations différentes : - des systèmes de gestion de crises d'une cellule de crise comme des systèmes d'aide à la décision, des systèmes de partage et d'échange de données de crises, des systèmes de planification des ressources utiles en cas de crise, des systèmes de gestion de capteurs ; - des systèmes de gestion de l'aéroport : par exemple un système de la tour de contrôle, un système ATFCM, acronyme pour l'expression anglo-saxonne Air Traffic Flow and Capacity Management, signifiant gestion du flux et des capacités aériennes ; - des systèmes de gestion des pompiers ; - des systèmes de gestion des hôpitaux ; - des systèmes de gestion des postes de police ; - et dans certains cas : systèmes de médias, d'autorités publiques ou gouvernementales comme le ministère de la défense ou de l'intérieur. Le nombre d'organisations différentes intervenant dans une crise, et les interactions entre leurs systèmes, dépendent du contexte c'est à dire du type de crise, de son ampleur, de ses risques et de son évolution. La manière dont sont réalisées les activités par les sous systèmes et les acteurs humains dépendent également du contexte. Par exemple, une cellule de crise ne fait appel à des hôpitaux que s'il y a des blessés. Le choix d'un ou plusieurs hôpitaux peut dépendre aussi de certaines informations : par exemple la proximité avec le lieu de la crise, le trafic routier, la capacité d'accueil des hôpitaux, le nombre de blessés, la nature des blessures. De plus, une crise évoluant dans le temps, le besoin du système complexe d'interagir avec l'une ou l'autre des organisations peut intervenir dès le début de la crise ou plus tard. Par exemple, une cellule de crise peut décider de faire intervenir la police si la crise a une nature terroriste ou criminelle. Puis, au fur et à mesure de l'évolution d'une crise des informations plus précises sur sa nature peuvent être disponibles. Ou encore, son évolution peut entrainer des dégâts de plus en plus importants nécessitant l'intervention d'organisations auxquelles il n'était pas nécessaire de faire appel au début de la crise. Un système de gestion de crises doit donc être capable de prendre en compte des variations dynamiques de contexte et de s'adapter en fonction du contexte courant, notamment en se connectant dynamiquement à des systèmes externes appartenant à des organisations diverses, par exemple : - en activant dynamiquement tous les capteurs de gaz appartenant à des zones différentes de l'aéroport pour suivre l'évolution d'une fuite de gaz ; - en modifiant des informations affichées sur les terminaux mobiles des secouristes pour des raisons de sécurité, de bande passante réseau. De façon générale, une adaptation dynamique, c'est à dire en cours de fonctionnement, d'un système de gestion de crises peut avoir plusieurs formes comme : - passer dynamiquement d'une première composition de sous-systèmes à une deuxième composition de sous-systèmes ; - supprimer, ajouter ou modifier dynamiquement une activité réalisée par un sous système ou un acteur humain ; - modifier dynamiquement le sous système ou l'acteur humain réalisant une activité ; - modifier dynamiquement un ordre des activités à exécuter ; - exécuter dynamiquement plusieurs activités parallèles dans un ordre séquentiel en cas de non disponibilité de ressources. Différents travaux ont été réalisés sur l'adaptabilité des systèmes informatiques ubiquitaires et ambiants. Des premiers travaux se sont principalement focalisés sur des environnements permettant d'exécuter des systèmes dynamiques adaptables, permettant de connecter et de déployer des composants à chaud, c'est à dire en cours de fonctionnement. Certains de ces premiers travaux définissent des « middlewares », expression anglo-saxonne signifiant littéralement intergiciels, ou logiciels médiateurs, gérant l'adaptabilité d'applications distribuées. Dans le domaine de l'architecture informatique, « middleware » est une expression anglo-saxonne désignant une couche de logiciels qui créée un réseau d'échange d'informations entre différentes applications informatiques. Le réseau d'échange est mis en oeuvre par l'utilisation d'une même technique d'échanges d'informations dans toutes les applications impliquées à l'aide de composants logiciels. De tels « middleware » sont notamment proposés et développés dans le cadre de projets européens tel que MADAM décrit dans « Distributed context management in a Mobility and ADaptation enAbling Middleware, ACM 2006 » et MUSIC décrit dans « MUSIC : Middleware Support for Self-Adaptation in Ubiquitous and Service-Oriented Environments, Springer 2009 » ou dans d'autres travaux de recherche tel que Wcomp décrit dans «A Middleware for Ubiquitous Computing : WComp, 2008 ». D'autres deuxièmes travaux se sont focalisés sur des approches et des environnements de conception et de développement de systèmes dynamiques adaptables. Ces deuxièmes travaux consistent en un ensemble de méthodologies de conception et en des méta-modèles pour la modélisation de systèmes adaptables, ainsi que des « Framework », expression anglo-saxonne pour cadre d'applications, pour le développement de ces systèmes. Un modèle est une abstraction d'un système qui est suffisante pour comprendre le fonctionnement du système modélisé. Un méta-modèle définit un langage d'expression d'un modèle c'est à dire des règles de modélisation à respecter pour construire un modèle en conformité avec son méta-modèle. Un « Framework » est de manière générale une bibliothèque de composants logiciels structurels, qui définissent des fondations ainsi que l'organisation de tout ou d'une partie d'un logiciel, c'est à dire son architecture. Ces deuxièmes types de travaux sont notamment décrits par Floch, J., Hallsteinsen, S., Stav, E., Eliassen, F., Lund, K., and Gjorven E., dans « Using architecture models for runtime adaptability in Software IEEE, 23(2):62-70, 2006 » et par Brice Morin, Franck Fleurey, Nelly Bencomo, Jean-Marc Jézéquel, Arnor Solberg, Vegard Dehlen and Gordon Blair dans « An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability, MoDELS 2008 ». Les travaux précédemment cités s'inscrivent souvent dans le cadre d'approches et/ou de middleware par composants et se focalisent sur des adaptations réalisées au niveau architecture de système et au niveau code de programmation du système. L'impact d'une variabilité au niveau architectural d'un système se traduit par des variations des composants constituant les systèmes et des connexions entre les composants. La variabilité est par définition une capacité d'un artefact logiciel à être personnalisé ou configuré. Un artefact logiciel est par exemple un port, un composant logiciel. L'introduction d'une variabilité au niveau des composants et au niveau de l'assemblage des composants permet de faciliter des reconfigurations éventuelles du système complexe et donc son adaptation aux différents changements. Cependant, aucune des différentes approches existantes ne permet d'étudier l'impact des changements de contexte sur les aspects métier du système complexe, ni de reporter un impact des changements de contexte sur l'architecture et le code informatique du système complexe. Les aspects métier d'un système complexe sont définis par des experts métier d'un domaine particulier et décrivent de manière conceptuelle des collaborations et des interactions entre sous systèmes au sein d'une ou plusieurs organisations. Les architectures ainsi proposées se focalisent sur une adaptation architecturale et technique du système complexe sans corrélation avec des adaptations métier. Les deux niveaux métier et technique sont alors en déphasage concernant les aspects d'adaptation en fonction du contexte. D'autres troisièmes travaux qui s'intéressent aux aspects métier, introduisent une variabilité dans les processus métier pour augmenter leur capacité à se configurer et à s'adapter en fonction des besoins d'une organisation. Ces travaux sont décrits par M. Rosemann et W.M.P. van der Aalst dans « A Configurable Reference Modelling Language, 2007 », par M. Razavian et R. Khosravi dans « Modeling Variability in Business Process Models Using UML, 2008 » et par M. La Rosa, M. Dumas, A.H.M. ter Hofstede et J. Mendling dans « Managing Variability in Process-Aware Information Systems, 2009 » D'une part, ces troisièmes travaux restent focalisés sur la phase de conception et modélisation des processus métier, sans avoir pour vocation d'exécuter un système complexe concret basé sur ces processus. Et d'autre part, la variabilité introduite par ces travaux est une variabilité s'exerçant dans le domaine métier, classiquement traitée par les approches de lignes de produits, et non pas une variabilité dynamique en fonction du contexte. Ces travaux ne visent pas une adaptation dynamique d'un système complexe en fonction du contexte prenant en même temps les deux aspects métiers et techniques. Certains quatrièmes travaux élaborés sur des cas d'études industriels internes à Thales (par exemple un système de supervision maritime) ou dans des projets de recherche industrielle (par exemple le projet IsyCri dans « interopérabilité par médiation dans le cadre d'une dynamique de collaboration : application à la gestion de crise, 2009 ») utilisent la notion du contexte dans les deux phases de conception des processus métiers et dans la phase d'exécution de ces processus métier en se basant sur l'architecture et le code technique. Ces travaux modélisent le contexte comme une information métier dans leurs processus métier, ce qui est contraire à la nature même des informations de contexte évoluant dynamiquement. Les informations métier sont généralement dénombrables et leur ordre de réception est connu. Alors qu'il est impossible de prévoir ni les moments de réception des événements de contexte, ni leur ordre d'apparition. Des jonctions, appelées aussi branchements, fournis par des langages de modélisation de processus métier permettent de faire des tests sur des informations métier dénombrables et ayant un ordre de réception prévu et connu, à l'inverse des informations de contexte imprévisibles. Ces quatrièmes travaux ne s'intéressent pas à l'adaptation dynamique en fonction du contexte mais à l'interopérabilité entre sous systèmes d'un système complexe. Représenter la variabilité et les configurations possibles d'un système complexe en fonction du contexte dans les processus métier de la même manière que celle décrite dans les quatrièmes travaux, c'est à dire avec des jonctions métier, se heurte rapidement d'une part à la complexité des processus métier résultants et d'autre part à l'explosion combinatoire des configurations possibles. A titre d'exemple, un analyste métier qui a besoin de représenter un processus métier composé de quatre tâches s'exécutant de façon séquentielle et dans tous les ordres possibles avec la possibilité qu'une ou plusieurs tâches soient optionnelles dans certains contextes, est obligé de représenter soixante quatre fois le processus métier dans les différentes ordres possibles. Ce besoin de représenter la variabilité séquentielle se heurte aussi à une explosion combinatoire du nombre de configurations possibles exprimé notamment par la formule suivante : En n'! (1001) P,-1 (n'-p')! dans laquelle n' représente un nombre entier de tâches dans une séquence 30 et p' un nombre entier variant de un à n'. En même temps que la variabilité séquentielle, d'autres types de variabilité peuvent être déclenchés par des changements de contexte. Par exemple des variabilités peuvent être dues à : - une différence dans les ressources qui vont accomplir les tâches ; - une différence dans les données échangées entre les tâches ; - une différence dans les flux d'exécution des tâches. Le nombre de configurations possibles devient trop important pour être modélisable. La modélisation de ces différents types de variabilité en fonction du contexte avec des langages de modélisation de processus métier existants se heurte souvent à la complexité des configurations possibles et à la complexité des processus métiers résultants. De façon générale, la plupart des travaux existants considèrent les aspects relatifs à la variabilité soit au niveau architectural et code applicatif, soit au niveau des processus métier sans corrélation des deux niveaux. De plus, la plupart des travaux au niveau des processus métier ne s'intéressent pas à la variabilité dynamique dans le contexte et se limitent surtout à la variabilité dans le domaine métier, également appelée variabilité statique ou variabilité de ligne de produits. Les travaux existants souffrent d'un manque de liens, voir de traçabilité entre les niveaux métiers et techniques concernant les aspects de variabilité dynamique dans le contexte. Ceci augmente l'écart entre les processus métier et les couches techniques sur le plan de prise en compte de ce type de variabilité dynamique dans le contexte. Par conséquent, il n'existe aucun mécanisme permettant de répercuter automatiquement un impact d'un changement dynamique de contexte sur les processus métier et sur l'architecture technique d'un système complexe. Les travaux existants ne permettent pas notamment la gestion des informations de contexte et de l'explosion combinatoire des configurations, au niveau des processus métiers. Un but de l'invention est notamment de permettre une gestion automatique de changements dynamiques de contexte et de leur impact sur les processus métier ainsi que sur l'architecture et le comportement des services offerts par un système complexe ainsi le comportement. A cette fin, l'invention a pour objet un dispositif d'adaptation dynamique d'un système complexe à différents contextes d'utilisation du système complexe. Le système complexe comporte un ensemble de sous-systèmes hétérogènes interagissant, un contexte étant défini par un ensemble de données caractérisant une situation particulière à laquelle est soumis le système complexe. Le dispositif effectue une orchestration des sous-systèmes en exécutant des processus métier adaptés automatiquement par ledit dispositif à un contexte courant. Ledit dispositif prend en entrée un modèle de processus métier variable en fonction du contexte. Un processus métier étant une succession de tâches à réaliser par les sous-systèmes dans le cadre d'une procédure propre à un domaine technique. Le contexte courant est un ensemble de données caractérisant la situation particulière à un instant donné. Le dispositif peut en outre comporter un premier composant effectuant une gestion centralisée des données de contexte. ~o Le contexte courant peut être un contexte de haut niveau comportant une interprétation d'un ensemble de données de contextes de bas niveau provenant de capteurs, d'autres types de sources, collecteurs de contexte. Le dispositif peut en outre comporter : 15 - un deuxième composant prenant en entrée : les données de contexte fournies par le premier composant et le modèle de processus métier variable, ledit deuxième composant déterminant en fonction du contexte courant les tâches composant le processus métier, générant un modèle de processus métier adapté au contexte courant ; 20 - un troisième composant prenant en entrée le modèle de processus métier adapté au contexte courant pour générer un processus métier exécutable ; - un quatrième composant utilisant en entrée un processus métier exécutable, orchestrant les sous-systèmes pour la réalisation du processus métier exécutable. 25 Le quatrième composant peut remplacer le processus métier en cours d'exécution par un nouveau processus métier exécutable sur un changement de contexte. Le dispositif peut en outre comporter : - un cinquième composant prenant en entrée le modèle de processus métier 30 variable, générant un processus métier variable exécutable ; - un troisième composant prenant en entrée le processus métier variable exécutable, les données de contexte fournies par le premier composant, générant un processus métier variable exécutable en fonction du contexte courant, résolvant les variabilités des processus métier en fonction du contexte courant, orchestrant les sous-systèmes pour la réalisation du processus métier exécutable. Les capteurs et les sources de contexte sont notamment répartis dans un théâtre d'opérations. L'invention concerne en outre un procédé d'adaptation dynamique d'un système complexe à différents contextes d'utilisation du système complexe. Ledit système complexe comporte un ensemble de sous-systèmes hétérogènes interagissant. Un contexte est défini par un ensemble de données caractérisant une situation particulière à laquelle est soumis le système complexe. Ledit procédé comporte au moins les étapes suivantes : - génération d'un modèle de processus métier adapté au contexte courant en fonction d'un modèle variable de processus métier et de données du contexte courant ; - génération d'un processus métier exécutable à partir du modèle de 15 processus métier adapté au contexte ; - orchestration des sous-systèmes pour la réalisation du processus métier exécutable. L'invention concerne en outre un procédé d'adaptation dynamique d'un système complexe à différents contextes d'utilisation du système 20 complexe. Le système complexe comporte un ensemble de sous-systèmes hétérogènes interagissant. Un contexte est défini par un ensemble de données caractérisant une situation particulière à laquelle est soumis le système complexe. Ledit procédé comporte au moins les étapes suivantes : - génération d'un processus métier variable exécutable en fonction d'un 25 modèle variable de processus métier ; - orchestration des sous-systèmes pour la réalisation du processus métier, en prenant en compte le processus métier variable exécutable et les données de contexte courant. 30 L'invention a notamment pour principal avantage de faire évoluer de manière dynamique un système complexe au fur et à mesure des changements du contexte. Par exemple, l'invention peut permettre à un système de gestion de crises de prendre les bonnes décisions au fur et à mesure des changements dynamiques survenant pendant la situation de 35 crise. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, donnée à titre illustratif et non limitatif, et faite en regard des dessins annexés qui représentent : - la figure la : un exemple d'une configuration d'un système complexe pour un contexte de type « incendie sans victime » ; - la figure 1 b : un exemple d'une configuration d'un système complexe pour un contexte de type « attaque terroriste » ; - la figure 1 c : un exemple d'une configuration d'un système complexe pour un contexte de type « accident d'avion » ; - la figure 2 : un exemple d'un modèle de processus métier au format BPMN, acronyme pour l'expression anglo-saxonne Business Process Modeling Notation, signifiant littéralement notation pour modéliser des processus métiers, avec une modélisation d'un contexte sous forme de données métier. - la figure 3 : un exemple d'un modèle de processus métier au format BPMN avec une modélisation du contexte sous forme d'événements métier ; - la figure 4 : un exemple de modèle d'informations contextuelles ; - la figure 5 : un exemple d'une partie d'un modèle variable de processus métier ; - la figure 6 : un processus de type « variable » avec un « pattern optional », expression anglo-saxonne signifiant littéralement motif optionnel ; - la figure 7 : un exemple de variabilité de flux de messages dans un modèle de processus métier ; - la figure 8 : un exemple de variabilité des participants dans un modèle de processus métier ; - la figure 9 : un exemple de variabilité de type configurable dans un modèle de processus métier ; - la figure 10 : un schéma d'une première architecture du dispositif selon l'invention ; - la figure Il a : un premier exemple d'un modèle BPMN adapté par le dispositif selon l'invention dans un premier contexte donné ; - la figure 11 b : un deuxième exemple d'un modèle BPMN adapté par le dispositif selon l'invention dans un deuxième contexte ; - la figure 12 : un schéma d'une deuxième architecture possible du dispositif selon l'invention. La description de l'invention est basée sur un système de gestion de crises d'un aéroport, cependant, un tel système est simplement choisi à titre d'exemple, d'autres systèmes peuvent servir de cadre à l'invention. Les figures la, 1 b et l c représentent des exemples de configurations d'un système complexe pour différents types de contexte. Sur les figures la, 1 b, 1c une configuration donnée d'un système complexe correspond à une intervention et une coopération d'un ou plusieurs sous systèmes en vue de résoudre une crise. Au fur et à mesure des changements dans le contexte comme par exemple une évolution du type de la crise ou des conditions climatiques, le système complexe met en place la configuration la plus adéquate et la mieux adaptée au contexte. La figure la présente un exemple d'une première configuration 10 du système complexe de gestion de crise pour un contexte de type « incendie sans victime ». Dans le cas d'une crise correspondant à un « incendie sans victime » deux systèmes peuvent par exemple intervenir pour résoudre la crise : un premier système 1 de gestion d'une brigade de pompier, un deuxième système 2 de gestion d'une cellule de crise dans l'aéroport. Les deux systèmes 1, 2 interagissent : chaque système peut communiquer des informations à l'autre système, et prendre en compte des informations provenant de l'autre système. La figure lb présente un exemple d'une deuxième configuration 11 du système complexe de gestion de crise pour un contexte de type « attaque terroriste ». Dans le cas d'une crise correspondant à une « attaque terroriste » quatre systèmes peuvent par exemple intervenir pour résoudre la crise : le premier système 1 de gestion d'une brigade de pompier, le deuxième système 2 de gestion d'une cellule de crise dans l'aéroport, un deuxième système de gestion d'un hôpital 3, un troisième système de gestion de la police 4. Les quatre systèmes interagissent et communiquent des informations tous entre eux. La figure 1c présente un exemple d'une troisième configuration 12 d'un système complexe pour un contexte de type « accident d'avion ». L'accident d'avion pris pour exemple peut être une explosion sur une piste d'atterrissage. Dans ce genre de crise, six systèmes peuvent par exemple interagir : le premier système 1 de gestion d'une brigade de pompier, le deuxième système 2 de gestion d'une cellule de crise dans l'aéroport, le troisième système de gestion d'un hôpital 3, le quatrième système de gestion de la police 4, un cinquième système de gestion des systèmes de médias 5, un sixième système de gestion de la tour de contrôle 6. Les six systèmes 1, 2, 3, 4, 5, 6 interagissent et communiquent des informations tous entre eux. Les figures la, 1 b, et 1 c montrent que plus l'impact de la crise est important plus le nombre de systèmes nécessaires à sa résolution est important. Un nombre important de systèmes entraine la multiplication des interactions entre les systèmes et donc une complexification du système de gestion de crise. Cette complexité est déjà formulée auparavant avec la formule mathématique (1000) qui calcule l'impact des changements de contexte sur l'assemblage entre sous systèmes d'un système complexe. Les figures la, 1 b, et 1c montrent l'impact des changements dans le contexte sur l'assemblage d'un système complexe ou encore la variabilité dans l'assemblage d'un système complexe en fonction du contexte. Cependant, l'impact du contexte ne se limite pas à la variabilité dans l'assemblage des sous systèmes. En effet, les figures la, 1 b, et 1c ne donnent aucune idée de la manière dont les fonctionnalités offertes par ces sous systèmes sont invoquées ni comment ces sous systèmes interagissent entre eux. Par exemple, sur la figure l c, on ne sait pas si la cellule de crise 2 contacte les pompiers 1 en premier, ou si elle contacte l'hôpital 3 avant. Les configurations 10, 11, 12 représentées sur les figures la, 1 b et 1c ne permettent pas en outre de définir des types de flux circulant entre les systèmes ainsi que leur variabilité en fonction des évolutions d'une crise. Sur les figures 2 et 3 dont la description suit, sont représentés d'autres impacts des changements dans le contexte sur le système complexe et donc d'autres types de variabilité en fonction du contexte. Les figures 2 et 3 illustrent notamment l'impact des changements de contexte sur la variabilité dans un flux de séquence circulant entre les sous systèmes d'un système complexe. La figure 2 représente notamment un premier exemple d'un premier modèle de processus métier 200. La modélisation représentée sur la figure 2 utilise une notation selon le standard BPMN, acronyme pour l'expression anglo-saxonne Business Process Modeling Notation signifiant littéralement notation pour modéliser des processus métiers. Un standard BPMN est notamment décrit dans le document suivant : « Business Process Modeling Notation (BPMN) Version 1.2, OMG Document Number : formai / 2009-01-03 Standard document ». Sur la figure 2, un premier sous processus « constitution des équipes sur site de crise » peut être modélisé par des variations 215, 216, 217, 218, 219, 220 d'une séquence de tâches. Les tâches peuvent être les suivantes : 15 une première tâche 209: « Prévenir la gendarmerie » une deuxième tâche 210 : « Prévenir les policiers » une troisième tâche 211 : « Prévenir les passagers » une quatrième tâche 212 : « Prévenir les hôpitaux » une cinquième tâche 213: « Prévenir les ressources internes 20 (conducteur de camion) » une sixième tâche 214: « Prévenir les ressources internes (conducteur de camion) » Les tâches 209, 210, 211, 212, 213, 214, d'après le processus métier décrit sur la figure 2, peuvent être invoquées de six manières différentes, 25 chaque invocation correspondant à une séquence d'exécution donnée des tâches 209, 210, 211, 212, 213, 214 ou d'un sous ensemble de ces tâches. Par exemple : - une première séquence 215 peuvent être invoquées dans l'ordre suivant : la première tâche 209, la deuxième tâche 210, la troisième 30 tâche 211, la quatrième tâche 212 ; - une deuxième séquence 216 peuvent être invoquées dans l'ordre suivant : la première tâche 209, la deuxième tâche 210, la troisième tâche 211 ; - une troisième séquence 217 peuvent être invoquées dans l'ordre : la première tâche 209, la deuxième tâche 210, la troisième tâche 211 ; la cinquième tâche 213 ; - une quatrième séquence 218 peuvent être invoquées dans l'ordre suivant : la première tâche 209, la sixième tâche 214, la troisième tâche 211 ; la quatrième tâche 212 ; - une cinquième séquence 219 peuvent être invoquées dans l'ordre suivant : la première tâche 209, la sixième tâche 214, la troisième tâche 211 ; - une sixième séquence 220, peuvent être invoquées dans l'ordre suivant : la première tâche 209, la sixième tâche 214, la troisième tâche 211, la cinquième tâche 213. La figure 2 présente un exemple de l'impact des changements de contexte sur l'ordre séquentiel d'exécution des tâches dans un processus métier. La variabilité séquentielle dans le processus métier est modélisée sur la figure 2 en traitant le contexte comme un ensemble d'informations métier selon le standard BPMN. Par exemple lors de l'exécution du sous processus métier « constitution des équipes sur site », le contexte est collecté une fois pour toute grâce à une septième tâche 201 « Collecter le contexte ». Un premier branchement 202 « Test contexte » permet de tester les données contextuelles en supposant leur disponibilité à ce moment de l'exécution du processus métier « constitution des équipes sur site ». La condition du test est évaluée par rapport à l'une des six possibilités de contexte 203, 204, 205, 206, 207, 208, représentés sur la figure 2. En fonction du résultat du test, une possibilité de contexte est valide et le flux de séquence correspondant est exécuté par le système complexe. Par exemple : - Une première possibilité de contexte 203: « attaque chimique avec risque explosion et dégâts humains » provoque l'exécution de la première séquence 215 ; - Une deuxième possibilité de contexte 204: « attaque chimique avec risque explosion et sans dégâts » provoque l'exécution de la deuxième séquence 216 ; - Une troisième possibilité de contexte 205: « attaque chimique avec risque explosion et dégâts matériels » provoque l'exécution de la troisième séquence 217 ; - Une quatrième possibilité de contexte 206: « attaque chimique avec risque d'asphyxie et dégâts humains » provoque l'exécution de la quatrième séquence 218 ; - Une cinquième possibilité de contexte 207: « attaque chimique avec risque d'asphyxie et sans dégâts » qui invoque l'exécution de la cinquième séquence 219 ; - Une sixième possibilité de contexte 208: « attaque chimique avec risque d'asphyxie et dégâts matériels » qui invoque l'exécution de la sixième séquence 220 ; Sur la figure 2, sont représentés pour l'exemple six flux de séquence, ou séquences, ou encore configurations 215, 216, 217, 218, 219, 220. Mais en théorie, le contexte évolue de manière exponentielle. Cette évolution exponentielle conduit à une explosion combinatoire des flux de séquences ou configurations possibles. Cette complexité est donnée par la formule mathématique (1001) qui calcule le nombre de configurations possibles dans le cas d'une variabilité séquentielle en fonction du contexte. D'autres types de variabilité peuvent bien évidement être déclenchés par des changements de contexte, par exemple : une variabilité dans un flux des données à transiter entre les tâches, dans les ressources exécutant les tâches. Le nombre de configurations possibles du système complexe augmente donc rapidement au cours de l'évolution du contexte de la crise et devient difficilement modélisable et gérable. La figure 3 représente un deuxième exemple 300 de modélisation de la variabilité séquentielle en fonction du contexte dans un processus métier. La figure 3 représente le même sous processus que la figure 2: « constitution des équipes sur site », mais en modélisant le contexte comme des événements métier selon le standard BPMN. Les branchements représentés sur la figure 3 sont des branchements sur les événements à la différence du branchement 202 représenté sur la figure 2 qui est un branchement sur les données. Sur la figure 2, le contexte est évalué une seule fois grâce à la septième tâche 201 « Collecter le contexte » et un branchement 202 sur les données résultant du « Test contexte ». Alors que dans la figure 3 le contexte est évalué à chaque branchement sur les événements définis dans le processus métier. Sur la figure 2, le système complexe prévoit le moment où il va chercher le contexte et il l'évalue une fois pour toute. Dans le cadre de la figure 3, le système complexe ne collecte pas le contexte mais interprète les données arrivant au fur et à mesure comme des événements de contexte en fonction des branchements sur les événements prévus lors de l'exécution du processus métier. La figure 3 représente une prise en compte des informations de contexte dans la description des différentes séquences possibles d'exécution des tâches 209, 210, 211, 212, 213, 214 représentées sur la figure 2. Par exemple, la figure 3 représente le processus métier en prenant compte d'un type de crise 301 qui peut être : - une attaque chimique 306 ; - un incendie 313 ; - un objet suspect 318. Selon le type de crise 301, la séquence de tâche engagée peut donc être différente. Par exemple, pour une attaque chimique 306, la première tâche à accomplir peut être la première tâche 209 « prévenir la gendarmerie » ; pour un incendie 313, la première tâche à accomplir peut être une huitième tâche 322 « prévenir les ressources internes (pompiers) ». Ensuite, selon un type de risque 302, la tâche suivant la première tâche 209 peut être : - la deuxième tâche 210 « prévenir les policiers » Si le type de risque 302 est « risque d'explosion 307 » ; - une sixième tâche 214 « prévenir les ressources internes (secours rapides) », Si le type de risque 302 est « risque d'asphyxie » 308 ; - une huitième tâche 319 « prévenir le gouvernement », Si le type de risque 302 est « risque de radiation » 309. Ensuite, une tâche suivant la huitième tâche 319 « prévenir le gouvernement » peut être une neuvième tâche 320 « prévenir l'armée », puis une dixième tâche 321 « prévenir les médias ». Quelque soit le type de risque 302, la tâche suivante est une troisième tâche 35 211 « prévenir les passagers ». Puis, selon un type de dégâts 303, soit : - la quatrième tâche 212 « prévenir les hôpitaux » est réalisée lorsque le type de dégât 303 est « humain » 310 ; - la cinquième tâche 213 « prévenir les ressources internes (conducteur de camion) » est effectuée si le type de dégât est matériel 312 ; - aucune autre tâche n'est accomplie si le type de dégât 303 est à « non » 311, c'est-à-dire qu'il n'y a pas de dégât. Dans le processus métier représenté sur la figure 3, lorsque la huitième tâche 322 a été accomplie, lorsqu'un type de gravité 304 est à « grave » 314, les tâches suivantes sont effectuées : une onzième tâche « prévenir les pompiers » 323 puis la troisième tâche 211 « prévenir les passagers ». Ensuite, et également lorsque le type de gravité 304 est « faible » 315, le type de dégâts 303 est évalué. Selon le type de dégâts 303 les tâches suivantes peuvent être effectuées : - pour un type de dégât 303 « humains » 310: « prévenir les ressources internes (secours rapides) » 214, puis « prévenir les hôpitaux » 212 ; - pour un type de dégât 303 « matériels » 312: « prévenir les ressources internes (conducteurs de camion) » 213 ; - pour un type de dégât 303 à « non » 311, pas de tâche particulière. Ensuite, selon un type de doute « douteux ? » 305 soit la réponse est « oui » 317 et la première tâche 210 « prévenir les policiers » est accomplie, soit la réponse est « non » 316 et aucune tâche particulière n'est réalisée. Sur la figure 3, on remarque également une complexité de description 25 du processus, aggravé par rapport à la figure 2 par le fait que l'ordre d'arrivée des informations de contexte peut être permuté dans n'importe quel ordre à priori. Par exemple l'aspect criminel, ou « douteux » 305 de la crise peut être détecté avant de connaître le type de gravité 304. Le type de dégâts 303 causé par la crise peut être détecté avant de connaître le type de 30 gravité 304 de la crise. La gestion du contexte est rendu plus complexe à cause de l'aspect dynamique des informations de contexte. Figer un ordre de réception des informations de contexte tel que représenté sur la figure 3, par exemple du type de crise 301 puis du type de dégâts 303 peut bloquer le processus au cas où l'information contextuelle type de dégâts 303 est reçue 35 avant l'information contextuelle type de crise 301. Spécifier tous les ordres possibles de réception d'informations contextuelles peut conduire à un modèle d'une telle complexité qu'il est indéfinissable. Les figures 2 et 3 montrent que la description du contexte et de son impact avec la sémantique actuelle des processus métiers conduit à une complexité énorme. Représenter la variabilité avec les langages existants de modélisation et d'exécution des processus métier conduit à une complexité exponentielle dans les configurations possibles à modéliser et à développer. A l'aide de la sémantique actuelle de BPMN, il est possible d'éviter de spécifier toutes ces configurations possibles et de modéliser les parties variables dans les processus métiers comme une boite noire abstraite et sans détails. L'automatisation et la génération de code à partir des parties variables n'est donc pas possible puisque ces parties ne sont pas spécifiées de manière détaillée lors de la modélisation. Il en résulte des processus métier partiellement automatisables et exécutables puisque seuls les parties invariables dans les processus métier peuvent être automatisés. Les modèles de processus métiers ne sont plus qu'une image de haut niveau d'une architecture applicative du système pouvant n'avoir aucun rapport avec une conception du système lui-même. Les figures 4 et 5 dont la description suit, représentent deux étapes dans la méthodologie préconisée selon l'invention pour résoudre la complexité engendrée par la gestion du contexte et de son impact, et expliquée précédemment dans la description des figures 1, 2 et 3. Les figures 4 et 5 représentent respectivement un exemple de modèle de contexte et des mécanismes facilitant une description de la variabilité en utilisant les sémantiques actuelles des processus métier. La figure 4 représente un exemple d'un modèle de contexte regroupant les informations contextuelles pouvant impacter le système complexe. Un contexte courant 47 représenté sur la figure 4 est un état donné ou une instance donnée du modèle de contexte. Le contexte courant 47 comporte donc des informations relatives à un contexte de crise à un instant donné de l'exécution du système complexe comme : un incendie 50, un crash d'avion 51, une attaque chimique 52, une découverte d'objet suspect 53. Ensuite pour chaque type de contexte de crise, on peut retrouver les informations suivantes : - pour un incendie 50 : présence de dégâts matériels 500, d'une visibilité réduite 501, d'une fuite de gaz 502 ; - pour un crash avion 51 et une attaque chimique 52 : présence d'un risque d'asphyxie 510, de neige 511, d'un aspect criminel 512, de dégâts humains 520, d'un trafic important 521, d'une proximité de personnes 522 ; - pour un objet suspect 53 : présence d'un risque d'explosion 530, d'un risque de radiation 531, d'une attaque à la bombe 532. Un modèle de données contextuelles tel que représenté par exemple sur la figure 4 peut être réalisé par un analyste spécialisé dans un domaine particulier comme la gestion de crises. L'analyste peut par exemple identifier et spécifier un ensemble de données de contexte susceptibles d'avoir un impact sur le système complexe en général et sur ces processus métiers en particulier. L'analyste métier passe à la modélisation du système complexe par des processus métier et modélise la variabilité en fonction du contexte appliqué au processus métier. De tels processus métier sont variables en fonction du contexte. La figure 5 représente un exemple non détaillé d'un modèle de processus métier variable 49 en fonction du contexte. Des exemples de tels modèles variables de processus métier 49 sont détaillés sur les figures 6, 7, 8 et 9 dont la description suit. Par exemple un système de gestion de secouristes 61 présents dans un aéroport peut communiquer à un système de gestion de pompiers 63, un rapport 62 électronique sur la situation de la crise, consultable depuis des terminaux mobiles des pompiers. Selon le contexte d'intervention des pompiers à savoir « en mobilité vers l'aéroport » ou « sur les lieux de la crise », le rapport envoyé peut être sous une forme vocale ou textuelle. Dans ce processus, les changements de contexte impactent le flux de données échangées. Le modèle variable de processus métier 49 peut dans ce cas prévoir deux variantes de flux de données, un pour le rapport vocal et un pour le rapport textuel. La variabilité ici s'exerce sur le flux de données à savoir le rapport envoyé 62. Ainsi pour chaque processus métier, un analyste métier peut définir un premier modèle variable de processus métier 49. Le premier modèle variable de processus métier 49 peut être défini à partir d'un modèle de processus métier enrichi par des éléments prenant en compte une variabilité en fonction d'un contexte. Un tel premier modèle variable de processus métier 49 peut être réalisé en étudiant des types de variabilité pouvant résulter des changements de contexte. Les modèles de processus métier peuvent donc être complétés par des « patterns » de variabilité et des informations contextuelles. « Pattern » est une expression anglo-saxonne que l'on peut traduire par motif. Dans le domaine de la conception de système, un « pattern » est par définition un motif pouvant se répéter dans un modèle objet par exemple. Un pattern représente un phénomène que l'on peut observer de façon répétée lors de l'étude de certains sujets auquel il peut conférer des propriétés caractéristiques. Des exemples de patterns sont représentés sur les figures 6, 7, 8, 9, 10, 11, 12. Un ensemble de patterns peut, par exemple, être défini afin d'indiquer dans un modèle de processus métier l'impact d'un contexte sur des éléments du processus métier, c'est à dire des artefacts produits par un changement de contexte sur les éléments du processus métier. Les patterns suivants peuvent par exemple être utilisés : - Un premier « pattern optional », expression anglo-saxonne signifiant optionnel, peut indiquer qu'un élément d'un processus métier n'est pris en compte que lorsque le contexte courant remplit des conditions précisées. Le « pattern optional » peut être appliqué à des tâches, des sous processus, des flux d'activité, des flux de message, des événements, des données. - Un deuxième « pattern default », expression anglo-saxonne signifiant par défaut, peut être appliqué lorsqu'un élément d'un processus métier peut se réaliser de plusieurs manières en fonction du contexte. Une réalisation par défaut peut être précisée si tous les contextes spécifiés ne sont pas vérifiés au moment de l'exécution du processus. Le « pattern default » permet d'éviter des cas non résolus par le raisonneur 48 représenté sur la figure 10. Le « pattern default » peut être par exemple appliqué à une tâche, un sous processus, un participant. - Un troisième « pattern parallel », signifiant littéralement motif parallèle, peut être utilisé pour indiquer que selon un contexte donné plusieurs éléments d'un processus métier peuvent être exécutés en parallèle. Le « pattern parallel » peut être appliqué à une tâche, un sous processus. - Un quatrième « pattern sequence » peut indiquer que selon un contexte donné, plusieurs éléments d'un processus métier peuvent être exécutés de façon séquentielle. Le « pattern sequence » peut être appliqué à une tâche, un sous processus. - Un cinquième « pattern exclusive choice », signifiant littéralement choix exclusif, peut indiquer qu'il existe plusieurs possibilités d'exécution d'un ou plusieurs d'un processus métier selon le contexte. Les possibilités d'exécution sont exclusives entre elles. Dans un contexte déterminé, une et une seule possibilité ou variante est choisie pour réaliser le processus métier. Le « pattern exclusive choice » peut être appliqué à un sous processus, un événement, une donnée, un participant. - Un sixième « pattern inclusive choice », signifiant littéralement choix inclusif peut indiquer que plusieurs possibilités d'exécution d'une procédure métier peuvent être appliquées. Une coexistence des possibilités d'exécution si au moment de l'exécution plusieurs états de contexte valident en même temps des conditions d'exécution spécifiées pour ces variantes. Le « pattern inclusive choice » peut être appliqué à des sous processus, des événements, des données, des participants. - Un septième « pattern variable » indique qu'un élément d'un processus métier peut avoir plusieurs possibilités d'exécution suivant le contexte, les différentes possibilités n'étant pas des exclusives ou inclusives les unes par rapport aux autres. Le septième « pattern variable » peut être appliqué à un sous processus. - Un huitième « pattern configurable » indique qu'un élément d'un processus métier peut avoir plusieurs possibilités d'exécution suivant le contexte et que ces possibilités sont décrites de façon déclarative à l'aide de règles contextuelles de configuration. Le huitième « pattern configurable » peut être appliqué à un sous processus, une donnée, un événement, un participant. - Un neuvième « pattern skipped », signifiant littéralement motif sauté, peut indiquer qu'un élément d'un processus métier est négligé dans le cas d'un contexte donné. Un « pattern skipped » peut être appliqué à une tâche, un sous processus. - Un dixième « pattern before », signifiant littéralement motif précédent, indique qu'un élément d'un processus métier est pris en compte avant un autre élément dans le cas d'un contexte particulier. Un « pattern before » peut être appliqué à une tâche, un sous processus. - Un onzième « pattern after », signifiant littéralement motif suivant, indique qu'un élément d'un processus métier est pris en compte après un autre élément dans le cas d'un contexte particulier. Un « pattern after » peut être appliqué à une tâche, un sous processus. - Un douzième « pattern inclusion», indique qu'un élément donné inclut un autre élément dans un contexte donné. Un « pattern inclusion» peut être appliqué à une tâche, un sous processus. - Un treizième « pattern exclusion», indique qu'un élément donné exclut un autre élément dans un contexte donné. Un « pattern exclusion » peut être appliqué à une tâche, un sous processus. Les figures 6, 7, 8 et 9 représentent des exemples de processus métier variables en fonction du contexte utilisant les patterns de variabilité proposés et préconisés par la méthodologie selon l'invention pour résoudre la complexité explicitée par la description des figures 1, 2 et 3. La figure 6 représente un premier exemple de sous-processus métier variable 70 selon un « pattern optional ». Le sous-processus métier « Activation dynamique des capteurs » 70 est décrit selon le standard BPMN. Le sous-processus métier « Activation dynamique des capteurs » 70 décrit des tâches à réaliser pour activer dynamiquement des capteurs dans un aéroport. En effet, dans un aéroport les capteurs ne sont pas tous initialement activés pour des raisons d'économie d'énergie par exemple. Le sous-processus métier « Activation dynamique des capteurs » 70 peut être impacté par des informations contextuelles de type « incendie » et « explosion ». En effet, en cas d'incendie, le système de gestion de l'aéroport active les détecteurs de fumée dans la zone de l'incendie pour connaître l'évolution de l'incendie et son périmètre. En cas d'explosion, le système de gestion de l'aéroport active des détecteurs de gaz pour vérifier toute fuite de gaz pouvant être due à une explosion et pour connaître le périmètre d'une fuite de gaz. Le pattern de variabilité « variable » indique que le sous-processus métier « Activation dynamique des capteurs » 70 est variable, c'est-à-dire que le contexte peut modifier les tâches à accomplir dans le cadre du sous-processus métier « Activation dynamique des capteurs » 70. 1 o Le sous processus métier « Activation dynamique des capteurs » 70 comporte les tâches suivantes effectuées dans l'ordre cité : - une première tâche 71 peut être : « Activer les caméras mobiles » ; - une deuxième tâche 72 peut être « Activer tous les détecteurs de fumées ». La deuxième tâche 72 peut intégrer un pattern de variabilité de 15 type « Optional » pour un contexte « incendie ». La deuxième tâche est donc réalisée uniquement en présence d'un incendie ; - une troisième tâche 73 peut être « Activer tous les détecteurs de gaz ». La troisième tâche 73 peut intégrer un pattern de variabilité de type « optionnal » pour un contexte « explosion ». La troisième tâche 73 est 20 donc réalisée uniquement dans un contexte d'explosion. L'annotation « CONTEXT = Incendie » mentionne le contexte impactant la deuxième tâche « Activer tous les détecteurs de fumées » 72. L'annotation « CONTEXT = explosion » mentionne le contexte impactant la troisième tâche « Activer tous les détecteurs de gaz » 73. 25 La figure 7 présente un exemple de variabilité dans un flux de messages entre différents participants 1, 3, 80 à un processus-métier. Par exemple, le système, ou le participant, de la brigade des pompiers 1 peut effectuer notamment une tâche ou un sous processus « mission éteindre le 30 feu » 68. Un système de gestion de ressources internes 80, par exemple d'un aéroport, peut effectuer notamment une tâche ou un sous processus « mission dégager les obstacles » 84. Le système de gestion d'hôpital 3 peut effectuer une « mission de soins médicaux » 83. La tâche « éteindre le feu » 68 peut être exécutée en premier. Ensuite la tâche à exécuter peut être : soit 35 la tâche « dégager des obstacles » 84 dans le cas où des victimes sont bloquées dans l'engin correspondant au contexte « Obstacles », soit la tâche « soins médicaux » 83 dans le cas contraire correspondant au contexte « Pas d'obstacles ». Les deux flux 85, 87 partants de la tâche « éteindre le feu » 68 respectivement vers les deux tâches « dégager des obstacles » 84 et « soins médicaux » 83 peuvent être annotés avec le pattern de variabilité « optionnal ». Le pattern de variabilité peut se décliner suivant le contexte en « Obstacles » pour le premier flux 85 et en « Pas d'obstacles » pour le deuxième flux 87. Le contenu de ces deux flux varie en fonction du contexte. Dans le cas du contexte « obstacles » il contient la localisation des obstacles et dans le cas du contexte « pas d'obstacle » il contient la description de l'état des victimes. Après la tâche « dégager des obstacles » 84, la tâche « soins médicaux » 83 est accomplie quelque soit le contexte. La variabilité d'un flux de messages peut se traduire aussi par une variabilité du contenu du message envoyé. La figure 8 représente un exemple de variabilité dans les participants à la gestion de la résolution de la crise. La figure 8 montre notamment l'impact d'un contexte sur la variabilité des participants. Les participants peuvent être des systèmes prenant part à la résolution de la crise. Selon le contexte et son évolution une même tâche peut nécessiter l'intervention de plusieurs participants. La figure 8 représente pour l'exemple un quatrième modèle 900 comportant trois participants concrets 1, 2, 80 : une brigade de pompiers 1, une cellule de crise 2, des ressources internes 80. Lorsque la cellule de crise 2 effectue une tâche de demande d'intervention aux pompiers 92, par exemple en cas d'incendie, alors elle transmet un rapport de mission 93. Par exemple, la tâche « Mission éteindre feu » 91 nécessite au début de l'incendie, c'est à dire dans un contexte de « Petit Incendie » 95, une intervention des ressources internes de l'aéroport 80. En cas d'aggravation de l'incendie le contexte devient « Important Incendie » 96. La même tâche « Mission éteindre feu » 91 nécessite alors aussi une intervention de la brigade des pompiers 1. Le quatrième modèle 900 peut comprendre un participant abstrait « Participant à la mission » 90. Le participant abstrait peut par principe être substitué soit aux ressources internes 80 soit à la brigade des pompiers 1, soit à la fois aux ressources internes 80 et à la brigade des pompiers 1. Pour cela, le participant abstrait 90 est annoté avec un pattern de variabilité de type « Inclusive Choice » 94 et les participants concrets sont alors déterminés suivant le contexte : le participant « Ressources interne » 80 dans le contexte « Petit Incendie » 95 et le participant « Brigade de pompiers » 1 dans le contexte « Important Incendie » 96. Un pattern de type « default » 98 peut également annoter un des participants concrets, afin de choisir le participant par défaut dans le cas où le contexte ne serait pas connu. La figure 9 représente un exemple de variabilité de type configurable. La figure 9 donne un exemple d'utilisation du pattern de variabilité « Configurable » 100. Le pattern «Configurable » 100 permet de spécifier par exemple un sous processus « Constitution des équipes sur site » 101 utilisé pour la constitution d'une équipe afin de faire face à une situation de crise donnée. Le pattern de variabilité « Configurable » 100 permet d'éviter une complexité d'un cinquième modèle 108 pour le sous processus « Constitution des équipes sur site » 101 telle que la complexité des modèles représentés sur les figures 2 et 3. Le pattern de variabilité « Configurable » 100 permet de spécifier des tâches sans spécifier de relation entre elles ni d'ordre particulier d'exécution. Les interactions entres les tâches ainsi que leur ordre d'exécution peuvent être spécifiés par des règles contextuelles. Les règles contextuelles peuvent être introduites dans un modèle via des annotations de type « Configurable » 100 attachées aux sous processus du modèle. La figure 9 illustre une annotation par le pattern « Configurable » 100 en utilisant par exemple une règle contextuelle « RULE » s'intitulant par exemple RI. Afin de pouvoir référencer les tâches variables du sous processus « Constitution des équipes sur site » 101 dans des règles, un identifiant propre leur est attribué. Par exemple, une tâche « prévenir la gendarmerie » 102 peut avoir un identifiant « ID » valant « gendarmerie ». De la même manière et par exemple : - une tâche « prévenir les ressources internes » 103 a pour identifiant « ressources » ; - une tâche « prévenir les passagers » 104 a pour identifiant « passagers » ; - une tâche « prévenir la police » 105 a pour identifiant « police » ; - une tâche « prévenir les pompiers » 106 a pour identifiant « pompiers » ; - une tâche « prévenir les hôpitaux » 107 a pour identifiant « hôpitaux ». La règle RI elle même peut être spécifiée de manière déclarative par les lignes suivantes : « Ligne 1 - "Attaque chimique" : "gendarmerie" Ligne 2 - "Explosion" : Parallel("passagers "," police") Ligne 3 - "Dégâts humains" : Sequence("ressources","hôpitaux") Ligne 4 - "Fin de la crise" : Exit » Le format des règles de contexte peut être un n-uplet décrit par exemple selon la forme Backus-Naur suivante : " :" 1 "(" ")" {"," "(" ")"}*. La forme Backus-Naur est une notation permettant de décrire des règles syntaxiques pour des langages de programmation, c'est un métalangage. La « Ligne 1 » est un couple (contexte, tâche(id)) indiquant que : si le contexte «Attaque chimique» est vérifié alors la tâche dont l'identifiant est «gendarmerie » est exécutée. Dans l'exemple de la ligne 1 ci-dessus, c'est la tâche « prévenir la gendarmerie ». La « Ligne 2 » est un couple de (contexte, pattern(tâches)). Le pattern utilisé dans la « Ligne 2 » est le pattern « Parallel » qui déclenche l'exécution de deux tâches en parallèle : « prévenir les passagers » et « prévenir la police » en cas de contexte « Explosion ». La « Ligne 3 » répond au même principe de rédaction que la « Ligne 2 ». Le pattern « Sequence » exécute deux tâches séquentiellement dans l'ordre mentionné : d'abord s'exécute la tâche « prévenir les ressources » puis la tâche « prévenir les hôpitaux ». La « Ligne 4 » spécifie une dépendance à une durée de vie du sous processus « Constitution des équipes sur site » 101 en fonction du contexte : La constitution des équipes sur site est un processus continu et s'exécutant jusqu'à la fin de la crise. La fin de la crise entraine une sortie du processus, notée « Exit ». Les annotations liées aux patterns décrits ci-avant peuvent être implémentés à l'aide de la plupart des environnements de modélisation de processus métiers existants. Les figures 10, 11 a, 11 b et 12 représentent l'invention proprement dite. Alors que les figures 5, 6, 7, 8, 9 représentent la partie méthodologique, ou le procédé, proposée par l'invention, les figures 10, 11 a, 11 b et 12 représentent la partie dispositif de l'invention. La figure 10 représente un schéma d'une première architecture 420 du dispositif selon l'invention. Cette architecture permet de capturer les changements dynamiques dans le contexte, de configurer les processus métier en temps réel suivant le contexte courant 47, de générer les adaptations à faire sur l'architecture technique du système complexe et de le migrer vers sa nouvelle architecture technique. La figure 10 représente notamment des composantes architecturales 40 d'une gestion de variabilité de processus métiers en fonction d'un contexte et des composantes architecturales 49 d'une gestion de l'impact de cette variabilité sur l'architecture des services selon l'invention. La figure 10 représente également une architecture de services 41 offerts par des systèmes composants un système complexe 405 ainsi que les interactions entre les différents systèmes. Pour l'exemple, le système complexe 405 comporte des systèmes suivants : - un premier système 406 de détection d'alertes ; - un deuxième système 407 de gestion d'alertes ; - un troisième système 408 d'aide à la décision ; - un quatrième système 409 de gestion de crise ; - un cinquième système 410 de tableau de bord ; - un sixième système 411 de gestion des hôpitaux ; - un septième système 412 de gestion des pompiers ; L'ensemble des systèmes 406, 407, 408, 409, 410, 411, 412 du système complexe 405 est relié à un même réseau 413. Les différents systèmes peuvent par exemple être reliés à un même bus par exemple un bus utilisant une technologie ESB. ESB est un acronyme pour l'expression anglo-saxonne Enterprise Service Bus, signifiant littéralement Bus de Service Entreprise. La technologie ESB permet d'établir une communication entre des applications de systèmes hétérogènes, n'étant pas réalisées pour communiquer entre elles. L'architecture 40 de gestion de la variabilité de processus métier en fonction du contexte comporte un gestionnaire de contexte 42. Le gestionnaire de contexte est une application informatique apte à être mise en oeuvre par un ordinateur. Le gestionnaire de contexte 42 collecte des informations de contexte 43 provenant de différents capteurs de contexte 44. Des capteurs de contextes peuvent être par exemple : des capteurs de chaleur, des caméras de vidéo mobiles ou fixes, des détecteurs de localisation. Les différents capteurs 44 sont distribués sur un réseau et publient les informations de contexte 45 qu'ils génèrent sur un « middleware » orienté message 46, middleware étant une expression anglo-saxonne désignant un logiciel médiateur ou interface. Le gestionnaire de contexte 42 permet d'agréger et d'interpréter des informations de contexte pour en déduire une définition d'un contexte courant 47. Une interprétation de contexte permet de définir un contexte plus significatif à partir des informations brutes envoyées par les capteurs. A titre d'exemple, les cordonnées GPS sur la position d'un agent de sécurité dans l'aéroport forment son contexte brut envoyé par le capteur GPS de son téléphone portable. Un gestionnaire de contexte peut interpréter ces cordonnées GPS pour fournir un contexte plus significatif comme par exemple la position de l'agent sur une carte réelle ou synthétique de l'aéroport. Le gestionnaire de contexte 42 peut mettre en oeuvre des mécanismes de collecte, d'agrégation et d'interprétation de contexte tel que décrits par A.K. Dey, G.D. Abowd, et D. Salber dans « A conceptual framework and toolkit for supporting the rapid prototyping of context-aware applications » de « Human-computer Interaction,16(2-4 (special issue on context-aware computing)) : 97-166, December 2001)), et par Davy Preuveneers, Yolande Berbers dans « Adaptive context management using a component-based approach » de « Proceedings of the 5th Ifip International Conference on Distributed Applications and Interoperable Systems, DAIS 2005, pages 14-26, vol 3543, June 2005, Athens, Greece ». Par exemple, le gestionnaire de contexte 42 peut agréger des informations de contexte collectées par un ensemble de détecteurs de feu. Le gestionnaire de contexte 42 peut déduire des informations de contexte agrégées qu'une explosion a eu lieu dans une zone bien déterminée d'un aéroport, par exemple. Le contexte 47 fourni par le gestionnaire de contexte 42 peut être mis à disposition d'un raisonneur 48. Le raisonneur 48 est une application informatique apte à être mise en oeuvre par un ordinateur. Le raisonneur 48 prend en entrée un modèle 49 de processus métiers enrichi d'éléments permettant d'exprimer la variabilité du système complexe en fonction du contexte. Le raisonneur 48 détermine, à partir du contexte 47 et du modèle 49 de processus métiers, le processus le mieux adapté au contexte courant 47. Le raisonneur 48 produit un troisième modèle de processus 400 adapté au contexte courant 47. Le troisième modèle de processus 400 est ensuite utilisé comme donnée d'entrée d'un générateur de processus métier exécutable 401. Le générateur de processus métier exécutable 401, génère un code exécutable qui implémente le processus qui orchestre les services offerts par un système complexe qui est un processus métier exécutable 402. Le processus métier exécutable contient la description de l'architecture technique du système complexe ç.à.d. la description des services fournis par les sous systèmes, les données échangées et les traitements à faire. Le processus métier exécutable peut être mis en oeuvre par un logiciel appelé orchestrateur ou moteur d'orchestration. Le générateur de processus métier 401 peut par exemple réaliser une transformation d'un modèle décrit selon le standard BPMN en un exécutable généré selon un format standard BPEL. BPEL est un acronyme pour l'expression anglo-saxonne Business Process Execution Langage signifiant langage d'exécution des processus métier. Une méthode de transformation d'un modèle BPMN en exécutable BPEL est notamment décrite dans le document « Business Process Modeling Notation (BPMN) Version 1.2, OMG Document Number: formal/2009-01-03 Standard document » p. 143. Le processus métier exécutable 402 correspondant au contexte courant 47 est ensuite fourni à un adaptateur d'orchestration 403. L'adaptateur d'orchestration 403 a pour rôle de mettre en place le processus métier exécutable 402. Cette mise en place se fait en migrant le processus métier exécutable en cours d'exécution 404 vers le processus métier exécutable 402 adéquat avec le contexte courant 47. Donc, en plus de fonctionnalités d'orchestration usuelles entre différents systèmes ou sous systèmes, le composant adaptateur d'orchestration 403 comporte des fonctionnalités lui permettant de remplacer un processus en cours d'exécution par un autre, tout en prenant en compte un état d'un précédent processus exécutable 404, ledit précédent processus exécutable 404 étant en cours d'exécution. L'adaptateur d'orchestration 403 a donc pour rôle d'orchestrer les différents systèmes 406, 407, 408, 409, 410, 411, 412 composant le système complexe 405. Le système complexe 405 ayant une architecture basée sur sa composition avec les systèmes indépendants 406, 407, 408, 409, 410, 411, 412. Les figures 11 a et 11 b représentent des exemples de modèles de sous-processus présentés selon le standard BPMN. Les figures 11 a et 11 b représentent respectivement le résultat de l'adaptation par le raisonneur 48 du modèle de processus variable représenté sur la figure 6 dans les deux contextes respectifs « Incendie » et « Explosion ». L'environnement de modélisation utilisé par le procédé selon l'invention peut permettre de stocker des spécifications de processus métier avec leurs annotations. Un des exemples de format de stockage dans une base de données est le format XML, XML étant un acronyme pour eXtensible Markup Langage, signifiant langage à balises extensible. Une annexe 1 donne un exemple d'un premier fichier de code XML généré pour décrire la variabilité du sous processus métier « Activation dynamique des capteurs » 70. Au moment de l'exécution, le raisonneur 48 représenté sur la figure 10, peut utiliser en entrée : - des informations de contexte collectées et agrégées, transmises par le gestionnaire de contexte 42, sous la forme d'une instance du modèle de contexte représenté sur la figure 4 par exemple. - le modèle de processus métier 49, annoté avec les différents patterns de variabilité en fonction du contexte tels qu'ils ont été illustrés dans les 25 figures 6, 7, 8 et 9, sous la forme du premier fichier de code XML de l'annexe 1 par exemple. Le raisonneur 48 effectue une analyse syntaxique du premier fichier de code XML. Pour chaque annotation trouvée, le raisonneur 48 vérifie que l'information de contexte mentionnée dans le premier fichier de code XML est 30 valide en se basant sur le contexte fourni par le gestionnaire de contexte 42. Quand c'est le cas, le raisonneur 48 interprète le pattern utilisé dans l'annotation et génère au fur et à mesure de cette lecture un deuxième fichier de code contenant le processus métier adapté au contexte courant au format XML par exemple. L'annexe 2 présente, à titre d'exemple, le deuxième fichier 35 de code XML représentant le processus métier adapté au contexte, généré par le raisonneur 48, à partir du processus métier variable représenté sur la figure 6 en cas d'un contexte « Incendie ». La figure 11a représente un septième modèle 74 du sous processus métier « Activation dynamique des capteurs » 70 sans variabilité associé au deuxième fichier XML, généré par le raisonneur 48 dans le cas d'un contexte « Incendie ». L'annexe 3 présente un exemple d'un troisième fichier de code XML du processus métier adapté au contexte, généré par le raisonneur 48 à partir du sous processus métier « Activation dynamique des capteurs » 70 dans le cas d'un contexte « Explosion ». La figure 11 b représente le modèle du sous processus métier « Activation dynamique des capteurs » 70 sans variabilité associé au troisième fichier de code XML figurant dans l'annexe 3. Le raisonneur 48 peut donc prendre en entrée le premier fichier de code XML de l'annexe 1 et les informations de contexte collectées. La suite décrit sur un exemple concret, un fonctionnement possible du raisonneur 48. Le raisonneur 48 interprète d'abord une première ligne suivante : @PATTERN= « Variable ». La première ligne indique que le sous processus est variable. Ensuite, le raisonneur 48 interprète le premier fichier de code XML ligne par ligne jusqu'à arriver à une deuxième ligne @PATTERN= «Optional», CONTEXT= « Incendie ». Le raisonneur 48 interprète la deuxième ligne comme une variabilité de type « Optional » et il vérifie que l'information de contexte est à « Incendie ». Le raisonneur 48 prend alors en compte les états suivants dans le deuxième fichier de code XML qu'il génère. Le raisonneur 48 continue à interpréter et recopier les lignes du premier fichier de code XML jusqu'à trouver une troisième ligne d'annotation suivante comportant l'annotation PATTERN= « Optional », CONTEXT= « Explosion ». L'information de contexte « Explosion » n'étant pas vérifiée, les lignes suivants la troisième ligne d'annotation PATTERN= « Optional », CONTEXT= « Explosion » ne sont pas recopiées dans le deuxième fichier de code XML généré par le raisonneur 48. Cela revient à remplacer dans le deuxième fichier de code XML généré la transition par la transition . Puisque l'état correspondant à la première transition est optionnel, le raisonneur 48 déduit que cette transition vers cet état est elle aussi optionnelle, la lettre g indiquant le positionnement graphique de l'élément. Un traitement selon le même principe est réalisé par le raisonneur 48 pour chacun des patterns de variabilité, à l'exception du pattern « Configurable ». Pour le pattern « Configurable », la gestion de la variabilité en fonction du contexte est gérée par des règles contextuelles. Dans ce cas, le raisonneur interprète au fur et à mesure les règles contextuelles, à chaque mise à jour du contexte et génère le code XML décrivant le processus métier en fonction des patterns de variabilité utilisés dans chaque règle métier. Le raisonneur peut utiliser plusieurs types d'algorithmes pour résoudre les systèmes de règles tels que l'algorithme de type RETE tel que décrit par Forgy, Ch. : "Rete: A Fast Algorithm for the Many Patterns/Many Objects Match Problem". Artif. Intell. 19(1): 17-37 (1982). En prenant par exemple la figure 9 qui représente le processus configurable « Constitution des équipes sur site » 101 avec une seule règle contextuelle de configuration RI. Supposons que seule l'information contextuelle « Dégâts humains » est disponible à l'exécution du système complexe, le raisonneur 48 interprète alors la règle qui dépend de cette information contextuelle à savoir RI et génère le code XML correspondant au pattern de variabilité associé à ce contexte à savoir Sequence("ressources","hôpitaux"). Le processus métier adapté au contexte, généré par le raisonneur sous la forme du deuxième fichier de code XML ou du troisième fichier de code XML est utilisé en entrée du composant générateur de processus métier exécutable 401 représenté sur la figure 10. Le générateur de processus métier exécutable 401 transforme le fichier de code XML adapté au contexte en un processus métier exécutable 402 tel que représenté sur la figure 10. L'annexe 4 décrit un exemple d'un premier fichier de code de processus métier exécutable au format standard BPEL. Le premier fichier de code de processus métier exécutable correspond au fichier généré à partir du deuxième fichier de code XML du processus métier adapté au contexte « Incendie ». L'annexe 5 décrit un exemple d'un deuxième fichier de code exécutable au format standard BPEL. Le deuxième fichier de code exécutable correspond au fichier généré à partir du troisième fichier de code XML du processus métier adapté au contexte « Explosion ». Le composant adaptateur d'orchestration 403 représenté sur la figure 4 utilise en entrée un fichier de code exécutable au format BPEL tel que le premier fichier BPEL décrit dans l'annexe 4 ou le deuxième fichier BPEL décrit dans l'annexe 5. Le composant adaptateur d'orchestration 403 effectue dans l'ordre les traitements suivants : - récupération de l'état d'exécution du processus exécutable 404 en cours d'exécution, l'état d'exécution du processus comportant l'état des tâches en cours d'exécution, les données transférées entre les tâches ou les branchements qui sont en cour d'évaluation. ~o ^ attente d'un état stable d'exécution du processus 404 exécutable, c'est à dire la fin des tâches en cours d'exécution, la fin du transfert des données en cours ou la fin de l'évaluation des branchements en cours. - Stopper le processus 404 en cours d'exécution une fois qu'il arrive à 15 un état stable, - instanciation du nouveau processus exécutable 402 adapté au contexte courant et généré par le générateur de processus métier exécutable 401 ; - lancement de l'exécution du nouveau processus exécutable 402 avec 20 prise en compte de l'état d'exécution du précédent processus exécutable 404, c'est à dire la tâche à partir de la quelle le nouveau processus 402 va démarrer, le contenu des données dont il va disposer lors de son lancement ; Les fonctionnalités d'orchestration de l'adaptateur d'orchestration 403 lui 25 permettant le lancement de l'exécution d'un processus exécutable peuvent être par exemple réalisés conformément à la spécification (Web Services Business Process Execution Language Version 2.0, OASIS Standard, 11 April 2007). La figure 12 représente un schéma d'une deuxième architecture 120 30 possible du dispositif selon l'invention. La deuxième architecture 120 reprend les composants de la première architecture 420, représentée sur la figure 10 à l'exception des composants suivants : - le raisonneur 48 ; - le générateur de processus métier exécutable 401 ; 35 - l'adaptateur d'orchestration 403. Le raisonneur 48 est remplacé dans la deuxième architecture 120 par un générateur de processus métier variable exécutable 121. Le générateur de processus métier exécutable 401 et l'adaptateur d'orchestration 403 sont remplacés dans la deuxième architecture 120 par un orchestrateur de processus métier variable exécutable 122. Le générateur de processus métier variable exécutable 121 utilise en entrée le modèle 49 de processus variable. Le modèle 49 peut par exemple se présenter sous la forme d'un modèle selon le standard BPMN annoté en fonction du contexte avec des patterns de variabilité. Le générateur de processus métier variable exécutable 122 transforme le modèle de processus variable 49 en un processus métier variable exécutable 123. Le processus métier variable exécutable 123 peut être écrit selon le standard BPEL par exemple et annoté en fonction du contexte avec des patterns de variabilité. Le processus métier variable exécutable 123 est ensuite pris en entrée de l'orchestrateur de processus métier variable exécutable 122. L'orchestrateur de processus métier variable exécutable 122 rempli à la fois les fonctions de raisonnement sur le contexte courant, et le déploiement des processus exécutables. En effet, l'orchestrateur de processus métier variable exécutable 122 prend en compte le contexte courant 47 afin de spécifier et de générer un processus métier variable exécutable en fonction du contexte courant 47. Le déploiement des processus exécutables est réalisé en parallèle avec une résolution de la variabilité des processus métier exécutables variables 122 en fonction du contexte disponible 47. Dans le cas de l'utilisation des standards BPMN et BPEL, l'orchestrateur de processus métier variable exécutable 122 peut être un moteur intelligent de « BPEL annoté avec une variabilité dépendante du contexte », qui déploie donc en fonction du contexte courant 47 des parties déterminables dans le fichier BPEL et ignore d'autres parties, et ceci en fonction des patterns de variabilité annotant ces parties. Le mécanisme qu'il utilise pour déterminer les parties du fichier BPEL pertinentes en fonction du contexte courant est le même que le mécanisme utilisé par le raisonneur pour construire le troisième modèle de processus métier 400 représenté sur la figure 10. L'avantage de la deuxième architecture 120 est qu'elle permet une prise en compte du contexte la plus tardive possible dans la génération du processus exécutable, ce qui permet d'avoir un impact à la fois rapide et fonction du contexte le plus récent, sur l'architecture technique 405 représentée sur la figure 10. Le dispositif selon l'invention peut être utilisé pour adapter différents types 5 d'architectures complexes, par exemple : - pour des systèmes ubiquitaires, mobiles, ambiants ou pervasifs, c'est-à-dire se diffusant à travers toutes les parties du système d'information : ces systèmes se basent sur des dispositifs de traitement en réseau, intégrés et distribués dans toute l'étendue de la 10 vie quotidienne, orientés vers les applications courantes. Ces systèmes donnent la capacité pour l'utilisateur « d'interagir (activement ou passivement), n'importe où, avec une multitude d'appareils interconnectés, de capteurs, d'activateurs, et plus globalement avec les systèmes électroniques « enfouis » autour de 15 lui ». Par exemple, un système de surveillance de vieilles personnes chez elles qui utilise des RFIDs (Radio Frequency Identification) et qui fait automatiquement des appels à des services comme des services d'urgences en fonction de leurs états et situations. Un autre exemple, « un système ubiquitaire domestique qui peut relier tous les contrôles 20 de l'éclairage et de l'environnement avec des capteurs biométriques individuels pour moduler en conséquence l'éclairage et le chauffage dans une chambre » ; - dans le cadre de « smart cities », « cyber cities » ou villes intelligentes. Une ville intelligente est une future ville qui fournit de 25 diverses technologies multiples intelligemment intégrées pour fournir des applications sans couture et des services avancés et intelligents sur différents réseaux d'accès. L'objectif de villes intelligentes est d'améliorer la qualité de vie dans les villes et catalyser le développement économique en intégrant une diversité de services de 30 différents champs tels que la protection et sécurité, la santé, l'éducation, le transport, le trafic comme par exemple les systèmes intelligents du trafic et les conseils piétonniers ou la gestion d'autres services publics tels que l'eau, l'énergie et l'environnement. L'objectif ultime des villes intelligentes est de fournir une meilleure manière de vivre à la communauté en rendant des services disponibles à chacun n'importe où à tout moment ; - les systèmes de transport intelligents sont par exemple des systèmes qui peuvent être offerts dans le cadre d'une ville intelligente. Les voyageurs peuvent employer divers services installés sur leurs terminaux mobiles ou une composition de services distants avant et pendant leurs voyages. Ces services peuvent faire intervenir plusieurs opérateurs tels que des banques (pour le paiement de leurs voyages), des compagnies de ligne ferroviaires ou aériennes, des opérateurs de services de voyages, des opérateurs de circulation routière, des opérateurs de métros, autobus, tramways, des aéroports, des compagnies de taxi, la police ou des pompiers et les services de météo. Les voyageurs peuvent utiliser plusieurs types d'appareils mobiles pour accéder à ces services. Plusieurs types d'événements imprévisibles peuvent apparaître pendant leurs voyages tels que des accidents bloquants le trafic ferroviaire ou routier ou des imprévisions météo comme la neige. Si l'itinéraire des voyageurs ne leur permet pas d'accomplir leurs objectifs après ces événements, alors de nouvelles possibilités doivent être évaluées afin de rajuster leur itinéraire. Un changement de l'itinéraire de voyageurs peut en résulter un changement de la composition des services utilisée ; - les situations tactiques militaires comme ceux de crises sont imprévisibles et dynamiques et nécessitent une compréhension rapide de la situation de bataille et de ses conséquences. Leur gestion consiste à créer rapidement une organisation qui peut commander la situation. Les technologies permettent de gérer automatiquement la variabilité des processus métier en se basant sur des capteurs localisant par exemple des chars, des bateaux ou des combattants et ayant la capacité de manipuler des situations dynamiques sont donc extrêmement utiles dans ce domaine. - pour des systèmes adaptatifs : ces systèmes sont de plusieurs types. Ils peuvent être évolutifs comme un système d'information sécurisé qui peut s'auto-adapter afin de diminuer des risques potentiellement encourus par le système suite à une intrusion illégale comme ils peuvent représenter un sous type de systèmes mobiles tel qu'une application utilisée sur différents terminaux mobiles qui varie par exemple en fonction de la taille de leurs écrans, de leurs systèmes d'exploitation ou de la mémoire qu'ils embarquent. Ils peuvent représenter aussi un sous type de systèmes autonomes comme une application de supervision d'infrastructures réseaux. Avantageusement, le système selon l'invention permet une adaptation dynamique d'un système complexe en fonction de son 10 environnement ou d'un événement particulier. Le dispositif selon l'invention permet d'adapter un système complexe au niveau de ses processus métier et de son architecture de services en fonction des variations dynamiques dans son contexte et son environnement. Ainsi, la variabilité est prise en compte de manière automatique à plusieurs 15 niveaux de conception du système : en partant du niveau des processus métiers définis par les utilisateurs opérationnels du système, en passant par l'architecture du système, et jusqu'au système exécutable lui-même. Avantageusement, la modélisation de la variabilité utilisée par le dispositif selon l'invention permet de rendre compréhensible et modifiable par des 20 utilisateurs n'étant pas spécialistes en programmation, les modèles de processus variables. Par exemple des experts métier peuvent facilement faire évoluer leurs modèles de processus variables en ajoutant ou modifiant des patterns de variabilité en fonction du contexte. Les modifications effectuées sur le modèle de variabilité du système peuvent ainsi être 25 automatiquement prises en compte pour générer une nouvelle composition du système ainsi que le code logiciel qui permet de déployer cette nouvelle composition du système. Avantageusement, l'architecture proposée par le dispositif selon l'invention permet de raisonner sur des informations de contexte et de déterminer 30 automatiquement un processus métier s'adaptant au mieux au contexte. Grâce au dispositif selon l'invention, des changements dynamiques de processus métier peuvent être modifiés à chaud en cours d'exécution sur la couche architecturale des sous-systèmes composant le système complexe, en modifiant leur assemblage ainsi que leur orchestration. Avantageusement, le dispositif selon l'invention est accompagné d'une méthodologie qui permet de modéliser des processus métier variables en fonction du contexte. Avantageusement la méthodologie proposée permet de réduire la complexité de la modélisation des processus métier et de pouvoir utiliser le dispositif selon l'invention pour aboutir à la génération d'un code qui compose l'application de manière qu'elle s'adapte au contexte. Le fait que l'invention soit basée sur une approche dirigée par les modèles permet de générer un code exécutable qui orchestre les services offerts par un système à partir d'un processus métier. Ainsi les processus métier, l'architecture et le code des sous-systèmes sont mis au même niveau par rapport à la prise en compte de la variabilité des processus métier. Ainsi la couche abstraite relative au métier est liée avec les couches techniques des sous-systèmes. Avantageusement, la méthodologie accompagnant l'architecture selon l'invention définit des patterns de modélisation des processus métier variables permettant d'une part d'étudier et d'analyser l'impact d'un changement de contexte sur un processus métier et d'autre part de réduire la complexité des processus métier. Avantageusement la variabilité est gérée à un niveau abstrait très proche de l'utilisateur final : celui des processus métiers. Ainsi il est beaucoup plus simple pour un utilisateur de définir ses processus métiers et de maîtriser leur prise en compte par les différents sous-systèmes du système complexe. Avantageusement, le dispositif selon l'invention permet de gérer la variabilité du contexte et l'adaptation du système d'abstraction et de répercuter étape par étape sur l'architecture technique du système de plus bas niveau la variabilité et l'adaptation du système. Ainsi, toute variation au niveau stratégique et métier peut être prise en compte avec des solutions techniques appropriées dérivant directement des variations prises en compte à haut niveau d'abstraction. Le dispositif selon l'invention permet ainsi de gérer la variabilité et l'adaptation à différents niveaux d'abstraction. Ceci permet de plus une traçabilité de la variabilité entre les différents niveaux de conception des systèmes : depuis le niveau processus métier, vers le niveau architectural et jusqu'au code applicatif. La traçabilité est assurée grâce à la transformation automatique des processus métiers.35 ANNEXES Annexe 1 : Code XML d'un processus métier variable @PATTERN= « Variable » @PATTERN=« Optional», CONTEXT= « Incendie » @PATTERN= « Optional », CONTEXT= « Explosion » Annexe 2 : Code XML sans variabilité généré par le raisonneur 48 dans le cas du contexte « Incendie » Annexe 3 : Code XML sans variabilité généré par le raisonneur 48 dans le cas du contexte « Explosion » Annexe 4: Code BPEL généré par le générateur de processus métier exécutable 401 et correspondant au code XML de l'annexe 2 Annexe 5 : Code BPEL généré par le générateur de processus métier exécutable 401 et correspondant au code XML de l'annexe 3 REVENDICATIONS1. Dispositif d'adaptation dynamique d'un système complexe (405) à différents contextes d'utilisation du système complexe (405), ledit système complexe (405) comportant un ensemble de sous-systèmes hétérogènes (406, 407, 408, 409, 410, 411, 412) interagissant, un contexte étant défini par un ensemble de données caractérisant une situation particulière à laquelle est soumis le système complexe, caractérisé en ce que ledit dispositif effectue une orchestration des sous-systèmes (406, 407, 408, 409, 410, 411, 412) en exécutant des processus métier adaptés automatiquement par ledit dispositif à un contexte courant (47), ledit dispositif prenant en entrée un modèle de processus métier variable en fonction du contexte (49), un processus métier étant une succession de tâches à réaliser par les sous-systèmes (406, 407, 408, 409, 410, 411, 412) dans le cadre d'une procédure propre à un domaine technique, le contexte courant (47) étant un ensemble de données caractérisant la situation particulière à un instant donné ; ledit dispositif réalisant en outre un remplacement d'un processus en cours d'exécution (404) par le processus métier adapté automatiquement au contexte courant (402), tout en prenant en compte un état de fonctionnement du processus en cours d'exécution (404). 2. Dispositif selon la revendication 1, caractérisé en ce qu'il comporte un premier composant (42) effectuant une gestion centralisée des données de contexte (45). 3. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que le contexte courant (47) est un contexte de haut niveau qui comporte une interprétation d'un ensemble de données de contextes de bas niveau provenant de capteurs et d'autres types de sources, et 3o collecteurs de contexte. 4. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte : - un deuxième composant (48) prenant en entrée : les données de contexte 35 fournies par le premier composant (42) et le modèle de processus métier variable (49), ledit deuxième composant déterminant en fonction du contextecourant les tâches composant le processus métier, générant un modèle de processus métier adapté au contexte courant (400) ; - un troisième composant (401) prenant en entrée le modèle de processus métier adapté au contexte courant (400) pour générer un processus métier 5 exécutable (402) ; - un quatrième composant (403) utilisant en entrée un processus métier exécutable (402), orchestrant les sous-systèmes pour la réalisation du processus métier exécutable. 10 5. Dispositif selon la revendication 4, caractérisé en ce que le quatrième composant (403) remplace le processus métier en cours d'exécution (404) par un nouveau processus métier exécutable (402) sur un changement de contexte (45). 15 6. Dispositif selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte : - un cinquième composant (121) prenant en entrée le modèle de processus métier variable (49), générant un processus métier variable exécutable (123) ; 20 - un sixième composant (122) prenant en entrée le processus métier variable exécutable (123), les données de contexte fournies par le premier composant (42), générant un processus métier variable exécutable en fonction du contexte courant (47), résolvant les variabilités des processus métier en fonction du contexte courant (47), orchestrant les sous-systèmes 25 pour la réalisation du processus métier exécutable. 7. Dispositif selon l'une quelconque des revendications 3 à 6 caractérisé en ce que les capteurs et les sources de contexte sont répartis dans un théâtre d'opérations. 8. Procédé d'adaptation dynamique d'un système complexe à différents contextes d'utilisation du système complexe, ledit système complexe comportant un ensemble de sous-systèmes hétérogènes interagissant, un contexte étant défini par un ensemble de données caractérisant une situation 30particulière à laquelle est soumis le système complexe, caractérisé en ce qu'il comporte au moins les étapes suivantes : - génération d'un modèle de processus métier adapté au contexte (400) courant en fonction d'un modèle variable de processus métier (49) et de 5 données du contexte courant (47) ; - génération d'un processus métier exécutable (402) à partir du modèle de processus métier adapté au contexte (400) ; - remplacement d'un processus en cours d'exécution (404) par le processus métier exécutable (402), en prenant en compte un état du processus en 10 cours d'exécution (404) ; - orchestration des sous-systèmes (406, 407, 408, 409, 410, 411, 412) pour la réalisation du processus métier exécutable (402). 9. Procédé d'adaptation dynamique d'un système complexe à différents 15 contextes d'utilisation du système complexe, ledit système complexe comportant un ensemble de sous-systèmes hétérogènes interagissant, un contexte étant défini par un ensemble de données caractérisant une situation particulière à laquelle est soumis le système complexe, caractérisé en ce qu'il comporte au moins les étapes suivantes : 20 - génération d'un processus métier variable exécutable (123) en fonction d'un modèle variable de processus métier (49) ; - remplacement d'un processus en cours d'exécution (404) par le processus métier exécutable (402), en prenant en compte un état du processus en cours d'exécution (404) ; 25 - orchestration des sous-systèmes (406, 407, 408, 409, 410, 411, 412) pour la réalisation du processus métier (49), en prenant en compte le processus métier variable exécutable (123) et les données de contexte courant (47). 30