Partie 4. La dynamique des acteurs

 

acteurs

 

Chapitre 10. Les intervenants et leurs rôles

 

OceanofPDF.com

Chapitre 10

 

Les intervenants et leurs rôles

 

10.1. Les acteurs et les instances

10.1.1. Les acteurs

Les acteurs d'un projet d'urbanisation de système d'information sont présentés dans le tableau 10.1. Il est à noter qu'il s'agit d'acteurs, c'est-à-dire de rôle type, et qu'un acteur ne signifie donc pas nécessairement un poste dans l'entreprise. Par contre, chaque rôle doit être affecté à une personne.

Tab. 10.1

Acteurs Définitions

Responsable des choix, en termes de structure du système

Architecte applicatifs dont les caractéristiques principales sont d'information, permettant de construire un ensemble de blocs applicatif

l'évolutivité,

la réutilisabilité, la maintenabilité et la performance.

Cette personne met en relief l'ensemble des moyens

techniques

et descriptions logiques possibles pour supporter le système

technique d'information. L'architecture technique résulte d'une Architecte

problématique générale exprimée par des enjeux, des

objectifs, des orientations

et des contraintes.

Consultant BPR reconfigure les processus de l'entreprise ou de l'organisme. Le consultant BPR décrit, modélise et éventuellement

Acteurs Définitions

Expert en

Le consultant en conduite du changement réalise le plan

de changement d'accompagnement des utilisateurs. conduite

Le chef de projet de l'étude est désigné pour que soient

menés

Chef de projet à bien les objectifs assignés à l'étude. Il est responsable de l'étude de la cohérence et de l'opportunité des choix entrepris au

cours

de chacune des phases de l'étude.

Le chef de projet métier est issu d'un service utilisateur. C'est

l'utilisateur clé qui sera en mesure de prendre, dans le cadre

de l'étude, toutes les décisions relatives aux caractéristiques

du système de traitement de l'information étudié. Sa mission

est d'aider le chef de projet. Il coordonne les travaux placés

Chef de projet sous

métier la responsabilité des utilisateurs.

Suivant la dimension du système étudié et le nombre

d'organisations métier impliquées, il peut y avoir plusieurs

autres utilisateurs associés à l'étude. Ils constituent alors le

groupe

de travail utilisateur.

L'étude est placée sous la responsabilité du directeur de

l'étude pour que soient menés à bien les objectifs assignés.

 

Directeur Le directeur de l'étude est le seul participant visible lors du succès ou de l'échec de l'étude. Il est l'individu qui est de l'étude responsable

de la coordination au jour le jour du projet et fournit la vision

générale sur le projet.

Direction métier Direction de l'entreprise ou de l'organisme en charge d'une partie de son activité opérationnelle.

DRH Direction des ressources humaines.

 

Direction des Direction de l'entreprise ou de l'organisme en charge du systèmes système d'information. d'information

L'équipe projet est constituée de personnes placées sous la

responsabilité hiérarchique et/ou fonctionnelle du chef de

projet

Équipe d'étude de l'étude. Elle collabore avec celui-ci pour que soient

atteints

les objectifs de l'étude, le nombre et la qualification

de ses participants variant au cours des phases de l'étude.

Équipe en charge des études et des développements

(nouveaux développements, maintenance évolutive,

maintenance corrective) du système d'information. Ces

et développement équipes apportent leur connaissance de l'existant et leur Équipes étude

vision du plan d'action pour converger

vers la cible. Elles sont également très utiles dans le test de

la cible.

Expert métier Il participe à l'étude. L'expert métier connaît parfaitement l'activité de l'utilisateur. Exploitant Le responsable de l'exploitation apporte notamment une vue

informatique objective du système existant.

Le responsable de la sécurité assure la promotion et

Expert sécurité les actions relatives à la sécurité des systèmes de traitement coordonne

de l'information.

Acteurs Définitions

Expert technique et infrastructures choisis pour le système d'information. Définit les règles et normes d'utilisation des différents outils

Désigne un intervenant sur un projet en charge de

l'animation

de groupes de travail et garant de la méthode de conduite

Facilitateur

d'un projet d'urbanisation ; les qualités requises incluent

l'expression orale en groupes de travail élargis, l'animation

d'équipes et la synthèse de travaux de groupes.

Le responsable d'application gère le cycle de vie d'un

système,

après qu'une première version a été installée.

d'application Il détermine si une demande de maintenance ou d'évolution Gestionnaire

doit être traitée immédiatement, si elle peut être mise en

attente

du prochain cycle d'évolution ou si elle doit être rejetée.

Responsable Le responsable assurance qualité assure la promotion et

qualité coordonne les actions d'assurance qualité.

Responsable du comité de direction en charge de favoriser

Sponsor de

l'étude humaines et financières. l'avancée de l'étude d'urbanisation : allocation de ressources

Toute personne susceptible de participer à la définition ou la

Utilisateur mise en œuvre du Plan d'occupation des sols, d'en valider

les résultats ou seulement d'en tirer profit.

 

10.1.2. Les instances Comme tout projet, une étude d'urbanisation de système d'information nécessite un certain nombre d'instances de manière à être maîtrisé et donc à conduire à un succès. Ces instances sont présentées dans le tableau 10.2. Il est à noter que le comité de pilotage de l'étude et le comité de suivi opérationnel sont des instances éphémères dont la durée de vie est celle de l'étude. Les autres instances sont des instances permanentes. C'est le pôle urbanisme et le comité de direction du système d'information qui veillent à la bonne mise en œuvre du plan défini lors de la phase d'étude et réalisent les mises à jour nécessaires de la cible et du plan de convergence.

Tab. 10.2

Instances Définitions

Comité de direction Il agit comme instance suprême pour orienter les travaux de l'entreprise relatifs aux développements et aux évolutions de ou de l'organisme l'entreprise.

Il agit comme instance suprême pour orienter les travaux

Comité de direction relatifs aux développements et aux évolutions de systèmes. du SI Dans une organisation, il n'existe donc qu'un seul comité de

direction du système d'information.

C'est ce comité qui approuve les orientations générales à

caractère technique, fonctionnel et financier (schéma

Comité de direction directeur – plan informatique), répartit le budget par domaine du SI (suite) de gestion, assure la promotion et coordonne au plus haut

niveau les options retenues dans l'entreprise. Il décide des

mises à jour du plan d'urbanisme et du plan de convergence.

Les responsabilités du comité de pilotage sont les

suivantes :

• Faire valider par la direction générale puis diffuser une note

de lancement.

• Fournir toutes les orientations nécessaires à l'équipe

d'étude pour mener à bien sa mission dans le respect du

calendrier prévu.

• Résoudre, le cas échéant, les difficultés liées à la

disponibilité de ressources.

• Assurer les arbitrages de haut niveau.

• Valider les livrables.

Le comité est, en principe, présidé par un utilisateur qui est

Comité de pilotage de l'étude. C'est le directeur du développement ou le le responsable de plus haut niveau concerné par le domaine de l'étude promoteur.

Est typiquement prévu dans le planning de la phase d'étude

un comité de pilotage correspondant à chaque phase clé de

l'étude :

• Revue des axes stratégiques.

• Analyse de l'existant.

• Définition de la stratégie.

• Plan d'actions.

Au-delà de l'étude, une fréquence trimestrielle est

généralement appropriée.

La fin de l'étude est validée par le comité de pilotage et

entérinée

par le comité de direction du système d'information.

Les responsabilités du comité de suivi opérationnel sont les

suivantes :

• Faire un point sur les difficultés rencontrées.

• Gérer le plan d'actions nécessaires à la résolution de ces

difficultés.

• Déterminer les solutions adéquates et éventuellement

Comité de suivi alerter le comité de pilotage s'il le juge nécessaire. opérationnel • Préparer les comités de pilotage.

Ce comité se réunit fréquemment (en général de manière

hebdomadaire) mais a une durée volontairement limitée

(typiquement 1 heure maximum). Il définit les actions à

mettre en œ re po r faire face a diffic ltés rencontrées

mettre en œuvre pour faire face aux difficultés rencontrées

et suit leur avancement, mais il ne traite pas des problèmes

sur le fond.

Instances Définitions

Le pôle urbanisme maintient le SI dans la trajectoire établie.

Ses responsabilités sont les suivantes :

• Instruction des demandes de permis de construire.

• Contrôle de conformité des systèmes livrés par rapport au

permis de construire.

Pôle urbanisme

• Maintenance du référentiel du système d'information.

• Production de documents de cadrage.

• Conseil après des maîtres d'œuvre et des maîtres

d'ouvrage.

• Mises à jour des règles d'urbanisme.

 

10.1.3. Les rôles des acteurs lors de l'étude Les rôles des différents acteurs et instances au cours d'un projet d'urbanisation de système d'information sont synthétisés dans le tableau 10.3 selon la logique RACI.

Tab. 10.3

Analyse Définition

Phases Rev. des axes strat.

de l'existant de la stratégie

de l'étude Planification de l'entreprise métier de la stratégie Compréhension cible vision de la Définition de l'existant Cartographie l'existant Bilan de technologiques opportunités Étude des stratégie de la déclinaison et Orientation des sols d'occupation Plan performances Prévision des cible Organisation et choix scénarios des Évaluation convergence du plan de Finalisation de suivi stratégie de la en place

 

Activités

 

Acteurs

Chef de projet A A A A A A A A A A A A A

Directeur R R R R R R R R R R R R R de l'étude

Équipe d'étude I A A A A A A A A A A A A

Comité I I I I I I I I I I C I I de direction

Direction

I C C C C C C C I I C C I

métier

Utilisateur I C C C C I C I I I C C I Direction

C C C C C C C C C C C C A

des SI

Responsable

I C C C C C C C C C C C C

qualité

Équipe étude

et I A I I I I A C C A I développement

DRH A A A A Comité

de direction I I I I I I I I I I I I I du SI

Sponsor A C C C C C C C C C C C C de l'étude

Chef de projet

C C C C C I C I I I C C I

métier

Pôle

urbanisme

R : est Responsable de. A : est Acteur (c'est-à-dire réalise l'opération). C : est Consulté. I : est Informé.

 

10.2. Les compétences, les techniques et les outils

10.2.1. Les compétences

Les compétences nécessaires pour mener à bien un projet d'urbanisation du système d'information sont multiples :

gestion de projet ;

analyse de risques ;

gestion de la qualité ;

développement de stratégie IS/IT ;

lien stratégie métier/système d'information ;

reconfiguration de processus métier ;

organisation ;

architecture fonctionnelle ;

architecture applicative ;

architecture technique ;

audit applicatif et technique ;

conduite du changement ;

exploitation informatique ;

conduite d'entretiens ;

rédaction de rapports ;

gestion de compétences.

10.2.2. Les techniques

Les techniques suivantes sont fréquemment utilisées dans des projets d'urbanisation de système d'information et sont mentionnées dans la démarche présentée au chapitre 9 :

brainstorming ;

conduite de réunions ;

JAD (Joint Application Design). De manière simple, le JAD est un type de réunion de travail conçu pour

faciliter la transformation d'opinions et de pensées abstraites en accords et décisions pour actions. La base du

JAD est la constitution de réunions de travail pour définir les besoins détaillés de chacun des processus ou des

sous-systèmes. Les participants à chacune de ces réunions de travail sont choisis en fonction de leur expertise

ou leur connaissance sur un ou plusieurs aspects du nouveau système. Les résultats de chacune de ces

réunions de travail sont recueillis par un des participants et sont consolidés avec les résultats d'autres réunions

pour fournir à terme un document de définition des besoins du système. Cette consolidation réalisée en dehors

des réunions de travail a pour difficulté principale la définition d'une vue générale du futur système qui

reprenne les différents points de vue. Cette synthèse peut mettre en évidence des contradictions. Le risque est

d'aboutir à un document qui ne satisfait aucun des intervenants des réunions de travail ;

workshops ;

diagramme d'Ishikawa. Le diagramme d'Ishikawa, encore appelé diagramme cause effet ou diagramme en

arêtes de poisson sert à présenter les causes et les effets qui s'ensuivent. Le premier élément est une flèche

centrale correspondant à l'effet majeur, tandis que les causes liées à ce type d'effet sont représentées sous

forme de flèches dirigées vers l'axe central (flèche signalant l'effet majeur). La flèche indiquant la cause est à

son tour considérée comme un effet, et les causes induisant cet effet sont représentées par des flèches dirigées

vers la flèche de cause/effet en question, etc. ;

RACI. Technique permettant de préciser les rôles des acteurs d'un processus. R indique que l'acteur est

responsable de l'activité, A que l'acteur réalise l'activité, C que l'acteur est consulté lors de l'exécution de

l'activité et I que l'acteur est informé lors de l'activité ;

grille d'analyse multicritère (rosace) ;

analyse de risques ;

QQOQC. Technique permettant de résoudre un problème ou de définir un plan d'actions pour le résoudre. Elle

consiste à se poser les cinq questions suivantes : Quoi ? Qui ? Où ? Quand ? Comment ?

SWOT. Technique permettant l'analyse critique d'une stratégie ou d'un processus. Elle consiste à se poser

quatre questions (Quelles sont les forces ? – Strenghts – Quelles sont les faiblesses ? – Weaknesses – Quelles

sont les opportunités ? – Opportunities – Quelles sont les menaces ? – Treathts) ;

balanced score card ;

benchmarking (banc d'essai) ;

modélisation de processus ;

modélisation de données ;

modélisation d'architectures ;

audit ;

analyse d'écart ;

planification de projet.

Ces techniques font l'objet d'une littérature assez abondante à laquelle le lecteur pourra si nécessaire se reporter. 10.2.3. Les outils

Les outils utilisés sur tout projet d'urbanisation de système d'information relèvent des deux types suivants :

outil de gestion de projet. Un projet d'urbanisation du système d'information doit, comme tout projet, faire

l'objet d'une planification et d'un suivi de projet. Cet outil étant un outil standard indépendant des

caractéristiques de ce type d'étude, il n'est pas nécessaire de le décrire plus amplement ;

outil de modélisation des processus, des architectures et des données.

La démarche méthodologique et l'expertise des intervenants externes et internes sont les facteurs fondamentaux de succès pour les études d'urbanisation. Cependant, l'outillage est aussi un facteur de première importance pendant la mission, puis pour faire vivre le référentiel constitué durant l'étude. Pour ce type de projet, il est donc indispensable de s'appuyer sur un outil de génie logiciel du marché. Il n'est pas ici question de se lancer dans un comparatif des outils du marché puisque des instituts sont spécialisés dans ce domaine mais, plus modestement, de définir les apports et les fonctionnalités attendues de ce type d'outil. L'outil idéal doit être basé sur un véritable référentiel intégré, fiable, souple et extensible. Il doit couvrir la modélisation et la simulation de processus et la modélisation d'architectures et supporter UML de manière à faire le lien avec les projets de conception et de développement par composants de systèmes d'information (c'est-à-dire la construction d'un immeuble prévu dans le plan de la ville).

Fonctionnalités de modélisation et de simulation de processus Ce module de l'outil doit permettre de :

définir les business models avec tous les intervenants impliqués et garantir la cohérence ;

aider à détecter facilement et rapidement les potentiels d'amélioration des processus existants ;

construire rapidement les nouveaux processus ;

comparer plusieurs scénarios d'organisation : quantifier les ressources humaines et informatiques nécessaires,

évaluer la durée des processus;

guider l'utilisateur dans toutes les phases du projet par le support de la démarche méthodologique via des

outils graphiques intuitifs ;

garantir le partage et la cohérence des informations.

Fonctionnalités de modélisation des architectures

Ce module de l'outil doit permettre de :

supporter les concepts d'urbanisme de la méthodologie ;

présenter un système d'information complexe et étendu ;

prendre en compte l'intégration d'applications ;

représenter le découpage fonctionnel d'une application ;

intégrer la dimension interne dans l'architecture applicative ;

formaliser les flux d'information ;

décrire une architecture fonctionnelle ;

décrire une architecture applicative ;

décrire une architecture technique ;

référencer des informations extérieures ;

analyser les impacts des modifications d'architecture.

Doit-on utiliser UML ?

Tout d'abord, il convient de noter que les méthodes et techniques présentées dans cet ouvrage ne sont liées à aucune technique de modélisation et sont probablement applicables quelle que soit la technique de modélisation retenue.

Le langage de modélisation unifié est devenu un standard du marché après avoir été standardisé par l'OMG en 1997. L'évolution vers UML est certes lente, mais à la fois réelle et inéluctable. Il faut d'ailleurs s'en féliciter. C'est en effet la première fois qu'un standard mondial se présente en termes de technique de modélisation, amenant ainsi une offre extrêmement abondante et compétitive d'outils de génie logiciel permettant un réel approvisionnement concurrentiel. Par ailleurs, le respect d' UML apporte un bon niveau d'interopérabilité entre outils de conception, ce qui, conjugué à la baisse des prix (par comparaison aux AGL de conception d'il y a dix ans), rend le choix de l'outil beaucoup plus réversible et donc beaucoup moins stratégique qu'auparavant. Certains font remarquer, à juste titre que UML :

est perfectible ;

n'offre pas grand-chose pour la validation de la cohérence des modèles ;

présente une faiblesse chronique pour la modélisation de l'organisation ;

n'offre aucun mode d'emploi.

Tout cela est vrai. Mais UML évolue et se clarifie ou s'enrichit, et divers modes d'emploi sont proposés par différents éditeurs ou sociétés de services et d'ingénierie informatique. Les vraies questions sont donc, en ce qui concerne le projet d'urbanisation du système d'information :

Peut-on tout faire en UML ?

Est-ce la meilleure façon de procéder ?

À la première question, la réponse est clairement positive.

Modélisation des processus en UML

On peut modéliser des processus en UML en s'appuyant sur l'un des diagrammes suivants :

le diagramme de séquence ou son frère jumeau le diagramme de collaboration ;

le diagramme de cas d'utilisation ;

le diagramme d'activité.

À titre d'exemple, les quatre figures suivantes présentent le processus de réservation actuel (voir chapitre 6.5.2) selon ces différents formalismes UML.

Par contre, il faut bien reconnaître que ces modèles permettent de réaliser des modèles de processus mais n'aboutissent pas aux modèles les plus clairs et donc les plus aisément « validables » par les personnes concernées. Le modélisateur doit contourner certaines difficultés, et notamment :

le diagramme de séquence (ou le diagramme de collaboration) correspondant normalement à un scénario ne

comporte a priori pas d'alternatives conditionnelles, chacune d'entre elles correspondant à un scénario donc à

un diagramme différent. Il est alors indispensable de trouver une astuce graphique ou textuelle (non

interprétée par l'outil) pour contourner ce problème. Il oblige également à identifier les classes concernées par

le déroulement de chaque activité.

Les figures 10.1 et 10.2 représentent respectivement le processus de réservation actuel sous forme d'un diagramme de collaboration et d'un diagramme de séquence.

 

Fig. 10.1

Fig. 10.2

 

le diagramme des cas d'utilisation permet de représenter chaque activité d'un processus comme un cas

d'utilisation et de montrer qui fait quoi. Par contre, il est difficile de représenter (sauf à passer par du texte ou

du graphique non interprétables par l'outil) l'enchaînement des activités. Ce diagramme permet aussi de

montrer sur un même schéma l'ensemble des processus, mais il peut devenir vite illisible dans le cas où

plusieurs acteurs communiquent avec chaque processus. Enfin, comme les diagrammes de séquence et de

collaboration, il oblige également à identifier les classes concernées par le déroulement de chaque activité.

La figure 10.3 représente le processus de réservation actuel sous forme de cas d'utilisation.

 

Fig. 10.3

 

le diagramme d' activité est celui qui permet sur le plan graphique de se rapprocher le plus d'un modèle de

processus tel que préconisé dans la méthode proposée. Par contre, des différences d'implémentions existent

d'un outil UML à un autre.

La figure 10.4 représente le processus de réservation actuel sous forme d'un diagramme d'activité.

Fig. 10.4

Enfin, pour la modélisation de processus, d'autres standards (limités aux processus) concurrencent UML et notamment BPML et BPMN (liste non exhaustive). Le premier (BPML = Business Process Modeling Language) permet la description de l'implémentation interne d'un processus exécutable à des fins de composition ou d'orchestration de services. Le second (BPMN = Business Process Modeling Notation) permet la représentation graphique des processus et leurs annotations avec des statistiques.

Modélisation des architectures en UML

Pour la modélisation des architectures, les concepts clés de la méthode préconisée (zones, quartiers, îlots) peuvent être implémentés via la création de stéréotypes de paquetage. Les architectures fonctionnelle et applicative peuvent être représentées par des modèles de classes dans lesquels on représente les zones, quartiers et îlots par les stéréotypes de paquetage correspondant et les flux entre paquetages par des diagrammes de séquences dans lesquels les colonnes sont les paquetages et les flux représentés par les flèches. L'architecture technique peut quant à elle être modélisée à l'aide des diagrammes de déploiement et de composant qui permettent moins de possibilités graphiques qu'un outil bureautique de réalisation de support de présentation mais qui permettent de rester dans l'outil.

Conclusions sur l'outil

Nous avons montré qu'un outil de conception du marché supportant UML permet de mener à bien ce type de projet, et ce d'autant mieux que son implémentation du diagramme d'activité permet de modéliser au mieux les processus.

Les alternatives à l'utilisation d'un outil UML sont :

l'utilisation d'un outil dédié à la modélisation des organisations ne supportant pas ou peu (c'est-à-dire offrant

une interface) UML. Cette alternative est intéressante lorsque le projet est essentiellement axé sur une

reconfiguration de processus. Par contre, elle présente l'inconvénient majeur d'aboutir à deux référentiels, l'un

décrivant l'organisation, l'autre le système informatique supportant cette organisation.

Dans ce cas de figure, il est intéressant de se baser sur un standard comme par exemple BPMN ou BPML ;

l'utilisation d'un outil de modélisation intégrant en plus d'UML et au sein d'un même métamodèle, des

concepts et des modèles spécifiquement adaptés à la modélisation de l'organisation et des processus. C'est a

priori la solution idéale pour mener à bien un projet d'urbanisation de système d'information. En effet, un tel

outil présente un avantage essentiel pour la modélisation de processus et pour la modélisation d'architectures

par rapport aux autres outils supportant uniquement UML. Les modèles proposés sont beaucoup plus clairs et

donc « validables » (en particulier validation des modèles de processus avec les maîtrises d'ouvrages) que s'ils

sont réalisés en UML, tout en offrant un lien, géré dans le référentiel, entre les concepts manipulés dans ces

modèles et les concepts UML manipulés dans la conception et le développement de systèmes qui peut suivre.

En fait, l'outil offre alors, en une seule suite logicielle, les fonctionnalités d'outils dédiés à la modélisation de

processus et les fonctionnalités d'un AGL (atelier de génie logiciel) UML, ce qui évite les problèmes

d'interfaçages entre les deux types d'outils.

Enfin, pour le choix d'un outil pour un projet d'urbanisation donné, il faut bien évidemment tenir compte des éventuels outils déjà utilisés au sein de l'entreprise ou de l'organisme et du bilan économique global (acquisition, formation, courbe d'apprentissage, maintenance) du choix de l'AGL.

 

10.3. Réinventer les relations entre maîtrise d'ouvrage et maîtrise d'œuvre

10.3.1. L'historique

Les relations entre maîtrise d'ouvrage et maîtrise d'œuvre ont évolué dans le temps, recherchant un équilibre jamais réellement atteint. On peut distinguer quatre grandes périodes dans l'histoire de ces relations :

le règne de l'informatique ;

l'enfance des maîtrises d'ouvrages ;

l'âge adulte des maîtrises d'ouvrages ;

la transition vers l'ère de la sagesse.

La première période, qui couvre les deux décennies des années 1960-1970, est caractérisée par l'informatisation des tâches administratives répétitives et par l'absence de véritable réflexion stratégique. C'est aussi l'époque de l'informatique surpuissante qui se voyait confier tous les projets et qui profitait de l'absence de culture informatique des utilisateurs pour régner sans partage. En réalité, il n'y avait pas de réelle maîtrise d'ouvrage. C'est le règne de l'informatique.

La deuxième, qui correspond au milieu des années 1980, est caractérisée par la mise en place de maîtrises d'ouvrage par projets. Devant les échecs de certains projets informatiques, les directions métier ne pouvant plus uniquement rejeter la responsabilité des échecs sur l'informatique ont pris conscience de la nécessité d'une réelle implication sur les projets critiques. Ces maîtrises d'ouvrages de projets ont mis en place sur les projets des chefs de projet utilisateurs (CPU) ou des directeurs d'application utilisateurs (DAU). Selon les organisations et la culture des entreprises et/ou organismes, le rapport de force maîtrise d'ouvrage/maîtrise d'œuvre pouvant pencher d'un côté ou de l'autre. La maîtrise d'ouvrage d'un projet était schématiquement responsable de la rédaction du cahier des charges, du pilotage des ressources utilisateurs et de la recette des applications. C'est l'enfance des maîtrises d'ouvrage.

La troisième période, qui couvre le milieu des années 1990, correspond à une prise de conscience du besoin d'une vision globale et non plus projet par projet de la maîtrise d'ouvrage. Cette prise de conscience a été pour l'essentiel provoquée par l'informatisation de l'ensemble des domaines des entreprises ou organismes. C'est à cette époque que les directions des systèmes d'information succèdent aux directions informatiques, que les comités de direction du système d'information se créent et que le pouvoir concernant le système d'information bascule souvent du côté des directions métier. C'est l'âge adulte des maîtrises d'ouvrage. La quatrième période, qui a commencé à la fin des années 1990, est l'ère de l'entreprise collaborative. C'est un début de transition vers l'ère de la sagesse, du moins l'espère-t-on. On sort progressivement du schéma classique dans lequel le maître d'œuvre propose quelque chose sur lequel le maître d'ouvrage doit se prononcer par écarts.

La distinction classique entre maître d'ouvrage et maître d'œuvre reste pour la mise en œuvre du plan d'urbanisation et pour ses différentes mises à jour, pas pour son élaboration. Durant l'élaboration, il n'y a qu'une seule équipe d'étude avec toutes les compétences nécessaires, c'est-à-dire à la fois des compétences métier et des compétences en organisation, en conduite du changement et en informatique. C'est fondamental, et si cette condition n'est pas réunie, on retombe alors quasiment inévitablement vers des études de type schémas directeurs classiques.

10.3.2. Le nouvel enjeu : la transition vers l'ère de la sagesse Dès lors, un nouvel enjeu apparaît pour ce type d'étude. C'est en effet l'occasion de réinventer l'articulation des travaux entre maîtrise d'ouvrage et maîtrise d'œuvre, en théorie pour la durée de l'étude, mais qui va bien au-delà car, en cas de succès, rien ne peut plus être comme avant. Il s'agit finalement de passer de l'apartheid à la cohabitation. Travaillant ensemble, la maîtrise d'ouvrage et la maîtrise d'œuvre se comprennent mieux et, par conséquent :

définissent ensemble de meilleures solutions pour l'entreprise ou l'organisme ;

se renvoient moins la balle en cas de difficultés.

La direction des systèmes d'information développe et fait vivre les applications informatiques alors que les directions métier définissent leurs ressources, y compris informationnelles, et veillent à disposer des bons outils au bon moment.

La maîtrise d'œuvre n'a pas le monopole de la création de valeur dans le système d'information ! La maîtrise d'ouvrage se décompose souvent en une maîtrise d'ouvrage stratégique et une maîtrise d'ouvrage opérationnelle.

La MOA stratégique, généralement assurée par un « comité de direction du système d'information », porte la vision métier. Le comité de direction du système d'information est une instance de décision qui réunit le responsable du métier et ses principaux collaborateurs directs ainsi que les responsables de la maîtrise d'œuvre. Se réunissant tous les deux ou trois mois, il prend des décisions sur :

l'orientation du système d'information en fonction de la stratégie métier ;

le lancement ou l'arrêt des projets stratégiques ;

la validation des étapes majeures des projets stratégiques ;

l'organisation de la maîtrise d'ouvrage opérationnelle.

C'est donc ce comité qui, avec l'appui du pôle urbanisme, a la responsabilité de veiller à ce que le plan d'urbanisme soit exécuté et de décider des mises à jour de la cible et, par conséquent, du plan de convergence. À l'image des grandes villes, on peut distinguer deux niveaux de gouvernance des systèmes d'information dans les grandes entreprises ou les grands organismes : le niveau ville et le niveau arrondissement. On peut donc avoir un comité de direction du système d'information pour la ville et un comité de direction du système d'information par arrondissement. L'implication de la direction générale dans le comité de direction du système d'information global de l'entreprise est fondamentale, à la fois parce que des décisions stratégiques sont à prendre et parce qu'il n'est pas naturel pour un directeur métier de consacrer du temps à son système d'information, même si c'est pour son bien. La participation de la direction générale induit une participation plus assidue des autres directions métier. La MOA opérationnelle  est la cheville ouvrière de la MOA stratégique. Elle assure la traduction de la vision métier en axes d'évolution du système d'information. Elle définit et modélise les processus métier, rédige les cahiers des charges et recette les applications.

Les responsabilités de la MOA sont les suivantes :

piloter : s'assurer du financement du projet, structurer ses équipes et fixer le cadre des travaux confiés aux

maîtres d'œuvre, les informer des règles et contraintes à prendre en compte, suivre l'avancement du projet,

définir puis surveiller le retour sur investissement, surveiller la cohérence avec la stratégie de l'entreprise ;

élaborer : définir les objectifs, les enjeux et les besoins fonctionnels correspondants ;

recetter : assurer la recette du système global dans le cadre de l'organisation cible ;

conduire le changement : définir et mettre en place l'organisation cible, s'assurer de la formation et de la

communication avec les utilisateurs.

Les cartographies (métier, fonctionnelle, applicative et technique) réalisées dans le cadre du projet d'urbanisation fournissent le moyen de répartir les responsabilités entre maîtrise d'ouvrage et maîtrise d'œuvre et, dans une certaine mesure, à l'intérieur de chacune d'elles sur la base d'un référentiel clair commun et partagé. Par exemple :

les processus étant cartographiés dans le cadre de la cartographie métier, on peut nommer un responsable par

processus qui a un périmètre bien délimité et des flux avec les autres processus identifiés et décrits ;

les zones, les quartiers, les îlots et leurs prises étant clairement définis, on peut attribuer la responsabilité d'un

de ces blocs à une entité organisationnelle donnée.

Bien entendu, si les cartographies sont un excellent outil pour préciser les périmètres de responsabilité de chacun durant l'étude, il faut être vigilant car, sous l'apparence de questions plus ou moins techniques peuvent se cacher des inquiétudes davantage liées à la répartition des périmètres. Mais ce n'est pas une raison pour rester dans le flou, et l'apport pour l'organisation des cartographies réalisées dans le cadre d'un projet d'urbanisation de système d'information est donc très largement positif.

 

10.4. Le rôle et l'organisation du pôle urbanisme Le pôle urbanisme peut prendre différentes formes selon l'entreprise ou l'organisme concerné : il peut s'agir d'un service, d'une cellule d'un bureau ou encore d'une division. Le terme « pôle » désigne une entité de l'organisation apte à remplir de manière pérenne (en effet, cette entité doit être pérenne et non pas fonctionner au coup par coup) les missions d'un pôle urbanisme telles que définies ci-après.

10.4.1. La finalité

La finalité du pôle urbanisme est de maintenir le système d'information dans la trajectoire établie en évitant que des projets successifs viennent « casser » l'urbanisme mis en place progressivement et réviser périodiquement la cible et le plan de migration.

10.4.2. Les missions

Le pôle urbanisme a en charge les dix missions essentielles suivantes :

élaborer et réviser le cadre de référence de l'urbanisme des S.I. ;

piloter l'urbanisation du système d'information ;

instruire les demandes de permis de construire ;

contrôler la conformité aux plans des réalisations ;

maintenir et diffuser le référentiel du système d'information ;

conseiller maître d'ouvrage et maître d'œuvre ;

contribuer aux instances d'arbitrage des projets ;

mettre sous contrôle les référentiels de données ;

standardiser et simplifier les échanges ;

développer les compétences.

L'élaboration et la révision du cadre de référence de l'urbanisme des S.I. Toute démarche d'urbanisation de S.I. en entreprise doit s'appuyer sur un cadre de référence précis comprenant :

les principes d'urbanisme et les perspectives à traiter ;

les concepts et outils sur lesquels se fonde la démarche d'urbanisation ;

un corpus de règles ;

les acteurs et les instances de pilotage de l'urbanisme et les règles de gouvernance liées à l'urbanisme ;

la démarche d'urbanisation, ou comment mener une étude d'urbanisation.

L'élaboration et la révision du cadre de référence sont bien évidemment de la responsabilité du pôle urbanisme. Le pôle urbanisme doit également produire des documents de cadrage permettant aux chefs de projets de déposer des demandes de permis de construire, de modification de permis de construire, des déclarations de travaux ou encore des demandes de permis de démolir qui seront acceptées parce qu'elles respectent l'ensemble des règles d'urbanisme.

Le pôle urbanisme veille aux normes avec les chefs de projets. Avec eux, il met en place des « contrats d'urbanisme » dans le respect des règles d'urbanisme, c'est-à-dire les normes fonctionnelles et techniques sur l'emplacement des données, leur mise à jour, etc.

Le pilotage de l'urbanisation du système d'information

Lorsque nécessaire et suite à une décision du comité directeur du système d'information, une mise à jour de la cible et donc du plan de convergence peut être décidée. Ce type de situation se produit lorsqu'un ou plusieurs facteurs internes ou externes à l'entreprise ou à l'organisme amènent à réviser la stratégie de manière significative. Il faut alors en déduire les mesures de réalignement du SI cible et de la trajectoire de convergence. Le pôle urbanisme a alors en charge le pilotage de cette mise à jour. Le pôle suit aussi l'avancement du programme de convergence vers la cible.

L'instruction des demandes de permis de construire (obligatoire avant le lancement de tout projet)

Comme pour un bâtiment, il est indispensable, si l'on veut imposer des règles d'urbanisme, de s'assurer a priori du respect de ces règles sur la base d'une description précise du projet.

Le demandeur doit donc déposer une demande de permis de construire précisant clairement le projet envisagé en termes de finalité, d'objectifs, de périmètre, de positionnement par rapport au plan d'occupation des sols, de respect des différents standards ou normes.

Le pôle urbanisme étudie le dossier et soit :

attribue le permis de construire dans le cas où toutes les règles sont respectées ;

refuse le permis de construire et expose les raisons du refus qui ne peuvent être que le non-respect d'une ou

plusieurs règles.

Plus exceptionnellement, le pôle urbanisme peut accorder une dérogation ou bien compléter ou amender le règlement.

Ensuite, si, en cours de projet, il est nécessaire de modifier l'un des éléments du dossier ayant permis l'obtention d'un permis de construire, le projet doit déposer une demande de permis de construire modificatif qui, lui aussi, peut être accepté ou refusé de manière motivée.

Pour un projet de maintenance, on parle de déclaration de travaux plus que de permis de construire, mais les mêmes principes s'appliquent.

Pour les applicatifs à supprimer, on parle de permis de démolir mais là aussi, les mêmes principes s'appliquent. Le contrôle de conformité par rapport aux plans du permis de construire en fin de développement

En fin de développement et avant la mise en service du nouvel applicatif ou de l'applicatif modifié, le pôle fait une visite dite de conformité, c'est-à-dire qu'il vérifie que l'applicatif réalisé est conforme au permis accordé et à ses éventuels modificatifs acceptés.

La maintenance et la diffusion du référentiel du SI constitué lors de l'étude d'urbanisation Les différentes cartographies réalisées lors de l'étude et saisies dans le référentiel de l'outil de conception retenu constituent un actif précieux pour l'entreprise ou l'organisme, permettant notamment :

des analyses d'impacts rapides et fiables ;

la maîtrise du système d'information ;

la formation rapide de nouveaux intervenants sur le système d'information.

Sans une mise à jour et une diffusion régulières, les informations contenues dans ce référentiel deviennent vite non fiables et même obsolètes. Il faut donc consacrer peu de temps mais de manière régulière pour conserver toute sa valeur à cet actif.

Rappelons que toutes les cartographies ne sont pas réalisées sur chaque projet d'urbanisation de système d'information mais que, dans le cas extrême, il peut y avoir jusqu'à trois cartographies (métier, applicative et technique) pour décrire le système d'information existant, quatre (métier, fonctionnelle, applicative et technique) pour décrire le système d'information cible et, pourquoi pas, quatre cartographies pour décrire chacun des paliers permettant de converger vers un système d'information cible.

Le conseil

Avec les maîtrises d'ouvrages, l'urbaniste joue un rôle de conseil. Il les aide à voir la valeur ajoutée métier de leurs besoins fonctionnels, à cadrer ces derniers par rapport au schéma stratégique mis en place par l'entreprise ou l'organisme et à les classifier. Assurant une veille technico-fonctionnelle du marché, il les informe des meilleures pratiques.

Avec les maîtrises d'œuvre, il apporte également au quotidien de l'assistance et de la valeur ajoutée aux projets. La contribution aux instances d'arbitrage des projets

Le pôle urbanisme pilote les instances dédiées à l'architecture et à l'urbanisme et participe en plus aux instances d'arbitrage des projets dans lesquelles il apporte l'un des éclairages permettant la prise de décision. La mise sous contrôle des référentiels de données

Le pôle urbanisme pilote l'identification et la définition des principaux référentiels de données (et éventuellement de règles). Il s'assure en particulier que le contenu, les responsabilités, les modalités de fonctionnement et les niveaux de service et de sécurité sont correctement définis et pilotés dans le temps. Il est également le garant de la bonne articulation des référentiels entre eux et avec le reste du S.I..

La standardisation et la simplification des échanges

Le pôle urbanisme pilote l'identification et la définition des principaux flux, de la définition des standards d'échange et éventuellement de la mise en place de solutions automatisées d'échanges. Le développement des compétences

Les compétences étant peu nombreuses, le pôle urbanisme doit avec l'appui de la direction des ressources humaines s'attacher à les développer, à les attirer et à les retenir.

10.4.3. Les écueils

Il n'entre pas dans la mission du pôle urbanisme :

de devenir un auditeur interne ;

de se prendre pour un décideur ;

de jouer les concepteurs ou les développeurs.

En réalité, pour réussir, le pôle urbanisme doit se limiter à remplir strictement les missions énumérées précédemment.

Il n'audite pas les projets, que ce soit sur le plan :

fonctionnel ;

technique ;

méthodologique ;

du pilotage.

Il n'a pas non plus à prendre d'autres décisions que d'accepter ou de refuser de manière motivée des demandes de permis de construire, de permis de construire modificatif, de permis de démolir, de déclaration de travaux sur la base d'un contrôle technique par rapport aux règles en vigueur. Il ne décide donc pas du lancement ou de l'arrêt des projets, ni même de la validation des applicatifs, même si ses décisions pèsent lourd dans le choix des décideurs. Enfin, même si le pôle urbanisme joue un rôle de conseil auprès de la maîtrise d'œuvre ou de la maîtrise d'ouvrage, il ne doit pas se substituer à eux. Il ne doit donc pas participer directement à la conception ou au développement des applicatifs.

10.4.4. L'organisation

Le rattachement

Force est de constater que le pôle urbanisme est souvent rattaché à la direction des Systèmes d'Information. Pourtant, il est préférable que l'urbaniste soit directement rattaché à la direction générale. Il assure le lien entre la stratégie d'entreprise qui relève par définition de la direction générale et le ou les systèmes d'information. Gardien du temple, il assure la cohérence de ce (ou de ces) derniers. La reconnaissance de la fonction dans l'entreprise est plus grande lorsqu'il est directement rattaché à la direction générale et qu'il accomplit sa mission dans une structure où l'informatique est au cœur du métier.

La composition

Le pôle urbanisme est exclusivement composé d'urbanistes qui s'appuient, si nécessaire et donc ponctuellement, sur d'autres acteurs parmi les types d'acteurs nécessaires dans l'équipe de projet d'urbanisation du système d'information.

L'équipe de projet d'urbanisation du système d'information met en jeu trois types d' acteurs :

des acteurs typiquement issus des directions métier et capables d'appréhender globalement la problématique

métier et de comprendre la démarche d'alignement ;

des acteurs capables d'aligner les processus et le système d'information sur la stratégie métier. Ce sont les

urbanistes ;

des acteurs capables d'aligner système d'information et système informatique. Ce sont les professionnels de

l'informatique et des NTIC (nouvelles technologies de l'information et des communications). Ce sont les

architectes fonctionnels et techniques.

Si les profils des architectes fonctionnels et techniques sont des profils bien connus car relativement anciens, le profil de l'urbaniste est en revanche à la fois plus récent et plus mal défini, comme d'ailleurs celui de l'urbaniste de la cité par rapport aux architectes en bâtiment. Il convient donc de s'attacher à définir le profil de ce nouveau métier.

L'urbaniste doit idéalement posséder :

une solide connaissance des systèmes d'information ;

une bonne connaissance du secteur d'activité ;

une expérience concrète du métier de la direction pour laquelle il opère ;

des capacités de conceptualisation et de modélisation ;

un bon esprit de synthèse ;

le sens de la négociation.

Souvent, on ne trouve pas le mouton à cinq pattes. Il faut se contenter de moutons à quatre pattes et les former. Il faut aussi penser à retenir ce collaborateur à fort potentiel, et donc proposer une valorisation du poste et des évolutions de carrières attractives.

Le dimensionnement du pôle urbanisme varie sensiblement d'une entreprise à une autre mais, pour fixer les idées, on constate typiquement qu'une équipe de deux à huit personnes peut remplir l'ensemble des missions d'un pôle urbanisme décrites dans cet ouvrage.

OceanofPDF.com