Un article qui part de la gestion de projet et de l'architecture d'entreprise en contradiction pour emmener sur la nécessité de la maîtrise d'ouvrage du système d'information.
Les serious games - Mémoire de master en Sc. Educ de Bernard Lamailloux
Article - Augmenter la valeur du système d'information
1. Augmenter la valeur du SI
Diminuer le coˆ t, am´ liorer les d´ lais, r´ pondre aux enjeux strat´ giques
u
e
e
e
e
Franck Rinaudo
Aix-en-Provence, le 10 décembre 2013
2. Préambule
E
couverture de ce document, La Grande Vague de Kanagawa (1831) de Hokusai. Vous retrouverez dans ce
document une grande partie de la symbolique présente dans cette estampe.
N
Une estampe est créée à partir d’un dessin qui servira de patron pour la gravure dans des planches qui seront à leur tour utilisées par des imprimeurs. Il est à noter que le dessin original est détruit dans la phase de
gravure et qu’il est rarement possible d’utiliser les mêmes planches plus de 300 fois. La notion d’estampe originale correspond donc à la série d’estampes du premier dessin original. Il s’agit d’un procédé en quelque sorte
semi-industriel pour lequel l’auteur du dessin original suivra toutes les étapes de fabrication afin de s’assurer de
l’intention mais les étapes de gravure et d’imprimerie seront réalisées par des artisans spécialisés. L’auteur est
donc maîtrise d’ouvrage de l’estampe.
Dans La Grande Vague de Kanagawa, Hokusai capte l’aspect fractal, avant même que le mot n’existe, de la vague
dont le motif s’apparente au triangle. En outre, vous constaterez que si vous ne considérez que le contour de la
mer et le reste de l’estampe, vous verrez apparaître deux formes imbriquées à la manière du Yin et Yang.
Enfin, un fait fascinant et non intuitif est que le sens de lecture occidental nous donne une perception faussée
de l’œuvre : Nous voyons la vague à la poursuite des pêcheurs alors que l’intention de Hokusai et la lecture dans le
sens oriental montre des pêcheurs allant au devant de la vague. Ainsi en fonction de la culture avec laquelle vous
abordez l’estampe, votre parcours visuel s’arrêtera d’abord sur la vague ou d’abord sur les pêcheurs. Ce biais vous
pousse à donner encore plus d’importance à la vague en tant que sujet que ne le voulait l’auteur, plutôt qu’en
tant qu’obstacle à braver par les pêcheurs 1 .
Prenons toujours garde d’adapter notre sens de lecture et d’écriture, et de ne pas nous tromper de sujet. Car
nous ne sommes pas seulement occidentaux. Nous sommes, entre autres mais pour beaucoup, des informaticiens.
Objectifs du document
La gestion de projet est un métier à part entière. Tout comme l’architecture et l’urbanisation. Or, si dans de
nombreuses cultures l’unité de transformation de l’entreprise et du système d’information est le projet, force est
de constater que peu de liens concrets sont établis entre les disciplines de la gestion de projet et de l’urbanisation
du SI 2 .
Pourquoi les passerelles entre les disciplines d’urbanisation du SI et de la gestion de projet n’existent pas de manière pragmatique ? Selon les méthodes actuellement plébiscitées, les chefs de projets pilotent dans le périmètre
défini de leur projet par le coût, le délai et la qualité jusqu’à la livraison. Mais qu’en est-il de la phase d’exploitation ? Du coût total de possession ? La somme des succès de ces projets informatiques est-elle la garantie du
succès pour le système d’information ?
Tout en puisant dans la culture populaire, nous reviendrons sur les notions structurantes des disciplines d’urbanisation et de gestion de projet dans un contexte de gouvernance du SI. Puis nous mettrons en évidence leurs
contradictions, avant de trouver un motif commun. Nous conclurons par la nécessité de définir les rôles d’une
maîtrise d’ouvrage du SI pour laquelle nous proposerons des actions à mener.
1. Un biais qui aura notamment poussé une célèbre marque de sportswear d’origine Australienne à faire de cette vague sur fond de montagne
son logo. Une vague qui, pour nous occidentaux, avance.
2. Système d’Information
2
4. 1 Retour d’expérience sur les disciplines à l’origine de la
démarche
« Lorsque tu ne sais pas où tu vas, regarde d’où tu viens »
Proverbe Sud-Africain
1.1 A propos de l’urbanisation du SI
1.1.1 Origine et objectifs
’urbanisation du SI est une discipline transverse du système d’information. Son émergence est due au constats
suivants :
– L’entreprise du XXIe siècle est dépendante de, et structurée par son SI.
– Le patrimoine informatique, notamment celui hérité du siècle dernier, résulte de l’empilement de générations successives d’applications comportant des redondances, des interdépendances et manquant de cohérence.
– La complexité de ce patrimoine va croissant et génère des difficultés de plus en plus grandes pour atteindre
les objectifs métiers.
L
Pour répondre à cette situation les entreprises ont développé les approches d’urbanisation du SI, ayant pour
objectifs de
– faciliter l’évolutivité et l’adéquation des SI vis-à-vis des processus,
– mettre en évidence les fonctions transverses ou communes, les partager,
– renforcer la cohérence des SI.
F IGURE 1.1: L’objet de la modélisation est d’examiner l’entreprise sous différents points de vue, tout comme ici
on examine un arbre.
Les disciplines d’urbanisation du SI et d’architecture d’entreprise s’appuient fortement sur l’activité de modélisation et cartographie, ce quel que soit le framework utilisé. On trouve donc dans TOGAF[5], chez Club UrbaEA[2], dans Praxeme[1] ou chez Longépé[6], l’abord et la modélisation de l’entreprise sous plusieurs “prismes”,
que l’on nomme couches ou aspects selon les méthodologies. Toutes ces méthodes ont en commun un approche
top-down, en partant notamment de la stratégie de l’entreprise jusqu’à l’implémentation technique pour répondre à cette stratégie.
4
5. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Ce qu’il faut retenir ! L’urbanisation répond au besoin d’adaptation rapide de l’entreprise, cherche
à diminuer la complexité du SI pour diminuer les coûts associés ou à augmenter la capacité à faire en
fonction de la situation.
Comme nous l’avons dit, l’urbanisation a pour objectif la diminution de sa complexité globale par la transformation de celui-ci en un système plus facilement modifiable. L’architecture d’entreprise tend à être la projection
sous plusieurs prismes du fonctionnement d’une entreprise tenant compte de l’omniprésence du système d’information. Les deux disciplines ont en commun une vision stratégique du SI, à savoir l’objectif de définition d’une
cible cohérente avec la stratégie générale et d’un chemin pour y parvenir. Mais là où l’urbanisation est centrée sur
le SI, l’architecture d’entreprise étend son périmètre à l’entreprise, ses membres compris. Dans la suite de ce document, on parlera d’urbanisation du SI, mais plusieurs préoccupations relèveront de l’architecture d’entreprise
sans que la distinction soit faite.
5
6. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
F IGURE 1.2: Catalogue des représentation du framework Zachman[8], considéré comme le premier framework
d’architecture d’entreprise
F IGURE 1.3: Cycle de développement de l’architecture TOGAF 9[5], la référence de l’architecture d’entreprise
anglo-saxonne
F IGURE 1.4: Modèle en couche des objectifs métiers aux infrastructures défini par Christophe Longépé et inspiré
par Jacques Sassoon[7]
6
7. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
1.1.2 Fondement scientifique
dans le fait qu’elles demandent une décomposition du
système et donc une orientation solution.
La méthode des points de fonctions permet de faire des
estimations plus fiables que les méthodes par décomposition et chiffrage linéaire à partir du moment ou le
système est suffisamment grand et complexe.
Les systèmes complexes
L’abord de la complexité d’un système est traité en
sciences dans le champ de la théorie des systèmes complexes.
Un système est un ensemble cohérent de composants
Un fait perturbant est que le modèle est en apparence
plus simple que le modèle cartésien : on a coutume de
dire dans l’approche systémique que le tout est à la fois
grand nombre d’entités en interactions locales et
plus et moins que la somme des parties. La significasimultanées.
tion de ce détournement des propos d’Aristote exprime
La méthode cartésienne, à savoir la décomposition le fait que le comportement d’un système complexe peutsuccessive en éléments plus simples et leur analyse dans être modélisé sans pour autant connaître localement le
le détail peine à modéliser un système complexe. L’étude système.
d’un système complexe dans sa globalité est appelée
l’analyse systémique. L’analyse systémique se base sur
la construction de modèles permettant d’appréhender
le système globalement.
en interaction.
Un système est dit complexe s’il est composé d’un
Quelques exemples de systèmes complexes
Le comportement de l’atmosphère sur le globe. La
météorologie est l’étude d’un système complexe.
La métaphore du papillon est souvent employée
pour décrire le caractère imprévisible d’un système chaotique, qui est un système complexe
Une ruche et ses habitants. Chaque individu participe d’un comportement perçu comme collectif
sans que les abeilles en soient conscientes
La bourse. Les courtiers effectuent des transactions qui
peuvent créer des phénomènes globaux
F IGURE 1.5: Platon expliquant à Aristote où il peut se
mettre "La totalité est plus que la somme
des parties"
Un système d’information est un système complexe.
Un simple incident dans le SI peut avoir des répercussions inattendues (par exemple l’incident
SMS Pôle Emploi SFR d’août 2013)
En France, l’approche cartésienne est culturellement
très enracinée. On aime classifier, décomposer, étiqueter. Une tendance que l’on retrouve dans l’urbanisation
Le cycle de développement d’un logiciel. Attardons du SI, confer la figure 1.6 page 8.
nous un peu sur cet exemple dans la paragraphe
suivant
Ce qu’il faut retenir ! Le système d’information est un système complexe. L’approche
Cas d’usage concret : La méthode des points de
systémique consiste à dégager des invariants
fonction
dans un système sans pour autant le connaître
dans le détail.
L’exemple de la méthode des points de fonctions est
particulièrement adapté pour décrire l’approche systémique. Dans cette méthode, plutôt que de se concentrer sur le comment et de quantifier le travail correspondant à ce comment, on se base sur des caractéristiques discriminantes du quoi pour chiffrer le comment.
C’est une approche systémique du développement logiciel qui se concentre sur le périmètre global et les interactions entre les sous-systèmes. Les méthodes paramétriques (Unité d’œuvre, COCOMO) sont par opposition des méthodes linéaires et elles trouvent leur limite
7
8. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
1.1.3 Pratiques de l’urbanisation du SI
L’objectif de cette section est de donner quelques exemples simples de pratiques préconisées par l’urbanisation du SI qui prennent directement leur source dans ce qui a été dit précédemment dans 1.1.2. Ils permettent de
diminuer le nombre d’interfaces entre sous-systèmes et limiter l’adhérence entre sous-système afin d’éviter les
effets de propagation.
Couplage faible - Cohérence forte
S’il n’y a qu’un principe à retenir en urbanisation du SI, c’est le principe de couplage faible / cohérence forte[6] :
– entre les applications,
– au sein d’une application : entre les différents modules,
– au sein d’un module : entre les différents composants.
Il est en effet souhaitable d’avoir une approche modulaire au niveau technique et au niveau fonctionnel pour
pouvoir faire facilement évoluer le SI. En découle un découpage fonctionnel du Système d’Information suivant
la métaphore de la ville en Zones, Quartiers, Ilots et Blocs. Afin de répondre au principe de couplage faible-
F IGURE 1.6: Exemple de découpage de SI d’agence de voyage avec plein de MS Office dedans. Beurk !
cohérence forte, chaque niveau doit idéalement communiquer avec son niveau homologue via un et un seul canal
qu’on nomme prise. Par exemple, dans la figure 1.6, page 8, le quartier Q_DemandesClient de la zone échange ne
doit pas communiquer directement avec le quartier Q_GestionClient de la zone opération et doit passer par la
prise de la zone. La zone échange est quant à elle en quelque sorte la prise du SI avec l’extérieur. Dans l’idéal, une
application ne doit appartenir qu’à un et un seul bloc fonctionnel.
Propriétaire de donnée unique, référentiels
Les données de référence 1 sont un sujet particulièrement sensible. Il est capital que le propriétaire de la donnée soit unique pour des raisons de cohérence. La propagation de ces données peut être complexe et il n’est
pas rare de voir des SI ou les interfaces se multiplient directement entre les applications sans qu’on ait plus de
maîtrise sur la pertinence, la provenance et la fraîcheur d’une donnée. On parle alors de l’effet plat de spaghetti.
Une autre référence de l’entreprise est la règle de gestion. Toujours pour des raisons de cohérence et de maintenabilité, il sera souhaitable de les règles de gestions soient implémentées en le moins d’endroits possible et
idéalement à un endroit unique. C’est pourquoi lorsque l’on parle de référentiel en urbanisation du SI, on parle
de données de références mais aussi de services de référence.
1. Les données de références sont définies par une stabilité dans le temps et une vocation à être utilisées dans plusieurs applications. Par
exemple un compte comptable, un utilisateur, un tarif.
8
9. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Achats
Gestion commerciale
Compta
RH
Logistique
Ventes
Marketing
Mamma mia !
Service Bus
Fournisseurs
Sous-traitant
Clients
Plateforme d’échange
Plateforme d’échange
Fournisseurs
Clients
Administration
Consommateur
F IGURE 1.7: L’effet spaghetti. En voulez-vous vraiment une autre assiette ?
Ce qu’il faut retenir ! Les pratiques de l’urbanisation du SI permettent de réduire la complexité du
SI par des principes inhérents à la complexité globale du système. Une solution simple peut apporter
de la complexité par sa spécificité et son manque de souplesse.
1.1.4 L’urbanisation du SI dans la vraie vie
Le logiciel intégré et l’urbanisation du SI
Il n’est pas possible de respecter systématiquement les principes de L’urbanisation du SI. En particulier compte
tenu de l’existence dans le SI de logiciels tiers. Les solutions tout-en-un sont particulièrement populaires dans les
zones types support, ressource et référentiels. On peut notamment penser aux progiciels de gestion intégrés. La
mise en place d’un PGI (ou ERP) mène typiquement à la situation décrite en figure 1.8.
Chaque bloc ne dispose pas de prise, et les données sont modifiables par le progiciel, ce qui en fait le propriétaire des dites données.
L’informatique comme vecteur de Qualité
Pour autant, cela ne signifie pas que les logiciels tiers n’ont pas leur place dans le système d’information. Développer en interne coûte cher et prend du temps. Certains quartiers fonctionnels sont quasiment identiques d’un
secteur d’activité à l’autre et l’adéquation au besoin étant bonne à très bonne, il n’y a pas d’intérêt à réinventer
quelque chose. En outre, il est plus facile de démarrer un logiciel tiers que de le développer soi-même.
Certains de ces avantages sont donc évidents :
– Le délai
– Le coût
– Le report du risque
9
10. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Zones
Référentiel
Opérations
Support
Applications
ERP en 3 lettres
Tarifs
Gestion commerciale
Comptabilité
F IGURE 1.8: Quelques blocs fonctionnels d’un ERP qui touchent à des zones différentes et seront difficilement
réutilisables dans le SI.
Ce que l’on dit moins souvent c’est qu’il offre la possibilité de la mise en place d’une organisation et de processus plus facilement que n’importe quelle autre conduite du changement. En effet, ce qu’on achète avec un
progiciel, c’est aussi une manière de travailler. Nombre d’organisations, particulièrement en France où la Qualité
n’est pas unanimement reconnue comme créatrice de productivité, ne prennent pas le risque d’une conduite du
changement directement par la discipline qualité.
En revanche, moderniser les processus par la mise en place d’un outil informatique se fait couramment, par
le biais de la formation à “l’outil”. La mise en place d’un progiciel est souvent prétexte à des changements organisationnels importants et à la mise en place d’indicateurs de manière transparente. Un exercice que pratiquent
parfaitement les éditeurs dans la vente et dans les faits.
(a) 5ème édition. Notez le titre.
(b) 6ème édition. Encore plus clair !
F IGURE 1.9: Progiciels et conduite du changement sont intimes sur les couvertures
Au début du siècle, à force de démarrage de progiciels, le sentiment que les directions des systèmes d’information prenait le pas sur les autres directions en ce qui concernait les processus était omniprésent.
10
11. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Ce qu’il faut retenir ! Le logiciel tiers fait partie de l’entreprise et lui est utile. La discipline urbanisation du SI a souvent tendance à se concentrer et s’exprimer sur les développements métier ou
spécifiques de l’entreprise. Elle doit adapter son approche et prendre soin de s’impliquer autant dans
l’intégration des logiciels tiers que dans les développements internes.
Distinguer les actifs applicatifs produits et les actifs applicatifs acquis
Il est donc important lorsque l’on parle d’architecture d’entreprise ou d’urbanisation de bien distinguer les
logiciels et solutions développées en interne et les solutions tierces. Dans le premier cas, on est plus ou moins
“maître de son destin”, dans le second, il faudra intégrer au mieux au système d’information.
Une des difficultées est que cette distinction existe de fait dans les Direction des Systèmes d’Information. En
effet, les champs disciplinaires des acteurs des projets de développement et de l’intégration de logiciels tiers sont
très différents. A titre d’exemple, aucun architecte logiciel n’interviendra lors de l’intégration d’un logiciel tiers.
Ce qu’il faut retenir ! Le fait que le sous-traitant ou fournisseur soit garant du bon fonctionnement
n’est pas toujours synonyme de pertinence pour sa solution. La sensibilisation aux principes d’architecture ou d’urbanisation dans les projets d’intégration des logiciels tiers est d’expérience toujours
beaucoup plus difficile à cause de la culture d’une part et des relations contractuelles d’autre part.
1.1.5 Pourquoi ce document traite peu d’architecture technique ?
Vous constaterez que dans ce document on parlera de métier, de stratégie, de consommation d’informatique
mais uniquement du point de vue application. Beaucoup d’architectes techniques ne se préoccupent que peu
des utilisateurs, quelquefois à tort. Mais il faut admettre que la réciproque est vraie : le comment de l’application
de manière générale n’intéresse que les geeks que nous sommes.
Les avancées technologiques actuelles permettent de faire en grande partie abstraction de l’architecture technique en ce qui concerne la flexibilité du SI et l’optimisation des coûts. L’architecture technique doit avoir sa
propre stratégie pour remplir ses objectifs. Dans ce document, on prend le parti de faire abstraction de la couche
technique pour deux raisons :
– C’est souvent faisable dans la vraie vie avec une vision orientée service de l’architecture technique.
– La communication avec le métier et la stratégie d’entreprise doit faire abstraction de la couche technique,
car comme on peut le voir dans la figure 1.10 en page 14, elles ne sont pas palpables par le métier.
Les acteurs des implémentations de la couche technique peuvent se différencier nettement en apportant les
briques techniques de l’urbanisation.
1.2 A propos de la Qualité
Dans ce document, et bien que l’on entre jamais dans le détail, il sera fait mention de Qualité au sens discipline
Qualité en distinction du mot qualité au sens commun. Quelle que soit la culture, la Qualité repose sur deux sousdisciplines complémentaires dont voici des définitions généralistes :
L’Assurance Qualité L’ensemble des actions entreprises pour garantir un niveau de qualité.
Le Contrôle Qualité L’ensemble des actes techniques permettant de déterminer la conformité au niveau de
qualité attendu.
Nous représenterons dans ce document la Qualité comme un cercle.
11
12. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Assurance
Qualité
Contrôle
Qualité
F IGURE 1.11: Complémentarité de l’Assurance Qualité et du Contrôle Qualité
Un qualiticien pourra lire ce document comme un ouvrage sur la Qualité qui ne parle pas de Qualité. Il n’aura
pas tort.
1.3 A propos de la Gestion de Projets
Si il est une référence aujourd’hui en terme de connaissance de gestion de projet, c’est bien le corpus de
connaissance du Project Management Institute[4]. L’ambition de ce document n’est pas de présenter les disciplines de la gestion de projet, qui sont généralement mieux connues ou du moins suscitent moins d’interrogation que l’urbanisation du SI. Nous nous en tiendrons simplement à quelques généralités qu’il est important de
dégager pour la suite.
1.3.1 Les différents types de projets
Il existe trois types de projets indépendamment de l’aspect métier abordé :
Les projets de développement Ils visent à développer l’activité, la mesure de leur réussite se fait sur le retour
sur investissement.
Les projets d’obsolescence ou d’amélioration Leur objectif est de remplacer des équipements ou des logiciels qui ne sont plus maintenables ou d’abandonner un langage de développement dont on a plus la maîtrise ou qui est lui même obsolète.
Les projets d’évolution réglementaire ou légale Une évolution de la réglementation ou du cadre légal implique une mise en conformité à une date donnée. Pour ces projets on n’attend pas de retour sur investissement mais la grande différence avec un projet d’obsolescence est qu’on ne peut pas le repousser au-delà
d’une date bien définie.
Notons qu’il est assez rare que les projets d’évolution réglementaire ou légale impactent significativement le
système d’information. Il s’agit le plus souvent d’une maintenance évolutive d’un logiciel ou d’une montée en
version d’un logiciel tiers. En revanche, les projets de développement et d’obsolescence constituent le coeur de la
roadmap des DSI. La particularité des métiers du SI est par ailleurs d’avoir une forte part de projet d’obsolescence
interne, c’est à dire des obsolescences qui ne sont détectées et gérées que par la DSI elle-même. Or, ce qu’on
constate couramment, c’est que les projets d’obsolescence sont souvent utilisés pour introduire des évolutions
fonctionnelles en quantité.
1.3.2 Consommer de l’informatique
On parle en gestion de projet d’analyse de décision MAKE-BUY. En fait, lorsqu’il s’agit d’informatiser des processus, il y a désormais une troisième option à prendre en considération. Il y a effectivement trois manières de
s’équiper en applications pour une entreprise :
FAIRE(MAKE) Développer en interne
ACHETER(BUY) Intégrer des logiciels tiers
LOUER(RENT) Souscrire à une offre en mode SaaS 2
2. Software as a Service
12
13. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Depuis plusieurs dizaines d’années, les entreprises se posent la question de savoir si elles outsourcent suffisamment. Traduction fais-je suffisamment la part entre ce qui constitue mon métier, ma valeur ajoutée et ce que j’ai
intérêt à sous-traiter, à acheter/louer ? Les allez-retours en la matière sont généralement nombreux. Le domaine
informatique ne fait pas exception.
N.B. Ces stratégies possèdent des variantes qui modifient légèrement leurs caractéristiques. Par exemple, lorsque
l’on fait appel à des ressources externes pour développer en interne, on achète des ressources et donc on augmente ses charges d’effectifs mais pas son effectif interne, c’est un peu différent. On est toujours dans le FAIRE,
mais avec une approche différente de l’aspect ressource qui se rapproche d’ACHETER.
1.3.3 PMI, des indicateurs adaptés
Un des éléments séduisants de la conduite de projet de PMI[4] est l’utilisation de la valeur acquise pour le suivi
d’avancement du projet.
Le principe d’utilisation de la valeur acquise est de mesurer la valeur en monnaie de ce qui a été produit à
l’instant t, puis de le ramener à ce qui avait été planifié et budgété à cet instant. Il y a plusieurs données et calculs
avec leur significations par exemple le SPI 3 et le CPI 4 .
SPI Mesure ce qui a été fait par rapport à ce qui était planifié.
CPI Mesure ce qui a été fait par rapport au budget.
Comme vous pouvez le voir sur la figure 1.12, on ramène tout à la monnaie certes, mais dans le cadre du budget
du projet. Les coûts de maintenance et d’exploitation sont absents du raisonnement, et c’est bien naturel.
Ce qu’il faut retenir ! L’objectif des disciplines de gestion de projet est de répondre au besoin et à
la demande sans la dépasser, en respectant la contrainte coût et la contrainte temps du build. Le coût
du run et donc le coût total de possession du produit ou service final est absent du raisonnement de la
gestion de projet.
1.3.4 Projets du SI et consommation d’application
La figure 1.14 en page 15 donne quelques caractéristiques des stratégies de consommation d’application.
D’autres facteurs entrent en compte lors du choix, comme la présence ou la possibilité d’acquérir la compétence
nécessaire pour le FAIRE. C’est à ce niveau qu’interviennent souvent les Entreprises de Service du Numérique 5 ,
et leur principale raison d’exister est le besoin pour l’entreprise d’innover tout en créant une structure interne la
plus petite possible.
Une autre manière de voir les choses consiste à se poser la question du run au moment de choisir sa stratégie :
FAIRE
ACHETER
LOUER
Développement
Obsolescence
Règlementaire
TABLE 1.1: Matrice d’affinité Types de projets/Stratégie
Seule la notion de run est mise en perspective ici. Il s’agit de s’inscrire dans le moyen et long terme pour évaluer la stratégie de consommation d’application vis à vis des projets qui viendront impacter le fonctionnel d’une
application ou d’un ensemble d’applications.
3. Schedule Performance Index
4. Cost Performance Index
5. ESN, on parle encore de SSII ou SS2I
13
14. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Architecture Métier
Architecture Fonctionnelle
Le métier est une partie
prenante avec une visibilité
Architecture Applicative
?!
Architecture Technique
Le métier est une partie
prenante
mais cette couche lui est
transparente
F IGURE 1.10: Les trois premières couches du modèle de Longépé sont adhérentes entre elles. La couche technique
est peu orientée par le métier et transparente pour lui.
k
Avancement
Projet λ
Aujourd’hui
Temps
Réalisé
Planifié
Avancement %
F IGURE 1.12: L’évolution de la valeur acquise dans le temps prend généralement la forme d’une sigmoïde qui est
ici la courbe de référence, le planifié. Le projet λ est en retard (avancement) mais a dépensé moins
d’argent que prévu (réalisé).
14
15. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
Périmètre
Qualité
Coût
Temps
F IGURE 1.13: Une représentation des facteurs de réussite selon PMI
Innovation / Avantage concurrentiel
Risque financier
Investissement sur les hommes
Peu de différentiation
Dépendance au fournisseur
Import de processus métiers
Caractéristique
Risque de sécurité
Innovation Adéquation
Ressources internes
FAIRE
ACHETER
LOUER
F IGURE 1.14: Caractéristiques des stratégies de consommation d’application
15
16. 1 Retour d’expérience sur les disciplines à l’origine de la démarche
La stratégie FAIRE est comme nous l’avons vu précédemment le moyen d’être le plus innovant et spécifique
dans un métier dans la vie de l’application. En contrepartie elle demandera de gérer seul les obsolescences
et les évolutions règlementaires.
La stratégie ACHETER n’offre pas l’adéquation idéale et il pourra être impossible de répondre à certains besoins ou à travers des développements spécifiques tellement lourds que cela en perd de son intérêt. L’obsolescence est gérée par l’éditeur qui peut à un moment ne plus certifier telle ou telle plateforme. En revanche, le support de l’éditeur garantit que les évolutions règlementaires seront suivies par l’application et
ramène la gestion du règlementaire à une gestion d’obsolescence. Attention toutefois à ne pas confondre
législation et pratiques de l’entreprise. Dans ce cas comme dans la stratégie LOUER, règlementaire ne
concerne ici que la législation du périmètre fonctionnel de l’application sur étagère. Si vous faites des développements spécifiques, vous devrez gérer vous-même (ou faire gérer à prix d’or).
La stratégie LOUER permettra peut d’évolutions à l’initiative du consommateur. En revanche, l’aspect hébergé affranchit assez largement de la gestion de l’obsolescence et du règlementaire.
1.4 Des objectifs contradictoires
Selon Robert L. Glass[3], la maintenance d’une application constitue environ 60 % du coût de sa vie. Dans ces
60%, 60 % concerne de la maintenance évolutive, la maintenance corrective étant aux alentours de 17 %. Le cabinet Solucom IT confirme ce chiffre de 60% dans les développements spécifiques pour une durée d’exploitation de
5 ans. Une part de maintenance évolutive (petites évolutions + nouvelles versions) entre 40 % et 75 %, et une part
de maintenance corrective à environ 15% . On peut dire que la règle des 60/60 est une bonne règle empirique.
Dans le cas de l’intégration de logiciels tiers, la part du build, notamment des phases d’étude est généralement moins élevée ainsi que la part du run. Ce bénéfice n’est toutefois pas toujours compensé par le coût des
licences. Ainsi, en considérant les licences, c’est à dire le coût d’usage de l’application, comme du run, on reste
sensiblement les mêmes tendances : Ce qui coûte cher, c’est l’usage.
Build
Coût total
de possession
∼40 %
Run
∼40 %
∼20 %
Build
Run - Evolutions
Run - Exploitation et Corrections
F IGURE 1.15: Une représentation de la règle des 60/60
Un projet réussi est donc un projet qui a satisfait les critères :
– Périmètre
– Temps
– Coût
– Qualité
Un projet réussi peut donc, par les charges qu’il impose sur le récurrent et la rigidité qu’il lui amène, diminuer
la valeur globale du SI.
Ce qu’il faut retenir ! Les coûts de maintenance d’une application représentent plus de la moitié du
coût total de possession de celle-ci. Par conséquent leur mise en place doit permettre une maintenance
la plus aisée et la moins coûteuse possible. Un projet réussi au sens métier ou au sens gestion de projet
strict ne prend pas ce fait en compte. Il faut formuler et structurer dans les objectifs du projet sa réussite
en terme d’intégration au SI.
16
17. 2 Vers la réconciliation
« Beau projet et drap neuf rétrécissent à l’usage »
Proverbe Scandinave
’objectif de ce chapitre est de mettre en évidence, par deux approches radicalement différentes, la nécessité
de la MOA du SI pour le SI. Dans la section 2.1 nous approcherons la nécessité de la MOA du SI par un objet
mathématique, alors que dans la section 2.2 nous l’approcherons par un exemple tiré de l’adaptation d’un livre
de science-fiction célèbre au cinéma.
L
2.1 Auto-similarité et dépendance
L’établissement de la feuille de route du SI est pour la Direction des systèmes d’information un exercice périodique dans lequel on sélectionne et établit la séquence des projets selon un processus itératif. Les projets auront
été au préalable pré-sélectionnés en rapport aux objectifs métiers puis chiffrés de manière macro en coût et en
temps. On retrouve ici les notions de coût, de délai et de périmètre chères à la gestion de projet. Il n’y a rien de
très choquant à voir apparaître ces notions à plusieurs niveaux de l’organisation. Par ailleurs, pour remplir ces
objectifs, assurance et contrôle seront à prévoir et on retrouve donc le motif suivant :
Dimension Objectifs
Dimension assurance et contrôle
Dimension Temps
Dimension Coût
F IGURE 2.1: Motif commun entre gouvernance et gestion de projet
Définition : Triade de la conformité aux objectifs Pour atteindre des Objectifs, il faut du Temps, de l’Argent
et s’assurer du tout par la discipline Qualité. Le tout de manière récursive.
On citera ce concept par la suite sous le nom de triade de la conformité aux objectifs ou plus simplement triade,
en référence à l’ensemble triadique 1 de Cantor, qui est le premier exemple de fractale 2 de l’histoire des mathématiques. Il est important de noter que ce motif n’est pas seulement commun au SI et la gestion de projet, mais
qu’il est beaucoup plus répandu.
Pour illustrer et étudier l’imbrication du motif de la triade l’un dans l’autre, nous utiliserons une fractale qui
s’apparente au flocon de Koch 3 . En effet, le triangle équilatéral est la première itération du flocon de Koch. Dans
le flocon de la conformité aux objectifs, la première itération est un triangle équilatéral inscrit dans un cercle
comme dans la figure 2.1. La deuxième itération, et si on replace les notions donne ceci :
1. Ayant un rapport avec une triade, par exemple pour nous les trois dimensions Objectifs, Temps et Coût
2. Le terme « fractale » est un néologisme créé par Benoît Mandelbrot en 1974 à partir de la racine latine fractus, qui signifie brisé, irrégulier.
Dans la « théorie de la rugosité » développée par Mandelbrot, une fractale désigne des objets dont la structure est invariante par changement
d’échelle.
3. http://fr.wikipedia.org/wiki/Flocon_de_Koch
17
18. 2 Vers la réconciliation
F IGURE 2.2: L’ensemble triadique de Maître Cantor ? Ah non ça c’est l’autre...
Objectifs du SI
Gouvernance Qualité du SI
Qualité
Qualité
Périmètre
Délai
Périmètre
Coût
Projet
Coût
Projet
SI
Délai
Qualité
Délai
Coût du SI
Coût
Vélocité du SI
Projet
Périmètre
F IGURE 2.3: Deuxième itération du flocon de la conformité aux objectifs
Dans cette figure 2.3, nous constatons que les variations des périmètres, des coûts et des délais pour un projet
donné impacte les autres projets ainsi que les dimensions objectifs, coût et temps du SI. Par exemple, si le coût
d’un des projet croît, tout le reste étant constant par ailleurs, le triangle n’est plus inscrit dans le cercle qualité
du projet. Mais pas seulement ! Soit le triangle du SI ne sera plus inscrit dans le cercle qualité du SI, soit des
paramètres d’autres projets vont devoir compenser.
En somme, un écart impacte la qualité des projets et/ou du SI. Cette figure rend bien compte de la complexité
du système d’information et de son existence en tant que système dynamique, il y a interaction locale qui impactent et peuvent provoquer des changements loin de ces interactions.
Intéressons nous de plus près aux interfaces entre le projet et le système d’information dans la figure 2.4 :
18
19. 2 Vers la réconciliation
Gouvernance Qualité du SI
Qualité
Périmètre
Coût
Projet
Point de contact
du projet et de
Complexité de
Délai
l’intégration à
la Qualité du SI
l’éxistant
F IGURE 2.4: Zoom sur le projet dans le SI
Sur cette courbe, il y a à la fois contact :
– entre le projet et le SI
– entre le Périmètre du projet, la Qualité du projet et la Qualité du SI
Les deux difficultés majeures de la gestion du portefeuille projet et de l’atteinte des objectifs sont donc ici bien
représentées :
– L’intégration à l’existant
– La conformité du périmètre des projets aux objectifs du SI
Remarque : En itérant encore une fois le flocon de la conformité au projet, on notera que des triades apparaissent pour le SI et dont les objectifs ne sont définis ou ne dérivent de nulle part. Des projets du SI pour le SI en
quelque sorte (en vert sur la courbe).
Objectifs du SI
Gouvernance Qualité du SI
Projet
Projet
Triades du SI
pour le SI et sans lien avec
des objectifs de haut niveau
SI
Coût du SI
Vélocité du SI
Projet
F IGURE 2.5: Troisième itération du flocon de la conformité aux objectifs.
19
20. 2 Vers la réconciliation
Dans cette itération, le projet se décompose lui aussi (en phase, en lot, ou en itération par exemple) mais cela
a été masqué pour des raisons de lisibilité.
La complexité de l’intégration fait naître des projets propres au SI et qui ne sont tangents à aucun objectif
initialement identifié. Ces projets sont des projets du SI pour le SI : La mise en place d’outils de supervision, la
mise en place d’une gestion de configuration, d’un ETL, d’un EAI, l’étude de la modélisation des objets métier
de l’entreprise ou la création d’un pack méthodologique de gestion de projet du SI n’ont pas d’objectifs métier
associé. Pour autant, ces projets demandent une véritable démarche de qualification du besoin, d’étude et de
conduite du changement au niveau de toutes les parties prenantes. Or, ce type de projet est souvent porté par une
entité organisationnelle qui ne prend en compte que ces besoins propres, et le caractère mutualisé et réutilisable
est ainsi perdu. En outre, si ses briques sont crées pour être réutilisable, leur utilisation dans les contextes des
autres projets doit être promue et décrite.
Pour finir sur l’appui sur cette construction mathématique, itérer encore aurait peu de sens :
– la courbe de Von Koch dont cette courbe est dérivée itérée ne serait-ce que 5 fois commence à poser des
problèmes d’épaisseur du trait.
– Deux itérations le plus souvent et un coup d’œil à la troisième permettent de comprendre le concept, et
comme la courbe présente des auto-similarité, mieux vaut faire son analyse descendante en plusieurs figures.
– La complexité ne se décompose plus à un moment donné dans l’organisation , par exemple quand on arrive
à une tâche bien décrite exécutable par une personne dans un temps donné.
Ce qu’il faut retenir ! Le respect de la triple contrainte pour les projets et pour le SI passe donc par
une approche qui permette à la fois de :
– Faire porter les objectifs du SI et du métier au projet.
– Faciliter l’intégration des produits et services finis du projet au SI par la mise à disposition de solutions standards ou réutilisables.
Dans la section suivante, nous allons illustrer les difficultés de la conformité aux objectifs par deux anecdotes.
La première porte sur le problème du piège du spécialiste : Comme nous l’avons dit en préambule, notre culture
et notre savoir-faire nous pousse à résoudre les problèmes d’une manière donnée sans se soucier de la complexité
de l’ensemble. La seconde porte sur la difficulté de répondre aux enjeux de haut niveau.
2.2 Illustration des difficultés de la triade
F IGURE 2.6: Chérie, je suis rentré !
Pour tourner cette scène célèbre de The Shining(1980) dans laquelle Jack Torrance (joué par Jack Nicholson),
emporté par la folie, poursuit son épouse et son fils et enfonce une porte à la hache, l’équipe a du renforcer la
porte à plusieurs reprises. Jack Nicholson ayant été pompier pendant plusieurs années, il venait trop facilement
20
21. 2 Vers la réconciliation
à bout de la porte et Stanley Kubrick n’y trouvait pas l’intensité dramatique qu’il cherchait. Kubrick a du faire renforcer la porte car Jack y mettait tant de compétence et d’entrain qu’il n’arrivait pas à filmer la scène qu’il voulait !
L’objectif n’était ni de casser une porte ni de la rendre difficile à casser, mais de communiquer à l’écran l’angoisse
des poursuivis.
Quelle que soit l’échelle, vous devrez faire des choses sans rapport direct avec les objectifs de haut niveau, et
même un excès de compétence peut être un obstacle.
Autre fait sur cette œuvre, on note de grandes différences entre le livre de Stephen King à l’origine de l’adaptation cinématographique et la vision de Stanley Kubrick. Par exemple la mort de Jack : Jack meurt de l’explosion
de la chaudière défecteuse de l’hôtel dans le livre et meurt gelé dans le film. Mais ce n’est pas pour ne pas avoir
engagé un plus gros budget pour son film (c’est quand même moins cher de filmer Nicholson dans la neige que
de faire péter un hôtel) que Stephen King dit du film qu’il était une trahison.
La plus marquante de ces différences à mon sens est l’image finale, celle dans laquelle on découvre Jack sur une
photo accrochée au mur d’une soirée ayant eu lieu en 1921, date à laquelle il ne pouvait pas être présent. C’est ce
détail qui fait du film un film de fantômes, là ou le roman de King n’en est pas un : aucune référence à un passé
commun entre une entité Jack et l’hôtel n’est faite dans le livre.
Palabre de geek ? Pas tant que ça. Le message du livre de Stephen King est qu’un bon père peut devenir un monstre
sous l’emprise de l’alcool. Le film est assez fidèle à cette représentation du père alcoolique : On peut citer les
conversations de Jack et du barman, la référence dans le film à Jack qui aurait cassé le bras de son fils Danny
par accident, le contenu du "livre" qu’écrit Jack mais surtout le traitement du personnage de Danny. On ne retiendrai que l’image de Danny sur son tricycle dans les couloirs lugubres de l’hôtel, son intuition lui faisant faire
des rencontres monstrueuses. A la fois fascinante et dérangeante, elle illustre l’innocence de Danny, le sentiment
d’isolement de celui-ci et la conscience permanente pour lui et le spectateur du mal à venir.
F IGURE 2.7: Stephen/Danny seul dans un couloir
Pour cette photo de Jack en 1921, ce plan de quelques secondes qui transforme le livre de monstre en film de
fantôme, Stephen King souhaitera ne pas apparaître au générique et dira du film qu’il trahit son livre. Il confiera
en effet des années plus tard que le livre était en partie autobiographique. La folie de Jack n’est autre que l’ivresse
de son père. L’intuition de Danny et l’incrédulité de sa mère Wendy ne sont que les projections dans un monde
fantastique de la certitude de Stephen qu’il faille partir et de son incompréhension pour sa mère indéfectible.
Il me semble naturel qu’il tenait à cœur à Stephen/Danny d’avoir une adaptation qui parle de l’homme devenu
monstre, et non un film de fantôme. Film de fantôme signifie possession, vieille histoire, déresponsabilise totalement Jack de sa métamorphose et fait perdre du sens.
Un détail peut donc faire qu’un objectif de haut niveau, une intention originale ne soient pas respectés, et d’expérience expliquer pourquoi ce détail ne respecte pas l’esprit n’est pas toujours chose aisée. Peut-être à l’époque
King n’est il pas arrivé à l’expliquer à Kubrick, ou peut-être ce dernier s’en moquait-il. Quoi qu’il en soit, il en
résulte que le chef d’œuvre par sa technique, par sa photo et ses plans, par le jeu de ses acteurs manque au final
non seulement d’ambition mais de cohérence.
21
22. 2 Vers la réconciliation
Ce n’est pas très grave pour un film, mais dans le cas du SI, vous ne voulez pas d’un chef d’œuvre technique qui
ne tienne pas compte des intentions et qui ne soit pas cohérent et facile à faire évoluer.
Ce qu’il faut retenir ! Dans toute entreprise, il est des tâches sans rapport avec les objectifs initiaux qu’il faudra engager. Par ailleurs, l’existence de contraintes et la multitude d’acteurs peuvent faire
perdre de vue les objectifs initiaux et faire perdre le sens de l’entreprise.
22
23. 3 La maîtrise d’ouvrage du SI
« Il faut faire vite ce qui ne presse pas pour pouvoir faire lentement ce qui presse »
Proverbe Chinois
D
A ns
ce chapitre, nous allons parler du « Quoi ? » de la MOA du SI. L’aspect organisationnel notamment, ne
sera pas abordé.
3.1 L’Assurance
3.1.1 Le médiateur de la techno-guerre
Gérer les modes
« De tous les monstres qui emplissent les cauchemars de notre folklore, aucun n’est plus terrifiant que le LoupGarou, car il se transforme sans crier gare du familier en horreur. Pour cette raison, on cherche la balle d’argent
capable de l’occire par magie »
Frederick P. Brooks, Jr.
Tout le monde utilise la métaphore de la Silver bullet de Brooks aujourd’hui pour rappeler qu’une solution
ou une action n’est pas magique et ne peut faire la différence à elle seule, mais peu se souviennent de l’origine
que celui-ci lui donne : la peur. Si vous vous demandez encore si la peur fait vendre, jetez un coup d’œil à vos
livres d’histoires, aux derniers sondages politiques ou tout simplement aux pratiques éditorialistes des journaux
télévisés.
La compétition, le besoin de se démarquer ou de suivre le mouvement, la nécessité d’aborder un thème nouveau
peut faire faire des choix basés sur la peur à un moment donné. Les urbanistes doivent se renseigner sur les
tendances, approches et éléments techniques en vogue selon trois axes avant de devoir fatalement argumenter
de la pertinence de telle ou telle manière de faire vue par un interlocuteur dans une revue informatique il y a
quelques mois :
– L’intention ; Pourquoi un besoin s’est-il fait sentir ou une nouvelle approche s’est vue nécessaire ?
– Le cadre d’usage ; Dans quels cas est-ce intéressant ? A quelle échelle ? Ce nouvel élément offre-t-il une opportunité ?
– La maturité ; Si c’est tout neuf, vous essuierez les plâtres.
Ça a peut-être l’air élémentaire, mais ce ne l’est pas. On continue d’entendre Faisons l’étude en mode AGILE,
sous-entendu le POC sera l’itération 0 du produit et le seul livrable de l’étude. On entend déjà grand volume de
donnée = Bigdata ou NoSQL = Plus besoin de SQL.
L’urbaniste ou l’architecte doit ici user de toute la pédagogie dans l’esprit de neutralité bienveillante qui s’impose
et il sera bien armé s’il s’est posé les trois questions précitées.
On peut d’ailleurs argumenter que dans ce domaine, les architectes et urbanistes font leurs propres erreurs et
leur propre commerce. La poussée de l’ESB comme solution miracle pour une architecture tout orientée service
a crée ses propres loups-garous !
On rencontre parfois des cas d’investissement dans une technologie ou méthodologie portée par une partie de
l’organisation fonctionnelle (dans la DSI ou hors DSI) qui est sans rapport avec les besoins du SI ou les objectifs
métiers et quelquefois même sans rapport avec les deux. L’occurrence de ce type d’événement est souvent révélatrice de dysfonctionnements et/ou d’enjeux cachés et doit alerter. A titre d’exemple, le gouffre qui se crée entre le
23
24. 3 La maîtrise d’ouvrage du SI
F IGURE 3.1: Toute mode n’est pas bonne à suivre. Vous feriez la même tête.
marketing et la DSI se creuse de plus en plus vite : souvent, à cause d’un existant lourd à gérer, les délais de livraison du SI ne sont pas compatibles avec les évolutions demandées par le marketing, qui finit par se désintéresser
de la DSI, la considérer comme un obstacle et finit par créer ses propres outils.
Le bon outil pour le job, la bonne compétence pour l’outil
Il est souvent utile de rappeler qu’il n’y a pas les bonnes technologies d’un côté et les mauvaises de l’autre.
Bien sûr, tout ceux qui ont quelque chose à vendre pourront tenter de vous en convaincre, y compris ceux qui
veulent vendre leur propre savoir-faire. Outre les porteurs de la technologie eux-mêmes, les jeunes ingénieurs
sont typiquement au front de la techno-guerre, la plupart du temps de bon ton, celui de la plaisanterie. C’est une
bonne chose, car c’est une affaire de passion : il y a peu de métiers dans lesquels on trouve autant de passionnés
de technos que dans les nôtres. Il faut dire qu’entre les différentes philosophies, filières, disciplines théoriques à
mettre en œuvre, sans compter l’aspect activité créatrice obéissant à une logique il y a de quoi s’occuper l’esprit.
On pourrait citer la guerre des OS, des outils de développements, des langages de développements, des SGBD,
des serveurs d’applications, et bien d’autres encore. La plupart du temps, toutes les pistes valent la peine d’être
citées avant d’être éliminées pour un problème nouveau.
Why do java developers wear glasses ?
Because they don’t C#
F IGURE 3.2: Prêt-à-produire de Microsoft contre ouverture de Java. On se charrie somme toute assez gentiment.
L’urbanisation doit, toujours par l’évaluation de l’intention, du cadre d’usage et de la maturité faire le lien entre
la technologie et la stratégie du SI.
Concrètement, l’existence de compétences pouvant donner lieu à une solution dans l’entreprise a souvent tendance à fortement orienter la solution. On doit certes capitaliser et faire des choses qu’on sait faire, mais on doit
aussi préparer les savoir-faire de demain. En relation avec l’architecture de solution, l’urbanisation doit détecter
24
25. 3 La maîtrise d’ouvrage du SI
les occurrences d’opportunité d’usage d’une technologie au même titre que les opportunités de décommissionement pour obsolescence et proposer les lancements d’étude adéquats de manière périodique sur tous les volets
pertinents, y compris les ressources.
Dans la vision de TOGAF, c’est le rôle de l’architecture d’entreprise de recenser les compétences et de donner les
entrées pour prévoir les plans de formations adéquats. Dans les organisations, cette tâche incombe typiquement
au département des Ressources Humaines. Une collaboration est souhaitable et doit s’établir. Concrètement on
la rencontre assez souvent.
La technologie et les méthodes adaptées au rythme du SI
Mais le bon outil pour le bon travail, ce n’est pas seulement une question de l’existence des compétences et
une utilisation pertinente dans le cadre de la résolution des problèmes du projet, c’est aussi une affaire de cohérence avec le rythme des évolutions de la zone ou du quartier dans lequel on se situe dans le SI. En effet, les outils
internes et les interfaces d’administration par exemple, sont typiquement exploités 10 ans ou plus. A contrario,
un front web devra suivre les évolutions technologiques et les demandes d’évolutions et sera l’objet de refontes
fréquentes.
Une erreur typique des DSI est par ailleurs d’utiliser des méthodes de gestion de projet, de qualification, de validation, de mise en production qui sont indépendantes de ces décalages des rythmes dans le SI.
A titre d’exemple, les pratiques agiles ont mis en évidence l’utilité de l’industrialisation des phases d’intégrations
et de tests. Mais ce n’est pas parce qu’on ne travaille pas en mode agile que cette industrialisation n’est pas utile.
Tout quartier nécessitant des évolutions fréquentes peut bénéficier de pratiques et d’outils d’intégrations industrialisés.
Par ailleurs, la vision projet n’est pas toujours pertinente. Un projet est une organisation temporaire qui doit livrer
des services ou produits. Gérer la vie d’un applicatif et ses évolutions peut être dans de nombreux cas appréhendé
comme une activité récurrente. La mise en place de processus et outils pourra souvent s’avérer plus efficace que
la gestion de projet. En outre, celle-ci sera d’autant plus efficace qu’elle a été prévue dès le projet de mise en place.
3.1.2 Le garant de la conformité aux objectifs
Comme nous l’avons vu dans le chapitre précédent, la conformité aux objectifs peut et doit prendre des chemins détournés. En effet, des projets conduits uniquement par les objectifs métier aboutiront forcément à des
produits et service dont les objectifs ne sont que de remplir des objectifs métier. Or, cela conduira invariablement à une situation dans laquelle le coût du run de ces produits et services deviendra si élevé que le système ne
pourra plus évoluer, rendant l’atteinte de nouveaux objectifs métier difficile et lente au mieux. Ce que prône ce
document, c’est que c’est le rôle de la MOA du SI de mettre à disposition des chefs de projets tous les éléments
techniques et documentaires dont ils ont besoin pour s’intégrer le plus facilement possible et au mieux au SI. En
effet, les systèmes de management qualité notamment, ont tendance à ne pas être suffisamment portés auprès
des projets. La MOA du SI doit être en contact permanent avec les directions :
Avec les métiers ou les autres directions Assister la modélisation des processus, modéliser les objets métiers
et accorder la terminologie dans l’entreprise.
Avec la stratégie d’entreprise Préparer le SI aux acquisitions, aux cessions ou aux profonds changements dans
l’activité de l’entreprise.
Avec l’encadrement de la DSI Rester au contact des équipes, prendre et traiter toutes les suggestions, expliquer, évangéliser.
3.1.3 Les exigences du SI
La formulation exacte des exigences est un exercice difficile qui dépasse le cadre de ce document. Néanmoins,
il est utile de donner quelques pistes concernant les domaines à aborder, la granularité attendue ainsi que le
périmètre dans lequel on doit formuler des exigences. En effet, les exigences du SI ne sont pas du ressort de
l’urbanisation ou de l’architecture d’entreprise uniquement. En outre, certaines exigences n’auront pas de sens
dans une stratégie de consommation d’application donnée ou dans un quartier fonctionnel donné. De toute
évidence, la plupart des exigences de la MOA du SI sont des exigences non-fonctionnelles.
25
26. 3 La maîtrise d’ouvrage du SI
Domaines d’exigences
Quelques exemples de domaines de départ sur lesquels on peut se concentrer dans un premier temps sont
cités dans le tableau 3.1, page 26. Il va de soit qu’il convient de contextualiser l’approche : d’autres domaines
d’exigences peuvent et doivent être envisagés en fonction du contexte.
Domaine d’exigence
Sécurité
Obsolescence
Échanges inter-applicatifs
Exploitabilité
Description
Ce domaine concerne tout ce qui concerne
la gestion des comptes, des authentifications,
de la gestion des droits applicatifs, des ACL
réseaux, des contraintes accès physique si
c’est pertinent, des contraintes sur les soustraitants éventuelles.
Ce domaine concerne la citation explicite des
technologies sur lesquelles ont ne souhaite
pas ou plus démarrer de projets et les obligations de décommissionnement en cas de
recouvrement fonctionnel avec un applicatif
existant
Ce domaine doit décrire quels sont les types
d’échanges autorisés et ceux explicitement
exclus (par exemple échanges par DB_LINK
interdits), pour les échanges synchrones et
asynchrones. Précise quel niveau de sécurité
est requis pour les échanges.
Ce domaine précise les exigences sur les livrables du point de vue production (ordonnanceur à utiliser, interdictions de pratiques,
etc...) mais aussi en vue des modifications à
venir.
A accompagner de...
Documents types de demande
d’ouverture de flux, politique de
sécurité générale, inventaire des
zones réseaux haut niveau pour
partager le langage
Politique générale de décommissionnement, raisons des mises
plan de gestion d’obsolescence
Politique générale concernant les
échanges, outils à disposition par
type de besoin, template de demande d’interface, batch ou certificat
Description des outils utilisés, des
pratiques attendues, template ou
du moins types de rubriques attendues dans les livrables
TABLE 3.1: Quelques domaines d’exigences génériques pour les projets du SI
Granularité des exigences
Lorsque l’on lit la section précédente, on se pose immédiatement le problème de la granularité. Vous aurez tous
rencontrés des cahiers des charges déjà trop orientés solution, et la tentation de devenir trop spécifique posera
des problèmes. On peut l’imputer à l’ampleur du SI, à ces différences trop grandes d’un pan à l’autre pour être à
la fois toujours cohérent, explicite, compréhensible et applicable.
Périmètre des exigences
Les exigences de haut niveau du SI doivent être respécifiées par Zone du SI, voire par quartier. On attendra pas
en effet la même chose des zones de support où on utilisera typiquement un ERP que des zones métiers où on développe ses propres outils. Vous l’aurez compris, en préalable à cette démarche, il faudra donc avoir cartographié
l’existant. Le niveau fonctionnel de la cartographie du SI devrait être utilisé pour venir positionner des exigences,
mais il ne faut pas s’interdire pour autant des choses très pragmatiques en rapport avec l’implémentation comme
des contraintes de zone de sécurité réseau pour une zone d’échange avec l’extérieur par exemple.
C’est même là où les choses prennent tout leur sens, dans la mesure où dans un quartier fonctionnel donné, les
exigences non fonctionnelles sont assez stables dans le temps, et on peut donc capitaliser ce travail efficacement.
26
27. 3 La maîtrise d’ouvrage du SI
Ce qu’il faut retenir ! Un travail préliminaire de cartographie est nécessaire à l’établissement d’exigences qui ont du sens et qui sont stables. Les exigences du SI doivent être positionnées au niveau
SI, zone et éventuellement quartier fonctionnel. Ces exigences resteront stables et maintenables, et
contribueront efficacement à la cohérence du SI.
3.2 Le Contrôle
Revenons sur l’un des grands attraits de PMI, la valeur acquise : La capacité de s’exprimer en monnaie. Très
culturellement Américain direz-vous ? Mais si l’on veut convaincre de l’utilité d’investir dans la MOA du SI, mesurer ses progrès et communiquer factuellement et simplement il faut utiliser des indicateurs qui peuvent être
compris universellement. En effet, plusieurs grandes organisations telles Renault ou Axa utilisent déjà des indices d’urbanisation définis par Club Urba-EA. Cela leur permet certes de mesurer leur progrès par rapport aux
exigences établies, mais pas à priori d’analyser factuellement les retours sur investissements de leur démarche. Il
y a plusieurs choses que l’on veut pouvoir mesurer :
L’écart entre les exigences du métier et le réalisé Le SI doit pouvoir servir les exigences métier, ce qui n’a
pas été livré doit être considéré comme une dette au métier.
L’écart entre les exigences du SI et l’existant Le SI doit être conforme aux exigences de la MOA du SI. Ce
qui n’est pas appliqué doit être considéré comme une dette technique.
Le rapport entre les coûts de transformation et les coûts de fonctionnement A budget pour le SI constant,
ce rapport doit être sain au risque de ne plus pouvoir transformer. Un SI sclérosé par ses coûts de fonctionnement ne peut plus évoluer.
Tout comme ce qui concerne les exigences du SI, ces indicateurs ont plus de sens localement que globalement. On
veut pouvoir identifier un quartier fonctionnel pour lequel les coûts de fonctionnement sont relativement élevés
avec une dette métier importante par exemple. Cela pourrait être révélateur d’une opportunité de transformation
à coût moins élevé qu’a priori compte, tenu des économies potentielles sur les coûts du run.
3.2.1 La dette métier
Par dette métier on entend le montant financier à engager pour se mettre en conformité avec les exigences
métier. Toute la difficulté réside dans la différence entre l’expression du besoin et ce dont on a réellement besoin.
Néanmoins, en début d’exercice, on peut se mettre d’accord sur les besoins stratégiques pour lesquels on mesurera la dette métier.
3.2.2 La dette technique
Par dette technique on entend ici le montant financier à engager pour se remettre en adéquation avec les
exigences de la MOA du SI.
C’est la somme des montants de mise en conformité relevés par la MOA du SI.
3.2.3 Dette volontaire et involontaire
Une dette peut être contractée de manière volontaire ou involontaire. En effet, dans le cas de la dette technique
par exemple, on peut choisir de ne pas suivre une recommandation ou une exigence pour gagner du temps.
Ce n’est pas un problème à partir du moment où c’est un acte conscient, un choix et qu’il est noté. On peut
choisir de régler la dette a posteriori. A contrario une dette involontaire est une dette qui n’a pas été contractée
en connaissance de cause ou qui est tout simplement ignorée et pour laquelle on n’intentera aucune action par
la suite.
27
28. 3 La maîtrise d’ouvrage du SI
3.2.4 Les coûts du run
Le montant engagé pour les projets est généralement bien connu dans le SI, même s’il peut être difficile de
l’imputer à tel ou tel quartier fonctionnel. En ce qui concerne les coûts du run, on en est généralement assez loin.
En effet même si depuis la démocratisation d’ITIL en tant que connaissance, et l’application de ses principes
dans l’entreprise on a plus d’éléments sur le "que coûte combien", il ne s’agit que d’une partie de la donne.
Regrouper les coûts de licences, la part des services mutualisés et des évolutions sur le ensembles applicatifs est
assez complexe, notamment vis-à-vis de l’usage de sous-traitance. Il y a nécessité de se mettre d’accord sur des
clés de répartition entre les zones et quartiers concernant les coûts de tous les services mutualisés.
3.3 Rôles de la MOA du SI
La MOA du SI doit a minima jouer son rôle Qualité et Alignement stratégique. Cela passe par la mise à disposition de matériaux pour la partie Assurance et par la définition d’indicateurs pour la partie Contrôle. Le périmètre
de ce document s’arrête aux pistes, et il est nécessaire de contextualiser après un diagnostic afin de définir les
indicateurs les plus pertinents dans l’organisation ainsi que les moyens de les calculer.
En résumé et pour finir :
Ce qu’il faut retenir ! La MOA du SI doit :
– Définir les cadres d’usage des technologies employées et envisagées afin de faciliter les études à venir
– Collaborer avec le métier, la MOA et/ou l’AMOA concernant les objets métier, la terminologie d’entreprise, l’utilisation et la promotion des langages de notations standards
– Analyser et porter auprès des projets la dimension SI de la stratégie d’entreprise
– Formuler des exigences de haut niveau, packagées et faciles à utiliser pour les projets et qui viendront
en entrants systématiques des projets
– Définir et faire appliquer les règles de la gestion d’obsolescence dans le SI
– Étudier, définir et promouvoir l’utilisation des briques techniques nécessaires dans le SI
– Définir et suivre les indicateurs de l’efficacité du SI
– Communiquer positivement et efficacement
28
29. A propos de l’auteur
Franck Rinaudo a a commencé sa carrière dans le monde de l’édition logicielle pour des
comptes tels que Inbev, Arcelor Mittal et Groupe Editor en occupant les fonctions de Responsable R&D et Responsable IT. Il a contribué aux standards Platon pour Orange au sein
de la cellule d’architecture base de donnée France. Il est actuellement Urbaniste, Market
leader, Architecte systèmes et middleware et Responsable d’Expertise Départemental Urbanisation et Architecture pour Atos Technology Services - Aix-en-Provence.
a. http://fr.viadeo.com/fr/profile/franck.rinaudo
Remerciements
Sincères remerciements à
– Nasreddine Bouzada, Jean-Paul Carmona, Benjamin Bonnet, pour leur précieuses relectures
– Claude Maymard, Christian Boitel, Olivier Rey, Bruno Olivieri, Jean-Pascal Cozic, Abderrafie Raïs pour nos
discussions sur ces thèmes ou des thèmes connexes
– Harmony Lemaître, Stéphanie Tielin pour m’avoir emmené sur les thèmes de l’art graphique et du cinéma
qui m’ont inspiré les représentations et illustrations de la conformité aux objectifs
J’espère que chacun a trouvé le petit caillou blanc que j’ai laissé pour elle et pour lui.
29
31. Bibliographie
[1] Pierre Bonnet, Jean-Michel Detavernier, and Dominique Vauquier. Le système d’information durable : la refonte progressive du SI avec SOA. Lavoisier, 2008.
[2] URBA-EA Club. Urbanisme des SI et gouvernance : Bonnes pratiques de l’architecture d’entreprise. Dunod,
2010.
[3] Robert L Glass. Frequently forgotten fundamental facts about software engineering.
18(3) :112–111, 2001.
Software, IEEE,
[4] Project Management Institute. A guide to the project management body of knowledge : Pmbok® guide. Project Management Institute, 2008.
[5] Andrew Josey. TOGAF Version 9 : A Pocket Guide. Van Haren Publishing, 2009.
[6] Christophe Longépé. Le projet d’urbanisation du si. Collection Informatique et Entreprise, Dunod, 2001.
[7] Jacques Sassoon. Urbanisation des systèmes d’information. 1998.
[8] John A Zachman. A framework for information systems architecture. IBM systems journal, 26(3) :276–292,
1987.
31
