SP1 ANALYSE DES USAGES ET BESOINS Lot 1.2 Des usages aux fonctionnalités

Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services SP1 ANALYSE DES USAGES ET BESOINS Lot 1.2 Des usages aux fonctionnalités Auteurs : Participants : Jean-Philippe Blanchard Stéphane Sollat Philippe Coudé Noëmie Simoni Version : 1.0 Date : 25/11/2009 1 / 30

Historique du Document Version Date Modifications 0.1 01/09/2009 Création du document 0.2 15/09/2009 Modification suite à groupe de travail 0.3 30/10/2009 Rédaction 1 ère Partie 0.4 15/11/2009 Rédaction Globale 0.5 20/11/2009 Relecture ABSTRACT: Mots clés : Mobilité, User Centric, Oasis numérique, zone UBIS, services dématérialisés, entreprise responsable, orchestration d activités, pilotage transformation biz, zone et Opérateur de confiance, réseaux sociaux. 2 / 30

Table des matières MOTS CLES :... 2 1. INTRODUCTION : OBJECTIFS DU LOT : 1.2 :... 5 2. ANALYSE DES ELEMENTS D ENTREE DE L ETUDE... 6 2.1. Classification des fonctionnalités... 6 2.2. Consolidation des fonctionnalités à retenir... 9 2.2.1 A qui la fonctionnalité rend-t-elle service : «Ontologie du User»... 10 2.2.2 Sur quoi la fonctionnalité agit-elle? : «Ontologie des domaines fonctionnels»... 12 2.2.3 Dans quel But? : «Ontologie des exigences pour le SP1»... 15 2.2.4 Fonctionnalités retenues... 19 3. DES FONCTIONNALITES AUX SERVICES DE BASE «UBIS».... 20 3.1. Impact du type de consommateur... 20 3.2. Impacts de la modélisation... 21 3.2.1 Userware :... 21 3.2.2 Serviceware... 22 3.2.3 Sessionware... 23 3.2.4 Les services retenus... 23 4. LES ELEMENTS COMPLEMENTAIRES A CONSIDERER DANS L ETUDE.... 24 4.1. Exemples de services exposables.... 24 4.2. La Zone Ubis:... 25 4.3. Proposition applicative complémentaire... 29 3 / 30

Table des Illustrations Figure 1: Schématisation des objectifs du SP1...5 Figure 2: répartition des fonctionnalités à 2 niveaux...7 Figure 3: alignement fonctionnalité - service entité d usage...9 Figure 4: principe de la bête à corne de l analyse de la valeur... 10 Figure 5: ontologie de l utilisateur... 11 Figure 6: influence domaine opérationnel et fonctionnel sur le modèle d instanciation de l usage... 12 Figure 7: cartographie des entités impliquées dans UBIS... 13 Figure 8:schéma relationnel par domaine user UBIS... 14 Figure 9: schéma des 4 domaines fonctionnels... 14 Figure 10: schéma principe des exigences... 15 Figure 11: objectif majeur du sous projet SP1... 16 Figure 12: macro design de l'objectif UBIS 1... 16 Figure 13: macro design de l'objectif UBIS 2... 17 Figure 14: schéma des gouvernances imbriquées des partenaires UBIS... 18 Figure 15: Userware / Serviceware/sessionware... 21 Figure 16: l'exposition de services par thème et ordre... 25 Figure 17 : Zone des désirs... 25 Figure 18 : Niveaux de visibilité... 26 Figure 19 : Zone UBIS... 26 Figure 20 : Zone des ressources... 27 Figure 21 : Zone du parcours client... 27 Figure 22 : Exposition de services d un opérateur métier A... 28 Figure 23 : Exposition de deux opérateurs avec rétribution... 28 Figure 24 : Le pilotage de la conquête... 30 4 / 30

1. Introduction : Objectifs du lot : 1.2 : Dans le lot 1.1 nous avons identifié les nouveaux paradigmes du contexte d aujourd hui centré sur l utilisateur. Nous devons maintenant en déduire les fonctionnalités à intégrer dans les plates-formes de services afin d offrir aux fournisseurs de services l environnement qui prend en compte ce nouveau contexte. Dans notre projet, nous devons définir ces «services» que nous dénommant «services de base» et les services que peuvent offrir différents fournisseurs qu ils soient ou pas des opérateurs. Ces derniers sont dénommés «services exposables», ce seront ceux des scénarios retenus dans le lot suivant (1.3) (Telco/SFR et Web/CA) que notre démonstrateur mettra en œuvre. Les fonctionnalités sont décrites à gros grain ainsi que la dynamicité de leur environnement d'usage. La description de ces fonctionnalités sera aussi générique que possible, mais toutefois suffisamment précise pour permettre leur utilisation dans la création de services spécifiques à un domaine d'activité. Figure 1: Schématisation des objectifs du SP1 Les fonctionnalités, dérivées de la tâche précédente, seront définis de manière à respecter un certain nombre de contraintes propres à l'environnement UBIS, parmi lesquelles il y aura au minimum cellesci: Elles seront capables de satisfaire un degré prédéfini de satisfaction de l'utilisateur (Gestion dynamique de la QoS via la notion de SLA). Elles pourront être fournies totalement ou partiellement (composition) par plusieurs opérateurs de services (transorganisationnels). Elles seront mobiles (continuité de session). Elles seront à large granularité : Les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion de composant technique. Elles seront multi facettes: Un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent implémenter une interface commune. Elles seront localisables : Avant d appeler un service, il faudra le trouver. Elles seront faiblement couplées 5 / 30

2. Analyse des éléments d entrée de l étude Le groupe de travail «SP1» (CAsa, TPT et SFR), réuni fin juillet, a finalisé la phase 1 du SP1 et produit les bases du SP1.2, en fournissant la liste des fonctionnalités «gros grain» ( 2.1). Il nous faut maintenant l analyser et consolider les services que devra proposer notre plate-forme de services UBIS. 2.1. Classification des fonctionnalités Une première analyse du constat des changements de paradigmes qui sont à l origine de notre projet, nous a fourni les fonctionnalités suivantes : Transorganisationnel Personnalisation Composition de service Gestion de la mobilité Continuité de service Localisation Découverte de service Session User Centric Gestion dynamique de la QoS Gestion des préférences Gestion des communautés Mutualisation Dématérialisation des services User Centric Adaptation face à l hétérogénéité Transparence Virtualisation Gestion d identité Réseau social (poids des communautés) A la lecture de la liste, il apparait indispensable de faire un travail de classification et d ordonnancement des fonctionnalités proposées. Mais aussi, il y a la nécessité de comprendre que, dans le contexte du projet, le terme «fonctionnalité» est à nuancer d une approche stricte, au sens d une ingénierie technique courante mue par une approche trop factuelle, sans recul et granularité. En effet, nous trouverons dans cette liste des termes très opérationnels, comme «gestion de la QOS dynamique», cohabitant avec «user centric», proche du concept ou de la «méta approche». Il y a, en l espèce, des univers sémantiques très différentiés, se rapportant à des référentiels et des univers d analyses, à priori hétérogènes. Mais comme, toute démarche de projet de recherche, les termes doivent être libres pour définir des modèles ou synthétiser l expression d un «vouloir». Organisés et instanciés, ils deviennent homogènes suivant un point de vue, un alignement stratégique. C est bien entendu le cas dans cette liste. Ainsi nous distinguons les termes exprimant une demande stricte, avec une cible «visible» de manière factuelle, d une demande appartenant au domaine de «l exigence» ou d une requête générique. Une fonctionnalité «fait». Une exigence donne un contexte à des fonctionnalités ou une transformation fonctionnelle, en les aiguillant suivant des critères donnés Nous devons donc, identifier parmi ces fonctionnalités, lesquelles appartiennent respectivement à ces deux niveaux de lecture, et traduire celles du domaine de l exigence/requête, au domaine de la fonctionnalité «opérationnelle». La figure suivante, relate cette première organisation : 6 / 30

Figure 2: répartition des fonctionnalités à 2 niveaux Cette première classification doit être compléter, par une tentative d aligner des «fonctionnalités» classées comme des exigences, au même niveau d exploitation du reste, des autres fonctionnalités, classées en tant que telles. Préalablement, nous passerons par une étape de retraduction des exigences pour y déceler des fonctionnalités. exigences - requêtes traduction fonctionnalités Adaptation face à l hétérogénéité Continuité d usage des services et de leur perception visuelle et sonore (si nécessaire), suivant l hétérogénéité des réseaux, des terminaux, des services, des situations usages et du profile de données (riches, maigres) Gestion dynamique de la QOS, découverte de services, gestion des communautés, continuité de services *Gestion de contenus (adaptation affichage, en fournissant info profil terminal) (hors scope) User Centric Démarche générique où l utilisateur est au centre de l organisation. Personnalisation de services Tout le système est à son service de façon transparente Localisation, gestion des préférences, gestion de l identité, continuité de services, gestion de la mobilité, composition de services *Langage de composition (hors scope) Session User centric Après identification, les services et leurs composants (logiques et matériels) s adaptent et se coordonnent pour fournir ou continuer de fournir les services invoqués (désirés) par l utilisateur dans une seule session Gestion des préférences, gestion de l identité, gestion de la mobilité, gestion des communautés, continuité de services, gestion de la session unique, Transparence Apporter un niveau d intégration et de simplification pour l utilisateur, à la réalisation de ses commandes, en lui masquant les traitements sous-jacents, tels que les Gestion des préférences, gestion de l identité, gestion de la mobilité, gestion des communautés, continuité de services, 7 / 30

opérations inhérentes aux continuités des sessions réseau (handover) et au traitement applicatif métier. Dématérialisation des services Etre capable de transformer un processus «analogique» et ses composants matériels, en services et supports numériques, invocables dans un workflow cible ou de manière ad-hoc Virtualisation, *Gestion de référentiels des services virtualisés (internet des objets, tag, code 2D ) mutualisation, gestion de la mobilité Réseaux social (poids des communautés) Prise en compte des mécanismes d avis et de notations des réseaux sociaux de l internet, par l intégration et/ou interfaçage à l architecture UBIS Gestion de l identité, gestion des communautés, composition de services Transorganisationnel Apporter des mécanismes protocolaires, informationnels, de sécurité, de référentiel métier et services ( ) permettant le partage de ressources intra entreprise, dans le but de constituer un référentiel commun d exposition et de composition de services. Continuité de services, gestion de l identité, gestion de la mobilité, découverte de services, composition de services, *visibilité des échanges *gestion de la transactivité gestion des communautés, gestion dynamique de la QOS Bilan analyse des exigences : Comme nous pouvons le constater, bon nombre de ces exigences se trouvent être matérialisées par les mêmes fonctionnalités. Nous remarquons que la personnalisation est traduite dans notre projet par la composition de services. En effet, pour pouvoir aller vers des services autonomes à liens lâches, il nous faut éviter des fonctions à sous fonctionnalités optionnelles Il est à noter que la session «user centric» désigne la session que désire établir l utilisateur, c'est-à-dire l espace temps pendant lequel il veut être en relation avec le système et appeler autant de composants de services (en parallèle ou en interaction) qu il désire. On la dénommera session UBIS ou session «user centric». Nous constatons des fonctionnalités supplémentaires au SP1.1, notées avec une * et en couleur verte dans le tableau ci-dessus, certaines sont hors scope, les autres sont à intégrer : gestion de référentiels des objets virtualisés Dématérialisation des services (internet des objets, tag, code 2D ) Les services peuvent être invoqués par des objets physiques «déclencheur». Les objets physiques (papier, portable, voiture ) peuvent avoir un équivalent d existence virtuel et être impliqué dans un processus métier ou ad-hoc. Le passage entre les deux mondes (réel et Numérique), le suivi de leur indexation et de leur identité sont nécessaire. - visibilité des échanges Transorganisationnel - gestion de la «transactivité» pilotage des activités de coopération, par des outils permettant de visualiser les associations, les flux, les processus (se rapproche des outils de Business Activity Monitoring «BAM») et du design de ses associations (Businesse Process Management «BPM») permettant de formaliser l exposition d offres composites, relevant de plusieurs partenaires. En conclusion, nous pouvons confirmer que la liste des fonctionnalités que nous allons retenir se focalisera sur l étude des fonctionnalités présentes dans la colonne de droite du tableau de synthèse. 8 / 30

Par étudier, nous entendons rechercher les services pour cette catégorie d item, en ayant soin de prendre comme critère de contrainte et d exigence, les items «exigences» de la colonne de gauche. EXIGENCES fonctionnalités gestion des préférences composition de services gestion de l identité découverte de services gestion de la mobilité Gestion de la session UBIS gestion dynamique de la QOS gestion des communautés* Localisation Continuité de services virtualisation mutualisation gestion de référentiels des services virtualisés. visibilité des échanges gestion de la transactivité et des communautés d intérêts économiques exigences - requêtes Adaptation face à l hétérogénéité user centric session user centric transparence Dématérialisation des services réseaux social (poids des communautés) Transorganisationnel 2.2. Consolidation des fonctionnalités à retenir En anticipant la méthode et dans le but de définir une approche fine, relative à la définition des services (fonctions autonomes à couplage lâche), nous devons identifier les entités concernées par ces services et, par la suite, leur relation. Bien entendu, quand nous parlons d entité, nous ne nous limitons pas une entité logique. Nous parlons, des entités présentes dans une relation de bénéfice et de médiation du service, ou concourant à ces fins. Si nous retenons qu un service a une valeur «vraie» (d existence) à l invocation d un utilisateur ou par une entité d usage, c est que nous considérons, de manière simplifiée, qu il existe un couple service/entité d usage qui se déclare au moment de l usage. Mais considérant, dans notre cas, que l identification des dits services est, justement, l objet des livrables, donc manquants à ce stade de l analyse, nous devons identifier l instanciation de l usage non plus sur deux points (services et entité d usage), mais comme la classique méthode de géométrie, sur trois points (fonctionnalité, service et entité d usage). Figure 3: alignement fonctionnalité - service entité d usage Pour facilite l'exploitation de ce modèle de raisonnement, nous nous intéresserons, en partie, à une approche méthodologique intéressante, issue de l industrie, connu pour son efficacité dans la définition 9 / 30

de produit et service : «l analyse de la valeur» des travaux de Larry Miles (Techniques of Value Analysis and Engineering). L un des piliers de cette méthode, appelée couramment par les cabinets d études français, «la bête à corne», consiste en un jeu de question simple qui permet de mieux cerner le cadre de réflexion et les éléments présents dans l échosystème du produit, dans notre cas, du service. Nous nous attacherons à nous poser les questions suivantes : A qui, la fonction, rend t elle service? Sur quoi agit-elle? Dans quel but? Figure 4: principe de la bête à corne de l analyse de la valeur Mais par rapport à la méthode initiale, il nous faut généraliser et abstraire les contextes d usage. De cette manière, c est toute la cartographie des entités d usages que nous allons pouvoir consolider et ainsi, nous permettre d ordonnancer et d identifier les services. 2.2.1 A qui la fonctionnalité rend-t-elle service : «Ontologie du User» POUR QUI? Préalablement au travail d association, nous allons prendre en compte toute la dimension utilisateur du projet UBIS, en l identifiant de manière structurée. Par utilisateur, nous ne nous limitons pas uniquement aux utilisateurs finaux, mais à tous les utilisateurs en rapport d usage avec l architecture de service UBIS. 10 / 30

Figure 5: ontologie de l utilisateur Quelques précisions sur certaines dénominations : Utilisateur visiteur : Nous considérons cet utilisateur comme une personne liée de manière non permanent au Système d Information ou un contrat commercial, à l un des partenaires «organisation» de l architecture UBIS. Nous lui associons aussi les termes de prospect, d invité, d utilisateur occasionnel Utilisateur prof. fournisseur : Ensemble des utilisateurs professionnels, appartenant à l organisation, fournissant les services. Utilisateur «designer Marketing» : Profil utilisateur du pôle marketing souvent associé à la définition, coordination de lancement et de suivi des offres (market ou product marketing). Utilisateur «stratège» : Utilisateur associé au pilotage et surveillance stratégique de l activité. Cet utilisateur peut être associé à une notion de fonction, elle-même intégrée à l utilisateur «designer marketing». Architecte métier et IT : Nous entendons deux profiles d architecte. L un pour les processus métier, l autre pour l intégration de ces processus dans l architecture de service. En fait, les travaux du TMF/eTOM nous fournissent les différents rôles que peut avoir une personne ou une organisation. En fait, il serait intéressant d avoir un profil générique par rôle joué par le «Partie» contenant toutes les informations relatives aux rôles. Dans l etom, nous trouvons les rôles suivants : Client qui peut être le «Payeur», «l administrateur», «l acheteur», «celui qui reçoit la facture», «le titulaire du compte» ; User qui peut remplir un des rôles décrit ci-dessus ; Opérateur qui fournit entre autre les services de transport ; Délégué qui peut représenter le titulaire ; Employé qui est souvent l utilisateur de service sans être ni le titulaire, ni le payeur ; Partenaires qui sont ceux qui rentrent dans le cercle des fournisseurs ; Etc 11 / 30

2.2.2 Sur quoi la fonctionnalité agit-elle? : «Ontologie des domaines fonctionnels» SUR QUOI? Dans notre volonté de préciser le contexte d instanciation d une fonctionnalité, pour y déterminer son pôle de services, nous nous efforcerons de répondre à la question que la méthode nous propose : «sur quoi la fonctionnalité agit-elle?» Bien entendu, la question du «quoi» peut être adressée à plusieurs éléments constituant la «matière» réceptacle de cette action, et ce, suivant plusieurs niveaux de visibilité, comme, les éléments d infrastructure, d équipements, de services, d unité logique Mais pour éviter de nous perdre dans les raisonnements et garder une rigueur d analyse, nous sanctuariserons l analyse suivant deux axes : le domaine fonctionnel-informationnel le domaine opérationnel-physique Dans la continuité de la méthode, d instanciation de la fonctionnalité, du service et de l entité d usage, nous poursuivons le raffinement de l approche, en y ajoutant les éléments de contexte d usage, d une part, dans sa dimension fonctionnel, d autre part, dans sa dimension opérationnelle «physique». En reformulant la question le raisonnement apparaît plus clair : «Sur quoi (quel domaine fonctionnel) la fonction agit-elle?» Concernant le domaine opérationnel, nous anticipons le facteur de lieu et les contraintes physiques d exécution de l usage comme une variable à prendre en compte, compte-tenu, du thème général de la mobilité du projet UBIS : nous devons avoir une visibilité de contexte de lieu d exécution des fonctionnalités, en termes de modèle. Figure 6: influence domaine opérationnel et fonctionnel sur le modèle d instanciation de l usage 12 / 30

Pour cerner les domaines fonctionnels, nous proposons dans un premier temps, de faire un bilan des entités présentes et impliquées dans l architecture UBIS, ainsi que leur relation. Le schéma suivant a pour finalité de fournir une vue relationnelle et fonctionnelle des diverses entités présentes dans le consortium du projet ANR, UBIS, participant fonctionnellement à la plate-forme de test de l architecture de services UBIS ou, tout du moins, que l on doit prendre en compte dans l étude. Par ce biais, nous ne négligeons aucun partenaire industriel et institutionnel du consortium. Mais cette approche reste une vue macro de l ensemble, elle ne nous permet pas de préciser les plates-formes logiciel (SUN), l intelligence logiciel embarquée dans les terminaux (Business Anywhere), ainsi que d autres détails. Figure 7: cartographie des entités impliquées dans UBIS Nous proposons cette couleur bleu claire comme identification de tout élément se constituant partie intégrante à l architecture UBIS. Comme vous pouvez le lire, au centre du schéma, nous avons délibérément noté «SI UBIS» et non architecture UBIS, afin de ne pas confondre avec l architecture de services UBIS. Ce que nous soulignons, c est la logique de «méta SI» qui se dégage du projet, du fait de la connectivité des partenaires et de l intégration dans une logique de groupe de services, dépendant de leur SI respectif. De ce fait, nous posons à la réflexion du groupe UBIS, la question de la gestion de cette entité globale, par le positionnement volontaire des deux blocs métiers «gestion IT» et «gestion métier», en dehors des organisations. L équipe projet ne manquera pas de répondre à cette question, impliquant plus des problématiques stratégiques que d intégration technique. Dernière étape de notre analyse des «quoi» de notre méthode, nous allons établir les domaines fonctionnels, en y regroupant les utilisateurs recensés dans le chapitre du «Pour qui?». Le premier schéma, figure 8, nous renseigne sur le regroupement des utilisateurs positionnés suivant un état d utilisateur interne ou externe ; de fournisseur interne ou externe. Par fournisseur, nous entendons un pôle d utilisateurs ayant un rôle de fourniture de services et de contenus et plus globalement d offres à structurer et à organiser, en vue de les exposer aux autres utilisateurs du SI UBIS. Sur ce point, le fournisseur externe est sous le pilotage du fournisseur interne, en termes de validation de son offre et eu regard de la cohérence stratégique. Il peut sembler ambitieux de rendre autonome les utilisateurs métiers «d obédience» marketing fort éloignés, par nature et parcours professionnelle, des contingences techniques des architectures S.I, dans l acte d exposition de services et d offres au SI UBIS. Mais compte-tenu de l approche «user 13 / 30

centric» du projet UBIS, nous pouvons parier sur un niveau de transparence et d intégration suffisamment avancés des outils développés, à terme, auprès des utilisateurs. Figure 8:schéma relationnel par domaine user UBIS La figure 9, fait état des quatre domaines fonctionnels prépondérant, pour notre analyse des fonctionnalités et des services. Nous ne sommes pas sans ignorer le modèle des processus métiers du TeleMangement Forum, «etom», avec toutes ses qualités et son extension à d autres secteur que les télécom, tel que le secteur de l énergie. Mais il nous appartient, à ce stade d avancement de l étude et de la charge de travail, d optimiser les études, en se concentrant sur l efficacité des messages et concept avancés. Figure 9: schéma des 4 domaines fonctionnels 14 / 30

2.2.3 Dans quel But? : «Ontologie des exigences pour le SP1» Le BUT En répondant à la question du «but» recherché, que cela soit pour une fonctionnalité ou un service exposable, nous retombons fort logiquement dans le cadre de l objectif du sous projet «SP1.3». Dans la perspective de prendre en compte tous les aspects de consignes et d objectifs assignés au projet UBIS et au sous projet 1. Nous allons prendre en compte tous les facteurs d exigences référencés, à différents degrés de proximité et impactant le livrable du sous projet, et ce suivant le schéma de principe suivant : Figure 10: schéma principe des exigences Exigences Projet UBIS : Si nous devons faire un travail de discernement sur l exigence du projet UBIS, nous devons prendre en point d entrée la volonté générique, mais néanmoins contractée auprès de l ANR, de démontrer un modèle d architecture de services, instancié en complément du secteur Télécom, auprès d un autre secteur d activité, démontrant l universalité de l approche. Nous parlons là, pour l équipe UBIS, de s inscrire dans une démarche et une vision portée sur les «réseau du futur». La figure 11 démontre la concentration de l objectif de l équipe, sur le démonstrateur, en croisant les deux facteurs : «Que voulons nous démontrer?» ; «Quels données et usage souhaitons-nous incorporer au projet UBIS?» La figure 12 explicite la démarche 15 / 30

Figure 11: objectif majeur du sous projet SP1 En synthétisant le document de référence du projet UBIS, nous pouvons mettre en lumière les points d intérêts du projet de recherche, ainsi que sa structure globale. Figure 12: macro design de l'objectif UBIS 1 16 / 30

La grille ou cinématique de lecture commençant par «intégration», nous permet d isoler les points d études et les bénéfices attendus pour les acteurs «utilisateurs» et «organisations», ainsi que la structure de modèle de l architecture UBIS, localisée en point 2. Figure 13: macro design de l'objectif UBIS 2 Exigences liées aux stratégies de gouvernance des partenaires UBIS L architecture de services UBIS, est un assemblage par intégration de plusieurs architectures de services. Cela nous permet de consolider une communauté d intérêts et de comprendre qu il est nécessaire d avoir une lecture large, dès lors que l on évoque une architecture de services, multi partenaires. A ce stade, il est nécessaire de prendre en compte la caractérisation des partenaires, principalement leur gouvernance informatique et la/les priorités qu ils placent au sein du projet UBIS. 17 / 30

Figure 14: schéma des gouvernances imbriquées des partenaires UBIS Parler et prendre en compte la Gouvernance IT des partenaires, c est reconnaitre que derrière le projet de recherche et de développement UBIS, se profile des questions de stratégie, de pratique métier et de S.I. De même, la gestion et prise en compte d un patrimoine informatique avec une hétérogénéité de maturité sur les questions de technologies, comme la sécurité et la mobilité, par exemple, est aussi un facteur important dans la consolidation d une architecture globale, tentant d intégrer des services et des réseaux dans une seule logique d exposition pour l utilisateur. En effet, ce qu il faut retenir de notre démarche, c est que dans le périmètre du projet UBIS, il n y a pas qu une et unique architecture, mais des architectures de services à intégrer, avec des points de connections et d échanges variables, suivant la volonté des équipes et de la gouvernance IT de leur organisation. Bien entendu, le travail de recherche se cristallise et s appuiera pleinement sur l architecture télécom. Mais la capacité d UBIS à intégrer un ensemble d architectures de services est une vision essentielle du projet. Pour le crédit agricole il est important de : maîtriser son infrastructure de service garder une indépendance stratégique prendre en compte le poids important du facteur de la sécurité IT positionner l alignement stratégique du Pôle Innovation sur la banque mobile et les nouvelles approches de la relation clientèle, «prioritisant» pour le démonstrateur du projet, «le conseiller en agence» et le «client». Pour SFR il est important de : maîtriser ses différents niveaux de service se positionner dans le «home network» prendre en compte le poids important du facteur «composition de service». proposer des services innovants intégrant l approche «user centric». L approche du design général doit favoriser une vision d adhésion/abonnement /à la carte des infrastructures en appliquant à tous les niveaux de services un couplage lâche, qu ils s agissent de services applicatifs ou de services réseaux. Chaque partenaire offrant ses services «exposables» à travers un catalogue. 18 / 30

Conclusion du SP1.1 2.2.4 Fonctionnalités retenues L analyse que nous venons de faire nous permet de consolider la liste des fonctionnalités à retenir : fonctionnalités 1 Gestion des préférences 2 Composition de services 3 Gestion de l identité 4 Découverte de services 5 Gestion de la mobilité 6 Gestion de la session UBIS 7 Gestion dynamique de la QOS 8 Gestion des communautés* 9 Localisation 10 Continuité de services 11 Virtualisation 12 Mutualisation 13 Gestion de référentiels de services virtualisés 14 Visibilité des échanges 15 Gestion de la «transactivité» et des communautés d intérêts économiques 19 / 30

3. Des fonctionnalités aux services de base «UBIS». Après avoir consolidé les fonctionnalités, nous devons identifier les services de base «UBIS» qui permettront à tout service offert (exposable) de s exécuter dans l environnement NGN/NGS. Pour poursuivre notre analyse, nous allons considérer les éléments impactant la décomposition en élément de service autonome à lien lâche, comme l impact du type de consommateur ( ), l impact de la modélisation ( ), 3.1. Impact du type de consommateur Dans l association des services aux fonctionnalités que nous allons réaliser ci-après, nous allons constater que la «consommation» des services est thématisée suivant le type d utilisateur, qui à priori seront soit les «utilisateurs finaux», soit «le système». Ce qui nous donnera deux ensembles de services, celui que nous qualifierons d «Userware» qui sera rattaché à l utilisateur et celui que nous qualifierons de «Serviceware» qui sera la partie fondamentale de la plate-forme de services du fournisseur de services. A ce niveau de l analyse, nous isolons la gestion de la session car elle est transverse à toute l architecture et nous la définissons en tant que «Sessionware». Cette analyse ne traite que des aspects fonctionnels et non de l organisation que mettrons en place les différentes entreprises. fonctionnalités Type de consommateur 1 Gestion des préférences User 2 Composition de services User 3 Gestion de l identité User / système 4 Découverte de services User 5 Gestion de la mobilité User / système 6 Gestion de la session UBIS User / système 7 Gestion dynamique de la QOS Système 8 Gestion des communautés* User / système 9 Localisation Système 10 Continuité de services User / système 11 Virtualisation Système 12 Mutualisation Système 13 Gestion de référentiels d objets virtualisés User 14 Visibilité des échanges Système 15 Gestion du «transactivité» et des communautés d intérêts économique Marketing Dans l «Userware» nous trouverons tous les services qui permettent à l utilisateur d interagir avec le système et de répondre aux exigences d UBIS, alors que dans le «Serviceware» ce sont les services qui supportent une architecture horizontale. Quant à «Sessionware» il assura le binding avec une vision de bout en bout, dans notre contexte entièrement dynamique. 20 / 30

Figure 15: Userware / Serviceware/sessionware 3.2. Impacts de la modélisation Conformément au macro design des objectifs (Figure 13) et à notre dernière classification (Erreur! Source du renvoi introuvable.), nous allons identifier les différents services de base de l «Userware» ( 3.2.1), du «Serviceware» ( 3.2.2) et du «Sessionware» ( 3.2.3), et expliciter certain, sachant qu ils seront repris dans les livrables adéquats. 3.2.1 Userware : Service de matching : «Ambient Grid» 1 Gestion des préférences Service d espace personnel Services de présentation IHM Service de matching : «Ambient Grid» : représente le service principal de l Userware permettant de traiter la demande de l utilisateur. L ensemble des paramètres jouant un rôle dans le processus d accès aux services construit une grille multidimensionnelle. Le traitement de cette grille (matching) permet de construire l organisation virtuelle qui satisfait la demande. Service d espace personnel : gère l espace d interaction de l utilisateur avec le système, afin de composer sa session. Service de présentation IHM : permet aux utilisateurs de définir leurs préférences à travers un modèle selon lequel ils pourront saisir leurs informations personnelles. Ces informations vont être utilisées ultérieurement par les autres composants de l Userware afin d établir une demande de service personnalisé. Service d autorisation Service d espace personnel 2 Composition de services Services de présentation IHM Service de découverte de services. Service de composition de services (VPSN) Service de présentation de services Service de composition de services, VPSN : (Virtual Private Service Network) : qui sont des réseaux de composants de service dans la visibilité «service». Il représente l application qui devient un réseau de 21 / 30

composants de service (SE). C est la logique de service qui relie les composants pour avoir une application globale demandée par l utilisateur Service de découverte de services 4 Découverte de services Service d espace personnel Services de présentation IHM Service de présentation de services Service de localisation des services 13 gestion de référentiels de services virtualisés Service d espace personnel Services de présentation IHM Service d indexation d objet virtuel 3.2.2 Serviceware Service d authentification 3 Gestion d identité Service d espace personnel Services de présentation IHM Service de fédération d identité Service d annuaire Service de géolocalisation 5 Gestion de la mobilité Service de handover (HHO/VHO) Services de provisionning Service de présence Service de VSC 7 Gestion dynamique de la QOS Service de gestion d évènement Services de présentation IHM Service de contrat de service SLA Service d authentification 8 Gestion des communautés Service de découverte Services de localisation Service de présence Service des activités Service de VSC Service d audit Service authentification : est la procédure qui consiste, pour un système informatique, à vérifier l'identité d'une entité (personne, ordinateur...), afin d'autoriser l'accès de cette entité à des ressources (systèmes, réseaux, applications...). L'authentification permet donc de valider l'authenticité de l'entité en question. Il est à noter que quelque soit la communauté que nous allons considérer (communauté des utilisateurs, des équipements, des services, etc), on aura besoin des quatre services suivant. Service de localisation : LBS (Location Based Service) Ce service de base a pour but de déterminer l endroit géographique d un composant de la communauté en fonction de l information donnée. Ce qui peut être l adresse ou la position de ce composant. LBS peut servir de trouver un composant avec une fonction et une QoS précise pour l ajouter à la communauté. Service de présencen : PBS (Presence Based Service) Ce service de base a pour but de trouver les composants qui sont à proximité d une position connue d un composant avec des critères. Les résultats de PBS peuvent servir à donner les possibilités concernant une demande. Service de découverte : DBS (Discovery Based Service) Ce service de base a pour but de découvrir les nouveaux membres qui sont qualifiés pour entrer dans la communauté actuelle. 22 / 30

Service d activité : ABS (Activity Based Service) Ce service de base est pour fournir le groupe des composants dans une même activité. Service de géolocalisation d un équipement 9 Localisation Service de géolocalisation d un utilisateur Service de géolocalisation d un service Service de géolocalisation d un.. Service de Handover 10 Continuité de services Service de découverte Services de localisation Service de présence Service des activités Service de gestion de ressource 11 Virtualisation Service d annuaire Service de provisionning avec des services ubiquitaires 12 Mutualisation Service de déploiement Services de partage de ressource Service SSO 14 visibilité des échanges Service de handover service de cartographie des relations de services Service de recouvrement gestion de la «transactivité» et Service de billing 15 des communautés d intérêts économique Services d offres de biens ou services commercialisés Services de catalogue service de cartographie des relations de services 3.2.3 Sessionware Service SSO Service d authentification 6 Gestion de la session UBIS Service de localisation Services de présentation IHM Service de présence 3.2.4 Les services retenus Service de matching : «Ambient Grid» Service d espace personnel Services de présentation IHM Service de découverte de services. Service de composition de services (VPSN) Service de présentation de services Service de découverte de services Service d indexation d objets virtuels Service de fédération d identité Service d annuaire Service de localisation des services Service de géolocalisation Service de handover (HHO/VHO) Services de provisionning Service de VSC Service de gestion d évènement Service de contrat de service SLA 23 / 30

Service de découverte Services de localisation Service de présence Service des activités Service de VSC Service de gestion de ressource Service de provisionning avec des services ubiquitaires Service de déploiement Services de partage de ressource Service de recouvrement Service de billing Services d offres de biens ou services commercialisés Services de catalogue service de cartographie des relations de services Service SSO Service d authentification Service d autorisation Service d audit Au-delà de cet aspect fonctionnel, il nous faudra aborder par la suite les autres dimensions, en particulier la dimension informationnelle qui joue un rôle important car elle représente toute la connaissance du contexte et mémorise tous les évènements traduisant la dynamicité du contexte. Nous nous efforcerons d organiser les services de base, suivants les déclencheurs d évènement impactant les services. 4. Les éléments complémentaires à considérer dans l étude. Nous venons de finaliser les services de base à proposer dans les plates-formes de services du nouveau contexte NGN/NGS. Pour notre démonstrateur, il nous faut maintenant proposer des services «exposables» par des fournisseurs de services qu ils soient opérateurs(sfr) ou pas (CA) afin de valider l approche «user centric» qui permet à un utilisateur de composer une session avec les composants de services qu il désire. Le lot 1.3 suivant du SP1 privilégiera deux rôles d utilisateurs ( ) à travers des scénarii adéquats. Par ailleurs, nous sommes conscients que le transorganisationnel n est pas encore considéré à part entière auprès de nos fournisseurs de service et des opérateurs, c est pourquoi nous proposons de commencer par considérer une zone UBIS ( ) qui permettrait de définir les prémisses de mise en relation avec un premier cercle de partenaires. 4.1. Exemples de services exposables. Les scénarii nous permettrons de lister les services «exposables» que nous trouverons dans le démonstrateur, mais à titre d exemple nous pouvons proposons d avoir (compte tenu du consortium du projet) ce type de services : Service bancaires de financements comprenant de nombreux sous service : simulation de prêt, taux de change, calcul de risque, Services d offres de biens ou services commercialisés Services de paiement Service de panier d achat Service de téléphonie Service SMS Service de messagerie instantanée Service de messagerie Service de visiophonie/visioconférence Services de paiement et panier d achat Sachant que nous privilégierons au moins les rôles de «utilisateur», du «client» et d un «délégué» dénommé dans la figure suivante «conseiller d agence» pour couvrir les cas significatifs de notre contexte. 24 / 30

Figure 16: l'exposition de services par thème et ordre 4.2. La Zone Ubis: Pour créer une aire fonctionnelle de confiance pour les utilisateurs et les entreprises, nous allons considérer que l'architecture finale du projet UBIS, apportera une zone sécurisée pour les utilisateurs et les entreprises partenaires : La figure suivante représente cette Zone UBIS. Les points d'accès «ID» in et out, symbolisent le périmètre sécurisé. Le première périmètre, en pointillés, est assimilé aux mécanismes préalables, tel que l'enregistrement d'un terminal dans un domaine donnée. Figure 17 : Zone des désirs D'un point de vue fonctionnel et logique, cette zone UBIS est «découpée» en sous zone de consommations et d'usages à disposition de l'utilisateur. Pour la démonstration et dans le but de rester 25 / 30

dans l esprit d une approche «user centric», nous appelons ces sous aires fonctionnelles des «zone de désirs». Dans chacune des ces zones de désirs, logiquement organisées par thème fonctionnel et métier, nous disposons de ressources correspondantes au thème de la zone de désirs, avec une plus ou moins grande granularité. Ces ressources sont modélisées de manière à être perçus sur deux niveaux de visibilités: la partie stratégie de son activité corporate la partie opérationnelle de ses activités, gérée par les entités «I.T» et services métiers Figure 18 : Niveaux de visibilité La représentation de la ressource ce fait par ce cercle central, connecté par quatre ergots représentant les Domaines d'activité Stratégique «DAS» de l'entreprise. Nous avons assimilé l'entreprise à un Opérateur Métier (OpM). Dans le cercle central sont présents les services, sensés concourir à la réalisation de ces domaines d'activités stratégiques. Ainsi, ces Opérateurs Métiers sont disposés, en termes de ressources, dans ces Zones de désirs, avec la possibilité de choisir le Domaine d'activité Stratégique exposé dans la Zone Ubis (représenté par la couleur violette). Figure 19 : Zone UBIS Ainsi, nous retrouvons les ressources «OpM» positionnées de manière illustrative, dans la zone UBIS. 26 / 30

Figure 20 : Zone des ressources Cela aura pour conséquence, pour les partenaires UBIS d'exposer des activités et des services aux utilisateurs, dans le cadre de son «parcours client». Figure 21 : Zone du parcours client Bien entendu, cette zone UBIS est en soit un écho système favorisant la dynamique de partenariats entre les entreprises. Il est donc logique de trouver des mécanismes de rétribution entre partenaires UBIS. 27 / 30

Figure 22 : Exposition de services d un opérateur métier A Prenons un exemple: Dans le cas d'un client d'un opérateur métier B, contractant une commande auprès d'un Opérateur métier A, une rétribution commerciale pour l'opérateur métier B, sera effective et convenue par avance, soit de manière générale au moment de l'exposition des activités choisies pour la Zone UBIS, soit de manière spécifique pour un type d'opérateur métier ou une situation donnée... Figure 23 : Exposition de deux opérateurs avec rétribution Ce qui est intéressant dans cet effort de normalisation et de modélisation des activités et relations commerciales dans la Zone UBIS, c'est la possibilité de définir un protocole de description des activités commerciales et de leurs offres de services, avec des éléments de descriptions explicites, à destination des partenaires et des consommateurs. L'idée étant de favoriser les opportunités entre partenaires sur la base d'une structure sémantique descriptive (ce que j'ai fais, mes besoins, mes contraintes, mon cadre règlementaires et contractuel, mes services composables, etc...), mais aussi, de promouvoir une certaine forme de présentation des offres commerciales, incluant de fait les avis des utilisateurs «UBIS», (par exemple), renforçant la confiance et les phénomènes de co création et co marketing avec les consommateurs... 28 / 30

4.3. Proposition applicative complémentaire Le projet UBIS porte en soit un bon nombre des dynamiques de recherches de ces dernières années, autour des «Next Generation Network» et des «Next Generation Service». En faisant un focus sur les NGS et en les associant à l approche «zone UBIS», nous proposons une déclinaison logique du terme NGS en NGBiz. Permettant, parallèlement au projet R&D, de proposer une troisième grille de lecture : du «use case» au «business case» En effet, nous considérons que le «use case» ubis comporte deux variables importantes de démonstration dans le périmètre fonctionnel Valeur d usage Valeur de transformation business C est cette dernière valeur de démonstration et de mise en pratique du projet, que nous nous permettons «d appuyer», tant ce facteur est essentiel pour une perception «étendue» du projet UBIS. Pour être synthétique, une valeur de transformation business, c est essentiellement avoir une posture et des pointeurs sur : Le développement de la valeur et de la part de marché ; L accompagnement et la sécurisation du processus de transformation des «leads» (piste affaires) ; C est faire une réassurance du parcours client, malgré l assemblage des partenaires ; C est sécuriser les process juridico-commerciaux entre partenaires (éviter les nuisances et parasitages de la performance marketing) Faire en sorte que la composition de services, soit aussi une composition à valeur ajoutée pour (et au) service des Directions marketing et du Développement (le premier client des équipes projet R&D). Si nous reprenons le schéma du parcours client, dans le cadre de la zone Ubis et déclinons une structure de services gestion et de supervision de ce parcours client, nous aurons L insertion des «sondes» de traçabilité de l utilisateur à chaque service exposé par les Opérateurs Métier (OpM), et uniquement ceux de la «zone UBIS». Le lien entre les opérations de «push» (exposition d offre marketing), de «collectes et de «traitements dans le cadre d opérations marketing, voire de panel récurrent Un système de base de données collectant les informations communes aux partenaires, dans le cadre «d une» opération marketing Des règles de gestion pour la consolidation et l envoi des données commerciales personnelles non partageables, à chaque OpM. 29 / 30

Figure 24 : Le pilotage de la conquête Cette structure logique ouvre des pistes intéressantes et «des possibles» à fort levier stratégique. En effet, avec une telle structure organisationnelle associée à l architecture d UBIS, (telle que nous la projetons à terme), c est une véritable «arme de guerre», particulièrement puissante, pour la constitution d offre packagée «brandé», entre partenaire UBIS. 30 / 30