Proposition d’une modélisation haut niveau des Smart Cities

Lorsque j’ai commencé à travailler sur des problématiques de système d’information relatives aux “Smart Cities” (on pourra se reporter à l’excellent dossier disponible ici pour tout savoir sur les Smart Cities), j’ai tout de suite été confronté à la diversité des interprétations, des propos ou des points de vue de mes interlocuteurs. Le foisonnement, voire le bouillonnement, des idées et des initiatives et la démultiplication particulière des acteurs impliqués dans ce domaine complexifient de manière considérable les échanges. Comprendre un environnement, qualifier un projet, structurer une gouvernance de programme, identifier des zones d’impact…Tout cela devient fort complexe dans une telle agitation, d’autant plus lorsque la pression temporelle, ultime expression de bien d’autres pressions (économique, politique, sociale, environnementale…), laisse peu de chance au temps nécessaire à la compréhension, l’analyse ou de la conception.

Quelques idées à prendre

J’ai donc cherché si des cartes haut niveau représentant l’ensemble des champs adressés par les “Smart Cities”, étaient disponibles sur le web. L’objectif était de disposer d’un outil cartographique, sorte de plan de classement méthodologique, qui devait permettre avant tout de jouer un rôle de facilitateur dans les échanges souvent débridés portant sur la ville durable-numérique-intelligente….

Celle que j’ai trouvée, comme étant la plus proche des objectifs que je poursuivais, était celle de Nikos Saharis. Assez “communicante”, elle correspondait aux spécifications que je m’étais données : séparation en couches logiques, complétude la couverture, classification des problématiques, stabilité temporelle…Elle a contribué certainement à constituer le point de départ de ma réflexion.

La proposition

En bon urbaniste, j’ai donc collecté, classé, trié, rangé, séparé, regroupé, répertorié, nommé…En partant du “bas”, le niveau physique, puis en raccrochant le “haut”, le niveau stratégique ou gouvernance. Puis de proche en proche, sans réellement de méthode, allant et venant, je regardais à chaque fois si chaque “chose” trouvait sa place. Je profitais de toutes les informations disponibles, mais aussi de mon quotidien comme usager des services de la ville.

Je me souviens avoir pris le bus et avoir alors observé que des écrans proposaient des contenus en tout genre (publicité, annonce du prochain arrêt, festivités locales, …). J’ai cherché alors si tous les composants fonctionnels ou techniques de ce service étaient identifiables dans la cartographie que je produisais. Après maintes itérations, j’ai abouti à un modèle sur lequel je reviens encore de temps en temps, mais qui, à l’usage, s’avère relativement stable et fort utile dans bon nombre de situations.

Le modèle proposé (moins communicant que celui de Nikos !) est structuré autour de 10 couches démarrant par le niveau “Gouvernance” et se finissant, traditionnellement, par les couches “Physiques”.

Pour faire quoi ?

Par exemple, commençons de façon “pratique” par positionner les objets de la ville sur une telle carte, histoire de voir si finalement, nous pouvons y placer quelques classiques de l’aménagement urbain.

Poursuivons et essayons par exemple (Toute ressemblance avec des situations existantes ou ayant existé seraient purement fortuites… ), de représenter un projet de collecte de données de température de voirie, (envisagé aujourd’hui par plusieurs collectivités pour optimiser des opérations de salage ou encore estimer l’énergie emmagasinée par les matériaux constituant la voirie).

Un tel projet, comme le montre la carte suivante, nécessite des capteurs (1) positionnés dans la chaussée (2), une solution de communication (3), un système d’intégration de données (4), une solution de stockage de données (5), probablement un système d’intégration organisationnel (6) si des processus métier sont activés auprès des acteurs internes (7) de l’organisation.

Dernier exemple. Réalisons un mapping d’une offre de services déployée sur la métropole lyonnaise : e-Tecely, l’agence en ligne de TCL en charge des transports publics urbains. Que trouve-t-on ? Des terminaux de services (1) mis à disposition des usagers (2) qui offrent des services de mobilité (3) et quelques fonctions de gestion de “Mon compte” (4). Le système permet l’usage de cartes à marqueur (5), contrôlés probablement par des capteurs (6), le tout supporté par une infrastructure numérique (7), des services d’intégration (8) avec certainement un back-office métier et/ou ressource (9) et un système de supervision (10).

Je laisse le lecteur de cet article, le soin de faire l’exercice de mixer les trois cartographies précédentes et en déduire certainement quelques observations inintéressantes !

Dans un article futur, nous verrons comment utiliser cette modélisation pour organiser et structurer un catalogue de services collaboratif qui pourrait être mis à disposition de l’ensemble des partenaires parties prenantes des Smart Cities sur un territoire.

Organiser des responsabilités, périmètrer des projets ou des plans projets, identifier des leviers permettant de développer de la cohérence, favoriser des partenariats, augmenter la valeur des actions réalisées en évitant les redondances de certaines solutions ou au contraire en imaginant d’autres, ….

Autant d’objectifs auxquels que cette cartographie peut certainement contribuer.

….Avec quelques restrictions d’usages

Mais elle ne fait pas tout !

Ce modèle n’est pas la représentation d’une cible à atteindre. Bien entendu. Elle est une forme d’inventaire des constituants méthodologiques, fonctionnels, techniques et physiques des “Smart Cities”. Sans autre prétention ! Elle est fixée sur le “Quoi” et doit permettre de trouver une place à chaque chose. Tout simplement pour favoriser la compréhension des réalités et l’expression des perceptions de chacun.

Cette représentation ne suggère aucune hypothèse organisationnelle, comme nous avons d’ailleurs pu nous en rendre compte dans les quelques exemples d’usages présentés ci-dessus. Par exemple, le bloc “Instances” du niveau Gouvernance ne suggère pas qu’il existe un modèle d’instance unique, mais sa présence doit inviter à se questionner quant à l’existence ou non d’une architecture organisationnelle de gouvernance pour les sujets qui sont étudiés.

La maille de représentation étant par ailleurs assez large, chaque bloc regroupe certainement plusieurs zones fonctionnelles ou techniques qui mériteraient d’être détaillées, ce qui sera fait ultérieurement sur ce blog pour plusieurs d’entre eux.

Enfin, cette modélisation n’est pas non plus d’une exhaustivité totale. Elle a été conçue dans un contexte territorial, institutionnel particulier, elle est donc forcément influencée par ce contexte, malgré tous les efforts d’abstraction qui ont été mobilisés. Tout usage doit donc être contextualisé à l’environnement dans lequel elle est projetée.

Reste probablement à la confier à un graphiste, digne de ce nom, qui saura certainement lui donner une allure plus “communicante”.

Une méthode de qualification de l’obsolescence d’un patrimoine applicatif

Un article récent de la revue “Programmez” nous montrait à quel point Cobol était toujours bien vivant dans quantité de systèmes d’information et que de nouvelles versions apparaissaient régulièrement. Pourtant, combien de fois avons-nous entendu dire que Cobol était “mort”. Mais, non, voilà. Cobol n’est pas mort. Non seulement, il n’est pas mort mais en plus, il nous interroge quant à la pertinence de nos décisions lorsque, motivés par une certaine “obsolescence” parfois subjective d’ailleurs, nous interrogeons sur la nécessité de changer telle ou telle application ou sur l’opportunité d’évoluer vers telle ou telle technologie . Qui n’a jamais entendu dire “qu’il était temps de changer cette application, car elle est devenue largement obsolète”, sans trop savoir d’ailleurs s’il s’agit d’une obsolescence technologique, technique ou fonctionnelle.

La question de l’obsolescence et plus largement du management de la criticité de l’obsolescence des systèmes informatiques est depuis de nombreuses années présentes à l’esprit de tous les gestionnaires de patrimoine que nous sommes, mais est certainement devenue prépondérante, voire préoccupante ces dernières années eu égard à la rapidité d’évolution des technologies, au rythme effréné du développement des systèmes d’information, au raccourcissement des durées de vie des produits et à la nécessaire maîtrise des investissements. Dans cet article, il est proposé un outil simple, largement inspiré par la méthode MARGO (1), permettant de qualifier la criticité d’une obsolescence constatée sur un composant logiciel. Un tel outil (2) nécessite bien évidemment d’être “rôder” sur quelques exemples (3) mais il nécessite aussi de disposer d’un référentiel minimal décrivant le patrimoine (4). S’il est d’une certaine subjectivité dans l’évaluation de l’obsolescence, il peut néanmoins constituer une premier filtre d’analyse et contribuer ainsi à améliorer les processus de décision dans le domaine de la gestion de patrimoine applicatif.

1 – La méthode MARGO

La méthode MARGO, présentée comme une approche systématique de la maitrise des risques d’obsolescence, a fait l’objet d’une publication lors du 16ème congrès de Maitrise des Risques et de Sureté de Fonctionnement en Octobre 2008. Leurs auteurs, Xavier Perrette et Anne Fornier, proposent une démarche structurée et systématique qui permet d’évaluer dans un premier temps la probabilité (les risques) d’apparition d’une obsolescence et dans un second temps d’estimer l’impact d’apparition d’une obsolescence avérée. Si cette méthode s’applique essentiellement aux processus dynamiques de construction (programmes, projets), elle peut tout à fait être adaptée à des sujets plus statiques comme un patrimoine applicatif exploité en production.

La particularité essentielle de la démarche proposée tient à l’approche globale (quasi systémique) qu’elle propose en prenant en compte l’ensemble des sources de risques d’apparition d’obsolescence : les modalités d’organisation des programmes de transformation, les choix technologiques, les solutions techniques, les potentiels du marché et les capacités des fournisseurs. Elle permet par une application de logigrammes de décisions détaillés d’obtenir une évaluation globale des risques d’obsolescence. Combinée de la même façon avec des critères économiques, de sûreté et de service rendu par le système, elle aboutit à une évaluation hiérarchisée de la gravité d’une obsolescence avérée. C’est cette idée qui est reprise ensuite (largement simplifiée) pour qualifier la gravité ou la criticité d’une obsolescence d’une solution applicative.

2 – Son adaptation

Rappelons d’abord quelques définitions proposées par Xavier Perrette et Anne Fornier.

[…] Un produit est une solution technique répondant à une exigence fonctionnelle exprimée par un dossier d’approvisionnement (cahier des charges fonctionnel, spécification technique, …)[…]. Dans cet article, nous limiterons le notion de produit aux applications mises à disposition des utilisateurs dans un système d’information.

Pour X. Perrette et A. Fornier […] L’obsolescence d’un produit traduit l’incapacité à approvisionner le produit sur le marché.[…]

Nous proposons ici de conserver cette définition et de modifier quelque peu la méthode MARGO en suggérant que l’obsolescence telle que définie précédemment n’est qu’un facteur aggravant (parmi d’autres) d’altérations d’usages fonctionnels, réglementaires, techniques ou économiques. Altérations qui démarrent pour toutes solutions dès leur premier jour d’intégration dans le système (ceci avec l’hypothèse optimiste que le cycle d’altération n’a pas démarré avant la possession !).

Ce que nous cherchons donc, n’est pas à qualifier la capacité du marché à approvisionner, mais plutôt la criticité des solutions, considérant que l’obsolescence n’est qu’un facteur aggravant de plus.

Nous proposons de procéder en plusieurs étapes :

  • La première étape consiste à qualifier la gravité des altérations observées par des valeurs allant de 1 à 4 (altération mineure, significative, importante et majeure). 4 axes d’observations sont proposés : l’altération fonctionnelle (appréciation de la capacité fonctionnelle de la solution à répondre aux besoins), l’altération des conditions d’intégration du produit dans son environnement (appréciation de la capacité de la solution à être accueillie par son environnement technique), l’altération économique (appréciation de la dérive des coûts d’exploitation de la solution), l’altération du fonctionnement opérationnel (appréciation de la qualité de service opérationnel). Nous obtenons ainsi par une notation de la gravité une valeur de criticité des altérations.

  • La seconde étape consiste à pondérer la criticité des altérations observée par des critères d’aggravation, que nous avons distingués ici essentiellement au niveau fonctionnel, considérant par exemple qu’un service bureautique (service fonctionnel transverse ou générique) est moins prioritaire qu’un service de messagerie (services de haute priorité par exemple dans un PRA).

  • Ensuite, en combinant la criticité des altérations et les facteurs d’aggravation avec la matrice d’aggravation ci-dessous, nous obtenons simplement ce que nous appelons la criticité en régime nominal.

  • Puis, de la même façon, nous introduisons une facteur de caractérisation de l’obsolescence, au sens ci-dessus, que nous considérons également comme un facteur d’aggravation.

  • Par la matrice d’aggravation, nous pouvons ainsi déterminer ce que nous appelons la criticité en régime d’obsolescence.

Le graphique présente la démarche complète :

3 – Quelques exemples

Passons à la pratique. Prenons quelques exemples de solutions qui présentent toutes des contextes d’altération et d’obsolescence différents :

  • Un produit de Buisiness Intelligence installé en production depuis plusieurs années. Les versions ont été mises à jour dans les premières années qui ont suivi la mise en production, puis abandonnées depuis 5 ou 6 ans. Entre-temps, deux versions sont sorties avec des sauts technologiques majeurs.
  • Une solution d’intégration d’applications de type ETL (Extract Transform Load), également installée depuis de nombreuses années, sans mise à jour de versions. Et pour cause, la solution a été rachetée par un autre éditeur qui a lui-même refondu la solution dans son offre.
  • Un progiciel CRM, toujours actif sur le marché, mais dont les spécificités apportées au cours du temps, ne permettent que difficilement de suivre le cycle de versions de l’éditeur.
  • Un produit de messagerie toujours en production, mais se situant en zone de support étendu, car déjà ancien.
  • Une suite bureautique largement encore utilisée, mais qui, eu égard à la rapidité de sortie des nouvelles versions de l’éditeur fragilise la légitimité de son utilisation.
  • Une application spécifique développée en PHP4, toujours en production.
  • Un progiciel de gestion de maintenance industrielle qui s’appuie sur une version de base de données arrivée en limite de support éditeur.

Le tableau suivant montre l’application de la méthode proposée et met en évidence une classification de criticité pour cet ensemble de solutions :

4 – Conditions de mises en œuvre

Quelles sont les conditions de mise en œuvre d’une telle méthode ? En toute rigueur, pour “amortir” autant que possible la subjectivité des appréciations, à minima il est nécessaire de connaître pour chaque produit (liste non exhaustive) :

  • Un référentiel des applications doté d’une critère de priorité (classique pour les infrastructures dotées de PRA).
  • Une qualification des usages et de la satisfaction des utilisateurs.
  • Les coûts d’intégration et de déploiement des solutions.
  • Les composants essentiels des produits (langage, base de données, environnement d’exécution, framework, bibliothèques, …) ainsi que leurs versions.
  • Les dates de mise sur le marché des produits et composants, les dates clé de support (standard, étendu, etc…) et les dates prévisionnelles de sorties des nouvelles versions.
  • Les coûts d’acquisition et coûts de maintenance évolutive et corrective annuels.

En conclusion, des apports, quelques réserves, et des ouvertures

Cette méthode, que nous avons pu éprouver sur plusieurs exemples, apporte sans conteste un plus dans les processus décisionnels de programmation des investissements. Elle permet, par une approche systémique, d’obtenir une classification de la criticité des applications d’un système d’information et peut ainsi, au delà l’amélioration indéniable de la connaissance du parc qu’elle apporte, aider à une meilleure objectivité des choix de maintenance .

Elle reste néanmoins d’une certaine subjectivité sur plusieurs critères. S’ils avèrent insuffisants, il ne faudra pas hésiter à préciser voire modifier certains critères pour qu’ils soient plus conformes au contexte d’application. Nous avons été amenés, par exemple, à préciser qu’une altération mineure des conditions d’intégration signifiait que la procédure standard de l’éditeur ne suffisait pas pour intégrer une application et qu’elle était modifiée, à la marge, mais modifiée quand même, pour permettre le déploiement de la solution.

Certains seuils doivent également être précisés. C’est le cas par exemple des critères d’altération fonctionnelle ou d’altérations économiques. Dans le premier cas, évidemment, des méthodes de qualification des usages par les points de fonction seraient bien plus rigoureuses. Dans le second cas, la question de prendre des critères de coûts absolus ou relatifs à la solution reste ouverte.

Propositions pour une fabrication des cartographies fonctionnelles de domaine

Ne rêvons pas ! La conception d’un diagramme fonctionnel est une action de modélisation et donc d’abstraction d’un monde bien réel qui peut s’avérer particulièrement complexe. À ce titre, il s’agit bien d’un acte de création voire de créativité pour lequel il n’existe aucune formule simple, efficace, juste, précise et reproductible. Tout au plus, il possible de définir quelques outils pour que chacun parle le même langage, ou quelques principes de conception pour que les grands traits de construction soient partagés. Mais, ne comptons pas trop sur des définitions précises de principes comme « la cohérence forte » ou « le couplage faible ».

Ainsi, loin d’être une recette de cuisine (beaucoup moins précise), toutes les recommandations qui suivent doivent surtout permettre au « modélisateur » de gagner du temps dans la démarche d’appropriation de la méthode.

À noter que la production d’un diagramme fonctionnel fait appel à quelques connaissances dans des domaines de la modélisation, mais, nous essaierons dans cet article qui se veut didactique, de nous détacher des concepts pratiqués maintenant depuis longtemps dans les milieux de l’informatique.

L’ensemble des étapes décrites ci-après sont présentées dans un certain ordre contraint par la présentation du document. Chacun pourra adapter l’ordre des opérations à son contexte particulier. Il n’y a aucune obligation de parfaire la première étape pour commencer la suivante. Au contraire, l’expérience montre que la réalisation d’un diagramme fonctionnel est un travail par touche successive, par itération, par retour fréquent sur l’ouvrage….

Enfin, n’oublions pas que nous évoluons dans au beau milieu de modèles qui seront tous emprunts de point de vue tous discutables. Donc, limitons nous à tendre vers….et acceptons l’imperfection.

Se documenter

Réaliser un diagramme fonctionnel, c’est, comme nous l’avons vu, se positionner à l’articulation entre le métier (processus, activités, acteurs) et le système informatique (application, serveurs, base de données…).

Aussi, la première étape va consister à collecter l’ensemble des informations concernées par le domaine pour ces deux points de vue :

  1. missions et objectifs du domaine concerné,
  2. description de processus, documents qualité (procédures, instruction, …),
  3. organigrammes,
  4. cartographie d’activités ou de processus,
  5. cartographie ou liste d’applications informatiques utilisées si possible avec un descriptif fonctionnel même succinct,
  6. liste des projets en portefeuille avec expression de besoins si possible,
  7. bilan de projets,
  8. études de portée système d’information de périmètre large par rapport au domaine étudié. Les lire une première fois pour s’imprégner du métier.

L’esquisse fonctionnelle

En théorie, les digrammes fonctionnels sont directement déduits d’une formalisation des processus. Dans la pratique, c’est rarement le cas. Alors comment faire sans ?

Tout d’abord, ne pas oublier que la conception fonctionnelle est un processus itératif. Il n’est pas question de produire un digramme fonctionnel, en une seule itération par un processus analytique linéaire. Il s’agit plutôt d’une approche « impressionniste » par touche successive.

Voici les quelques étapes que nous proposons de respecter (sans obligation bien sûr) :

  • Poser les fondations :
    • Poser sur l’espace de dessin les zones fonctionnelles « standardisées » : pilotage, support, référentiel, échanges, front office. Cela permet d’ors et déjà d’organiser la « surface du territoire fonctionnel ». Pour cela, on pourra s’appuyer sur des patterns « maison ».
    • Segmenter les zones d’échanges par acteur (technique de première approche retenue pour identifier les échanges avec l’extérieur).
    • Poser également les zones transverses d’infrastructure fonctionnelle et technique.
  • Rechercher les macro-objets (classe concept dans le langage Longépé)
  • Identifier les macro-objets utilisés par tous (les référentiels), les ranger selon une typologie partagée telle que proposée plus haut.
  • Dissocier les macro-objets métiers des macro-objets support.
  • Identifier les fonctions de pilotage en identifiant les grandes thématiques de gouvernance.
  • Identifier les zones d’échanges dans un premier temps en segmentant les parties prenantes externes bénéficiaires « front-office » et ressources « back-office.

Préciser les frontières de domaines

Une des étapes importantes est la définition des périmètres de domaine. Sujet difficile à traiter car, comme nous l’avons vu, le digramme fonctionnel dispose de zones métier, mais également de zones support, échanges, etc…Autant de zones qui ont de fortes chances d’être partagées par plusieurs domaines de l’organisation.

En première approximation, le plus simple est probablement de cartographier les macro-activités de l’organisation. Cette première approche suffisante dans un premier temps, peut être complétée par :

  • un recensement exhaustif des missions de l’organisation.
  • une identification des acteurs externes, c’est-à-dire l’ensemble des acteurs bénéficiaires des processus du domaine. On pensera aux acteurs bénéficiaires directs (client, usagers), mais également aux partenaires sur lesquels l’organisation prend appui pour réaliser ses processus (concessionnaire de service public par exemple). On pensera également à certains systèmes de production qui peuvent être considérés comme des acteurs externes (un réseau d’eau par exemple). On exclura tout acteur interne.
  • une identification des évènements par acteur. Dans son cycle de vie, chaque acteur va émettre un ou plusieurs événements auquel va réagir le domaine par l’exécution de processus. Le choix des évènements pris en charge par le domaine va permettre de préciser le domaine d’étude : de prendre en compte tel événement ou d’exclure tel autre. Rappelons comme l’a très justement signalé [Le Roux] que ce n’est pas le choix de traiter tel ou tel événement d’un acteur externe que se définit une organisation, quelque soit d’ailleurs son mode de traitement. Comme le préconise [Mandel], on poussera l’analyse ici au-delà même des frontières de l’organisation.
  • une formalisation des échanges. Chaque événement va donner lieu à un ensemble d’échanges entre l’acteur et le domaine. L’ensemble de ces échanges constitue un protocole qui définit les informations échangées, les conditions d’échanges, les conditions de sécurité, etc….

Plusieurs techniques de modélisation sont possibles pour cette première analyse. [Le Roux] préconise l’utilisation d’UML et de ses diagrammes de séquence. Moins précise mais suffisant de notre point de vue, nous avons préféré le polygone d’activités de [Mandel] qui permet de représenter les frontières d’un domaine particulier par une approche plus systémique des organisations.

Contrôler l’architecture fonctionnelle obtenue

Plusieurs moyens existent pour vérifier la qualité du modèle fonctionnel obtenu :

  • En cas d’existence d’une formalisation de processus, on pourra « jouer » le processus en simulant son exécution. À l’exécution de chaque activité, on vérifiera que chaque fonction attendue du système d’information a trouvé sa place et que sa définition est conforme aux services attendus. On pourra profiter de cet exercice pour préciser les blocs fonctionnels.
  • Dans le cas contraire, fréquent, c’est-à-dire sans carte de processus, on pourra chercher à valider le modèle par des analyses entre modèles. Par exemple, en présence d’un polygone de Mandel sur un domaine, on cherchera à projeter les frontières sur la cible fonctionnelle exprimée par la cartographie de domaines, pour vérifier la présence des fonctions de front-office, en vérifiant par exemple que les « évènements » des parties prenantes sont bien traitées par des fonctions SI, sinon identifier pourquoi.
  • Reprendre l’ensemble des documents disponibles et vérifier que tout y est.
  • Reprendre la liste des applications du domaine concerné et contrôler la complétude du modèle fonctionnel obtenu.
  • Faire le point sur la liste des projets en cours et ceux prévus. Attention ! Ici, ne pas reprendre les diagrammes pour les faire coller aux projets, il s’agirait d’une erreur de méthode.
  • Parcourir les règles du cadre d’urbanisme et vérifier que le modèle est conforme, que chaque bloc fonctionnel est bien responsable de ses données, que les zones assument complètement leur rôle, etc…

Impliquer les maîtrises d’ouvrage métier

Si la première version du diagramme de domaines peut être réalisée indépendamment de la maitrise d’ouvrage métier du système d’information concerné, il va falloir tout mettre en œuvre pour favoriser l’appropriation de cet outil et des résultats obtenus.

Les enjeux sont de plusieurs ordres : permettre la maîtrise de cet outil méthodologique par les utilisateurs du système d’information, contribuer à une meilleure justesse fonctionnelle cible, faire adhérer les maîtres d’ouvrage à la nécessité de cohérence.

Les objectifs que nous allons rechercher sont d’obtenir une validation des macro-fonctions, une validation des référentiels, une validation des fonctions d’échanges.

Quelques conseils pratiques dans la relation avec les métiers :

  • Présenter les diagrammes fonctionnels en plusieurs itérations en évitant des niveaux de détails à faible valeur ajoutée. Le premier digramme de domaines présenté sera épuré de tous les détails fonctionnels. Seules les zones fonctionnelles de haut niveau macroscopiques seront présentes sur le diagramme. Cette façon de faire permettra aux interlocuteurs de s’approprier dans un premier temps les principes de modélisation. Ils pourront aussi rapidement réagir sur les découpages fonctionnels de haut niveau. On vérifiera ainsi s’ils s’y retrouvent, éventuellement on modifiera ou on précisera certaines zones.
  • Identifier les acteurs externes avec lesquels le métier échange des informations. Cela permettra de compléter l’analyse des évènements déclencheurs et amènera tout naturellement des questions comme « Que faites-vous de cette information ? ».
  • Pour les macro-données sur lesquelles il existe des doutes, se faire préciser les processus (événement déclencheurs, enchaînement des activités, résultat obtenu, suite du processus).
  • Se faire préciser les projets SI en cours et ceux envisagés dans leur champ fonctionnel.
  • Profiter de ces entretiens pour chercher des critères de différentiation forts entre concepts a priori proches d’un point de vue de fonctionnel.

Qualifier le niveau de description des domaines fonctionnel

Comme nous l’avons vu dans un chapitre précédent, les démarches de déploiement des méthodes d’urbanisme pour les systèmes d’information s’accompagnent généralement d’une mise en œuvre d’indicateurs de mesure du taux de pénétration de la méthode au sein de l’organisation. Le Club Urba-EA avait proposé un indice d’urbanisation qui permet non seulement de définir des orientations stratégiques particulières concernant le déploiement de la méthode mais également de mesurer les progrès réalisés.

Nous proposons ici de définir un critère particulier de qualification du niveau de description des domaines fonctionnels. Ce critère permet d’évaluer l’existence d’une démarche de construction et de modélisation de l’architecture fonctionnelle cible du SI :

  • Modélisation de la cible d’urbanisme fonctionnel (POS fonctionnel du SI ou architecture fonctionnelle du SI) : structuration en zones, quartiers, blocs fonctionnels.
  • Cible globale ou cibles par sous-ensemble.
  • Connaissance des écarts avec l’existant applicatif (applications redondantes, périmètres applicatifs inadéquats …).

Notons que ce critère déroge à l’indice d’urbanisation proposé par le « Club-Urba ». En effet, la notion de connaissance des écarts avec l’existant n’est pas prise en compte ici. Elle pourrait effectivement l’être, à condition bien sûr que les moyens affectés à l’urbanisme le permettent.

À Chaque domaine fonctionnel de la cartographie de domaines est affectée une valeur caractérisant son taux d’analyse fonctionnelle (nommée xi) de la manière suivante :

  • (0) Sans couverture fonctionnelle définie.
  • (1) Couverture fonctionnelle initialisée.
  • (2) Couverture fonctionnelle partielle.
  • (3) Couverture fonctionnelle a priori complète, avec description.
  • (4) Couverture fonctionnelle complète avec description déduite de processus.

La couverture fonctionnelle d’un domaine est « initialisée » lorsque le domaine concerné est agrémenté de quelques fonctions, généralement collectées lors des diagnostics de projets.

Une couverture fonctionnelle est partielle, lorsque le domaine concerné a fait l’objet d’une analyse, même rapide, permettant d’identifier de manière macroscopique les fonctions structurantes.

Elle est complète lorsque l’on considère que l’ensemble des fonctions (regroupement de fonctions et macro-fonctions) sont présentes sans forcément disposer d’une description détaillée (entrées, sorties, services rendus).

La couverture fonctionnelle d’un domaine est complète lorsque l’ensemble des macros fonctions et regroupements de fonctions qui le composent sont déduites d’une analyse de processus et décrites finement (entrées, sorties, services rendus).

La valeur globale du taux de description fonctionnelle du système d’information considéré, en pourcentage, est obtenue en calculant la moyenne des valeurs obtenues. En affectant, par classe de 0 à 4, il est alors possible de renseigner l’indice d’urbanisation proposé par le Club-Urba.

Quelques conseils pratiques

Nous proposons ici quelques conseils, directement issus de l’expérience.

  • Rechercher la meilleure granularité. Pas de remède miracle ! On trouvera tant et tant de conseils sur le sujet, tous plus subjectifs les uns que les autres. Quelques idées pour résoudre cette question :
    • Arrêter le processus de décomposition fonctionnelle lorsque la désimbrication informationnelle n’est plus possible.
    • Toujours se souvenir que l’urbanisme vise à organiser un territoire fonctionnel d’une organisation ou d’une entreprise et non à définir l’ensemble des fonctions d’un SI. Ainsi, on s’intéressera bien plus aux échanges entre blocs fonctionnels qu’à l’architecture fonctionnelle interne d’un bloc.
    • Se laisser guider par le bon sens et sa propre connaissance de l’offre. Pourrais-je trouver une solution sur étagère qui ne traite que de cette fonction ?
    • Ne pas perdre de vue les objectifs initiaux de la cartographie fonctionnelle.
  • Utiliser des patterns de conception fonctionnelle. Plusieurs patterns de conceptions sont disponible pour les systèmes d’information, essayer de s’en s’inspirer autant que possible, vérifier leur conformité fonctionnelle, et au besoin les faire évoluer en les dérivant.
  • Ne pas réinventer la roue. Pour certains domaines fortement « progicialisés », il n’est pas utile de ré-inventer la carte fonctionnelle à atteindre, on pourra s’inspirer largement de leur conception, tout en restant macro (la GMAO par exemple).
  • Revenir aux fondamentaux. Il est important de toujours revenir à la définition d’une fonction pour s’éloigner de la vision « Activité » et se rapprocher le plus proche possible de la vision fonctionnelle.

Une fonction correspond à tout ou partie d’une activité qui compose le processus : c’est l’action de cette activité sur son environnement d’informations. Elle est réutilisable dans le cadre de la réalisation de tel ou tel processus. Elle est responsable des informations qu’elle crée ou met à jour. Elle peut consulter des informations dont elle a besoin, mais dont elle n’est pas responsable.

  • Solliciter les experts métier du domaine concerné. Une bonne façon de vérifier un modèle fonctionnel est de le soumettre à l’avis d’experts du métier : les chefs de projets informatique par exemple qui maitrisent des domaines du secteur concerné, des experts métiers qui ont eu en charge des projets de refonte du système d’information du domaine, …
  • Ne pas chercher à mutualiser trop tôt. Dans le cas de plusieurs domaines, on trouvera rapidement des similarités, au moins sur le plan conceptuel. Attention à ne pas aller trop vite à la fois pour les futurs lecteurs des digrammes, mais aussi pour ne pas aboutir à un diagramme uniquement conceptuel et peu applicable dans la réalité.
  • Ne pas chercher à mutualiser à tous prix. Pour différentier des fonctions, qui sur le plan conceptuel assis derrière bureau semble proches, on cherchera en permanence à caractériser les différences, pour cela on peut s’appuyer sur des plusieurs critères de différentiation :
    • En utilisant les processus (événement déclencheur, activités, temps, …).
    • En identifiant le taux de similarité des informations descriptives (ex similarité entre un ouvrage d’art et un feu de circulation).
  • Observer l’équilibre fonctionnel. En parcourant le digramme fonctionnel, on peut « estimer » le poids fonctionnel de chaque bloc. Il s’agit évidemment d’une méthode peut objective, mais elle permet de s’interroger sur l’équilibre global des masses fonctionnel. Est-ce que ce bloc décomposé en 3 blocs est d’un poids fonctionnel équivalent à celui-ci qui n’a pas de décomposition ?

Une cartographie fonctionnelle pour l’infrastructure

Après plusieurs années de pratique d’urbanisme des systèmes d’information pour plusieurs domaines métier, j’ai eu, il y a quelques années, à prendre en charge la programmation, l’organisation et la conduite d’un portefeuille de projets dits de “services communs”, regroupant sous ce vocable à peu près, tous les projets transversaux pour lesquels la maitrise d’ouvrage est difficilement identifiable. Fort de mon expérience et de mon approche résolument “fonctionnel”, il m’est apparu impératif de disposer d’une cartographie permettant d’établir un canal d’échanges avec les commanditaires de projets, mais également avec les détenteurs des cordons de la bourse. Champ peu adressé par les urbanistes “classiques”, je me suis attelé, avec l’aide d’un urbaniste local, à la création d’une cartographie fonctionnelle des domaines d’infrastructure, pris ici au sens large comme nous allons le voir. En voici le résultat.

Les services fonctionnels d’infrastructure sont classés dans cette cartographie en trois grandes catégories :

  • les services transverses d’infrastructure : ensemble des fonctions utilisables par interaction directe de l’utilisateur, lui-même décomposé en deux sous-ensembles (les fonctions génériques indépendantes de toutes considération métier, et les fonctions d’intégration fonctionnelle, dites fonctions de second ordre car utilisées en grande partie par des fonctions supérieures).
  • Les services techniques d’infrastructure : ensemble de fonctions permettant à l’ensemble de fonctionner.
  • Les services fonctionnels des domaines métiers des systèmes numérique, sous-ensemble d’un ensemble fonctionnel plus large, généralement appelé le système d’information de la fonction informatique (pour être vieux jeu), numérique (pour être plus moderne), ou mieux digitale (pour être à la pointe !).

Cette cartographie a été utilisée à plusieurs occasions, par exemple lors d’une présentation du portefeuille de projets (projets ouverts, projets à lancer) :

Ou encore pour définir le périmètre d’un programme stratégique important d’amélioration de l’environnement de travail de l’utilisateur, en collectant et représentant toutes les idées de faire, tous les projets en cours, les besoins exprimés et les besoins urgents :

Reste à laisser aller son imagination…

 

Les treemaps au service de la représentation du système d’information

Sans vouloir réduire l’activité de l’urbaniste des systèmes d’information, il faut bien le dire….L’urbaniste passe une grande partie de son temps à faire des rectangles, entre autre dans l’élaboration des fameux “POS fonctionnels”, sur lesquels nous reviendrons certainement !

Que ce soit avec un crayon, une solution de type bureautique ou une solution de cartographie du système d’information, l’urbaniste fait un jour ou l’autre des boites. Régler les hauteurs, largeurs et autres alignements, devient sa spécialité. Le temps passé dans ces nombreux ajustements, prend le pas parfois sur le temps nécessaire à l’élaboration de représentations justes, expressives et surtout utiles ! D’autant plus lorsqu’il se fait prendre au piège d’une trop grande finesse du “grain fonctionnel”et qu’il se retrouve, bien malgré lui, face à une mosaïque de rectangles peu exploitable sur laquelle, il est bien difficile de revenir.

C’est à l’occasion d’une analyse d’un patrimoine applicatif assez touffu de plus de 550 “applications”, qu’il m’est venu l’idée d’utiliser des cartographies assez expressives, rendues célèbres par la variabilité des tailles des écrans des mobiles : les treemaps. Outil de visualisation déjà ancien, les treemaps peuvent être exploitées dans quantité d’analyses des systèmes d’information, avec pour seule limite, l’imagination de l’analyste ou peut-être la capacité fonctionnelle de la solution utilisée pour les produire.

Dans mon cas, je cherchais à la fois à produire des cartes (….de rectangles) dont la taille et/ou la couleur pouvaient varier en fonction de paramètres divers : nombre d’utilisateurs, nombre d’applications, poids fonctionnels, coûts de maintenance, etc…Mais évidemment, pas question de produire ces cartes à la main.

J’ai utilisé pour cela l’excellent add-in “Sparklines for Excel” qui permet, entre autre, de produire dynamiquement des treemaps. Solution simple, documentée et libre d’usage.

Quelques exemples…

La treemap suivante montre une représentation du nombre d’applications par direction métier (anonymisée ici par “Dir”). La taille des rectangles est proportionnelle au nombre d’applications, la couleur est proportionnelle au nombre d’utilisateurs déclarés pour chaque direction dans l’annuaire.

Dans l’exemple suivant, la treemap montre une cartographie de quelques applications, également anonymisées. La taille des rectangles est proportionnelle au poids fonctionnel de chaque application, la couleur est proportionnelle au nombre d’utilisateurs de l’application.

Dernier exemple, une vision plus “urbanistique” d’un système d’information. Cette carte présente, pour un volume total de 255 applications métier, le nombre d’applications par domaine fonctionnel (la taille des rectangles) pondéré visuellement par le nombre d’utilisateurs de chaque domaine fonctionnel (la couleur).

Reste à exploiter tout cela, car bien entendu, il y a certainement beaucoup à dire.

A vous de jouer….