La transformation d’information en connaissances

Détecter une ou plusieurs divergences entre les modèles de la situation collaborative n’est pas suffisant pour savoir (i) si une adaptation des workflows ou processus est né- cessaire, (ii) à quel niveau cette adaptation doit avoir lieu et à quelle profondeur. Il faut connaître la nature de ces divergences pour pouvoir les identifier (source de la diver- gence), les classer (laquelle a le plus d’impact sur la collaboration). En effet, savoir que le nombre de véhicules sanitaires légers acheminés sur le terrain n’est pas le même que celui attendu (eût égard au processus de réponse à la crise) ne nous renseigne que sur l’existence de la divergence.

Savoir si le nombre réel de véhicules disponibles est supérieur ou inférieur au nombre attendu peut modifier le comportement de la cellule de crise et l’adaptation des work- flows : dans un cas il y a pénurie, dans l’autre excédent. Dans un cas, on cherchera à trouver des solutions alternatives (faire faire des allers-retours aux véhicules, appeler des renforts, etc.), dans l’autre, on pourra remettre en jeu ces ressources excédentaires.

Pour cela, il faut introduire la notion de coût d’une divergence suivant deux axes : • Sa nature : s’agit-il d’une suppression ? D’un ajout ? D’une modification ? Par

exemple : suppression d’un acteur de la cellule de crise, ajout de nouvelles com- pétences pour un acteur de la cellule de crise, modification d’un risque.

• Sa gravité : il s’agit de qualifier plus finement la divergence. Il paraît en effet évident que l’ajout d’un risque « état grippal » est moins important que l’ajout d’un risque « état grave » à nombre d’individus concernés égal. Il faut arriver à traduire une classification des instances des classes du modèle de la situation collaborative.

Si nous nous tournons vers le domaine de la gestion de projet, nous pouvons nous apercevoir qu’elle intervient alors pour contrôler la continuité des objectifs. Lorsqu’il y a dérive, elle développe les actions d’ajustement en réaction aux changements ou risques avérés. La notion de risque est donc naturellement présente dans tout projet et la gestion des risques va de pair avec la gestion de projet.

tique de la fréquence et de l’importance des dommages d’un risque. De nombreux travaux et normes s’attachent à la phase d’identification des risques, tels que ceux de [Smith, 2007], [ISO, 2009] et [Hopkin, 2010]. Le but de cette phase est d’énumérer les risques du projet : elle constitue une tâche d’extrapolation car il faut anticiper et imaginer les risques que le projet peut être amené à traverser du fait de sa nature et de son environ- nement. Cette activité nécessite donc la présence d’experts-projet capables de disposer d’une vision globale quant aux données relatives aux sources de risques (les composantes du projet).

Un outil classique de la gestion des risques est la matrice de criticité. La criticité est définie comme le produit de la probabilité d’occurrence d’un accident par la gravité de ses conséquences :

Formule 2 Criticité = Probabilité × Gravité

Une explication plus détaillée de la matrice de criticité est disponible en Annexe D.

II.3 Conclusion

L’étude bibliographique par rapport à l’objectif nous a amené à définir la notion d’agilité en nous appuyant sur différents domaines tels que la gestion de chaines d’ap- provisionnement, la gestion de systèmes d’informations, etc. Les contraintes dues au contexte particulier qu’est la réponse à la situation de crise nous ont tout naturelle- ment amenées à positionner l’adaptation des processus collaboratifs par rapport à une approche de conception ad-hoc.

La connaissance du contexte de la collaboration est essentielle pour suivre les évo- lutions du théâtre de la collaboration et de la collaboration elle-même. Il est crucial de pouvoir collecter toutes les données pertinentes qui peuvent traduire un changement dans la caractérisation de la situation collaborative. L’EDA répond à ce besoin en pro- posant tout d’abord une collecte des données intelligente via le principe d’abonnement aux événements puis en permettant la mise en place d’un CEP. Ce CEP permet de découvrir les événements complexes, par déduction, analyse et corrélation d’événements élémentaires.

Etant donné la volumétrie des données récupérées, l’EDA convient parfaitement pour cette fonction en permettant un pré-tri au moment de la collecte elle-même puis la possibilité de filtrer les événements recueillis via le CEP. Ce CEP va filtrer, transformer et reconnaître des motifs d’événements par le biais de règles métiers. Les événements sortants (émis par le CEP) serviront à mettre à jour les modèles terrain et attendu. Après comparaison des solutions existantes, Esper dans sa version open source et gratuite est le CEP retenu pour ces travaux de thèse.

L’étude des moyens de mise en œuvre de l’agilité des processus dans la Section II.1 a mis en valeur le besoin de transformer les données issues des modèles terrain et attendu

en information permettant de conclure à un besoin d’adaptation —et le cas échéant à son amplitude—. Ce besoin est traduit par la comparaison des modèles terrain et attendu qui sont au format XML. Le choix d’un outil capable de supporter cette fonctionnalité doit répondre aux exigences suivantes :

• Structure

— Pouvoir tirer parti de la nature d’un document XML : comparer les nœuds entre eux, ne pas effectuer un traitement ligne à ligne,

— Ne pas tenir compte de l’ordre des nœuds dans une même branche : seule la distance par rapport à la racine compte.

• Contenu

— Pouvoir accéder facilement au contenu du fichier δ,

— Détailler la différence trouvée entre les deux modèles : sur quel aspect du modèle porte la différence, quels sont les attributs impactés, etc.

Nous pouvons en conclure que seul l’algorithme de XMLUnit répondait à la plupart de nos exigences.

Si le résultat de la comparaison entre les modèles terrain et attendu permet de don- ner une photographie globale de la divergence entre les modèles, cela n’est pas suffisant pour décider puis choisir l’adaptation des processus collaboratifs à mener. Il faut ana- lyser chaque instance concernée par la divergence afin qu’il soit possible de déterminer (i) l’existence d’un besoin d’adaptation des processus collaboratifs, (ii) l’amplitude de l’adaptation à mener le cas échéant. Cette analyse peut être menée dans le même esprit que les principes de gestion des risques en projet. L’évolution étant avérée, il ne s’agit pas de la prévenir et de mener des actions préventives mais plutôt de l’intégrer dans la réalité de la situation collaborative et d’en déduire les actions correctives à mener si nécessaire. Si la gestion des risques permet d’évaluer notamment la probabilité de la survenue d’un risque et sa gravité, dans notre cas il s’agit plutôt de définir l’impact d’une instance et son poids dans la prise de décision. A cette fin, nous introduisons :

• La notion d’opération qui permet de qualifier la nature de la divergence : ajout, suppression ou modification d’une instance entre les modèles terrain et attendu de la situation collaborative.

• La notion de concept, qui permet de déterminer la classe à laquelle l’instance appartient : acteur, service, risque, etc.

Pour chacune des instances, le croisement de ces informations permet de déterminer sa criticité pour la pérennité de la situation collaborative et donc son poids dans la décision finale d’adaptation. Le classement des instances suivant les axes opérations et

concepts est matérialisé par une matrice. Cette matrice est définie lors de la conception

des processus collaboratifs par des experts métier. Elle devra pouvoir évoluer au cours du cycle de vie des processus collaboratifs afin de pouvoir corriger des erreurs d’appréciation ou de mieux refléter le domaine métier ou la réalité du terrain.

Mise à jour des modèles :

Détection (partie 1)

La détection est une des quatre composantes de l’agilité telle que nous l’avons définie dans le Chapitre II (détection, adaptation, réactivité et efficacité) et l’une des trois que nous conservons dans ces travaux. Cependant, avant de pouvoir détecter quoi que ce soit, il faut définir l’objet sur lequel porte la détection : son périmètre, ses caractéristiques. Afin de répondre à nos exigences de suivi de l’évolution de la situation collaborative, il faut également permettre le recueil et le traitement des données pertinentes tout au long du cycle de vie de la collaboration (voir Figure III.1).

FigureIII.1 – Architecture simplifiée du Service d’Agilité et périmètre de l’étude dans le Chapitre III

Le présent chapitre vise à expliquer d’une part le modèle de la situation collaborative sur lequel la détection va s’effectuer, d’autre part les mécanismes de mise à jour de ce modèle afin de suivre en temps réel l’évolution les changements qui surviennent dans la collaboration ou dans le théâtre de son déroulement. La Figure III.1 représente le périmètre de l’étude de ce chapitre, à savoir :

• La structure et le contenu du modèle de la situation collaborative (obtenu via le modeleur issu des travaux de thèse de [Mu, 2012]),

• Le mécanisme de mise à jour des modèles terrain et attendu grâce aux événements générés par le moteur de CEP (par filtre et/ou dérivation d’événements émis par le terrain et la supervision des processus) et à la connaissance additionnelle provenant de la correspondance entre les activités métier et les services techniques [Boissel-Dallier, 2012].

III.1 Le modèle de la situation collaborative

Nous avons évoqué le méta-modèle de la situation collaborative et la sur-couche dédiée à la gestion de crise dans le Chapitre I. Nous allons présenter plus en détails le contenu des modèles qui l’instancient ainsi que l’outil qui, sur la base de ce méta- modèle, permet d’obtenir un modèle de la situation de crise et de son environnement (i.e. le système étudié) ainsi que le système de traitement.