3.1 Les progiciels de gestion intégrés

3.1.1 Positionnement des PGI (Progiciel de Gestion Intégré)

3.1.1.1 Caractéristiques d’un PGI

Caractéristiques essentielles	Commentaire
Solution globale.	Couvrant la plupart des processus de gestion de l’organisation.
Non-redondance des données.	Une information n’est stockée qu’une fois.
Référentiel unique des données.	L’unicité de l’information évite les problèmes de correspondance entre des représentations différentes de la même information.
Solution de type progiciel.	Utilisation par de nombreuses organisations, garantie de pérennité et de stabilité du fonctionnement du produit.

La vision systémique des organisations fait référence à un ensemble de processus métiers en interaction. Il doit avoir une évolution « homothétique », cela signifie qu’un format qui est proportionnel dans ses dimensions à un autre. Appliqué au système d’information cela signifie donc qu’il doit évoluer en cohérence dans ses dimensions avec l’évolution de l’organisation.

Un PGI utilise une base de données unique, cela évite les redondances d’information. C’est un progiciel, car il représente un caractère d’efficacité et d’économie, contrairement aux solutions de développement spécifique.

Les ERP

Les ERP (Enterprise Resource Planning) leaders du marché possèdent des caractéristiques communes. Ils appartiennent à la catégorie des PGI, mais ils n’en constituent qu’une famille aux caractéristiques spécifiques. Ce sont des produits dont l’élaboration conceptuelle remonte le plus souvent à la fin des années 70. Puis suite aux révolutions techniques, ils ont été uniquement « relookés » sur le plan technologique. Ils sont passés d’une interface homme-machine en mode texte, au mode fenêtre, puis au mode web. Ils ont suivi l’évolution des bases de données relationnelles et ont intégré la révolution des outils d’accès aux données, qu’a constitué l’émergence des outils de l’informatique décisionnelle.

Par exemple, on l’oublie souvent, mais l’acronyme qui les caractérise a son origine dans la méthode de gestion MRP (Motion Resource Planning). Malgré ses versions successives, la méthode MRP est fondée sur une vision de la circulation des flux au sein de l’organisation qui va de l’amont vers l’aval. Cette méthode est donc en opposition sur le plan conceptuel avec la méthode des flux tirés et tendus ou d’une manière plus générale avec les méthodes dites « à la japonaise ».

La vision structurelle des organisations qui est cohérente avec cette génération de progiciels s’appuie :

· sur l’approche fonctionnelle, qui s’oppose à la vision par processus en interaction s’imposant aujourd’hui ;

· sur une structure hiérarchique et centralisée, alors que l’on constate actuellement le développement de la méthode projets en tant que mode de mise en œuvre de la stratégie de développement de l’organisation, méthode projet qui s’appuie sur la mise en place d’une structure matricielle, qui implique une révolution du système de pilotage et, notamment, la possibilité d’un mode de gestion par affaires se superposant à un mode de gestion par produits ou services ;

· sur une vision comptable des données à traiter, alors que la vision actuelle des données est orientée sur les flux d’activités opérationnels. Cette nouvelle vision, conforme à l’ISO 9000, permet l’acquisition des données à la source et sous leur forme native ;

· sur une approche de la comptabilité analytique et du contrôle de gestion, de type coût complet classique utilisant les sections homogènes et les analyses partant de la traduction comptable des informations. Cette approche ne correspond pas à la maîtrise des flux d’activités, qui ne sont pas toujours traduits en comptabilité car ils ne sont pas tous exprimés de manière monétaire. Ainsi, la gestion de la flexibilité dans l’industrie, repose sur la gestion des cadences et des événements de non-qualité, dont les mesures ne sont pas monétaires, tout au moins à leur origine. On les gérera sur un plan extra-comptable, afin de corriger les anomalies au plus tôt, leur éventuelle traduction monétaire et comptable intervenant beaucoup plus tard.

Le succès actuellement de cette gamme de progiciels, et notamment du plus connu d’entre eux, SAP, s’explique essentiellement par le marketing de ces produits et par la relation entre les directions générales des organisations et leurs directions informatiques.

La structure des ERP :

Elle est comme celle des PGI, avec une base de données unique pour l’ensemble de données, de type base de données relationnelle et des modules applicatifs par fonction : finance-comptabilité, gestion des stocks…

Par contre, elle ne s’applique pas à la vision systémique de l’organisation, reprise par l’ISO 9000 version 2000. Or, sur cette optique repose la possibilité de mettre en place une politique de la qualité totale. Celle-ci est tout à fait nécessaire dans l’économie mondialisée actuelle. L’organisation y est vue comme un tout mettant en interaction des processus. Cela implique l’adoption d’un développement par la méthode projet, qui s’appuie sur une structure matricielle. Le contrôle de gestion doit y être structuré par rapport aux flux des activités opérationnelles.

Il ne faut donc pas aborder les problèmes dans le système d’information par le biais des fonctions ou des services, mais par le biais des processus.

Pourquoi les concepts des ERP sont obsolètes ?

D’un point de vue technologique de bases de données, bien qu’utilisant des moteurs de bases de données relationnelles, leur modélisation est de type bases de données hiérarchiques, intégrant une énorme quantité de redondance, qui doit être propagée par des traitements par lots se déroulant la nuit.

D’un point de vue conceptuel :

· les modules applicatifs ne sont pas modélisés de manière à respecter la notion de processus. Ils correspondent beaucoup plus à une vision fonctionnelle que processielle de l’organisation ;

· la vision MRP qui sous-tend les outils de gestion et l’orientation des flux est diamétralement opposée à la pratique des flux tirés et tendus que l’on trouve dans les progiciels de type CIM (Computer Integrated Manufacturing) ;

· des entrées de menu proposent d’utiliser la gestion de projets, la gestion de la qualité ou l’Activity Based Costing en tant que méthode de calcul de coûts complets, mais :

o la prééminence de la vision pièce comptable de l’information,

o l’orientation des flux de l’amont vers l’aval,

o le traitement des notions de système d’information, de gestion des projets ou de gestion de la qualité comme des pans d’applications en elles-mêmes,

démontrent que ces concepts ne sont pas intégrés correctement dans les ERP.

Le système d’information ne peut-être un choix de menu puisque c’est le Tout.

La méthode projets et la structure matricielle, qui lui est associée, sont des méthodes de mise en œuvre stratégique qui doivent structurer l’information dans une logique de type de gestion par affaires.

Exemple :

La plupart des logiciels proposent une application de gestion des stocks. Sur le plan conceptuel, on se trompe alors d’objectif. La gestion des stocks est certes nécessaire mais elle ne constitue en aucun cas un processus de gestion. Il faut gérer les flux entrants et sortants, ainsi on aura la connaissance du stock. La perception de la notion de stock dans les organisations a deux acceptions, et il ne faut pas en privilégier une au détriment de l’autre. Du point de vue opérationnel, le stock n’a pas d’état stable et correspond à une gestion non interrompue des flux entrants et des flux sortants. Du point de vue comptable, il faut pouvoir arrêter les stocks et leur évaluation à une certaine date, avec une coupure nette des périodes, pour donner une photographie instantanée d’une valeur bilancielle de l’entreprise. Ces deux points de vue doivent être gérés et être rendus compatibles dans la vision proposée par le logiciel. Pour ce faire, il faut que les concepts précédents soient pris en compte ce qui n’était quasiment jamais le cas dans les applications modélisées avant les années 90. Le plus souvent elles visaient à satisfaire essentiellement le point de vue comptable et intégraient des méthodes de gestion de stocks assez simples, comme le modèle de Wilson, qui n’est plus adapté, dans la plupart des cas, à l’économie actuelle.

Les PGI (Progiciels de Gestion Intégrée)

Les avantages
Cohérence des données	Grâce au recours à une base de données unique.
Ergonomie unique	Facilité d’apprentissage et d’obtention d’une courbe d’expérience pour les utilisateurs.
Interopérabilité des modules	Permet des échanges naturels entre les différents processus.
Application paramétrable	Adaptabilité et évolutivité liées aux possibilités de contextualiser l’utilisation à un site particulier par des données modulables.
Réduction de la durée de mise en œuvre	Bien que long à mettre en place, à cause de sa globalité, ce type de solution est plus rapide à mettre en œuvre.
Maîtrise des coûts	Bien que très coûteuse, ces solutions le sont moins que les développements spécifiques (coûts mieux connus dès le départ).
Fiabilité des résultats	Plus élevé que dans le cadre d’application spécifique
Indépendance des dirigeants	Les dirigeants sont indépendants de la direction informatique.
Existence de choix	Le recours a des produits du marché offre un plus grand choix.
Solutions orientées métiers	On peut trouver dans son secteur une application spécifique à l’organisation.
Consolidation comptable	Surtout pour les groupes.

Les inconvénients
Obligation de réorganiser l’entreprise conformément aux nécessités du logiciel.	L’organisation doit revoir sa manière de gérer ses processus métiers afin de s’adapter aux facteurs de rigidités du progiciel.
Remise en cause simultanée de l’ensemble du système d’information de l’organisation	La plupart des mises en place de PGI se font en « big bang ». Cela signifie un changement généralisé de l’ensemble des processus de gestion, ce qui est très risqué.
Coût direct très élevé, mais également coût induit très important et sous-estimé.	Il y a de nombreux coûts induits, en termes de temps de travail des personnels et en termes de baisse d’efficacité des services, de manière relativement durable. Risque de dégradation sociale.
Perte de savoir-faire et d’avantage compétitif liés aux applications informatiques.	La maîtrise de l’information peut-être un avantage compétitif dans le métier de l’organisation. Recourir à un PGI élimine cet avantage, alors que le développement d’une application spécifique permet d’y intégrer un savoir-faire unique.
Limitation liés aux produits impactant la gestion.	Les choix de méthodes de gestion offerts à la direction sont limités aux capacités du progiciel.
Dépendance par rapport aux intégrateurs et aux consultants.	La mise en place d’un PGI passe par l’intervention obligatoire d’intégrateurs et de consultants, fréquemment mal perçus par les salariés de l’organisation et qui recherchent rarement à transférer les compétences vers les salariés de l’entreprise, afin de garder un potentiel de facturation de prestations à moyen et long terme.

Le système d’information urbanisé

Caractéristiques
Utilisation d’un EAI (Entreprise Application Intégration)	Structure d’échange entre applications hétérogènes par un mécanisme de connecteurs.
Structure de données spécifique :Objets métiers spéc.	Structure de données communes pour les objets pivots du système, servant de base à l’échange entre applications.
Utilisation d’un service de transport de données.	Il a pour objectif l’acheminement des données entre les différentes applications.
Avantages
Evite les interfaces multiples et spécifiques.	En l’absence de cette solution, chaque application doit développer des interfaces avec toutes les autres.
Mise à jour permanente des données.	Il n’est pas nécessaire de déclencher un traitement de mise à jour des données. Le connecteur scrute les modifications effectuées en 1 point et propage les modifications (par MAJ objets métiers).
Extensibilité et réutilisabilité du système.	L’intégration d’une nouvelle application se fait facilement.
Inconvénients
Faible performance.	En cas de gros volumes d’informations à traiter à un moment donné, ce mécanisme sera peu performant. Il sera préférable de faire un traitement de mise à jour par lots.
Investissement initial important.	Afin de mettre en place un tel système le coût initial est élevé. De plus, de nombreuses applications actuelles en place dans les organisations, ne savent pas gérer ce type de processus d’échanges. Cela implique leur remplacement.

3.1.2 La conduite d’un projet PGI

3.1.2.1 Comment réussir l’implantation d’un PGI

Il faut tout d’abord être en mesure de le choisir de manière rationnelle et efficace. Pour cela, il faut d’abord bien connaître les besoins de son organisation. On parle de BPR (Business Process Reengineering) : Approche visant à repenser totalement les processus d’une organisation pour en améliorer la gestion. Cette approche est utilisée fréquemment à l’occasion de l’évolution du système d’information.

Cela implique :

· de mener une analyse préalable approfondie des processus de l’entreprise ;

· de définir précisément les règles de gestion que l’on souhaite mettre en place ;

· de définir avec précision les changements organisationnels souhaitables et les modes d’organisation préjudiciables ;

· définir un paramétrage qui lui conviendra et qu’il faudra mettre en place, avec l’assistance de l’intégrateur. Cela permettra de garder la maîtrise lors de la mise en place. En effet, dans de nombreux cas le client est à la merci de l’intégrateur. Les choix qu’il lui propose se transforment en choix imposés par l’intégrateur, dans la mesure où le client n’a pas suffisamment réfléchi à ses propres besoins.

3.1.2.2 Méthode de déploiement

Caractéristiques
Architecture client-serveur ou n-tiers.	La base de données est stockée sur un serveur, accessible par les postes clients soit en mode client de gestion (par exemple, Windows), soit en mode navigateur. Le site de déploiement se trouvera alors le plus fréquemment sur un serveur spécifique, indépendant du serveur de base de données.
Utilisation des bases de données relationnelles.	Le mode d’organisation des données privilégié par les PGI est la base de données relationnelle, notamment ORACLE ou SQL SERVER.
Modules applicatifs orientés gestion des processus opérationnelles et outils d’aide à la décision.	Les fonctionnalités sont réparties, soit d’une manière fonctionnelle (par service) pour les plus anciens logiciels, soit d’une manière opérationnelle, par processus, pour les plus récents. Les produits leaders possèdent des fonctionnalités d’aide à la décision (Business Intelligence), appliquant le modèle OLAP.
Client de gestion et client léger	Les postes des utilisateurs accèdent aux modules du PGI, soit par une interface graphique utilisateur de type Windows, soit par un navigateur Web, dans le cadre d’un espace numérique de travail qui permet avec une seule connexion, protégée par authentification, d’accéder à l’ensemble des outils mis à la disposition de l’utilisateur.

3.1.2.3 Analyse du risque

Rappelons quelques critères de mesure du risque d’implantation d’un logiciel, en les appliquant au cas d’un PGI :

· la taille ;

· la maîtrise des techniques ;

· le degré d’intégration, tous les processus ;

· la durée, en générale très longue ;

· la stabilité de l’équipe de projet.

3.2 La gestion de la performance informatique

 

3.2.1 Mesurer la performance informatique

 

Il s’agit de fixer des objectifs qualités au service informatique et de se doter d’indicateurs de mesure de leur atteinte. Mais il s’agit également comme dans toute démarche qualité d’assurer un niveau de qualité des prestations régulier à l’ensemble de l’organisation.

Par exemple, concernant les indicateurs d’alertes liés à l’apparition d’événements de non-qualité, on peut se baser sur :

· le nombre d’interruption du réseau ;

· la durée des interruptions du service ;

· le nombre d’arrêt des serveurs ;

· le nombre d’interventions auprès des utilisateurs liées à des anomalies de fonctionnement.

3.2.2 Le contrat de service

3.2.2.1 Les différents contextes internes ou externes

L’externalisation

Les services informatiques constituent un domaine de développement important de « l’outsourcing », qui permet d’externaliser des prestations faiblement liées au métier de l’organisation.

On peut externaliser de nombreux services :

· la sauvegarde des données ;

· l’hébergement d’un site internet ;

· la gestion du réseau et des serveurs ;

· le développement de logiciels ;

· la maintenance et l’assistance aux utilisateurs…

Il faut néanmoins se méfier de ne pas perdre la maîtrise de l’information.

Pour la contractualisation de l’externalisation, il faudra faire attention à définir précisément :

· les services attendus et leur niveau requis ;

· les seuils d’écarts par rapport aux services attendus, qui déclencheront des pénalités pour le prestataire ;

· les responsabilités des contractants face aux risques encourus ;

· les modalités de contrôle et les indicateurs de mesure des performances qui seront retenus pour juger de l’exécution conforme des obligations contractuelles ;

· les moyens d’assurer la poursuite du service au niveau du client en cas de défaillance du fournisseur, pour quelque cause que ce soit ;

· les modalités de reprise de l’exploitation du service en interne, si le client le désire.

L’utilisation de services internes :

Equipes principales	Sous-équipes	Rôles
Equipe de développement	Equipe méthode	Chargée de développer les outils standards et les normes en matière d’interface homme/machine (IHM).
	Equipe développement d’applications	Développement d’applications orientées vers les utilisateurs.
	Equipe recettes et déploiement	Assure la mise en œuvre des versions successives des logiciels.
Equipe système	OS (système d’exploitation)	Installe les serveurs avec les versions du système d’exploitation.
	DBA (Administration Base de données)	Gère les bases de données, les droits d’accès aux données, les sauvegardes.
Equipe réseaux et sécurité	Réseau	Gère les protocoles de communication, les câblages, les appareils actifs.
	Sécurité	Gère la sécurité d’accès aux informations, l’authentification, la prévention des intrusions.
Equipe micro-informatique	Configuration postes clients	Installe et dépanne les postes clients et les éléments périphériques ;
	Assistance	Répond aux questions fonctionnelles des logiciels.

3.2.2.2 La mise en place d’un centre de services et la certification ITIL

ITIL (Information Technology Infrastructure Library) vise à instaurer des bonnes pratiques dans la gestion des services aux utilisateurs. Elle repose sur la notion de centre de services, qui vise à s’assurer que l’utilisateur a accès aux services dont il a besoin et pour lesquels il est référencé en tant qu’utilisateur agréé.

Fonctions	Rôles
Service Desk : centre de services	Point unique de réponses aux demandes des utilisateurs, orientés dans une optique de satisfaction client dans tous les domaines des demandes qui sont formulées. Interface avec tous les autres services de l’ITIL. L’idée est d’offrir un guichet unique qui ne soit pas un simple centre d’appels qui enregistre les demandes, mais un interlocuteur capable d’offrir une réponse circonstanciée.
Incident Management : gestion des incidents	Un incident est un événement qui entraîne l’interruption ou la dégradation du service. Gérer les incidents consiste à rétablir le fonctionnement correct du service pour l’utilisateur dans les meilleurs délais, en fonction de niveau de priorité et en organisant la traçabilité des incidents. Il s’agit de mesures correctives.
Problem Management : gestion des problèmes	La gestion des problèmes consiste à rechercher les causes des incidents de manière à détecter l’enchaînement de causes à effets et à mettre en place des mesures préventives. On utilisera des méthodes dérivés des 5M (types de causes des incidents : matière, main-d’œuvre, milieu, méthode, machine) et des 5P (en cinq pourquoi successifs, on peut remonter une chaîne causale, ayant entraîné un événement de non-qualité), ainsi que le diagramme ISHIKAWA, outils utilisés dans la gestion de la qualité en ISO 9000 et adaptés au contexte ITIL
Change Management : gestion du changement	L’évolution est inscrite en permanence dans la vie du système. Gérer le changement consiste à maîtriser cette évolution pour minimiser les risques, qui lui sont inhérents et qui entraîneraient une dégradation ou une interruption du service.
Release Management : Gestion des versions	Le système évolue par la mise en production de versions successives des logiciels et des configurations. Ce processus de mise en production doit être sécurisé pour éviter les interruptions du service.
Configuration Management : Gestion de la configuration	La mise en œuvre des services passe par une infrastructure composée de plusieurs éléments, qui doivent être en état de fonctionnement simultané et que l’on doit maintenir en cohérence alors qu’ils évoluent chacun suivant une logique et un rythme qui leur est propre.

3.2.3 La connaissance des coûts

Les budgets informatiques sont de plus en plus élevés. Dans les grandes organisations, le renouvellement des matériels et des logiciels pose un problème de fond. La connaissance et la maîtrise des coûts constituent donc une priorité pour les directions générales.

La mesure des coûts informatiques constitue une problématique complexe, mettant en jeu de nombreux facteurs. Elle est influencée par la taille et la nature de l’organisation. C’est un domaine où de nombreuses idées fausses amènent là prendre des décisions inefficaces, voire pernicieuses. Notamment, on confond souvent produit libre et gratuité. De la même manière, on se limite trop souvent à l’évaluation des coûts directs entraînant une dépense traçable en comptabilité et on omet les coûts induits.

3.2.4 La gestion budgétaire appliquée à la fonction informatique

3.2.4.1 Le service informatique prestataire de l’organisation

Le service informatique n’est pas propriétaire de l’information et ne doit en aucun cas exercer de pouvoir sur celle-ci. Son rôle est de mettre à disposition des utilisateurs les informations dont ils ont besoin dans l’exercice de leurs métiers, où qu’ils soient, quels que soient leur fonction et leur statut, et au bon moment.

La meilleurs pratique pour faire exercer ce rôle au service informatique est de le positionner en tant que fournisseur. D’ailleurs, certaines grandes structures en font une structure juridique singulière au service de l’ensemble de l’organisation, de type GIE, afin de formaliser cette position.

De ce fait, la meilleure manière d’aborder, sur le plan budgétaire, les coûts du service informatique et de l’obtention des services qu’il fournit à l’ensemble de l’organisation est de mettre en place la méthode ABC, Activity-Based Costing.

Mise en place de la méthode ABC pour évaluer les prestations du service informatique :

Elle nécessiter :

· De définir les activités ou tâches

Il faudra en premier lieu définir les activités ou tâches qui incombent au service informatique. Cela peut varier d’une organisation à l’autre, mais cette liste est absolument nécessaire, faute de quoi la confusion sur le rôle du service sera pérennisée.

· De définir les services rendus aux clients

Une procédure devra définir :

o les services que la direction informatique doit aux services clients ;

o le niveau qu’il doit atteindre pour chacun d’eux ;

o et la manière dont ils doivent être demandés par les clients et délivrés par le service informatique.

· De définir les inducteurs ou clés de répartition

Il est important que les inducteurs retenus expriment bien la proportionnalité entre le coût et le service rendu, afin qu’ils soient acceptés par les clients.

Il importe également de choisir des inducteurs qui pourront être mesurés et répartis de manière automatique à partir des données traitées elles-mêmes, afin de ne pas entraîner un coût supplémentaire pour les déterminer de manière manuelle.

Exemple :

On pourra retenir le volume de place disque occupée par les données du service utilisateur, le nombre de postes connectés au réseau, le nombre de pages imprimées, le nombre de transactions soumises à la base de données, le nombre d’interventions d’assistance effectuées sur une période, le nombre de licences d’un logiciel utilisées par le service…

3.2.4.2 La maîtrise des coûts liés à l’informatique

L’incitation à la croissance inconsidérée des coûts informatiques est générée, à la fois :

· par les utilisateurs, qui veulent toujours plus et mieux ;

· par le service informatique, qui veut prendre de l’ampleur au sein de l’organisation pour des motifs de pouvoir ;

· et par les fournisseurs, qui accélèrent l’obsolescence de leurs outils pour provoquer un besoin de renouvellement rapide, rémunérateur pour eux.

Pour maîtriser les coûts, qui sinon auront tendance à croître d’une manière sauvage et considérable, il faut définir une stratégie concernant les deux axes, renouvellement et développement. Celle-ci figurera dans le schéma directeur. Cela permettra que la stratégie en matière informatique reste en cohérence avec la stratégie de l’organisation.

Maîtriser les coûts n’implique pas nécessairement de remplacer des logiciels ayant un coût de licences d’utilisation par des logiciels libres. Car cela peut-être une sorte de fuite en avant car, au lieu de poser le problème de la définition d’une stratégie en matière de renouvellement de certains logiciels de types système d’exploitation, moteurs de base de données ou suites bureautiques, on se réfugie vers l’utilisation de logiciels libres, identifiés à tord comme des solutions gratuites.

3.2.5 L’évaluation des projets informatiques

3.2.5.1 Les méthodes d’évaluation des coûts en fonction des types de projets

Type de projet	Problématique du coût
Développement de logiciel	Maîtriser l’évaluation des jours/hommes nécessaires au développement et au déploiement de l’application. Evaluer le temps à passer par les utilisateurs à tester et recetter l’application. Prendre en compte le coût de la maintenance et de l’évolution pendant la durée de vie.
Mise en œuvre d’un progiciel	Evaluer le coût d’acquisition des licences, les prestations d’intégration par les consultants, la formation, mais également déterminer les coûts induits par les personnels, qui sont sollicités par le paramétrage et les tests, les conséquences du changement sur la productivité des utilisateurs, les coûts de maintenance et d’assistance ultérieure.
Mise à jour d’une suit e bureautique	Evaluer l’incidence du nombre de licences à mettre à jour pour garder l’homogénéité des versions. Envisager l’utilisation d’une suite de bureautique libre (sans licence à acquérir) sans en déduire que cette démarche est gratuite car il faut gérer le changement des habitudes qui entraîne la baisse d’efficacité des utilisateurs…

3.2.5.2 L’évaluation du retour sur investissement

Type de gains obtenus	Sources et effets
Gain de productivité	L’automatisation du traitement des informations permet une économie considérable d’heures de travail d’exécution.
Gain de qualité	L’automatisation des traitements permet d’intégrer des contrôles évitant de commettre certaines erreurs fréquentes. Le gain de qualité entraîne la diminution des coûts parasites liés à la correction des erreurs.
Meilleure disponibilité de l’information	Avoir la bonne information au bon moment peut permettre de prendre la bonne décision et d’anticiper certains événements.

3.2.5.3 Problématique du choix des investissements informatiques

Les investissements informatiques s’effectuent suivant deux axes du renouvellement des équipements existants et du développement des nouveaux équipements, en termes de matériels et de logiciels. Le budget étant limité des choix seront à opérer et il faut déterminer des critères de sélection et de classement des investissements, afin d’affecter au mieux les ressources disponibles.

Le domaine des investissements informatiques est complexe car ils induisent des charges complémentaires en termes d’assistance, de formation, de baisse de productivité des utilisateurs, de maintenance, charges qui ne sont pas toujours aisées à mesurer a priori.

La liste des investissements possibles fait partie du schéma directeur et de son découpage en tranches annuelles.

De surcroît, si les investissements sont mal choisis et les produits acquis mal adaptés aux besoins, les effets peuvent être inversés et complètement négatifs.

Critères de classements et de choix des investissements :

Les critères traditionnels peuvent être utilisés mais ils présentent pour la plupart d’entre eux une inadaptation de fond à la problématique définie ci-dessus.

a) Le classement par la Valeur Actuelle Nette (VAN)

Dans la majorité des cas, il est inefficace puisqu’il n’y a pas de flux de trésorerie entrants, c’est-à-dire par de recettes attendues suite à cet investissement. Cela peut tout de même avoir du sens si le service informatique effectue des investissements qu’il rentabilise en facturant effectivement ses prestations aux services clients. Cependant c’est une approche dangereuse car cela pourrait amener à privilégier des investissements qui ne présentent pas en réalité le maximum d’intérêt stratégique pour l’organisation, mais qui sont facturables à un prix élevé. Car pour rappel, ce n’est pas le métier de l’organisation.

b) Le classement par le délai de récupération (Payback)

Il faut évaluer les gains de productivité, en heures de travail économisées, les gains de coûts de la non-qualité évitée grâce à la diminution des phénomènes de non-qualité, les gains financiers liés à l’accélération des traitements de l’information et à la réduction du cycle d’exploitation qui permet de diminuer le besoin en fond de roulement…

c) Le classement par le taux de rendement interne (TRI)

Ce critère appelle les mêmes remarques que celui de la VAN.

 

 

3.3 L’architecture technique

3.3.1 Domaines de choix à effectuer

Partant de l’analyse des besoins du système d’information, il va falloir structurer l’architecture physique qui est nécessaire à ce dernier. Pour cela, quatre domaines sont à envisager ainsi que l’étude de leurs interactions.

Domaines	Rôles
1) Serveur	Permet de partager différentes ressources entre les utilisateurs.
2) Base de données	Offre des modalités de stockage et d’accès aux informations.
3) Poste client	Constitue l’interface d’accès de l’utilisateur aux applications et aux données.
4) Système d’exploitation	Constitue le logiciel de base offrant les fonctionnalités élémentaires.

3.3.1.1 Le serveur

Il y a différents types de serveurs, donc différentes manières de partages des ressources.

3.3.1.1.1 L’architecture matérielle des serveurs

Doit-on se tourner vers la micro-informatique ou vers les « mainsframes » ?

Micro-ordinateur : Ordinateur de dimension réduite dont l’unité centrale est constituée d’un ou plusieurs microprocesseurs.

Mainframe ou grand système : Terme utilisé à l’origine de l’informatique. A cette époque, un ordinateur occupait un espace important, spécialement aménagé en termes d’environnement en matière électrique et en climatisation.

3.3.1.1.2 L’usage et l’application fonctionnels des serveurs

Définition fonctionnelle de la notion de serveur : Un serveur, au sens informatique, est un ordinateur et/ou un logiciel, dont le but est de rendre des services à d’autres ordinateurs ou logiciel connectés à l’aide d’un réseau.

Suivant les services rendus, il existe plusieurs types de serveurs :

· le serveur de fichiers ;

· le serveur de base de données ;

· le serveur de transaction ;

· le serveur de groupware (gère les flux de travail d’un même groupe par une traçabilité) ;

· le serveur d’application objet (objet avec données et des traitements propres) ;

· le serveur d’application web (poste client par le web communique avec un serveur).

Le serveur de fichiers :

Un serveur de fichiers permet le partage d’informations au travers d’un réseau. Le serveur de fichiers assure uniquement le stockage des informations. Aucun processus dédié à la manipulation des données ne s’exécute sur le serveur, contrairement au serveur de bases de données. Il permet de centraliser le point de sauvegarde, dans la mesure où il centralise le stockage des données partagées. Le traitement de mise à jour se fait souvent la nuit.

Le serveur de base de données :

Le serveur de base de données constitue une évolution du serveur de fichiers. Ce dernier n’assurait, comme on l’a vu qu’un service de stockage. Un serveur de base de données assure ce même service de stockage, mais il fournit en plus une logique applicative permettant d’organiser les données et de les exploiter de manière plus efficace et performante.

Le logiciel de base de données :

· assure l’organisation des données ;

· leur stockage ;

· met en œuvre les mécanismes permettant d’y accéder ;

· ainsi que des fonctions de sécurité.

Il exploite :

· les fonctionnalités du serveur pour assurer le stockage des données ;

· et les fonctionnalités du réseau pour communiquer avec les postes des utilisateurs.

Dans cette architecture, les applications clientes ne manipulent pas directement les données. Elles communiquent avec le serveur de base de données en utilisant un langage dédié, le langage SQL (produit par Oracle Corporation sur les travaux d’Edgar Codd).

SQL se compose de 5 parties. Les quatre premières parties regroupent les ordres de structuration et d’exploitation des données, la cinquième s’apparentant davantage à un ensemble d’outils de communication et d’interfaçage.

Les 5 types de fonctions de SQL	Rôles
Commandes DDL (Data Definition language)	Définition de la structure des données de la base.
Commandes DML (Data Manipulation Language)	Réaliser les opérations courantes sur les données : insertion, modification, suppression, consultation.
Commandes DCL (Data Control Language)	Elles permettent d’assurer la sécurité des structures et des données. Elles sont à la disposition du DBA (Administrateur de la Base de Données).
Commandes TCL (Transaction Control Language)	Elles permettent de rendre cohérentes, sur la base de données, un ensemble d’opérations liées.
Commandes SQL Procédural (Traitements)	Elles permettent de déporter et de stocker des traitements sur la base de données afin d’automatiser leur exécution.

a) Les commandes DDL (Data Definition Language)

Ces commandes permettent de structurer la base de données. Les commandes DDL regroupent les ordres de gestion des tables de la base de données, qui sont des espaces physiques de stockage des données gérées par les utilisateurs. Ces ordres permettent de créer, de modifier, de supprimer des objets de type table à l’intérieur de la base de données. On y retrouve également les ordres de gestion des index, des contrôles et des contraintes.

Un index permet de retrouver les enregistrements dans les tables par rapport à un champ de données qui sera trié, afin d’accélérer la recherche.

Un contrôle est une action effectuée de manière automatique par le moteur de la base de données, sous certaines conditions, notamment lors de l’insertion, de la modification ou de la suppression d’un enregistrement dans une table de la base de données.

Une contrainte constitue un lien entre les données de plusieurs tables, qui permet de s’assurer de manière automatique de la cohérence des données au sein de la base, notamment lors d’insertion ou de suppression de données.

b) Les commandes DML (Data Manipulation Language)

Il s’agit certainement des commandes les plus utilisées, puisqu’il s’agit des commandes permettant de manipuler les données elles-mêmes. Chaque fois que l’utilisateur, au travers d’une application cliente, insère, modifie, supprime ou simplement consulte une donnée, il utilise un ordre de ce type. Il s’agit des ordres SELECT, INSERT, UPDATE et DELETE.

c) Les commandes SQL de type DCL (Data Control Language)

Le 3^ème type des ordres SQL permet d’assurer la sécurité des données et des structures, en définissant les utilisateurs et leurs privilèges. Il s’agit des ordres de type CREATE USER, CREATE ROLE, GRANT.

Si l’on a un nombre important d’utilisateurs et un nombre important de tables dans la base de données, accorder les privilèges pour chaque utilisateur, objet par objet, peut vite devenir fastidieux. Dans ce cas, on utilisera le mécanisme des rôles. Les privilèges sont attribués non pas aux utilisateurs directement, mais à des objets intermédiaires appelés rôles. Ensuite, on attribue un ou plusieurs rôles aux utilisateurs. On peut ainsi définir des rôles par domaines d’activités ou par prérogatives.

d) Les commandes TCL (Transaction Control Language)

Il s’agit de la gestion des transactions. Une transaction peut se définir comme le regroupement logique d’un ensemble d’ordres SQL de modification des données d’une base. Une transaction a pour but de garantir la cohérence des données lors d’une mise à jour, on parle de propriété ACID (Atomicité, Cohérence, Isolation, Durabilité).

Une transaction consiste :

· en un marqueur de début de transaction ;

· suivi d’un ensemble d’ordre SQL de modification des données (INSERT, UPDATE ou DELETE) ;

· et terminée soit par un ordre de validation de la transaction, soit par un ordre de retour en arrière, au dernier état stable connu.

Il faut toutefois prendre garde au fait que le mécanisme de gestion des transactions est très consommateur de ressources au niveau du serveur, et que toute donnée modifiée et non validée est bloquée pour les autres processus applicatifs sollicités par les utilisateurs. Une transaction fonctionne comme un système de brouillon, pendant son déroulement, le serveur maintient à la fois les données dans leur état original et dans leur état modifié. Si la transaction est validée, l’état d’origine est effacé. Si elle est annulée, l’état modifié est effacé. Ce maintien est réalisé dans un espace particulier de la base de données appelé segment d’annulation (ou rollback segment). Cette zone de débordement doit donc être dimensionnée de telle sorte que l’intégralité des transactions actives à un instant donné puisse y loger.

e) Commandes SQL Procedural

La 5^ème partie des ordres SQL concerne le SQL Procedural. Cette partie contient entre autre les procédures stockées PSM (Persistent Stored Module). Cela permet de disposer à l’intérieur de la base de données d’un véritable langage de programmation, utilisable sous forme de déclencheur, c’est-à-dire permettant la réalisation d’un traitement associé à un événement, ou utilisable sous forme de procédures ou de fonctions regroupées dans des événements, ou utilisable sous forme de procédures ou de fonctions regroupées dans des packages, afin de déporter sur la base de données une partie des traitements habituellement confiés à l’application cliente.

Dans ce type d’architecture, les ressources du serveur sont isolées des clients. La base de données fonctionne comme un processus dédié sur le serveur et communique avec les postes clients des utilisateurs au travers du réseau. Cela nécessite la mise en œuvre d’une logique de communication entre le client et le serveur. Du côté du serveur, un module dédié à l’écoute du réseau, nommé listener, est chargé de gérer les communications réseau, entre les clients et la base de données.

Du côté du poste client, une couche applicative spécifique devra être mise en œuvre suivant la base de données à laquelle on souhaite accéder. Diverses solutions techniques existent. Elles dépendent à la fois :

· de la base de données utilisée ;

· du système d’exploitation fonctionnant sur le poste client ;

· de la technologie de développement des applicatifs clients.

Sur un poste client fonctionnant sous Windows, une des solutions les plus répandues sera l’utilisation d’un pilote ODBC.

ODBC signifie Open DataBase Connectivity. Il s’agit de la définition d’une interface logicielle permettant à une application cliente de communiquer avec une base de données en utilisant le langage SQL. Les applications clientes développées à l’aide du langage Java utilisent une évolution de la technologie ODBC, nommée JDBC (pour Java DataBase Connectivity). ODBC et JDBC sont des interfaces logicielles standard, mais suivant la base de données exploitée, il sera également possible d’utiliser une interface logicielle propriétaire. Un poste client fonctionnant sous Windows, accédant à une base de données ORACLE, pourra soit utiliser le pilote ODBC pour Oracle fourni par Windows, soit utiliser le pilote ODBC pour Oracle fourni par Oracle, soit utiliser le client Oracle lui-même, c’es-à-dire une interface logicielle dédiée, optimisée pour la base de données concernée. Cette solution, plus performante en termes de vitesse d’accès à la base et en termes de fonctionnalités, est aussi plus contraignante à mettre en œuvre, car elle requiert une installation lourde sur le poste client. Elle est également plus complexe à mettre en œuvre au sein des applications clientes.

Le serveur de transaction :

Dans une architecture client/serveur à deux tiers telle que celle décrite précédemment, l’atomicité des transactions est gérée par la logique applicative sur le poste client. C’est en effet de la responsabilité du concepteur de l’application de choisir d’isoler au sein d’une transaction un ensemble d’ordres SQL. De plus, une transaction peut ne pas concerner qu’une seule source de données. Comment faire alors si une application doit mettre à jour, dans une même opération élémentaire, des informations présentes dans différentes bases de données ?

Il faut utiliser une architecture client/serveur avec moniteur de transactionnel. Dans ce modèle, le poste client n’exécute pas directement les ensembles d’ordres SQL servant à mettre à jour des données ou à récupérer les informations devant être affichées sur le poste de l’utilisateur.

Un moniteur transactionnel est un « middleware » de gestion des transactions requises par les utilisateurs, qui impliquent l’accès à de multiples sources de données.

Un middleware (ou intergiciel) est un logiciel qui sert d’intermédiaire de communication entre plusieurs applications, notamment sur un réseau.

Le client invoque des procédures distantes, placées sur le serveur. Les échanges entre le poste client et le moniteur transactionnel se font dans un langage et selon une norme définie par le moniteur transactionnel. Le rôle essentiel du moniteur transactionnel est de masquer la complexité de la structure des données aux clients. Ainsi l’application cliente émettra une demande de service auprès du moniteur transactionnel, qui sera le garant de la qualité de la réponse. Le moniteur transactionnel présente l’avantage de sécuriser les données, de permettre une meilleure répartition de la charge de travail au niveau des serveurs en intégrant une logique d’équilibrage dynamique des ressources et une gestion des priorités des requêtes. Outre la sécurité, le fait de masquer la complexité de la base de données, permet de faire évoluer cette dernière sans avoir à reconcevoir l’application cliente. Qu’on comprenne là l’intérêt de cette architecture, c’est de séparer physiquement le serveur de transactions du serveur de base de données.

Mais l’inconvénient d’une telle architecture réside principalement dans le fait qu’il est nécessaire d’écrire des procédures dans les programmes à la fois pour l’application cliente et pour l’application serveur.

Le serveur groupware :

C’est de combler les difficultés rencontrés lorsqu’on souhaite travailler de manière fiable à plusieurs personnes dans un échange collaboratif.

Les serveurs groupwares permettent de gérer cette complexité. Leur rôle est de permettre la gestion du workflow (littéralement le flux de travail ou d’activités) entre les différents acteurs d’un groupe de travail. On peut ainsi savoir où est un document, quel est l’acteur du système qui le détient pour modification. Il est possible d’organiser la circulation de l’information par la mise en place d’un circuit logique que doit suivre le document. On peut également retrouver l’historique des versions d’un document et connaître ainsi les modifications apportées par une personne en particulier.

Actuellement, la majorité des logiciels « groupware », disponibles sur le marché utilise la messagerie électronique pour faire circuler l’information.

Le serveur d’applications objet :

Au sens informatique du terme, un objet est un tout possédant un ensemble de connaissance et capable de réaliser certains traitements, appelés comportements.

La définition d’un objet se fait à partir d’un fichier de classe. Une classe contient :

· la description des variables de l’objet (les membres) ;

· et la description des fonctions (les méthodes).

Un objet donné correspond à l’instanciation d’une classe, c'est-à-dire à la création d’un exemplaire de la classe modèle. Cela correspond au moment où le fichier de classe est chargé en mémoire de l’ordinateur, et où il commence à « exister » réellement. Une classe peut faire l’objet d’une ou plusieurs instanciations.

Ainsi, l’ouverture d’une fenêtre dans une application quelle qu’elle soit correspond à l’instanciation d’une classe, et chaque fenêtre ouverte va se comporter de la même façon. Dans la fenêtre, le concepteur de l’application va placer des zones de textes, des champs de saisie, des listes, des boutons… en fait chaque élément de l’interface est un objet.

Dans le concept d’objet, il y a deux idées maîtresses :

· la première est la notion de composant ;

· la seconde est la notion de réutilisation.

En effet, si à chaque fois que le concepteur d’une application doit utiliser un bouton dans une fenêtre, il devait écrire tout le code relatif à la création du bouton et à la gestion de ses comportements, cela lui prendrait un temps considérable. Il y aurait en plus un risque évident qu’au fil du temps, les objets de type boutons devant avoir des comportements identiques dans deux fenêtres différentes seraient inévitablement codés de façon différentes.

L’apport de l’objet dans les applications se fait au niveau du composant métier. Ainsi l’objet métier, à l’image du bouton dans une fenêtre, possède des données qui lui sont propres et est capable de traitements relatifs à l’application de règles métier.

Un autre apport extrêmement important de l’objet dans les logiciels est la notion d’héritage. Cette notion permet de créer une hiérarchie de classe, où toute classe de niveau N+1, héritant d’une classe de niveau N, reprendra l’ensemble du patrimoine génétique de la classe parente (les membres et les méthodes), tout en ayant la possibilité de compléter ce patrimoine par de nouveaux membres et/ou de nouvelles méthodes, et, si besoin, de redéfinir des éléments (membres et/ou méthodes). On parlera aussi dans ce cas de classes dérivées.

Dans le cadre d’une application objet, on retrouve des objets sous forme de composants à la fois du côté du serveur et du côté du client.

Les objets clients communiquent avec les objets serveur au moyen d’un ORB (Objet Request Broker ou courtier de requête objet). Un ORB peut se voir comme un dispositif logiciel permettant à un objet client d’envoyer une requête à un objet serveur, puis de recevoir la réponse du serveur, et cela sans avoir à gérer la localisation des objets. Lorsqu’un objet client invoque une méthode d’un objet distant, l’ORB localise l’objet serveur et lui transmet un message correspondant à sa demande. L’objet serveur exécute la requête et retourne le résultat à l’objet client. Les architectures à objet répartis s’appuient sur la norme CORBA (Common Object Request Broker Architecture).

Le serveur d’application Web :

Le Web permet à des postes clients, équipés d’un logiciel particulier, nommé navigateur, d’envoyer des requêtes à un serveur. En réponse à ces requêtes, le serveur retourne au client un flux d’informations structuré, mis en forme et affiché par le navigateur. Pour échanger, le client et le serveur utilisent un protocole de type RCP (Remote Procedure Call ou Appel de Procédure Distante), appelé http (Hyper Text Transfert Protocol).

Pour fonctionner, le Web s’appuie sur un ensemble de technologies normalisées :

· le navigateur Web ;

· le serveur Web ;

· entre les deux, une liaison réseau nommée Internet, consistant en un protocole de communication http, s’appuyant sur la pile de protocoles TCP/IP.

Le navigateur Web est constitué de trois éléments :

· un moteur de rendu permettant de traiter et d’afficher les différents standards du WWeb (HTML, XHTML(le X veut dire que le HTML est plus protégé), XML(c’est le balisage des documents pour qu’ils soient lus), CSS (c’est un sous-programme de présentation, couleur, largeur des traits…)…) ;

· une interface utilisateur permettant à l’internaute de voir de façon intelligible le contenu d’une page Web, et d’interagir avec elle (clic sur un lien, saisie d’un formulaire, défilement de pages…) ;

· pour finir, un gestionnaire d’extensions (extensions également appelées plugins) permettant au navigateur de s’enrichir et d’être capable d’actions non définies à l’origine.

Fin 1997, le W3C publie la spécification 4.0 de HTML, introduisant entre autre les feuilles de style (CSS), les cadres (frames) et les applets, permettant la gestion dynamique de contenu, c'est-à-dire qu’une seule partie de la page est réactualisée (au lieu de toute la page), ce qui permet une plus grande vitesse de réponse car le serveur est questionné sur une seule partie de la page.

3.3.1.2 La base de données

Une base de données peut se définir comme un ensemble structuré d’informations, stocké sur une mémoire de masse, disposant d’un logiciel spécialisé dans l’organisation et la gestion des données, ainsi que dans le contrôle des accès concurrents.

1) Systèmes de fichiers en séquentiels indexés

Un index se présente sous la forme d’un fichier organisé de façon différente du fichier de données et associé à celui-ci.

2) Les bases de données hiérarchiques

Une base de données hiérarchique est organisée en arborescence. Un élément peut avoir plusieurs descendants, mais il ne possède qu’un seul ascendant, à l’image d’un système de fichiers. On est en présence de relation de type 1,N.

Ce type de représentation est pratique pour des données ayant un lien de dépendance, mais lorsque la relation de 1 vers N ne peut respectée, le modèle hiérarchique ne peut plus être utilisé. Pour lever cette contrainte, le modèle hiérarchique a évolué vers le modèle des bases de données réseau. Dans ce type de base de données, il est possible de créer des liens entre tous les objets, on parle de base de données relationnelles.

3) Les bases de données relationnelles

Les bases de données relationnelles représentent aujourd’hui les trois quarts des bases de données en exploitation. Le modèle relationnel fournit une représentation des données sous forme matricielle. Les données sont stockées dans des tables pouvant se concevoir comme des tableaux à deux dimensions. Les colonnes des tables représentent les différents champs permettant de stocker l’information. Chaque ligne correspondant à un enregistrement. En algèbre relationnelle, on dira qu’une table est une relation. Elle est constituée :

· d’un schéma fixé et d’une extension ;

· d’un contenu, ensemble de n-uplets non ordonnés.

Exemple :

La table ou relation « Personne » se définira de la façon suivante :

PERSONNE {ID_PERSONNE INTEGER, NOM VARCHAR(50), PRENOM VARCHAR(50), SEXE VARCHAR(1)}

Le peuplement de cette relation se notera :

{

ID_PERSONNE : 1, NOM : DUPONT, PRENOM : PAUL, SEXE : M

…

}

Dans le modèle relationnel, les propriétés d’une relation sont subordonnées à une propriété particulière, la clé primaire.

Cette propriété garantie l’unicité des n-uplets. Il ne sera pas possible d’avoir deux enregistrement dans la table ayant le même identifiant, de cette manière, on s’assure de la non-redondance des informations. Dans le modèle relationnel, il est possible de combiner les relations entres elles. Dans c cas, on parle de jointure. Pour combiner des relations entre elles, il faut faire correspondre une ou plusieurs propriétés de la première relation avec un nombre équivalent (et logique) de propriétés der la seconde relation.

Dans notre exemple, on peut ajouter une catégorie à la personne : étudiant, salarié… Cela sera un sous-ensemble qui viendra s’ajouter à PERSONNE, et cette catégorie aura une clé étrangère de lien avec l’autre table CATEGORIE.

La combinaison de relations permet de définir des jointures de type 1 à N. Il arrive cependant que la combinaison conduise à des jointures de type N à N, c’est lorsque 2 tables en créent une troisième.

4) Les bases de données objets

Les systèmes de gestion de base de données objet (SGBDO) permettent de stocker l’information non pas sous la forme d’une représentation matricielle, comme dans les SGBDR, mais sous forme objet, représentation de la réalité, incluant à la fois les données et les traitements. Comme on l’a vu précédemment, un objet est l’instanciation en mémoire, d’une classe. Une des difficultés rencontrées est la possibilité de rendre permanente l’information objet même en cas d’arrêt de l’ordinateur hôte. Si l’ordinateur est privé de courant électrique, le contenu de sa mémoire est irrémédiablement perdu. Il a donc fallu trouver des méthodes pour rendre les objets persistants.

Une méthode communément utilisée consiste à stocker la description des objets dans des tables d’une base de données relationnelle. Il y a dans ce cas une déstructuration de l’information puisque l’on enregistre les informations de description de l’objet lui-même.

Une base de données objets comporte un langage de description de schéma, un langage de programmation orienté objet. Comme dans les bases de données relationnelles, il existe un langage de requête. Il s’agissait de SQL pour les bases de données relationnelles. On disposera d’OQL pour les bases de données objet.

L’utilisation d’un SGBDO permet aux objets persistants d’apparaître comme élément du langage.

3.3.1.3 Le poste client

Le client lourd ou client de gestion :

Le terme « client lourd » (ou client de gestion), désigne une application cliente graphique exécutée sur le système d’exploitation de l’utilisateur.

Le client léger :

Le terme « client léger », souvent cité en opposition au client lourd, désigne en fait deux types de technologies totalement différentes.

Dans un cas, la logique de présentation de l’application s’appuie exclusivement sur une interface web. Dans l’autre cas, on utilise un logiciel client dédié, s’exécutant soit dans la machine de type PC reconvertie en terminal, soit dans une machine de type terminal dédié.

a) Client léger à interface Web

Ce terme sert à désigner une application accessible via une interface Web, consultable à l’aide d’un navigateur Web, où la totalité de la logique applicative métier est traitée du côté du serveur.

b) Client léger à interface dédiée

Pour mettre en place une architecture de type client léger, il est possible d’utiliser une couche cliente spécifique. Dans ce cas, le poste client reste un ordinateur à part entière, permettant l’exécution comme dans le cas du client lourd, des applications utilisant les ressources de la machine (mémoire, disque dur, processeur…), mais également de virtualiser le poste client en utilisant des protocoles de type RDP (Microsoft Terminal Server) ou ICA (Citix Presentation Server).

Dans cette architecture, l’utilisateur dispose, à partir de son bureau informatique, d’un raccourci vers un logiciel client. Ce logiciel prend en charge la connexion à un serveur dédié, permettant à l’utilisateur d’ouvrir une session de travail distante. Il se retrouve alors dans une configuration identique à celle qui serait la sienne si les applications auxquelles il accède étaient installées sur son poste. Les avantages de cette solution sont multiples :

· En matière d’installation

Il n’est plus nécessaire de réaliser une installation des logiciels sur chaque poste utilisateur, mais de réaliser l’installation uniquement sur le serveur. Il faut ensuite uniquement publier cette application pour les utilisateurs autorisés.

Par la suite, si un nouvel utilisateur doit accéder à cette application, il sera uniquement nécessaire :

o soit de l’inscrire dans un groupe disposant de l’application ;

o soit de publier l’application pour cet utilisateur.

Cette tâche ne prendra que quelques secondes à un administrateur. Elle se fera de façon centralisée, sans avoir besoin de se déplacer jusqu’au poste de l’utilisateur ou de prendre le contrôle de son poste à distance.

Dans le cas d’une évolution, il suffira à l’administrateur de mettre à jour l’application sur le serveur, pour qu’elle soit automatiquement disponible et à jour pour l’ensemble des utilisateurs.

· En matière de durée de vie du parc informatique

On est passé d’une durée de vie moyenne d’un poste utilisateur de sept ans à cinq ans, puis trois ans. Même s’il est vrai que parallèlement le prix des matériels a considérablement baissé.

· En matière de sécurité

Toutes les ressources de l’utilisateur étant déportées sur le serveur, le poste client n’est plus qu’un simple outil de travail individuel. Aucune donnée sensible n’est plus présente dessus, de plus on ne peut pas installer des logiciels sur son poste.

c) Client léger et terminaux spécifique

C’est lorsqu’on utilise les navigateurs internet sur son poste pour se connecter à un serveur Web, le navigateur est parfois appelé client universel.

Le client léger à interface riche :

Un « client riche » est compromis entre le client léger et le client lourd. Les clients riches permettent ainsi de gérer l’essentiel des traitements du côté du serveur. Les données sont ensuite transmises dans un format d’échange standard utilisant la syntaxe XML (SOAP), puis elles sont interprétées par le client riche.

3.3.2 Structures types de déploiement

3.3.2.1 Déploiement client/serveur

Le déploiement client/serveur consiste à mettre à disposition des postes clients, les applications opérationnelles auxquels ils ont accès.

3.3.2.2 Utilisation d’un serveur d’application

Une autre solution disponible pour les applications de type fenêtrées, est la virtualisation. Microsoft avec Windows Terminal Server Edition (TSE) et Citrix avec Presentation Server proposent des solutions de virtualisation et de streaming d’applications. Elle permet, en plus, de mettre un système d’authentification unique pour les applications virtualisées. Cette méthode s’appelle le SSO (Single Sign On). La virtualisation permet également, et il s’agit là d’un aspect non négligeable, de continuer à utiliser des postes clients qui commenceraient à manquer de ressources du fait de l’augmentation de puissance demandée par les applications. Il y a donc rallongement de la durée de vie potentielle des postes clients.

Dans ce type de déploiement, on prendra soin de dimensionner correctement les ressources du serveur (puissance processeur, mémoire, disque). La puissance disponible sur le serveur, sera bien en dessous de la puissance cumulée de l’ensemble des postes utilisateurs, dans une solution alternative, avec une économie importante.

3.3.2.3 Recours au « middleware »

Le middleware (terme anglais sans réel équivalent en français, on trouvera comme traduction les termes de logiciel médiateur ou d’intergiciel, peu satisfaisants) est une couche logicielle dont le but est d’assurer le dialogue entre le client et le serveur dans des environnements hétérogènes.

son rôle est d’assurer le transport des requêtes et des réponses du client au serveur. En terme de structure logicielle, le middleware se situe entre le logiciel applicatif et le système d’exploitation. Il existe différents types de middleware. Un pilote ODBC est un middleware, il constitue une interface pour se connecter à une base de données, permet de transmettre les requêtes au moteur de la base de données et de récupérer les réponses.

3.3.2.4 Mode de déploiement n-tiers

Avant d’arriver à des architectures multi-tiers (ou n-tiers), revoyons les différentes étapes :

1) Dans une architecture un tiers, le client se présente sous la forme de terminaux passifs. Le serveur prend en charge la totalité du déploiement. La gestion des données, l’exécution des traitements et la présentation des résultats sont assurés par le serveur.

2) Dans une architecture deux tiers, le client prend en charge la partie traitement et la partie présentation de l’application. De son côté, le serveur assure la gestion des données. Pour dialoguer le client et le serveur utilisent les service d’un middleware de type ODBC. Les applications opérationnelles fonctionnant dans des interfaces graphiques, en mode client lourd, correspondent à des applications client/serveur à deux tiers. Ce type de déploiement a été très utilisé par le passé et reste encore aujourd’hui le mode de déploiement le plus fréquemment rencontré.

Les architectures deux tiers présentent un inconvénient majeur, qui est que le client doit assurer à la fois la présentation des données et la logique applicative (les traitements).

3) L’architecture trois tiers.. Il y a donc besoin de séparer la partie présentation de la logique de traitement. On arrive ainsi à une séparation complète données, traitements, présentation. Il s’agit là d’une architecture baptisée architecture trois tiers. Les moniteurs transactionnels s’inscrivent tout à fait dans cette logique.

Internet et le Web représentent également une architecture de type trois tiers. La partie présentation est dévolue au poste client au travers d’un logiciel spécialisé, le navigateur. Le navigateur communique au travers d’un protocole standardisé (http) avec le serveur Web. Les traitements sont répartis en traitement locaux, exécutés sur le poste client, par le navigateur, à l’aide d’un langage script (VB script ou Java script), et les traitements globaux exécutés sur le serveur. La gestion des données est toujours confiée à un serveur de base de données.

4) Les architectures n-tiers. Attention, architecture n-tiers ne signifie pas que l’on multiplie les niveaux de services, mais que l’on répartit l’application sur de multiples fournisseurs de services. Cette répartition est possible par l’utilisation de composants métiers, indépendants et spécialisés, mis en œuvre par une approche objet. Les applications et les architectures n-tiers offrent une vision systémique du système d’information de l’entreprise. Celui-ci est constitué d’objets métiers communiquant entres eux et avec l’utilisateur pour fournir un ensemble de services. L’évolution du système d’information de l’entreprise passe alors par l’évolution des objets métier distribués, au travers d’évolution ponctuelles intégrées, maîtrisées, n’impliquant pas une remise en cause du système dans son ensemble.

3.3.2.5 Utilisation d’un portail ou d’un espace numérique de travail

Selon l’Education Nationale, les « espaces numériques de travail » (ENT) sont des sites « Web portail » permettant d’accéder, via un point d’entrée unique et sécurisé, à un bouquet de services numériques ; ils peuvent être mis en œuvre dans les écoles, les établissements publics locaux d’enseignement (EPLE) et les établissements d’enseignement supérieur visés par les dispositions des articles L.711-1 à L.722-16 du code de l’éducation.

L’objectif d’un environnement de travail est d’utiliser le navigateur web du poste client comme d’une interface universelle. L’intérêt d’utiliser un ENT devient évident dès lors que les applications opérationnelles sont des applications n-tiers. Dans ce cas, l’utilisateur, par le biais de son navigateur, se connecte au serveur.. De là, il peut accéder à l’ensemble de ses ressources (messagerie, planning, forums, site Web, application opérationnelle…). Dans ce contexte, l’ENT se sert d’un annuaire LDAP pour l’authentification (CAS, Central Authentification Service). Toutes ces ressources sont indépendantes de la nature du poste client et du système d’exploitation utilisé, qu’il s’agisse d’un PC sous Windows, d’un Macintosh sous MAC OS ou d’une machine sous Linux.

3.3.2..6 Nouvelles tendances : services et virtualisation

a) Le web service

Le web service est une technologie qui permet à un fournisseur de proposer des services informatiques, exposés sur le web. Cela permet de faire communiquer des environnements hétérogènes. Les web services s’appuient sur le protocole SOAP.

b) SOAP, Single Object Acces Protocol

Il s’agit d’un protocole de transmission de messages qui permet d’invoquer des méthodes distantes, implémentées dans des objets non présents physiquement sur la machine d’exécution de l’application. Il s’agit donc d’un protocole de type RPC (Remote Procedure Calll), utilisant http pour le transport des données et XML pour le langage de description des données.

c) Saas, Software as a Service

Il s’agit d’applications informatiques fournies non pas sous la forme d’une licence classique avec la possibilité à son détenteur de l’installer pour l’utiliser, mais d’applications, souvent métiers, fournies sur internet, que l’on ne paye qu’à la consommation. On peut parler ici d’informatique « on demand ».

Ce qui différencie les applications de type SaaS des applications précédemment bâties sur le modèle ASP (Application Service Provider), c’est qu’il s’agit d’applications conçues dès le départ pour un usage via interface web, contrairement aux applications traditionnelles sur lesquelles est venue se greffer l’interface web.

En termes de montée en charge et de déploiement, la mise en œuvre d’une solution SaaS est également très allégée. Il suffit que l’utilisateur final ait à sa disposition un poste informatique équipé d’un navigateur compatible avec les spécificités du service pour que ce dernier puisse accéder aux ressources mises à sa disposition. Il n’est plus nécessaire de procéder à une installation physique sur le poste utilisateur. Suivant les applications utilisées, les investissements en termes de matériel informatique pour les utilisateurs finals peuvent être grandement réduits. Au lieu d’équiper chaque utilisateur d’un PC complet, il peut être envisagé la mise en place de terminaux légers de type NC –Network Computer).

Dans cette méthode, il y a le problème des navigateurs avec leurs différentes versions et leurs particularités qui apportent des comportements des applications différentes. De plus, il y a l’hébergement des données délocalisées où on ne sait pas vraiment où elles se trouvent physiquement. Il y a aussi un risque lorsqu’on change d’hébergeur, comment se fera le basculement ?

d) Le cloud computing

Il se base sur des architectures réparties, structurées en nuages d’ordinateurs, interconnectés par des réseaux avec une bande passante importante. Le cloud computing pose comme postulat que l’entreprise n’aura plus d‘intérêt à investir dans les serveurs, mais pourra comme elle le souhaite disposer de services, de capacité de calcul, de capacité de stockage à la demande, notamment au travers de logiciels fournis sous forme de SaaS.

e) La virtualisation

Dans le cas de la virtualisation du poste de travail, un système d’exploitation hôte sera installé sur la machine, puis un logiciel dédié (tel que VirtualBox, VMWare…) sera lancé. Ce logiciel aura pour tâche d’émuler une ou plusieurs machines physiques, pouvant chacune exécuter un système d’exploitation différent, et disposant chacune de leurs ressources propres. De plus, il est très facile de créer des images des machines virtuelles permettant de cloner très facilement une machine, puis la restaurer.

On peut aussi virtualiser les serveurs, afin d’avoir une meilleure optimisation de leurs ressources mémoires.

 

3.4 L’auditeur en environnement informatique

 

3.4.1 Audit en système d’information et audit informatique

 

Une erreur à éviter consiste à considérer l’audit du système d’information et l’audit informatique comme une seule et même chose.

 

L’audit du système d’information va permettre :

·         de vérifier que les besoins et les règles de gestion par rapport à ce que sont l’organisation et les objectifs qu’elle poursuit sont définis correctement ;

·         de recenser les outils nécessaires pour satisfaire ces besoins et de vérifier s’ils sont présents ou non.

 

L’audit informatique va permettre :

·         de s’assurer que les outils fournis correspondent bien aux besoins recensés ;

·         qu’ils réalisent correctement ce pour quoi ils sont prévus ;

·         que les services associés dans les différents domaines à mettre en œuvre ont le niveau de qualité attendu.

 

 

3.4.2 Démarche et outils d’audit du système d’information

 

3.4.2.1 La démarche

 

Il faut tout d’abord définir le domaine d’étude, pour délimiter le champ d’investigation. Il n’est pas systématique que l’audit porte sur l’ensemble du système d’information, même si cela peut être le cas.

 

Afin de s’imprégner des règles de gestion existantes et de celles souhaitées par les décideurs, l’auditeur réalisera des interviews des décideurs et des opérationnels, respectant en cela la définition, qui a été donnée précédemment de la structure d’un système.

 

Domaines à appréhender	Modalités
Fonctionnement de l’existant	Cette collecte est effectué auprès des opérationnels, qui gèrent les flux.
Règles de gestion souhaitées par le décideur	A l’aide d’interview des décideurs.
Mesure des écarts entre ce qui est souhaité et ce qui est souhaitable, pour le bon fonctionnement de l’organisation.	Comparaison entre les points de vue souhaités par les décideurs et la détermination de pratiques efficientes.
Mesure les écarts entre le souhaitable et la réalité	Comparaison entre les points de vue et les pratiques souhaitées par les décideurs et mis en œuvre par les opérationnels.

 

Les acteurs des processus audités ne sont pas passifs dans cette démarche. Ils sont appelés à réfléchir sur leurs méthodes de travail et à découvrir ce que font les autres membres de l’organisation. On obtient donc un effet positif, dérivé de la démarche, en termes de cohésion des équipes et d’apprentissage organisationnel. Ce sera un facteur positif en cas de modification ultérieurs de l’organisation, car la tendance à la résistance au changement sera plus faible à la suite de cette démarche.

 

 

3.4.2.2 Les outils

 

a)      Rôle des outils

·         de s’imprégner du contexte de l’organisation, en évitant les contresens et faux-sens ;

·         d’être le plus exhaustif possible.

 

b)      Mise en œuvre des différents outils

·         collecte des documents

Il faut collationner un jeu complet de tous les documents utilisés. On ne se bornera pas à collecter des documents vierges. On demandera également aux utilisateurs concernés des copies de documents remplis.

Les raisons de cette demande sont les suivantes. Il arrive fréquemment que l’on trouve, sur un document rempli, des mentions marginales en dehors des rubriques d’information pré imprimées. Il arrive également de trouver des mentions au dos du document. Ces informations peuvent être normalisées, comme des conditions générales de ventes. Elles apportent des renseignements utiles à la compréhension du fonctionnement du processus.

Pour les documents remplis, on demandera un échantillon de cas divers et significatifs des différents scénarios possibles. Cela permettra d’éviter d’oublier les cas marginaux. Bien que peu fréquents, ils sont importants dans la mesure où ils représentent une augmentation de la complexité du système d’information à prendre impérativement en compte.

Si ce n’était pas le cas, on se trouverait face au développement de l’entropie dans l’organisation. On notera :

o  le nombre d’exemplaires des liasses ;

o  les informations clairement répertoriées et formalisées ;

o  mais également la présence d’informations informelles ou marginales ;

o  les informations présentes au recto du document, mais également au verso.

 

·         Déroulement des interviews

Les entretiens avec les utilisateurs et les décideurs vont permettre :

o  de préciser les règles de gestion qui doivent être appliquées dans le déroulement du processus par les opérationnelles. Ils doivent également exprimer les conséquences organisationnelles que ces règles induisent ;

o  d’obtenir des informations complémentaires à propos du contenu des documents. L’auditeur ne doit pas avoir d’a priori. Il doit vérifier qu’il a parfaitement compris la signification de chaque élément trouvé sur les documents.

o  de mettre en accord les différentes personnes concernés par le processus. Dans un processus de traitement de l’information, les utilisateurs sont interdépendants. La prise de conscience de cette situation est souvent nouvelle pour les acteurs du groupe de travail. Les interviews permettent de faire prendre conscience des dépendances entre personnes qui n’appartiennent pas nécessairement aux mêmes services. Cela permet de justifier à leurs yeux certaines tâches qui leur sont imposées, alors qu’ils n’en tirent pas de bénéfices directs dans leur poste de travail. Cela permet de construire une approche de groupe de travail (groupware) qui ne s’appuie pas exclusivement sur les outils informatiques, mais, au contraire, sur les besoins organisationnels de l’entreprise ;

o  de faire apparaître d’éventuels problèmes de conflits ou d’organisation. Si la démarche doit aboutir à des modifications du système d’information, cela entraînera des modifications de l’organisation. Il faudra revoir les profils de postes et la répartition des tâches. Ces évolutions entraîneront des conflits potentiels, qu’il faut anticiper avant de les gérer ;

o  d’amener les décideurs à prendre les décisions qui s’imposent. L’audit du système d’information amène le plus souvent à opérer des modifications dans la gestion des processus et dans l’organisation des postes de travail. Si l’organisation s’engage dans une démarche d’audit de son système d’information, c’est en général à la suite d’une prise de conscience des décideurs qu’il existe des dysfonctionnements.

Les décideurs peuvent avoir peur des conflits et hésiter à conduire le changement, ils pourront remettre leurs décisions d’ordre organisationnelle à plus tard. L’interview collectif lui fera prendre conscience de la nécessité à une remise à plat des procédures, en entraînant une réorganisation des groupes de travail.

 

Nature des interviews	Objectifs poursuivis
Individuelles	Compréhension du poste de chaque opérationnel.
	Expression des règles de gestion souhaitées, par les décideurs.
	Analyse détaillée des informations manipulées, présentes sur les docs.
Collectives	Prise en compte de l’interdépendance des individus dans les groupes de travail.
	Perception des sources potentielles de conflit.
	Perception des nécessités de réorganisation.

 

·         Outils de modélisation des processus

Cette phase vise à formaliser la compréhension du domaine et à faire valider sa vision des processus, des problèmes et des solutions proposées

 

 

3.4.3 Démarche et outils d’audit de l’informatique

 

On utilisera souvent le modèle CobiT (Control Objectives for Business & Related Tecnology) pour mettre en œuvre des techniques d’audit informatique.

Ce modèle décompose le système d’information en 4 domaines, qui se décomposent eux-mêmes en 34 procédures.

 

Domaines	Nombre de processus
La planification et l’organisation	11
L’acquisition et l’installation du matériel	6
La livraison et le support	13
Le monitoring ou surveillance des processus	4

 

IT GOVERNANCE - la gouvernance des technologies de l’information, c'est-à-dire du système informatique :

·         Alignement avec la stratégie de l’organisation, servir la stratégie pour être un facteur clé de succès ;

·         Mesure de la performance, doit disposer d’indicateurs de mesure de la performance des différents types de services offerts à l’organisation ;

·         Gérer les ressources, doit permettre de gérer les ressources utilisées dans le cadre du système informatique ;

·         Gérer les risques, doit permettre d’évaluer les risques et de les gérer pour qu’ils ne se déclenchent pas ;

·         Analyse de la valeur fournie, doit posséder un mécanisme d’évaluation et de contrôle de la valeur fournie par rapport à la valeur attendue.

L’intérêt d’utiliser ce modèle d’audit est qu’il est le support de certification comme l’ITIL.