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

  • 546 views
Uploaded on

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.

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
546
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
31
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 3. Table des matières 1 Retour d’expérience sur les disciplines à l’origine de la démarche 4 1.1 A propos de l’urbanisation du SI . . . . . . . . . . . . . . . . . . . . . 1.1.1 Origine et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Fondement scientifique . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Pratiques de l’urbanisation du SI . . . . . . . . . . . . . . . . . 1.1.4 L’urbanisation du SI dans la vraie vie . . . . . . . . . . . . . . 1.1.5 Pourquoi ce document traite peu d’architecture technique ? 1.2 A propos de la Qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 A propos de la Gestion de Projets . . . . . . . . . . . . . . . . . . . . . 1.3.1 Les différents types de projets . . . . . . . . . . . . . . . . . . 1.3.2 Consommer de l’informatique . . . . . . . . . . . . . . . . . . 1.3.3 PMI, des indicateurs adaptés . . . . . . . . . . . . . . . . . . . 1.3.4 Projets du SI et consommation d’application . . . . . . . . . 1.4 Des objectifs contradictoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Vers la réconciliation 4 4 7 8 9 11 11 12 12 12 13 13 16 17 2.1 Auto-similarité et dépendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Illustration des difficultés de la triade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 La maîtrise d’ouvrage du SI 17 20 23 3.1 L’Assurance . . . . . . . . . . . . . . . . . . . . . 3.1.1 Le médiateur de la techno-guerre . . . . 3.1.2 Le garant de la conformité aux objectifs . 3.1.3 Les exigences du SI . . . . . . . . . . . . . 3.2 Le Contrôle . . . . . . . . . . . . . . . . . . . . . . 3.2.1 La dette métier . . . . . . . . . . . . . . . 3.2.2 La dette technique . . . . . . . . . . . . . 3.2.3 Dette volontaire et involontaire . . . . . . 3.2.4 Les coûts du run . . . . . . . . . . . . . . 3.3 Rôles de la MOA du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 25 25 27 27 27 27 28 28 Ce qu’il faut retenir ! Vous êtes pressés ? N’hésitez pas à vous concentrer sur les pavés Ce qu’il faut retenir ! 3
  • 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
  • 30. Table des figures 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.11 1.10 1.12 1.13 1.14 1.15 Différents points de vue . . . . . . . . . . . . . . . . . . . . . . . . Framework Zachman . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle de développement TOGAF 9 . . . . . . . . . . . . . . . . . . Modèle en couches de Longépé . . . . . . . . . . . . . . . . . . . . Platon embête Aristote . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de découpage en Zones, quartiers, blocs . . . . . . . . . L’effet spaghetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de couverture de plusieurs zones . . . . . . . . . . . . . Progiciels et conduite du changement . . . . . . . . . . . . . . . . Complémentarité de l’Assurance Qualité et du Contrôle Qualité Particularité de la couche technique . . . . . . . . . . . . . . . . . Suivi de valeur acquise dans PMI . . . . . . . . . . . . . . . . . . . Une représentation des facteurs de réussite selon PMI . . . . . . Caractéristiques des stratégies de consommation d’application Une représentation de la règle des 60/60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6 6 6 7 8 9 10 10 12 14 14 15 15 16 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Motif commun entre gouvernance et gestion de projet . . . . Archive de publicité pour Maître Kanter. . . . . . . . . . . . . Deuxième itération du flocon de la conformité aux objectifs . Zoom sur le projet dans le SI . . . . . . . . . . . . . . . . . . . Troisième itération du flocon de la conformité aux objectifs . Chérie, je suis rentré ! . . . . . . . . . . . . . . . . . . . . . . . . Stephen/Danny seul dans un couloir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18 18 19 19 20 21 3.1 La mode pique les yeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Blague dans le mauvais langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24 30 . . . . . . . . . . . . . .
  • 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