Cours de Systèmes d'information (.pdf)

COURS DE SYSTÈMES D’INFORMATION

IUT de Tarbes Université Paul Sabatier

Licence ATC

Année 2005/2006 P A T R I C K F E R R É

C^HAPITRE 1: L^{ATECHNIQUECLASSIQUEDEMISEENŒUVREDES} SI... 6

Section 1 L’étude préalable... 6

Sous section 1 La décomposition en étapes... 6

§1 Les différentes étapes... 6

§2 Intérêts et lacunes de la décomposition en étapes... 6

§3 La tendance à l’intégration... 7

Sous section 2 Les objectifs de l’étude préalable... 8

§1 Formuler le problème à résoudre... 8

A) La formulation des besoins... 8

B) Poser correctement le problème à résoudre... 8

§2 Définir un avant-projet de solution... 8

A) La praticabilité de la solution... 8

B) L’opportunité de l’automatisation... 9

Sous section 3 Les techniques de l’étude préalable...9

§1 L’organisation de l’étude préalable... 9

A) La responsabilité de l’étude... 9

B) La planification de l’étude préalable... 10

§3 L’analyse de l’existant synonyme de documentation... 10

A) Le recueil des informations... 11

B) La présentation des observations... 13

§4 Le diagnostic de l’existant... 14

Section 2: La réalisation de l’avant projet... 17

§1 L’élaboration des solutions...17

A) Le cadre de solution... 17

B) La construction de l’avant projet... 19

§2 L’évaluation des solutions... 20

A) La praticabilité de la solution... 20

Section 3 Le dossier d’avant projet et le cahier des charges... 22

§1 Le dossier d’avant projet... 22

§2 Le cahier des charges (aspects juridiques)... 22

§3 La fusion du dossier d’avant projet et du cahier des charges... 23

C^HAPITRE 2 L^{ESTECHNIQUESDE}PROTOTYPAGEETDEL’UTILISATEURFINAL...25

Section 1 La stratégie du prototypage... 25

§1 Philosophie du prototypage... 25

§2 Les techniques de la stratégie de prototypage... 27

Section 2 L’informatique de l’utilisateur final...30

Sous section 1 Le contexte de développement de l’I.U.F...30

§1 Le développement des outils Bureautique... 30

§2 L’interrogation simplifiée et le développement des bases de données... 31

§3 Le développement des progiciels: Les produits logiciels... 31

§4 Les langages dit de quatrième génération... 31

§5 L’explosion de la micro-informatique... 32

Sous section 2 Conditions et limites de l’I.U.F...32

§1 L’utilisateur final est un gestionnaire informaticien... 32

§2 Les limites de l’I.U.F... 33

Sous section 3 Les principes affectés par le concept d’informatique de l’utilisateur final... 34

§1 L’organisation néo-taylorienne des systèmes d'information... 34

§2 La technique plus souple des Computers Personnel de l’I.U.F... 35

§3 La modification de la relation agent / poste informatique... 35

§4 La modification des étapes de mise en œuvre... 35

CHAPITRE 3 LACRISEDES MÉTHODES... 37

Section 1 Un état des lieux des méthodes traditionnelles... 37

§1 Des chiffres éloquents... 37

§ 2 Une contradiction... 37

§ 3 Un mythe à comprendre et à gérer... 38

Section 2 Développer rapidement des solutions... 38

§2 Le développement de composants logiciels à l'aide de RAD...38

Section 3 Les modèles adéquats apparaissent... 39

§1 Des aménagements espérés... 39

§2 Des méthodes maintenant mieux adaptées... 39

ENGUISEDECONCLUSION...40

II Partie

La Mise en œuvre des Systèmes d’information

Au terme de la première partie de ce polycopié ( traité en 2er année SeRéCom), nous disposons des concepts qui dominent l'étude des systèmes d'Information et partant leur mise en œuvre. Ces concepts de base constituent un cadre, utile, mais non « indispensable » s’il sagit de traiter d’une étude limitée aux techniques de Mise En Oeuvre des Systèmes d’information dans les organisations. Chose ce que nous allons maintenant étudier.

Pour mieux situer ce que devient notre objet d'étude traitant maintenant plus des aspects "organisationnels" de l'automation dans les organisations, nous pouvons nous inspirer des titres d'ouvrages qui dominent la littérature existante. Ces derniers évoquent les façons diverses les méthodes de l'automatisation. Ainsi selon les ouvrages l'on trouve les titres évocateurs suivants: "La Mise en œuvre des Systèmes d'Information" qui évoque l'approche la plus générale. S'il est question de mettre l'accent sur les technologies de l'automation l'on évoque "La Conduite des projets d’automatisation de traitements". Enfin si l'objet d'étude relève plus particulièrement des aspects organisationnels l'on trouve comme intitulé "la Conception des systèmes d’information". Soit un corps commun d'idées et des gradations mettant en avant les aspects techniques ou ceux relevant de l'organisation de l'entreprise.

Notons alors que les différents intitulés avancent toujours l’idée de l’utilisation de méthodes présentées comme nécessaires à l’étude et à la mise en œuvre des systèmes d'Information. Notons aussi que les contenus diffèrent selon l'intérêt, plus ou moins prononcée, porté aux technologies d'automatisation.

A) Deux sous-entendus implicites

1°) La complexité: Les traitements et les problèmes liés à l’utilisation de l’information sont des problèmes complexes. Cette caractéristique invite à recourir à des modèles conceptuels auxquels se référer ou dit autrement à des méthodes adaptées. La théorie systémique se proposant de décrire les organisations comme étant des systèmes complexes susceptibles d'être modélisés. Les systèmes doivent donc pourvoir être disséqués pour être compris au plus secret de leur complexité. Ce n'est donc pas une moindre ambition, ni une tentative qui choisirait les chemins de la facilité.

2°) L'automatisation de tâches "intellectuelles": Les traitements étudiés ont pour objet des travaux intellectuels, qui concourent à la prise de décisions, gérées par les organisations. Cette caractéristique de l'objet d'étude est essentielle. Il ne s’agit pas de d'organiser le fonctionnement de machines ou l'automatisation des chaînes de production. Le domaine est plus "sensible" puisqu'il s'agit d’introduire des modifications touchant à la prise de décision. Ce, en confiant à des automates des travaux qui étaient et sont souvent considérés relever de l'intelligence humaine.

La prise en compte de ces deux caractéristiques constitue le terrain d'investigations d’écoles qui proposent différentes méthodes. On distinguera pour aborder cette étude deux approches, nées de deux "courants de pensée". L'un qualifié de "classique" et l'autre présenté comme regroupant des techniques ou méthodes qualifiées d'alternatives. Nous notons à ce stade que les méthodes classiques (initiales), ont été élaborées pour des systèmes centralisés et ont du accepter la remise en cause de certains de leurs principes initiaux, dès l'apparition massive dans les bureaux de la micro informatique.

B) Deux grands courants (ou écoles) 1°) L'approche classique

Longtemps dominante cette dernière est une approche théorique qui se caractérise par un formalisme pointilleux et efficace. Au point que l'on peut dire qu'elle est dominée par une conception des systèmes d'information que l’on peut qualifier de "militaire". Pour une présentation introductive, on retiendra les caractéristiques suivantes.

a) Un processus linéaire de mise en œuvre des systèmes d'Information: Des étapes très précises sont suivies et caractérisent l’approche classique. Le processus linéaire qui en découle est le suivant:

* L’étude de l’existant: Qui consiste à relever minutieusement la structuration existante du système de traitement de l’information avant que ses traitements ne soient automatisés.

* La collecte de l’information, très minutieuse: Elle se doit de localiser chaque flux à chaque poste de travail.

Différents catalogues voient alors le jour et présentent de manière ordonnée le résultat de ce travail de type photographique.

b) Une formalisation poussée des résultats de l'étape précédente:

* Une présentation du système existant et son analyse critique.

* Des propositions de solutions et de programmes.

* Un cahier des charges prenant la forme d’un document qui a deux objectifs. Il détaille la demande de réalisation concrète à partir de l’analyse de l’existant, et il constitue le cadre juridique de réalisation. Le cahier des charges lie le demandeur et l’entreprise qui va implanter le système automatisé dans son organisation.

c) Un processus basé sur des besoins supposés connus et stables: Partant de l’étude minutieuse de l’existant l’approche classique permet de dégager les besoins. C'est ainsi qu'un postulat important domine cette méthode.

Les besoins peuvent être déterminés et sont considérés, pour un métier donné, être stables. Or ce relevé précis des besoins est adéquat à un temps t1, au début de l'étude, perd de sa valeur rapidement. Ainsi à un temps t2 les outils d’automatisation des traitements résolvent des besoins mais crée aussi de nouveaux besoins.

L’approche classique, très précise dans ces résultats est confrontée à un problème d'évolutivité. Celle des logiciels, mais encore celle des procédures de gestion.

2°) La crise de la méthode classique

Les méthodes que l'on peut qualifier d'alternatives, apparaissent au départ sans être vraiment et totalement en rupture d’avec l’approche dite classique. Elles posent cependant des principes et des propositions de modèles novateurs et intéressants. L’une de ces approches va jusqu'à avancer une affirmation assez osée mais qui n’est pas dénuée de fondements. L’affirmation, dans ses grandes lignes se pose en questionnement critique. En déclarant que les besoins sont difficilement connus et ne peuvent l'être, du fait même de la complexité des traitements. Et surtout de l’évolution "naturelle" des systèmes d’informations, qui ne peuvent être saisi en une vue statique. Parce que les organisations sont en perpétuelle transformation, les méthodes sont nécessairement limitées dans leur efficacité. Jusqu'au point d'affirmer que les besoins ne peuvent être recensés parce que trop mouvants. Toute prétention, à fixer comme sur un négatif photo, l'existant et à dégager les besoins, est en conséquence vouée à l’échec.

Aussi c'est une pratique de découverte, au fur et à mesure de la réalisation des programmes, qui est proposée.

Le bricolage, en lieu et place des méthodes, est même avancé comme étant la plus efficace des méthodes.

Or cette affirmation, ne manque pas de bon sens comme nous pourrons le constater plus loin. L’on parle alors de méthodes ou de techniques de prototypage et on évoque le développement rapide d’application (R.A.D), les approches objets, et les systèmes d’information à base de composants(⁰). Des langages spécialisés permettant le développement de produits non finis, mais qui fonctionnent et que l’on peut adapter au fur et à mesure des besoins.

Cependant et malgré la réalité des critiques avancées, la méthode classique conserve de réels avantages. Elle reste pertinente, au moins s'agissant de sa capacité à représenter les flux et les traitements dans une organisation. Aussi ne jetterons-nous pas à la poubelle trop rapidement les préceptes des modèles classiques.

Cette seconde partie du cours sera donc consacrée aux méthodes concrètes de mise en œuvre en étudiant la méthode dominante "classique" pour mieux cerner et étudier les prolongements qualifiés "d'alternatifs" dont on essaiera de comprendre les points forts et novateurs.

0L'idée est la suivante, les métiers, y compris touchant à la décision, peuvent être partiellement réduits à des algorithmes plus ou moins complexes. L'on peut utiliser des composants métiers. Ces derniers peuvent être "manipulés", par des personnels qui n'ont pas la connaissance du métier, à condition qu'une machine soit capable de les assister dans la maîtrise ou l’utilisation de cette connaissance.

Nous développerons ce point plus loin dans le cadre de cet enseignement.

Chapitre 1: La technique classique de mise en œuvre des SI

Dominante dans la littérature théorique et chez les praticiens, jusque dans les années 1980-90, l’approche classique utilise les concepts étudiés dans la première partie de ce cours. L’approche est donc systémique. Si d'autres approches se présentent comme plus souple et concurrentes, elles empruntent en fait de nombreuses techniques à l’approche classique. Il convient donc de bien situer le fait, que la méthode classique existe, a existé, et a été l'objet d'améliorations, fusse au prix d'une critique (les critiques qui sont du point de vue des sciences des actes constructifs et n'ont pas le sens que le vocable au sens courant sous-entend).

Section 1 L’étude préalable

L’étude préalable constitue la première phase et la plus importante de l’approche classique. Au terme de cette étude, un diagnostic est réalisé et une évaluation est mise en œuvre. L’avant projet qui en est issu constitue alors le cadre de conception de la solution informatisée. Pour aboutir à un tel résultat une succession d'étapes est proposée. C'est le respect de cette organisation précise des travaux à réaliser qui constitue sans doute l'une des qualités de l'approche classique. Dès cette décomposition, l'on se trouve être plongé dans la logique intrinsèque de l'approche classique.

Sous section 1 La décomposition en étapes

C’est la réalisation de la conduite linéaire de l’approche classique qui est évoquée à ce stade de travail et qu'un schéma peut traduire assez opportunément comme celui de la figure 32.

§1 Les différentes étapes

1°) L’étude préalable stricto sensu

Dans le cours de cette étape est étudié l’opportunité à recourir à une solution automatisée de traitement de l’information. Il s’agit de mesurer les atouts d’une telle automatisation. La praticabilité constitue une seconde préoccupation, tentant de répondre à la question: La solution automatisée est-elle réalisable au point de vue technique mais aussi au point de vu organisationnel? Soit à savoir si les techniques existent et si l’organisation supportera les changements induits.

2°) L’analyse fonctionnelle ou conception du projet

On analyse l’insertion du projet dans l’organisation en étudiant la logique de la solution ou sa cohérence. Il s’agit d’isoler les travaux à automatiser et les postes de travail concernés.

3°) L’analyse organique ou développement du projet

Cette étape est capitale. Il est question maintenant d’organiser les informations. Les fichiers sont liés, structurés, à l'aide de modèle du type "entité association". Ce résultat est la conséquence de l’étude affinée des données.

Les traitements dégagés par l’étude préalable sont organisés en tenant compte de leur enchaînement. On tente de déterminer la suite logique des étapes d’un travail (soit les entrées, les traitements qui les affectent, et les sorties...).

4°) L’étape de programmation

Les étapes d’analyse et les solutions dégagées sont, après contrôle, programmées pour aboutir à la phase finale et utilisable. Cette phase est supposée résoudre tous les besoins exprimés. En principe, à ce stade aucune surprise n’est possible. Il est en effet dans la logique de l’approche classique de considérer que tous les problèmes ont été localisés dans le cours des étapes précédentes.

§2 Intérêts et lacunes de la décomposition en étapes 1°) La précision dans l’étude de l’existant

L’approche classique se révèle d’une grande précision dans l’évaluation des besoins tels qu’ils ressortent du système d’information existant. L’étude détaillée des flux, la description minutieuse des travaux dans chaque station de l’organisation permet une vue "photographique" très détaillée. Au terme d’une telle approche l’on connaît très précisément les données, les documents circulants, les traitements. La solution peut alors être mise

en œuvre avec un rendement de gestion de l’information très élevé. En particulier les bases de données, finement organisées, constituent l’un des résultats les plus convaincants de cette approche.

2°) Le caractère figé ou statique de l’analyse classique.

Cependant, un premier risque apparaît consistant dans la reproduction des lacunes du système d’information existant. A trop se tenir au plus près des flux existants et des traitements réalisés manuellement par le passé, l'on risque de prendre pour argent comptant ce qui était des faiblesses, voir des erreurs de gestion du système.

Une phase d’analyse critique est donc nécessaire.

Plus risqué encore est le caractère figé des solutions obtenues à l’aide de l’approche classique. Ces dernières résolvent un problème à l’aide d’une solution organisant chaque poste de travail (ou stations) et chaque flux. On note qu'alors toute évolution du système se révèle très difficile à mettre en œuvre. L’évolution des outils logiciels et des phénomènes tels le développement de la micro-informatique exigent des marges de manœuvre plus souples.

Il faudra donc intégrer les correctifs possibles. Mais ces derniers se révèlent contradictoires d’avec la logique même de l’approche classique qui ne tolère pas les retours en arrière (ni même le feed-back, dont on connaît maintenant l'intérêt). L’on doit recourir à des approches concurrentes comme celle du prototypage ou de l’informatique dite de l’utilisateur final.

Malgré ces faiblesses l’approche classique doit être étudiée parce qu’elle se trouve être, dans le cadre de systèmes d’informations qui restent, à ce jour, très structurés voire centralisés, la meilleure approche descriptive des systèmes. La précision de type "quasi-militaire" des systèmes mis en œuvre à l’aide de l’approche classique présente de véritables avantages.

§3 La tendance à l’intégration

Il s’agit là d'une importante caractéristique qui illustre la combinaison d'atouts et de faiblesse de l’approche classique. Les stations ou services concourant aux objectifs de l’entreprise, dépendent fortement d’un système centralisé. L’on évoque alors la notion de structure maître / esclave. Où les utilisateurs doivent travailler sur des terminaux strictement configurés. Si les besoins exigent l’accès à des données existantes mais pour lesquelles les postes clients n’ont pas été "préparés", l'utilisateur n'a alors aucune possibilité d'accès. Les postes sont comme l'expression l'évoque des postes de travail esclaves ou client, selon les terminologies.

1°) La notion d’intégration des systèmes d'information

Les organisations ayant recouru, de plus en plus, à l’automatisation de leur système d’information. Elles le font avec une conséquence importante consistant à centraliser - physiquement - leurs conteneurs de données.

L’accès aux données communes, regroupées dans des bases de données interconnectées, par plusieurs utilisateurs en même temps définit la notion d’intégration. On y remarque une rigueur des procédures d’accès et des contrôles très poussés.

Nous pouvons sans grand risque d'erreur considérer que la notion d’intégration est synonyme de centralisation.

C’est cette dernière qui va être contestée, pour devenir relative avec l’apparition des grands réseaux, parmi lesquels l’Internet. A l’inverse des réseaux classiques - limités à une organisation particulière -, l’Internet permet, parce qu’il n’est pas centralisé (personne n’en est propriétaire) un accès à des données, variées parfois contradictoires mais ayant l’intérêt de la variété. Hors un tel type de réseau ne rentre pas dans le cadre des modélisations classiques des systèmes d’information.

2°) L’intégration et l’approche classique

L’étude du partage de "ressources" informationnelles, par le biais de flux d’informations se révèle tout à fait cohérente d’avec l’approche classique. Mais, un problème apparaît, les stations, qui doivent accéder aux données centralisées dans les conteneurs centraux que sont les bases de données, ont leurs propres besoins.

Ces derniers n’ont pas nécessairement été prévus, souvent pour une raison simple, ils n’existaient pas lors de la mise en place du Système d'information.

On doit alors relever que l’approche classique, initialement figée et prônant une intégration poussée, tentera divers correctifs. Y compris en empruntant certains techniques aux approches alternatives. Ce, au moins pour prendre en compte l’évolution rapide des outils informatiques, et des possibilités que ces outils font naître. Les stations "slaves" ou esclave ayant une certaine tendance à redevenir maître de leur travail. L'approche classique devra prendre en compte ce fait nouveau.

Sous section 2 Les objectifs de l’étude préalable

§1 Formuler le problème à résoudre A) La formulation des besoins

C’est partant d’un besoin que les applications informatiques sont réalisées. Ce besoin peut cependant être formulé de manière très différente. Il peut consister dans la demande précise d’un utilisateur ou résulter du constat de la nécessité d'accélérer les travaux répétitifs etc. Quelle que soit la cause initiale du recours à une solution automatisé, le besoin est toujours formulé. Ce faisant, il est plus ou moins bien explicité. Il peut être soit incorrectement formulé ou exprimé de manière trop générale ou - à l'inverse - de manière trop restrictive. Cette diversité des lacunes d'expressions des besoins motive la mise en place de technique de recueil des désirata.

Chose que propose l'approche classique.

Exemple: Le responsable d’un service de gestion évoque le besoin d’améliorer à l’aide d’un traitement automatisé son suivi de relance clients. Après examen l’étude peut révéler que plus que le problème des relances sur impayés, c’est l’ensemble de la gestion de la facturation qui est inadéquate c’est à dire non adapté aux besoins présents de l’organisation.

B) Poser correctement le problème à résoudre

Les besoins plus ou moins bien formulé, exigent l'intervention d'un agent que l'on qualifiera pour les besoins de la cause d'interprète. En son travail il opérera une traduction des besoins formulés. La traduction des besoins aboutira à une formalisation appelée à rendre accessible à tous les responsables la description la plus précise que possible des besoins de l'organisation. Ceux-ci se répartissent alors en besoins effectivement exprimés ou déduits au terme d'un audit. Rappelons qu'une organisation est constituée d'agents humains qui ne manifesteront pas les mêmes points de vue relativement à l'intérêt de l'automatisation de leur travail quotidien.

§2 Définir un avant-projet de solution

Une fois dégagée la nature exacte du problème à résoudre et des besoins à satisfaire l’étape suivante a pour but de dégager une orientation générale de solution. Il s'agit au début d'une ébauche, qui devra par la suite être reprise de manière détaillée lors de la conception du projet. Deux points important doivent à ce stage retenir l’attention. Ces points sont deux préalables à la réalisation du projet d’automatisation.

A) La praticabilité de la solution

On se pose la question de savoir s'il est possible d’utiliser des outils automatisés pour résoudre le problème posé? L’on emploie parfois le terme d’étude de faisabilité pour évoquer ce questionnement essentiel. Cette étude consiste à recenser les possibilités techniques existantes. A ce stade l’on traite le problème des contraintes matérielles et humaines à l’emploi d’outils automatisé. En particulier l’on étudie l’impact de l’automatisation sur l’organisation. La praticabilité met à jour deux "variantes" importantes de cette notion.

1°) La praticabilité technique

Elle nécessite l’intervention de techniciens extérieurs qui déterminent si le matériel existant sur le marché permet l’automatisation des traitements envisagés. Concrètement il s’agit d’examiner si les techniques existent.

2°) La praticabilité organisationnelle

Combiné au problème précédent le problème de la praticabilité organisationnelle doit prendre en compte plusieurs sous problèmes. Il est alors question de recenser tout ce qui peut relever des aspects organisationnels. L’introduction de nouveaux outils modifie les travaux des agents, leur manière de travailler mais aussi les compétences. Pour ces raisons, c'est un point délicat, source parfois de conflits qu'il faudra résoudre.

B) L’opportunité de l’automatisation

La praticabilité d’une solution est une chose son opportunité économique en est une autre. L'analyste ici doit s’attacher à apprécier en terme de coûts l’intérêt d’une solution automatisée. Le calcul est en théorie simple et consiste à comparer le rapport coûts/avantages des solutions proposées. En pratique cette évaluation est délicate. La mesure des avantages d’un système automatisé dans un domaine aussi incertain que celui des technologies de l'automation ne permet pas l’appréciation des avantages futurs souvent inconnus et imprévisibles. Le calcul prévisionnel devrait pouvoir intégrer des qualités non chiffrables, d'autant qu'elles ne se manifesteront que plus tard.

Sous section 3 Les techniques de l’étude préalable

En premier lieu, les techniques classiques de l’étude préalable organisent les étapes de l'étude. Ainsi les équipes de travail sont mises en place, la planification de l’étude dans le temps est fixée, les responsabilités de chaque agent sont déterminées. Il en est de même concernant les tâches à réaliser en commençant par l’étude de l’existant.

§1 L’organisation de l’étude préalable

L’organisation de l’étude préalable donne une assez bonne image du caractère linéaire et formalisé de l’approche classique. Avant que ne soit étudiée la moindre donnée, le plus petit traitement du système à automatiser la première étape consiste à mettre en place l’équipe de travail, avec ses responsables et un programme de travail très précis.

Apparaît ici l’importance révélée par les méthodes systémiques nées autour des grands projets de gestion des structures complexes durant la seconde guerre mondiale. On situe à cette époque le développement des théories systémiques.

C’est dire qu’un projet qui touche à l’organisation, à ses règles et habitudes de gestion, implique un rôle des agents de l’organisation fixé très précisément. Parce qu'il s'agit de gérer l'information coproduite par les utilisateurs, l'implication des agents est essentielle. Ces derniers pouvant bloquer tout ou partie de la dynamique mise en place. Cela complique la mécanique hiérarchique d'une organisation; et rappelle qu'on ne peut pas travailler sur l'information comme sur une quelconque ressource. Aussi avant toute chose est mise en place une équipe, c'est la première étape de l’étude préalable. En notant que l'importance d'un groupe de pilotage est inversement proportionnelle à la taille de l’organisation concernée.

A) La responsabilité de l’étude

La taille de l’organisation est un critère de la détermination du nombre de participants à l’équipe responsable du projet. Mais aussi, dans le cadre de petites unités de travail, la tendance à la participation du maximum d’agents sera très prononcée. Entre autres éléments encourageant de telles pratiques, les techniques de management du personnel de type participatives. Cette participation se révélant, souvent symbolique lorsqu'elle inclut le maximum d’agents y compris les agents de saisie. En pratique une certaine démagogie sociale ne manque pas de régner dans la constitution de l’équipe responsable lorsqu’on interpelle les utilisateurs, souvent conviés à un rôle de simples figurants.

En fait sous l’appellation de groupe de pilotage et d’un groupe d’étude sont regroupés un ou plusieurs représentants de la direction générale, les directeurs de fonctions, et un panel d’utilisateurs à différents niveaux hiérarchiques. La participation active des utilisateurs sera considérée comme un plus.

1°) Le groupe de pilotage: Comme son nom l’indique, il dirige l’étude. C’est lui qui définit les grandes orientations et qui tranchera entre les différentes propositions.

2°) Le groupe d’étude: Il a un rôle plus technique d’analyse des problèmes et de proposition de solutions. C’est dans ce groupe que l’on trouve les informaticiens et les utilisateurs qui maîtrisent les travaux non automatisés soumis à l’étude préalable.

3°) Le conseil extérieur (éventuel): Extérieur à l’organisation il intervient dans la plupart des cas en sa qualité de spécialiste. Même si l’organisation possède un service informatique. C’est souvent le conseil extérieur qui sera

le véritable dirigeant du groupe de pilotage qui de plus aura le "rôle" difficile de réguler les conflits internes à l’entreprise. Ces conflits qui sont inévitablement engendrés par l’automatisation.

B) La planification de l’étude préalable

L’étude préalable se présente donc comme une analyse globale et très générale. En ce sens le travail consiste à dégrossir les solutions. C'est un affinement ultérieur qui validera les résultats obtenus. On distingue deux grandes étapes, planifiées dans le temps. La première consistant en l’analyse de l’existant. Cette phase de travail consiste à prendre connaissance du domaine d’application concerné par l’automatisation. Un moment important sera celui du diagnostic - où sont évalués les forces et les faiblesses du système d’information existant.

Au terme de cette analyse une ébauche de solution peut être construite. C’est cette ébauche qui entame l’étude de l’opportunité et de la praticabilité du projet. Divers graphiques donnent un aperçu des étapes (classiques) de l’analyse préalable comme celui de la figure 32.

§3 L’analyse de l’existant synonyme de documentation

C’est la clé de voûte de l’approche classique, et le travail le plus délicat de l’étude préalable. Encore, doit-on admettre que l’organisation qui décide l’automatisation de certains traitements connaît mal (ce qui est très souvent le cas) son système d'information existant. Ce dernier est souvent le fruit d’une longue expérience non formalisée. Il n’existe que très rarement un catalogue présentant les flux existants et les liaisons entre les tâches de travail de chaque service de l’organisation.

Parce que le Système d'information d'une organisation est le résultat d’une histoire et d’une pratique souvent empirique (basée sur l’expérience). Elle doit donc être formulée en passant par un recueil affiné et par la réalisation de documents, très précis, représentant le système. En ce sens la notion d’étude de l’existant est synonyme de documentation. Cette dernière emploie des graphiques susceptibles de représenter le système objet de l’étude. C’est alors un travail en deux temps qui est mis en œuvre. Le recueil des informations constitue ainsi une première phase. La présentation et l’analyse des données recueillies déclenchent une seconde phase de travail. Un arsenal de techniques graphiques de représentations peut alors être utilisé, ceux étudiés en première partie de ce cours, entre autres.

Recherche des moyens (praticabilité)

Propositions de Solutions Organisation du

groupe d'étude Etude

de l'existant Diagnostic

Définition des objectifs (opportunité)

Analyse de l'existant Conception

Fig. 32

A) Le recueil des informations

Il est nécessaire de cataloguer les informations considérées utiles, en mettant en œuvre des techniques adéquates de recueil. Ces techniques sont souvent inspirées des modèles Merise, relationnels, etc. et sont combinés avec les "actigrammes", ou encore avec les modèles dynamiques de processus. Soit autant de techniques graphiques appartenant à la modélisation "Entité / Association". Ce si l'on a choisi de retenir comme méthode de modélisation, celle dominante en France: La méthode Merise.

1°) Quelles informations recueillir

D’une manière générale il s'agit de collecter et d’identifier les traitements effectués et les informations / données utilisées. Ces informations doivent en outre appartenir au domaine à automatiser. S’agissant d’éviter l’éparpillement, il est en effet indispensable de délimiter le domaine qui sera celui de l’introduction des outils automatisés. Ainsi apparaissent des domaines et des sous domaines à étudier. Tous ne subiront pas les même degrés d'automatisation. Aussi l'organisation doit déterminer des priorités, des exclusions aussi, lorsqu'elle estimera que certains services et certaines travaux ne gagnent pas à être automatisés. De plus, deux catégories d’informations devront être distinguées et constituer des informations objectivement quantifiables. En effet l’appréciation ne sera valable que si une limite est posée aux incursions subjectives. Soit que l’on dissociera les faits d’une part et les opinions de l’autre. Les opinions seront prises en compte de manière différente dans le cours de l’étude.

2°) Recueil de faits et recueil d’opinions

Les documents produits par le travail des agents dans les différentes stations, les matériels utilisés, les fichiers manuels ou informatisés sont des éléments de faits qui peuvent être catalogués. Les volumes et la fréquence d’utilisation des documents sont aussi des faits qui doivent être précisément relevés. A ces éléments de faits, objectifs, seront joints le recueil d’opinions. Ces opinions, éléments subjectifs, sont d’un grand intérêt s’agissant de localiser les dysfonctionnements du système. Lors de la phase de diagnostic qui s'inscrit dans l’étude préalable et par recoupement d’avec les documents recueillis, ces opinions permettront l’intégration de l’appréciation du "ce qui ne va pas ou qui pourrait être amélioré".

3°) Les techniques de recueil

Les techniques employées lors de la phase de "recueil de l’information" permettent de maximiser les résultats, si elles sont adéquates. Toute une panoplie de techniques est mise en œuvre existent. Ces outils sont eux même le résultat d’études très affinées, issues des différents travaux universitaires et consistant à mettre à la disposition des analystes les outils de modélisation adéquats. Ainsi:

a) Les organigrammes et les fiches de fonctions des services: Très utiles lorsqu’elles existent dans les systèmes y compris non automatisés. Elles sont mises en œuvre à l’occasion du recueil de l’information (Fig. 33).

b) Les fiches d’observation et d’entretien: Outils importants, leur forme est calquée sur les documents de recueil d’informations employés par les enquêteurs psychosociologues et autres spécialités du même domaine. Ces fiches permettront entre autres une confrontation avec les organigrammes et les fiches de fonctions des services. Le recoupement d’information permet de mettre à jour certains dysfonctionnements ou certains besoins non formulés.

c) Les documents d’auto-analyse: Ces derniers consistent en des questionnaires qui sont remis aux agents et remplis par eux de préférence de manière non dirigée. Les résultats sont souvent intéressant en cela qu’ils font apparaître la distorsion existante entre la fonction d’un agent et l’idée qu’il se fait de son travail. L’ergonomie des écrans de saisie sera étudiée, en partie, à l’aide de ces questionnaires.

Fig. 33

Notes / particularité notable: Fichier, au service Vente, et impression 2 fois par ans.

N° Description Type (caractéristique) Acquis le Durée de vie

M1 Machine à écrire Reuter 1950 25 ans

M2 Imprimante Espson 1985 5 ans

01En registrement Ba c ES 2 ans 6000 02 Gestion Portefeuille DUT Gestion 4 10000 N° Poste Occupé Cat égorie Ancienneté Coût:

Personnel:

Fichiers / Supports:

N° Désignation Support Nombre Fiches Volume

F05 Cl ients Fiches carton 5 000 2000c/ Fiche

F06 Catalogue produits Fiches carton 10000 5000c/ Fiche

Matériel:

Fiche d'analyse de station Document : PrCpt0001

Identification: Saisie des commandes (Service Commande)

Station: Commandes (notée SC, dans le schémas de flux et station Service de rattachement: Vente

Responsable: Mm Vente 05 65 00 25 69 Localisation: Siége central

Mission générale: Enregistrement des commandes, réception clients, vérification solde

d) L’analyse des documents représentants les flux: La compilation de tous les documents d’entrée, de sortie, et de supports des traitements, est analysée. C’est à partir de l’ensemble de ces documents que l’on peut reconstituer les flux, leur sens, les volumes d’informations. C'est aussi à ce stade que l'on isole les redondances éventuelles de ces informations. Un graphe de circulation est réalisé à partir de ces documents.

e) L’analyse de la documentation informatique existante: Dans le cas où certains traitements sont automatisés, le recours à la documentation informatique existante est précieux. Entre autres les dossiers d’analyse et de programmation sont utiles à la compréhension de la cohérence des traitements.

B) La présentation des observations

Au terme du recueil et à l'aide des outils évoqués, la mise en forme des observations permet de vérifier que l’on a recueilli les informations nécessaires. Et que l'on a constitué la vue "photographique" la plus fidèle que possible du système d'information étudié. De plus ces documents permettront de communiquer au groupe de pilotage les matériaux nécessaires à son travail. Il s’agira, bien entendu, des schémas de flux et stations, des modèles tel le modèle entité/ association. C'est derniers ont été organisés et compilés afin de constituer une vue

"grand angle" du système d'information; autant s'agissant des données que des traitements qui se trouvent réalisés au sein des services du domaine étudié.

La représentation des traitements prend la forme de schéma de validation des documents résultants. Ces documents de présentations des observations doivent décrire trois aspects fondamentaux du système étudié:

L’organisation du domaine à automatiser, les informations utilisées, les traitements effectués.

1°) L’organisation du domaine

Il s’agit de délimiter le sous-ensemble des services de l'entreprise qui est l’objet de l’étude préalable. Délimiter le domaine correspond donc à indiquer le service ou la fonction dont les travaux vont être automatisés. La représentation réalisée prend la forme d’un organigramme de structure. Ce dernier peut intégrer une arborescence hiérarchique. De même un circuit d’information peut être appelé à représenter les flux et stations concernés par l’automatisation. La combinaison de ses différentes représentations doit permettre de délimiter au plus juste le domaine retenu. Pour chaque poste de travail une fiche de station représente les travaux réalisés et les moyens utilisés.

2°) Les flux d'informations

Localisées précisément ces derniers alimentent un répertoire auquel est joint un exemplaire de chaque document qui constitue le support des flux. En distinguant les informations internes à la station, reçues par elle ou émises par elle. Un répertoire des lots d’informations et des fichiers permettra l’analyse du contenu sous la forme des rubriques des fichiers.

3°) Les traitements

L’automatisation a pour objectif de traiter l’information, la présentation des traitements est donc des plus importante Ainsi les schémas des flux de données, les tables de décision, les actigrammes etc. constitue un stock de techniques pratiques et efficaces. Un schéma de procédure (Fig. 34) est aussi un outil adapté. Il représente la circulation entre les postes de travail et indique les traitements et les conditions du déclenchement des travaux.

§4 Le diagnostic de l’existant

A partir de l’ensemble des documents de représentation des flux d’informations et des traitements et après qu'une analyse des flux représentés ait été réalisée, il est possible d’établir un diagnostic. L'on recense, concrètement, les problèmes et on analyse les causes. C’est cette localisation des points faibles du système qui permet un diagnostic. C'est ce diagnostic qui permettra de tenter une optimisation du système en automatisant certaines tâches.

A) Le recensement des problèmes

L’examen des documents issus de l’analyse de l’existant permet de localiser les problèmes. Ces derniers localisés à un niveau autre que celui de la simple formulation plus ou moins précise qui a été à l’origine de l’étude préalable. Les documents analysés par recoupement et en particulier les critiques issues du recueil des opinions et confrontés au recueil des faits permettent de dégager deux catégories de critiques habituellement rencontrées à ce stade de l’étude. Soit le manque d'efficience, et le manque d’efficacité, Qui sont deux types de dysfonctionnements courants des systèmes d'information.

1°) Le manque d’efficience / faiblesse des performances

Dans ce cas l’on remarque que Le système à des performances insuffisantes par rapport aux objectifs qui lui étaient assignés. Les causes peuvent être de plusieurs ordres. Elles couvrent des domaines allant de l’insuffisance technique, à l’emploi de procédures inadaptées et qui peuvent être améliorer.

a) Les insuffisances techniques: Ce sont elles qui sont le plus souvent relevées par les utilisateurs eux même.

Ces derniers se trouvant au plus prés des travaux quotidiens et dont les plus à même de localiser les problèmes techniques.

BL Procédure: Facturation / Société Dupond Fi che: 0125

Fig. 34 1 Création du Bon

de commande

2 Préparation de la Commande

3 Etablissement de la facture 4 Transmission

5 Contrôle et archivage

PostesPos te 1Pos te 2Pos te 3

TâchesCom mercialM agasinierCom pta.

BC

Cde BC

BL

Fact. 1 Fact. 2

Fact.

1,2 n Client

Client Comptabilité

Livres

* Le débit trop faible et les temps de réponse trop élevés: C’est là un constat fait par les utilisateurs. Ces derniers habitués dans leur travail quotidien à apprécier les fluctuations de la charge de travail, savent situer les moments et les circonstances où apparaissent des lenteurs, des engorgements.

Exemple: Au magasin à intervalle régulier est constatée une lenteur dans la capacité du service à contacter le fournisseur et à mettre à disposition des ateliers demandeurs les commandes de pièces détachées. La procédure doit alors être revue, en suivant le diagramme de procédure, en utilisant les répertoires et les analyses issues de la phase d’étude de l’existant.

* La sécurité des données: Parmi les dysfonctionnements techniques, la sécurité défaillante des traitements est à prendre en compte. Ainsi l’analyse des documents résultants peut révéler des lacunes importantes (erreurs répétées dans les calculs de soldes clients par exemple) nécessitant des corrections manuelles longues et générant de pertes de temps donc des surcoûts.

b) Les procédures mal adaptées: Les utilisateurs et responsables de service évoquent alors des procédures mal adaptées. Quelquefois les documents utilisés sont nombreux, parfois redondants: L'information existe, en ce cas, sur plusieurs documents soit ce que l'on appelle des doublons. Ces incohérences informationnelles ne sont pas rares dans les services où certaines habitudes bureaucratiques se sont peu à peu mises en place.

c) Les coûts élevés: La connaissance des coûts du système existant au cours du recueil permet, cette appréciation. En effet, sont connus les volumes d’informations traitées, les outils employés les agents et leur volume de travail à chaque poste. A partir de cette évaluation au moment de l’étude il est possible d’élaborer un prévisionnel ou une extrapolation tenant compte de l’évolution prévisible de la taille de l’organisation. A ce point de l’analyse l’on peut réaliser l’étude chiffrée d’une solution informatisée.

2°) Le manque d’efficacité

L’efficacité décrit un système où les performances sont acceptables pour les objectifs qui étaient fixés. Par contre les résultats peuvent ne plus être adaptés aux besoins actuels. Le système d’information en ce cas est caractérisé par la qualité relative des résultats, ce n’est que relativement aux nouveaux besoins que le système n’est plus adapté. Le cas se produit lorsque les méthodes de gestion ont évolué, les solutions ne sont alors plus en phase avec les besoins.

B) L’analyse des problèmes

Plus qu'un simple constat, le diagnostic doit situer précisément les causes de dysfonctionnements. Pour ce faire l’analyse doit permettre de localiser les points forts et les points faibles du système existant.

1°) L’analyse des causes

Le simple constat consisterait en une énumération des problèmes rencontrés. Il faut dans cette phase de travail répondre à la question: Pourquoi existe tel ou tel dysfonctionnement? Parmi les causes multiples certaines sont matérielles. D’autres causes relèvent de problèmes liés à l’organisation du travail.

a) Les causes matérielles: Ces dernières sont facilement localisables. Les insuffisances peuvent être des insuffisances de capacité de stockage des informations. Par exemple le partage d'informations sur fiches cartonnées constitue un exemple classique de certains points faibles d’un système.

Exemple:

Un fichier client qui est nécessaire au service commercial, mais aussi au magasin, et au service comptable existe en plusieurs exemplaires avec des risques important de contradictions informationnelles induites par la multiplicité des fichiers. Certains d’entre eux, alors qu’ils ont le même contenu théorique ne sont pas à jour provoquant des erreurs de traitements. Le commercial a, par exemple, pris note du changement d’adresse d’un client et a actualisé son fichier, alors que le service comptable ne dispose pas de cette information.

Dans le cas de systèmes déjà informatisés, c'est la capacité des supports magnétiques de stockage qui peut plus faire face à une augmentation de volume des informations mémorisées. Des lenteurs d’interrogations apparaissent et entraînent des retards dans de traitements.

b) Les causes logicielles des systèmes automatisés: Les logiciels existants se trouvent dépassés, ces derniers ayant été choisis et implantés à une époque où les volumes de données et les traitements demandés étaient, en

quantité et en qualité, moins importants. La taille croissante de l’organisation (et de ses besoins) n’est alors plus gérable avec les logiciels initiaux. Souvent des retouches aux logiciels ont été réalisées, mais le matériel ne peut pas suivre. La combinaison de cette obsolescence technique (logiciels et matériels) nécessite l'évaluation des besoins nouveaux et des outils capables d’y faire face.

c) Les causes tenant au personnel: La transformation des procédures de travail peut dans certains cas ne pas être acceptée par les personnels. Ce sera le cas aussi des personnels informaticiens dépassés par l’évolution rapide des logiciels et des systèmes. Jusqu'à faire apparaître une certaine "incompétence" lorsqu’une formation continue adéquate n’a pas été mise en œuvre.

d) Les causes tenant à l’organisation et aux méthodes: En ce cas, les solutions peuvent être inefficaces. Elles fonctionnent mais ne sont plus adaptées aux besoins actuels. C’est l’organisation et les méthodes de management qui peuvent être la cause de dysfonctionnements que l’étude préalable dégage.

* Cas d’une centralisation trop lourde: Le contrôle, par exemple, par une seule personne de tous les achats de l’entreprise peut dans certains cas constituer un bon choix de gestion. La personne est au courant de tous les achats, elle connaît les fournisseurs, elle est seule à négocier les prix etc. Elle maîtrise l'histoire de la relation aux fournisseurs.

A partir d’une certaine taille de l’organisation ce qui constituait un atout devient une faiblesse. Le responsable débordé de travail est difficile à joindre, il n’est plus disponible pour suivre les contacts. Les conséquences peuvent atteindre la rupture de stocks. D'autant que l'organisation est passé, par exemple, à une politique d'approvisionnement "juste à temps".

* Cas d’une spécialisation trop rigide: Tout étant relatif la spécialisation des tâches a certainement été la source de rendements plus élevés. La contre partie a été parfois l'apparition d'un manque de motivation des personnels s'ils pratiquent des travaux répétitifs peu motivants. Ce qui à été à une époque une règle de management efficace devient une faiblesse du système.

* Les conflits de compétence: Certaines manières d’organiser la responsabilité des agents peuvent être source d’inadéquation importante. Ainsi le cas du contrôle des paiements des clients; qui peut être réalisé par le commercial, mais aussi le service comptable. Si les rôles de chacun n’ont pas été strictement définis le contrôle n’est plus effectué. Le commercial pourra estimer que le service comptable a effectué ce travail, alors que le service comptable pense la même chose du responsable commercial.

* Des procédures non adaptées: Les procédures inadaptées sont souvent constatées dans les grosses organisations, et peut être plus encore dans les administrations publiques. La circulation des documents peut alors relever d’un véritable parcours du combattant avec arrêt et attente dans plusieurs services. Le traitement des réclamations des clients peut faire l’objet de flux trop nombreux entre de trop nombreuses stations.

L’analyse de l’existant peut localiser ces redondances fonctionnelles dont certaines pourront être révisées en situant avec précision quel service doit être interpellé.

Dans tous ces cas de figure, dont la liste n’est pas exhaustive, la localisation précise des causes doit être réalisée. Soit que l’on se pose la question: Où et pourquoi? Au besoin la question sera posée en boucle jusqu’à obtenir une réponse satisfaisante.

2°) Détermination des points forts et des points faibles du système

Le diagnostic de l’existant doit être une analyse critique. En ce sens il doit dégager les points faibles du système.

Tous les documents nécessaires ayant été collecté. Les points faibles révélés doivent recevoir une solution praticable.

Ce faisant, il convient d’éviter un risque important. En recherchant une automatisation à tout prix et animé d’un élan de recherche des lacunes du système, la tendance à oublier les points forts se trouve être une réalité. Or si l’organisation a fonctionné jusqu’à ce jour c’est qu’elle possède des points forts (des techniques efficaces et adéquates). Le rêve du tout informatique peut contribuer à oublier que l’organisation réalise des traitements qui ne gagneront pas à être automatisés. Tout dépend de ce point de vue des mesures qui auront pu être faite de l’efficacité d’une tâche. L’instrument de mesure est censé rester l’efficacité gestionnaire et la satisfaction des objectifs de l'organisation.

Section 2: La réalisation de l’avant projet

Au terme de l’étude préalable l’organisation dispose d’une panoplie de résultats. Elle connaît mieux son système d’information. De plus elle en a isolé les points faibles et les points forts. Elle connaît aussi ses faiblesses organisationnelles. L'organisation a une meilleure connaissance des procédures de gestion qui organisent le travail de ses services. Les flux d’information sont clairement localisés. Certes à ce stade de l'étude préalable, aucun résultat opérationnel ou utilisable n’est atteint. Mais tous les ingrédients nécessaires à la réalisation sont réunis. Le groupe de pilotage et le ou les groupes d’étude peuvent aborder, maintenant, la phase de réalisation en examinant les différentes solutions. Cet examen implique la prise en comptes de l’environnement de contraintes de l’organisation. En tenant compte de sa stratégie globale de gestion, l’organisation peut envisager les différentes solutions opérationnelles.

§1 L’élaboration des solutions

C’est en déterminant un cadre de solution que l’organisation met en œuvre l’avant projet.

A) Le cadre de solution

Il va se définir par la prise en compte de contraintes d’objectifs et de niveaux de solutions.

1°) Les objectifs

C’est la critique de l’existant qui permet d’entrevoir les objectifs qui devront être atteints. On doit noter alors que l'ampleur et la complexité des objectifs à atteindre, varie avec la taille de l’organisation et le nombre de problèmes qui sont apparus lors de l'étude préalable. Dans un cas, l'exercice peut relever d'une gageure complexe, là où une petite organisation ne nécessitera que quelques implantations de solutions automatisées à la marge des travaux quotidiens de l'organisation.

a) Cas d’une entreprise importante: Si l’organisation est importante en taille (ou en nombre de postes et de flux à gérer) une hiérarchie d’objectifs devra être dégagée. Il est possible de classer par ordre d’importance les objectifs à atteindre. On intègre à cette réflexion des préoccupations telles celles relative à la priorité et à l'appréciation des facteurs clés (plus important) à traiter en priorité. C’est dire qu’en plus des préoccupations propres aux systèmes d'information, l'on doit prendre en comptes des considérations plus globales de stratégie et d’objectifs globaux de l’organisation. Ainsi si dans la hiérarchie des problèmes rencontrés c’est la commercialisation qui se révèle problématique, c'est ce service qui devra dans le plan informatique bénéficier des premières mesures d’automatisation.

b) Cas d’une organisation de plus petite taille: Ici le domaine concerné est moins complexe ou d’une importance stratégique moindre. Les objectifs peuvent alors être définis en terme de fonctions à améliorer et de résultats à optimiser et concernent une tâche donnée précisément délimitée. Dans ce cas le catalogue des objectifs se limite à l’automatisation de certains travaux d'un service. Certaines tâches resteront traitées manuellement si l’apport d’une automatisation n'est pas d’un intérêt probant.

c) Les niveaux de performances: Dans la plupart des cas les temps de réponse, et les capacités en volume de traitement seront les deux préoccupations majeures. Il s’agit pour un travail égal d’aboutir à des résultats optimisés ou à des volumes traités plus importants.

2°) Les contraintes

Tout objectif se confronte à des contraintes. Très variées ces dernières affectent les coûts, les personnels (agents de l’organisation), les délais de réalisation des travaux considérés acceptables.

a) Les contraintes financières: Elles sont à prendre en compte avec rigueur. L’organisation doit pouvoir obtenir ses résultats escomptés au meilleur coût. Les coûts d’études, les investissements initiaux et sans les oublier les coûts de fonctionnement doivent être quantifiés avec la précision optimum. L’aspect financier est au moment de choisir entre les solutions possibles un critère qui n'est pas le seul, mais qui est important.

b) Les contraintes relatives au personnel: On étudie et on chiffre les conséquences en termes d’embauches, de licenciements éventuels pour recourir à des personnels initiés aux techniques informatiques. La formation constitue une alternative à envisager.

c) Les contraintes de délais: Ces dernières consistent à établir une planification dans le temps des objectifs à atteindre. Cette planification exige la prise en compte de la hiérarchie d'objectifs, à articuler avec le calendrier de mise en œuvre de l'automation.

3°) Les niveaux de solution

En fonctions des changements induits les solutions peuvent être classées selon la nature des changements mis en œuvre. Ainsi on distingue des niveaux de solution qui affectent les procédures de ceux qui ne les modifient pas. Cette distinction est primordiale.

a) Les solutions ne remettant pas en cause les procédures de gestion: Dans ce cas, il s’agit d’automatiser certaines opérations ou de mettre en œuvre des outils d’assistance aux travaux des services, sans modifier les modalités de gestion. Ni les procédures de gestion ni les principes de gestion ne sont affectés. Ce cas se présente par exemple lorsque les secrétariats se voient équipés de logiciels de traitements de texte, de tableurs sur poste individuel. En ces cas les procédures de gestion ne sont pas modifiées. Fondamentalement, les tâches sont similaires à ce qu’elles étaient. Le courrier par exemple est réalisé à l'aide d'un traitement de texte, au lieu d'une machine à écrire. Le travail de la secrétaire n'est pas fondamentalement modifier. Une simple automatisation, très partielle, a été "greffée" à des tâches relativement identiques.

b) La modification des procédures et des fonctions: Ici ce sont les fonctions et les postes de travail qui sont repensés. Les agents de l’organisation voient l'exécution de leurs travaux quotidiens changer. C'est le cas lorsque certaines tâches sont déléguées à des machines parce qu'elles se révèlent réductibles à des algorithmes. Le courrier est par exemple, dans certains services, rédigé et expédié automatiquement.

Le domaine des assurances est un exemple de ce type de modification. (Celui de la presse aussi): Ainsi les sociétés d’assurance avaient une organisation qui dissociait les fonctions de commerciaux (les agents vendaient des contrats d’assurance), les fonctions juridiques (soit la gestion des contrats relevait du service juridique). Le traitement des sinistres relevait d’un autre service (expertise du sinistre et activation de la procédure de dédommagement). De sorte que pour un assuré donné plusieurs interlocuteurs spécialisés intervenaient au cours du contrat. L’automatisation des traitements modifie les procédures lorsqu'en raison de l’automatisation d’un système de gestion documentaire les contrats type peuvent être générés par un non-spécialiste. La gestion automatisée des procédures nées d’un sinistre combiné à la gestion des contrats modifie les procédures de gestion.

Un seul agent gère alors l’ensemble de la relation avec l’assuré. Le contrat type complété pour ses composants informatifs les plus simples par le commercial est réalisé par ce dernier assisté d'un logiciel de rédaction juridique. Les procédures de gestion sont donc modifiées. Les métiers des agents ont changé. Dans une telle situation les modifications affectent l’organisation et les techniques de travail. Ce sont aussi les compétences requises qui sont modifiées.

c) La modification des principes de gestion: Ce cas de figure révèle plus encore les transformations qui peuvent intervenir. Au-delà des modifications des tâches des agents et des procédures de traitements par les services ce sont les principes les plus globaux, voire stratégiques, de l’organisation qui sont modifiées. En ce cas l’analyse de l’existant aboutit à constater que l’automatisation jugée nécessaire doit se combiner avec de nouvelles procédures de gestion.

Le choix par exemple de passer à une politique de production à la commande, et non plus en stockant, modifie considérablement le travail des services. Le service commercial doit être réorganisé. Le suivi client lui-même voit son organisation transformée. Mais surtout, Le travail d’ordonnancement de la production est profondément modifié. On a ici un principe essentiel de gestion qui se trouve être repensé. Dans le même temps l'on doit

noter que le phénomène se produit avec un effet en cascade. S’il devient indispensable de modifier les principes essentiels de l’entreprise, tous les services sont affectés, seul le degré peut varier.

d) Comment déterminer le niveau de solution: C’est l’analyse de l’existant qui permet la localisation des dysfonctionnements. C’est à partir de ce travail et des constats faits que le niveau de solution est déterminé.

L’automatisation aboutit à modifier les métiers et dépasse la simple conséquence d’une modification des procédures née de l’apparition d’un outil nouveau. Le niveau de la solution se situe donc de plein pied dans le domaine des choix organisationnels.

La question est devenue: Quelle est l'organisation que doit avoir l’entreprise pour être le plus efficace possible dans sa gestion? A ce stade l’on dépasse les problèmes des systèmes d'information, pour entrer dans le domaine des choix stratégiques.

B) La construction de l’avant projet

L’analyse des niveaux de solution permet de situer la nature et l'ampleur des modifications que l’organisation va subir. Que ce soit s'agissant des procédures mais aussi dans des principes de gestion. On distingue alors des types de solutions.

1°) Les types de solutions

a) La notion de types de solution: Ces derniers dépendent des caractéristiques propres aux traitements automatisées. Dit autrement on peut isoler deux catégories de techniques informatiques entre lesquelles il faudra choisir, selon ce que l'on attend de l'automatisation.

* L’automatisation des traitements par lots: Ce type d’automatisation est choisi lorsque le volume des traitements est élevé avec des temps de réponse dont il n’importe pas qu’ils soient très rapides. C’est le cas des traitements comptables. Dans ces domaines autant la saisie doit être aisée et les états de sorties précis et utiles, autant l’on n’a pas de besoins instantanés de disposer des états de sortie. Ainsi les livres comptables s’établissent au jour le jour mais il n'est pas nécessaire d’obtenir les états comptables à l’instant même (le bilan est annuel, les autres états sont mensuels). C’est que les impératifs légaux, et ceux touchant à la gestion, ne nécessitent pas dans ces domaines des réponses instantanées du système.

Exemple: Le traitement de la paie, mensuelle, exige que les feuilles de paie soient disponibles la veille des paiements. Une plus grande rapidité serait, sauf cas particulier, sans intérêts. Dans ce type de traitement, les écritures sont saisies une fois par mois.

* L’automatisation basée sur des traitements unitaires: Ce type de solution est mis en œuvre quand les temps de réponses exigés sont très courts. Par exemple, le suivi des stocks, avec possibilités pour les commerciaux d’annoncer (immédiatement) les délais de livraison, la disponibilité (ou non) des produits commandés. Cette immédiateté suppose une organisation d’une certaine taille et une politique des stocks exigeant cette qualité du système d’information. Dans cette hypothèse l’automatisation des traitements est synonyme de modification des procédures voire des principes de gestion.

Dans la pratique les deux types de solution pourront coexister. Moyennant une étude judicieuse des besoins, certains traitements se verront affectés une solution traitement par lot, d’autres une solution traitements unitaires. Ces derniers étant quelquefois qualifiés de traitement en temps réel.

b) Le choix: Alors que les types de solutions sont déterminés l’on doit affiner la solution informatique.

L’affinement consiste dans le fait de préciser quelques points essentiels.

* Les fonctions ou tâches à automatiser: Soit à analyser avec précisions les tâches, dans les postes clairement localisés et que l’on considère à l’aide de l’étude préalable, appartenir au questionnement que faire? . Ce en ayant à l’esprit qu’à un tel niveau de détail, l'étude est supposée avoir dégagé quelles tâches gagnent à être automatisées.

* Les sorties: Les traitements automatisés le sont pour obtenir des résultats. Il convient d’analyser sur quels supports ces résultats devront apparaître. C’est le quoi produire? de l’automatisation.

* Les entrées externes ou stockées: Répondant à la question à partir de quoi? Soit que l’on détermine les événements déclencheurs des opérations automatisées. C'est la commande d’un client, l’ordre de paiement d’une banque etc. Nous avons ainsi une définition pratique de la solution lorsqu’une réponse à été apportée à la

question générique suivante: Que doit faire le système automatisé à partir de quelles informations doit-il produire des résultats dégagés par l’analyse?

2°) Les moyens à utiliser

La solution a été considérée opportune, il est nécessaire de définir les moyens. Ce en tenant compte des quantités, des puissances de calcul, de l'architecture (en réseau par exemple). Le tout est doublé d'une évaluation financière. Notons qu'à ce stade, il ne s'agit que d'une une esquisse de solution où sont énumérés le matériel (hard), les logiciels (soft) ou progiciel ainsi que les personnels nécessaires.

* Les moyens matériels: Constitués des outils informatiques, ce sont les organes de calculs au sens large du terme. Leur puissance devra être calculée. L'architecture générale du système au point de vue technique est analysée à ce point de l’étude. Ainsi est pris en compte le nombre de postes en précisant ceux qui seront structurés autour de connexions en réseaux locaux. La précision dans ce travail aura des conséquences sur le choix des logiciels, qu’il s’agisse des applications (logiciels divers.). Mais aussi des systèmes d'exploitations (ces systèmes sont retenus selon des critères fonctionnels (Windows, Unix, autres)). C’est donc une adéquation, entre matériels et logiciels qui est la préoccupation à ce stade.

* Le choix entre logiciels et progiciels: Dans certains cas et ce de plus en plus, le recours à des progiciels permet de satisfaire les solutions dégagées. Le choix peut se limiter à l’étude comparée des produits logiciels. Ces derniers, standardisés, correspondent bien à des applications générales et routinières telles celles des métiers de la gestion. L’importance de l’offre et les coûts bas motivent cette recherche sur le marché des éditeurs de ces produits.

Certes, toutes les applications ne se prêtent pas à la l'utilisation de progiciels. Il convient alors de recourir à des applications spécialisées. Ces dernières sont spécialement écrites pour l’organisation et adaptées à ses besoins particuliers. La démarche et les coûts sont très différents. L’avantage des progiciels consiste dans le prix d’une part mais encore dans le fait que les essais et les mises à jour ont été réalisés à l'occasion de l’utilisation par de nombreux utilisateurs. Ce "partage" d’une solution standard aura l’intérêt de permettre au futur acquéreur de bénéficier des améliorations successives mesurées parfois à l'indicateur du numéro de version de l'application logicielle.

Dans le cas d’une acquisition de logiciels spécifiques - écrits sur commande pour une entreprise - les erreurs de programmation, les manques constatés doivent être découverts au jour le jour et nécessitent des corrections de la part du programmeur. Les programmes opérationnels à 100% dés la première écriture sont très rares. La solution progiciel permet dont d'atténuer, voire d'éliminer cette problématique de la phase de mise au point "en situation".

§2 L’évaluation des solutions.

Au terme de la phase d’élaboration telle qu’elle est issue de l’étude préalable une ou plusieurs solutions sont dégagées. Elles ont d’un strict point de vue technique la même qualité. C’est le cas, du fait même qu’il est rare que plusieurs solutions ne soient pas adaptées à un problème donné. Le choix qui devra intervenir car il faudra se décider tôt ou tard, est le fruit d’une évaluation des solutions. Deux instruments de mesures servent d’outils d’évaluation. La praticabilité sera ce premier instrument, l’opportunité constituant le second instrument d’appréciation.

A) La praticabilité de la solution.

Le problème de la praticabilité, posé lors de la phase initiale (l’étude préalable), est reposé après que les résultats de l’analyse de l’existant aient été obtenus. Ce questionnement, renouvelé peut être considéré comme un "zoom" fait sur le précédent. Il s’agit de déterminer la liste des matériels permettant de satisfaire les besoins mis à jour. Mais aussi l'on aborde la gestion des changements organisationnels que la solution informatique rend nécessaire.