Urbanisme, modélisation, UML ENSG 18 septembre 2006

I – Urbaniser un SI

Un cas : l’ANPE Volumétrie 20 000 salariés équipés de PC en réseau 1 000 agences disséminées sur le territoire Budget informatique annuel de plus de 100 M€ Un cœur de métier : l’intermédiation du marché de l’emploi Stocker des offres et des demandes, trouver des rapprochements Deux clients : l’entreprise, l’actif (demandeur d’emploi le plus souvent) Plusieurs grands projets GEODE : intermédiation du marché de l’emploi (cœur de métier) OASIS : gestion des ressources humaines SIAD : système d’aide à la décision S@D : services à distance (Internet et/ou téléphonie) Informatique de communication Messagerie, agenda partagé, Intranet, workflows

Principes Fournir une « portée de phares » de trois ans Mettre en perspective le budget annuel Anticiper à grosses mailles les évolutions futures Un exercice à renouveler chaque année « Schéma d’évolution du système d’information » Appel d’offres, puis contrat avec DMR (devenue ensuite Mitsubishi) Calendrier des travaux Début en novembre 2000 Livrable final prévu pour fin 2001, rendu en juin 2002 Phases des travaux 1 – État des lieux 2 – Objectifs prioritaires 3 – Architecture cible 4 – Plan d’action

Déroulement Organisation des travaux Difficultés Une responsabilité bi-céphale Direction de l’architecture de la DSI Coordination des maîtrises d’ouvrage Dans chaque métier, un maître d’ouvrage délégué Un comité de pilotage mensuel Difficultés Une logistique compliquée Recueil d’expertise Rédaction, circulation et recueil des remarques Validation des documents Communication, appropriation… D’épais dossiers à la lecture laborieuse Besoin d’une présentation figurée, imagée

Le schéma d’urbanisme Une cartographie qui se détaille par zooms successifs : Entreprise Domaine Processus Activité Composant Donnée

Le schéma d’urbanisme Les commentaires précisent le contenu et expliquent les choix de priorités La vue d’ensemble montre la solidarité des divers domaines Mise en évidence des questions d’architecture Importance des référentiels Gestion des données de référence Règles de mise à jour des bases de données Exigences de synchronisation Apports de l’informatique de communication Un langage de modélisation Utiliser UML sous une forme propre à la communication (diagramme d’activité)

Présenter un modèle à la validation Validations techniques Validation intermédiaire stratégique Modèle formalisé « en français »

L’appropriation du schéma d’urbanisme Une très grande difficulté ! Il est difficile de faire s’approprier le schéma d’urbanisme par l’entreprise Les documents consignent le résultat d’un travail technique Ils sont longs Ils ne se prêtent pas à la lecture Il est difficile d’obtenir des dirigeants une validation authentique La valeur ajoutée du dirigeant risque d’être perdue Il faut compléter le SESI par une médiatisation Elle doit toucher le cercle des dirigeants (~ 100 personnes environ), plus les experts métier et les experts de l’informatique (quelques centaines), soit au total 2 % de l’entreprise Buts Percevoir les implications pratiques du système d’information par delà son apparente abstraction En tirer les conséquences en termes d’organisation (travail coopératif, application de nouvelles normes)

Couches de la plate-forme informatique Applications métiers Infrastructure applicative Infrastructure de communication Génie logiciel Infrastructure de base Équipement physique et OS Infrastructure d’administration

Urbanisme fonctionnel et urbanisme technique

Mise en discussion de questions stratégiques L’Agence doit-elle ou non offrir des services marchands ? Exemple : « recrutement par habileté ». Évaluer les prestations, facturer, encaisser, comptabiliser Faut-il enrichir l’intermédiation du marché de l’emploi en prenant en compte l’offre de formation ? L’intermédiation passe de deux à trois pôles : complexité multipliée par trois Faut-il articuler le système d’information avec les services rendus sur l’Intranet? Modification des procédures, nouvelle répartition des responsabilités Faut-il articuler les services rendus sur le Web et les plateaux téléphoniques avec les services « présentiels » en agence ? Mise en place d’une CRM, intégration de services multicanaux Comment doit évoluer la relation avec les partenaires ? Interopérabilité des systèmes d’information

Principaux obstacles à l’urbanisation Sociologiques Refus de l’explicitation Refus de la logique Compromis managérial Intellectuels Refus de la pratique de l’abstraction Méconnaissance des techniques et apports de la modélisation Défaut d’expertise en statistique Difficulté à définir les indicateurs Difficulté à penser l’articulation entre l’être humain et l’automate Philosophiques Difficulté à penser en termes de processus La pensée grecque porte sur des concepts pérennes… Refus de l’articulation entre la pensée et l’action

Que signifie « modéliser » ? Qu’est-ce qu’un modèle ? représentation explicite d’un être réel permettant de simuler mentalement son fonctionnement théorie orientée vers l’action concepts (descriptifs) & relations fonctionnelles entre concepts Modèle implicite et modèle explicite Chacun modélise tout le temps, mais de façon implicite La science et l’entreprise exigent des modèles explicites Un modèle explicite est pratique, mais difficile à comprendre

« Modéliser » l’entreprise Principe de la modélisation Documenter les tâches réalisées dans l’entreprise, tant par l’être humain que par l’informatique. Seule une partie des tâches est réalisée par le logiciel Clarifier le vocabulaire, expliciter procédures et contraintes, rôles et responsabilités Prévoir notamment les démarches en mode dégradé (Jacques Printz) Contenu du modèle Référentiel Dictionnaire, identifiants, nomenclatures, règles de gestion Urbanisme Modélisation globale : « plan de masse » des processus et de leurs relations Modélisation du processus Enchaînement des activités humaines et opérations informatiques, dossiers (« objets ») que le processus manipule Règles de gestion : contraintes d’intégrité, cycle de vie des objets

Processus Plate-forme du SI Activité Événement déclencheur réponse Indicateurs et bouclage Communication interpersonnelle

Activité EHO APU IHM Organisation Écouter Comprendre Expliquer Concevoir Décider Communication interpersonnelle EHO IHM Classer Trier Calculer Traiter APU Plate-forme

II – Modéliser un processus

Finalités de la modélisation Finalité technique Préciser la conception du SI, guider sa construction Qualité du SI : ISO 9126 FURPSE : « Functionality, Usability, Reliability, Performance, System Maintainability, Evolutivity » Finalité intellectuelle Élucider les objets, concepts, processus, référentiels de l’entreprise Compenser l’autisme centrifuge des spécialistes Que chacun puisse se représenter clairement Le cours du processus pour lequel il travaille Son propre rôle dans le processus, les rôles des autres acteurs Les relations entre les divers processus de l’entreprise

Pourquoi modélise-t-on ? Certaines entreprises ne veulent pas modéliser… Elles croient inutile de comprendre comment elles font ce qu’elles savent faire Un modèle explicite dérouterait des salariés formés aux habitudes maison … d’autres, de plus en plus nombreuses, sont contraintes modéliser Évolutivité : l’entreprise ne sera souple que si les salariés se sont appropriés le modèle Interopérabilité : deux entreprises ne peuvent interopérer que dans la mesure où leurs modèles sont explicites

Comment présenter un modèle ? Modèle = être idéal (donc invisible) représenté par un document (texte et graphique) Il faut fournir à chaque acteur (utilisateur, analyste, responsable hiérarchique, expert du domaine) la « vue » qui lui convient Exemple : système d’information géographique Deux écueils Exagérer le formalisme d’un langage de modélisation interdirait toute compréhension à certains acteurs L’absence d’une méthode de représentation empêcherait la collecte et la synthèse de l’information

Des vues autour du modèle formel

Quelles sont les « vues » que le modèle doit présenter ? Pour les informaticiens qui produisent le logiciel : faciliter le travail Diagrammes de classe, d’état etc. Automatisation (partielle) de la production du code Pour les responsables hiérarchiques : faciliter la validation Diagramme d’activité Texte en langage naturel Pour les utilisateurs : faciliter l’appropriation Présentation sur l’Intranet Outil de contrôle personnel des connaissances

Une démarche méthodique

Les phases amont du développement Les acteurs (décisionnaires, utilisateurs, MOA) bâtissent l’objectif stratégique Le contour du domaine, les engagements fonctionnels, budgétaires, de planning et architecturaux apparaissent Enjeu : définir des objectifs compris par tous, réalistes, recouvrant entièrement la vision initiatrice du projet Maîtriser les risques Sélection des ressources de développement Compétence technique Budget et planning réalistes Conduite de projet organisée et suivie Méthode de développement et assurance qualité adaptées au projet

Comment modéliser ? Langage UML et outils de cohérence La méthode qui convient pour mettre en œuvre UML n’est pas écrite Il faut choisir dans la panoplie des outils Principes utiles Critères de qualité du SI : Pertinence, Sobriété, Cohérence Piloter par les livrables  Définir les produits plutôt que la façon de les produire Ne pas se lancer dans la modélisation sans disposer d’une expression de besoins validée et stabilisée Progresser « top down » Ne jamais anticiper une étape ultérieure Réaliser entièrement chaque étape avant d’attaquer la suivante S’assurer de l’authenticité des validations S’il faut corriger, modifier en amont et boucler vers l’aval Le modèle métier peut être remis partiellement en question par la prise en compte des contraintes et ressources de la plate-forme

Méthode proposée pour la modélisation Phase 1 : Expression de besoin validée Dictionnaire Description du domaine Approche systémique Structures impliquées, mode de coopération Notion de « flot d’information » d’UML 2.0 Phase 2 : Modélisation des processus Diagramme d’activité Modèle conceptuel Diagramme de classes Règles métier Contraintes, invariants, pré- et post-conditions Démarche à suivre en fonctionnement dégradé Phase 3 : Modèle de cas d’utilisation Phase 4 : Prise en compte des contraintes et ressources de la plate-forme Modèle complet Validation et appropriation Présentation du modèle aux responsables et aux utilisateurs

Approche systémique : le « flot d’information »

Modélisation du processus

Cas d’utilisation

« Modèle métier » et « modèle complet » (Pascal Roques et Franck Vallée, UML en action, Eyrolles 2003) Modèle métier Modèle complet Responsabilité de la MOA de la MOE conjointe Contraintes et ressources de la plate-forme

Pourquoi faut-il un modèle métier ? Les processus métier sont très divers Automate pur (pilote automatique etc.) Back-office Front-office Interopérabilité avec des partenaires Exigences spécifiques Temps réel, synchronisme, qualité des données, homogénéité des codages Bien séparer les rôles de l’EHO et de l’APU L’informatique ne peut pas tout savoir La modélisation procure au métier une révision de ses processus, voire une relance de sa réflexion stratégique L’évaluation du coût et des gains (rentabilité) du projet progresse pendant la modélisation La révision du modèle métier lors de la prise en compte des contraintes et ressources de la plate-forme n’excèdera pas 10 à 20 %

Désordres à éviter Référentiel Spécification Modélisation Validation Identifiants et nomenclatures défectueux, homonymes, dialectes locaux, défaut de mise à jour des BD Spécification Démarrage précipité, inflation et versatilité des besoins Modélisation Anticiper le travail des phases suivantes Validation Manque de lisibilité du modèle Responsabilité Confusion MOA/MOE, manque de légitimité de la MOA Conduite de projet Mauvaise définition des comités, mauvaise qualité du suivi Appropriation Carence de la communication avec les utilisateurs