Article - Augmenter la valeur du système d'information

Augmenter la valeur du SI

Diminuer le cout, ameliorer les delais, repondre aux enjeux strategiques

Franck Rinaudo

Aix-en-Provence, le 10 décembre 2013

Préambule

EN couverture de ce document, La Grande Vague de Kanagawa (1831) de Hokusai. Vous retrouverez dans cedocument une grande partie de la symbolique présente dans cette estampe.

Une estampe est créée à partir d’un dessin qui servira de patron pour la gravure dans des planches qui se-ront à leur tour utilisées par des imprimeurs. Il est à noter que le dessin original est détruit dans la phase degravure et qu’il est rarement possible d’utiliser les mêmes planches plus de 300 fois. La notion d’estampe origi-nale correspond donc à la série d’estampes du premier dessin original. Il s’agit d’un procédé en quelque sortesemi-industriel pour lequel l’auteur du dessin original suivra toutes les étapes de fabrication afin de s’assurer del’intention mais les étapes de gravure et d’imprimerie seront réalisées par des artisans spécialisés. L’auteur estdonc 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 vaguedont le motif s’apparente au triangle. En outre, vous constaterez que si vous ne considérez que le contour de lamer 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éede l’œuvre : Nous voyons la vague à la poursuite des pêcheurs alors que l’intention de Hokusai et la lecture dans lesens oriental montre des pêcheurs allant au devant de la vague. Ainsi en fonction de la culture avec laquelle vousabordez l’estampe, votre parcours visuel s’arrêtera d’abord sur la vague ou d’abord sur les pêcheurs. Ce biais vouspousse à donner encore plus d’importance à la vague en tant que sujet que ne le voulait l’auteur, plutôt qu’entant 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. Carnous ne sommes pas seulement occidentaux. Nous sommes, entre autres mais pour beaucoup, des informati-ciens.

Objectifs du document

La gestion de projet est un métier à part entière. Tout comme l’architecture et l’urbanisation. Or, si dans denombreuses cultures l’unité de transformation de l’entreprise et du système d’information est le projet, force estde constater que peu de liens concrets sont établis entre les disciplines de la gestion de projet et de l’urbanisationdu SI 2.

Pourquoi les passerelles entre les disciplines d’urbanisation du SI et de la gestion de projet n’existent pas de ma-nière pragmatique ? Selon les méthodes actuellement plébiscitées, les chefs de projets pilotent dans le périmètredé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’exploi-tation ? Du coût total de possession ? La somme des succès de ces projets informatiques est-elle la garantie dusuccès pour le système d’information ?

Tout en puisant dans la culture populaire, nous reviendrons sur les notions structurantes des disciplines d’ur-banisation et de gestion de projet dans un contexte de gouvernance du SI. Puis nous mettrons en évidence leurscontradictions, avant de trouver un motif commun. Nous conclurons par la nécessité de définir les rôles d’unemaî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 montagneson logo. Une vague qui, pour nous occidentaux, avance.

2. Système d’Information

2

Table des matières

1 Retour d’expérience sur les disciplines à l’origine de la démarche 41.1 A propos de l’urbanisation du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Origine et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.2 Fondement scientifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3 Pratiques de l’urbanisation du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.4 L’urbanisation du SI dans la vraie vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.5 Pourquoi ce document traite peu d’architecture technique ? . . . . . . . . . . . . . . . . . . . 11

1.2 A propos de la Qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 A propos de la Gestion de Projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.1 Les différents types de projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2 Consommer de l’informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 PMI, des indicateurs adaptés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4 Projets du SI et consommation d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Des objectifs contradictoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Vers la réconciliation 172.1 Auto-similarité et dépendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Illustration des difficultés de la triade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 La maîtrise d’ouvrage du SI 233.1 L’Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Le médiateur de la techno-guerre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 Le garant de la conformité aux objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3 Les exigences du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Le Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.1 La dette métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 La dette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.3 Dette volontaire et involontaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4 Les coûts du run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Rôles de la MOA du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Ce qu’il faut retenir ! Vous êtes pressés ? N’hésitez pas à vous concentrer sur les pavés Ce qu’il fautretenir !

3

1 Retour d’expérience sur les disciplines à l’origine de ladé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

L’urbanisation du SI est une discipline transverse du système d’information. Son émergence est due au constatssuivants :

– 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éra-

tions 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 atteindreles objectifs métiers.

Pour répondre à cette situation les entreprises ont développé les approches d’urbanisation du SI, ayant pourobjectifs 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.

FIGURE 1.1: L’objet de la modélisation est d’examiner l’entreprise sous différents points de vue, tout comme icion 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 Urba-EA[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 approchetop-down, en partant notamment de la stratégie de l’entreprise jusqu’à l’implémentation technique pour ré-pondre à cette stratégie.

4

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 enfonction de la situation.

Comme nous l’avons dit, l’urbanisation a pour objectif la diminution de sa complexité globale par la transfor-mation de celui-ci en un système plus facilement modifiable. L’architecture d’entreprise tend à être la projectionsous plusieurs prismes du fonctionnement d’une entreprise tenant compte de l’omniprésence du système d’in-formation. Les deux disciplines ont en commun une vision stratégique du SI, à savoir l’objectif de définition d’unecible cohérente avec la stratégie générale et d’un chemin pour y parvenir. Mais là où l’urbanisation est centrée surle SI, l’architecture d’entreprise étend son périmètre à l’entreprise, ses membres compris. Dans la suite de ce do-cument, on parlera d’urbanisation du SI, mais plusieurs préoccupations relèveront de l’architecture d’entreprisesans que la distinction soit faite.

5


FIGURE 1.2: Catalogue des représentation du framework Zachman[8], considéré comme le premier frameworkd’architecture d’entreprise

FIGURE 1.3: Cycle de développement de l’architecture TOGAF 9[5], la référence de l’architecture d’entrepriseanglo-saxonne

FIGURE 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


1.1.2 Fondement scientifiqueLes systèmes complexes

L’abord de la complexité d’un système est traité ensciences dans le champ de la théorie des systèmes com-plexes.

Un système est un ensemble cohérent de composantsen interaction.

Un système est dit complexe s’il est composé d’ungrand nombre d’entités en interactions locales etsimultanées.

La méthode cartésienne, à savoir la décompositionsuccessive en éléments plus simples et leur analyse dansle détail peine à modéliser un système complexe. L’étuded’un système complexe dans sa globalité est appeléel’analyse systémique. L’analyse systémique se base surla construction de modèles permettant d’appréhenderle système globalement.

Quelques exemples de systèmes complexes

Le comportement de l’atmosphère sur le globe. Lamétéorologie est l’étude d’un système complexe.La métaphore du papillon est souvent employéepour décrire le caractère imprévisible d’un sys-tème chaotique, qui est un système complexe

Une ruche et ses habitants. Chaque individu parti-cipe d’un comportement perçu comme collectifsans que les abeilles en soient conscientes

La bourse. Les courtiers effectuent des transactions quipeuvent créer des phénomènes globaux

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’incidentSMS Pôle Emploi SFR d’août 2013)

Le cycle de développement d’un logiciel. Attardonsnous un peu sur cet exemple dans la paragraphesuivant

Cas d’usage concret : La méthode des points defonction

L’exemple de la méthode des points de fonctions estparticulièrement adapté pour décrire l’approche systé-mique. Dans cette méthode, plutôt que de se concen-trer sur le comment et de quantifier le travail corres-pondant à ce comment, on se base sur des caractéris-tiques discriminantes du quoi pour chiffrer le comment.C’est une approche systémique du développement lo-giciel qui se concentre sur le périmètre global et les in-teractions entre les sous-systèmes. Les méthodes para-métriques (Unité d’œuvre, COCOMO) sont par opposi-tion des méthodes linéaires et elles trouvent leur limite

dans le fait qu’elles demandent une décomposition dusystème et donc une orientation solution.La méthode des points de fonctions permet de faire desestimations plus fiables que les méthodes par décom-position et chiffrage linéaire à partir du moment ou lesystème est suffisamment grand et complexe.

Un fait perturbant est que le modèle est en apparenceplus simple que le modèle cartésien : on a coutume dedire dans l’approche systémique que le tout est à la foisplus et moins que la somme des parties. La significa-tion de ce détournement des propos d’Aristote exprimele fait que le comportement d’un système complexe peut-être modélisé sans pour autant connaître localement lesystème.

FIGURE 1.5: Platon expliquant à Aristote où il peut semettre "La totalité est plus que la sommedes parties"

En France, l’approche cartésienne est culturellementtrès enracinée. On aime classifier, décomposer, étique-ter. Une tendance que l’on retrouve dans l’urbanisationdu SI, confer la figure 1.6 page 8.

Ce qu’il faut retenir ! Le système d’infor-mation est un système complexe. L’approchesystémique consiste à dégager des invariantsdans un système sans pour autant le connaîtredans le détail.

7


1.1.3 Pratiques de l’urbanisation du SIL’objectif de cette section est de donner quelques exemples simples de pratiques préconisées par l’urbanisa-

tion du SI qui prennent directement leur source dans ce qui a été dit précédemment dans 1.1.2. Ils permettent dediminuer le nombre d’interfaces entre sous-systèmes et limiter l’adhérence entre sous-système afin d’éviter leseffets 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 pourpouvoir faire facilement évoluer le SI. En découle un découpage fonctionnel du Système d’Information suivantla métaphore de la ville en Zones, Quartiers, Ilots et Blocs. Afin de répondre au principe de couplage faible-

FIGURE 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 canalqu’on nomme prise. Par exemple, dans la figure 1.6, page 8, le quartier Q_DemandesClient de la zone échange nedoit pas communiquer directement avec le quartier Q_GestionClient de la zone opération et doit passer par laprise de la zone. La zone échange est quant à elle en quelque sorte la prise du SI avec l’extérieur. Dans l’idéal, uneapplication 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 don-née soit unique pour des raisons de cohérence. La propagation de ces données peut être complexe et il n’estpas rare de voir des SI ou les interfaces se multiplient directement entre les applications sans qu’on ait plus demaî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 main-tenabilité, il sera souhaitable de les règles de gestions soient implémentées en le moins d’endroits possible etidéalement à un endroit unique. C’est pourquoi lorsque l’on parle de référentiel en urbanisation du SI, on parlede 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. Parexemple un compte comptable, un utilisateur, un tarif.

8


Gestion commerciale

RHCompta

Achats

Marketing

Sous-traitant

ConsommateurAdministration

Ventes

ClientsFournisseurs

Plateforme d’échange Plateforme d’échange

Service Bus

ClientsFournisseurs

Logistique

Mamma mia !

FIGURE 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é duSI par des principes inhérents à la complexité globale du système. Une solution simple peut apporterde la complexité par sa spécificité et son manque de souplesse.

1.1.4 L’urbanisation du SI dans la vraie vieLe 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 comptetenu de l’existence dans le SI de logiciels tiers. Les solutions tout-en-un sont particulièrement populaires dans leszones types support, ressource et référentiels. On peut notamment penser aux progiciels de gestion intégrés. Lamise 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éve-lopper en interne coûte cher et prend du temps. Certains quartiers fonctionnels sont quasiment identiques d’unsecteur 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éinventerquelque 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


Zones

Applications

ERP en 3 lettres Tarifs Gestion commerciale Comptabilité

Référentiel Opérations Support

FIGURE 1.8: Quelques blocs fonctionnels d’un ERP qui touchent à des zones différentes et seront difficilementré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 pro-cessus plus facilement que n’importe quelle autre conduite du changement. En effet, ce qu’on achète avec unprogiciel, 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 duchangement directement par la discipline qualité.

En revanche, moderniser les processus par la mise en place d’un outil informatique se fait couramment, parle biais de la formation à “l’outil”. La mise en place d’un progiciel est souvent prétexte à des changements orga-nisationnels importants et à la mise en place d’indicateurs de manière transparente. Un exercice que pratiquentparfaitement les éditeurs dans la vente et dans les faits.

(a) 5ème édition. Notez le titre. (b) 6ème édition. Encore plus clair !

FIGURE 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’informa-tion prenait le pas sur les autres directions en ce qui concernait les processus était omniprésent.

10


Ce qu’il faut retenir ! Le logiciel tiers fait partie de l’entreprise et lui est utile. La discipline ur-banisation du SI a souvent tendance à se concentrer et s’exprimer sur les développements métier ouspécifiques de l’entreprise. Elle doit adapter son approche et prendre soin de s’impliquer autant dansl’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 leslogiciels 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. Eneffet, les champs disciplinaires des acteurs des projets de développement et de l’intégration de logiciels tiers sonttrè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 fonctionnementn’est pas toujours synonyme de pertinence pour sa solution. La sensibilisation aux principes d’archi-tecture ou d’urbanisation dans les projets d’intégration des logiciels tiers est d’expérience toujoursbeaucoup 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 peudes utilisateurs, quelquefois à tort. Mais il faut admettre que la réciproque est vraie : le comment de l’applicationde 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 tech-nique en ce qui concerne la flexibilité du SI et l’optimisation des coûts. L’architecture technique doit avoir sapropre stratégie pour remplir ses objectifs. Dans ce document, on prend le parti de faire abstraction de la couchetechnique 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 lesbriques 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 disciplineQualité en distinction du mot qualité au sens commun. Quelle que soit la culture, la Qualité repose sur deux sous-disciplines 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 dequalité attendu.

Nous représenterons dans ce document la Qualité comme un cercle.

11


AssuranceQualité

ContrôleQualité

FIGURE 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’aurapas 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 deconnaissance du Project Management Institute[4]. L’ambition de ce document n’est pas de présenter les disci-plines de la gestion de projet, qui sont généralement mieux connues ou du moins suscitent moins d’interroga-tion que l’urbanisation du SI. Nous nous en tiendrons simplement à quelques généralités qu’il est important dedégager pour la suite.

1.3.1 Les différents types de projetsIl 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 retoursur investissement.

Les projets d’obsolescence ou d’amélioration Leur objectif est de remplacer des équipements ou des logi-ciels 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 im-plique une mise en conformité à une date donnée. Pour ces projets on n’attend pas de retour sur investis-sement 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 lesystème d’information. Il s’agit le plus souvent d’une maintenance évolutive d’un logiciel ou d’une montée enversion d’un logiciel tiers. En revanche, les projets de développement et d’obsolescence constituent le coeur de laroadmap des DSI. La particularité des métiers du SI est par ailleurs d’avoir une forte part de projet d’obsolescenceinterne, 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’onconstate couramment, c’est que les projets d’obsolescence sont souvent utilisés pour introduire des évolutionsfonctionnelles en quantité.

1.3.2 Consommer de l’informatiqueOn parle en gestion de projet d’analyse de décision MAKE-BUY. En fait, lorsqu’il s’agit d’informatiser des pro-

cessus, il y a désormais une troisième option à prendre en considération. Il y a effectivement trois manières des’é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


Depuis plusieurs dizaines d’années, les entreprises se posent la question de savoir si elles outsourcent suffisam-ment. Traduction fais-je suffisamment la part entre ce qui constitue mon métier, ma valeur ajoutée et ce que j’aiintérêt à sous-traiter, à acheter/louer ? Les allez-retours en la matière sont généralement nombreux. Le domaineinformatique ne fait pas exception.

N.B. Ces stratégies possèdent des variantes qui modifient légèrement leurs caractéristiques. Par exemple, lorsquel’on fait appel à des ressources externes pour développer en interne, on achète des ressources et donc on aug-mente 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ésUn 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 calculsavec 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 budgetdu 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ûtdu run et donc le coût total de possession du produit ou service final est absent du raisonnement de lagestion de projet.

1.3.4 Projets du SI et consommation d’applicationLa 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étencené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 laplus 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 LOUERDéveloppement

ObsolescenceRè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 éva-luer la stratégie de consommation d’application vis à vis des projets qui viendront impacter le fonctionnel d’uneapplication ou d’un ensemble d’applications.

3. Schedule Performance Index4. Cost Performance Index5. ESN, on parle encore de SSII ou SS2I

13


Architecture Métier

Architecture Fonctionnelle

Architecture Applicative

Architecture Technique

? !

Le métier est une partieprenante avec une visibilité

Le métier est une partieprenantemais cette couche lui esttransparente

FIGURE 1.10: Les trois premières couches du modèle de Longépé sont adhérentes entre elles. La couche techniqueest peu orientée par le métier et transparente pour lui.

k€

Temps

Ava

nce

men

t

Réalisé Avancement %Planifié

Aujourd’hui

Projet λ

FIGURE 1.12: L’évolution de la valeur acquise dans le temps prend généralement la forme d’une sigmoïde qui estici la courbe de référence, le planifié. Le projet λ est en retard (avancement) mais a dépensé moinsd’argent que prévu (réalisé).

14


Qualité

TempsCoût

Périmètre

FIGURE 1.13: Une représentation des facteurs de réussite selon PMI

FAIRE ACHETER LOUER

Caractéristique

Innovation Adéquation

Ressources internes

Innovation / Avantage concurrentielRisque financierInvestissement sur les hommes

Peu de différentiationDépendance au fournisseurImport de processus métiers

Risque de sécurité

FIGURE 1.14: Caractéristiques des stratégies de consommation d’application

15


La stratégie FAIRE est comme nous l’avons vu précédemment le moyen d’être le plus innovant et spécifiquedans un métier dans la vie de l’application. En contrepartie elle demandera de gérer seul les obsolescenceset 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 be-soins ou à travers des développements spécifiques tellement lourds que cela en perd de son intérêt. L’ob-solescence est gérée par l’éditeur qui peut à un moment ne plus certifier telle ou telle plateforme. En re-vanche, le support de l’éditeur garantit que les évolutions règlementaires seront suivies par l’application etramène la gestion du règlementaire à une gestion d’obsolescence. Attention toutefois à ne pas confondrelégislation et pratiques de l’entreprise. Dans ce cas comme dans la stratégie LOUER, règlementaire neconcerne 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 ces60%, 60 % concerne de la maintenance évolutive, la maintenance corrective étant aux alentours de 17 %. Le cabi-net Solucom IT confirme ce chiffre de 60% dans les développements spécifiques pour une durée d’exploitation de5 ans. Une part de maintenance évolutive (petites évolutions + nouvelles versions) entre 40 % et 75 %, et une partde 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érale-ment moins élevée ainsi que la part du run. Ce bénéfice n’est toutefois pas toujours compensé par le coût deslicences. Ainsi, en considérant les licences, c’est à dire le coût d’usage de l’application, comme du run, on restesensiblement les mêmes tendances : Ce qui coûte cher, c’est l’usage.

BuildRun - EvolutionsRun - Exploitation et Corrections

Coût total ∼40 %de possession

∼40 % ∼20 %

Build Run

FIGURE 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é ducoût total de possession de celle-ci. Par conséquent leur mise en place doit permettre une maintenancela plus aisée et la moins coûteuse possible. Un projet réussi au sens métier ou au sens gestion de projetstrict ne prend pas ce fait en compte. Il faut formuler et structurer dans les objectifs du projet sa réussiteen terme d’intégration au SI.

16

2 Vers la réconciliation

« Beau projet et drap neuf rétrécissent à l’usage »

Proverbe Scandinave

L’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 livrede science-fiction célèbre au cinéma.

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ério-dique 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 entemps. 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 detrès choquant à voir apparaître ces notions à plusieurs niveaux de l’organisation. Par ailleurs, pour remplir cesobjectifs, assurance et contrôle seront à prévoir et on retrouve donc le motif suivant :

Dimension assurance et contrôle

Dimension TempsDimension Coût

Dimension Objectifs

FIGURE 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’Argentet 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, maisqu’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 quis’apparente au flocon de Koch 3. En effet, le triangle équilatéral est la première itération du flocon de Koch. Dansle flocon de la conformité aux objectifs, la première itération est un triangle équilatéral inscrit dans un cerclecomme 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ût2. 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 changementd’échelle.

3. http://fr.wikipedia.org/wiki/Flocon_de_Koch

17

http://fr.wikipedia.org/wiki/Flocon_de_Koch


FIGURE 2.2: L’ensemble triadique de Maître Cantor ? Ah non ça c’est l’autre...

Objectifs du SI

Vélocité du SI

Gouvernance Qualité du SI

PérimètreCoût

DélaiSI

Projet

Qualité

Projet

Coût

Qualité

Périmètre

Projet

CoûtDélai

Périmètre

Qualité

Délai

Coût du SI

FIGURE 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 projetdonné impacte les autres projets ainsi que les dimensions objectifs, coût et temps du SI. Par exemple, si le coûtd’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 desparamè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 im-pactent 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



PérimètreCoût

Délai

Projet

Qualité

Complexité de

l’intégration à

l’éxistant

Point de contact

du projet et de

la Qualité du SI

FIGURE 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 SILes 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 appa-raissent 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 enquelque sorte (en vert sur la courbe).

Objectifs du SI

Vélocité du SI


SIProjetProjet

ProjetCoût du SI

Triades du SIpour le SI et sans lien avecdes objectifs de haut niveau

FIGURE 2.5: Troisième itération du flocon de la conformité aux objectifs.

19


Dans cette itération, le projet se décompose lui aussi (en phase, en lot, ou en itération par exemple) mais celaa é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 objectifinitialement identifié. Ces projets sont des projets du SI pour le SI : La mise en place d’outils de supervision, lamise en place d’une gestion de configuration, d’un ETL, d’un EAI, l’étude de la modélisation des objets métierde l’entreprise ou la création d’un pack méthodologique de gestion de projet du SI n’ont pas d’objectifs métierassocié. Pour autant, ces projets demandent une véritable démarche de qualification du besoin, d’étude et deconduite du changement au niveau de toutes les parties prenantes. Or, ce type de projet est souvent porté par uneentité organisationnelle qui ne prend en compte que ces besoins propres, et le caractère mutualisé et réutilisableest ainsi perdu. En outre, si ses briques sont crées pour être réutilisable, leur utilisation dans les contextes desautres 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 fi-gures.

– 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 parune 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 solu-

tions 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 cultureet 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

FIGURE 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 laporte à plusieurs reprises. Jack Nicholson ayant été pompier pendant plusieurs années, il venait trop facilement

20


à bout de la porte et Stanley Kubrick n’y trouvait pas l’intensité dramatique qu’il cherchait. Kubrick a du faire ren-forcer 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’angoissedes poursuivis.

Quelle que soit l’échelle, vous devrez faire des choses sans rapport direct avec les objectifs de haut niveau, etmê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’adapta-tion cinématographique et la vision de Stanley Kubrick. Par exemple la mort de Jack : Jack meurt de l’explosionde 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 avoirengagé un plus gros budget pour son film (c’est quand même moins cher de filmer Nicholson dans la neige quede 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 unephoto accrochée au mur d’une soirée ayant eu lieu en 1921, date à laquelle il ne pouvait pas être présent. C’est cedé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 monstresous l’emprise de l’alcool. Le film est assez fidèle à cette représentation du père alcoolique : On peut citer lesconversations de Jack et du barman, la référence dans le film à Jack qui aurait cassé le bras de son fils Dannypar accident, le contenu du "livre" qu’écrit Jack mais surtout le traitement du personnage de Danny. On ne re-tiendrai que l’image de Danny sur son tricycle dans les couloirs lugubres de l’hôtel, son intuition lui faisant fairedes rencontres monstrueuses. A la fois fascinante et dérangeante, elle illustre l’innocence de Danny, le sentimentd’isolement de celui-ci et la conscience permanente pour lui et le spectateur du mal à venir.

FIGURE 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 defantôme, Stephen King souhaitera ne pas apparaître au générique et dira du film qu’il trahit son livre. Il confieraen effet des années plus tard que le livre était en partie autobiographique. La folie de Jack n’est autre que l’ivressede son père. L’intuition de Danny et l’incrédulité de sa mère Wendy ne sont que les projections dans un mondefantastique 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 devenumonstre, et non un film de fantôme. Film de fantôme signifie possession, vieille histoire, déresponsabilise totale-ment 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’ex-périence expliquer pourquoi ce détail ne respecte pas l’esprit n’est pas toujours chose aisée. Peut-être à l’époqueKing n’est il pas arrivé à l’expliquer à Kubrick, ou peut-être ce dernier s’en moquait-il. Quoi qu’il en soit, il enrésulte que le chef d’œuvre par sa technique, par sa photo et ses plans, par le jeu de ses acteurs manque au finalnon seulement d’ambition mais de cohérence.

21


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 quine 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 ini-tiaux qu’il faudra engager. Par ailleurs, l’existence de contraintes et la multitude d’acteurs peuvent faireperdre de vue les objectifs initiaux et faire perdre le sens de l’entreprise.

22

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

DAns ce chapitre, nous allons parler du « Quoi ? » de la MOA du SI. L’aspect organisationnel notamment, nesera pas abordé.

3.1 L’Assurance

3.1.1 Le médiateur de la techno-guerreGérer les modes

« De tous les monstres qui emplissent les cauchemars de notre folklore, aucun n’est plus terrifiant que le Loup-Garou, car il se transforme sans crier gare du familier en horreur. Pour cette raison, on cherche la balle d’argentcapable 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 solutionou une action n’est pas magique et ne peut faire la différence à elle seule, mais peu se souviennent de l’origineque celui-ci lui donne : la peur. Si vous vous demandez encore si la peur fait vendre, jetez un coup d’œil à voslivres d’histoires, aux derniers sondages politiques ou tout simplement aux pratiques éditorialistes des journauxté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 nouveaupeut faire faire des choix basés sur la peur à un moment donné. Les urbanistes doivent se renseigner sur lestendances, approches et éléments techniques en vogue selon trois axes avant de devoir fatalement argumenterde la pertinence de telle ou telle manière de faire vue par un interlocuteur dans une revue informatique il y aquelques 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 op-

portunité ?– 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 dedonné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’imposeet 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 etleur propre commerce. La poussée de l’ESB comme solution miracle pour une architecture tout orientée servicea crée ses propres loups-garous !

On rencontre parfois des cas d’investissement dans une technologie ou méthodologie portée par une partie del’organisation fonctionnelle (dans la DSI ou hors DSI) qui est sans rapport avec les besoins du SI ou les objectifsmétiers et quelquefois même sans rapport avec les deux. L’occurrence de ce type d’événement est souvent révéla-trice de dysfonctionnements et/ou d’enjeux cachés et doit alerter. A titre d’exemple, le gouffre qui se crée entre le

23


FIGURE 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 livrai-son du SI ne sont pas compatibles avec les évolutions demandées par le marketing, qui finit par se désintéresserde 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 quiveulent vendre leur propre savoir-faire. Outre les porteurs de la technologie eux-mêmes, les jeunes ingénieurssont typiquement au front de la techno-guerre, la plupart du temps de bon ton, celui de la plaisanterie. C’est unebonne chose, car c’est une affaire de passion : il y a peu de métiers dans lesquels on trouve autant de passionnésde 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’êtrecitées avant d’être éliminées pour un problème nouveau.

Why do java developers wear glasses ?Because they don’t C#

FIGURE 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 entrela technologie et la stratégie du SI.Concrètement, l’existence de compétences pouvant donner lieu à une solution dans l’entreprise a souvent ten-dance à fortement orienter la solution. On doit certes capitaliser et faire des choses qu’on sait faire, mais on doitaussi préparer les savoir-faire de demain. En relation avec l’architecture de solution, l’urbanisation doit détecter

24


les occurrences d’opportunité d’usage d’une technologie au même titre que les opportunités de décommissione-ment pour obsolescence et proposer les lancements d’étude adéquats de manière périodique sur tous les voletspertinents, 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 lesentrées pour prévoir les plans de formations adéquats. Dans les organisations, cette tâche incombe typiquementau département des Ressources Humaines. Une collaboration est souhaitable et doit s’établir. Concrètement onla 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 etune 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 outilsinternes 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 refontesfréquentes.Une erreur typique des DSI est par ailleurs d’utiliser des méthodes de gestion de projet, de qualification, de vali-dation, 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égrationset 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 indus-trialisés.Par ailleurs, la vision projet n’est pas toujours pertinente. Un projet est une organisation temporaire qui doit livrerdes 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 quela 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 objectifsComme nous l’avons vu dans le chapitre précédent, la conformité aux objectifs peut et doit prendre des che-

mins détournés. En effet, des projets conduits uniquement par les objectifs métier aboutiront forcément à desproduits et service dont les objectifs ne sont que de remplir des objectifs métier. Or, cela conduira invariable-ment à une situation dans laquelle le coût du run de ces produits et services deviendra si élevé que le système nepourra plus évoluer, rendant l’atteinte de nouveaux objectifs métier difficile et lente au mieux. Ce que prône cedocument, c’est que c’est le rôle de la MOA du SI de mettre à disposition des chefs de projets tous les élémentstechniques et documentaires dont ils ont besoin pour s’intégrer le plus facilement possible et au mieux au SI. Eneffet, les systèmes de management qualité notamment, ont tendance à ne pas être suffisamment portés auprèsdes 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étierset accorder la terminologie dans l’entreprise.

Avec la stratégie d’entreprise Préparer le SI aux acquisitions, aux cessions ou aux profonds changements dansl’activité de l’entreprise.

Avec l’encadrement de la DSI Rester au contact des équipes, prendre et traiter toutes les suggestions, expli-quer, évangéliser.

3.1.3 Les exigences du SILa 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 lepérimètre dans lequel on doit formuler des exigences. En effet, les exigences du SI ne sont pas du ressort del’urbanisation ou de l’architecture d’entreprise uniquement. En outre, certaines exigences n’auront pas de sensdans 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


Domaines d’exigences

Quelques exemples de domaines de départ sur lesquels on peut se concentrer dans un premier temps sontcités dans le tableau 3.1, page 26. Il va de soit qu’il convient de contextualiser l’approche : d’autres domainesd’exigences peuvent et doivent être envisagés en fonction du contexte.

Domaine d’exigence Description A accompagner de...Sécurité Ce domaine concerne tout ce qui concerne

la gestion des comptes, des authentifications,de la gestion des droits applicatifs, des ACLréseaux, des contraintes accès physique sic’est pertinent, des contraintes sur les sous-traitants éventuelles.

Documents types de demanded’ouverture de flux, politique desécurité générale, inventaire deszones réseaux haut niveau pourpartager le langage

Obsolescence Ce domaine concerne la citation explicite destechnologies sur lesquelles ont ne souhaitepas ou plus démarrer de projets et les obli-gations de décommissionnement en cas derecouvrement fonctionnel avec un applicatifexistant

Politique générale de décommis-sionnement, raisons des misesplan de gestion d’obsolescence

Échanges inter-applicatifs Ce domaine doit décrire quels sont les typesd’échanges autorisés et ceux explicitementexclus (par exemple échanges par DB_LINKinterdits), pour les échanges synchrones etasynchrones. Précise quel niveau de sécuritéest requis pour les échanges.

Politique générale concernant leséchanges, outils à disposition partype de besoin, template de de-mande d’interface, batch ou cer-tificat

Exploitabilité Ce domaine précise les exigences sur les li-vrables du point de vue production (ordon-nanceur à utiliser, interdictions de pratiques,etc...) mais aussi en vue des modifications àvenir.

Description des outils utilisés, despratiques attendues, template oudu moins types de rubriques at-tendues 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 tousrencontrés des cahiers des charges déjà trop orientés solution, et la tentation de devenir trop spécifique poserades 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 pasen 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 commedes 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é, lesexigences non fonctionnelles sont assez stables dans le temps, et on peut donc capitaliser ce travail efficacement.

26


Ce qu’il faut retenir ! Un travail préliminaire de cartographie est nécessaire à l’établissement d’exi-gences qui ont du sens et qui sont stables. Les exigences du SI doivent être positionnées au niveauSI, zone et éventuellement quartier fonctionnel. Ces exigences resteront stables et maintenables, etcontribueront 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èsculturellement Américain direz-vous ? Mais si l’on veut convaincre de l’utilité d’investir dans la MOA du SI, me-surer ses progrès et communiquer factuellement et simplement il faut utiliser des indicateurs qui peuvent êtrecompris universellement. En effet, plusieurs grandes organisations telles Renault ou Axa utilisent déjà des in-dices d’urbanisation définis par Club Urba-EA. Cela leur permet certes de mesurer leur progrès par rapport auxexigences établies, mais pas à priori d’analyser factuellement les retours sur investissements de leur démarche. Ily 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’apas é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. Cequi 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 fonction-nement ne peut plus évoluer.

Tout comme ce qui concerne les exigences du SI, ces indicateurs ont plus de sens localement que globalement. Onveut pouvoir identifier un quartier fonctionnel pour lequel les coûts de fonctionnement sont relativement élevésavec 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étierPar 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 mesu-rera la dette métier.

3.2.2 La dette techniquePar 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 involontaireUne 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 peutchoisir de régler la dette a posteriori. A contrario une dette involontaire est une dette qui n’a pas été contractéeen connaissance de cause ou qui est tout simplement ignorée et pour laquelle on n’intentera aucune action parla suite.

27


3.2.4 Les coûts du runLe 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 principesdans 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 estassez complexe, notamment vis-à-vis de l’usage de sous-traitance. Il y a nécessité de se mettre d’accord sur desclé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 à disposi-tion de matériaux pour la partie Assurance et par la définition d’indicateurs pour la partie Contrôle. Le périmètrede ce document s’arrête aux pistes, et il est nécessaire de contextualiser après un diagnostic afin de définir lesindicateurs 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’en-

treprise, 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

A propos de l’auteur

Franck Rinaudo a a commencé sa carrière dans le monde de l’édition logicielle pour descomptes tels que Inbev, Arcelor Mittal et Groupe Editor en occupant les fonctions de Res-ponsable R&D et Responsable IT. Il a contribué aux standards Platon pour Orange au seinde la cellule d’architecture base de donnée France. Il est actuellement Urbaniste, Marketleader, Architecte systèmes et middleware et Responsable d’Expertise Départemental Ur-banisation 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

http://fr.viadeo.com/fr/profile/franck.rinaudo

Table des figures

1.1 Différents points de vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Framework Zachman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Cycle de développement TOGAF 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Modèle en couches de Longépé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Platon embête Aristote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Exemple de découpage en Zones, quartiers, blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7 L’effet spaghetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.8 Exemple de couverture de plusieurs zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.9 Progiciels et conduite du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.11 Complémentarité de l’Assurance Qualité et du Contrôle Qualité . . . . . . . . . . . . . . . . . . . . . 121.10 Particularité de la couche technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.12 Suivi de valeur acquise dans PMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.13 Une représentation des facteurs de réussite selon PMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.14 Caractéristiques des stratégies de consommation d’application . . . . . . . . . . . . . . . . . . . . . 151.15 Une représentation de la règle des 60/60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Motif commun entre gouvernance et gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Archive de publicité pour Maître Kanter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Deuxième itération du flocon de la conformité aux objectifs . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Zoom sur le projet dans le SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Troisième itération du flocon de la conformité aux objectifs . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Chérie, je suis rentré ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7 Stephen/Danny seul dans un couloir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 La mode pique les yeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Blague dans le mauvais langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

30

Bibliographie

[1] Pierre Bonnet, Jean-Michel Detavernier, and Dominique Vauquier. Le système d’information durable : la re-fonte 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. Software, IEEE,18(3) :112–111, 2001.

[4] Project Management Institute. A guide to the project management body of knowledge : Pmbok® guide. Pro-ject 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

Article - Augmenter la valeur du système d'information

Technology

Transcript of Article - Augmenter la valeur du système d'information