Vous êtes sur la page 1sur 473

DS C G 5

Management des
systèmes d’information
MANUEL ET
APPLICATIONS
Corrigés inclus

Michelle GILLET Patrick GILLET


Enseignante en management des Enseignant en programmation et architecture
systèmes d’information et en gestion de projets des systèmes en Master 2 à l’IAE de Poitiers
en Master 2 à l’IAE de Poitiers et en modélisation et en programmation orientée objet,
des systèmes d’information et génie logiciel programmation système et Web, méthodologie
au CNAM Poitou-Charentes de déploiement au CNAM Poitou-Charentes

2e édition
© Dunod, Paris, 2010
ISBN 978-2-10-056134-6
ISSN 1269-8792
Sommaire

Pour réussir le DCG et le DSCG VII


Manuel, mode d’emploi VIII
Programme de l’épreuve XI
Avant-propos XV

PARTIE 1 Gouvernance des systèmes d’information 1


CHAPITRE 1 Relation entre informatique et système d’information 3
Section 1 Vision systémique des organisations 4
Section 2 Place et rôle du système d’information au sein du système entreprise 30
Section 3 Relation entre maîtrise d’œuvre et maîtrise d’ouvrage 45
Applications 48
CHAPITRE 2 Structure du système d’information 51
Section 1 Facteurs influençant la structure du système d’information
d’une organisation 51
Section 2 Éléments constitutifs d’un système d’information 89
Applications 134
CHAPITRE 3 Structuration des systèmes d’information 135
Section 1 Position de la fonction informatique au sein de l’organisation 135
Section 2 Stratégie informatique 144
Section 3 Urbanisation des systèmes d’information 146
Applications 152

PARTIE 2 Gestion des projets en système d’information 155


CHAPITRE 4 La conduite et la gestion de projet 157
Section 1 Principes généraux de la gestion de projets 157
Section 2 Aspects spécifiques des projets en système d’information 179
Section 3 Rédaction du cahier des charges fonctionnel 182
Applications 205
CHAPITRE 5 L’implantation du système d’information 207
Section 1 Mise en place d’un système 207
Section 2 Cycle de vie du projet 213
Section 3 Gestion de la qualité 217
Section 4 Gestion des risques 247
Applications 256

V
Sommaire

CHAPITRE 6 Gérer le système d’information de l’organisation 259


Section 1 Les impacts du système d’information sur la mise en place
de la stratégie de l’organisation 260
Section 2 L’interaction entre l’évolution du système d’information
et l’évolution organisationnelle 267
Section 3 L’adéquation du système d’information à l’état de l’organisation 277
Application 279

PARTIE 3 Outils et méthodes informatiques 281


CHAPITRE 7 Les progiciels de gestion intégrés 283
Section 1 Positionnement des PGI 283
Section 2 La conduite d’un projet PGI 297
Applications 300
CHAPITRE 8 La gestion de la performance informatique 301
Section 1 Mesurer la performance informatique 301
Section 2 Le contrat de service 303
Section 3 La connaissance des coûts 306
Section 4 La gestion budgétaire appliquée à la fonction informatique 308
Section 5 L’évaluation des projets informatiques 312
Applications 315
CHAPITRE 9 Architecture technique 317
Section 1 Domaines de choix à effectuer 317
Section 2 Structures types de déploiement 347
Applications 355
CHAPITRE 10 La sécurité des systèmes informatiques 357
Section 1 Mise en place d’une architecture de confiance 358
Section 2 Surveillance et prévention 366
Applications 373
CHAPITRE 11 L’auditeur en environnement informatique 375
Section 1 Audit du système d’information et audit informatique 375
Section 2 Démarche et outils d’audit du système d’information 376
Section 3 Démarche et outils d’audit de l’informatique 382
Section 4 Un environnement spécifique pour l’auditeur 387
Section 5 L’audit assisté par ordinateur 388
Applications 392

Annexes 393
Corrigés des applications 395
Bibliographie 437
Lexique 439
Index 451
Table des matières 455

VI
Pour réussir le DCG et le DSCG

Le cursus des études conduisant à l’expertise comptable est un cursus d’excellence, pluri-
disciplinaire, vers lequel se dirigent, à raison, de plus en plus d’étudiants.
Dunod dispose depuis de très nombreuses années d’une expérience confirmée dans la
préparation de ces études et offre aux étudiants comme aux enseignants une gamme
complète d’ouvrages de cours, d’entraînement et de révision qui font référence.
Ces ouvrages sont entièrement adaptés aux épreuves, à leur esprit comme à leur
programme, avec une qualité toujours constante. Ils sont tous régulièrement actualisés pour
correspondre le plus exactement possible aux exigences des disciplines traitées.
La collection Expert Sup propose aujourd’hui :
– des manuels complets mais concis, strictement conformes aux programmes, comportant
des exemples permettant l’acquisition immédiate des notions exposées, complétés d’un
choix d’applications permettant l’entraînement et la synthèse ;
– des livres de cas pratiques originaux, spécialement conçus pour la préparation des
épreuves ;
– la série « Réussir », spécifiquement dédiée à l’entraînement à l’examen.
Elle est complétée d’un ensemble d’outils pratiques de révision, avec la collection Express
DCG, ou de mémorisation et de synthèse avec les « Petits » (Petit fiscal, Petit social, Petit
Compta, Petit Droit des sociétés…).
Ces ouvrages ont été conçus par des enseignants confirmés ayant une expérience reconnue
dans la préparation des examens de l’expertise comptable.
Ils espèrent mettre ainsi à la disposition des étudiants les meilleurs outils pour aborder leurs
études et leur assurer une pleine réussite.

Jacques Saraf
Directeur de collection

VII
NU EL
MA D’EMPLOI
MOD E ,le co urs présente tou
tes les c
ntés
o
d
n
a
n
ns
aissa n
des rubrique
ramm
s distinctiv
e de l’épreuve DSCG 5.
ces au prog es, sont aisément repéra
bles

structuré ns,prése
Clair et bien mp le s et illustratio issances à acquérir.
exe nna
Plus de 300 e mieux assimiler les co
n t d
et permette
De nombreux schémas,
Le mini-sommaire précise tableaux et exemples
le plan du chapitre

Le cours
complet et progressif

Renvoi vers
une autre partie
du cours

WEB Renvoi vers


Internet

3 fiches pratiques
sur la conduite
de projets
is.
et la va lidation des acqu
en œuvre lée sont
m e pe rm ettent la mise a tières détail
p rogra m de s m
ints du la table
tio n co uv ra nt tous les po og ra p hie ,l’index et
d’applica ,la bib li
26 énoncés es c o rr ig és complets
ge,l
e fin d’ouvra
En annexe d mplémentaire
s.
’outils co
autant d

Les énoncés
d’application
de thématiques variées
et de complexité progressive
sont regroupés en fin de chapitre

Les corrigés des questions


de cours, le lexique L’index pour retrouver
et l’index facilement les notions
Les corrigés des applications
pour s’auto-évaluer dans l’ouvrage

La bibliographie donne des indications


de volume,de difficulté et de proximité avec
le programme des ouvrages référencés
Programme de l’épreuve n° 5,
DSCG Management des systèmes
d’information*
DURÉE
NATURE DE L’ÉPREUVE DURÉE COEFFICIENT
DE L’ENSEIGNEMENT
Épreuve écrite portant sur l’étude
d’un cas ou de situations pratiques
(à titre indicatif)
pouvant être accompagnées
140 heures 3 heures 1
de commentaires
15 crédits européens
d’un ou plusieurs documents
et/ou d’une ou plusieurs questions

THÈMES SENS ET PORTÉE DE L’ÉTUDE NOTIONS ET CONTENUS


1. Gouvernance Comprendre la nécessité d’associer au
des sytèmes d’information système d’information de l’organisation
(25 heures) des structures de prise de décision

1.1 Le positionnement Analyser les relations entre la direction La direction des systèmes d’information : mission, organigramme, tableau
de la fonction générale, la direction des systèmes de bord.
informatique au sein d’information et les directions « métiers » La fonction informatique dans les petites organisations.
l’organisation
Connaître le contenu et la démarche Alignement de la stratégie informatique sur la stratégie « métier ».
d’élaboration de la stratégie informatique. Le schéma directeur informatique : définition, évolution, communication sur
1.2 La stratégie Comprendre ses liens avec la stratégie le schéma directeur.
informatique globale et définir la chaîne d’alignement Plan informatique.
stratégique. Démarche de planification informatique.
1.3 Urbanisation (évolution) Prendre en compte la diversité des appli- Cartographie du système d’information.
des systèmes cations informatiques dans l’organisation.
d’information

2 La gestion
de projets de système
d’information
(25 heures)
Analyser les conditions de lancement Place du projet dans la stratégie.
2.1 Les enjeux d’un projet d’un projet. Périmètre de son application.
Organisation du projet.
Connaître la démarche et les outils pour Cahier des charges.
mettre en œuvre un projet. Cycle de vie d’un projet : prévision, planification, ordonnancement.
Plan d’assurance qualité : normes ISO sur la qualité du logiciel ; méthode de
2.2 La mise en œuvre conduite de projets ; méthode d’amélioration des processus (CMMI).
d’un projet Suivi et contrôle des coûts et des délais : analyse des écarts (de planning,
budgétaires).
Test : jeux d’essai, site pilote, test en situation réelle, qualification, recette.
Déploiement d’une solution et formation des utilisateurs.
Connaître les différents types de mainte- Maintenance corrective.
nance et comprendre leur adaptation au Maintenance évolutive.
2.3 Maintenance projet. Contrat et maintenance.
Tierce maintenance applicative.
Identifier les conditions qui peuvent con- Analyse et gestion des risques.
2.4 Gestion des risques duire à l’échec et les mesures préventives Intégration des risques dans les contrats.
du projet et correctives utilisables.

* Arrêté du 8.03.2010

XI
Programme de l’épreuve n° 5, DSCG Management des systèmes d’information


2.5 Les meilleurs Découvrir l’importance d’une capitalisa- Gestion des connaissances;
pratiques – Les facteurs clès tion des savoirs et savoir-faire au sein de Outils collaboratifs.
de succés l’organisation.

3. Les progiciels
de gestion intégrés
(25 heures)
Comprendre la segmentation du marché Le progiciel de gestion intégré :
3.1 La place des PGI en fonction des besoins des – définition
des progiciels de gestion clients. – diffusion dans les entreprises et les administrations
intégrés (PGI) Analyser les fonctionnalités des logiciels. – couverture fonctionnelle
– évolutions technologiques
Illustrer les concepts de la gestion de pro- Expression des besoins.
3.2 Le cycle de vie jets. Choix de la solution.
d’un progiciel de gestion Mise en place et déploiement de la solution.
intégré Exploitation de la solution.
Évaluation des systèmes de gestion intégrés.
4. Gestion
de la performance
informatique (25 heures)

4.1 Définition Indicateurs de performances.


d’indicateurs Indicateurs de qualité.

Rechercher les niveaux de service à attein- Objectifs et contraintes du contrat de service.


dre. Élaboration du contrat.
4.2 Le contrat Repérer les enjeux des contrats en fonc- Mise en œuvre du contrat.
de service tion du contexte organisationnel (infogé-
rance, prestataire, facturation en interne).
Négocier avec les parties prenantes.
Appliquer les concepts de la comptabilité Analyse des coûts.
4.3 Les coûts de gestion aux spécificités de la fonction Budget de fonctionnement de la fonction informatique.
informatique.
Agréger les dépenses informatiques décen- Budget de la fonction informatique.
traliséess. Facturation en interne de l’utilisation des ressources informatiques.
4.4 Les budgets Comprendre l’intérêt de la facturation
pour responsabiliser les utilisateurs.
4.5 Évaluation Établir des critères de choix des investisse- Évaluation des coûts/avantages des projets informatiques.
des projets ments dans le domaine informatique. Critères de selection des projets.
informatiques

5. Architecture et sécurité
des systèmes
informatiques (20 heures)
Être capable d’identifier les principales Client-serveur
architectures techniques Médiateur (middleware)
5.1 Architecture technique Transactionnel
Intégration
Portail
5.2 Mise en place Comprendre le fonctionnement d’une Infrastructure à clé publique.
d’une architecture infrastructure à clé publique. Certificat numérique.
de confiance Signature électronique.

Prendre les dispositions pour garantir la Surveillance des processus.


5.3 Surveillance continuité de l’activité. Protection juridique.
et prévention Assurances et garanties (légales et contractuelles).
6. L’audit et la gouvernance
(20 heures)

6.1 Audit du système Comprendre le sens d’une mission d’audit Audit interne, audit externe et audit stratégique de la fontion informatique
d’information de la fonction informatique

6.2 Gouvernance d’entre- Appréhendre les enjeux de l’audit dans Contrôle des comptes des entités informatisées.
prise et environnement une organisation informatisée. Risques d’audit.
spécifique Prendre connaissance des obligations Normes professionnelles nationales et internationales.
pour l’auditeur légales et des normes professionnelles. Obligations légales et réglementaires.

6.3 L’audit assisté Identifier les ressources informatiques néces- Les étapes de l’audit assisté par ordinateur.
par ordinateur saires pour réaliser une mission d’audit. Les progiciels d’aide à la révision.

XII
Programme de l’épreuve n° 5, DSCG Management des systèmes d’information

Indications complémentaires
2.1 Dans la partie stratégique, il est important de distinguer la maîtrise d’ouvrage et la
maîtrise d’œuvre et d’étudier l’opportunité de faire ou de faire-faire. La partie organisation-
nelle doit aborder les points suivants : contrat régie et forfait ; relation client-fournisseur en
interne ; relations contractuelles avec les fournisseurs et les prestataires ; l’animation des
équipes.
4.3 L’analyse des coûts fera référence aux éléments suivants : centre d’analyse, unité
d’œuvre, inducteur de coûts ; coût de fonctionnement, coût de développement, coût de
possession (TCO, Total Cost of Ownership). On étudiera les enjeux et les modalités le la
réduction des coûts de l’informatique : externalisation de certaines fonctions, infogérance,
recours à des progiciels, licences libres, délocalisations.

XIII
Avant-propos

Le management des systèmes d’information fait appel à quasiment tous les autres domaines
de la gestion, notamment :
– la stratégie ;
– la gestion des ressources humaines ;
– le marketing et la communication ;
– l’analyse financière ;
– la comptabilité analytique ;
– le contrôle de gestion.
C’est une discipline qui implique une bonne connaissance de toutes les problématiques liées
à l’organisation, quelles que soient la nature de l’activité de l’organisation, sa taille et sa
forme juridique. Elle nécessite une bonne culture générale dans des domaines aussi variés
que l’épistémologie, le management et l’informatique.
Enfin, cette discipline requiert des capacités d’analyse et de synthèse, doublées de compé-
tences techniques et humaines.
Dans un domaine aussi transversal que celui du management des systèmes d’information,
nous avons souhaité susciter la curiosité de l’étudiant et l’inciter à consolider ses connais-
sances par des renvois vers Internet tout au long de l’ouvrage.
Ainsi, si d’une part, le cours présente de façon claire et exhaustive les concepts fonda-
mentaux au programme du Management des systèmes d’information, d’autre part, il
intègre certaines notions connexes qu’il est nécessaire de bien maîtriser pour une parfaite
assimilation des connaissances, et qui sont signalées par un pictogramme (voir le mode
d’emploi du manuel) pour une recherche sur Internet. Nous invitons l’étudiant à soumettre
les termes, acronymes ou expressions signalées, à un moteur de recherche. Il pourra ainsi
trouver dans les dix premières réponses des articles intéressants qui lui permettront
d’approfondir ses connaissances sur la notion concernée.

XV
1
PARTIE
Gouvernance
des systèmes
d’information
CHAPITRE 1 Relation entre informatique et système d’information
CHAPITRE 2 Structure du système d’information
CHAPITRE 3 Structuration des systèmes d’information

1
1
CHAPITRE
Relation entre informatique
et système d’information
section 1 Vision systémique des organisations
section 2 Place et rôle du système d’information au sein
du système entreprise
section 3 Relation entre maîtrise d’œuvre et maîtrise d’ouvrage
applications

L’idée première est qu’il faut en finir avec l’identification du système d’information à l’informatique.

De manière générale, on a tendance à identifier système d’information et informatique.


L’opinion majoritaire est que le système d’information d’une organisation se résume à un
ensemble d’outils informatiques.
Bien que cette opinion soit majoritaire, elle est erronée.
■ Premier motif d’erreur
Il existe bien de nos jours une relation étroite entre système d’information et informatique.
Cependant, il ne s’agit pas d’une relation d’identité mais d’une relation de type demande et
offre. Il existe dans les organisations des besoins de traiter des informations pour permettre
à l’organisation d’être efficace et de se développer. L’informatique peut offrir des outils
permettant de satisfaire ces besoins d’une manière adaptée. La relation entre les deux est
donc de type maîtrise d’ouvrage et maîtrise d’œuvre ou client à fournisseur. Cela aura des
incidences très importantes qui feront l’objet d’une partie conséquente de cet ouvrage.
■ Second motif d’erreur
Le concept de système d’information n’est pas né de l’informatique, mais d’un courant de
pensée épistémologique, le constructivisme, dont une branche a donné la systémique. Cette
discipline a d’abord été appliquée en physique et dans d’autres domaines scientifiques, pour
ensuite être adaptée à la gestion des organisations.
Ce chapitre va donc être consacré au concept de système d’information et à ses implications.
La seconde partie permettra de comprendre la relation entre la maîtrise d’ouvrage et la
maîtrise d’œuvre.

3
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

section 1
vision systémique des organisations
1. Les bases méthodologiques :
un nouveau discours de la méthode
Le concept de système d’information fait l’objet de très nombreux contresens qui ont un
effet très néfaste sur le fonctionnement des organisations.
Pour éviter ces contresens, il est nécessaire de présenter le positionnement exact de ce
concept, qui est relatif à la systémique. La systémique, telle que nous la considérerons ci-
dessous, est un véritable courant épistémologique, qui fournit une représentation du
monde dans la continuité du courant de pensée constructiviste. Ce courant de pensée
s’oppose au cartésianisme et au positivisme.
Même si cela peut paraître ardu d’envisager la notion de système d’information à ce niveau
d’abstraction, c’est une démarche absolument nécessaire pour qui veut comprendre ce
concept. C’est la seule approche pour éviter le contresens courant de l’identification à
l’informatique, avec laquelle il n’a rien à voir sur le plan des idées.
La systémique constitue un nouveau paradigme, c’est-à-dire un nouveau modèle de repré-
sentation du monde, par rapport à celui qui nous a été inculqué, dès notre plus jeune âge,
dans nos sociétés occidentales. WEB Systémique • Paradigme

Ce nouveau paradigme induit un nouveau discours de la méthode.


WEB Discours de la méthode
René Descartes avait défini son discours de la méthode avec pour but de « bien conduire sa
raison et de rechercher la vérité dans les sciences ».
Dans le cadre du paradigme systémique, on peut dire que l’idée d’un nouveau discours de
la méthode, adapté à cette nouvelle vision du monde, est tout à fait pertinente. Il s’agit bien
du même objectif global, à savoir définir des règles du comportement de l’homme pour que
celui-ci soit adéquat avec son environnement.
1.1 Modifications des principes d’un discours de la méthode,
liées au changement de paradigme
Nous identifierons ci-dessous l’ancien discours de la méthode à René Descartes et le
nouveau à Jean-Louis Le Moigne (v. bibliographie). WEB Jean-Louis Le Moigne

Résumons l’opposition des principes, dans l’ancien et le nouveau discours de la méthode,


avant d’en développer la signification et les conséquences.

René Descartes : Jean-Louis Le Moigne :


l’ancien discours de la méthode le nouveau discours de la méthode
La recherche de la vérité Le précepte de pertinence
La décomposition Le précepte du globalisme
L’analyse puis la synthèse Le précepte téléologique
L’exhaustivité Le précepte d’agrégativité

4
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

a) Premier principe
■ Ancien discours de la méthode : la recherche de la vérité
« Le premier était de ne recevoir jamais aucune chose pour vraie que je ne la connusse évidemment
être telle, c’est-à-dire d’éviter soigneusement la précipitation et la prévention, et de ne comprendre
rien de plus en mes jugements que ce qui se présenterait si clairement et si distinctement à mon esprit
que je n’eusse aucune occasion de la mettre en doute. »
Premier précepte du Discours de la méthode de R. Descartes.

■ Nouveau discours de la méthode : le précepte de pertinence


« Convenir que tout objet que nous considérerons se définit par rapport aux intentions implicites ou
explicites du modélisateur. Ne jamais s’interdire de mettre en doute cette définition si, nos intentions
se modifiant, la perception que nous avions de cet objet se modifie. »
J.-L. Le Moigne, La Théorie du système général, Puf, 1985, p. 43.

■ Commentaire
• La recherche de la vérité entraîne une attitude à la fois passive et intolérante
Attitude passive parce que, si la vérité existe et que l’homme est capable de l’atteindre, cela
veut dire que les choses sont ce qu’elles sont, en dehors de lui. Il est en position d’obser-
vateur et non d’acteur. Il ne cherchera pas à transformer le monde mais à s’y adapter. On
rencontrait cette attitude de manière très fréquente dans le management des entreprises
jusqu’à un passé récent.

EXEMPLE
Il était courant d’entendre, dans les années 70, que les points de vue du marketing et de la production
étaient irréductibles. Le responsable du marketing cherchait à individualiser les produits pour répondre
plus précisément aux besoins des consommateurs. Cela impliquait de produire avec des séries les plus
petites possibles. Le responsable de la production voulait allonger les séries au maximum de manière
à diminuer les coûts fixes unitaires.
L’attitude consistant à considérer que les choses sont ce qu’elles sont, qui s’appuie sur le principe
cartésien de la recherche de la vérité, entraînait ce constat, sans que l’on imagine pouvoir y remédier.

Attitude intolérante : À partir du moment où l’on considère, à la suite de ce principe, que


la vérité existe et que l’on doit la rechercher, cela entraîne l’idée chez certains qu’ils
détiennent la vérité. À partir de ce moment, ils vont vouloir l’imposer aux autres, puisque
la vérité est nécessairement unique.
Quand on est persuadé de détenir une vérité, tous les points de vue contraires deviennent
inévitablement faux.
• Le précepte de pertinence provoquera un comportement inverse
Attitude active : Quand bien même une vérité immanente existerait, on considère qu’il est
impossible, et surtout inutile, d’essayer de l’atteindre. Nous n’aurons qu’un point de vue
subjectif sur les choses. Un point de vue pertinent, à un moment donné, est un point de vue
qui démontre son efficacité dans la relation du sujet à la chose. La réalité et l’objectif du
sujet évoluant, il pourra modifier son point de vue afin de conserver la pertinence de la
relation à la chose.

5
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

Attitude tolérante : À partir du moment où nous savons que notre perception de la réalité
est notre point de vue en tant que sujet, il ne présente pas, à nos yeux, de caractère absolu.
Nous serons donc enclins, plus facilement, à considérer le point de vue de l’autre comme
étant susceptible d’autant de pertinence que le nôtre.
b) Deuxième principe
■ Ancien discours de la méthode : la décomposition
« Le second, de diviser chacune des difficultés que j’examinerais en autant de parcelles qu’il se pourrait
et qu’il serait requis pour les mieux résoudre. »
Deuxième précepte du Discours de la méthode de R. Descartes.

■ Nouveau discours de la méthode : le précepte du globalisme


« Considérer toujours l’objet à connaître par notre intelligence comme une partie immergée et active
au sein d’un plus grand tout. Le percevoir d’abord globalement, dans sa relation fonctionnelle avec son
environnement sans se soucier outre mesure d’établir une image fidèle de sa structure interne, dont
l’existence et l’unicité ne seront jamais tenues pour acquises. »
J.-L. Le Moigne, La Théorie du système général, Puf, 1985, p. 43.

■ Commentaire
L’idée de décomposition repose sur le principe de complication. Si on considère que la
réalité est compliquée, il devient évident que, pour l’appréhender, il suffit de la simplifier
c’est-à-dire de la décomposer en éléments simples. Chaque élément pourra alors être
compris dans sa structure et son fonctionnement beaucoup plus facilement.
Cela suppose que le tout se résume à la somme de ses parties. Nous savons bien aujourd’hui
qu’il n’en est rien. En effet, dans un ensemble, il y a les éléments qui le composent, mais
également l’interaction entre ces éléments, et l’interaction de l’ensemble avec son environ-
nement. Cela change totalement les données du problème.
On est donc obligé de raisonner sur la globalité du réel. Cela signifie que l’on doit considérer
la réalité non pas comme compliquée mais comme complexe. Le comportement par
rapport à ces deux visions n’est pas du tout le même. Ce qui est compliqué peut effecti-
vement se simplifier. La complexité doit se mesurer et se gérer, sinon elle entraînera
l’entropie.
c) Troisième principe
■ Ancien discours de la méthode : l’analyse puis la synthèse
« Le troisième, de conduire par ordre mes pensées en commençant par les objets les plus simples et les plus
aisés à connaître, pour monter peu à peu comme par degrés jusques à la connaissance des plus composés,
et supposant même de l’ordre entre ceux qui ne se précèdent point naturellement les uns les autres. »
Troisième précepte du Discours de la méthode de R. Descartes.

■ Nouveau discours de la méthode : le précepte téléologique


« Interpréter l’objet non pas en lui-même, mais par son comportement, sans chercher à expliquer a
priori ce comportement par quelque loi impliquée dans une éventuelle structure. Comprendre en
revanche ce comportement et les ressources qu’il mobilise par rapport aux projets que, librement, le
modélisateur attribue à l’objet. Tenir l’identification de ces hypothétiques projets pour un acte
rationnel de l’intelligence et convenir que leur démonstration sera bien rarement possible. »
J.-L. Le Moigne, La Théorie du système général, Puf, 1985, p. 43.

6
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

■ Commentaire
• Vision statique et objective
Après la décomposition, il serait possible de reconstruire une vision complète compréhen-
sible du tout.
On alternerait ainsi, dans la démarche intellectuelle, l’analyse et la synthèse, pour atteindre
la vérité, immanente, qui nous est extérieure. La vision reconstruite de cette réalité est
statique. Elle est axée sur la description et la compréhension structurelle du monde réel.
• Vision dynamique et finalisée
Nous sommes dans une position de modélisation c’est-à-dire de représentation schéma-
tique de règles de fonctionnement de l’objet. Nous ne sommes pas intéressés par la compré-
hension structurelle de l’objet. Ce qui nous importe est d’en construire une représentation
schématique, permettant de comprendre son fonctionnement. Cette représentation
constitue un modèle. Elle doit nous permettre d’être capables de simuler les conséquences
de nos actions en termes d’interactions avec l’objet. Si le comportement réel de l’objet est
bien celui que nous attendions par la simulation, cela signifie que notre modèle est
pertinent. Le jour où nous constaterons que la réalité s’écarte de la simulation, nous recon-
sidérerons notre modèle.

EXEMPLE
Un domaine bien connu où l’on utilise la modélisation depuis de nombreuses années est l’industrie de
montage (automobile, aéronautique, etc.). De nos jours, cette pratique a amplifié sa capacité à la
conception rapide et efficace des nouveaux produits grâce à la CAO (conception assistée par
ordinateur). Mais l’approche de modélisation existait déjà antérieurement dans ce domaine. Elle
permettait de simuler le comportement du futur produit, à l’aide de modèles réduits, dans des
souffleries. Par exemple, on étudiait un profil d’aile d’avion de cette manière, pour voir qu’elle serait la
maniabilité de l’appareil et sa tolérance des situations extrêmes. Dans ces domaines, l’aptitude à
modéliser et à simuler a atteint un tel degré de maîtrise qu’aujourd’hui, les pilotes d’essai de l’Airbus
A 380 ont déclaré, après leur premier vol, que les réactions en vol, au décollage et à l’atterrissage de
l’appareil étaient totalement conformes à ce que laissait prévoir le simulateur. Il en est de même dans
l’automobile lorsque l’on teste la sécurité passive des véhicules dans des simulations d’accidents et que
l’on rapproche les résultats des situations réellement observées (déclenchement des airbags ou des
prétentionneurs de ceinture de sécurité).

La modélisation des comportements des organisations obéit aux mêmes principes.


Cependant, elle n’a pas atteint le même degré de perfection que dans les services R&D de
l’industrie.
Deux raisons à cela :
1) La compétence des managers, dans le domaine de la modélisation, est bien moindre que
celle des ingénieurs. Cela ne fait pas partie de leurs habitudes professionnelles de base.
2) Le domaine est plus complexe. Les systèmes industriels sont des systèmes fermés. Il est
vrai que de nos jours l’interaction avec leur environnement peut avoir une complexité très
importante. Néanmoins, l’objet obéit à des règles mécaniques, physiques, connues et que
l’on peut décrire sous forme de formules mathématiques. Au contraire, les organisations
sont des systèmes ouverts, dont la complexité et les axes d’évolution sont incertains. Il est
donc plus difficile de modéliser le fonctionnement d’une organisation dans son environ-

7
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

nement à cause de sa complexité et de son interaction avec son environnement, que de


modéliser le comportement prévisible d’un avion. WEB Téléologie

d) Quatrième principe
■ Ancien discours de la méthode : l’exhaustivité
« Et le dernier, de faire partout des dénombrements si entiers et des revues si générales que je fusse
assuré de ne rien omettre. »
Quatrième précepte du Discours de la méthode de R. Descartes.

■ Nouveau discours de la méthode : le précepte d’agrégativité


« Convenir que toute représentation est partisane, non pas par oubli du modélisateur, mais
délibérément. Chercher en conséquence quelques recettes susceptibles de guider la sélection d’agrégats
tenus pour pertinents et exclure l’illusoire objectivité d’un recensement exhaustif des éléments à
considérer. »
J.-L. Le Moigne, La Théorie du système général, Puf, 1985, p. 43.

■ Commentaire
La recherche de l’exhaustivité dans la compréhension de la structure de l’objet est
logiquement liée à la recherche de la vérité.
Dans le cadre du nouveau discours de la méthode, lié à la systémique, on ne s’intéresse pas
à ce que pourrait être l’objet, en terme de structure, mais à la vision que l’on a de celui-ci. Or
cette vision est un point de vue partiel sur l’objet, qui correspond aux besoins et aux intentions
que l’on a par rapport à lui. Deux sujets pourront donc avoir deux représentations totalement
différentes du même objet, sans pour autant qu’il y en ait un plus « vrai » que l’autre. Si les
deux représentations correspondent à deux usages différents de l’objet, il est normal que les
points de vue des deux sujets divergent. L’important est que chacun d’eux soit pertinent pour
le sujet qui le possède par rapport à l’interaction qu’il doit avoir avec l’objet.

EXEMPLE
Prenons l’objet automobile.
Le point de vue du constructeur implique la connaissance de la nomenclature des pièces nécessaires
pour le construire et des méthodes d’assemblage.
Le point de vue du propriétaire consiste à en connaître l’immatriculation, le contrat d’assurance, les
règles de maintenance et de garantie en cas de panne.

En conclusion : l’incidence du changement de discours de la méthode pour mettre en œuvre le


nouveau paradigme.
Afin de permettre la mise en œuvre, de manière effective, du paradigme systémique dans la gestion
des organisations, il est nécessaire d’adopter ce nouveau discours de la méthode. Dans la suite de cet
ouvrage, nous utiliserons en permanence ses principes, que ce soit dans le recours à la modélisation,
à l’empathie ou à la dynamique.

8
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

1.2 Première définition de ce qu’est un système(1) (1)


Cette définition aura une portée pratique très importante en matière de système d’infor-
mation.

Éléments composants un système dans la définition dite « trivial »


Quelque chose : un objet
Dans quelque chose : son environnement composé d’autres objets
Pour quelque chose : cet objet a un but qu’il poursuit
Fait quelque chose : l’objet mène des activités pour atteindre son but
Par quelque chose : l’objet possède une structure sur laquelle repose le déroulement de ses activités
Qui se transforme dans le temps : l’évolution de l’objet est génétique

Un système, c’est :
a) quelque chose (un objet)…
Dans l’action qui consistera à modéliser l’objet, il ne faudra pas perdre de vue que ce que
nous cherchons à représenter existe. On a souvent tendance, en matière de système d’infor-
mation et d’outils de gestion, à vouloir modéliser ce que l’on a en tête, sans se remémorer
que l’objet à modéliser appartient au monde réel. Cette existence de l’objet entraîne que la
validation du modèle, qui en constitue une représentation, consiste en sa capacité à en
prédire les comportements, dans le cadre de simulation.
b) … dans quelque chose (son environnement)…
L’interaction entre le système et son environnement constitue également un facteur dont
on peut tirer de nombreuses conséquences en matière de gestion des organisations.
L’organisation est vue comme un système en interaction avec un environnement, composé
lui-même de nombreux autres systèmes. Cette vision de l’organisation implique qu’elle ne
peut se concentrer uniquement sur son fonctionnement interne, mais doit au contraire
s’axer sur les interactions qu’elle entretient avec les autres systèmes constituant son
environnement.
c) … pour quelque chose (sa finalité)…
L’organisation, en tant que système, poursuit un but. Elle recherche soit un profit à répartir
à ses actionnaires, soit un service à rendre à la collectivité ou à un groupe d’ayants droit.
Cette caractéristique est très importante, car il faut être conscient de ce qu’est le but de
l’organisation et il faut un minimum de consensus sur celui-ci.
d) … fait quelque chose (son activité)…
Pour atteindre le but, il faut mener une activité, créatrice de valeur ajoutée. Cette activité est
menée que par les différents acteurs de l’organisation. Cela redonne toute sa place à l’humain,
qui est le seul facteur de création de valeur.
Cela démontre également l’aspect dynamique inéluctable. L’activité créatrice transforme
l’organisation en l’inscrivant dans un mouvement perpétuel, en interaction avec les acteurs
de son environnement.

(1) D’après Jean-Louis Le Moigne.

9
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

e) … par quelque chose (sa structure)…


Comment mener l’activité, qui permet d’atteindre le but ? Grâce à une structure, qui
permet d’organiser l’action des différents acteurs et de faire circuler les flux nécessaires.
f) … qui se transforme dans le temps (son évolution)
L’action création constitue un processus de transformation de ressources. Elle a un impact
sur l’organisation elle-même.
1.3 La prise en compte du concept de complexité
La complexité n’est pas la complication.
« La complexité s’impose d’abord comme impossibilité de simplifier, elle surgit là où l’unité complexe
produit ses émergences, là où se perdent les distinctions et clartés dans les identités et les causalités, là
où les désordres et les incertitudes perturbent les phénomènes, là où le sujet-observateur surprend son
propre visage dans l’objet de son observation, là où les antinomies font divaguer le cours du
raisonnement…
La complexité n’est pas la complication. Ce qui est compliqué peut se réduire à un principe simple
comme un écheveau embrouillé ou un nœud de marin Certes, le monde est très compliqué, mais s’il
n’était que compliqué, c’est-à-dire embrouillé, multidépendant, etc., il suffirait d’opérer les
réductions bien connues : jeu entre quelques types de particules dans les atomes, jeu entre 92 types d
atomes dans les molécules, jeu entre quatre bases dans le « code génétique », jeu entre quelques
phonèmes dans le langage. Je crois voir montré que ce type de réduction, absolument nécessaire,
devient crétinisant dès qu’il devient suffisant, c’est-à-dire prétend tout expliquer. Le vrai problème
n’est donc pas de ramener la complication des développements à des règles de base simple. La
complexité est à la base »
E. Morin, La Méthode, T.1, coll. « Essais », Points, 1977, p. 377.

La complexité ne se simplifie pas et ne s’élimine pas. Il faut la mesurer et la gérer.


Elle se mesurera par le nombre d’interactions, qui existent entre les éléments d’un système.

EXEMPLE
Une entreprise produit et vend 10 produits différents dans le domaine des jeux et loisirs. Elle les
distribue par l’intermédiaire de deux canaux de distribution : vente en libre-service et commerce
électronique. Elle vient de décider de lancer un 11 e produit. Sa complexité ne va pas augmenter
seulement d’un facteur 1. Ce nouveau produit va entrer en interaction avec les dix autres et les deux
canaux de distribution. En effet, pour le produire, le stocker, le vendre, il va falloir coordonner l’activité
liée à ce nouveau produit avec l’existant.
Cela va modifier :
– la planification de la fabrication ;
– le planning de travail du service maintenance pour adapter les machines ;
– l’arrangement des surfaces de stockages ;
– les modalités de passation des commandes de matières premières ;
– le travail de la force de ventes, qui va devoir s’occuper de son positionnement sur le marché auprès
de la grande distribution ;
– le service informatique, qui gère le site de vente en ligne, qui va devoir modifier les pages du site, la
base de données et prévoir des pages d’information complémentaires pour ce nouveau produit, etc.

10
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Si, de surcroît, ce produit n’appartient pas à la même technologie que les précédents, il va entraîner une
baisse de compétences des ouvriers qui va rendre nécessaire une action de formation et revoir toute la
planification des ressources, car le temps passé pour ce produit ne sera plus disponible pour les autres.
WEB Complexité

1.4 Le recours à la modélisation


Action d’élaboration et de construction intentionnelle, par composition de symboles, de
modèles susceptibles de rendre intelligible un phénomène perçu complexe et d’amplifier le
raisonnement de l’acteur projetant une intervention délibérée au sein du phénomène ; raison-
nement visant notamment à anticiper les conséquences de ces projets d’actions possibles.
WEB Modélisation – http://www.volle.com/travaux/modelisation2.htm

STRUCTURE D’UN SYSTÈME ORGANISATIONNEL : PREMIÈRE APPROCHE

Environnement

Organisation

Modules
pilotes

Système
d’information
Ressources
prélevées dans
Modules l’environnement
opérationnels

Produits & services fournis


à l’environnement incluant
Processus de transformation de flux une valeur ajoutée
d’entrées et flux de sorties avec
création de valeur ajoutée

Jusqu’ici nous avons évoqué une approche de l’organisation en tant que système. Il pourrait
sembler que nous nous soyons écartés de notre sujet : le système d’information de celle-ci.
Revenons donc à la structure d’un système appliqué à une organisation, ce qui va permettre
de définir précisément le concept de système d’information.
1.5 Un système est composé de trois types d’éléments
Les trois composantes de tout système sont :
– les modules opérationnels, qui assurent la transformation des flux entrants en flux sortants, c’est-à-
dire l’activité ;
– les modules pilotes, qui assurent la prise de décision à différents niveaux ;
– le système d’information, qui assure le couplage organisationnel entre les deux autres types d’éléments.

11
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

a) Des modules opérationnels


Ils mènent l’activité créatrice de valeur ajoutée. Pour cela, ils présentent plusieurs caractéris-
tiques essentielles :
– l’organisation doit trouver les ressources de toutes natures qui feront l’objet des processus
de transformations par les modules opérationnels à l’extérieur, c’est-à-dire auprès d’autres
systèmes de son environnement ;
– l’activité, qui caractérise l’organisation dans sa recherche pour atteindre son but, consiste
donc en un processus de transformation des flux entrants en flux sortants. De la même
manière qu’elle trouve ses ressources dans son environnement, elle produit un résultat
qui est destiné à celui-ci ;
– les modules opérationnels sont donc au contact permanent des acteurs de l’environ-
nement. Parallèlement à leurs opérations de transformation des flux, ils collectent les
données sur les conditions d’obtention des flux entrants et sur la perception de flux
sortant par l’environnement. Les modules opérationnels ont donc deux fonctions
également fondamentales pour la vie de l’organisation :
• la création de valeur dans le cadre de l’activité, qui va permettre d’atteindre le but,
• la connaissance des conditions dans lesquelles se déroule l’activité, grâce à la collecte des
données au sein de l’environnement.
La prise en compte, complète et efficace, de ces deux aspects de leur activité est essentielle
pour atteindre le but de l’organisation.
Les implications de cette définition du rôle des modules opérationnels sont très nombreuses,
ainsi qu’on pourra le voir tout au long de cet ouvrage.
La méconnaissance de ce qu’est un système, et notamment des rôles dévolus aux modules
opérationnels, est cause de nombreux déboires constatés dans les organisations actuelles.
b) Des modules pilotes
Ils prennent les décisions stratégiques et tactiques, et qui doivent faire en sorte de les faire
appliquer par les modules opérationnels. Pour prendre des décisions, les modules pilotes ont
besoin d’informations sur les conditions de l’activité du système qu’ils pilotent. Ces informa-
tions seront issues de la collecte des données, effectuée par les modules opérationnels qui sont
au contact de l’environnement tandis que les modules pilotes ne le sont pas.
c) Le système d’information
Il assure le couplage organisationnel entre les modules opérationnels et les modules pilotes.
Un de ses rôles essentiels est de maîtriser l’entropie dans le déroulement du processus de
croissance de l’organisation.
Le système d’information est donc un des trois types d’éléments composant tout système. Ce
concept n’est donc pas lié du tout aux outils informatiques. Il est fondamental dans une organisa-
tion, qui est un système vivant, donc à complexité croissante. En effet, c’est sur lui que repose la
maîtrise de l’entropie qui, par un effet dialectique, peut stopper le développement de l’organisation
et, à plus long terme, entraîner sa disparition.

12
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

2. L’organisation vue comme un système vivant et ouvert


La systémique a d’abord été utilisée en physique ou en biologie, avant d’être utilisée en gestion.
C’est pourquoi, pour comprendre les implications concrètes de l’affirmation : une organi-
sation est un système, il est commode de faire une comparaison avec un être biologique qui
est également un système vivant et ouvert.
L’exemple le plus facile à comprendre, car le plus proche de nous, est celui de l’être humain.
À partir de cette comparaison, nous pourrons définir quels sont les éléments composant un
système et qu’elles sont leur interaction, dans le cadre d’une organisation.
Nous analyserons le schéma suivant, afin de dégager :
– les caractéristiques essentielles d’un système vivant et ouvert ;
– les modes d’organisation permettant le développement et la vie de l’être vivant, au sein de
son environnement.
Nous en déduirons les règles similaires à implanter dans les organisations.
En effet, force est de constater que le fonctionnement des êtres biologiques évolués est globa-
lement plus satisfaisant que celui des êtres sociaux que sont les organisations. On peut donc
légitimement se dire qu’en tirant les enseignements des structures et du fonctionnement des
êtres biologiques, il devrait être possible d’améliorer le fonctionnement des organisations.
La transposition n’est cependant pas mécaniste, ainsi que nous allons le voir par la suite, car
les cellules d’un être biologique ne disposent pas de libre arbitre. Dans un être social, la
cellule de base est un être humain, qui peut décider de son comportement individuel.
L’ORGANISATION SYSTÈME VIVANT

Décision
élaborée
cerveau (MP)

Environnement

Décision
Communication réflexe
Avec l‘environnement Moelle épinière
Par les organes
des sens (MO)
Collecte
des données

Processus vitaux
Autorégulés
Décentralisation
Et gestion Le système
par exception d‘information,
système nerveux
Organisme de l‘enteprise

13
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

2.1 Les modules opérationnels : nos organes des sens


Pour agir et permettre l’interaction avec notre environnement, nous disposons des membres
et des organes des sens.
Ces éléments constituent nos modules opérationnels.
Leurs caractéristiques essentielles sont :
a) L’interaction avec l’environnement

EXEMPLE
Je veux réaliser une tarte aux pommes. Pour cela, je vais devoir me procurer les éléments nécessaires
dans mon environnement : farine, beurre, sucre, pommes et ustensiles de cuisine. Les ressources néces-
saires à la fabrication de cette tarte sont disponibles ou non, sous différentes formes, dans mon
environnement. Il se peut qu’au lieu de prendre tous les éléments de base pour fabriquer la pâte à
tarte, je me rende au supermarché voisin pour acheter un rouleau de pâte toute prête dans son
emballage sous vide. Une fois tous les ingrédients nécessaires regroupés, je vais pouvoir procéder à
leur transformation afin d’obtenir la tarte. Grâce à mes organes des sens (modules opérationnels), j’ai
donc transformé les ressources entrantes (les matières premières) en extrants (la tarte), en créant de la
valeur ajoutée par mon travail.

b) L’acquisition d’informations sur les conditions de l’environnement

EXEMPLE
En réalisant ma tarte aux pommes, j’ai collecté des informations sur l’environnement. Le prix des
pommes était peu élevé car je les ai trouvées en promotion à cause de la surproduction relative. J’ai
trouvé un nouveau packaging pour le sucre beaucoup plus facile d’utilisation. Je ne me suis pas méfiée
mais le couteau que j’ai utilisé pour éplucher les pommes était très coupant et je me suis blessée. Les
modules opérationnels que sont mes organes des sens, m’ont permis d’enregistrer toutes ces informa-
tions sur l’environnement. J’ai vu le prix des pommes, affiché dans le rayon. J’ai constaté de mes mains
la facilité d’ouverture de la boîte de sucre et je me suis coupé le doigt.

c) L’action, qui est orientée vers l’environnement et qui va influer sur lui

EXEMPLE
Cette tarte, une fois réalisée, va servir de dessert au prochain repas. Je l’ai réalisée pour me nourrir,
mais également pour la partager avec les convives de ce repas. Je porterai les épluchures des pommes
sur le compost.

2.2 Les modules pilotes et la décentralisation de la prise de décision


Nous prenons des décisions élaborées par le cerveau, qui est notre « direction générale »,
capable de prendre les décisions stratégiques qui orienteront notre avenir.
Mais toutes les décisions ne sont pas prises par la partie intelligente de notre cerveau, nos
petites cellules grises, comme Agatha Christie le fait dire à Hercule Poirot.
Nous possédons différents modes de décision, adaptés aux situations variées, qui néces-
sitent une prise de décision. Pour chaque type, nous disposons de modules pilotes adéquats.

14
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Pour informer les modules pilotes des conditions de notre environnement, nous disposons
d’un système nerveux qui permet de communiquer aux modules pilotes les informations
captées par les modules opérationnels.
Notre système nerveux constitue notre système d’information, permettant le couplage des
modules opérationnels et pilotes afin de maintenir l’intégrité de notre organisme, son
développement et la poursuite de nos objectifs.
On peut constater que nos modules pilotes sont structurés de manière à prendre les
décisions de façon la plus efficace possible.
a) Premier niveau de prise de décision : les décisions réflexes
■ La situation
Lorsqu’une décision doit être prise rapidement, dans la mesure où elle ne présente pas de
difficulté de choix, c’est un centre de décision décentralisé qui est chargé de la prendre, car
ce qui importe c’est la rapidité de réaction, fondamentale pour maintenir l’intégrité du
système.

EXEMPLE
Lâcher lorsque l’on a pris un objet brûlant. On ne pèse pas le pour et le contre. La question de la valeur
de l’objet qui risque de casser n’intervient pas dans la décision. De manière immédiate, en réaction à
la douleur de la brûlure, la main lâche l’objet. Si ce n’était pas le cas, le temps de réfléchir à la bonne
décision, il pourrait y avoir des dégâts irréversibles au niveau de la main par le contact prolongé avec
l’objet brûlant. Bien que les décisions de ce type soient prises de manière automatique, avec un circuit
court, il faut néanmoins noter que, sans le système nerveux qui transmet l’information comme quoi
l’objet est brûlant au centre de décision réflexe, il ne pourrait pas y avoir la réaction nécessaire. C’est
la sensation de douleur qui signale le phénomène et entraîne la prise de décision. Bien qu’il s’agisse
d’une décision réflexe, donc très simple, le centre de décision ne se situe pas au niveau de la main,
c’est-à-dire du module opérationnel. Il faut donc que l’information soit transmise rapidement au
décideur, afin qu’il prenne sa décision et déclenche l’action de la main.
Imaginons une personne ne disposant pas de terminaisons nerveuses dans la main. Le centre de
décision réflexe ne sera pas informé, puisque la sensation de douleur de la brûlure ne sera pas
ressentie. Quelques instants plus tard, en voyant sa main rougir et la peau faire des cloques sous l’effet
de la chaleur, la personne en déduira que le plat doit être chaud et le posera. La lacune au niveau du
système nerveux (ou si l’on préfère du système d’information de la personne) amène deux remarques.
Tout d’abord, lorsqu’un circuit nerveux spécialisé est inefficace, on finit tout de même par avoir une
information grâce à un autre circuit. On ne ressent pas la douleur au niveau de la main, mais la vue
permettra ultérieurement de transmettre une autre information.
Ensuite, le mécanisme de la prise de décision sera différent. Ce n’est plus le centre réflexe qui décide,
car il n’est pas informé par le circuit nerveux spécialisé. C’est le cerveau qui déduira, de l’information
transmise par la vue, qu’il y a une anomalie au niveau de la main, et que celle-ci doit être due à l’état
de chaleur du plat. En conséquence, la prise de décision est infiniment plus lente. Il faut attendre
que le phénomène ait créé une lésion détectable à l’œil pour entamer une réflexion, au niveau du
cerveau, amenant à décider de poser le plat. Cette décision n’étant pas réflexe, on va poser délica-
tement le plat sur une surface ne le mettant pas en danger. Ce faisant, tout ce temps perdu, à cause
de l’inefficacité du circuit nerveux spécialisé pour cette tâche, va entraîner une lésion irréversible de
la main ou tout au moins nécessitant des soins médicaux très longs et coûteux, afin de restituer à la
main son état normal.

15
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

■ Transposition des décisions réflexes à une organisation ?


Il faut chercher à définir des « réflexes organisationnels » et à déléguer la prise de décision
dans ces domaines aux acteurs directement concernés. Si on ne le fait pas, les échelons
supérieurs de la hiérarchie s’apercevront des problèmes plus tard, lorsque les conséquences
en seront dommageables.
Pour cela, il faut identifier les situations, qui peuvent être traitées de cette manière, définir
le rôle des acteurs et mettre en place la circulation des informations qui permettra leur mise
en œuvre.

EXEMPLE
Une règle de gestion prévoit, dans une entreprise industrielle, que les commandes ne peuvent être
saisies et honorées que dans la mesure où l’en-cours de crédit du client le permet.
En effet, saisir et valider une commande correspond à l’acceptation de celle-ci, c’est-à-dire à la création du
contrat de vente.
La personne en charge de la saisie des commandes doit appliquer cette règle. L’application informa-
tique qu’elle utilise pourra l’y aider en interdisant de valider une commande, si cette règle n’est pas
respectée. Il pourra y avoir à un échelon supérieur le directeur commercial, par exemple, qui aura le
droit de passer outre. Mais l’employé, en tant que module opérationnel, prendra ses décisions dans le
cadre d’un mécanisme réflexe, ce qui constitue un type de décision binaire.
En l’absence de l’instauration de cette procédure, le risque sera de constater que des commandes
ont été acceptées, qui ne correspondaient pas à la règle. Il se peut que ce fait ne soit découvert
que dans des situations de défaillance de règlement des factures. Cela sera défavorable pour
l’entreprise. Dans certains cas, la liquidation judiciaire du client par exemple, la conséquence de
l’inexistence de la décision réflexe entraînera des conséquences quasi irrémédiables pour l’organi-
sation.

En conclusion :
Les décisions de type « réflexes » sont binaires. Elles doivent être prises le plus vite possible,
donc le plus près de la source de l’information. Cela rend nécessaire que le système d’informa-
tion soit structuré de telle sorte que le décideur, qui est, en principe, le module opérationnel en
charge du sous-processus, soit informé sans délai, décide et déclenche immédiatement l’action
adéquate.
L’implémentation des décisions réflexes constitue un premier axe fonctionnel du système d’infor-
mation.

b) Deuxième niveau de prise de décision : la gestion de processus automatisés


■ La situation
Poussons plus loin l’investigation afin de déceler quelques mécanismes supplémentaires de
fonctionnement que nous pourrons ensuite transposer aux organisations.
Nous possédons des mécanismes de régulation, sous contrôles décentralisés tels que
l’homéostasie, qui maintient notre température à 37° plus ou moins 2/10e, quelle que soit la
température extérieure. La respiration, la digestion, la circulation sanguine, etc., sont
également des processus automatisés. Tant que les automates chargés de ces mécanismes de
régulation parviennent à assurer correctement leur fonction, c’est-à-dire à respecter les

16
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

objectifs qui leur ont été assignés, le module pilote supérieur, la partie intelligente de notre
cerveau, n’intervient pas. Par contre, lorsqu’il y a dysfonctionnement, le contrôle est passé
au cerveau afin qu’il mette en œuvre les décisions correctives qui s’imposent. Nous
pratiquons donc la gestion par exception. Mais cette méthode d’intervention n’est
possible que dans la mesure où le cerveau est informé des dysfonctionnements grâce à des
symptômes, qui jouent le rôle de signaux d’alertes. Pour prendre des décisions, il faut
donc que le module pilote soit informé. Être informé signifie disposer, d’une part, de
variables d’état permettant au module pilote de connaître le niveau de performance du
fonctionnement du système et, d’autre part, de variables d’alertes permettant de signaler
au module pilote les dysfonctionnements.

EXEMPLE
En cas de canicule, notre automate de régulation de l’homéostasie a des difficultés à nous maintenir
à 37°. Pour y arriver, il provoque le mécanisme de transpiration qui a pour but de refroidir la peau.
Mais, si la température extérieure est vraiment excessive, nous allons nous déshydrater. L’automate de
régulation de la température ne peut rien contre la déshydratation. Il faut que consciemment nous
décidions de la nécessité de boire pour nous réhydrater.
C’est donc la partie intelligente de notre cerveau qui doit intervenir. Pour cela, il faut qu’elle soit
alertée de l’incapacité de l’automate à poursuivre la régulation thermique dans les conditions
actuelles. Une information va être envoyée au cerveau sous forme, par exemple, de la sensation de soif.
Notre intelligence, « supérieur hiérarchique » de l’automate de régulation de la température, va inter-
venir pour corriger le problème et rendre la main à l’automate.
Mais il existe des cas où l’information alertant le cerveau n’est pas correcte ou inexistante, bébé ou
personne âgée, et cela peut entraîner de graves problèmes, voire la mort.

■ Transposition du mécanisme de régulation à une organisation ?


Les automates de régulation de notre organisme sont des sortes de cadres moyens,
échelons intermédiaires dans la hiérarchie. Ils disposent d’une responsabilité complète
sur un processus, avec un objectif à atteindre, caractérisé par un intervalle de valeurs
admises pour un ou plusieurs indicateurs. Il y a donc une décentralisation de la prise de
décision et une délégation de responsabilité concernant le processus, qui est donnée par
le cerveau, direction générale, à l’organe de contrôle, son subalterne. Celui-ci contrôle
cependant un processus vital qui demande une attention permanente ; mais si le cerveau
devait gérer ces processus, il n’aurait plus la possibilité de se consacrer à ses propres
tâches, qui sont liées à l’intelligence, c’est-à-dire à la capacité de création de solutions
nouvelles à des problèmes inconnus par la pratique du raisonnement analogique. Or, la
prise en compte de ces tâches est essentielle pour l’avenir de l’être, considéré dans sa
globalité. C’est ce qui va lui permettre de se développer à long terme et de s’adapter à
l’évolution de son environnement.

17
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

Deux principes à retenir peuvent se déduire de ce qui précède :


Énoncé du principe Mise en œuvre
Premier principe : la décentralisation est nécessaire. Dans une organisation, pour que la direction générale puisse se consacrer
à la prise de décision stratégique et à sa mise en œuvre, il lui faut décen-
traliser la prise de décision concernant les processus de l’activité courante
à des subalternes, qui disposeront d’une délégation de responsabilité
totale dans le cadre d’indicateurs permettant de contrôler qu’ils réalisent
l’objectif qui leur a été assigné.
Lorsque l’organe subalterne n’est plus en mesure de prendre en main sa tâche
correctement pour des motifs divers, le cerveau reprend le contrôle du processus
afin d’en rétablir le fonctionnement normal. Pour cela, des symptômes ont
permis d’informer rapidement le cerveau du dysfonctionnement du processus. Il
a donc pratiqué la gestion par exception, grâce aux mécanismes de contrôles
que constituent les indicateurs et d’alertes que constituent les symptômes qui lui
permettent d’être en permanence informé de la maîtrise du processus par son
subalterne.
Second principe : il faut disposer d’indicateurs La délégation de responsabilité n’est possible que si l’on dispose d’indica-
de la performance et des dysfonctionnements teurs de mesure de la performance et d’indicateurs d’alertes en cas de
de l’organe subalterne qui dispose d’une délégation dysfonctionnement. La direction générale pourra alors pratiquer effica-
de responsabilité. cement la gestion par objectifs et par exception, en intervenant à propos,
c’est-à-dire en cas de problème. Cela implique la mise en place d’outils de
contrôle permanent de la performance de tous les processus et de signaux
d’alertes, à déclenchement rapide en cas de problème. C’est ce que fait
notre système nerveux, c’est ainsi que doit être construit le système
d’information de l’organisation.

c) Troisième niveau de prise de décision : la prise de décision stratégique


■ La situation
Elle est le fait de la direction générale et engage l’avenir à long terme de l’organisation. Il en
est de même pour un être humain, qui décide du choix de ses études et de sa profession, de
son engagement à construire une famille, ou à la dissoudre.
Ces décisions demandent de prendre en compte de nombreux paramètres, de peser le pour
et le contre.
Afin de faire reculer l’incertitude qui entoure la prise de décision, il sera nécessaire de
s’informer. Il serait dangereux de décider d’entreprendre des études qui n’ont aucun
débouché. Plus pernicieux encore est de s’engager aujourd’hui dans une voie qui semble
porteuse d’emploi et qui se révélera, à plus long terme, totalement bouchée.
■ Transposition à l’organisation
Cette transposition est facile.
La prise de décision stratégique nécessite donc de disposer d’informations synthétiques, basées
sur de nombreuses données de départ, qui auront été compilées par le système d’information.
Dans ce domaine également, le système d’information possède un rôle essentiel.

18
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

2.3 Différenciation d’un système social par rapport à un système biologique


Ce qui différencie un système biologique d’un système social, c’est essentiellement le libre arbitre
des cellules qui le constituent. Dans un être biologique, chaque cellule joue le rôle pour lequel elle
est conçue, sauf en cas de maladie ou de désordre génétique.
Dans un être social, telle que l’entreprise, la « cellule » élémentaire est un être humain, donc un
système complexe en lui-même, dont les objectifs peuvent être différents de ceux de l’organisation.

Cette importante différence rend le fonctionnement de l’entreprise sujet à des conflits.


D’autre part, les décisions pour être transformées en action doivent être expliquées, voire
justifiées auprès des modules opérationnels.
Cependant, les principes de la systémique, nés en physique et appliqués à de nombreux
domaines, sont désormais applicables au domaine de la gestion des organisations.
Le fil conducteur consiste donc à essayer de tirer les enseignements des autres disciplines pour
structurer et gérer les organisations en appliquant les mêmes principes. Mais il faut prendre en
considération le fait que la nature sociale de l’organisation rend permanente la nécessité de gérer
les conflits d’objectifs et de finalités, entre l’organisation et ses éléments constitutifs. C’est ce qui
modifie fondamentalement la problématique et en fait un nouveau domaine d’investigation.
L’organisation sociale évolue dans un environnement complexe et mouvant.
Comme un être biologique, l’organisation est un système vivant. Cela implique un
processus qui, de sa naissance à sa mort, l’amène à se développer, puis à décliner et dépérir.
Mais, contrairement à un être biologique, pour une organisation, l’amplitude de sa durée de vie
n’est pas définie dans le cadre d’un intervalle assez précis. La phase de croissance de l’entreprise
peut s’arrêter momentanément, puis reprendre au cas où arrive une nouvelle équipe dirigeante
plus dynamique, cause interne, ou à l’apparition de nouvelles opportunités de l’environ-
nement ou d’un contexte économique beaucoup plus favorable, cause externe. Néanmoins,
l’être social qu’est l’organisation obéit aux mêmes lois du vivant qu’un être biologique. Dès
qu’elle n’est plus impliquée dans un processus de croissance, elle commence à régresser.
Par contre, la durée de sa période de croissance peut être très variable.
Elle est victime d’un taux de « mortalité infantile » très élevé : une proportion très impor-
tante d’entreprises qui se créent n’atteint pas les cinq ans.
D’autres existent depuis plusieurs siècles.
Autrement dit, pour éviter de décliner puis de disparaître, l’organisation est « condamnée »
à la croissance. Mais ce processus de développement va entraîner l’augmentation de la
complexité et son corollaire, le développement de l’entropie. De manière dialectique, le
processus de croissance contient sa propre négation, car l’entropie non maîtrisée va inverser
l’évolution de la croissance vers le déclin. Le seul remède au développement de l’entropie
sera l’évolution cohérente du système d’information par rapport au développement de
l’organisation, afin d’assurer la maîtrise de la complexité.
2.4 Structure de l’organisation en tant que système
Un système social, comme l’entreprise, est composé de ses trois types de modules, comme
tout système :
– les modules opérationnels, qui assurent l’activité du système dans le cadre de la structure
et interagissent avec l’environnement ;

19
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

– les modules pilotes, qui en définissent la finalité et la conduisent vers l’objectif ;


– le système d’information, qui assure le couplage entre modules opérationnels et
modules pilotes, en facilitant la prise de décision à tous les niveaux, en transmettant
les décisions prises pour exécution et en permettant de contrôler les résultats de
l’activité.
On peut tenter de structurer ce système social comme un être biologique de manière à
obtenir une qualité meilleure de son fonctionnement.

Objectifs visés par la vision de l’organisation en tant que système vivant et ouvert, tel un être biologique
Permettre la décentralisation des décisions répétitives.
Pratiquer la gestion par exception au niveau de processus vitaux, mais dont la régulation est automatisable.
Se doter d’un tableau de bord comportant à la fois des indicateurs de performances, qui mesurent de variables
essentielles, et des indicateurs d’alertes permettant la détection très rapide des dysfonctionnements dans les pro-
cessus auto régulés.
Faire reculer l’incertitude en fournissant une analyse des conditions de l’environnement, qui s’appuie sur des modèles
représentatifs de ses comportements possibles, pour étayer la prise de décisions stratégiques.

2.5 Éléments caractéristiques de l’organisation en tant que système


L’organisation, comme tous les systèmes complexes, possède les caractéristiques suivantes :
– le système, que constitue l’organisation, peut être délimité et identifié, par rapport à l’ensemble
des autres systèmes qui l’environnent ;
– l’organisation agit à travers ses modules opérationnels ;
– l’organisation doit posséder une structure, qui définisse le rôle de chacun ;
– l’organisation doit être informée et apprenante ;
– elle est douée de créativité ;
– elle a une finalité ;
– elle s’inscrit dans la dynamique.

a) Le système, que constitue l’organisation, peut être délimité et identifié,


par rapport à l’ensemble des autres systèmes qui l’environnent
La délimitation du système est assez souvent possible sans équivoque.
Néanmoins, aujourd’hui, les limites de l’organisation peuvent être floues et différentes
suivant le point de vue adopté.
Le point de vue économique peut être différent du point de vue juridique.

EXEMPLE
Deux entreprises peuvent être indépendantes juridiquement et être en relation de partenariat très
étroit dans le cadre d’un processus de fabrication. C’est le cas, par exemple, dans le secteur automobile
entre les constructeurs et les « équipementiers ». Le partenariat existera entre eux de la conception du
produit à sa fabrication. Cela les amène à échanger de nombreuses informations et donc à harmoniser
leurs systèmes d’information.

20
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Le point de vue des relations d’information peut différer du point de vue économique.
Ainsi, le concept de « supply chain management » implique que l’entreprise gère la chaîne
des informations du fournisseur de son fournisseur au client de son client.

EXEMPLE
Cela correspond bien aux préoccupations d’industrie telle que l’industrie alimentaire où les problèmes
de sécurité alimentaire nécessitent un contrôle depuis la production agricole (absence d’OGM,
problème de la dioxine dans le poulet, etc.) jusqu’au consommateur final (problème de listéria ou de
salmonelle dans les fromages ou les produits charcutiers).

b) L’organisation agit à travers ses modules opérationnels


Ceux-ci interviennent dans les processus de transformation des flux entrants en flux sortants,
qui constituent l’activité de l’organisation. En tant qu’être social, l’organisation, dont la finalité
est de créer de la valeur ajoutée, prend les ressources à transformer dans son environnement. Il
peut s’agir de ressources matérielles, financières ou humaines. Mais la poursuite de sa finalité
entraîne qu’elle doit restituer à l’environnement son produit avec une certaine valeur ajoutée.
Les modules opérationnels de l’entreprise sont :
– la force de vente, qui est le service commercial en prise directe avec le marché ;
– les acheteurs et approvisionneurs, qui fournissent les ressources matérielles à transformer ;
– la fabrication, dans le cas d’une entreprise industrielle, qui transforme les matières
premières en produits finis ;
– les recruteurs, qui sont les personnes du service gestion des ressources humaines, qui
recherchent le personnel sur le marché du travail ;
– les personnels des services financiers, qui gèrent la trésorerie, etc.
c) L’organisation doit posséder une structure, qui définisse le rôle de chacun
Elle devra disposer :
– de méthodes réflexes ;
– de mécanismes de régulation, qui automatiseront les fonctions vitales mais répétitives, et
permettront de lutter efficacement contre la tendance au désordre, qui accompagne
inévitablement la croissance ;
– d’organes de prise de décision stratégique.
Elle organise et coordonne ses décisions d’action, grâce à cette structure définie, à la
standardisation des processus de décision et d’action, à la formalisation des procédures à
appliquer dans chacune des situations identifiables.
d) L’organisation doit être informée et apprenante
Elle s’informe sur les conditions internes et externes de son fonctionnement, afin de décider
de son comportement à venir et de corriger les écarts éventuels entre sa vision du réel et la
réalité, perçue à travers les résultats obtenus de ses actions antérieures.
Elle mémorise les informations qui la concernent, afin d’apprendre et d’enrichir une base
de connaissances qui constitue son savoir et son savoir-faire. Cela lui permettra d’agir de
manière de plus en plus efficace, mais elle devra savoir lutter contre l’oubli qui accompagne
souvent le « turn-over », c’est-à-dire le départ des salariés.

21
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

e) Elle est douée de créativité


Cela signifie qu’elle est en mesure de créer des solutions possibles à des problèmes nouveaux, par
application du raisonnement analogique et grâce à l’utilisation de sa base de connaissances.
f) Elle a une finalité
La poursuite de cette finalité justifie globalement son action. L’entreprise recherchera la
rentabilité. D’autres organisations proches, telles que les associations, auront une autre
finalité : par exemple, apporter un service à une communauté d’individus. Une finalité n’est
pas un simple objectif, c’est une raison d’être.
g) Elle s’inscrit dans la dynamique
Elle s’inscrit dans un mouvement de développement au sein d’un environnement de plus en
plus mouvant et incertain. L’aspect dynamique de la vie de l’organisation est inéluctable,
puisque sa survie à long terme est liée à son développement. Cette dynamique a toujours
existé, mais elle était autrefois moins sensible. Ce qui est différent de nos jours c’est l’accélé-
ration du mouvement et la vitesse croissante du changement. Cela ne permet plus aux
dirigeants de s’appuyer uniquement sur la réalité passée, même à court terme, pour étayer
leur prise de décision. Cela renforce l’importance de la possession d’un système d’infor-
mation adéquat et évolutif.
2.6 Fonctionnement d’un système
L’environnement actuel se caractérise par :
a) L’incertitude et la mouvance
L’organisation ne peut pas considérer que les conditions d’obtention des ressources qui lui
sont nécessaires et de cession de ses produits présentent une certaine stabilité dans le temps.
Au contraire, on constate à la fois une accélération du changement et un caractère très
aléatoire des chemins qu’il emprunte. Par exemple, on peut constater dans l’environnement
économique actuel des inversions de conjoncture économique en quelques semaines. Les
anticipations des marchés, dont l’ampleur est favorisée par les médias, entraînent des
réactions inattendues, voire opposées à toute attente.

EXEMPLE
Au moment des premières crises pétrolières, on s’attendait dans l’industrie automobile à un
engouement pour les petites voitures. Cela n’a pas été le cas.
Les anticipations des acteurs économiques peuvent provoquer la croissance (par exemple, le
phénomène du « Mondial 98 ») ou la récession (par exemple, la crainte du chômage ou d’une crise
boursière mondiale).

b) Une variation rapide de la variété


Les volumes d’activités sont soumis dans presque tous les secteurs à de fortes variations, sous
l’impact de phénomènes conjoncturels ou saisonniers. Le niveau de ressources à mettre en
œuvre d’une période à l’autre est donc très différent, d’où la recherche de flexibilité au niveau
des conditions d’obtention des ressources de différentes natures, et notamment du travail.
c) Une variation rapide de la complexité
L’entreprise, pour maintenir ses positions concurrentielles, est contrainte de s’attaquer à de
nouveaux marchés et d’innover dans de nouvelles techniques ou de nouveaux produits.

22
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Cela devient un processus permanent alors qu’antérieurement il s’agissait d’opérations


ponctuelles. Cette innovation permanente nécessite une réaffectation des ressources en
continu. Mais cela exige également une organisation adéquate en terme de structures et de
méthodes de gestion pour conduire en permanence des projets en parallèle.
Cela amènera l’organisation à adopter de nouvelles méthodes, telle que la méthode projets,
et une nouvelle structure, telle que la structure matricielle. Part. 2

d) Une variation de la mobilité


Celle-ci se caractérise par des cycles de vie des produits raccourcis par rapport au passé.
Pour rester compétitif, il faut donc être le plus rapide à mettre de nouveaux produits sur le
marché. Ceux-ci doivent être rentabilisés très vite, puisque :
– leur durée de vie est plus courte. On ne peut donc remettre à plus tard la rentabilisation
d’un produit. Il faut réussir à le positionner sur le marché immédiatement ;
– les conditions de la concurrence sont plus virulentes. Lorsque le produit arrive à maturité,
la concurrence étant plus vive, cela nécessite une réorientation de la gestion du produit.
C’est ce qu’exprime l’usage des méthodes telles que le « redesign to cost ».

Maîtriser les nouvelles conditions de l’environnement du fonctionnement du système qu’est l’orga-


nisation passe par le renforcement de l’importance du rôle du système d’information, qui doit être
parfaitement adapté en permanence aux besoins.

La maîtrise des contraintes précédemment exposées, et qui sont relativement nouvelles


pour les organisations, exige un changement de rythme de fonctionnement de l’organi-
sation, de manière à raccourcir son temps de réponse par rapport aux sollicitations de
son environnement. Cette nécessité d’une remise en cause organisationnelle, afin de
créer les conditions internes favorables pour que l’entreprise s’adapte aux mutations de
son environnement, est présente notamment dans la démarche du « ré-ingénierie des
processus ».
Ce n’est qu’en obtenant un meilleur couplage entre les modules opérationnels et pilotes de
l’organisation, notamment par une circulation de l’information plus rapide et plus fiable,
que l’on peut obtenir cette accélération du fonctionnement. Or, cela exige efficacité et
évolutivité de son système d’information.

2.7 Conditions d’un couplage satisfaisant entre modules opérationnels et pilotes

Le couplage, entre modules opérationnels et modules pilotes, ne peut être satisfaisant que :
– si le système d’information possède une complexité suffisante ;
– s’il possède une mobilité suffisante, c’est-à-dire une capacité d’évolution aussi rapide que
l’exigent les conditions de l’environnement.

a) Le système d’information possède une complexité suffisante


Cela signifie que le système d’information possède une complexité supérieure à celle du
système à contrôler. Rappelons que la complexité se mesure par le nombre d’interactions
entre les éléments que le système intègre et doit gérer.

23
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

EXEMPLE
Imaginons que le système d’information d’une entreprise réalise la gestion commerciale de la
commande du client au règlement de la facture. Si le système d’information est incapable de relier un
règlement à plusieurs factures ou une multiplicité de règlements à une facture, alors que ces cas se
présentent fréquemment dans la réalité, sa complexité sera insuffisante par rapport au réel. En consé-
quence, il ne permettra pas de gérer les imputations des règlements sur les factures de manière satis-
faisante. Il ne permettra donc pas d’exercer le contrôle nécessaire sur les créances clients. Il faudra
modifier manuellement les informations, les cumuler ou les éclater à la main et de ce fait perdre la
traçabilité des règlements pour pouvoir les imputer dans le système.

b) Le système d’information possède une mobilité suffisante,


c’est-à-dire une capacité d’évolution aussi rapide que l’exigent
les conditions de l’environnement
L’organisation est intégrée dans un processus dynamique qui l’amène à évoluer sans cesse et
de plus en plus vite afin de s’adapter au contexte de son environnement. On sait que,
pour un être vivant, ne pas s’adapter aux modifications de son environnement, quelle
que soit la raison des mutations de celui-ci, remet en cause sa survie. Le système
d’information constitue l’organe, qui permet de prendre conscience et de mesurer les
évolutions de l’environnement ; il est nécessaire qu’il évolue au même rythme que
l’entreprise. Par comparaison, on pourrait dire qu’une évolution insuffisante du
système d’information de l’organisation la mettrait dans la même situation qu’un être
humain dont le système nerveux n’aurait pas suivi son processus de croissance. Son
système nerveux s’arrêterait, par exemple, au coude ou au genou. Il pourrait donc subir
toutes sortes d’accidents au niveau des mains ou des pieds, sans pouvoir intervenir
rapidement en cas de modification des conditions de l’environnement, car son cerveau
n’en serait pas informé rapidement, fautes des capteurs et des circuits de transmission
nécessaires. La mobilité de l’organisation n’est donc possible qu’à travers l’évolutivité
de son système d’information.

Tout ce qui précède permet de montrer la place, le rôle et les qualités du système d’information
dont l’organisation a besoin. Les principes, établis dans le cadre des concepts de la systémique,
permettront de définir et de justifier une manière d’utiliser les techniques informatiques disponi-
bles, tant en ce qui concerne les matériels que les logiciels, pour doter, en permanence, l’organisa-
tion du système d’information dont elle a besoin. Elles permettront également de fournir un cadre
conceptuel aux choix à opérer entre solutions techniques concurrentes, dans une organisation
donnée à une époque donnée.

2.8 L’utilisation de la modélisation et de la simulation


L’existence d’un système d’information conforme aux besoins de l’entreprise va permettre
aux modules pilotes de mettre en œuvre deux méthodes essentielles à la gestion des organi-
sations contemporaines : la modélisation et la simulation.

24
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

a) La modélisation
La modélisation permet de faciliter la prise de décision.
Rappelons les phases de la prise de décisions stratégique selon H. Simon.
L’analyse IMC (Intelligence – Modélisation – Choix) de H. Simon montre que la démarche de prise
de décision se déroule en trois phases :
– intelligence du problème ;
– modélisation des solutions possibles ;
– choix de la solution à mettre en œuvre.

La modélisation consiste à construire une représentation schématique de la réalité, de


manière à être capable d’en étudier le fonctionnement et d’en prévoir le comportement.
La modélisation fait partie du mécanisme de prise de décision au sein du système qu’est
l’organisation.
■ Intelligence du problème à résoudre
Il s’agit de la faculté de comprendre un problème. Le raisonnement analogique, c’est-à-dire
l’intelligence ou faculté d’adaptation, permettra de concevoir les éléments d’une situation
réelle nouvelle et de comprendre le problème qu’elle pose à l’organisation.

EXEMPLE
Le gouvernement français a instauré les 35 heures. Cette situation nouvelle pose des problèmes aux
organisations. Cependant, elle ne pose pas le problème de manière identique à une industrie,
confrontée à la concurrence mondiale et aux délocalisations dans les pays en voie de dévelop-
pement, ou à une entreprise du secteur des services où le coût du travail représente au moins les
deux tiers de ses charges. La problématique n’est pas la même pour un hôpital public, qui tarifie à
l’acte médical, et pour une entreprise sur le secteur concurrentiel.

■ Modélisation des solutions possibles


Cela va constituer une démarche structurante, qui vise à représenter schématiquement les
caractéristiques essentielles du système étudié et ses mécanismes : structures causales,
processus d’effet de retour, etc.
Il s’agit de comprendre le comportement du système concerné pour prévoir son interaction
possible avec l’organisation, afin de rechercher les solutions envisageables au problème
perçu et de prendre une décision pertinente, donc efficace dans le contexte.

EXEMPLE
Pour reprendre l’exemple précédent, on modélisera l’incidence sur le coût de revient des produits ou
des services de la mise en place des 35 heures. Il sera alors possible d’étudier les solutions de compen-
sations de l’augmentation des coûts, soit par la hausse du prix de vente au client, soit par l’augmen-
tation de la productivité, soit par une meilleure organisation permettant de réduire les coûts parasites.

■ Choix de la solution à mettre en œuvre


Le modèle élaboré ayant montré le fonctionnement prévisible du réel et les solutions
envisageables pour résoudre le problème perçu, la décision relève d’un choix entre les diffé-
rentes alternatives qu’il aura permis éventuellement d’évaluer.

25
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

EXEMPLE
Pour terminer l’exemple précédent, si l’entreprise est une industrie, l’augmentation des coûts de
revient, liée à une augmentation d’environ 11 % du taux de salaire horaire, correspondra, compte tenu
de la structure de ses charges, à 3 % d’augmentation du coût. C’est au minimum ce qu’elle gagne
chaque année en productivité. Elle décidera d’être attentive à contrôler l’obtention rapide de ce gain
de productivité, afin de garantir son taux de marge.
Dans le cas d’une entreprise de service, les gains de productivité sont souvent plus difficiles à obtenir
et moins importants. La structure des coûts est plus défavorable. On peut imaginer que le coût de
revient augmente de 8 % à la suite de l’augmentation du taux de salaire de 11 %. Si cette entreprise
se trouve dans un secteur concurrentiel ou dont les tarifs sont réglementés, elle ne pourra pas réper-
cuter son augmentation de coût de revient sur son prix de vente. Il lui faudra donc faire la chasse aux
coûts parasites, liés à la non-qualité et à la désorganisation.
b) La simulation
Grâce à l’existence de la démarche de prise de décision précédente au sein d’un système, on
dispose d’un modèle représentatif du fonctionnement de l’environnement dans lequel on
s’inscrit et de son interaction avec l’organisation. Si ce modèle est conçu de telle sorte que
l’on puisse le faire fonctionner de manière dynamique, à partir de scénarios différents, on
pourra simuler ses réactions à certains facteurs externes de façon à étayer la prise de
décision. Cela évitera un certain nombre d’erreurs d’appréciation en vraie grandeur dont
les conséquences sont coûteuses, voire fatales.
Cette méthode est utilisée dans la gestion prévisionnelle mais, pour être efficace, elle doit
être intégrée au système d’information, qui pourra à la fois l’alimenter en données et implé-
menter le modèle de fonctionnement.
D’artisanale et ponctuelle, cette méthode de gestion, qui s’appuie sur les principes de la
systémique, va devenir générale et permanente.
3. L’organisation, ensemble de processus en interaction
dans un système global
La vision systémique de l’organisation, qui est commune au domaine de la gestion des
systèmes d’information et à celui de la gestion de la qualité, s’appuie :
■ Sur une vue globale de l’organisation
Cette approche globale du système est nécessaire puisque le tout est plus que la somme des
parties.
■ Sur une décomposition par processus
Le système sera représenté sous forme de processus et non de services. Rappelons qu’un
processus est un enchaînement de tâches menant à un objectif et déclenché par un
événement extérieur. Les processus possèdent des points d’ancrage ou d’interaction entre
eux. Cette représentation est cohérente avec le concept de système, puisqu’elle offre une
vision de la structure des éléments en interaction dans leur activité et au sein d’un tout.
Résultats de l’approche systémique
Représentation de l’activité du système.
Prise en compte de la globalité avec l’interaction entre les processus.
Prise en compte de l’interaction avec l’environnement.
— comme facteur déclenchant de certains processus ;
— comme fournisseur de ressources pour le déroulement des processus de transformation d’intrants en extrants.
Prise en compte de la structure logique du système, lui permettant de mener à bien son activité finalisée.

26
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

On retrouve donc dans cette représentation, qui est incluse également dans la norme
ISO 9000 version 2000 concernant la gestion de la qualité, tous les éléments de la définition
du concept de système.
Il faut remarquer que cette représentation de l’organisation implique qu’elle soit adaptée :
■ À la nature de l’activité de l’organisation
Celle-ci déterminera les types de processus à mettre en œuvre. On ne trouvera pas les mêmes
processus dans une industrie et une entreprise de prestations de services, par exemple.
■ À la taille de l’organisation
Celle-ci déterminera le découpage des processus. Dans certains cas, il faudra décomposer le
processus production d’une industrie en plusieurs processus pour tenir compte de la mise
en œuvre de métiers différents.
■ Aux méthodes de gestion que les dirigeants veulent mettre en œuvre
Celles-ci influeront sur le sens de circulation des flux et, par conséquent, sur l’enchaî-
nement des processus.
Elles auront également un impact sur les données, qui seront à considérer comme perti-
nentes pour la prise de décision.
Les remarques précédentes démontrent que la modélisation du système global, fondée sur
l’interaction des processus, ne peut être un schéma général, valable pour toutes les organi-
sations, en tous lieux et en tous temps.

EXEMPLE

VISION SYSTÈMIQUE GLOBALE, ENSEMBLE DE PROCESSUS EN INTERACTION


DANS UNE INDUSTRIE AGROALIMENTAIRE

PRO01
R&D
Revue de
Contrat + PRO09
Achats Comptabilité

PRO02
EDI Suivi de
Commande PRO10
Ressources
Humaines
PRO04
Production

EDI PRO03
PRO11 PRO05
Approvision-
Groupware Maintenance
nement

PRO07 PRO08 PRO06


Système Flux Réclamation
EDI
Doc qualité Logistiques Client

27
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

Le schéma précédent représente la vision globale d’une industrie agroalimentaire où l’on cherche à
implanter une méthode de gestion en flux tirés et tendus. Dans ce cadre, les flux seront orientés de
l’aval vers l’amont.
On trouve deux types de processus :
– les processus d’activité de transformation, gérés par les modules opérationnels, constitués en groupes
de travail, qui sont en vert sur le schéma ;
– les processus supports, pris en charge par des services généraux ou externes, qui sont en gris sur le
schéma.
Cette représentation correspond à une industrie agroalimentaire dans le contexte de l’environnement
contemporain, en France notamment, où il existe une préoccupation importante de gestion de la santé
publique et de prévention des risques alimentaires.
PROCESSUS PRO01 : RECHERCHE & DÉVELOPPEMENT – ACHATS
Dans cette activité, aujourd’hui et dans notre pays, la plupart des produits sont commercialisés par les
enseignes de la grande distribution, qu’ils soient à la marque de ces distributeurs ou à la marque du
fabricant.
L’élaboration d’un nouveau produit est donc encadrée par un cahier des charges très strict, avec
notamment des obligations qui concernent :
• les matières premières. La plupart des enseignes exigent que les produits qu’elles commercialisent,
notamment les produits à leurs marques, ne contiennent ni OGM, ni substance à risque, par exemple
allergisante. Elles exigent une traçabilité amont totale sur ces facteurs de risques. A contrario, elles
exigent l’utilisation de certains types de matières premières, comme des variétés ou des appellations
d’origine contrôlée, qui leur permettront de différencier leurs produits.
• les emballages : le packaging des produits de consommation courante, distribués en libre-service,
joue un rôle primordial. Il doit faciliter l’acte d’achat en permettant l’identification rapide du produit,
ce qui implique un type d’emballage et un volume qui correspondent au modèle attendu par le
consommateur, c’est-à-dire au produit de référence du marché à ce moment-là, et un graphisme qui
permette de le différencier des autres produits. Cela entraîne l’abondance d’innovation dans le
packaging, qui a une durée de vie très courte par rapport à la formulation du produit en lui-même.
• la gamme de produits, qui tend à se renouveler et à s’élargir de plus en plus vite.
Le processus de Recherche & Développement met en œuvre, dans une industrie de processus comme
l’agroalimentaire, à la fois :
– des techniques de laboratoires en ce qui concerne la formulation du produit. Ces méthodes
s’appuient sur des principes chimiques, organoleptiques et physico-chimiques ;
– et des techniques de marketing, de merchandising et de conception graphique en ce qui concerne le
packaging.
Les contraintes du cahier des charges, exposées ci-dessus, entraînent peu de liberté dans la phase de
conception quant au choix des matières premières. Une fois celles-ci définies, dans la mesure où la
composition doit figurer sur l’emballage, il ne sera plus possible de modifier la composition, sauf à
modifier l’emballage. Modifier l’emballage représentant un risque économique et un délai important,
la composition d’un produit ne variera guère.
Cette réalité de la conception du nouveau produit entraîne que le processus achat, dont la mission est
de référencer les fournisseurs et les produits qui leur seront achetés, est totalement dépendant du
processus Recherche et Développement.
Ce processus est néanmoins très important puisque les éléments composant le produit sont contrac-
tuels et que le fait de ne pas s’y conformer peut entraîner des poursuites judiciaires pour l’entreprise.

28
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

PROCESSUS PRO02 : SUIVI DES COMMANDES CLIENTS


Les clients, qui sont les distributeurs, vont passer commandes en fonction des référencements qu’ils
auront effectués, aux conditions commerciales de la charte tarifaire qu’ils auront négociée. La plupart
des enseignes exigent actuellement de pouvoir passer leurs commandes par EDI (échanges de données
informatisées) ce qui permet de gagner du temps et d’éviter des erreurs de saisie. Les méthodes
relatives à la gestion de ce processus ne seront donc pas choisies librement par l’entreprise, mais en
grande partie imposées par ses clients. Néanmoins, actuellement clients comme fournisseurs ayant
pour objectifs de réduire les stocks, la gestion des flux de l’aval vers l’amont s’impose.
Les produits qui seront commandés par les clients vont correspondre à ceux qui auront été formulés
dans le processus précédent. Afin d’avoir une fiche produit à jour au bon moment, la coordination des
informations concernant le produit sera assurée par le chef de produits, qui a un rôle important dans
ce type d’activités.
PROCESSUS PRO04 : PRODUCTION
Le portefeuille des commandes des clients, qui sont cadencées sur la saison, notamment pour les
produits à la marque du distributeur mais également pour les produits à la marque du fabricant dans
le cadre des accords commerciaux ayant abouti à la charte tarifaire, permet de planifier la production.
Pour cela, il faut disposer des nomenclatures et gammes de fabrication des produits issus du processus
recherche et développement et du portefeuille de commandes des clients.
Gérer la production nécessite dans cette activité de prévoir d’abord le planning des lignes de condition-
nement, qui constituent le goulot d’étranglement. On déduira le planning de la préparation des
mélanges de celui-ci.
Le planning de conditionnement va entraîner à la fois l’ordonnancement des équipes de travail sur les
machines et un impact sur le processus Maintenance.
PROCESSUS PRO05 : MAINTENANCE
En fonction du planning de production, le service maintenance va devoir ajuster son planning pour
prendre en main ses différentes missions. En effet, le service maintenance doit à la fois : régler les
machines en fonction du planning de fabrication, insérer ses tâches d’entretien et de maintenance
préventifs, lors des temps d’inutilisation des différentes machines, être prêt à réparer en cas de pannes
les lignes en production, afin de bloquer le moins longtemps possible la fabrication.
PROCESSUS PRO03 : APPROVISIONNEMENT
La planification de la production va permettre de connaître les besoins en matières premières et embal-
lages et de passer les commandes aux fournisseurs, conformément aux données d’achats définies dans
le processus 1.
On aura de plus en plus recours à l’EDI pour échanger avec les fournisseurs, comme avec les clients, et
pour les mêmes raisons.
PROCESSUS PRO08 : FLUX LOGISTIQUES
Ce processus peut être en partie géré de manière interne et en partie de manière externe. En ce qui
concerne le stockage et la livraison des produits finis et le stockage et la mise à disposition des
matières et emballages, la gestion sera le plus souvent interne. Généralement, la phase transport,
depuis le fournisseur ou vers le client, fera appel à des prestataires extérieurs. Cependant, la maîtrise
du processus incombe au fabricant. Il doit vérifier la qualité et la conformité de ce qui lui est livré par
les fournisseurs et s’assurer que la livraison de ces clients est réalisée de manière conforme également.
Les processus support peuvent être en partie alimentés de manière automatique par les processus
opérationnels.

29
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

C’est le cas du processus Ressources humaines qui prend en compte les besoins de la production et qui
reçoit de ce processus les informations nécessaires à l’établissement de la paie notamment.
C’est aussi le cas de la comptabilité où se déverseront de manière automatique les informations
provenant de la gestion des ventes, des achats, de la paie et de la maintenance.
En ce qui concerne les deux derniers processus support figurant sur le schéma, ils fournissent un cadre
procédural au fonctionnement de l’ensemble. Le processus « groupware » permet de définir les droits et
obligations des opérateurs sur l’information manipulée dans les processus. Le processus « système
documentaire qualité » permet de gérer les procédures de travail définies pour que les processus soient
pris en compte conformément aux règles définies par l’organisation.
Ce schéma permet donc de présenter une vision globale et logique de l’interaction des différents
processus qui doivent être mis en œuvre pour mener correctement l’activité de l’entreprise.
Il correspond à la logique de l’enchaînement des flux de toutes natures et, notamment, des flux d’infor-
mations. Il permettra de comprendre comment structurer le système d’information, car celui-ci doit
permettre le fonctionnement global et l’interaction schématisés ci-dessus, pour satisfaire les besoins de
cette organisation.

section 2
place et rôle du système d’information
au sein du système entreprise
1. Vision statique : le système d’information, système nerveux
de l’organisation
1.1 Rôle du système d’information
De ce qui précède, il ressort que le système d’information constitue :
– l’instrument du couplage entre modules opérationnels et modules pilotes ;
– la mémoire de l’organisation ;
– l’instrument de la mise en forme des données.

a) L’instrument du couplage entre modules opérationnels et modules pilotes au


sein de l’organisation
L’efficacité de la prise de décision et la rapidité de la réaction aux modifications des condi-
tions de l’environnement, dans tous les domaines, dépendent de la qualité de ce couplage en
terme :
– de rapidité de transmission de l’information ;
– de fiabilité des informations transmises, non-déformation par des bruits parasites ;
– de complétude de l’information. Il ne doit pas y avoir d’omission dans la transmission de
données ;
– d’adéquation de l’information transmise par rapport aux besoins du destinataire. Chaque
destinataire de l’information aura des besoins caractérisés par sa position hiérarchique et
son rôle fonctionnel dans l’organisation.

30
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

b) La mémoire de l’organisation
Une entreprise qui perd sa mémoire perd son histoire, son savoir et son savoir-faire.
L’amnésie est aussi désastreuse chez un être social que chez un être humain. La créativité,
permettant de résoudre les problèmes étant fondée sur le raisonnement analogique, il est
très important de capitaliser ses connaissances pour accroître son potentiel, comme le fait le
cerveau humain. Malheureusement, de nombreuses organisations ne sont pas structurées
pour prendre en main correctement cette fonction de mémorisation, qui nécessite le
stockage des informations mais également leur mise à disposition en cas de besoin.
c) L’instrument de la mise en forme des données
Pour que chacun dans l’entreprise possède l’information adéquate au bon moment, le
système d’information doit non seulement faire circuler les données, mais les mettre en
forme, conformément aux besoins de chaque destinataire. L’adéquation de l’information au
destinataire doit prendre en compte sa position et son rôle dans l’organisation. Cela permettra à
chaque acteur de répondre aux types de questions qu’il rencontre dans l’exercice de son poste de
travail au bon moment.
La relation complexe entre information et organisation apparaît donc fondée sur un
rapport dialectique. L’information permet d’informer l’organisation. L’organisation
progresse et apprend. Elle va formuler de nouvelles demandes, qui vont permettre
d’organiser l’information et d’approfondir le système d’information. On entre ainsi dans
une spirale de progrès mutuels, lorsque l’organisation s’approprie le système d’information
et lui renvoie de nouvelles demandes. Malheureusement, cette spirale peut fonctionner
également de manière négative, lorsque le système d’information est trop éloigné des
besoins de l’organisation ou lorsque l’organisation refuse de se l’approprier. Cette relation
dialectique complexe entre organisation et système d’information correspond au concept
de paradigme inforgétique de Jean-Louis Le Moigne.
1.2 Caractéristiques du système d’information
La structure des informations, présentée ci-dessous, se compose de plusieurs axes :
– les informations représentations des flux manipulés par les modules opérationnels, qui corres-
pondent aux données réelles ;
– les informations traitements des flux, par les applications opérationnelles ;
– les informations d’aide à la décision, respectant le niveau hiérarchique et l’angle de vue du desti-
nataire du résultat ;
– les informations concernant les objectifs assignés, lors de la démarche budgétaire, ou informa-
tions prévisionnelles ;
– les informations concernant les décisions prises par les modules pilotes ;
– les informations expression des décisions prises par les modules pilotes, afin de permettre les
actions correspondantes ;
– les informations informelles, non intégrables dans le système d’information.

Le schéma ci-dessous montre les différentes interactions à mettre en œuvre au sein du


système d’information, afin qu’il ait la possibilité de satisfaire les besoins de l’organi-
sation.

31
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

STRUCTURE STANDARD DE TOUT SYSTÈME D’INFORMATION

Modules Pilotes (MP)

Axe 4 Informations décisions


Axe 3 entrées dans le système

Objectifs : inclus
dans le budget Informations d’aide
Données prévisionnelles à la décision
adaptées au niveau Inform ations
hiérarchique : à caractère
respect de l’angle informel
Axe 5
de vue du sujet non
et zoom sur les intégrable
informations au système
d’inform ation

Système d’information (SI)

Informations Axe 7
Informations expressions
Axe 1 traitements des décisions
Outil de contrôle : Informations des Modules
des flux :
calcul et analyse représentations des flux Pilotes pour action
applications
des écarts entre manipulés par les MO opérationnelles
réalisation et objectifs, Données réelles
tableau de bord :
variables d’état Axe 2
Axe 6
et alertes
Flux entrants de Flux sortants de
l'environnement Modules opérationnels (MO) l'environnement

a) Axe 1 : informations représentations des flux manipulés par les modules


opérationnels, qui correspondent aux données réelles
L’action sur les flux matériels, monétaires ou humains entrants, réalisée par les modules
opérationnels pour les transformer en flux sortants s’accompagne de flux d’informations
ou données, que les modules opérationnels (MO) doivent collecter pour les entrer dans le
système d’information.
Ces informations représentent les divers flux, en nature et en débit.

EXEMPLE
Lorsqu’un client passe une commande, les opérations de suivi de celle-ci nécessiteront de connaître
l’adresse de livraison et de facturation, la nature des produits, les quantités commandées et les prix
négociés avec le commercial de l’entreprise.

32
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Les modules opérationnels auront donc pour tâche de permettre au système d’information
l’acquisition immédiate et complète de ces flux de données. Cette acquisition devra avoir recours
aux techniques adéquates pour que l’entreprise obtienne les informations dans les délais requis.

EXEMPLE
Dans une entreprise de vente par correspondance, on propose au client une livraison en 24 heures.
Il faut une transmission des données de la commande par un système de télécommunication, qui évite
la saisie des informations. Mais il faut aussi pouvoir contrôler immédiatement, par des moyens téléma-
tiques, la solvabilité du client. Par exemple, s’il règle avec une carte bancaire, il faut obtenir l’autori-
sation de débit du compte avant la livraison.

b) Axe 2 : informations traitements des flux : applications opérationnelles


Le système d’information va permettre de traiter les flux d’informations volumineux et
répétitifs, qui sont liés à la transformation des flux entrants en flux sortants par les modules
opérationnels.

EXEMPLE
Le système d’information permettra, à partir des commandes des clients, d’établir les bons de livraison
et les états de préparation des colis, les factures, les relances en cas d’absence de règlements dans les
délais prévus, etc.

Cette partie des fonctions du système d’information constituera les applications opération-
nelles du système informatique de gestion.
Ces applications permettront :
■ De décharger les MO de traitements longs et fastidieux, également sources d’erreurs

EXEMPLE
Dans la plupart des organisations, on ne peut imaginer aujourd’hui réaliser les factures manuellement. L’heure
de travail est très coûteuse. Il faut facturer au plus vite compte tenu des délais de règlement et du coût financier
que représente le cycle d’exploitation. Il faut éviter les erreurs conformément à la politique de qualité.

■ D’implémenter dans les applications opérationnelles


– les règles de gestion de l’organisation, notamment celles de type décisions réflexes ;

EXEMPLE
On peut imaginer que le contrôle de l’en-cours autorisé du compte client, avant validation de la
commande, soit rendu automatique dans l’application opérationnelle qui permet de gérer le suivi des
commandes des clients. Dans ce cas, l’automatisme correspondant à la décision réflexe s’imposera à
l’employé qui gère la prise de commande. Par contre, il faudra prévoir qu’un acteur ayant une position
hiérarchique supérieure puisse passer outre et déverrouiller le blocage en cas de besoin.

– le contrôle des droits et obligations des acteurs des groupes de travail (groupware), pour
aider à la formalisation des processus ;

EXEMPLE
L’application pourra vérifier les droits attribués à l’acteur connecté pour lui permettre ou lui interdire
certaines fonctions, par rapport à la définition de son poste de travail. Ainsi, l’acteur qui est respon-

33
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

sable de la saisie des commandes, ne devrait pas pouvoir aller modifier le dossier du client, même s’il
a constaté une erreur ou une omission. Les fonctions de création, modification et suppression de
données sur le dossier client lui seront donc interdites dans l’application.

– les moyens de faire circuler l’information au sein des groupes de travail, qui prennent en
charge les processus afin d’éviter les erreurs et omissions.
EXEMPLE
L’application pourra offrir des fonctionnalités afin d’avertir le responsable des dossiers clients de
l’anomalie constatée par l’employé qui saisit les commandes. Cela permettra que la correction inter-
vienne systématiquement et dans les meilleurs délais.
Elle pourra fournir au service qui assure la préparation et la mise en livraison des commandes, un
récapitulatif des commandes à livrer cadencées. Cela facilitera l’organisation des tâches du service, et
évitera les retards ou les erreurs de livraison. La satisfaction des clients sera ainsi améliorée grâce à une
meilleure circulation de l’information.

■ D’alimenter en données les modules pilotes


L’objectif est de fournir les outils de contrôle de gestion permettant de juger de l’atteinte des
objectifs, ainsi que des outils d’aide à la prise de décision.
Les données, qui sont liées aux manipulations de flux par les modules opérationnels, sont la
source de l’information des modules pilotes. Elles leur permettront de comparer les
objectifs assignés avec les réalisations et de prendre des décisions pour les orientations à
venir de l’organisation.

EXEMPLE
La direction commerciale a décidé de fixer un objectif de ventes de + 10 % pour une gamme de
produits. Elle pourra vérifier que cet objectif est atteint grâce aux statistiques commerciales qui seront
extraites de l’application de gestion de suivi des commandes des clients. Si certains secteurs de ventes
ne réalisent pas l’objectif, le responsable pourra pratiquer la gestion par exception en analysant plus
finement les données, pour comprendre les raisons de cet écart défavorable et prendre les mesures
nécessaires à la correction des problèmes rencontrés, qui s’opposent à l’atteinte de l’objectif.

c) Axe 3 : informations d’aide à la décision respectant le niveau hiérarchique


et l’angle de vue du destinataire
Le système d’information va également permettre de diffuser auprès des décideurs des
informations pertinentes, avec un délai suffisamment bref et sans déformation.

EXEMPLE
Le responsable de la force de ventes aura besoin de statistiques mensuelles du chiffre d’affaires réalisé
par chacun des vendeurs sous ses ordres.

Cette partie du système d’information constituera les applications décisionnelles du système


informatique de gestion.
Dans le couplage entre modules opérationnels et pilotes, le système d’information n’a pas
pour unique fonction de faire circuler les informations, mais également de les rendre plus
ou moins synthétiques et de les adapter au point de vue du destinataire.

34
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

EXEMPLE
Le directeur des ventes aura besoin d’informations par vendeurs, tandis que le directeur commercial
d’un groupe d’entreprises filiales aura besoin du chiffre d’affaires par filiales. Cela correspond à un
effet de « zoom arrière » lorsque l’on monte dans la hiérarchie. Plus on se positionne à un niveau élevé
de la hiérarchie et plus on a un angle de vue large. Par contre, on voit le réel de manière plus éloignée
donc avec moins de détails.

En ce qui concerne les différences d’angles de vue, elles sont liées au fait qu’à un même
niveau hiérarchique, les différents acteurs n’ont pas les mêmes rôles. Leur périmètre de
décision est différent. Les natures des décisions à prendre divergent de l’un à l’autre. Ils ont
donc besoin d’informations différentes, même si elles sont au même niveau de synthèse, et
si leurs données d’origine sont les mêmes.

EXEMPLE
Le directeur du marketing aura besoin du chiffre d’affaires par gamme de produits ou par segment de
clientèles, parce qu’il gère le cycle de vie des produits et la stratégie marketing. Par contre, le directeur
commercial du groupe aura besoin du chiffre d’affaires par filiales, parce qu’il gère la force de ventes
opérationnelle. Le directeur de la trésorerie aura besoin de la rotation des créances clients nées de ce
chiffre d’affaires. Ils ont donc une différence de point de vue, même s’ils se trouvent au même niveau
de la hiérarchie. Le système d’information doit donc être conçu de telle sorte qu’il fournisse à chacun,
en fonction de la nature des variables qu’il gère et de son niveau hiérarchique, la bonne information
au bon moment, en respectant son angle de vue sur le réel et le degré de synthèse dont il a besoin. Il
doit lui permettre également d’accéder aux détails d’une information de synthèse, pour pratiquer la
gestion par exception, en cas d’écart significatif entre la prévision et la réalisation.

d) Axe 4 : informations concernant les objectifs assignés


lors de la démarche budgétaire
Le module pilote pourra également fixer des objectifs, qui seront mémorisés et contrôlés
par le système d’information. La démarche budgétaire doit avoir pour mission de définir les
objectifs à atteindre et de les décomposer au niveau de responsabilité de chacun. Ce
mécanisme sera la base de la délégation de responsabilité et du contrôle de la réalisation par
la hiérarchie. Pour pouvoir automatiser ce système, il est nécessaire que les données prévi-
sionnelles, que constituent les objectifs, soient intégrées dans le système d’information. On
pourra automatiser la production du contrôle de gestion, suivant les règles de gestion
établies, avec les données réelles, dont on a vu précédemment qu’elles étaient présentes dans
le système d’information dès la gestion des flux de l’activité.
e) Axe 5 : informations concernant les décisions prises par les modules pilotes
Les modules pilotes vont pouvoir prendre des décisions, en s’appuyant sur les informations
qui leur sont fournies pas les outils d’aide à la décision.
Prendre une décision ne suffit pas. Ce qui est plus difficile c’est d’obtenir sa transformation
en action.
Pour que cela soit possible, il faut que les acteurs opérationnels, qui vont transformer la
décision en action soient informés de la décision. Il faut donc pouvoir intégrer la décision
dans le système d’information. Cette décision peut porter tant sur les méthodes de travail et
règles de gestion que sur les résultats à obtenir.

35
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

EXEMPLE
La direction décide que, dans le cadre de la mise en place des règles de sécurité financière, la compta-
bilisation des factures des fournisseurs et leur mise en règlement seront des fonctions séparées, en
termes de postes de travail et donc en termes d’acteurs dans le processus. Il faudra donc modifier les
règles de fonctionnement du groupe de travail. Cela devra être transposé dans les fonctions
« groupware » de l’application de suivi des commandes aux fournisseurs, par une modification du
paramétrage.

EXEMPLE
La direction commerciale décide de réaliser une opération promotionnelle pour le lancement d’un
nouveau produit. Cela va nécessiter de disposer d’un stock tampon de produits plus important de
30 % que prévu initialement, d’ici à un mois, lors de la mise en marché.

f) Axe 6 : informations expression des décisions prises par les modules pilotes
Le système d’information doit permettre de transformer les décisions globales en informa-
tions opérationnelles adéquates pour l’action. Les décisions globales prises par la hiérarchie
doivent être détaillées et traduites par rapport aux conséquences qu’elles entraînent pour
chaque module opérationnel.

EXEMPLE
Décider d’introduire un produit nouveau sur le marché impliquera pour le responsable du magasin, où
sont stockés les emballages, de gérer plusieurs références supplémentaires.
Pour la planification de la production, il faudra modifier les équipes de fabrication pour tenir compte du
surcroît de fabrication à prendre en charge à la suite de la décision de modifier le stock tampon de + 30 %.
Le service maintenance va devoir mettre à jour son planning, pour intégrer des nouveaux réglages et
décaler des entretiens préventifs, prévus dans cette période sur ces équipements.
La force de ventes va devoir planifier la visite des clients pour le lancement du nouveau produit.

Le système d’information, s’il est correctement structuré, assurera effectivement le couplage


entre modules opérationnels et modules pilotes. Il permettra donc le contrôle et la
régulation du système qu’est l’organisation.
g) Axe 7 : informations informelles non intégrables dans le système d’information
En dehors de l’intervention du système d’information, les données acquises par les modules
opérationnels circulent de manière informelle. Cette circulation d’informations se fait sans
aucune adaptation, mais parfois avec des distorsions, sans aucune fiabilité et sans qu’aucun délai
de transmission ne puisse être déterminé. Il en est de même pour les décisions prises par les
modules pilotes, qui doivent être transmises aux modules opérationnels pour action.
Cependant, certaines informations ont, par nature, un caractère informel et s’appuient sur des
relations interpersonnelles, qui rendent impossible, et même non souhaitable, l’intervention du
système d’information dans leur circulation. Elles doivent conserver leur caractère de subjectivité.

EXEMPLE
On ne peut faire entrer dans le système d’information le fait qu’un directeur coopère efficacement avec
sa secrétaire ou au contraire qu’il ne la supporte que difficilement ! Cependant, cela aura une impor-

36
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

tance dans la qualité de leur collaboration et ce sera un facteur de progrès ou de non-qualité pour
l’organisation.

EXEMPLE
Dans l’organisation des équipes de travail dans une industrie, on pourrait penser que l’ordonnan-
cement est un simple problème de planning. Si c’est le cas, une automatisation de la détermination des
équipes serait facile. Les règles à appliquer étant objectives et dépendant d’informations disponibles,
comme les congés, les horaires de travail et les besoins en postes pour la production, il semble possible
d’informatiser l’ordonnancement des équipes. Mais cela ne permettra pas la prise en compte des
relations interpersonnelles au sein de l’équipe. Ainsi, le responsable aura constaté que de mettre A et
B dans la même équipe est gênant, car ces deux personnes se détestent. Ou au contraire les associer
n’est pas favorable, car ils passent leur temps à discuter au lieu de travailler. On peut bien évidemment
décider que ce ne sont pas des critères à prendre en compte. Néanmoins, ils généreront des inconvé-
nients pour l’organisation, qui se traduiront, soit par de la non-qualité, qui a un coût, soit par une
baisse de productivité et donc une érosion des marges. Prendre en compte ce type de critères interdit
une automatisation complète de l’ordonnancement des équipes, car les paramètres ne sont pas
modélisables ni généralisables. On a plus de cas d’exceptions que de cas d’application des règles.

EXEMPLE
Dans les années 80, dans une PMI de transformation de métaux, la situation économique et la tréso-
rerie étant très bonnes, les dirigeants souhaitaient pouvoir spéculer sur les tarifs des matières
premières, comme la tonne d’acier, pour améliorer leur marge. Il pouvait en effet y avoir des hausses
spectaculaires sur prix à la tonne sur un délai très court. Les clients, de gros industriels, acceptaient la
révision des prix en fonction de la hausse des cours des matières premières sur le marché mondial. La
capacité d’anticipation et de spéculation de l’entreprise pouvait donc, en fonction de l’habileté de ses
dirigeants, lui procurer une augmentation substantielle de sa rentabilité des capitaux investis. L’appli-
cation informatique leur proposait, en matière de gestion des stocks, la mise en œuvre du modèle de
Wilson. Les dirigeants ne géraient donc pas de manière automatique leurs achats de matières
premières sensibles.

Dans les années 70 et 80, on avait tendance à penser que des applications intégrées permet-
traient de débarrasser les décideurs de prise de décisions qui semblaient élémentaires,
comme le réapprovisionnement des matières et marchandises. On pensait alors que les
modèles de gestion de stocks implémentés dans les applications permettraient de savoir
que, le stock d’alerte étant atteint et le lot économique de commande ayant été défini, le
système pourrait passer les commandes aux fournisseurs pour maintenir les stocks à leur
niveau requis.
C’était omettre la complexité de la réalité. Une décision, si modeste puisse-t-elle paraître, ne
peut émaner que d’un être humain. Le rôle du système d’information est d’alerter, d’attirer
l’attention et de proposer une action. Son rôle s’arrête là. La décision appartient à l’acteur
en charge de la responsabilité.

EXEMPLE
Toute situation de prise de commande est complexe. Le système, en tenant compte des données,
d’achats et des nomenclatures des produits, des prévisions de ventes et de délai d’approvisionnement,

37
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

peut proposer un plan de commandes aux fournisseurs, afin d’éviter les ruptures de stocks. Mais la
durée de vie des produits diminuant, la reconception des produits étant de plus en plus fréquente pour
des raisons techniques ou commerciales, des données non disponibles dans le système peuvent
entraîner la modification des ordres à passer. Il faut donc laisser la main au décideur et ne pas vouloir
tout automatiser.

1.3 Qualités du système d’information, dans une vision statique


Il nous faut maintenant résumer les qualités que doit avoir le système d’information de l’organisa-
tion pour lui permettre d’assurer correctement et pleinement les fonctions qui ont été définies
précédemment.
On peut les résumer sous forme de deux qualités essentielles :
– première qualité : la rapidité de transmission de l’information. Il ne doit pas y avoir de délai, de
rétention dans la circulation de l’information ;
– seconde qualité : la fiabilité de la transmission, caractérisée par la pertinence des données et leur
complétude.

a) Première qualité : la rapidité de transmission de l’information


Ce critère n’est pas à considérer de manière absolue. Il signifie que la vitesse de circulation
d’une information doit être déterminée par le temps maximum tolérable pour que
décisions et les actions qu’elles entraînent soient effectuées dans des délais compatibles avec
le contexte concurrentiel. Cette vitesse est donc évolutive en fonction du moment
considéré, variable en fonction de la nature de l’activité et également en fonction de la
nature de l’information elle-même.
Il s’agit donc de posséder la bonne vitesse de transmission de l’information pour chaque
donnée et dans un certain contexte.

EXEMPLE
Lorsque les conditions techniques ne permettaient pas aux entreprises de ventes par correspondance
d’obtenir les informations de commandes des clients autrement que par courrier et que les moyens de
traitement de l’information ne permettaient pas de livrer sans un délai se mesurant en semaines, il n’y
avait aucun inconvénient, pour une entreprise de ce secteur, à livrer sous deux à trois semaines. Mais
aujourd’hui où les moyens techniques permettent à certains de livrer en 24 heures, c’est un handicap
concurrentiel que de ne pouvoir le faire. La rapidité requise dans le système pour faire circuler les infor-
mations est donc liée à une époque et à des conditions technologiques. Si on veut se servir de cet
argument sur le plan commercial, il faut organiser une veille technologique qui permette d’être le
premier à mettre en œuvre l’innovation dans le traitement de l’information. Cela permettra de se diffé-
rencier en apportant une meilleure qualité de traitement au client. Mais il faut par contre être attentif
à l’efficacité réelle de la technologie, afin de ne pas proposer une avancée illusoire que l’on sera
incapable de faire fonctionner.

EXEMPLE
La transmission des commandes des clients entre la grande distribution et les fabricants de produits de
consommation courante, comme ceux des rayons alimentaires, est aujourd’hui souvent réalisée en EDI
(échange de données informatisées). Cela permet une transmission immédiate entre systèmes d’infor-

38
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

mation d’entreprises différentes, sans saisir les informations plusieurs fois, donc sans délais et sans
erreurs. Cela permet de travailler avec un stock qui tend vers zéro grâce à une réduction au strict
minimum du délai de livraison.

Au contraire, la transmission d’un contrat de vente dans l’aéronautique ou la construction


navale peut se faire par courrier, car la fabrication va durer plusieurs années.
La rapidité est donc liée à la nature des activités, qui fixe la vitesse requise.

EXEMPLE
Dans une entreprise de vente par correspondance, le service logistique, qui traite les commandes des
clients, a besoin de les recevoir le plus rapidement possible, en fonction de ce que permet la technique,
pour assurer le délai de livraison minimal. Mais, dans cette même entreprise et au même moment, le
directeur commercial n’aura besoin de statistiques sur le chiffre d’affaires réalisé qu’une fois par
semaine ou une fois tous les quinze jours, voire une fois par mois.

En conclusion, à un moment donné et dans une certaine organisation, la vitesse requise


pour la transmission des informations n’est pas la même pour toutes les informations et
pour tous les destinataires.
b) Seconde qualité : la fiabilité de la transmission
La fiabilité est une qualité qui doit être absolue.
Elle signifie que l’information doit être pertinente et complète, lors de son acquisition, et qu’elle
doit ensuite être transmise sans déformation et sans déperdition tout au long du circuit.
■ La pertinence de l’information
Cela signifie que l’information ne doit être présente dans le système que dans la mesure où
elle le concerne.

EXEMPLE
Une facture d’un fournisseur ne doit être saisie qu’après vérification de son bien-fondé. Cela signifie
qu’il faut vérifier qu’elle correspond à une commande, qui a été livrée, et que les mentions qu’elle
comporte sont bien exactes en termes de natures des produits, de quantités facturées et de tarifs
appliqués. Ce n’est qu’après ces contrôles que l’on peut déclarer l’information comme pertinente, donc
intégrable dans le système d’information. Néanmoins, le système d’information peut aider à la qualifi-
cation des données. Ainsi, on peut prévoir de valider le bon de livraison dans l’application par rapport
à la commande passée et la facture par rapport au bon de livraison. Cela fera apparaître d’éventuels
écarts qui amèneront à refuser la validation de la facture dans le système. Elle ne poursuivra donc pas,
en l’état, les phases de son cycle de vie en attendant, par exemple, la réception d’un avoir. Elle pourra
même être totalement rejetée, en cas de non-correspondance à une commande ou à une livraison. Une
donnée ne deviendra donc une information exploitable par le système, dans le cadre des phases d’un
processus, qu’après contrôle et validation, quand bien même ces phases sont incluses dans l’appli-
cation informatique.

■ L’information doit être complète


Cela signifie qu’une information partielle ne peut pas être traitée ou peut entraîner des
erreurs de traitement.

39
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

EXEMPLE
À l’arrivée d’une commande d’un client, il ne faut pas omettre de saisir une éventuelle modification
d’adresse de livraison, qui serait signalée.
Si l’on omet de le faire, le bon de livraison portera l’ancienne adresse erronée et le livreur se présentera
à cette mauvaise adresse, retardant ainsi la livraison et augmentant le coût du transport.

1.4 Limites du système d’information


Le système d’information ne peut faire circuler, stocker et traiter toutes les natures d’information
existant dans l’organisation.
Toutes les informations de l’entreprise ne concernent pas le système d’information.
Certaines informations ne peuvent pas être traitées de manière automatisée.
Il existe dans le système d’information un périmètre des informations dont le traitement est auto-
matisé.
La distinction entre domaine automatisable et domaine automatisé permettra de définir la stratégie
en matière de système d’information.

LA STRUCTURE DU SYSTÈME D’INFORMATION DE L’ENTREPRISE

L'INFORMATION

Le système d’information de l’entreprise

Le sous-système automatisable

Le sous-système
automatisé

Le schéma précédent appelle quelques remarques :


a) Toutes les informations de l’organisation ne concernent
pas le système d’information
Nous avons déjà précisé que certaines informations subjectives et appartenant au domaine
des relations humaines étaient à considérer comme ne faisant pas partie du système d’infor-
mation. Elles sont parfois très importantes et contribuent à expliquer le fonctionnement de
tel service ou de telle entreprise, mais le système d’information ne peut en rendre compte.

EXEMPLE
Le caractère autoritaire d’un dirigeant dans une PME est un facteur important, mais qui ne peut pas
faire partie du système d’information.

40
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

b) Certaines informations ne peuvent pas être traitées de manière automatisée


D’autres informations peuvent exister, mais ne peuvent être traitées de manière automa-
tisée, c’est-à-dire informatisée. Elles ne sont pas reproductibles et codifiables, elles ne
présentent pas de caractère de répétitivité.
Les informations qui ne relèvent pas du système d’information automatisable doivent
cependant être prises en compte par les modules pilotes dans leur processus de décision.

EXEMPLE
L’information de l’arrivée d’un concurrent, qui met en péril une des gammes de produits, n’aura peut-
être pas été perçue à travers les statistiques commerciales, ou elle sera perçue trop tard, lorsque l’effet
de la présence du concurrent se fera sentir sur les ventes.

Cette information devrait être traitée par les dirigeants de l’entreprise avant que ce ne soit
le cas. Lorsque l’on constatera au niveau des statistiques une baisse de chiffre d’affaires, il
sera trop tard.
Mais elles concernent également une catégorie d’informations, qui ont une incidence sur le
long terme et la stratégie, et qui ne peuvent appartenir au système d’information automatisable.

EXEMPLE
Les conséquences de la chute du mur de Berlin sur l’industrie d’armement ont été multiples et
profondes. On pouvait penser que cela ralentirait la course aux armements et donc rendrait la concur-
rence plus difficile, sur un marché limité. En fait cela a surtout modifié les cibles et donc la nature des
« produits ». Les dirigeants d’entreprise qui ont su modéliser rapidement les conséquences probables,
en termes de géopolitique, de cet événement historique ont su préparer la reconversion de leur firme
plus tôt et donc plus facilement que les autres. Ils ont pu répondre en termes d’offre produits aux
nouvelles orientations de la demande.

c) Le périmètre des informations dont le traitement est automatisé


Parmi les informations qui appartiennent au système d’information, certaines peuvent faire
l’objet d’un traitement automatisé, grâce aux outils informatiques :
– il s’agit des informations volumineuses et répétitives, comme le traitement des commandes
clients et fournisseurs, la comptabilité, la paie, etc. ;
– ou de la construction d’outils d’aide à la décision, statistiques multicritères, graphiques, etc.
En tout état de cause, qu’il soit automatisé ou non, toute information appartenant au
système d’information va faire l’objet d’un traitement dont la procédure doit être définie à
l’avance de manière formelle et explicite, sous forme de règles de gestion standards à
appliquer, en fonction des différentes situations possibles qui seront toutes envisagées.
La maîtrise de la construction du système d’information va donc passer par la connaissance
de la nature des données à traiter et par la définition des règles de gestion à appliquer.
d) La distinction entre domaine automatisable et domaine automatisé
La distinction entre domaine automatisable et domaine automatisé a son importance. Elle
permet de différencier, parmi les données qui pourraient faire l’objet d’un traitement
automatisé, celles qui sont effectivement informatisées de celles qui subsistent en traitement
manuel.

41
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

EXEMPLE
Dans une petite entreprise, on pourrait automatiser la paie mais, pour des raisons de coûts, on
préférera peut-être faire les deux ou trois bulletins mensuels manuellement.
Avec l’évolution des logiciels disponibles, dont certains sont peu coûteux, et la complexité de plus en
plus grande du calcul de la paie, l’entreprise pourra ensuite revenir sur cette décision et automatiser le
traitement de ses salaires, soit en achetant un logiciel du marché, soit en confiant le traitement de sa
paie à son expert-comptable, soit en utilisant des services existants sur Internet.

C’est pourquoi, afin d’assurer la cohérence du système d’information et parce que tous les
domaines à automatiser ne peuvent l’être simultanément, il sera nécessaire de concevoir et
de faire évoluer un schéma directeur. On aura de plus en plus tendance à le concevoir dans
le cadre d’une évolution permanente, qui sera positionnée dans le cadre de l’urbanisation
du système d’information. Part. 1, chap. 3, sect. 2 et 3

2. Vision dynamique : gérer la complexité croissante

Changement technique
Prise en compte pour avoir un système
de la variation d’information innervant
de la variété (volume) Prise de décisions
l’entreprise pour l’acquisition,
et de la complexité stratégiques et tactiques
la transmission et le traitement
(éléments en du pilotage de l’entreprise
adéquat des informations
interaction) par le SI

Changement
organisationnel :
conduite du
changement, gestion
de la compétence
des salariés
dans leur poste

Le développement d’une organisation à travers les prises de décision stratégiques va entraîner, de


manière inéluctable, le besoin d’évolution du système d’information.
Or, le développement est une nécessité vitale pour un système vivant et ouvert. S’il ne se développe
plus il décline et disparaît. Comme on le dit couramment, « qui n’avance pas, recule ».
Il n’y a pas d’état stable, qui puisse durer. On ne peut donc se contenter d’une vision statique du
système d’information. Après l’avoir envisagé sous cet angle, il faut maintenant considérer les
impacts de la dynamique.

2.1 Les conséquences de la dynamique du système


sur son système d’information
Toute prise de décision stratégique ou tactique va influer sur la variété ou la complexité de
l’organisation.

42
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

Ce faisant, le système d’information va devoir absorber cette évolution de l’organisation,


afin d’en maintenir le contrôle et la régularité du développement.
Ses performances vont devoir s’accroître pour traiter l’augmentation du volume d’activité,
dans les mêmes délais et avec le même effort.
Sa complexité va devoir évoluer pour contrôler celle de l’organisation. Cela permettra
d’éviter le développement de l’entropie, ou tendance au désordre.
Si cela n’est pas le cas, l’organisation ne va pas instantanément s’arrêter de fonctionner.
Mais, ce qui est plus pernicieux, son fonctionnement va se dégrader.

EXEMPLE : NON-ABSORPTION DE L’AUGMENTATION DE VOLUME


Le délai de traitement des informations commerciales va s’allonger à cause de l’augmentation du
volume que le système d’information n’arrive pas à absorber. On va donc augmenter le besoin en fonds
de roulement, entraînant une baisse de rentabilité des capitaux investis, puis une diminution de la
cotation sur le marché financier ou des difficultés de trésorerie pouvant entraîner le dépôt de bilan.

EXEMPLE : NON-ABSORPTION DE L’AUGMENTATION DE LA COMPLEXITÉ


Une entreprise qui gère un réseau de panneaux d’affichage décide de lui associer une activité de
conception et de réalisation graphique. Les caractéristiques de la gestion de ces deux activités sont très
différentes. Notamment, cette nouvelle activité intègre une dimension d’approvisionnement et de
gestion de stocks de matières premières, de nomenclatures et de gammes de fabrication, de mesure
des temps de production et des coûts, autrement dit la nécessité d’une gestion de production qui
n’existait pas dans l’activité antérieure. Certes, il y avait des installations et des entretiens de panneaux
et la mise en place d’affiches. Par contre, il n’y avait pas de devis et de fabrication d’articles. L’entre-
prise n’ayant pas pris conscience des besoins d’évolution de son système d’information a essayé de
détourner les fonctionnalités de son logiciel actuel de gestion de l’activité d’affichage pour traiter sa
nouvelle activité. Ce faisant, elle ne disposait pas des notions de nomenclatures et de gammes de fabri-
cation et ne pouvait exercer aucun contrôle automatique des écarts entre les devis et les coûts
réellement supportés. Elle ne disposait donc d’aucun outil d’analyse de la rentabilité de sa nouvelle
activité.

De surcroît, la dynamique du système d’information liée à celle de l’organisation va


entraîner :
– des évolutions dans l’organisation et les relations humaines ⇒ Part. 2, chap. 8
– des évolutions sur le plan technique ⇒ Part. 1, chap. 4

2.2 Qualités du système d’information dans une vision dynamique


Il nous faut maintenant résumer les qualités que doit avoir le système d’information de l’organisa-
tion pour lui permettre d’assurer correctement et pleinement les fonctions qui ont été définies dans
le cadre de la dynamique de l’organisation.
– première qualité : l’évolutivité du système. Dans une organisation en mouvement permanent, le
système d’information doit évoluer également en permanence ;
– seconde qualité : la complexité. Pour maîtriser l’entropie, c’est-à-dire la tendance au désordre liée
au développement de l’organisation, le système d’information doit en permanence avoir une
complexité égale ou supérieure à celle de l’organisation.

43
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

a) Première qualité : l’évolutivité du système


Le système d’information doit pouvoir évoluer parallèlement à l’évolution de l’entreprise et
au même rythme. Pour ce faire, il lui faut posséder certaines caractéristiques qui permettent
cette évolutivité. Dans la mesure où l’entreprise est un système ouvert, dans un environ-
nement mouvant et incertain, l’ensemble des chemins que peut prendre l’évolution est
infini. Dans ces conditions, construire un système d’information évolutif consiste essen-
tiellement à éliminer les éléments de rigidité, notamment les facteurs constants, pour les
remplacer par des paramètres susceptibles de changer de valeur et de nombre de variantes
offertes.

EXEMPLE
Le fait de rendre paramétrable le taux de TVA applicable à une ligne de facture en fonction du produit
permettra de prendre en compte des modifications de la réglementation fiscale en la matière. On peut
aussi imaginer que le même produit supporte des taux différents en fonction de zones géographiques
(métropole, Corse, DOM). Si le système d’information a été conçu de manière rigide, c’est-à-dire en ne
permettant pas d’avoir une pluralité de taux qui puissent être associés aux produits, voire aux croise-
ments des produits et des zones géographiques des clients, il ne peut s’adapter facilement à cette
modification des conditions de l’environnement légal. Si, par contre, pour les taux de TVA comme pour
tout autre élément d’information, le système est basé sur la possibilité de gérer la pluralité de valeurs
et la pluralité de situations, il s’adaptera sans difficultés aux évolutions rendues nécessaires par le
contexte.

b) Seconde qualité : la complexité


Pour contrôler le fonctionnement du système de l’organisation de manière efficace, le
système d’information doit posséder une complexité au moins aussi grande que l’organi-
sation elle-même.
La complexité se mesure par le nombre d’éléments qui peuvent entrer en interaction dans
l’organisation. Avec le développement, cette complexité est croissante dans l’entreprise, elle
doit donc l’être également dans le système d’information. C’est un des axes de son évolu-
tivité. Dans l’absolu, il faudrait être en mesure de ne rien figer et de tout prévoir, ce qui est
impossible. Il existe aujourd’hui des manières de concevoir les systèmes d’information qui
permettent de gérer la complexité, sans avoir besoin d’envisager a priori tous les axes de
développement possibles. Elles sont fondées sur l’utilisation du paradigme objet, dans la
conception et la construction des systèmes d’information. Le terme paradigme signifie qu’il
s’agit d’un modèle abstrait généralement répandu.

EXEMPLE
Il est possible de définir à un moment donné une catégorie d’objets (on dit une classe d’objets), par
exemple, les objets volants. Cette classe d’objets possède une structure de données (des informations
connues sur chaque objet) et des procédures de traitements qui sont communes à tous les objets de la
classe, que ce soit des oiseaux, des insectes volants, des avions, des ballons, etc. Il sera alors possible
de créer des objets, spécialisations de cette classe d’objets, pour chacune des catégories spécifiques
existantes, afin de compléter l’information disponible par des caractéristiques et des comportements
particuliers. Ainsi, ces classes d’objets spécialisés hériteront des données et comportements de l’objet
général et elles auront, en plus, leurs spécificités. Mais, de surcroît, cette modélisation objet facilite
l’accroissement de la complexité du système d’information. Elle permet, lorsqu’apparaît un nouveau

44
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

type d’objets inconnus jusqu’alors, de créer une nouvelle spécialisation, qui sera classée dans les objets
volants mais qui pourra présenter de nouvelles particularités. C’est ainsi que nous pourrons ajouter à
la liste précédente les fusées habitées ou non, et les navettes spatiales.
Part. 2, chap. 6, sect. 1 • Part. 2, chap. 7, sect. 3

section 3
relation entre maîtrise d’œuvre
et maîtrise d’ouvrage

Système d’information Informatique

Besoin de la gestion :
Traiter des informations
Demande : besoins Offre : outils
à des fins opérationnelles
et décisionnelles

Maîtrise d’ouvrage Maîtrise d’œuvre

Les développements qui précèdent ont montré que le concept de système d’information n’est pas
lié à l’émergence de la discipline de l’informatique. Par contre, cette dernière propose des moyens
de traitement automatique de l’information, ce qui, de nos jours, constitue une panoplie d’outils
utiles à la construction et à l’évolution du système d’information d’une organisation.
La relation qui unit les deux disciplines est donc fondée sur une relation de demande et d’offre. On
se retrouve donc dans le cadre d’une relation entre une maîtrise d’ouvrage, dont le rôle est
d’exprimer ses besoins et une maîtrise d’œuvre dont la mission est de proposer des outils propres à
satisfaire les besoins exprimés.

Les méthodes permettant de gérer correctement cette relation seront traitées dans la partie 2
de l’ouvrage ⇒ Part. 2, chap. 6, sect. 3
Nous aborderons ici les aspects généraux de la relation entre maîtrise d’ouvrage et maîtrise
d’œuvre.
Dans la plupart des domaines, la relation de marché, entre demande et offre, est soit
dominée par la demande, soit dominé par l’offre.
La règle qui s’applique le plus communément à un marché est la domination par l’offre,
dans une première phase, tant que l’offre est inférieure à la demande, c’est-à-dire tant que
le marché ne se situe pas en phase de maturité. Ensuite, il y a inversion des forces. Le marché
est alors dominé par la demande à partir du moment où l’offre excède la demande.
En ce qui concerne l’informatique, on a constaté cette évolution. On est en effet passé,
depuis 1981 (apparition de la notion de « personnal computer » et de produit standard dans
l’offre d’IBM), d’une situation dominée par les constructeurs, qui pouvaient imposer leur
volonté au marché, à une situation dominée par la demande, qui exige des offres standards
et des produits « libres » afin de ne pas dépendre des offreurs. Part. 1, chap. 4

45
1 CHAPITRE 1 – Relation entre informatique et système d’information
PARTIE

La même évolution n’a pas été constatée dans le domaine des systèmes d’information, où la
domination de la maîtrise d’œuvre se fait toujours ressentir.
On peut expliquer cette situation par différentes raisons.

1. Première raison : faible compétence dans ce domaine


des maîtrises d’ouvrages
Qui décide, dans la plupart des organisations, en matière de système d’information ?
Ce sont souvent des spécialistes du domaine financier qui prennent les décisions.
Ainsi que nous l’avons vu dans les sections précédentes de ce chapitre, la notion de système
d’information est beaucoup plus globale et elle nécessite une vision systémique et donc
dynamique de l’organisation. Actuellement, cela ne correspond pas à la culture des
dirigeants des organisations et des spécialistes du domaine financier, entre autres. La
maîtrise d’ouvrage se trouve donc confrontée à un problème de compétences dans
l’expression des besoins et l’évaluation des solutions qui lui sont proposées. En consé-
quence, de très nombreuses organisations se trouvent dotées d’outils qui devraient lui
permettre de construire le système d’information dont elle a l’absolue nécessité et qui ne
sont pas du tout adaptés aux besoins effectifs.
Bien que cette problématique soit un secret de polichinelle, les relations de pouvoir entre les
décideurs potentiels gèlent la nécessaire évolution des méthodes de prise de décision en
matière de système d’information.
Dans de très nombreuses organisations de toutes tailles et de toutes natures d’activité, on
entend fréquemment parler des incohérences du système d’information et des méthodes
arbitraires de choix en la matière. C’est un problème dont on ne mesure pas suffisamment
la gravité et les conséquences dommageables, mais qui est très difficile à aborder serei-
nement à cause des enjeux de pouvoir qu’il recouvre.
« Information est un mot piège, un concept protéiforme, parfois un argument commercial, ou l’objet
de luttes de pouvoir.
Devant les difficultés actuelles des organisations, chacun dit qu’il y a un problème d’information :
mieux informer le personnel (information montante et descendante), mieux connaître l’environnement,
répartir l’informatique, etc. Tout ceci est certainement vrai et part de bonnes intentions, mais ne touche
pas au fond du problème, à savoir :
– Qu’est-ce qui est information pour un individu particulier, dans une situation donnée à un moment précis ?
– Qu’est-ce qui a de la signification pour lui ?
– Quels sont ses désirs d’information ?
– Comment l’organisation conditionne-t-elle l’information, et réciproquement ?
Faute de chercher des réponses à de telles questions, on s’est attaché à sérier et à codifier des besoins
d’information en définissant des systèmes d’information comptables, budgétaires, financiers, techniques,
commerciaux, sociaux, économiques, l’information des actionnaires, des cadres, du personnel, etc. Ce
souci de fractionnement, de codification, de quantification, a conduit à bâtir des systèmes de données
dont le contenu informationnel, pour les gestionnaires, est souvent très faible par rapport à leur coût et à
leur lourdeur : l’information est passée à travers les mailles du réseau formé par ces systèmes. »
J. Melese, Approches systémiques des organisations, Éditions d’Organisation, 1990, p. 14.

46
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

2. Seconde raison : pouvoir des informaticiens


sur le système d’information
Dans les organisations, notamment les plus grosses d’entre elles, les directions informa-
tiques existent depuis longtemps, tandis que les directions des systèmes d’information sont
récentes ou inexistantes. Il arrive même souvent que la direction des systèmes d’infor-
mation corresponde à un simple changement de nom de baptême, de tout ou partie, de la
direction informatique. Dans d’autres cas, les deux directions sont indépendantes, mais la
compétence métier des personnes qui dirigent la direction des systèmes d’information est,
au pire, l’informatique et, au mieux, la finance.
Jusqu’au passage à l’an 2000 et à l’euro, les directions générales des organisations privées de
grande taille se trouvaient très souvent en position d’otage de leurs directions informa-
tiques. Cela signifie qu’il leur était très difficile d’obtenir la satisfaction de l’expression de
leurs besoins dans les conditions et les délais qu’elles souhaitaient. Dans bien des cas, elles
ont profité des deux événements, externes, inéluctables et datés, précédents le passage à l’an
2000 et à l’euro pour échapper au pouvoir exorbitant de leur direction informatique. Pour
cela, les directions générales de grands groupes ont fait des choix progiciels, notamment
dans le cadre de l’offre des ERP, afin de ne plus dépendre de leur service interne.
Part. 3, chap. 9
On constate toujours les méfaits de cet excès de pouvoir des informaticiens sur l’infor-
mation de l’organisation, dans le secteur public notamment.
Et le changement de centre de décision en matière de système d’information n’a pas été très
satisfaisant, dans la mesure où l’on est souvent tombé de Charybde en Scylla ; en quittant
l’excès de pouvoir des informaticiens, on a transféré le pouvoir aux financiers.
WEB Charybde

En conclusion, une relation équilibrée entre maîtrise d’ouvrage et maîtrise d’œuvre passe par la défini-
tion du périmètre de chacun. La maîtrise d’ouvrage doit être compétente en matière de systémique et
d’élaboration d’un cahier des charges. Elle doit savoir exprimer les véritables besoins de l’organisation en
matière de système d’information, dans un cadre global et dynamique. À ce titre le responsable de la
gestion de la qualité et le responsable du contrôle de gestion, à défaut d’un véritable responsable du
système d’information, seront plus qualifiés que le responsable financier. La maîtrise d’œuvre, qu’elle
soit interne ou externe, doit se positionner dans une optique orientée client qui vise, dans une démarche
qualité, à satisfaire, de mieux en mieux, les besoins de la maîtrise d’ouvrage. Sur le plan formel, c’est
souvent ce qui est annoncé, notamment par les grands éditeurs de logiciels et les grandes sociétés de
conseil, mais c’est rarement la réalité sur le fond. En effet, cela implique de la part de la maîtrise d’œuvre
de renoncer à son pouvoir sur l’information et d’adopter une vision systémique de l’organisation. Il est
alors nécessaire qu’elle prenne en compte l’aspect dynamique du système d’information et qu’elle
adopte des méthodes nouvelles pour développer et faire évoluer les outils informatiques. Cette exigence
est rarement avérée actuellement, même chez ceux qui annoncent avoir adopté ces méthodes. En effet,
on constate que les méthodes utilisées majoritairement par les informaticiens n’ont pas évolué confor-
mément aux besoins de la prise en compte correcte des besoins de la maîtrise d’ouvrage. De plus, ceux
qui ont adopté les nouvelles méthodes en ont très souvent retenu la lettre et non l’esprit. Cela constitue
une appropriation insuffisante de ces nouvelles méthodes pour satisfaire les besoins.

Pour un exposé complet de ces méthodes ⇒ Part. 2, chap. 2, sect. 3

47
APPLICATIONS

APPLICATION 1

QUESTIONS
Rechercher dans les différents processus les décisions réflexes qui pourraient être instaurées,
dans le cadre d’une entreprise industrielle, dans le secteur de la fabrication d’articles électroni-
ques de grande consommation, comme des téléviseurs.
Définir les acteurs, qui doivent en être responsables.
Rechercher les mécanismes de substitution, en l’absence de ces décisions réflexes.
Évaluer les inconvénients de l’absence des mécanismes réflexes.

APPLICATION 2

QUESTIONS
Rechercher les différents processus qui pourraient faire l’objet d’une délégation de responsabi-
lité dans la même entreprise industrielle que précédemment, qui se situe dans le secteur de la
fabrication d’articles électroniques de grande consommation, comme des téléviseurs.
Définir des indicateurs de performances et d’alertes qui pourraient être mis en place dans le sys-
tème d’information pour que la direction générale puisse pratiquer une véritable direction par
objectifs et mettre en œuvre la gestion par exception.
Expliquer les inconvénients, qui pourraient résulter :
– de l’absence de délégation des responsabilités ;
– de l’absence d’indicateurs d’alertes.

48
CHAPITRE 1 – Relation entre informatique et système d’information 1
PARTIE

APPLICATION 3

QUESTIONS
Rechercher, dans le contexte économique et social contemporain, des exemples des caractéristi-
ques énoncées précédemment.
Lister notamment :
– des activités sensibles et non sensibles à la saisonnalité ;
– des conséquences de la saisonnalité de l’activité sur la gestion des flux de ressources ;
– des conséquences de la complexité croissante sur la maîtrise des flux ;
– des conséquences de la mobilité croissante sur la poursuite de l’objectif de l’organisation.

49
2
CHAPITRE
Structure
du système d’information
section 1 Facteurs influençant la structure du système d’information
d’une organisation
section 2 Éléments constitutifs d’un système d’information
applications

section 1
facteurs influençant la structure
du système d’information
d’une organisation
Ce chapitre a pour but de montrer que le système d’information, étant vu comme le système
nerveux de l’organisation, il ne peut pas avoir une structure unique, efficace, en tous temps et en
tous lieux.

Dans les espèces biologiques, le système nerveux est spécifique à chacune afin de lui
permettre de survivre et de se développer. Dans les organisations, différents éléments, tels
que la finalité, l’activité, la taille, l’histoire, vont influer sur la structure du système d’infor-
mation dont elle a besoin, à un moment donné de son existence.
Deux conséquences évidentes :
– les outils informatiques, qui en constituent les briques, ne peuvent être identiques d’une
organisation à une autre ;
– les organisations étant condamnées à se développer pour survivre à long terme, le système
d’information devra suivre cette évolution permanente.
Cela permet de poser comme une évidence que le discours de certains éditeurs de progi-
ciels, qui affirment que leur produit peut convenir à toutes les organisations, est sans
fondement.

1. L’influence du métier : typologie des organisations


et structure du système d’information
1.1 Typologie des entreprises et influence
sur la structure du système d’information
Nous proposons ici une classification sommaire des entreprises sur le plan de leur « métier »,
afin de montrer les implications de la nature d’activité sur la structure adéquate du système
d’information. Dans la réalité, il faudra appréhender la notion de métier d’une façon plus fine.
Le but est de démontrer que le « métier » de l’entreprise influe sur les variables essentielles à

51
1 CHAPITRE 2 – Structure du système d’information
PARTIE

gérer, sur la structure des données pertinentes et sur les règles de gestion à appliquer. Par
conséquent la construction du système d’information, adéquat pour une entreprise donnée à
un moment donné de son histoire, doit tenir compte de son métier.
Une démonstration de ce principe est d’ailleurs apportée par les sociétés d’ingénierie en infor-
matique, qui sont, pour celles qui réussissent le mieux, spécialisées sur une offre par métier.
Cette logique d’efficacité est d’ailleurs reconnue par les constructeurs informatiques,
notamment IBM, à travers leurs réseaux de VAR (Value Added Retailors), qui sont des
éditeurs de progiciels et des sociétés de service ayant des compétences sur un axe métier.
Nous proposons une typologie des entreprises en sept grandes branches, car elle permet
d’envisager les principales caractéristiques de la différenciation des systèmes d’information.
Cependant, dans la réalité, une entreprise particulière peut être un assemblage de différents
cas ou être une variante spécifique de ceux-ci.
Il s’agit de montrer que la réflexion qui est à mener pour penser et structurer le système
d’information d’une organisation donnée doit s’appuyer sur une très bonne compré-
hension de ses « métiers » et de leur évolution probable à moyen terme.
TYPOLOGIE DES ENTREPRISES

Commerce e-commerce Commerce


de produit ou B to C de produits et services
avec la grande (Business To B to B
distribution Consumer) (Business to Business)

Gestion par affaires Gestion par produits

Industrie de montage Industrie de processus

TABLEAU RÉCAPITULATIF DES SEPT AXES DE LA TYPOLOGIE PROPOSÉE

Types d’activités Déclinaisons des activités


Trois modes de • La distribution en libre-service par les grandes enseignes de la distribution moderne.
commercialisation C’est actuellement un mode de distribution dominant des produits et services
des produits et services, destinés à la consommation finale, notamment en France.
couramment utilisés • La commercialisation « B to B » ou « Business to Business ». Il s’agit d’un mode de
de nos jours. distribution entre entreprises, qui concerne la consommation intermédiaire de biens
et services.
• La commercialisation « B to C » ou « Business to Consumer ». Il s’agit d’un mode de
commercialisation en développement rapide, qui a été représenté dans une
première période par la vente par correspondance (VPC) classique, pour évoluer de
nos jours vers la commercialisation par Internet.

52
CHAPITRE 2 – Structure du système d’information 1
PARTIE


Types d’activités Déclinaisons des activités
Deux modes de gestion. • Gestion par produits (ou services). Dans cette situation, on cherchera à déterminer
On entend par modes un résultat par produit ou par gamme de produits. On sera dans une situation
de gestion, la manière d’offre de produits ou de services standard, définis dans un catalogue. S’il s’agit de
pertinente de structurer produits, se posera également la question de la gestion de stocks.
l’analyse des charges • Gestion par affaires. Dans cette situation, chaque contrat correspond à un cas
et des produits, afin particulier. On cherchera donc à regrouper les charges et les produits par contrat,
de déterminer les afin d’en déterminer le résultat. Chaque contrat aura, généralement, fait l’objet d’un
conditions d’obtention devis préalable.
du résultat, à travers
les flux d’activité.
Deux types d’activités • Les industries de montage, telles que l’automobile ou l’électronique.
industrielles • Les industries de processus telles que l’agroalimentaire ou la pharmacie.

1.2 Les différents modes de commercialisation

Plusieurs
« métiers » pour
vendre, avec l’objectif
Grande distribution de l’orientation client

B to B

Communication par EDI Devis et affaire : la base


(Échange de données de la négociation
informatisées) Suivi de l’éclatement
Codification commune de la facturation et des
des obj ets (GE NCOD) règlements
B to C
Identification palette (SSCC Contrats et avenants à
Serial Shipping Container Code) suivre sur la durée
Maîtrise de la dégradation
de la marge : TMP (Taux moyen Difficulté pour connaître les Garantie et maintenance
promotionnel), RFA (Remise de clients et leurs besoins Vendre des produits
fin d’année) Problème du paiement : standards
Éclatement de la notion de sécurité réciproque ou à la commande
client : du référencement au Problème de la logistique :
règlement de la facture après la commande la livraison
Maîtrise des coûts logistiques
SCM (supply chain management) :
aller jusqu’au fournisseur du
fournisseur
DCM (Demand chain management) :
aller jusqu’au client du client

53
1 CHAPITRE 2 – Structure du système d’information
PARTIE

a) Commercialisation par les enseignes de la grande distribution


La distribution en libre-service concerne aujourd’hui tous les biens de consommations
finales, qu’ils s’agissent de produits ou de services, qu’il s’agisse de biens de consommations
courantes ou d’équipements du foyer.
Les entreprises qui fournissent les distributeurs appartiennent aux secteurs de l’agroali-
mentaire, de la pharmacie, aux cosmétiques, mais également à l’électroménager, aux articles
de sports, au vêtement, au domaine de l’assurance, des agences de voyages ou des articles
culturels. Cette liste n’est pas limitative.
Tous ces produits et services ne présentent pas les mêmes caractéristiques.
Il faut distinguer :
■ Les produits de consommation courante, à date limite d’utilisation optimale (DLUO),
présents dans les linéaires en libre-service et identifiables par leur packaging
Les conséquences des dates de péremption des produits sur la gestion et, par conséquent,
sur le système d’information sont très lourdes. Le point essentiel, c’est la nécessité d’une
gestion des stocks qui ne se fasse pas par produits mais par lots. On appellera lot une
quantité d’un certain produit fabriqué à une certaine date par un fabricant.

EXEMPLE
Le chef du rayon ultra-frais d’un magasin en libre-service ne gérera pas son stock de packs de yaourts
aux fruits Danone par 16, mais saura qu’il a encore 50 paquets dont la date de validité sera atteinte
dans 5 jours et 100 paquets dont la date de validité expire dans 2 semaines. Il fera le réassortiment
du rayon en conséquence, afin que les clients prennent en priorité les produits les plus rapidement
périmés. Sa méthode de gestion des stocks consistera à faire du FIFO (premier entré - premier sorti) de
manière physique. Ce ne sera pas uniquement une manière de procéder abstraite pour l’évaluation du
stock à un moment donné. Il s’agira d’une méthode de gestion physique des stocks.
Il aura également besoin que le système d’information l’alerte sur le vieillissement anormal de
certains lots, car les produits vont perdre totalement leur valeur à leur date de péremption.
Garder en rayon des produits ayant dépassé leur date limite fait courir un risque au client et, en cas
de contrôle par la répression des fraudes, le commerçant risque des amendes.
Il aura également besoin d’alertes sur le non-respect des dates de péremption des produits livrés, au
moment de la livraison par le fabricant. En effet, cela fait partie des conditions négociées avec le
fournisseur et doit motiver un refus de la marchandise.
Il sera amené :
– à vouloir déterminer un résultat au niveau du lot en comparant le chiffre d’affaires réalisé au coût
d’achat (prix d’achat au fournisseur + frais accessoires à l’achat),
– à gérer les flux au niveau du lot et non du produit. Il en sera de même pour les stocks, qui constituent
la résultante des flux d’entrée et de sortie d’une période.
Les méthodes de gestion du chef de rayon chez le distributeur vont bien évidemment devoir être appli-
quées sur une plus grande échelle et avec encore plus de rigueur chez le fabricant.

L’exemple qui précède montre que des règles de gestion particulières à ce type de situation
doivent être prises en compte dans le système d’information, afin qu’il puisse tenir son rôle.
Il faut rappeler qu’actuellement, et notamment en France, les préoccupations en matière de
santé publique ont un impact très fort sur les fabricants des produits de toutes natures et sur
les distributeurs de ces produits.

54
CHAPITRE 2 – Structure du système d’information 1
PARTIE

EXEMPLE
Lorsque des produits charcutiers ou fromagers ont été mis en cause, du fait de listeria ou de salmo-
nelles ayant entraîné des hospitalisations voire des décès, les fabricants et les distributeurs ont dû
prendre des mesures de retraits des produits. Cela a semé le doute autant sur les enseignes de commer-
cialisation que sur les marques des fabricants, pendant plusieurs semaines.

EXEMPLE
En France, les consommateurs ne sont pas favorables aux OGM. Les principales enseignes de la distri-
bution sont donc très strictes dans leurs cahiers des charges, concernant les produits alimentaires,
notamment ceux qui portent leurs marques. Elles refusent toute trace d’OGM dans les matières direc-
tement ou indirectement utilisées dans la fabrication du produit. Une entreprise, qui utilisait du rhum
vieilli pour faire macérer des raisins secs entrant dans la composition d’une crème glacée, a dû
démontrer qu’il n’y avait pas d’OGM dans le glucose de maïs qui permettait de fabriquer le caramel
qui colorait le rhum utilisé pour la macération des raisins secs.

Le système d’information des fabricants de produits agroalimentaires, sous la pression des


enseignes de la distribution, doit permettre de manière instantanée de fournir la traçabilité
amont et aval des lots de produits fabriqués et livrés.

EXEMPLE
Il y a quelques années, on a découvert en Belgique que certains poulets avaient été contaminés par
de la dioxine. Cela avait des conséquences sur la viande des poulets, mais également sur les œufs
pondus par les poules pendant cette période. Lorsque cette information a été divulguée, les grandes
enseignes ont mis en demeure leurs fabricants, qui étaient susceptibles d’avoir utilisé dans leurs
matières premières dans les 6 mois précédents les poulets ou les œufs incriminés, de fournir la preuve,
en moins de 4 heures, que ce n’était pas le cas dans les lots de produits qui leur avaient été livrés.
Si la preuve n’était pas apportée dans ce délai, ils devaient reprendre tous leurs produits chez le
distributeur.

■ Les produits d’équipements, à cycle de vie et marge réduits


Ces produits ne comportent pas de DLUO et ne comportent pas de risque économique lié
à l’innovation par le biais de la modification du packaging.
Par contre, ils correspondent en général :
– à des produits en phase de maturité ;
– au cycle de vie de plus en plus court ;
– avec des marges étroites ayant nécessité une opération de « redesign to cost » afin de
pouvoir les positionner sur le canal de distribution en libre-service.
Les enseignes demanderont, comme dans le cas des produits précédents, la traçabilité
concernant l’application des normes et règlements en matière de sécurité et l’application
des règles en matière de recyclage en fin de vie ou de recyclage des emballages.
Elles négocieront des volumes de produits pour des opérations promotionnelles, qui
obligeront le fabricant à anticiper la production et à stocker, mais également à faire des
tarifs très préférentiels avec des marges extrêmement réduites, en contrepartie de la garantie
de volume. WEB AMDEC • Éco emballage – http://www.ecoemballages.fr

55
1 CHAPITRE 2 – Structure du système d’information
PARTIE

■ Les services et produits culturels


Les grandes enseignes de la distribution se développent de plus en plus sur des activités de
services, tels que les activités bancaires, d’assurance, de voyages et de loisirs.
Elles consacrent une part importante de leur surface de ventes, dans les enseignes non
spécialisées, aux produits de loisirs et de cultures. On voit également des enseignes se
développer spécifiquement dans ces secteurs de la consommation.
■ Caractéristiques communes aux relations avec la distribution moderne
en libre-service
• L’éclatement de la notion de client
Ce type d’entreprise de distribution contemporaine correspond à un mode de commerce
où la notion de client est éclatée.
Le choix des produits qui seront présents sur les linéaires (processus de référencement) est
le fait d’une centrale d’achat (régionale, nationale ou internationale).
La fonction logistique du commerce (passation des commandes, gestion de la livraison,
stockage, dégroupage) constitue le métier de plateformes logistiques. Celles-ci sont le plus
souvent indépendantes juridiquement de l’enseigne de distribution.
Les magasins, ou points de vente, ne font qu’assurer la mise à disposition vers le consom-
mateur final.
Ce circuit complexe connaît différentes variantes d’une enseigne à l’autre.

EXEMPLE
Fonctionnement en mode dépôt-vente avec l’enseigne Auchan.
Le schéma ci-dessous montre les rôles des différents acteurs, qui reconstituent ce que l’on appelait
antérieurement la notion de client unique.
Les conséquences de cet éclatement de la relation commerciale sont nombreuses.
Prenons l’exemple de la facturation aux magasins, avec une facture par bon de livraison de la plate-
forme logistique au lieu de la facturation des livraisons effectuées aux plateformes.
Il y a environ 5 plateformes logistiques pour environ 150 points de ventes. Les plateformes sont livrées
deux fois par semaine pour l’ensemble des produits référencés, ce qui représenterait une dizaine de
factures à établir par semaine. Les magasins sont livrés au minimum 5 fois pas semaine par les plate-
formes. En fait, il faudra établir entre 750 et 900 factures par semaine !
Envisageons ensuite la gestion des règlements des factures, qui sont effectués par la centrale d’achat,
sous forme d’un billet à ordre relevé décadaire, qui correspond donc à chaque fois à plusieurs
centaines de factures émises pour les magasins, et qui sont des montants souvent identiques.
Le système nécessite d’ouvrir des comptes pour tous les magasins afin de pouvoir suivre la factu-
ration et les avoirs éventuels. La comptabilisation automatique des factures à partir de l’appli-
cation de gestion commerciale va donc mouvementer 150 comptes de tiers différents à chaque
facturation.
Il faudra imputer les règlements qui seront comptabilisés à l’origine sur le compte de la centrale, sur
les factures des magasins et procéder au lettrage des comptes.
Si aucun automatisme n’est en place, il faudra faire un travail manuel et passer des écritures de
virement pour solde, entre le compte de la centrale, qui règle mais ne doit rien et les 150 comptes
des magasins, qui doivent des factures mais ne les règlent pas. Le fait de n’avoir qu’un seul

56
CHAPITRE 2 – Structure du système d’information 1
PARTIE

compte ne faciliterait pas la gestion quotidienne de l’administration des ventes ; Comment


répondre à un magasin au sujet d’un avoir ou d’une contestation de facture, si l’on a dans un
compte unique des milliers d’écritures ! Le compte de chaque magasin possédera déjà environ
300 factures et avoir par an. Il sera donc fondamental de pouvoir lettrer les pièces au fur et à
mesure des règlements.
Dans une telle situation, soit le système d’information permet de mettre en place des automatismes,
soit il faudra consacrer un poste de travail supplémentaire à la gestion de ces magasins.

FONCTIONNEMENT EN MODE DÉPÔT-VENTE

Fournisseur 6 – Facturation du magasin


1 – Référencement du par BL plateforme
produit charte tarifaire

8 – Règlement des 7 – Transmission des


factures des magasins factures bonnes à payer
Centrale par BOR décadaires
d’achat Magasin
3 – Livraison en dépôt
vente 5 – Transmission du
double du BL au
2 – Commandes EDI par
magasin en EDI
chaque plateforme 4 – Livraison dégroupée
au magasin avec BL
Plateforme de la plateforme
logistique

• L’ouverture des systèmes d’information


Dans les relations commerciales entre fournisseur et enseigne de la distribution, il est de
plus en plus obligatoire de recourir à une transmission d’information immédiate entre les
différents partenaires du circuit, transmission qui se fait grâce à l’EDI (Échange de Données
Informatisées).
Cette méthode présente les avantages suivants :
– Désynchronisation de l’émission et de la réception du message
Il n’est pas nécessaire que les partenaires établissent une communication explicite simul-
tanée. Le système de la messagerie permet que l’émetteur et le destinataire désynchronisent
leurs actions d’émission et de réception.
– Standardisation de la structure des messages
Le recours à une structure standardisée des messages permet de simplifier les problèmes de
traduction et de trouver facilement des logiciels de communication adaptés aux besoins.
Chaque nature de messages pouvant intervenir entre les partenaires fait l’objet d’une
structure standardisée qui permet de dématérialiser les différentes opérations du cycle de
vie du contrat de vente, par exemple, dans le cadre des relations commerciales.

57
1 CHAPITRE 2 – Structure du système d’information
PARTIE

– Sécurisation de la transmission des messages


Les protocoles de messagerie utilisés sont acquittés et sécurisés. Cela signifie que l’émetteur
sait quand le destinataire a relevé sa boîte et que les messages ne peuvent pas se perdre à
cause d’un défaut de transmission sur le circuit entre émetteur et destinataire.
– Existence d’un cadre contractuel entre les partenaires
Une convention d’interchange est signée entre les partenaires, qui permet de définir les
conditions de fonctionnement de leur relation : fréquence de relevé des messages,
amplitude horaire d’accès à la messagerie, circonstances d’émission de chaque type de
messages, champs utilisés dans la structure standard proposée et contenu attendu.
– Référentiel commun pour les produits et les acteurs
Une codification commune des acteurs et des produits est mise en place, avec l’organisme
GENCOD, qui permet d’identifier les différents intervenants et les produits concernés.
Compte tenu de l’éclatement de la notion de client la codification des interlocuteurs porte
le nom de code « lieu fonction ». En effet, il permet d’identifier une structure économique
et juridique (le lieu) et un rôle joué dans la relation (la fonction). 6 codes lieux fonctions
différents peuvent être référencés dans un message, en fonction de leur position dans la
structure du message.

TABLEAU DES RÔLES ASSOCIÉS AUX CODES LIEU FONCTION DANS UN MESSAGE DE COMMANDE

Il peut s’agir du magasin ou d’un service central


Acteur qui passe la commande
ou régional.
Permet de vérifier que le message que l’on reçoit
Fournisseur destinataire de la commande
nous concerne bien.
Acteur destinataire de l’accusé de réception Il peut s’agir de l’acteur qui a passé la commande
de commande, annonçant la livraison ou d’une plateforme logistique.
Il peut s’agir du magasin, dune centrale nationale
Acteur qui est livré ou régionale ou d’une plateforme logistique indé-
pendante de l’enseigne.
Les factures peuvent être envoyées à la centrale, à la
plateforme, au magasin. Elles peuvent être ensuite
Acteur qui reçoit la facture envoyées à l’acteur qui réceptionne ou utilise les
marchandises pour contrôle et validation du bon à
payer.
Il peut s’agir de différents acteurs, en charge
Acteur qui est destinataire de la facture
de contrôler et de valider la facture.
Il peut s’agir d’une centrale d’achat ou
Acteur qui règle la facture
de la plateforme ou du magasin.

58
CHAPITRE 2 – Structure du système d’information 1
PARTIE

L’ÉCHANGE DE DONNÉES INFORMATISÉ

Des messages
Un réseau de standards adaptés aux Une
communication : différentes opérations codification
X400 ou Web commune

Gencod
Code lieu
fonction
EDI

Une norme
de messages Une organisation
Edifac de l’ISO définie par la
convention
Des d’interchange
logiciels

Communication
Traduction
Interfaces

Mais elle présente également des difficultés qu’il faut gérer donc connaître et évaluer.
• Le recours à plusieurs logiciels
Intégrer les flux d’information EDI dans la gestion commerciale oblige à empiler l’utili-
sation de progiciels.

LES DIFFÉRENTS LOGICIELS UTILISÉS EN EDI ET LEURS RÔLES

Type de logiciel Fonctions


Un logiciel Il permet d’atteindre la messagerie pour lire ou écrire les messages.
de communication
Un logiciel de traduction Il permet de retranscrire le contenu des messages en fichiers plats. La norme ISO de
message EDI utilisée dans le commerce est la norme Edifac. Les structures stan-
dards des messages prévoient la possibilité d’insérer de très nombreuses informa-
tions, mais celles-ci ne sont pas obligatoires, donc pas toujours utilisées. Les
messages transmis ont une structure définie dans la convention d’inter change. On
peut donc paramétrer leur traduction à partir de ces descriptifs. Le contenu de cha-
que zone peut être repéré à l’aide de balises. À l’issue de la traduction et quel que
soit le partenaire, l’entreprise possédera un fichier plat (ou fichier texte) qui
comportera des enregistrements de longueur fixe avec des zones séparées par un
caractère choisi.

59
1 CHAPITRE 2 – Structure du système d’information
PARTIE


LES DIFFÉRENTS LOGICIELS UTILISÉS EN EDI ET LEURS RÔLES

Type de logiciel Fonctions


Une application d’interface • Les partenaires, à partir de leur code lieu fonction.
avec l’application de gestion Un tiers peut avoir plusieurs fonctions qui doivent figurer dans la fiche du client
commerciale. avec le code lieu fonction qui lui est attribué pour les messages EDI.
Cette interface permet • Les produits à partir de leur GENCOD relatif à l’unité considérée : UVC ou unité
de faire correspondre de vente au consommateur (la boîte), UL ou unité de livraison au distributeur (le
les champs des fichiers plats carton), US ou unité de stockage (la palette).
avec les champs • En cas d’erreur d’identification, l’interface doit fournir un état des anomalies qui
correspondants dans la base sera exploité manuellement. On pourrait envisager d’éviter des correspondances
de données. d’identification entre le code interne et le GENCOD des produits et des parte-
Elle permet également naires. Cela éviterait les erreurs de reconnaissance des objets dans les messages.
d’effectuer les contrôles Cette solution qui peut paraître évidente, présente des difficultés de mise en
nécessaires pour identifier œuvre. En premier lieu, elle s’oppose à des dizaines d’années d’habitude des
les données de différentes entreprises dans leur manière d’identifier les produits et les tiers. Ensuite, la taille
natures. des GENCOD étant importante (minimum 13 caractères), elle peut poser des
problèmes de saisie dans certaines applications informatiques, qui n’en permet-
traient pas l’utilisation en tant qu’identifiant principal.

• La nécessité d’une organisation rigoureuse chez les partenaires


Échanger des données entre partenaires implique une organisation rigoureuse entre les
structures qui échangent l’information. En principe, cette organisation est prévue par la
convention d’interchange. Dans la réalité, il y a de nombreux dysfonctionnements dans la
transmission des informations entre les partenaires, qui perturbent le fonctionnement du
système de l’EDI, le rend compliqué à utiliser et coûteux par le nombre d’interventions
manuelles nécessaires pour corriger les anomalies des données.

EXEMPLE
La convention d’interchange prévoit la manière d’insérer un nouveau référencement dans la prise de
commande EDI. La centrale d’achat doit transmettre le résultat de ses choix, avec les données corres-
pondantes, au service central qui effectue les commandes EDI pour l’ensemble de l’enseigne. Le
fabricant constate à la mise en place d’un nouveau référencement que les commandes de ce produit
interviennent par fax. Il est obligé de contacter le service EDI de l’enseigne pour lui fournir les informa-
tions nécessaires à l’intégration de ce produit dans les messages.
Lors de messages de commandes d’une enseigne émanant d’une plateforme logistique, un message
est rejeté en anomalie, le magasin concerné par la livraison à facturer étant inconnu. Normalement,
la convention d’interchange de l’enseigne prévoyait qu’une information soit diffusée à la création
d’un nouveau magasin à l’ensemble des partenaires concernés. Cette procédure n’ayant pas été
respectée, le fournisseur a dû effectuer un traitement manuel : contacter la plateforme, auteur du
message, qui a répété pour la nième fois qu’il s’agissait du nouveau magasin de X.

Tous ces dysfonctionnements, qui n’ont pas une origine technique mais organisationnelle,
font perdre actuellement beaucoup de son intérêt à l’utilisation de l’EDI. Ils représentent un
coût de traitement des anomalies très important chez les partenaires.

60
CHAPITRE 2 – Structure du système d’information 1
PARTIE

■ L’influence sur les méthodes de gestion


• La gestion par lots des articles
La gestion par lots se répand en dehors des entreprises dont les produits sont soumis à une
date de péremption. Pour des raisons de traçabilité dans le cadre du contrôle qualité (norme
ISO 9000), les entreprises sont contraintes d’isoler des lots de fabrication ou d’achats de
matières premières et de marchandises. Cette volonté d’isoler un lot d’articles livré ou
fabriqué entraîne des conséquences sur la structure des données à gérer, donc sur la
complexité requise du système d’information.
Le schéma ci-dessous montre la différence de structure de données et de modalités de
gestion des flux et des stocks dans l’optique gestion par produit et dans l’optique gestion par
lots de produits.
Pour pouvoir mettre en place une gestion par lots de produits, il est impératif que le système
d’information possède le niveau de complexité du schéma de droite.

MÉTHODES DE GESTION DES ARTICLES

Flux d'entrée
Produit X

Synthèse
Produit X des stocks
Flux d'entrée
Niveau du stock
Évaluation du stock
Lot 1 Lot 2 Lot 3
Niveau Niveau Niveau
Flux de sortie et évaluation et évaluation et évaluation
du stock du stock du stock

Flux de sortie

Gestion par produit Gestion par lots

WEB EDI – http://www.commentcamarche.net/entreprise/edi.php3


• Le suivi des marges et de leur dégradation
Les relations avec la grande distribution présentent des contraintes et des risques en matière
commerciale qui doivent être gérés avec précision par le fournisseur.
– Les mentions de la charte tarifaire
Depuis 1996 et la loi Galland, la discrimination tarifaire est interdite. Cela signifie qu’un
fabricant doit posséder un tarif général publié pour ses produits. Il doit rédiger une charte
tarifaire pour y déroger expliquant et motivant les conditions particulières accordées pour
des raisons de volume, de groupage des livraisons, de mise en avant de sa marque, etc. La
négociation avec une enseigne de la grande distribution aboutira donc à la rédaction d’une
charte tarifaire pour chaque référencement, qui fixera le cadre concernant les volumes, les
tarifs, les opérations promotionnelles, etc. WEB loi Galland

61
1 CHAPITRE 2 – Structure du système d’information
PARTIE

– Les taux moyens promotionnels garantis


La négociation avec les enseignes prévoit, en général, un taux moyen promotionnel garanti.
Cela signifie que deux prix de base de facturation vont être prévus, le prix normal et le prix
promotionnel. L’enseigne va décider de faire dans le courant de l’année un certain nombre
d’opérations de promotions. En fin d’année, cela doit correspondre à un taux moyen de
promotion, prévu à la charte tarifaire, sur l’ensemble des ventes.

EXEMPLE
Le produit est vendu 2 € HT au tarif normal et 1,60 € pendant les opérations de promotions, soit
un prix inférieur de 20 %. Compte tenu des volumes qui seront écoulés pendant les périodes
normales et pendant les périodes promotionnelles, il faudra en fin d’année que cela corresponde à
une facturation moyenne de 1,94 € toute l’année, soit un taux moyen promotionnel garanti de
3 %. Si ce taux est supérieur parce qu’il y a eu un gros volume de promotion, l’enseigne est censée
rembourser la différence. Cela reste, dans la plupart des cas, théorique. Par contre, si ce taux est
inférieur, l’enseigne demandera un avoir de la différence au fournisseur. Celui-ci perdra donc sur les
deux tableaux, il devra rembourser une partie de sa facturation à l’enseigne et, compte tenu de
l’insuffisance des périodes promotionnelles, il aura certainement vendu un plus faible volume qu’il
n’aurait pu.

Cela implique une gestion mensuelle des taux moyens promotionnels par la direction
commerciale du fournisseur, en fonction des différentes chartes tarifaires. Il faut donc
pouvoir paramétrer les conditions commerciales. Si le système d’information ne permet pas
ce suivi, soit il n’y aura pas de suivi du tout, soit le suivi sera réalisé manuellement, avec des
saisies de données à partir de la facturation et des tableaux Excel. Cela représentera un coût
récurrent en heures de travail.
– Le passage du prix de vente brut au prix de vente net net
Fournir des produits aux enseignes de la grande distribution nécessite d’avoir un système
de calcul des marges spécifique et puissant. En effet, la marge du fabricant ne correspond
pas à un différentiel entre son prix de facturation brut, qui figure sur chaque ligne de
facture, et son coût de revient. De nombreux phénomènes interviennent qui ne
permettent de connaître le produit réalisé qu’en fin d’année. En dehors du mécanisme du
taux moyen promotionnel garanti, il peut exister des remises annuelles, calculées sur des
tranches de chiffre d’affaires ou de volumes de ventes, avec des formules de calcul diverses
et compliquées. De surcroît, le fabricant peut participer financièrement à des opérations
ponctuelles de mise en avant de ses produits, comme l’impression et la distribution de
tracts pour des opérations commerciales organisées par l’enseigne et qui présente son
produit, ou des opérations de démonstration dans les points de vente en bouts de
gondoles.
Bien que le prix net net, toutes remises déduites et toutes opérations commerciales prises en
compte, ne puisse être déterminé qu’en fin d’année, il est important de pouvoir disposer
d’informations sur l’évolution des données commerciales sur une base mensuelle. Cela
évite les mauvaises surprises en fin d’année, permet de provisionner les avoirs correspon-
dants aux remises « arrières » de fin d’année. Cela permet également de vérifier que les
données contractuelles de la charte tarifaire sont bien appliquées.

62
CHAPITRE 2 – Structure du système d’information 1
PARTIE

EXEMPLE
La charte tarifaire prévoit une remise logistique de 10 % par rapport au tarif général, parce que
l’enseigne s’engage à passer des commandes qui permettent une livraison des plateformes par
camions complets (35 tonnes ou 32 m 3). Le tarif étant franco de port, les volumes de commandes
sont très importants pour le fournisseur. Les transporteurs ont des tarifs à la palette, pour une
distance donnée, qui sont très différents en fonction du nombre de palettes à livrer. Il est donc très
important de savoir, en permanence, dans quelle mesure les conditions de la charte tarifaire sont
bien appliquées.

Dans ce domaine, comme précédemment, si la complexité du système d’information ne lui


permet pas de produire directement ces tableaux de bord, soit on n’aura pas de suivi, soit
celui-ci demandera une intervention manuelle récurrente et coûteuse en temps de travail et
en délai d’obtention des résultats.
– Le risque économique sur les emballages
L’innovation dans les produits de consommation courante distribués en libre-service sur
les linéaires de la grande distribution est fréquente. Les produits référencés ont des
durées de vie très courte, souvent une année ou une saison. Les évolutions sont réalisées
essentiellement dans le packaging ou par la multiplication des variantes d’un même
produit.
Il y a de nombreuses conséquences économiques à cette situation, qui correspondent à des
risques pour le fabricant.
Le nombre de références d’emballages à gérer est très important. Il existe souvent 10 fois
plus de références d’emballages que de matières premières.
Les emballages sont le plus souvent spécifiques pour un produit. Leur stock perd totalement
sa valeur lors d’une décision de changement de packaging. La formule du produit est, en
général, imprimée sur l’emballage, ce qui interdit la modification de la composition du
produit de manière indépendante de celle de l’emballage. Toute modification du produit
perceptible par le consommateur doit entraîner une modification de son GENCOD, donc
du code à barres imprimé sur l’emballage pour le passage en caisse, en appel prix. On ne
peut rien modifier dans le produit sans modifier son emballage. La conception marketing et
graphique d’un nouvel emballage a un coût important. Les délais de fabrication d’un
emballage sont relativement longs (2 à 3 mois fréquemment) et les tarifs sont fortement
dégressifs en fonction des quantités, compte tenu des conditions de réglages des impres-
sions en couleurs.
Tous les éléments qui précèdent démontrent l’importance de la gestion des emballages qui,
grâce à la publicité présentant les produits mis en linéaires, en facilite leur reconnaissance
instantanée.
Le système d’information doit fournir les outils de suivi des emballages qui permettent de
réduire les coûts et d’affiner les prévisions, afin de limiter le risque.
b) Commercialisation B to C, Business to Consumer
Ce mode de commercialisation correspond à la vente par correspondance (VPC) qui a
évolué vers l’e-commerce, vente par Internet, et qui concerne de nouveaux produits et
services.

63
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Le développement de ce mode de commercialisation, qui connaît un très grand dévelop-


pement et qui devrait continuer à connaître une très forte croissance, ne s’est cependant pas
révélé être la traînée de poudre qui était annoncée. Il y a à cela différentes raisons, exposées
ci-dessous.
Afin de résoudre ces problèmes qui constituent des freins au développement de ce circuit de
distribution, on voit qu’il faut disposer des outils nécessaires dans le système d’information.
On constate aisément, par comparaison, que la gestion commerciale de ce circuit n’a aucun
point commun avec la précédente.
■ Premier problème à résoudre : la difficulté pour connaître les clients et leurs besoins
Le fournisseur ne rencontre jamais son client. Il n’y a pas de phase de négociation dans la
vente. Le produit n’a pas d’action directe sur l’acte d’achat puisqu’il n’y a pas de contact
direct entre le client et le produit. Au mieux le client pourra voir une photographie, ou une
vidéo, et un descriptif du produit qu’il envisage d’acquérir. Cela ne permet d’activer qu’un
ou deux de ses organes des sens, la vue et, éventuellement, l’ouie. De plus cette perception
sera partielle. Cela peut être un handicap.

EXEMPLE
Lorsque l’on veut acquérir un vêtement ou des chaussures, on souhaite assez généralement essayer.
Cela permet de s’assurer de la taille, mais également de l’adaptation de la coupe. On recherche la
réponse à la question : « est-ce que cela me va ? ». Pour cela, il faut porter l’objet sur soi. Certes, on
peut, lorsqu’on commande, renvoyer si cela ne convient pas, mais cela complique les choses et
rallonge le délai pour obtenir l’objet qui conviendra.
Lorsque l’on veut acquérir un meuble, il est agréable de pouvoir le toucher, prendre conscience de la
masse et du volume qu’il représente, pour évaluer son positionnement dans la pièce.
Et même, lorsque l’on veut acquérir un livre, on aime bien pouvoir le feuilleter.

Le contact physique avec l’objet acheté est très important pour la plupart des consomma-
teurs et la plupart des objets. Il est possible que les habitudes d’achats se modifient. Il est
cependant probable que cela reste un frein dans certains domaines, car la relation à l’objet
fait appel à tous les sens de l’être humain et ce circuit de distribution présentera des lacunes
dans ce domaine.
La relation commerciale va se développer de manière indirecte, à travers le site commercial
sur Internet.
Pour que cette relation soit efficace, le fournisseur doit résoudre un certain nombre de
problèmes :
• Adapter le site au comportement des clients potentiels
Il faut notamment offrir une méthode de recherche sur son site commercial, qui corres-
ponde au mode de raisonnement des clients, lorsqu’ils font une recherche. Au bout d’un
temps assez court, si le visiteur du site ne trouve pas ce qu’il cherche, il abandonne et ne
reviendra plus.
• Se servir des informations collectées sur le site
pour étudier le comportement des consommateurs
Il faudra récupérer de l’information sur le comportement d’achat du visiteur, par le biais de
son comportement sur le site.

64
CHAPITRE 2 – Structure du système d’information 1
PARTIE

• Essayer de pousser la vente comme dans une surface de ventes en libre-service


Le but est d’accroître la valeur du panier moyen en proposant des achats liés ou connexes,
au fur et à mesure de la commande du client connecté.

EXEMPLE
Lors d’une commande de livres sur le site d’Amazon, le client est incité à étendre son panier d’achats,
car on lui propose de manière automatique des ouvrages qui correspondent aux thématiques qu’il a
achetées antérieurement et des ouvrages qui sont corrélés, dans les achats des clients du site, à celui
qu’il vient d’insérer dans son panier. De plus, dans la mesure où le client accepte de recevoir des publi-
cités par mail, il recevra des informations régulières sur les offres correspondant à ces choix antérieurs,
que le distributeur assimile à une perception de ses goûts.

■ Deuxième problème à résoudre : le paiement, recherche de sécurité réciproque


L’absence de relation directe dans la vente entre le distributeur et le client implique que le
règlement de l’achat intervienne avant la livraison. Le site marchand proposera un
règlement par carte bancaire ou en utilisant une carte de crédit « revolving » associée au site
marchand. Le vendeur pourra donc vérifier la solvabilité et obtenir la garantie du paiement
de l’achat, avant la livraison.
Par contre, le client, qui est amené à donner le numéro de sa carte bancaire sur un site
Internet, doit avoir une garantie de paiement sécurisé. Il n’y a pas de contrôle de son
identité, ni du fait qu’il soit le véritable possesseur de la carte. C’est pourquoi les sites de
paiement en ligne utilisent un protocole sécurisé et demandent le plus souvent les 3 derniers
chiffres du cryptogramme au dos de la carte. Part. 3, chap. 11

■ Troisième problème à résoudre : la logistique :


après la prise de commande, les conditions de la livraison
L’achat en ligne par Internet présente des avantages pour le client, qui ne doivent pas être
contrebalancés par les inconvénients.

AVANTAGES ET INCONVÉNIENTS USUELS DE L’ACHAT EN LIGNE

Avantages pour le client

Avoir une meilleure connaissance Il peut accéder à différents sites concurrents rapide-
des offres qui lui sont proposées. ment et facilement, avec les moteurs de recherche.

Ne pas se déplacer pour acheter. C’est un mode d’achat accessible de n’importe quel
endroit, économisant l’énergie et sans nuisance pour
l’environnement.

Gagner du temps pour passer sa commande. On peut passer une commande rapidement et à
n’importe quel moment. Il n’y a pas d’horaire
d’ouverture. ☞

65
1 CHAPITRE 2 – Structure du système d’information
PARTIE


Réduire le coût de passation de sa Les abonnements à l’accès à Internet ont un coût
commande. modique et forfaitaire. On évite une communication
ou un envoi postal qui représente un coût supplémen-
taire à chaque commande.
Disposer d’un suivi de sa commande. On peut suivre de manière autonome, à n’importe quel
moment le traitement de sa commande.
Inconvénients pour le client
Tarif plus élevé pour le même produit De nombreuses enseignes ont un tarif plus élevé pour
ou le même service qu’en magasin. amortir les frais de fonctionnement de leur site. L’alter-
native est le recours à la publicité, qui peut être enva-
hissante pour l’internaute.
Offre produits ou services différente, On ne trouve pas toujours le même catalogue de
en général plus réduite qu’en magasin. produits sur Internet et dans le magasin.
Délai de livraison relativement long. Passer la commande est très rapide, mais il arrive
souvent que la livraison soit longue. Afin de minimi-
ser les frais de livraisons, les sites proposent un envoi
groupé de l’ensemble des articles commandés.
L’internaute ne maîtrise pas la disponibilité des
produits, bien que les sites donnent souvent une
information indicative sur ce point. L’internaute peut
attendre très longtemps une livraison qui lui a
demandé quelques minutes à passer.
Frais élevés, liés à la livraison à domicile. L’économie réalisée lors de la passation de la com-
mande peut être largement compensée par les frais de
livraisons facturés par le fournisseur.

Il est donc important pour le vendeur d’analyser les freins et motivations de ses clients dans
ce domaine, afin que son site marchand se développe et lui amène le chiffre d’affaires
espéré.
Il doit avoir une offre lisible et des services logistiques associés qui semblent cohérents au
client en termes :
– de possibilité de se faire livrer à domicile ;
– de délais de livraison ;
– de coût supplémentaire supporté pour la livraison.

EXEMPLE
Certaines enseignes de produits spécialisés dans la culture et les produits techniques proposent à côté
de leurs magasins une possibilité de vente en ligne. Le catalogue de produits proposés est différent.
Pour certains services les avantages tarifaires de la carte adhérent ne sont pas appliqués lors d’achat
en ligne pour le même produit ou service, alors que l’achat en magasin en fait bénéficier.
C’est une volonté stratégique de ne pas cannibaliser la distribution en magasin avec la vente en ligne.
Cependant, c’est un frein pour le client dans l’utilisation de l’achat en ligne. Lorsqu’il aura constaté ces
inconvénients, sa réaction peut être globale. Il n’achètera plus en ligne sur ce site, ayant l’impression
d’être trompé. Mais il ira peut-être également à la concurrence pour ses achats en magasin.

66
CHAPITRE 2 – Structure du système d’information 1
PARTIE

EXEMPLE
Lors du lancement de son site marchand une compagnie de transport ne proposait pas l’envoi des
billets à domicile. Il fallait les retirer sur place au moment du départ ce qui impliquait d’arriver une
heure avant le départ. L’avantage de l’achat en ligne pouvait donc paraître compensé par l’inconvé-
nient de devoir anticiper son départ.
WEB e-commerce
En conclusion, la possibilité de gérer l’ensemble des problèmes liés à la commercialisation
en B to C repose sur la disponibilité d’un système d’information adapté à ce mode de vente.
Compte tenu de l’absence totale de contact direct entre le client et le fournisseur, l’existence
de ce système d’information constitue même le facteur clé de succès de ce mode de distri-
bution.
c) Commercialisation B to B, Business to Business
Ce mode de commercialisation concerne la relation commerciale entre entreprises.
Il s’agit donc de produits et services de consommation intermédiaire, ou de biens d’équipe-
ments.
Lorsque cette commercialisation s’effectue par commerce électronique, elle peut faire
appel à la notion de place de marché (market place) qui permet aux offreurs de présenter
leurs produits et services et aux clients d’entrer en relation avec eux. Dans les grandes
entreprises industrielles, les acheteurs ont de plus en plus recours à ces places de marché,
qui peuvent être publiques ou privées. Sur le plan théorique, on pourrait dire que la
généralisation de ces sites permettrait de rétablir une des caractéristiques du marché de
concurrence, qui est l’information parfaite sur les conditions du marché. Sur le plan
pratique, on peut dire que c’est un gain de temps, donc une économie considérable, pour
les partenaires industriels de pouvoir porter à la connaissance des uns et des autres les
offres et les besoins.
En ce qui concerne l’incidence de l’utilisation de ces méthodes sur la structure du système
d’information ⇒ Part. 1, chap. 3, sect. 3

En dehors du recours à la technique de l’e-commerce dans le B to B, la démarche commer-


ciale entre entreprises présente des différences importantes par rapport aux deux situations
précédentes.
■ La négociation commerciale
Dans la plupart des cas, il y a une négociation commerciale qui porte sur les tarifs, les carac-
téristiques des produits et des services associés, les volumes d’achats et leur cadencement.
Cela aboutit à la conclusion de marchés annuels ou saisonniers. Cette gestion par marché
n’est pas propre au domaine public. Ce qui différencie les marchés privés des marchés
publics, c’est l’absence de réglementation. Cela signifie que les conditions du marché sont
uniquement contractuelles.
■ La charte portant sur la qualité
Dans la mesure où les entreprises mettent en œuvre une politique de la qualité, les condi-
tions contractuelles de l’achat, avec ou sans marché, interviennent dans l’évaluation du
fournisseur, qui permettra de renouveler ou non son référencement par le service achat du
client.

67
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Les produits ou prestations fournies ou les conditions de ventes sont fréquemment spéci-
fiques pour chaque client. Le contrat de vente est donc un document juridique complexe,
qui peut faire l’objet de l’intervention des services juridiques de partenaires et d’une
négociation longue.
Dans certains domaines relatifs à des industries lourdes fournissant des biens d’équipe-
ments, les contrats ont une durée de réalisation de plusieurs années. Cela entraîne une
gestion de la facturation d’appels de fonds périodiques, liés à des événements déclencheurs
spécifiques à chaque contrat. Cela exige un mode de gestion particulier.

EXEMPLE
Une entreprise de fabrication de crèmes glacées passe un marché avec un fabricant de plasturgie pour
un certain volume de bacs et couvercles en plastique pour l’année prochaine. Les tarifs sont négociés
en fonction des volumes et le fournisseur s’engage, dans le cadre des volumes et cadencements prévus
par le client, à avoir en permanence un stock tampon, afin d’éviter les ruptures de stock d’emballage
chez son client. Le contrat prévoit l’identification des produits par parfum (étiquettes parfum – fraise,
vanille – et marque du bac et du couvercle, posées au thermoformage, à partir d’étiquettes commandées
par le client à un imprimeur qui les livrent chez le plasturgiste).
Le système d’information va devoir permettre de suivre, entre autres :
– la réalisation des conditions du marché : quantités prévues, réellement utilisées, disponibles ;
– le calcul du coût d’achat du bac ou du couvercle étiqueté, qui inclut le coût facturé par le plastur-
giste, auquel s’ajoute le coût de l’étiquette facturé par l’imprimeur ;
– la gestion du stock d’étiquettes chez le plasturgiste et le rapprochement avec l’inventaire physique
de celui-ci, afin de savoir à quel moment il faudra passer des commandes à l’imprimeur et d’évaluer
le stock en fin d’exercice.

EXEMPLE
Lorsqu’Airbus Industrie négocie un contrat avec une compagnie aérienne, celui-ci peut entraîner :
– des commandes fermes ;
– des options.
En ce qui concerne les commandes fermes, elles sont cadencées sur plusieurs années.
Elles font l’objet d’appels de fonds, qu’il faut facturer aux échéances prévues et dont il faut suivre le
règlement.
Il faut pouvoir gérer précisément les incidences des différences de change. En effet, les clients sont
facturés en dollars US, alors que les coûts sont supportés en euros essentiellement. Il y a de plus un
décalage important dans le temps entre les produits et les charges.
WEB b to b – http://www.journaldunet.com/encyclopedie/definition
WEB place de marché – http://www.commentcamarche.net/entreprise/place-marche.php3
En conclusion, la commercialisation B to B entraînera la nécessité d’applications informa-
tiques particulières dans le système d’information de l’organisation. On peut même déduire
de ce qui précède qu’il ne pourra y avoir un seul type d’application utilisable pour tous les
types de commercialisation entre entreprises, les situations étant extrêmement variées.

68
CHAPITRE 2 – Structure du système d’information 1
PARTIE

1.3 Les différents modes de gestion

Rentabilité par produit


ou par affaire
Déterminer comment
se forme le résultat

Gestion par affaire Gestion par produit

Affaire : contrat, Entreprises diffusant


souvent issu d'un des produits ou des
devis, sur lequel se services standards
regroupe des produits (catalogues) conçus et
et des charges pour Gestion mixte mis en marché selon
déterminer un leur propre décision.
résultat. Toutes les entreprises
Entreprise en B to B vendant des produits
ou en B to C Entreprises possédant suivant les cas manufacturé de
travaillant à la les deux poins de vue. consommation
commande dans la Exemple : assurance courante ou
production de biens Gestion du client ou affaire sous l'angle d'équipement,
ou de services patrimoine et gestion des produits sous dont la plupart sont
l'angle risque et actuariat aujourd'hui distribués
par les circuits de la
distribution en libre-
service ou tout au
moins en GMS (Grands
Magasins Succursalistes)

a) Gestion par affaires


Dans de nombreuses entreprises, telles que les agences de publicité, de communication, de
marketing direct, ou même dans le bâtiment ou la fabrication mécanique de précision, on a
besoin d’analyser un résultat par affaires.

Une affaire est un contrat de vente. Mais ce qui distingue une « affaire » d’un autre contrat de vente,
c’est son caractère unique. Cela entraîne la nécessité pour le client d’exprimer formellement son
besoin sous la forme d’un cahier des charges et, pour le fournisseur, d’exprimer son offre sous
forme d’un devis ou d’une réponse à l’appel d’offres.

Certaines affaires peuvent posséder des caractéristiques qui en accroissent la complexité en


termes de gestion. Il s’agit de :
■ Leur durée de la réalisation
Celle-ci peut être de plusieurs années. C’est le cas dans des secteurs comme l’aéronautique,
la construction navale, les BTP.

69
1 CHAPITRE 2 – Structure du système d’information
PARTIE

■ La complexité de leur réalisation


Elle est liée au nombre de prestations de différentes natures que le fournisseur doit apporter
à son client. On trouvera ce type de problèmes dans la publicité, le merchandising.
■ Le fractionnement de la facturation et des règlements correspondants
Il nécessite une gestion des appels de fonds, spécifique de chaque affaire.
Le résultat, bénéfice ou perte, obtenu pour une affaire, sera issu de la confrontation entre :
■ Le chiffre d’affaires réalisé sur ce contrat
Il est complexe à suivre, pour les raisons décrites ci-dessus.

EXEMPLE
Dans le bâtiment, des appels de fonds sont prévus à chaque tranche de réalisation du chantier : à
l’obtention du permis de construire, au démarrage des travaux, à la mise hors d’eau, etc. Il y a une
retenue de garantie qu’il faut également gérer. Il faut pouvoir déclencher des appels de fonds au bon
moment, suivre leur règlement et leur solde sur la facture définitive.

■ Les charges affectées au contrat


Leurs origines et les natures sont diverses : commandes sous-traitées à des fournisseurs,
évaluation des temps passés par les salariés de l’entreprise, évaluation des prestations
fournies par l’entreprise elle-même.
Pour gérer correctement ce type d’activités, on aura donc besoin d’une application de
gestion par affaires.
Elle offrira la possibilité :
– d’un critère de regroupement, qui permette de suivre l’affectation à un contrat des
charges et des produits ;
– d’un processus de contrôle rigoureux des prestations facturées, afin d’éliminer les erreurs
d’imputation et les omissions.
Il sera également nécessaire de suivre l’affectation des moyens mis en œuvre, afin de
minimiser leur coût. On aura donc au niveau flux de sorties de stocks et au niveau de l’affec-
tation des temps hommes, besoin d’applications permettant d’imputer directement les
unités physiques à l’affaire et d’en fournir automatiquement une valorisation.

EXEMPLE
Dans le bâtiment, on souhaitera pouvoir :
– analyser les consommations de ciment ou de sable en fonction du type de chantier, ou les durées
d’utilisation des équipements : grues, pelleteuse, par rapport à leurs temps d’immobilisation sur le
chantier ;
– analyser la valeur ajoutée horaire des salariés, en fonction du type de construction.
Une PME du bâtiment, qui employait environ 300 salariés, ne s’était pas dotée d’une application de
gestion par affaires (ou par chantiers). Elle ne pouvait donc pas suivre les indicateurs définis ci-dessus.
Cela a induit des comportements néfastes des salariés, qui ont entraîné à long terme l’érosion des
marges, jusqu’au dépôt de bilan. Tout d’abord, les chefs de chantiers ont pris l’habitude d’immobi-
liser le matériel de chantier plus que nécessaire. S’ils avaient besoin d’une grue pendant deux
semaines avec une interruption entre les utilisations, ils ne rendaient pas le matériel disponible pour

70
CHAPITRE 2 – Structure du système d’information 1
PARTIE

un autre chantier pendant l’interruption. L’entreprise a dans un premier temps surinvesti. En consé-
quence, la rentabilité des capitaux investis a chuté. Ensuite, lorsque la situation économique s’est
dégradée, elle ne tenait plus les délais à cause de l’indisponibilité des équipements. En dehors de
l’insatisfaction des clients que cela provoquait, elle ne pouvait facturer les échéances dans les délais
prévus, ce qui aggravait ses problèmes de trésorerie. Un deuxième phénomène s’est développé à cause
du manque d’outils de contrôle adaptés. Les ouvriers sur les chantiers, s’apercevant qu’aucun
contrôle n’était effectué sur les matériaux utilisés, se sont mis à prélever des matériaux pour leur
propre usage. Il n’y avait pas non plus de contrôle sur les temps passés, donc les pauses sur les
chantiers se sont allongées petit à petit. La répétition de ces phénomènes a conduit à une baisse
progressive de la rentabilité.

En conclusion, la gestion par affaires est une nécessité dans certaines activités. En l’absence d’outils
de ce type dans le système d’information, on peut affirmer que l’entreprise court à sa perte.
Mais en dehors des entreprises dont l’activité relève de la gestion par affaires, le besoin d’une telle
gestion se généralise par l’adoption de la méthode projets, dans les organisations de tous types et de
toutes tailles.

Pour un exposé de cette méthode ⇒ Part. 2, chap. 6


Pour se développer, les organisations mènent un flux de projets qui leur permettent de
concevoir et de lancer de nouveaux produits et services. Actuellement, la plupart des
groupes industriels gèrent leur service Recherche et Développement par projets. Un projet
est assimilable à une affaire. Le contrôle de gestion R&D nécessite donc la disposition d’un
outil de type gestion par affaires dans le système d’information.
b) Gestion par produit ou par service
Cette gestion est plus classique. Il s’agit de gérer la rentabilité de produits et services
standard, au catalogue de l’entreprise.

EXEMPLE
Pour des biens :
– des packs de yaourts aux fruits,
– des micro-ordinateurs portables,
– des voitures…
Dans les services :
– des circuits de voyages,
– des contrats d’assurance-automobile,
– des produits de placements pour les banques.

De nombreux paramètres entrent en jeu dans la détermination du résultat concernant un


produit.
Concernant la détermination des produits réalisés : il existe des différences importantes
entre le montant facturé au client et le produit réalisé. Ce problème a déjà été évoqué dans
les relations avec la grande distribution, où la facture fait apparaître un prix brut qui peut
être assez différent du prix net, véritable produit de la vente.
Ce type de problème se rencontre dans de nombreuses activités.

71
1 CHAPITRE 2 – Structure du système d’information
PARTIE

EXEMPLE
Le chiffre d’affaires d’une agence de voyages est lié à sa prestation propre et non aux montants des
factures réglées par les clients. L’agent de voyage n’est qu’un intermédiaire qui doit reverser l’essentiel
du montant payé par le client aux compagnies de transport et aux hôteliers.

Les charges ne sont pas plus faciles à imputer.


Le coût de revient des produits et services standards, présents au catalogue de l’entreprise,
inclut des charges directes et des charges indirectes. L’évaluation des charges indirectes, la
méthode de calcul de coût à retenir suivant les contextes, nécessitent des choix de gestion.
Ce qui importe, c’est que le système d’information permette au manager de mettre en
œuvre ses choix. Ceci est rarement le cas aujourd’hui.
Pour le développement de ce point ⇒ Part. 1, chap. 2, sect. 1-2
En ce qui concerne la gestion des produits standard, la notion de méthode d’évaluation des
sorties de stocks, tant pour les matières que pour les produits, va entrer en jeu dans le calcul
des coûts.
c) Gestion mixte
Certaines entreprises ont besoin d’une gestion qui leur permette d’adopter les deux points
de vue, gestion par affaire et gestion par produit.
C’est le cas des banques ou des assurances. Elles ont une orientation de type gestion par
affaire par rapport au portefeuille de clientèle. Il s’agit dans ce domaine d’avoir une offre de
produits conforme aux besoins d’un client afin de le fidéliser et de rentabiliser au mieux son
potentiel. Elles ont également une optique par produits, par rapport à leurs offres de service.
Elles doivent en effet être capable de calculer la rentabilité d’un service afin d’en déterminer
le tarif de facturation.
Ces entreprises auront donc besoin de plusieurs applications différentes dans leur système
d’information. Se posera alors le problème de les rendre cohérentes et interopérables.
Part. 1, chap. 3, sect. 3.
Il est évident que c’est loin d’être le cas aujourd’hui dans la plupart des cas.

72
CHAPITRE 2 – Structure du système d’information 1
PARTIE

1.4 Les différents types d’industrie

Processus ou
Montage, deux types
d'industries à
processus totalement
différents

Industrie de montage Industrie de processus

Conception : CAO Conception : laboratoire


(Conception Assistée Fabrication en deux
par Ordinateurs) phases :
Fabrication : – mélange sans MOD
ordonnancement de (main d’œuvre directe)
« métiers » différents à puis conditionnement
synchroniser de l’aval vers avec MOD peu qualifiée ;
l'amont pour éviter les – planification naturelle
stocks intermédiaires. aval vers amont pour
gérer les goulots
Modularité du produit d'étranglement dans le
permettant le recours à conditionnement et les
des ruptures dans le contraintes physico-
process chimiques dans la
Partenariat avec les sous- préparation.
traitants allant jusqu’à Dans la plupart des
l’uniformisation des outils activités :
de traitements de – risque économique
l'information important sur l’emballage
– innovation dans le
packaging.

a) Les industries de montage


Les industries de montage correspondent aux industries de type mécanique, électrique,
électronique, etc.
■ La fabrication se déroule en deux phases
• La première phase consiste à confier la production de sous-ensembles
Ce sont des pièces ou des modules à des ateliers qui correspondent à des métiers différents,
qu’ils appartiennent à l’entreprise ou à des sous-traitants.

EXEMPLE
Dans le secteur de l’automobile, on trouvera :
– un métier de la tôlerie qui permet la réalisation des pièces de la carrosserie, à travers les phases :
• de découpe des tôles,
• d’emboutissage pour leur donner forme,

73
1 CHAPITRE 2 – Structure du système d’information
PARTIE

• de soudure pour les assembler,


• de traitement anti-corrosion et de peinture,
– un métier de la mécanique, qui permet la fabrication du moteur, mais également de la boîte de vites-
ses, ou de l’embrayage,
– un métier de la sellerie, qui réalise les sièges des véhicules,
– un ensemble de métiers pour lesquels les constructeurs automobiles font appel à des sous-traitants,
que l’on appelle les « équipementiers » et qui fournissent tous les équipements annexes des pneuma-
tiques aux éléments électriques ou aux freins.

• La deuxième phase consiste en l’assemblage des sous-ensembles

EXEMPLE
Pour poursuivre l’exemple de l’industrie automobile, il s’agit de l’atelier de montage ou chaîne de
montage. Elle est appelée ainsi à cause de son aspect linéaire. Aujourd’hui, l’assemblage s’effectue
parfois sous forme de petits ateliers ou « îlots ». Dans ce cas toute la logistique qui gère les déplace-
ments internes à l’usine et qui est pilotée par l’informatique a dû être repensée.
Dans les deux cas d’assemblage, la mise en place des nouvelles méthodes de gestion dites à la
japonaise, a modifié totalement le système d’information. Part. 1, chap. 2, sect. 1-2

■ Optimiser la planification de la fabrication


va nécessiter de résoudre différents problèmes
• Interfacer la conception assistée par ordinateur (CAO)
et la gestion de production (GPAO)
Avec la réduction du cycle de vie du produit, on a également réduit la durée du cycle de
conception, grâce au recours à la CAO. Le produit fait actuellement l’objet d’une recon-
ception quasi permanente à chaque phase de son cycle de vie, pour relancer sa commercia-
lisation, ou pour diminuer son coût.
Chaque modification au niveau de la CAO aura des impacts sur la GPAO, en termes :
– de modification des nomenclatures et des gammes de fabrication ;
– mais également sur les conditions d’achat puisque certains composants seront abandonnés
et remplacés par d’autres.
Cela implique :
– d’intégrer les systèmes d’information des fournisseurs principaux, qui sont des parte-
naires, depuis la phase de conception du produit, à l’aide de la CAO, jusqu’au contrôle
qualité des pièces livrées directement sur la chaîne de montage ;
– d’interfacer la CAO et la GPO, pour avoir un report immédiat et automatique des modifi-
cations de nomenclatures et de gammes de fabrication.

EXEMPLE
Dans le secteur automobile, on constate que les équipementiers et les constructeurs ont uniformisés
leur logiciel de CAO, afin de simplifier les échanges de données qui sont permanents.

WEB CATIA

74
CHAPITRE 2 – Structure du système d’information 1
PARTIE

• Obtenir la synchronisation des opérations


Il s’agit d’éviter les goulets d’étranglement, cause des stocks intermédiaires et des ruptures
de stocks. C’est dans ce type d’entreprises que se sont implantées les méthodes de gestion
dites à la japonaise, telles que le « juste à temps ». Part. 1, chap. 2, sect. 1-2
• Le contrôle qualité de chaque élément
Le contrôle qualité va s’exercer sur chaque élément ou sur chaque sous-ensemble, sous la
responsabilité de l’atelier qui l’a réalisé ou du sous-traitant, qui le fournit directement dans
l’atelier d’assemblage. Cela permet d’éviter les rebuts et les coûts prohibitifs au niveau de la
garantie des vices cachés, liés aux produits défectueux en sortie de l’assemblage.
b) Industrie de processus
Les industries de processus correspondent aux secteurs de l’agroalimentaire, de la chimie,
de la pétrochimie, de la pharmacie ou de la cosmétique.
La gestion de la production dans ce type d’entreprises est totalement différente de la précé-
dente.
■ La production se déroule également en deux phases
• La première phase consiste à élaborer un mélange
Au cours de cette phase, le mélange réalise la fusion des matières premières dans une
réaction de type chimique.
Cette phase possède les caractéristiques suivantes :
Aucune main d’œuvre directe. Cela signifie qu’aucune main d’œuvre ne s’exerce sur l’élabo-
ration du produit à cette étape. La main d’œuvre concernée, constituée de préparateurs, a
pour mission de permettre aux matières premières d’être présentes dans les cuves de
mélanges, et de contrôler le déroulement de la préparation du mélange et de sa maturation
éventuelle.
Perte d’unicité des matières premières. Les matières premières perdent leur individualisation
au cours de cette phase. On ne peut plus les distinguer dans le mélange résultant.

EXEMPLE
Pour fabriquer du yaourt à la fraise, on appliquera une recette, comme en cuisine. On mettra dans
la cuve de mélange une certaine quantité de plusieurs ingrédients : lait, présure, sucre, stabi-
lisant, confiture de fraise, morceaux de fraises au sucre, colorant de betterave, etc. À l’issue du
mélange, il sera très difficile de redécomposer les matières élémentaires. Ces matières seront
brassées dans la cuve, à une certaine température et à une certaine pression atmosphérique. La
durée de cette phase permettra d’harmoniser le goût, la texture et la couleur du mélange. Un
travail de contrôle par prélèvements et analyses de laboratoire, dans les domaines bactériolo-
giques et physico-chimiques permettront de déterminer la qualité du résultat et sa capacité à
être conditionné.

Dans certains cas, un temps minimal de maturation du mélange est nécessaire. Il peut exister
également un temps maximal de maturation. En dehors de cet intervalle de temps, les
qualités physico-chimiques du mélange se détériorent.

75
1 CHAPITRE 2 – Structure du système d’information
PARTIE

EXEMPLE
Dans l’exemple de la fabrication du yaourt à la fraise, il faudra respecter un délai minimum pour
obtenir un résultat conforme à ce qui est attendu en termes de saveur, de texture et de couleur. Par
contre, passé un certain délai, le mélange va se dégrader. Il n’aura plus les qualités optimales. On
aura, par exemple, un minimum de 12 heures de préparation pour obtenir l’état recherché du
mélange. Au-delà de 48 heures, celui-ci commencera à se dégrader. Donc, il faudra conditionner le
mélange entre 12 et 48 heures après sa mise en préparation. Cela correspondra à la contrainte essen-
tielle à gérer compte tenu des capacités du conditionnement.

EXEMPLE
Pour certains produits, il n’y a pas de durée de maturation. Chez l’Oréal, on fabrique les produits
cosmétiques, comme les vernis à ongles par exemple, sur des micro-lignes de conditionnement pilotées
par une seule personne qui gère la ligne et le contrôle qualité de premier niveau. Les ouvriers de condi-
tionnement peuvent bénéficier de l’horaire variable :
– car la préparation des mélanges est très rapide compte tenu des faibles volume et de l’inexistence
de temps de maturation ;
– il n’y a pas d’interdépendance des ouvriers au conditionnement grâce aux micro-lignes avec une
seule personne.
Le contrôle qualité effectué consiste à vérifier le remplissage des flacons par pesée, sur des échan-
tillons, au fur et à mesure du remplissage par la machine.

La phase « mélange » produit des résultats qui ne sont pas toujours recherchés. On peut obtenir
des déchets et sous-produits, liés au déroulement des réactions chimiques. C’est le cas dans
le raffinage du pétrole, mais également dans l’agroalimentaire, la production de produits
pharmaceutiques ou la production de papier.

EXEMPLE
Lors du conditionnement des crèmes glacées, le mélange en sortie de freezer n’est pas suffisamment
homogène ; on va donc déverser une certaine quantité du mélange dans des seaux avant d’entamer
le conditionnement des produits. Le contenu de ces seaux pourra ensuite être réemployés dans une
préparation ultérieure, de même type ou d’un type compatible. Le système d’information doit gérer
tous ces paramètres afin de prévoir une quantité de mélange correspondant à ce qui est à condi-
tionner et à faciliter la réutilisation rapide des seaux de réemplois, tant pour des motifs de coûts que
de qualité.

• La seconde phase consiste à conditionner le mélange élaboré


Cette phase intervient à la suite de la précédente et, souvent le délai d’attente possible est
court.
Cette seconde phase représente un goulot d’étranglement, pour plusieurs raisons :
– la spécialisation des lignes de conditionnement en fonction de la nature des emballages ;
– la disponibilité des équipes de personnel ouvrier et d’encadrement ;
– les cadences maximales de conditionnement des machines.
On aura donc une gestion de l’aval vers l’amont. C’est en fonction de la planification du
conditionnement, qui constitue le goulot d’étranglement, que l’on décidera de la mise en
fabrication du mélange.

76
CHAPITRE 2 – Structure du système d’information 1
PARTIE

La conception des produits n’a pas recours à la Conception Assistée par Ordinateur.
La conception des produits relève des techniques de laboratoires, dans les domaines de la
chimie, de la physique et de la biologie.
La CAO sera remplacée, dans le domaine du « packaging », par les techniques de la
conception graphique. L’emballage a un rôle marketing très fort dans les produits de ces
secteurs, qui sont souvent distribués en libre-service et sont prévendus par la publicité,
notamment télévisée.

En conclusion, on peut retenir de cette typologie simplifiée des entreprises :


– que toute organisation doit avoir une structure de son système d’information, et notamment de
ses bases de données, conforme aux besoins de son métier ;
– que la nature et le circuit des flux d’information entrants et sortants, liés à la manière dont se
déroulent les processus de son activité, doivent être intégrés en totalité dans le système d’informa-
tion mis en place ;
– qu’une organisation cherche à réaliser son but. Pour s’en assurer, le contrôle de gestion doit
disposer d’outils cohérents avec les processus.
Par conséquent :
– la structure des données pertinentes n’est pas la même dans toutes les entreprises, puisqu’elles
doivent représenter des réalités différentes ;
– les résultats à produire, donc les traitements à appliquer, sont différents également.
De nombreuses organisations se sont diversifiées, durant leur développement, ce qui les amène à
avoir plusieurs « métiers ». Elles combinent plusieurs situations, parmi celles décrites ci-dessus.
Elles devront donc posséder des outils de traitements de l’information adaptés aux différents
processus, s’appuyant sur des structures de données adéquates.
Cela aura une influence sur la structure des applications opérationnelles et sur les applications
d’aide à la décision, mais également sur les choix techniques et sur le choix d’outils de communica-
tion entre l’entreprise et son environnement.

2. L’influence du choix des méthodes de management


sur le système d’information
2.1 Influence des méthodes de management dites à la japonaise
La modification du contexte économique mondial a eu des conséquences sur les méthodes
de gestion des organisations.
La modification des pôles économiques mondiaux, après les crises pétrolières des années 70,
a entraîné la prééminence du modèle japonais en gestion, notamment dans les industries.
À la fin des années 70, de nombreux dirigeants occidentaux sont allés voir comment
fonctionnaient les entreprises japonaises.
Des articles et ouvrages sont parus en grand nombre depuis lors pour expliquer aux entre-
prises occidentales comment acclimater les méthodes de gestion dites « à la japonaise ».
Mais c’est la concurrence, dans le cadre de la mondialisation, qui a poussé à l’application
générale de ces méthodes dans les industries occidentales.

77
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Il semble néanmoins, que ce soit dans les entreprises japonaises ou occidentales, que la mise en
œuvre de ces principes ne soit pas simple. La disponibilité d’un système d’information cohérent
avec ces méthodes est nécessaire. Or, de nombreux outils existants sont toujours orientés vers
les méthodes de management antérieures, où les flux sont gérés de l’amont vers l’aval.

RÉCAPITULATIF DES DIFFÉRENTES MÉTHODES DITES À LA JAPONAISE

Dénomination de la méthode Cible


Le juste à temps. Mener l’activité en fonction de la demande, sans stock et sans délai.
Les flux tirés et tendus. Les flux d’activité sont tirés par la demande et sans stocks.
Les fiches Kanban. Fiches suiveuses au cours des process, qui circulent de l’aval vers
l’amont, afin de garantir que l’on ne fabriquera pas de stock.
Les cinq zéros olympiques. Recherche de l’idéal (niveau zéro) dans cinq domaines : zéro stock,
zéro délai, zéro panne, zéro défaut, zéro papier. On ajoute fréquem-
ment un 6e, le zéro mépris.
La méthode SMED. Méthode de réduction des durées de changements d’outils sur les
machines afin de permettre la réduction des séries, donc la réduction
des stocks intermédiaires et des délais de livraison.

a) Produire Juste à Temps ou en flux tirés et tendus


Produire Juste à Temps signifie ne pas mettre de produits en fabrication pour les stocker,
qu’il s’agisse de produits finis ou pire, de sous-ensembles intermédiaires. Pour autant, cela
ne doit pas entraîner un délai de livraison plus long pour le client, qui passe commande.
L’élimination des stocks intermédiaires dans l’enchaînement des opérations de production
est un problème essentiellement présent dans les industries de montages décrites ci-dessus.
L’élimination des problèmes de stocks intermédiaires ou de ruptures de stocks implique de
synchroniser les vitesses de travail dans la succession des postes de travail des différents
ateliers et entre les ateliers eux-mêmes.

EXEMPLE
Il faut produire à la même cadence les carrosseries, les châssis et les moteurs, afin de les assembler en
respectant la cadence optimale de l’atelier de montage : ne pas créer de stocks de sous-ensemble à
l’entrée de cet atelier, mais lui fournir suffisamment de sous-ensembles de toutes natures afin d’assurer
son travail à cadence maximale.
La synchronisation des vitesses est rendue possible par la polyvalence de la main d’œuvre, car les
cadences potentielles des machines sont différentes, compte tenu qu’elles appartiennent à des
technologies différentes et représentent des métiers très divers.
Organiser la production en Juste à Temps (JAT) implique le recours à un système d’information
structuré de manière à optimiser les flux, en partant de l’aval vers l’amont. WEB Juste à Temps

L’idéal visé consiste à :


– produire en flux tirés, par la demande des clients ;
– produire en flux tendus, c’est-à-dire sans stocks.

78
CHAPITRE 2 – Structure du système d’information 1
PARTIE

LES NIVEAUX DE STOCKS À ÉLIMINER PAR CETTE MÉTHODE

Niveau d’apparition du stock Méthode


Pas de stocks amont, au niveau Travailler en temps réel avec les fournisseurs, qui livrent
des approvisionnements. directement les ateliers de l’industrie.
Pas de stocks intermédiaires, entre les étapes Synchroniser les cadences des différentes machines et
de la production. réduire les séries de manière à avoir un process de fabri-
cation continu.
Pas de stocks en aval, concernant les produits finis. Améliorer la flexibilité et la prévision à cour terme.

Les méthodes de réduction des différents niveaux d’apparition de stocks impliquent toutes
la disposition d’informations fiables et disponibles sans délai. Pour être mises en œuvre, il
faut que le système d’information évolue dans ce sens.
L’idée de base des flux tirés et tendus est de ne pas anticiper la demande et de ne fabriquer
que ce qui est commandé par les clients.
Avec cette approche, il ne serait pas nécessaire de financer les stocks, ce qui représenterait
une diminution importante du besoin en fonds de roulement. Elle présente également
l’avantage d’éviter des pertes de valeur sur des stocks de produits, qu’il faut solder ou même
détruire.

EXEMPLE
Nous avons fait référence précédemment au problème des stocks d’emballages dans l’agroalimen-
taire, qui perdent totalement leur valeur lors d’un changement de packaging.
On peut également faire référence à la notion d’année modèle pour les véhicules automobiles et leur
cotation à l’Argus.
C’est également le cas des stocks dans le commerce de détail, qui sont écoulés pendant les périodes
de soldes.

Cette approche présente l’avantage, qui peut sembler paradoxal, de permettre de réduire le
délai de livraison au client. On a tendance à croire que le stock apporte de la souplesse et
donc la réduction du délai de livraison au client. C’est exact dans le cadre d’un raison-
nement statique. Si l’on se place dans une vision dynamique, il n’en est rien.
Pendant la durée de la fabrication de produits, qui vont être stockés, on ne peut pas
fabriquer les produits commandés par les clients. Leur délai d’attente de la livraison est
donc rallongé. On voit bien que livrer le client le plus rapidement possible est un objectif
cohérent avec celui de réduire les stocks. Mais, cela implique une production en séries plus
courtes, en fonction du portefeuille de commandes. Il faut arriver à réduire les séries sans
augmenter le coût de production unitaire. Ce problème peut se résoudre en utilisant deux
méthodes : le recours à la méthode SMED, qui sera développée ci-dessous et l’utilisation
d’un système d’information adapté.
Il faudra que le système d’information possède les fonctionnalités nécessaires à ce type de
gestion.

79
1 CHAPITRE 2 – Structure du système d’information
PARTIE

RÉCAPITULATIF DES FONCTIONNALITÉS NÉCESSAIRES À LA MISE EN ŒUVRE DE LA GESTION


EN FLUX TIRÉS ET TENDUS

Fonctionnalité Cible
Transmission instantanée des nouvelles commandes Réduire les délais de livraison au client commence par
pour les intégrer dans le portefeuille. gérer le portefeuille des commandes en temps réel.
Planification dynamique de la fabrication. La création et l’ordonnancement des fiches Kanban à
partir de l’évolution du portefeuille de commandes doi-
vent être automatiques.
Gestion des flux matières correspondant au programme L’approvisionnement doit être déclenché sans délai, en
de fabrication. fonction du planning de fabrication quotidien, pour évi-
ter les stocks. Les méthodes de communication avec les
fournisseurs doivent permettre une livraison immédiate
sur la ligne de montage.
Gestion de l’ordonnancement des équipes en fonction S’appuyant sur la polyvalence des ouvriers, l’ordonnan-
des cadences. cement des équipes, en fonction des cadences, évite les
stocks intermédiaires.

EXEMPLE
Dans l’automobile, on pourra transmettre la commande du client du concessionnaire à l’usine par
télématique, réduisant ainsi le délai de mise en portefeuille de la commande. La planification de la
fabrication sera automatiquement ajustée. S’appuyant sur la gestion automatisée et l’utilisation de
la méthode SMED au niveau des équipements, l’ordinateur permettra d’enchaîner des fabrications
différentes :
– au niveau des pièces de carrosserie, notamment à la découpe et à l’emboutissage
– à l’atelier de peinture, en permettant d’alterner les couleurs d’un véhicule à l’autre
– à l’assemblage en assurant la fourniture des bons éléments au bon moment, par exemple pour pas-
ser d’un véhicule 2 portes à un véhicule 4 portes, d’un véhicule bleu à un véhicule vert, etc.

Il faut relativiser la notion de zéro stock et l’incidence des flux tirés et tendus :
– il s’agit d’un idéal. L’idée à retenir est qu’il faut chercher en permanence à faire baisser le
niveau des stocks ;

EXEMPLE
L’application de ces méthodes de gestion dans l’industrie automobile au cours de années 90 a permis
de faire baisser le niveau des stocks d’un équivalent de 3 mois de ventes à 3 semaines, tout en
réduisant de plusieurs mois à deux à trois semaines le délai moyen de livraison d’un véhicule neuf.
Cette évolution a été rendue possible par l’utilisation des outils adaptés dans le système d’infor-
mation.

– la réduction des séries de fabrication ne consiste pas à produire à l’unité. Statisti-


quement, une unité industrielle reçoit un volume de commandes quotidiennes de chaque
pièce ou produit qui peut varier, mais qui présente une certaine régularité. Il ne s’agit
donc pas de revenir à une production de type artisanal.

80
CHAPITRE 2 – Structure du système d’information 1
PARTIE

EXEMPLE
Prenons l’exemple d’une ligne d’assemblage automobile prévue pour produire en moyenne
200 véhicules/jour. Il est possible de déterminer avec une certaine régularité le nombre de pièces de
chaque catégorie qui sera nécessaire. Cela permettra, entre autres, aux équipementiers de livrer les
points d’assemblages qui les concernent directement sur la ligne. L’équipementier qui fournit les
optiques de phares pourra prévoir la livraison quotidienne de 200 phares gauches et 200 phares droits.

L’élimination des séries est surtout un problème d’assemblage : présenter la bonne pièce au
bon endroit et au bon moment. C’est au système d’information de gérer ce problème.
b) Utiliser les fiches Kanban
La méthode Kanban est un système de fiches suiveuses, dont l’objectif est de ne pas produire
pour le stock, mais pour satisfaire uniquement la demande.
Ces fiches suiveuses vont donc être générées de l’aval vers l’amont. À partir de la demande
du client, on génère une demande de produits finis. En remontant le process de fabrication,
en fonction des nomenclatures qui décrivent la composition du produit et des gammes de
fabrication qui décrivent les tâches à effectuer, on génère les demandes des sous-ensembles
nécessaires à l’assemblage final. Ceux-ci sont eux-mêmes décomposés jusqu’à l’approvi-
sionnement en matières premières. Le principe fondamental est qu’à chaque étape, un
atelier ne fabrique que dans la mesure où il a une demande de l’aval, matérialisée par des
fiches suiveuses cartonnées, positionnées dans un tableau de planning, au sein de l’atelier.
L’originalité n’est pas dans le tableau de planning et les fiches suiveuses, mais dans le fait
qu’elles sont créées par l’atelier en aval (flux tirés) et non, comme c’était le cas antérieu-
rement, par l’atelier amont (flux poussés). Cette méthode implique également que l’on
admette que le personnel puisse être payé à ne rien faire s’il n’y a pas de demande, plutôt
que de produire pour le stock.
La question souvent posée pour mettre en place ce type de fiches est la taille requise du
tableau Kanban pour un atelier donné. S’il y a des différences de nombre de fiches en attente
d’un atelier à l’autre, c’est l’expression d’une différence de vitesses de travail – ou cadences
– entre les ateliers. Les demandes s’entassent dans les ateliers les plus lents, tandis que le
tableau est souvent vide dans les ateliers les plus rapides. La solution est dans la synchroni-
sation des vitesses, en jouant sur la polyvalence des hommes et la disponibilité des équipe-
ments.
Ce problème sera gérable plus facilement en automatisant la gestion des fiches Kanban au
sein du système d’information. Dans ce cas, ce ne sont plus des fiches cartonnées sur un
tableau, mais des enregistrements dans des bases de données, consultables par l’intermé-
diaire d’un terminal présent dans l’atelier. Néanmoins, le problème de fond qui réside dans
la synchronisation des cadences des ateliers subsiste et il constitue le problème essentiel à
résoudre pour optimiser la production. Dans la mesure où la gestion de production est
conçue pour gérer les flux de l’aval vers l’amont, elle pourra non seulement se substituer
aux fiches cartonnées, mais également assurer la proposition de planification des hommes
et des équipements, permettant de fabriquer les commandes en portefeuille dans les
meilleurs délais.

81
1 CHAPITRE 2 – Structure du système d’information
PARTIE

c) Le principe des cinq zéros olympiques et la politique de la qualité totale

Les cinq zéros olympiques Recherche de l’idéal (niveau zéro) dans 5 domaines + 1

Zéro stock Chercher à réduire le stock au minimum nécessaire.

Zéro panne Les pannes entraînent la baisse des cadences réelles par rapport aux cadences
prévues, avec une incidence négative sur les délais de livraison et les coûts
unitaires.

Zéro défaut Les rebuts et vices cachés coûtent cher et dégradent l’image de l’entreprise.

Zéro délai Il faut réduire au minimum le délai de livraison de la commande du client.

Zéro papier La transmission instantanée et fiabilisée des informations exclut le recours au


papier.

Zéro mépris Ce sixième principe a été rajouté, car il faut obtenir des comportements orien-
tés vers la qualité de chaque individu de l’organisation, Cela n’est pas com-
patible avec le mépris latent des décideurs vis-à-vis aux opérationnels.

Afin d’améliorer la gestion, en satisfaisant les clients et en éliminant les coûts de la non-
qualité, cette méthode propose une liste des points critiques à prendre en compte.
■ Pas de stock
On cherche à réduire les stocks à tous les niveaux.
– réduction des approvisionnements stockés en réduisant les délais de commande et de
livraison avec les fournisseurs ;
– réduction des stocks intermédiaires et des ruptures de stocks intermédiaires en synchro-
nisant les cadences des postes de travail. Cela implique la polyvalence des salariés ;
– réduction du stock de produits finis en produisant Juste à Temps.
Cela implique une gestion des informations fiable et en temps réel.
■ Pas de panne
Cela implique une maintenance préventive des équipements de manière à ne pas inter-
rompre la fabrication pour une panne machine. En effet, cela impliquerait la désynchroni-
sation de la fabrication, l’allongement des délais de livraison aux clients, et un surcoût,
puisqu’il faudrait payer les ouvriers alors qu’ils attendent que la machine soit réparée. Cela
a favorisé l’apparition dans le système d’information d’applications de type GMAO
(Gestion de Maintenance Assistée par Ordinateur) permettant :
– le suivi des plans de maintenance préventive en fonction de la nomenclature des pièces
d’une machine et de leur MTBF (Moyenne des Temps de Bon Fonctionnement) ;
– l’élaboration de statistiques de pannes permettant de détecter les points faibles ;
– l’analyse des coûts et des interventions de maintenance sur les équipements de manière à
choisir une politique de remplacement des équipements qui minimise le coût investis-
sement + maintenance.

82
CHAPITRE 2 – Structure du système d’information 1
PARTIE

RÉCAPITULATIF DES FONCTIONS DE LA MAINTENANCE INTÉGRÉE DANS LA GMAO

Fonctions Situations
Maintenance préventive Remplacement préventif des pièces en fonction de leur durée d’utilisation
prévue.
Entretien préventif Entretien, nettoyage, vidange, changement des pièces et consommables.
Réglage des machines Réglages préalables à la fabrication en fonction du planning de pro-
duction.
Travaux neufs Agencements et création d’équipements neufs.
Dépannage Interventions en cas de pannes.

Le responsable de la maintenance doit disposer des informations lui permettant d’obtenir


un équilibre entre les différentes fonctions sous sa responsabilité.
■ Pas de défaut de fabrication
On multiplie les étapes de contrôles partiels dans le cours de la fabrication, car il est inutile
d’assembler un produit qui présente un défaut de fabrication dans une étape ultérieure de
la production. Les rebuts et déchets augmentent le coût unitaire du produit vendable. De
plus, ils ralentissent la cadence de fabrication utile et il est possible que, n’étant pas détectés
à temps, les défauts subsistent dans un produit livré au client, ce qui est mauvais pour
l’image de marque de l’entreprise et augmentent les coûts de la garantie des vices cachés.

EXEMPLE
À la fin des années 70, un véhicule sur trois qui sortait des chaînes automobiles présentait des défauts
qui n’étaient pas tous décelés à la sortie de l’usine. Parfois, en sortie de chaîne de montage, la voiture
ne démarrait pas, tout simplement parce que la batterie ou le démarreur qui avaient été montés étaient
défectueux. En contrôlant chaque élément avant l’assemblage, on diminue les coûts de manière consi-
dérable et on accroît de manière très importante la satisfaction du client, donc sa fidélité à la marque.
Les japonais ont pu tirer de cette méthode un avantage compétitif en offrant aux clients des conditions
de garantie plus favorables que leurs concurrents : un an au lieu de six mois ou 100 000 km, pour une
voiture, par exemple – sans que cela leur coûte plus cher que leurs concurrents, bien au contraire.

EXEMPLE
Aujourd’hui dans certains secteurs, comme l’aéronautique, la concurrence est tellement vive que les
conditions de garantie offertes par les constructeurs impliquent quasiment un bon fonctionnement à
vie des équipements. Toute panne est donc à la charge du constructeur, sans limitation de durée. Il est
donc essentiel d’accroître les contrôles de qualité.

Pour atteindre cet objectif du zéro défaut, il faut être en mesure de mettre en place l’enregis-
trement des événements de non-qualité et en faciliter l’analyse. Ces pratiques sont prévues
dans la norme ISO 9000, mais elles font souvent l’objet d’un système de gestion déconnecté de
l’activité de production elle-même. C’est une perte d’efficacité dans le système qualité. La
place naturelle du système qualité et de ses informations, est dans le système d’information en
prise directe sur les flux d’activité. Gérer la qualité va donc entraîner des exigences nouvelles
concernant la structure et les modes de fonctionnement du système d’information.

83
1 CHAPITRE 2 – Structure du système d’information
PARTIE

■ Pas de délai de livraison


Les résultats des actions qui précèdent doivent permettre de réduire les délais de livraison
aux clients tout en améliorant son niveau de satisfaction.
Contrairement à ce que l’on peut penser, la possession de stocks ne raccourcit pas le délai
moyen de livraison au client, mais, au contraire, l’allonge. En effet, dans une perspective
dynamique, le temps de fabrication du stock, ensemble de produits non demandés par les
clients, représente un délai de livraison supplémentaire pour les commandes en portefeuille.
■ Pas de papier
Travailler sans stock et sans délai nécessite une transmission fluide et instantanée des infor-
mations. La « paperasserie » administrative est un frein bureaucratique. Des techniques
comme l’EDI (Échange de Données Informatisées) entre entreprises, ou l’utilisation
d’Internet entre particuliers et entreprises, éliminent l’utilisation du papier tout en
accélérant la transmission des informations et en éliminant de nombreuses erreurs de
retranscription de l’information. Toutes ces techniques impliquent le recours à
l’intégration d’outils de télématique dans le système d’information.
Actuellement, on peut exiger du système d’information deux axes de progrès en la matière :
– la dématérialisation des opérations commerciales entre entreprises et entre consom-
mateur et fournisseur ;
– la communication des acteurs des groupes de travail, qui doit pouvoir être automatisée
en intégrant des fonctionnalités de gestion des flux d’activités (« workflow ») dans les
applications.
■ Pas de mépris
Ce sixième principe a été ajouté a posteriori. L’idée de progrès permanent (Kaizen), qui
permet à l’organisation dans sa globalité de progresser, n’est possible qu’à condition de
mobiliser l’ensemble des individus de l’entreprise, quel que soit leur niveau dans la
hiérarchie, et d’obtenir leur adhésion à l’objectif commun. Cela implique que le point de
vue et les efforts de chacun doivent être reconnus. L’importance monétaire du résultat d’un
effort est d’un grand intérêt, mais si petit soit le résultat pour l’organisation, l’effort doit être
reconnu par le groupe social. Si ce n’est pas le cas, les individus seront démobilisés et ne
feront plus d’efforts.
■ L’intégration des zéros olympiques dans la politique de la qualité totale
La gestion de la qualité fait appel à deux outils d’inégale importance : les cercles de qualité
et la politique de la qualité totale.
Le premier est un outil au sens strict du terme, tandis que le second est plus une philosophie
du comportement collectif au sein des organisations.
En ce qui concerne les cercles de qualité, il s’agit de résoudre un problème identifié afin
d’améliorer la qualité du travail et du produit. Pour cela on crée des groupes pluridiscipli-
naires pour résoudre les problèmes qui apparaissent à différents endroits de l’organisation.
L’essentiel de la démarche qualité repose sur la politique de qualité totale.
La retranscription opérationnelle de ce principe est réalisée à travers la mise en œuvre de la
norme ISO 9000 version 2000. Cette mise en place nécessite une structuration du système
d’information adéquate. Cette norme insiste expressément sur la nécessité de mettre en

84
CHAPITRE 2 – Structure du système d’information 1
PARTIE

place une politique de la qualité totale et sur la nécessité d’intégrer les outils du contrôle
qualité dans le système d’information. Le système d’information permet la gestion des flux
d’activités de l’organisation. C’est dans cette gestion qu’apparaissent les phénomènes de
non-qualité. Cela implique que les contrôles qualité, l’enregistrement des phénomènes de
non-qualité et les moyens statistiques pour les analyser, soient intégrés dans les applications
elles-mêmes, qui gèrent les flux. Il ne s’agit pas de domaines applicatifs indépendants, mais
d’une manière d’aborder la gestion de tous les processus.
d) Le recours à la méthode SMED
SMED signifie Single Minute Exchange of Dies : changement d’outils en une seule minute.
Le dilemme classique entre le marketing et la production réside dans la taille des séries. La
satisfaction du consommateur, sans stock, sans délai et avec un produit personnalisé, passe
par des séries très courtes. Mais les contraintes de changement d’outils rendaient nécessaire
l’allongement des séries, afin d’imputer la charge fixe du changement d’outils sur un nombre
d’unités important. S. Shingo, ingénieur japonais, a fait des expériences chez Toyota qui lui
ont permis de faire passer de 4 heures à 4 minutes certains changements d’outils et donc de
réduire les séries. Cela lui a permis de dégager certains principes simples applicables partout.

QUELQUES PRINCIPES DE BASE POUR APPLIQUER LA MÉTHODE SMED

Principes Effets recherchés


N’arrêter la machine que lorsque tous les éléments Organiser le changement d’outils afin d’éviter les pertes de
nécessaires au changement d’outils sont regroupés temps liées aux recherches de pièces manquantes en
au pied de la machine. dernière minute.
Faciliter le montage et le démontage par des Les systèmes classiques (boulons et écrous) exigent du
systèmes de fixation plus rapides à manipuler. temps de montage et démontage et se bloquent
fréquemment. On leur substitue des systèmes de fixation
instantanée.
Transférer les réglages des moteurs électriques sur Éviter de monter des outils en panne.
des bancs d’essais externes à la machine.
Remplacer des mises au point machine arrêtée par Optimiser les réglages en les transformant en temps de
des mises au point réalisables machine en route. production à cadence réduite.

Des résultats spectaculaires dans ce domaine peuvent être réalisés dans le cadre des
techniques implantées, par des méthodes qui relèvent plus de l’astuce et du bon sens que
d’une révolution technologique.

EXEMPLE
Lors de la mise en route de sa nouvelle ligne de fabrication pour un nouveau modèle, un constructeur
automobile a modifié les robots de peinture, de manière à pouvoir changer de couleurs de peinture en
quelques secondes. Cela lui permettait de ne pas avoir de contraintes sur l’enchaînement des couleurs
de pièces de carrosserie à peindre. Cela évitait la fabrication de stocks de pièces de carrosserie. Cette
modification était nécessaire pour fabriquer en Juste à Temps à l’atelier de carrosserie.
Le corollaire de cette action est de lier le système d’information, qui gère la logistique, c’est-à-dire la
circulation automatique des flux dans l’atelier de carrosserie, avec l’ordonnancement de fabrication
qui est issu du carnet de commandes.

85
1 CHAPITRE 2 – Structure du système d’information
PARTIE

En conclusion, l’ensemble de ces méthodes a eu pour objectif l’amélioration de la satisfaction du


client.
Mais on constate que l’introduction de ces nouvelles méthodes dans les organisations entraîne
deux conséquences très importantes au niveau du système d’information :
– modification de sa structure pour le rendre compatible avec la circulation des flux inversée par
rapport à la gestion classique ;
– accroissement de son caractère facteur clé de succès dans la mise en œuvre de la stratégie,
puisqu’il rend possible l’adoption de ces méthodes d’organisation et de gestion.
Il y a une évolution du comportement des individus qui est nécessaire pour effectuer cette transi-
tion. Il faut renoncer à la vision analytique et statique des problèmes pour aborder une vision
synthétique et dynamique.

2.2 Influence des nouvelles méthodes de gestion et de contrôle


a) La méthode ABC (A Activity Based Costing)
Contrairement à la méthode traditionnelle des coûts complets, cette méthode propose
l’identification d’activités qui permettent aux processus opérationnels de se dérouler dans
de bonnes conditions. Il s’agit d’une perception plus conforme à la vision systémique et
dynamique des organisations que la méthode des coûts complets traditionnelle. Les frais
généraux apparaissent dans le cadre de centres de coûts fonctionnels, qui ont pour finalité
de rendre des services aux activités opérationnelles. Ces derniers consomment les frais. La
prestation et la consommation de ces frais généraux sont proportionnelles à des inducteurs,
représentatifs des activités menées par les services prestataires, pour le compte des modules
opérationnels, qui en sont les clients.
L’inducteur choisi doit correspondre à plusieurs critères.

Critères de qualité d’un inducteur Effets recherchés


Être représentatif de la proportionnalité des charges Calcul un coût complet permettant de prendre des déci-
liées à la fourniture de la prestation par le service sions réalistes.
fonctionnel et de consommation par le service Servir d’outil de communication entre services fonction-
opérationnel. nels et opérationnels.
Être facilement et objectivement mesurable, de La mesure ne doit pas être sujet à caution. Le coût de
manière automatique, dans le cadre de la partie son obtention ne doit pas être supérieur à l’avantage de
automatisée du système d’information. disposer de l’infirmation.

EXEMPLE
Une entreprise possède plusieurs départements qui commercialisent différentes familles de produits.
Le service administration des ventes, qui assure la facturation et le recouvrement des créances, est
commun à tous les départements. Une analyse de son activité a permis de lister et d’évaluer le volume
des tâches élémentaires de toutes natures à accomplir dans le cadre de sa mission. Il s’agit de trouver
un inducteur qui permettra d’affecter le coût de fonctionnement du service aux départements
commerciaux de manière cohérente. Cela signifie que la méthode ne doit pas apporter de distorsion
modifiant l’opinion que l’on pourrait avoir sur la rentabilité de certains produits et qu’elle doit être
comprise et acceptée par les départements. Il faut ensuite que le système d’informations soit capable

86
CHAPITRE 2 – Structure du système d’information 1
PARTIE

de calculer automatiquement la répartition à partir de la mesure des flux d’activité. Les études
réalisées ont montré que l’inducteur qui est le mieux corrélé à la progressivité des coûts de fonction-
nement du service est le nombre de factures établies pendant la période. En effet, que le montant de
la facture soit faible ou élevé, le temps de travail nécessaire à son traitement est apparu identique.
Le système d’information devra donc chaque mois compter le nombre de factures et d’avoirs établis
pour le compte de chaque département afin de lui imputer dans l’analyse des coûts la part qui lui
revient.

Pour mettre en place cette méthode, le système d’information doit permettre de paramétrer
et de stocker les données nécessaires aux services fonctionnels, à leurs activités et aux induc-
teurs. Il doit posséder les procédures de traitement nécessaires au calcul des coûts complets
suivant cette méthode.
Si le système d’information en place ne dispose pas de cette possibilité, la mise en place de
la méthode ABC se traduira :
– au mieux, par des extractions de données et des retraitements plus ou moins manuels qui
seront coûteux car il faudra les répéter chaque mois ;
– au pire, cela posera des problèmes de cohérence des méthodes d’évaluation entre les
calculs effectués dans le système d’information et les retraitements externes.
b) La méthode ABM (A Activity Based Managment)
La méthode de la gestion basée sur les activités propose une vision transversale et pluridis-
ciplinaire de l’entreprise. Elle s’appuie sur les calculs de la méthode ABC.
Elle est conforme à une optique de gestion par projets.
Elle est basée sur une certaine logique de l’action s’appuyant sur plusieurs éléments
composants :

Composants Effets
Le niveau d’aspiration des acteurs. Les salariés ont besoin de reconnaissance et de perspec-
tive de développement personnel afin d’adhérer à la
poursuite de l’objectif de l’organisation.
L’investissement émotionnel de l’acteur dans l’action. Le salarié ne peut faire abstraction de sa subjectivité et
sa nature d’être humain dans l’action créative de valeur
ajoutée au sein de l’organisation.
L’objectif assigné par le donneur d’ordre. La recherche de la satisfaction du client nécessite la
prise en compte des besoins, qui se traduit par l’objectif
du projet.
Les moyens alloués par le décideur à la réalisation La recherche d’efficacité et d’efficience implique la
de l’action. mesure de l’allocation des ressources pour les comparer
au résultat obtenu.
Le résultat obtenu. L’organisation ayant une finalité, elle doit mesurer le
résultat obtenu qui constitue la marche vers son objectif.
L’impact sur l’environnement. Dans une logique de gestion de projet et de développe-
ment durable, on doit mesurer l’action de l’organisation
sur son environnement.

87
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Pour mesurer ces différents aspects de la gestion, la méthode ABM propose de construire
une batterie d’indicateurs d’efficacité et d’efficience. L’efficacité mesure le degré d’atteinte
des objectifs tandis que l’efficience mesure le rendement des ressources employées. Ces
indicateurs appartiennent au tableau de bord et aux outils de la partie décisionnelle du
système d’informations.
Pour construire des indicateurs, il faut disposer de données pertinentes. Si le système
d’information ne dispose pas des données permettant de calculer certains indicateurs, soit
on renoncera à les calculer, soit on aura recours à des retraitements externes au système
d’information, source de coûts parasite, de délais d’obtention et d’erreurs dans les résultats.
WEB Méthode ABC
c) Le design et le r e d e s i g n t o c o s t
L’objectif de l’entreprise est de satisfaire les besoins du client en tenant compte de l’état de
la concurrence et de la nécessité de rentabiliser son activité.
Pour cela, la conception des produits, à l’origine et puis dans les différentes versions au
cours de leur cycle de vie, fait appel aux techniques de l’analyse fonctionnelle et de l’analyse
de la valeur.
Le « redesign to cost » amène à remettre en œuvre ces techniques, au cours des étapes du
cycle de vie du produit.
Lorsque le produit est nouveau, on pratique l’analyse de la valeur de façon à le concevoir à
un coût compatible avec le prix de marché ou prix psychologique, pour lequel il existe un
marché potentiel.
Dans sa phase de maturité, le produit va connaître une concurrence forte, notamment par
les prix, qui va rendre nécessaire une redéfinition de l’analyse de la valeur, afin de le
produire moins cher et de pouvoir faire face à la concurrence et à de nouveaux canaux de
distribution.
Pour pratiquer facilement cette méthode de gestion du cycle de vie du produit, il faudra
posséder plusieurs possibilités au sein du système d’information :
Capacités du système d’information Effets
L’interopérabilité entre la conception et la production. Les nomenclatures et gammes de fabrication devant
évoluer durant toute la vie du produit, la mise à jour des
données implique l’automatisation du passage des infor-
mations entre la conception et la production.
Le choix des méthodes de calcul de coûts et de marges, La gestion de nouveaux circuits et l’étroitesse des mar-
incluant la possibilité de modéliser les calculs de coûts ges impliquent la possibilité de modéliser et de simuler
et d’en tirer des simulations. le comportement des coûts et des marges avant de pren-
dre des décisions.

EXEMPLE
Lorsqu’une technologie nouvelle apparaît (par exemple, les écrans plats pour les téléviseurs en rempla-
cement des écrans à tube cathodique) :
– les produits sont vendus, dans des circuits spécialisés ;
– ils ont des prix de vente très élevés ;
– le marché est réduit aux clients précurseurs à revenu élevé ;

88
CHAPITRE 2 – Structure du système d’information 1
PARTIE

– le coût de production peut être relativement élevé. L’objectif est de maîtriser la technologie, d’amor-
tir les charges de recherche et développement et de susciter la demande, dans un marché à très forte
marge.
Lorsque le produit devient banal, dans sa phase de maturité :
– la concurrence est plus forte ;
– il faut pouvoir écouler de nombreux produits, ce qui implique le recours à la grande distribution ;
– le prix de vente baisse fortement. Il est souvent divisé par 3 ou 4 ;
– une reconception des produits en fonction du coût, fondée sur une analyse de la valeur, est alors
impérative, afin de le réduire au minimum, pour garantir une marge suffisante.

EXEMPLE
Pour certains produits, il y a simultanément des gammes s’adressant à différents segments de
clientèle, qui nécessitent le recours à l’analyse de la valeur. Par exemple, dans le domaine des stylos,
il faut adapter la nomenclature pour fabriquer, d’une part, des stylos jetables et, d’autre part, des
stylos de luxe, rechargeables et fabriqués en matières prestigieuses.
Les données techniques et les exigences en matière de niveau de qualité ne seront pas le mêmes. Cela
signifie que les procédures et les alertes que le système devra fournir en cas de réclamations des clients,
par exemple, devront être adaptées aux différentes situations.

En conclusion, l’adoption de méthodes de gestion différentes a des conséquences pour le système


d’information.
Ces conséquences portent :
– sur les structures de données permettant la mise en œuvre des nouvelles méthodes ;
– sur les procédures de traitement et leur enchaînement logique ;
– sur l’évolutivité nécessaire du système, pour l’adapter aux besoins mouvants de l’entreprise.
La construction du système d’information et son évolution permanente sont donc aujourd’hui des
éléments essentiels dans la réussite de la stratégie de développement de l’organisation. S’il est
conforme aux besoins et s’il évolue en cohérence avec l’organisation, il constituera un indéniable
facteur clé de succès.
Mais si au contraire il ne l’est pas, il sera un facteur d’échec implacable. Cela sera pernicieux, car
l’organisation n’en aura pas toujours conscience. Elle essaiera de détourner le système et de trouver
des palliatifs, sans toujours mesurer les coûts parasites que cela représente et l’inefficacité que cela
provoque.

section 2
éléments constitutifs
d’un système d’information
Un système d’information se compose :
– d’applications opérationnelles, destinées aux modules opérationnels, pour gérer les
processus de transformation des flux entrant en flux sortants ;
– d’applications décisionnelles, destinées à aider les modules pilotes à prendre les décisions.

89
1 CHAPITRE 2 – Structure du système d’information
PARTIE

1. Applications opérationnelles

Gestion Gestion des


commerciale ou salaires et des
Applications
suivi des clients ressources
Opérationnelles :
humaines
gestion de l'activité de
Gestion de l'entreprise, au sein des
production processus, visant la maîtrise
des flux et de leur
transformation, par les acteurs
opérationnels du système
Gestion de Gestion des achats
maintenance et des
approvisionnements

Gestion comptable
et financière

Acquisition Acquisition
automatique automatique
par interface par interface

1.1 Définition des applications opérationnelles


Une application opérationnelle permet de traiter les informations liées aux flux entrants et
sortants. Ceux-ci sont gérés par les modules opérationnels et constituent l’activité de
l’organisation, menée pour atteindre sa finalité. Les informations concernées sont volumi-
neuses, mais répétitives. Elles concernent aussi bien les commandes des clients que l’élabo-
ration des bulletins de salaires, les mouvements de stocks, ou les fiches de fabrication.
Une application opérationnelle est utilisée par les personnels qui sont en position opéra-
tionnelle dans l’entreprise, d’où son appellation.
Elles sont constituées des applications de gestion des opérations courantes de l’entreprise.

Application opérationnelle Processus géré


Gestion commerciale ou suivi des clients. Suivi des conditions de l’exécution des contrats de vente.
Gestion des achats et des approvisionnements. Suivi des conditions de l’exécution des contrats d’achats.
Gestion de production. Suivi de la production, de la fiche produit issue de la concep-
tion à l’entrée en stock.
Gestion de la maintenance et des garanties. Gestion du service maintenance (toutes les fonctions d’une
entreprise sont présentes au service maintenance).
Paie et la gestion des ressources humaines. Gestion du potentiel humain, prise en compte des obliga-
tions en matière de paie.
Comptabilité et la gestion financière. Gestion de la comptabilité en fonction des règles en vigueur.

90
CHAPITRE 2 – Structure du système d’information 1
PARTIE

L’appellation d’application opérationnelle remplace celle d’application fonctionnelle.


Pourquoi cette modification du vocabulaire ?

Une application fonctionnelle était une application destinée à une fonction de l’entreprise. Elle
concernait un service. Les applications fonctionnelles correspondaient donc à l’organigramme de
l’entreprise et assimilaient la notion de groupe de travail à celle de service.
La vision des organisations ayant évolué, les applications informatiques prennent en compte cette
évolution.
En premier lieu, une application opérationnelle gère un processus. Celui-ci se déroule, le plus
souvent, de manière transversale par rapport aux services. Le groupe de travail lié au processus est
constitué d’acteurs appartenant à différents services.
Ensuite, une fonction, au sens traditionnel du terme, peut être concernée par plusieurs processus,
donc par plusieurs applications opérationnelles.

EXEMPLE
Dans une entreprise de vente par correspondance, on a plusieurs applications de gestion des achats
et approvisionnements. Une première application gère les articles de faible valeur et de faible volume
que l’on est amené à stocker dans les entrepôts de l’entreprise de VPC, à partir desquels on procèdera
à la livraison au client final.
Une seconde application gère le cas des articles à forte valeur ou de gros volumes qui seront livrés aux
clients par le fournisseur. Cette seconde application possède deux variantes : pour les fournisseurs
importants, pour lesquels un minimum de commandes hebdomadaires est atteint, les échanges
d’information sont dématérialisés et réalisés par une application EDI ; pour les autres, le circuit des
informations est plus classique, les informations sont transmises par fax.

1.2 Méthodologie de construction d’applications opérationnelles évolutives


Parmi les applications opérationnelles, certaines diffèrent peu d’un type d’activité à l’autre.
C’est le cas de la comptabilité et, dans une moindre mesure, de la paie.
Il est donc facile de recourir à des logiciels standard du marché ou progiciels pour se doter
de ces applications.
En ce qui concerne les applications liées à la nature de l’activité, telles que les suivis des
opérations avec les clients et les fournisseurs ou la gestion de production dans les entre-
prises industrielles, il est plus difficile d’avoir recours à une application standard, à moins
d’accepter une adéquation partielle aux besoins. Dans ce cas, le logiciel ne permettra pas un
contrôle total du système par insuffisance de complexité ou par inadaptation aux habitudes
et à l’histoire de l’entreprise.
Une voie médiane existe cependant entre le logiciel spécifique et le progiciel standard, sans
égard au type d’activité, il s’agit de progiciels « métiers » développés par des éditeurs de type
VAR ou travaillant sur des marchés de niches.
Un progiciel n’est pas nécessairement rigide et non évolutif.
Pour permettre une certaine souplesse du logiciel, l’éditeur prévoit un maximum de
paramétrages qui sont à effectuer à l’ouverture du dossier ou dans le courant de l’utilisation
du produit, de manière à offrir une possibilité d’adéquation aux besoins de l’entreprise et à
leur évolution.

91
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Les applications opérationnelles standard, ou progiciels, possèdent des caractéristiques


communes, notamment lorsqu’elles fonctionnent dans un environnement graphique utili-
sateur (GUI, dont l’exemple le plus répandu est Windows).
LES CARACTÉRISTIQUES D’UN PROGICIEL

Fonctions Utilisations
Existence d’un programme d’installation automatique. Décompression des fichiers fournis, souvent en téléchar-
gement ou éventuellement sur CD ou DVD.
Création des groupes et icônes permettant d’utiliser
directement l’application à partir du bureau.
Fourniture d’outils de paramétrage, d’ouverture Toutes les codifications et tous les objets de base du
de dossier et de gestion des données permanentes système.
ou structurelles. Toute application de gestion correspond à une structure
de données possédant :
– des codes appartenant à des objets paramètres ;
– des objets de base du système pivots de l’application,
dont les données sont utilisées ensuite dans le
traitement des flux.
Fourniture d’une documentation. Autrefois fournie uniquement sous forme papier, elle
laisse, de plus en plus, la place à une documentation en
ligne, fournissant une aide contextuelle omniprésente,
lors de l’utilisation de l’application.

EXEMPLE
Un artisan a acheté un progiciel de comptabilité et de facturation dans un rayon spécialisé d’une
enseigne de la grande distribution. Il utilise l’installation automatique du produit à partir du CD
ROM présent dans la boîte du logiciel, qui comporte également une documentation simplifiée,
concernant notamment les modalités d’installation et d’enregistrement en ligne. L’installation
automatique se déroule suivant les phases définies précédemment. À l’issue de celle-ci, le programme
d’installation demande à l’utilisateur de se connecter à Internet pour obtenir la clé d’activation de
son logiciel. Cela constitue une mesure de protection contre le piratage, mise en place par les
principaux éditeurs de logiciels standard.

Les différents domaines des applications opérationnelles vont être envisagés ci-dessous, pour
en donner les caractéristiques essentielles, que l’on retrouvera dans les progiciels du marché.
Le recours aux progiciels de gestion intégrés (PGI) sera traité ultérieurement.
Part. 3, chap. 9
Pour présenter les différents types d’application, nous aurons recours à deux types de
schémas :
– le premier présentera une organisation type du processus concerné ;
– le second présentera une structure de données types associée au processus.
Rappelons que traiter des informations consiste à appliquer des procédures de traitements à des
structures de données. Comprendre comment fonctionne une application, qui doit permettre la
gestion d’un processus, nécessite d’envisager ces deux aspects, modélisation du processus et de la
structure de données sous-jacente.

92
CHAPITRE 2 – Structure du système d’information 1
PARTIE

1.3 Présentation des types d’applications opérationnelles usuelles


a) Applications liées au suivi des contrats d’achat-vente
(relations avec les tiers clients et fournisseurs)
Bien que les objectifs de gestion soient différents, dans le cas du suivi des commandes des
clients et du suivi des commandes des fournisseurs, il s’agit toujours de suivre les étapes du
cycle de vie d’un contrat de vente. L’enchaînement des flux d’informations, matérialisés par
une succession de documents, est donc le même dans les deux cas. Pour une organisation,
les deux types d’applications seront liés par une sorte d’effet miroir, où l’on inverse le sens
de la relation. C’est pourquoi les caractéristiques générales des deux types d’application ne
feront l’objet que d’une seule présentation.

REPRÉSENTATION DU PROCESSUS SUIVI DES CLIENTS


INTÉGRANT LA DÉMARCHE COMMERCIALE, QUI ABOUTIT AU RÉFÉRENCEMENT PAR LE CLIENT

PRO02-1
PRO06 :
Dossier Client Réclamations clients

Commandes clients
CDCL PRO02-2 PRO02-3
Gestion Commande Référencement
Assistante Commerciale
ACOM

PRO02-4 PRO02-5
Responsable Expédition Facturation
Expédition Marchandises
EXPE
Administration des Ventes
PRO02-6
ADV
Gestion des règlements

Comptabilité Client
CCLI

■ Commentaire général concernant la construction de ce type de schéma


Pour représenter les processus on a recours ici à une utilisation du modèle des cas d’utili-
sation d’Ivar Jacobson, légèrement modifié.

Commandes clients
CDCL

93
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Les acteurs sont des membres du groupe de travail en charge du processus. Ils sont respon-
sables des cas d’utilisation ou sous processus.

PRO02-2
Gestion Commande

Les cas d’utilisation, ou sous processus, représentent un lot de tâches et de traitements de


l’information, sous la responsabilité d’un acteur unique. Les cas d’utilisation sont liés entre
eux par une relation logique et chronologique, qui signifie que l’enchaînement des tâches
des différents acteurs doit respecter un ordre dans le processus. Les acteurs du groupe de
travail sont assimilables à des coureurs d’une équipe de relais. Ils enchaînent leurs efforts,
dans un ordre préétabli, et se passent le témoin.
PRO06 :
Réclamations clients

L’accès à un processus connexe. Cette représentation n’existe pas dans le modèle de départ
d’Ivar Jacobson. Il permet de faire apparaître les liens entre les processus. Cela matérialise
l’idée qu’un système est un tout dans lequel des processus entre en interaction.

REPRÉSENTATION DU PROCESSUS SUIVI DES FOURNISSEURS


INTÉGRANT UNIQUEMENT LES OPÉRATIONS RELATIVES À L’APPROVISIONNEMENT.
LE PROCESSUS ACHAT APPARAÎT COMME UN PROCESSUS CONNEXE

PRO01 :
Processus Achats Référencement Composant-Fournisseur
PRO03-1
Gestion Commande
PRO04 : Besoins MP et EMB Responsable Approvisionnement
APRO
Processus
Production

PRO03-2
Réception Marchandises

Réception
PRO03-3 RECE
Contrôle factures

Administration Achats PRO03-4


ADA
Règlement Fournisseur
Comptabilité Fournisseur
CFOU

94
CHAPITRE 2 – Structure du système d’information 1
PARTIE

■ Commentaire du modèle de processus « référencement »


Un premier processus, appelé référencement, consiste à gérer la recherche du fournisseur
et du produit. Ce processus est sous la responsabilité du service Achats. Acheter consiste à
référencer, alors qu’approvisionner consiste à passer les commandes et à gérer le niveau des
stocks. Bien que sous la responsabilité des acheteurs, ce processus a pour but de satisfaire les
besoins d’autres services, tels que les services marketing, R&D, production, maintenance.

PROBLÈMES PRIS EN COMPTE DANS LE PROCESSUS RÉFÉRENCEMENT

Étapes du processus Objectifs


Prise en compte des besoins en matière de R&D, Le fournisseur devra mettre en œuvre cette méthode
définis par les cahiers des charges du marketing, pour définir le type de réponse, qu’il peut technique-
et mise en pratique de l’analyse de la valeur. ment et commercialement apporter à la demande du
client.
Mise en place d’une revue de contrat. Dans une optique Identifier correctement et sans délai, le contenu de la
d’assurance qualité, des procédures sont à mettre en demande du client.
place, pour s’assurer que la demande du client recevra Organiser le circuit des informations qui permettra de
une réponse circonstanciée dans des délais normaux construire la réponse à l’appel d’offres du client, par éta-
ou conformes aux exigences du client. pes, en faisant circuler le dossier dans les services
concernés par la demande.
Mise en place des données d’assurance qualité, Il faut posséder les informations nécessaires au suivi
cohérentes avec le dossier du client, lorsque celui-ci ultérieur des commandes qui seront passées par le
accepte l’offre qui lui a été faite. client ou aux fournisseurs, afin d’élaborer un produit
conforme. Pour ce qui concerne le client, il doit mettre
en place les critères d’évaluation de la prestation du
fournisseur.
Mise en place des données dans la cas d’un nouveau Avant toute acceptation de commande, il faudra véri-
client. fier la solvabilité du client, mettre en place l’en cours
autorisé avec ou sans assurance du crédit client et sui-
vre son évolution au fur et à mesure des flux de com-
mandes.
Négociation des conditions de la charte tarifaire Assurer un fonctionnement de qualité dans l’adminis-
annuelle ou saisonnière, qui devra être écrite et tration des ventes.
constituera la base des informations à appliquer
dans l’exécution du référencement.

Un logiciel de gestion commerciale pourra proposer des fonctions permettant de gérer ce


premier processus de la relation client-fournisseur.
Des variantes très importantes de ce processus existent suivant que l’entreprise vend des
produits ou marchandises standard en fonction d’un catalogue, ou qu’elle propose une
solution spécifique à chaque client, dans le cadre d’un devis préalable.
Le logiciel choisi devra donc tenir compte de l’option nécessaire, qui relève d’une gestion
par produits ou d’une gestion par affaires. Si l’entreprise a les deux types d’activité, elle
devra avoir les deux variantes dans son système d’information.

95
1 CHAPITRE 2 – Structure du système d’information
PARTIE

■ Commentaire du modèle de processus « gestion des commandes »


Un second processus consiste à gérer les commandes.
Il s’agit de l’approvisionnement.

PROBLÈMES PRIS EN COMPTE DANS LE PROCESSUS RÉFÉRENCEMENT

Étapes du processus Objectifs


La première étape consiste dans la prise de commandes. Les Des procédures doivent être mises en place :
manières d’intégrer la commande du client dans le système – chez le fournisseur, pour définir les conditions d’acceptation
d’information peuvent être variables. de la commande du client, car cela vaudra création du contrat
Les commandes peuvent être saisies. Cependant, pour des rai- de vente et entraînera la naissance de ses obligations vis-à-vis
sons de rapidité de transmission des informations et de réduc- du client ;
tion des erreurs, elles sont de plus en plus souvent transmises – chez le client, pour s’assurer que l’on respecte bien les
par des procédés télématiques : Internet ou EDI (Échange de données d’achat lors de la passation des commandes au
Données Informatisées). fournisseur.
La seconde étape consiste à gérer la livraison. Elle incluse la Chez le client, la livraison entraînera un contrôle s’exerçant
résolution des questions relatives à la gestion des stocks. sur :
Cette phase comporte : – l’état des produits à réception,
– la résolution des problèmes logistiques, pour permettre de – la conformité à la commande,
préparer la livraison, – la conformité du contenu des colis avec les mentions du bon
– la gestion de l’identification des colis, qui permettra la mise de livraison qui les accompagne.
en place de la traçabilité, Le schéma de processus montre qu’il ne peut y avoir de livrai-
– l’édition du bon de livraison, qui accompagnera la livraison et son, sans indentification d’une commande à livrer enregistrée
attestera, après signature du client à réception, que celle-ci a dans le système.
eu lieu.
La troisième étape consiste dans la gestion de la facturation. Cela implique la mise en application rigoureuse des conditions
Il importe de mettre en place des procédures, qui évitent de la charte tarifaire ou du marché, tant du coté du fournisseur
les erreurs de facturation, telles que les erreurs de prix ou que du côté du client.
d’adresse de facturation.
La quatrième étape concerne le suivi des règlements. Elle concerne l’imputation des règlements sur les factures dues,
Dans le cas du règlement de la facture, elle débouche sur mais également l’élaboration des relances, en cas de non règle-
l’archivage. ment, dans les délais négociés.
Dans le cas de non règlement, à l’issue des trois relances pré-
vues, cette étape entraîne le passage au processus Mise au
Contentieux.

EXEMPLE
Il arrive fréquemment que les prix changent à cause des opérations de promotions. Le suivi des avoirs
de prix et de quantités, qui correspond à des corrections d’erreurs de transmission des informations, est
donc un bon indicateur de qualité.
Dans une entreprise de l’agroalimentaire qui fournissait une enseigne où chaque hypermarché
décidait de ces périodes de promotions, cet indicateur avait révélé pour un mois la réalisation
d’environ 300 avoirs de prix, pour quelque 150 magasins facturés. Rappelons que l’on fait un avoir de
prix lorsque le prix initial sur la facture est plus élevé que celui négocié par le client.
L’application permettant d’automatiser les périodes de promotion par magasin pour appliquer le prix
prévu dans ce cas à la charte tarifaire, la fréquence de ces événements de non-qualité pouvait sembler

96
CHAPITRE 2 – Structure du système d’information 1
PARTIE

étonnante. Il fallait y remédier car cela ternissait l’image de l’entreprise auprès des magasins, qui
devaient effectuer des réclamations. Et cela coûtait très cher à l’entreprise en coûts parasites (on
évaluait dans cette entreprise à environ 2 € le coût de réalisation d’un avoir). L’analyse des causes a
permis de montrer qu’il y avait une incompréhension entre le client et le fournisseur sur la notion de
dates de promotion. Le client considérait la période de disposition des produits dans son linéaire,
tandis que le fournisseur faisait correspondre ses périodes à ses dates de bons de livraison, départ usine.
En conséquence, il y avait un décalage d’environ 5 jours dans la définition des deux périodes. La mise
en place de l’indicateur dans l’application de gestion commerciale a permis de résoudre le problème
sur une période de deux mois.

■ La structure de données sous-jacente au processus du suivi


des contrats d’achat-vente

Secteur Zone
Enseigne Familles
d'activité géographique

Tiers (Client ou Produits


Fournisseur)
Commandes

Lots
Bons de
livraisons

Légende :
Facture Paramètres codifiés
Objets de base ou pivots
Objets représentation des
Règlement flux d’activité

• Les paramètres codifiés


Un certain nombre de codifications sont nécessaires pour structurer l’analyse des données
ultérieure. Elles constitueront des dimensions d’analyse permettant de recherche des expli-
cations aux résultats obtenus. Elles pourront être utilisées dans les fonctions statistiques des
applications opérationnelles, mais elles prendront tout leur intérêt dans le cadre des appli-
cations décisionnelles.
Elles peuvent également constituer des données de base, pour appliquer des règles de
gestion, permettant de différencier les objets du système.
EXEMPLE
La notion d’enseigne permettra d’appliquer le bon référencement et la bonne charte tarifaire à
chaque tiers.
Imaginons un fabricant qui produit des articles à la marque de l’enseigne Carrefour et d’autres à la
marque d’Auchan.

97
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Il est fondamental de ne pas commettre d’erreurs de livraison. On pourra utiliser la codification de


l’enseigne dans la fiche du client et l’association entre le référencement et l’enseigne, pour supprimer
ce risque d’erreurs.

• Les objets de bases ou pivots


– les produits, biens ou prestations de services vendus ou les matières, emballages ou
marchandise achetés. Les produits seront éventuellement gérés par lots. Dans ce cas, la
commande du client concernera des produits et la livraison du fournisseur, des lots de ces
produits ;
– les tiers, clients ou fournisseurs, suivant l’application.
Les données dont on dispose concernant ces objets, appelées données permanentes ou
structurelles, servent de pivot à la gestion des flux d’activité du processus.
Dans une application d’achat ou de vente, les flux mettent en permanence en relation le
produit et le tiers.
La mise à jour correcte, sans erreur, sans omission et sans délai, de ces informations est donc
essentielle au bon fonctionnement du processus. La plupart des événements de non-qualité
qui seront constatés dans la gestion des flux d’activité ont leur origine dans des erreurs au
niveau des données des objets pivots. L’organisation aura donc tout intérêt à définir une
procédure de mise à jour de ces données et un acteur responsable. Elle devra auditer
soigneusement le fonctionnement du sous processus et s’assurer de la compétence de
l’acteur. Part. 2, chap. 8
Ces données sont structurées de manière à rendre compte du couple missions des produits/
segmentation de la clientèle. Les produits sont regroupés en familles, éventuellement à
plusieurs niveaux, qui structurent les gammes de produits. De plus en plus fréquemment,
on tient compte également de la codification des marques pour tenir compte de l’existence
de marques propres et de marques de distributeurs.
Les clients sont regroupés en catégories, en enseignes et en zones géographiques, afin de
définir les typologies de clientèles.
• Les objets représentation des flux d’activité
Les flux d’activité représentent l’enchaînement des étapes du cycle de vie du contrat de
vente. Leur gestion permet de produire les documents nécessaires au suivi de celui-ci, y
compris sur le plan du droit commercial.
La commande saisie et validée dans le système attestera de la naissance du contrat de vente.
Le client a élaboré son bon de commande et le fournisseur l’a intégré dans sa gestion
commerciale, cela prouve l’accord des parties. Les relations commerciales s’appuient sur
des habitudes relatives aux différents secteurs d’activité, la manière de gérer les flux
d’activité doit respecter les us et coutumes du secteur.
EXEMPLE
Dans la distribution de fruits et légumes en gros, notamment dans le cadre des Marchés d’Intérêts
Nationaux (MIN), il existe différentes modalités d’achat. À l’importation, il arrive fréquemment que le
prix d’achat ne soit pas fixé, mais qu’il soit déduit du prix moyen de vente du lot duquel on déduit
les frais annexes sur achat et un pourcentage de marge du distributeur négocié avec le fournisseur. Il
arrive également que la facture du fournisseur soit établie par le client lorsque le fournisseur est un
petit maraîcher.

98
CHAPITRE 2 – Structure du système d’information 1
PARTIE

La livraison ne devra pouvoir intervenir que dans la mesure où l’on identifie une commande
à livrer. Suivant les secteurs d’activité, le fournisseur pourra procéder à des livraisons
partielles. Dans ce cas, l’application devra être capable de gérer les reliquats. Si le tarif
pratiqué est fonction de la quantité livrée, l’application devra être capable de distinguer une
quantité livrée conforme à la quantité commandée, d’une quantité livrée correspondant à
un reliquat de livraison.
Certaines activités nécessitent l’édition de documents complémentaires au moment de la
livraison.

EXEMPLE
Pour un transport organisé en tournée, un état de la tournée est nécessaire. Il doit mentionner les
codes des produits dangereux, le cas échant
Pour les transports en froid négatif, le contrôle de la non-rupture de la chaîne du froid pendant le
transport nécessite de faire signer au départ, par le chauffeur, un document attestant du relevé de
température du camion et au cœur des produits.

La facturation ne devra pouvoir intervenir que pour une livraison effectuée. Un contrôle
devra exister permettant, en fin d’une période déterminée, de s’assurer que tous les bons de
livraison de la période ont été facturés. On peut appliquer diverses règles de gestion en
matière de facturation. Soit on pratique la pré facturation, ce qui signifie que, dès l’émission
du bon de livraison, on peut établir la facture sans attendre le retour du bon de livraison,
acquitté par le client ; on s’expose alors à devoir faire des avoirs en cas de litige. Soit on fait
de la post-facturation, on attend le retour du bon de livraison et on tient compte des
mentions du client pour établir la facture. Le choix entre les deux méthodes appartient
également aux habitudes sectorielles.
Dans certaines activités, les clients ne règlent pas au vu des factures, mais exigent un relevé
de factures périodiques qui leur servira de base pour effectuer leurs règlements.
De nos jours, on considère comme normal qu’une interface existe entre la facturation et la
comptabilité, afin d’éviter la comptabilisation manuelle des factures.
La législation en vigueur exigeant une séquence de numérotation continue des factures, il
peut être pratique de disposer d’une application introduisant la notion de préfactures ou de
brouillons de factures. Elle permettra de faire des modifications et de suppressions
librement. Ce n’est qu’après validation de cette étape que seront générées les factures défini-
tives, avec une numérotation sans rupture. Cette étape ayant été franchie, l’annulation
d’une facture définitive impliquera la génération automatique d’un avoir et la production
d’une nouvelle facture, afin de ne pas rompre la séquence de numérotation. Si l’application
permet de réaliser cet enchaînement de manière automatique, ce sera un gain de produc-
tivité et de sécurité évident. Les factures devront pouvoir s’adapter à l’évolution des
mentions légales et calculer automatiquement les échéances de règlement en fonction des
conditions accordées au client.

EXEMPLE
Depuis quelques années maintenant, il est obligatoire de faire figurer le numéro de TVA intracommu-
nautaire du client sur la facture.
Cela implique :
– de posséder un champ dans la base de donnés permettant de stocker celui-ci dans la fiche du client ;

99
1 CHAPITRE 2 – Structure du système d’information
PARTIE

– de modifier l’interface homme machine, qui permet de saisir la fiche client, pour entrer cette nou-
velle donnée ;
– de modifier l’édition du document facture pour rajouter cette mention.

La gestion des règlements devra permettre d’imputer plusieurs règlements sur une même
facture, pour tenir compte des règlements partiels, et d’imputer un règlement sur plusieurs
factures, pour tenir compte des règlements groupés ou des règlements sur relevés de
factures, qui ne sont pas comptabilisés. Elle devra permettre de lettrer les comptes indivi-
duels de tiers par le biais de l’imputation des règlements, afin de gagner du temps. Elle
permettra, le plus souvent, de récupérer les règlements par effets de commerce et par
virements, sur les comptes bancaires par téléchargement.
Gérer les règlements consiste également à suivre les relances en cas de dépassement des
délais accordés. Les relances doivent pouvoir être générées automatiquement et être
graduées avec au minimum trois relances successives, en cas de non-paiement. Cela
permettra, le cas échéant, de justifier de provisionner une créance non réglée et, dans la
plupart des cas, cela permettra de procéder à l’encaissement du règlement qui a souvent été
omis par le client.
Il faudra se méfier de cet automatisme des relances, en termes de procédures d’organisation.

EXEMPLE
Dans une PME, le service administration des ventes qui établissait les factures était également respon-
sable de la production et de l’envoi des lettres de relance. Il s’acquittait de cette tâche très réguliè-
rement, celle-ci étant automatisée dans le logiciel de gestion commerciale. Parallèlement,
l’imputation des règlements des clients était effectuée par le service comptable, qui avait très souvent
deux à trois semaines de retard dans ce travail. En conséquence, les clients recevaient des lettres de
relances fréquentes alors qu’ils avaient déjà réglé les factures. Ce n’était pas susceptible d’améliorer
l’image de l’entreprise auprès de ses clients !

La gestion commerciale est l’un des domaines les plus concernés par les outils d’aide à la
décision. Il existe des statistiques commerciales dans le cadre des progiciels de gestion
commerciale. Mais c’est insuffisant pour aider à la prise de décision en ce domaine. Les
décideurs souhaitent disposer d’outils d’analyses de données multidimensionnelles, qui
leurs permettent de comprendre le comportement de leurs clients et l’évolution de ce
comportement.
Pour une présentation détaillée de ces outils ⇒ Part. 1, chap. 2, sect. 2-2
Cependant, il faut bien se souvenir que les outils d’aide à la décision auront leur source de
données dans l’application opérationnelle de gestion commerciale et que la qualité des
résultats qu’ils pourront fournir sera contingente à la qualité des données de celle-ci.

100
CHAPITRE 2 – Structure du système d’information 1
PARTIE

b) Application comptable

PRO09-1-1
PRO10 :
Processus
RH/paie Saisie des écritures
Paie/
cotisations sociales
PRO03 : extension
Processus Approvi-
sionnements Facturations/
réglements fournisseurs
PRO09-1-2
Facturations/
réglements fournisseurs Intégration utilise Comptable
PRO05 : des écritures
Processus utilise
Maintenance
Facturations/
règlements clients
PRO10 :
Processus utilise
vente

PRO09-2
utilise
Production du reporting mensuel
Chef
comptable

PRO09-3

Production des comptes annuels

PRO09-4
Domaine Application
d’Audit Révision des comptes annuels

Expert comptable

utilise

PRO09-5

Commissaire
aux comptes
Audit des comptes CAC

■ Commentaire du modèle de processus « tenue de la comptabilité »


Le processus géré par le logiciel doit respecter les règles de la loi comptable. Notamment
celles concernant la non modification des écritures comptables validées et la production des
documents. Cette exigence se traduit souvent, par une saisie dans un fichier temporaire
appelé un brouillard, puis par une validation périodique des écritures les rendant défini-

101
1 CHAPITRE 2 – Structure du système d’information
PARTIE

tives. Les écritures du brouillard étant considérées comme provisoires, elles peuvent être
modifiées ou supprimées. Par contre, les écritures une fois validées deviennent définitives et
toute modification ultérieure devra donner lieu à une contrepassation de l’écriture erronée
et à la saisie d’une nouvelle écriture exacte.
Une alternative consiste à valider les écritures au moment d’une clôture de période. Cette
solution est correcte sur le plan légal, mais moins souple pour l’organisation du travail de
contrôle des imputations comptables.
La première solution permet :
– de contrôler les écritures provisoires par lots, grâce à une édition par brouillard ;
– de ne pas pouvoir revenir en arrière sur une période clôturée, en général le mois.
La plupart des écritures ne sont pas saisies, mais intégrées automatiquement grâce à des
interfaces avec les autres applications opérationnelles.
Le logiciel doit disposer des éditions des documents comptables, obligatoires ou non :
journaux, grands-livres, balances, compte de résultat et bilan. Certains comptes font l’objet de
nombreux sous-comptes individuels, comme les fournisseurs ou les clients. Il est donc utile de
posséder des comptabilités auxiliaires détaillées et une centralisation en comptabilité générale.
L’application peut fournir des outils complémentaires tels que :
– analyse de comptes de gestion sur différents critères ;
– calcul des tableaux d’amortissements des immobilisations ;
– lettrage des comptes ;
– et rapprochements bancaires.
Il est important pour une entreprise, notamment si elle est de petite taille, de bien
paramétrer son logiciel de comptabilité. La manière de structurer le plan de comptes,
notamment pour les comptes de charges et de produits peut conditionner la possibilité
d’obtenir des états d’analyse, qui seront pour elle des états de gestion.

EXEMPLE
Une maison de la presse vend des journaux, des livres et de la papeterie. Le dirigeant pourra prévoir
une ventilation des comptes de ventes en sous-comptes par secteur d’activité pour obtenir la venti-
lation du chiffre d’affaires de chaque période. Il pourra faire de même pour les comptes d’achat et
toutes les charges qui peuvent être isolées par secteur d’activité. Cela lui permettra de calculer de
manière simple une marge brute de chaque activité et de voir comment elles évoluent dans le temps.

Par contre, on ne peut pas attendre du seul système d’information comptable la production
d’une comptabilité de gestion en permettant le pilotage. Ces outils ne peuvent émaner que
de la gestion et du contrôle des flux d’activité.
Le progiciel de comptabilité peut également offrir la possibilité d’obtenir :
– des états commodes pour le lettrage (pointage) des comptes ;
– des balances âgées pour les tiers ;
– des échéanciers.
Il peut aussi fournir des outils d’analyse financière.

102
CHAPITRE 2 – Structure du système d’information 1
PARTIE

■ La structure de données sous-jacente au processus du tenue de la comptabilité

Journaux Types de
auxiliaires pièces
Regroupements

Plans de
comptes

Écritures

Légendes :
Paramètres codifiés
Objets de base ou pivots
Documents Objets représentation
comptables des flux d’activité

• Les paramètres codifiés


Le système d’information comptable appelle les remarques suivantes :
– il doit avoir la possibilité de gérer des dossiers multiples avec le même logiciel. En dehors
des cabinets d’experts-comptables et des centres de gestion agréés, de nombreuses entre-
prises, même de taille moyenne, se trouvent au sein de groupes ayant à leur tête les mêmes
dirigeants et possédant parfois un service comptable commun. Il est donc très commode
de posséder un logiciel multisociété permettant de tenir la comptabilité de toutes les
entreprises concernées, voire de consolider les résultats ;
– il doit disposer d’une gestion des paramètres codifiés, qui consistent à définir des regroupe-
ments des comptes pour différents usages, calcul et édition du compte de résultat et du bilan,
production de la liasse fiscale, calcul et édition du tableau des emplois et ressources, etc.
• Les objets de bases ou pivots
Le logiciel de comptabilité doit disposer d’une gestion des objets de base que sont :
– les journaux auxiliaires ;
– les types de pièces ;
– le plan de comptes.
Cela permet d’ouvrir des journaux auxiliaires et de structurer le plan comptable, en
fonction des besoins.
• Les objets représentation des flux d’activité
L’objet représentation des flux est l’écriture comptable, ou plutôt la ligne d’écriture
comptable. Actuellement, la majorité des écritures de base qui retranscrivent dans le
langage comptable les flux d’activités courants de l’organisation sont comptabilisée de
manière automatique, grâce à des interfaces. La saisie manuelle concernera des opérations
de fin d’exercice ou de régularisation. À partir des écritures et des données pivots, il est
possible de produire tous les documents nécessaires.

103
1 CHAPITRE 2 – Structure du système d’information
PARTIE

• Fonctionnement du logiciel de comptabilité


– la saisie des écritures comptables, qui constitue la collecte des informations, se fait dans
le cadre de journaux auxiliaires, en écriture guidée ou directe, souvent par une saisie
temporaire dans un brouillard. De plus en plus fréquemment, les écritures comptables
liées aux factures de ventes et d’achats, aux salaires ou opérations bancaires, sont générées
automatiquement par le biais de programmes interfaces, avec les autres domaines
d’applications opérationnelles. Il semble préférable que l’enregistrement des écritures,
même dans le brouillard, soit soumis à un contrôle préalable d’équilibre entre les débits
et les crédits. L’expérience prouve que les erreurs et les sommes imputées automati-
quement en comptes d’attente sont plus difficiles à justifier a posteriori qu’à l’origine ;
– la saisie, lorsqu’elle s’effectue dans un brouillard, peut être pointée, puis faire l’objet de
modifications ou de suppressions. L’existence d’un brouillard facilite l’organisation du
travail comptable en permettant de travailler par lots d’écritures qui une fois pointées
pourront devenir définitives. L’utilisation de la notion de journaux auxiliaires, tant au
niveau du brouillard que des écritures définitives, facilite la division du travail au sein du
service comptable ;
– le lettrage permet de justifier les comptes en rapprochant les écritures et en imputant les
débits et les crédits. L’opération de lettrage peut être réalisée automatiquement par le
système informatique en rapprochant les écritures, soit sur le numéro de pièce, soit sur les
sommes. C’est le cas dans le pointage automatique des comptes de tiers ou dans le rappro-
chement bancaire. Le lettrage peut également être manuel. L’utilisateur consulte le
compte à l’écran et saisit lui-même les codes de lettrage qui rapprochent les écritures à
imputer réciproquement. Il peut y avoir un système de lettrage de plusieurs comptes à la
fois qui génèrent les écritures de virements pour solde de manière automatique. Ce
système peut être utile dans le cas où l’éclatement des fonctions du client amène que le
débiteur ne soit pas celui qui règle les factures ;
– les écritures sont rendues définitives au plus tard lors d’une clôture de période, qui inter-
vient, en règle générale, à la fin de chaque mois. Elles peuvent être rendues définitives par
une mise à jour par lots, après pointage d’un lot d’écritures au brouillard. La clôture de
période doit s’accompagner de l’interdiction de saisir à nouveau des écritures à une date
antérieure à celle de la dernière clôture pratiquée ;
– l’obtention des documents comptables : une seule saisie permet d’éditer avec une
fiabilité totale l’ensemble des documents obligatoires et d’obtenir des outils d’analyse de
comptes. Le système de normalisation de la comptabilité amène à produire des
documents, où les écritures sont classées dans des ordres différents.
EXEMPLE
Les journaux présentent les écritures par date, alors que les comptes et la balance les présentent par
numéro de compte.
En principe, aucune erreur de report n’est possible avec un logiciel de comptabilité. En effet les
écritures ne sont enregistrées qu’une seule fois. Pour obtenir divers ordres d’édition, on utilise diffé-
rentes clés d’accès à la même information.

En conclusion, le logiciel de comptabilité est l’application la plus standard, car la plus normalisée.
Elle peut donc correspondre à une solution progicielle. Néanmoins, il faut s’assurer que ce type de
choix ne remettra pas en cause la productivité et la sécurité que donnent la possibilité de compta-
bilisation automatique, par interfaces avec les autres applications.

104
CHAPITRE 2 – Structure du système d’information 1
PARTIE

c) Application de gestion des ressources humaines et de la paie


PRO10-1
Dossier salarié
Domaine Gestion de la paie
utilise
PRO10-2
Responsable Personnel
Contrat de travail

PRO10-3
PRO04 :
Processus Saisie des événements
Gestion de (mouvements mensuels)
production
PRO10-3-3 extension
Absences, heures
supplémentaires, primes
Intégration
des badgeuses

extension
PRO10-3-2
PRO05 : Responsable
Processus Intégration utilise Paie
Gestion de Absences, des événements
maintenance heures supplémentaires, (mouvements
primes mensuels)

utilise
PRO10-4

Traitement du salaire mensuel

utilise Chef du
personnel

PRO10-5

Traitement annuel (DADS-U etc.)

utilise

Domaine Gestion des PRO10-6


ressources humaines
utilise Gestion du potentiel humain
Recrutement, Formation, Évaluation
DRH

PRO10-7

Gestion de la masse
salariale

PRO10-8 utilise

Bilan social

105
1 CHAPITRE 2 – Structure du système d’information
PARTIE

■ Commentaire du modèle de processus « tenue de la comptabilité »


Les processus paie et gestion des ressources humaines reposent sur les informations du
dossier du salarié.
En France, compte tenu de la complexité des statuts, la gestion des contrats de travail repré-
sente un aspect important du suivi sur salarié, entraînant de nombreuses conséquences sur
la gestion ultérieure.
Le traitement de la paie et de toutes les tâches annexes présente beaucoup de complexité et
un très fort taux d’évolutivité en France, où les règles en la matière servent depuis de
nombreuses années d’instrument de politique économique, influençant le taux de salaire
réellement supporté par les organisations.
Du point du management de l’organisation, il est nécessaire de dépasser la seule gestion des
salaires, pour mettre en place une véritable gestion du potentiel humain.
■ La structure de données sous-jacente au processus du gestion de la paie

Catégories de Plan
catégoriel Rubriques
personnel

Plan
Salarié personnel

Mouvements
de paie

Légendes
Paramètres codifiés

Documents à Objets de base ou pivots


produire Objets représentation
des flux d'activité

L’application doit disposer de données paramètres concernant les catégories de salariés qui
permettent de déterminer leur statut et leur mode de rémunération.
Elle doit disposer de rubriques de paie et d’un paramétrage de leur mode de calcul,
Des profils ou plans de rubriques permettent de définir la structure d’un bulletin de paie
type pour une catégorie de salariés, afin d’adapter le mode de calcul au statut d’un salarié.
Un plan catégoriel est donc une liste de rubriques de calcul de paie s’appliquant à un profil
de salarié.
Il est souvent nécessaire de posséder des plans individuels, afin d’adapter les calculs à
chaque individu. En règle générale, simple duplication du plan catégoriel, il permet
d’individualiser les situations.

106
CHAPITRE 2 – Structure du système d’information 1
PARTIE

• Les objets de bases ou pivots


Il s’agit des rubriques de paie qui permettent de définir les modalités de calcul des lignes
figurant sur le bulletin de salaire
Des informations relatives aux salariés.
• Les objets représentation des flux d’activité
À partir :
– des informations du dossier salarié, qui déterminent, par exemple, sa quotité de temps de
travail et son salaire mensuel brut ;
– de mouvements mensuels de paie, qui représentent les événements de la période pour le
salarié (par exemple, les jours de congés payés pris pendant le mois) ;
– de rubriques d’application permanente, comme l’adhésion à une mutuelle.
Le plan de rubrique personnel va permettre au programme de calcul d’élaborer le bulletin
de salaire de la période conformément au statut du salarié et aux événements le concernant.
• Fonctionnement du logiciel de paie et de gestion des ressources humaines
Ces données permettent :
– d’établir les bulletins de salaires ;
– d’éditer un journal de paie et de le transférer en comptabilité grâce à une interface de
comptabilisation ;
– d’élaborer les déclarations fiscales et sociales périodiques ;
– de générer les règlements, qui s’effectuent le plus souvent par virements sur supports
magnétiques ou télématiques ;
– d’éditer les fiches individuelles des salariés ;
– d’élaborer les déclarations annuelles des salaires, notamment la DADS-U, transmises par
Internet.
Mais, la gestion du personnel ne se limite pas à la gestion des salaires, c’est pourquoi les
logiciels proposent d’autres modules :
– la gestion des horaires : de nombreuses entreprises pratiquent l’horaire variable. Avec
l’introduction des 35 heures et la notion d’annualisation du temps de travail, la gestion de
l’ARTT nécessite des outils de suivi automatisé ;
– la gestion des congés payés : les salariés acquièrent et utilisent leurs droits aux congés
payés dans le cadre légal et conventionnel. Cette gestion peut être également prise en
compte par le logiciel, car elle requiert de nombreuses manipulations d’informations et
de nombreux contrôles et calculs, notamment concernant le montant de l’indemnité de
congés payés. Cela entraîne une mise à jour permanente des compteurs de congés acquis,
de congés pris et de congés à prendre, ce qui permet au responsable de renseigner les
salariés sur leur droit aux congés ;
– la gestion de la formation permanente : la gestion des actions de formation, sous toutes
leurs formes et celle du droit au congé formation et de la DIF représente également une
gestion lourde. C’est pourquoi de nombreux logiciels offrent une gestion automatisée ;
– la gestion des statistiques internes et externes. Les services du personnel se voient sollicités
pour fournir des informations d’ordre statistiques par des organismes très nombreux.
Suivant la taille de l’entreprise, elle est également soumise à l’obligation de fournir un

107
1 CHAPITRE 2 – Structure du système d’information
PARTIE

bilan social. Là encore, on trouve dans de nombreux logiciels la possibilité de traitements


automatisés.
La gestion des ressources humaines permettant de simuler les tendances d’évolution de la
masse salariale, du « turn-over », des profils de poste, etc.

L’ENCHAÎNEMENT DES OPÉRATIONS DE LA GESTION DES SALAIRES

Périodicité Opérations à effectuer Objectifs poursuivis


Mensuelle Un certain nombre d’événements vont rendre Il s’agit des absences, des congés, des heures
nécessaire la saisie de mouvements supplémentaires ou des primes.
ou variables de paie.
Mensuelle Grâce aux données permanentes, définies Fournir à chaque salarié son bulletin de salaire,
ci-dessus, et aux variables de paie, le calcul effectuer les virements des salaires.
des bulletins et leur édition seront possibles.
Mensuelle L’interface avec le progiciel comptable pour la Intégrer les écritures de paie dans le tableau
comptabilisation automatique des écritures. de bord mensuel.
Mensuelle/trimestrielle Calcul et édition les récapitulatifs de charges Calculer et éditer les déclarations de charges
salariales et patronales pour le règlement des sociales (éventuellement par trimestre pour les
cotisations aux différents organismes, petites structures).
permettant l’établissement des déclarations
fiscales et sociales.
Mensuelle/annuelle Édition :
– du journal de paie ;
– des fiches individuelles des salariés, incluant
les éléments sur l’année issues de leurs
fiches de paie.
Annuelle Effectuer la déclaration annuelle des salaires, Les informations à fournir étant modifiées tous
DADS-U, grâce à la possession d’un historique les ans, les progiciels prennent en compte
de paie et de très nombreuses codifications chaque année le cahier des charges de la
standard, fournies par l’administration. Cette DASD-U, pour fournir les modifications
déclaration est transmise par Internet. nécessaires à leur logiciel.

d) Applications de gestion de production


Ce type d’application concerne les entreprises industrielles.
C’est une application qui peut difficilement être standard, car elle doit être conforme au
process de fabrication, qui est lié au métier de l’entreprise. Néanmoins, pour éviter de faire
développer une application spécifique, on peut trouver des applications par métier, auprès
d’éditeurs de progiciels.

108
CHAPITRE 2 – Structure du système d’information 1
PARTIE

■ Les industries de montage


• Le schéma type du processus
PRO02 :
Processus
Commandes clients Commande
Client
PRO04-1

Planification de Production Besoins MP PRO03 :


et composants Processus
Direction de Production Approvision-
nement
DPRO

PRO04-4
PRO04-2
Affectation du Personnel
Fabrication des ensembles
Responsable Planning métier Contremaître fabrication
RPLA FAB

PRO04-3

Assemblage PRO04-5
Contremaître Assemblage
COND Contrôle Qualité
Responsable Qualité
RAQ

PRO04-6

Calcul des coûts


Contrôle de Gestion
CDG

Familles Catégories de Catégories de


machine personnel

Matières Gamme de Salariés


premières fabrication Machines

Composants
intermédiaires
Produits Bon de
travail

Nomenclature
multi niveaux Commandes
Légendes :
à fabriquer
Paramètres codifiés
Sorties de Objets de base ou pivots
stock Objets de représentation
des flux d’activité

109
1 CHAPITRE 2 – Structure du système d’information
PARTIE

• La structure de données sous-jacente


Les industries dites de montage appartiennent à des domaines tels que la mécanique ou
l’électronique. Leurs applications de gestion de production doivent avoir les caractéris-
tiques suivantes :
– liaison entre la Conception Assistée par Ordinateur (CAO) et la Gestion de Production
Assistée par Ordinateur (GPAO)
Dans ce type d’industrie, la création de produits nouveaux a gagné en productivité grâce
à la CAO. Mais le passage de la conception à la production nécessite de créer la nomen-
clature du produit, c’est-à-dire la liste de ses éléments composants dans la gestion de
production. Or, on possède déjà cette description dans l’application de conception. Afin
de gagner en productivité et en fiabilité, il est donc nécessaire de posséder une interface
entre les deux applications qui permette la mise à jour de la base de données de la gestion
de production à chaque création ou modification de la conception du produit. Cette
nomenclature est multi-niveaux, car on peut, soit partir de la matière première élémen-
taire, soit puiser dans le stock d’éléments composants intermédiaires déjà élaborés ;
– communication avec les partenaires, fournisseurs et sous-traitants, mais également distribu-
teurs. Les partenaires qui créent des éléments entrant dans la composition du produit,
comme les équipementiers dans le secteur automobile, doivent intervenir dès la
conception du produit. Ensuite, ils doivent fournir, en « juste à temps », la production et
assurer le contrôle qualité sur les composants qu’ils fournissent. Les applications infor-
matiques doivent donc être compatibles et les systèmes informatiques doivent pouvoir
communiquer par des réseaux télématiques appropriés.
– évolution des méthodes de gestion de production
La transition s’effectue d’une méthode de gestion planifiant de l’amont vers l’aval :
gestion suivant les règles du MRP I (Materials Requirements Planning) vers une méthode
de gestion planifiant de l’aval vers l’amont, conforme à la logique du Juste à Temps. :
gestion suivant les règles du CIM (Computer Integrated Manufacturing). La logique
initiale fondait la planification de la production et des besoins matières sur des prévisions
de ventes et sur la nécessité d’alimenter un stock tampon de produits finis et d’éléments
composants. La nouvelle logique (Juste à Temps), qui utilise les fiches Kanban, fonde la
planification de la production sur le carnet de commandes des clients.
■ Les industries de processus
Elles appartiennent à des domaines tels que l’alimentaire ou la chimie. Elles ont une gestion
de production aux caractéristiques très différentes de celles des industries de montage.

110
CHAPITRE 2 – Structure du système d’information 1
PARTIE

• Schéma type du processus

PRO02 :
Processus
Commandes clients Commande
Client
PRO04-1
Besoins MP et EMB PRO03 :
Planification de Production Processus
Direction de Production Approvision-
nement
DPRO

PRO04-4
PRO04-2
Affectation du Personnel
Préparation
Responsable Planning
Contremaître préparation
RPLA PREP

PRO04-3

Conditionnement PRO04-5
Contremaître Assemblage
COND Contrôle Laboratoire
Laboratoire Qualité
LABO

PRO04-6

Calcul des coûts


Contrôle de Gestion
CDG

• Structure de données sous-jacente

Familles Catégories de Catégories de


machine personnel

Matières Gamme de Salariés


Emballages Machines
premières fabrication

Nomenclature Produits Bon de


travail

Lots à
fabriquer Légendes :
Paramètres codifiés
Sorties de Objets de base ou pivots
stock
Objets de représentation
des flux d'activité

111
1 CHAPITRE 2 – Structure du système d’information
PARTIE

• La conception des produits n’utilise pas la CAO mais la recherche en laboratoire.


• Une des difficultés majeures consiste à gérer, dans les nomenclatures, les conversions
d’unités.

EXEMPLE
Il arrive fréquemment que l’on ait des formules de mélanges qui expriment les besoins en matières
premières dans une unité, alors que les stocks de certaines matières sont gérés dans d’autres unités.
Dans la fabrication de la glace à la vanille, le mélange sera exprimé pour une tonne. L’arôme liquide
de vanille est livré en conditionnement de 5 litres. Il faudra convertir le kg de vanille en litre, en tenant
compte de la densité de la vanille, pour savoir combien de litres de vanille sont nécessaire à la prépa-
ration du mélange.

• La succession de l’étape de mélange, soumise à des contraintes physico-chimiques, et de


l’étape de conditionnement, où se trouvent les goulots d’étranglements liés aux cadences
des machines, oblige ce type d’industrie à planifier la fabrication de l’aval vers l’amont.
Cela signifie que l’on doit d’abord définir le planning de la phase de conditionnement avant
de définir les préparations en fonction des contraintes physiques. Par contre, la production
à l’unité n’est pas une chose envisageable pour ce type de production. En effet, la
production industrielle de ces types de produits nécessite une certaine quantité de mélange
qui constitue une masse critique pour obtenir la réaction chimique souhaitée et les caracté-
ristiques optimales physico-chimiques du résultat.

EXEMPLE
Pour fabriquer un mélange de glace à la vanille, la cuve de macération du mélange doit comporter
une quantité minimale de 600 kg afin que les caractéristiques physico-chimiques optimales, saveur,
texture, couleur, puissent être obtenues. Cela va amener à conditionner plusieurs centaines de bacs. Si
on doit conditionner des bacs aux parfums panachés, il faudra autant de cuves de macération en
entrée de la ligne de conditionnement que de parfums différents et chaque cuve devra respecter la
masse critique du mélange.

Il existe de nombreuses solutions de gestion de production, orientées « métiers ».


Un tel système doit permettre :
– de gérer la planification et l’ordonnancement de la production ;
– d’assurer la traçabilité des opérations, depuis la réception des matières et composants, jusqu’à la
livraison au client, conformément aux exigences de la politique de la qualité totale ;
– de calculer les coûts de production et les comparer aux normes définies par les nomenclatures et
gammes de fabrication.

112
CHAPITRE 2 – Structure du système d’information 1
PARTIE

2. Applications décisionnelles

Elles peuvent avoir deux


types de structure
de données
Datawarehouse Reporting
Elles concernent
les décideurs :
elles sont subjectives

Hypercubes
Data Mart
APPLICATIONS
DÉCISIONNELLES
Data
ETL Mining
Extract, Transform
Load
ZOOM ANGLE DE VUE

Elles doivents respecter Elles fournissent


Bases
deux critères : trois types de résultats
opérationnelles
zoom et angle de vue

2.1 Objectifs des Systèmes Interactifs d’Aide à la Décision (SIAD)


L’entreprise vue comme un système global, comporte :
– des modules pilotes, qui doivent posséder des informations pertinentes pour prendre
leurs décisions ;
– des informations, qui sont acquises par le système d’information, dans le processus de
transformation des flux entrants en flux sortants, par les modules opérationnels.
On dit des applications décisionnelles qu’elles sont subjectives. Cela signifie que les infor-
mations, pour être pertinentes, doivent respecter le point de vue du destinataire et son
niveau de responsabilité au sein de la hiérarchie.
Le Système Interactif d’Aide à la Décision (SIAD) vise à doter les décideurs d’outils
d’analyse adéquats pour faciliter la prise de décision en terme de fiabilité et de rapidité.
Pour le construire, il est nécessaire de préciser ce que l’on entend exactement par la perti-
nence des informations fournies aux décideurs.
Pour qu’une information soit adaptée à son destinataire, il faut :
a) qu’elle soit conforme à son niveau hiérarchique
Cette exigence correspond à un effet de zoom par rapport au réel. Plus on monte dans la
hiérarchie, plus l’angle de vue sur le réel est grand, mais plus on voit le réel de loin, moins
on perçoit les détails. On a une vue d’ensemble. On voit la forêt, mais on ne détaille plus
chaque arbre.

113
1 CHAPITRE 2 – Structure du système d’information
PARTIE

EXEMPLE
Un commercial appartenant à la force de vente d’une filiale d’un groupe de l’alimentaire doit
posséder des informations sur le chiffre d’affaires qu’il a réalisé avec chacun de ces clients. Le
commercial appartient à un secteur commercial qui comporte 12 commerciaux. Il existe en France
8 autres secteurs. Les 9 secteurs sont répartis sur 4 régions. Les secteurs et les régions sont sous la
responsabilité respective des chefs de secteurs et des directeurs de région. La direction des ventes de la
filiale est sous la responsabilité du directeur commercial France. Le groupe a une direction commer-
ciale Europe, une direction Asie et une direction Amérique. Les chefs de secteur auront besoin des infor-
mations, pour chacun des commerciaux, sous leur responsabilité. Le directeur de région aura besoin
des résultats de chaque secteur sous sa responsabilité et le directeur commercial les résultats de
chaque région. Cependant, afin de permettre la gestion par exception, il devra être possible au
directeur des ventes France d’accéder aux informations relatives aux secteurs d’une région donnée, au
cas où les résultats observés s’écarteraient de manière significative des objectifs qui lui ont été
assignés. Le directeur de région aura besoin d’accéder, par exception, à l’analyse par commercial, au
sein d’un secteur, et ainsi de suite.

Le système des tableaux de bord devra donc permettre de pratiquer l’effet zoom et offrir une
fonction d’accès au détail, condition de la mise en place de la gestion par exception.
b) qu’elle soit conforme au point de vue du destinataire
À niveau hiérarchique équivalent, différents destinataires de l’information décisionnelle
auront des points de vue différents sur une même réalité.

EXEMPLE
Le directeur des ventes, le directeur marketing et le directeur de la trésorerie auront des points de vue
différents sur la relation avec les clients.
Le directeur des ventes cherche à gérer son équipe de force de ventes et recherche des informations par
commercial ou secteur géographique.
Le directeur du marketing, qui est responsable de la gestion de la gamme des produits pour satisfaire
les besoins des clientèles cibles, préférera des informations croisées par segments de clientèles et par
gammes de produits.
Le directeur de la trésorerie sera soucieux de connaître la durée de crédit réelle accordée aux clients par
rapport à la durée théorique prévue.

Le système de tableaux de bord devra respecter les angles de vue, afin de croiser les dimen-
sions pertinentes pour chacun, même si la source est la même donnée de base.
La construction des outils appartenant au système interactif d’aide à la décision devra donc
respecter ces deux principes afin de donner aux décideurs des informations conformes à
leurs attentes.
2.2 Structures des données d’un SIAD
(Système d’Information d’Aide à la Décision)
Un SIAD s’appuie sur une base de données décisionnelles issue essentiellement des bases de
données opérationnelles. Il offre aux modules pilotes des outils d’aide à la décision qui doivent être
adaptés à chaque sujet destinataire, en termes de niveau de synthèse et d’angles de vue sur les
données.

114
CHAPITRE 2 – Structure du système d’information 1
PARTIE

Il faut tout d’abord rappeler que les informations des applications décisionnelles ont leur
source essentielle, et quasi unique, dans les données des bases opérationnelles.
Les bases de données décisionnelles vont donc être alimentées par des procédures automa-
tiques, à partir des données des bases décisionnelles.
Cette remarque est importante parce que de nombreux décideurs, dans les organisations de
toutes natures, n’ont pas conscience de ce phénomène.
Ils imaginent que les données des bases décisionnelles vont faire l’objet d’une saisie de
données. Ils ne perçoivent pas l’impact de la qualité des données opérationnelles et des
procédures de gestion mises en œuvre par les modules opérationnels sur les résultats qu’ils
pourront obtenir en matière d’outils d’aide à la décision.
Le SIAD est une auberge espagnole. La qualité des résultats que l’on pourra obtenir dépend de
celle des données que l’on aura introduites à l’origine, c’est-à-dire dans les flux opérationnels.
Dans les applications opérationnelles décrites précédemment, la structure des données est
essentiellement une structure à deux dimensions, bien représentée par la notion de table
dans les bases de données relationnelles. Les colonnes de ces tables représentent les champs
ou rubriques d’information, tandis que les lignes sont les enregistrements de la table. Cette
logique de structuration des données est bien adaptée aux objectifs des applications opéra-
tionnelles, qui sont la performance du traitement et la sécurité des informations.
Les informations de synthèse nécessaires pour les outils d’aide à la décision sont extraites à
partir des données des applications opérationnelles. Mais elles ne constituent pas une
simple copie des informations opérationnelles.
Plusieurs structures de données sont proposées pour les applications décisionnelles.
On parle d’infocentre, de datamart et de datawarehouse.
L’infocentre fait référence à une banque de données, partagée en réseau, où les données n’ont
pas été modifiées, sur le plan structurel, par rapport aux bases de données opérationnelles.
WEB Infocentre
On définit le datawarehouse (entrepôt de données) comme une collection de données
orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d’un
processus d’aide à la décision.
La notion de datawarehouse implique un certain nombre de transformations, par rapport
aux sources des données opérationnelles.

Opérations de transformations Objectifs


Nettoyage des données Dans les bases opérationnelles, certaines données ne
sont pas pertinentes pour l’analyse. Elles provoque-
raient des « bruits ».
Historisation automatique de certaines données Certaines données sont utilisées avec leur valeur instan-
tanée dans les bases opérationnelles. En analyse déci-
sionnelle, leur évolution de valeurs dans le temps
représentera un facteur explicatif.
Synthèse des données En analyse décisionnelle, il n’est pas toujours nécessaire
de stocker l’information élémentaire de base avec tout
son niveau de détail.

WEB Entrepôt de données

115
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Un datamart est un magasin de données spécialisé. Il concerne un sous-ensemble de


données particulier et homogène, par exemple les données commerciales clients. La mise en
œuvre d’un datawarehouse étant complexe, notamment lorsque les sources de données
sont hétérogènes, il est plus facile de construire un ensemble de datamarts.
Néanmoins, pour pouvoir disposer d’un véritable SIAD, la construction d’un dataware-
house est impérative.
Il faut se méfier de la tendance, dans les organisations, à baptiser datawarehosue des struc-
tures de données qui n’en sont pas car elles ne respectent aucune des règles qui le
définissent.

EXEMPLE
Une entreprise possède une application de paie et gestion des ressources humaines totalement
indépendante au sein de son système d’information. Elle utilise un moteur de base de données
différent des autres applications, fonctionnant avec la base Paradox. Son référentiel est différent de
celui des autres applications. Notamment, la codification des personnes n’est pas la même que dans
l’application de gestion de production. En conséquence, la DRH étant très demandeuse d’outils
d’aide à la décision, l’entreprise a décidé de construire un data mart RH pour l’usage des décideurs
de ce service. En conséquence de cette spécialisation, il sera impossible de croiser les données de la
production et de la paie. Seule la structure de type datawarehouse permet de croiser de manière
automatique les données émanant des différents processus de l’organisation.
WEB Datamart

2.3 Les concepts sur lesquels sont fondés les bases de données relationnelles
et décisionnelles
Les applications opérationnelles du système d’information de gestion s’appuient essentiel-
lement aujourd’hui sur les bases de données relationnelles.
Elles mettent en œuvre les concepts de l’OLTP On Line Tansactionnal Processing. Ce type
d’environnement de traitement de l’information suppose :
– une réponse à l’utilisateur qui doit être donnée dans un temps acceptable, c’est-à-dire
inférieur à 2 secondes ;
– en s’appuyant sur une structure de données qui garantit la non-redondance et la
cohérence des informations (particulièrement adapté à l’informatique des applications
opérationnelles). WEB OLTP

Les applications décisionnelles s’appuient sur une structure de données qui obéit à
d’autres règles.
L’OLAP On Line Analytical Processing caractérise l’architecture nécessaire à la mise en
place d’un système d’information décisionnel, offrant une structure multidimensionnelle
des données et nécessitant des calculs intermédiaires, dont les résultats sont enregistrés dans
les données c’est-à-dire figés. On accepte la redondance directe (duplication d’une infor-
mation dans plusieurs endroits de la base) ou indirecte (stockage de résultats de calculs),
pour des raisons de performance et de disponibilités de résultats. WEB OLAP

Des transformations sont à opérer pour passer des bases de données opérationnelles aux
bases de données décisionnelles.

116
CHAPITRE 2 – Structure du système d’information 1
PARTIE

2.4 Explications sommaires pour savoir lire les modèles de données ci-dessous
Afin de comprendre les développements concernant l’historisation des données et les
conséquences de ce mécanisme sur la nécessité de posséder un entrepôt de données, à côté
des bases de données opérationnelles, il nous faut recourir à un outil de modélisation des
données.
La représentation des structures de base de données présentées dans l’exemple ci-après
correspond à ce que l’on appelle le Modèle Conceptuel des Données (MCD), dans la
méthode de modélisation MERISE. Cette méthode appartient à la génération de modélisa-
tions fondées sur les notions d’entité et d’association.
Le modèle qui sert d’illustration à ces quelques explications est celui de la gestion de la
vidéothèque d’un particulier.
On y trouve des films, classés par genres et par réalisateurs. On y a également recensé les
acteurs principaux. Ainsi l’utilisateur peut choisir un film policier, un film réalisé par Jean-
Pierre Mocky, un film dans lequel Jean-Paul Belmondo joue un rôle.
■ Formalisme du MCD
On construit le modèle en utilisant le formalisme suivant :

Le rectangle représente le type d’objets ENTITE.


Dans le cartouche, en haut de l’objet, figure le nom de l’entité.
Dans le cadre en dessous figure la liste des propriétés de l’objet en matérialisant la propriété
identifiante.

EXEMPLE
L’entité FILM.
Possédant les propriétés :
– numéro du film, qui en constitue l’identifiant, c’est-à-dire la propriété qui permettra de le retrouver
dans la vidéothèque ;
– titre du film, date d’achat, type de support, qui constituent les informations que l’on possède sur le
film.

Le cercle permet de représenter une association non porteuse de propriété.

117
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Il s’agit :
– d’une Contrainte d’Intégrité Fonctionnelle (CIF) ;
ou
– d’une Dépendance Fonctionnelle (DF).

L’ellipse permet de représenter une association de type Contrainte d’Intégrité Multiple. La


partie supérieure permet de nommer l’association. On la nomme soit par un verbe OU, si
l’objet ainsi défini porte un nom dans le système modélisé, par son nom.
Les cardinalités, représentant la nature des liens entre les objets du modèle :
On détermine les cardinalités en posant les questions suivantes :
– dans le cas des CIF ou DF, associations non porteuses de propriétés qui relient deux objets :
à un exemplaire d’un objet combien correspond au moins et au plus d’exemplaires de
l’objet lié.
Suivant les règles de gestion en vigueur :
•la cardinalité minimale est 0, 1 ou exactement un nombre précis,
•la cardinalité maximale est pour un des deux objets, 1 ou un nombre précis, et pour
l’autre n, ou un nombre précis.
Il existe une CIF entre le FILM et le GENRE.
Nous pouvons dire qu’un film, appartient à un genre et un seul. Il fait partie des films
policiers ou des comédies, etc. Nous pouvons dire que pour un genre donné, il y aura au
moins un film dans la vidéothèque, mais en principe on en trouvera plusieurs, un nombre
indéterminé représenté par n.
– dans le cas des CIM (Contrainte d’Intégrité Multiple), associations porteuses de
propriétés, qui relient deux ou plusieurs objets grâce à l’association : pour chacun des
objets liés par l’association, pour un exemplaire d’un des objets, combien obtiendra-t-on,
au moins et au plus, d’exemplaires de l’association.
Suivant les règles de gestion du système modélisé :
•la cardinalité minimale est 0 ou 1,
•la cardinalité maximale est n.

EXEMPLE
En ce qui concerne l’association ROLE qui associe FILM et ACTEUR :
– nous dirons qu’à un acteur peut correspondre de 1 à n RÔLES dans différents films ;
– et qu’à un film, peut correspondre de 0 à n ACTEURS, recensés dans la base.

118
CHAPITRE 2 – Structure du système d’information 1
PARTIE

Genre Réalisateur Acteur

Code genre Code rélisateur Code acteur


Libellé genre Nom réalisateur Nom acteur
Prénom réalisateur Prénom acteur

1.n 1.n
1.n

CIF

CIF
1.1
Joue

Réalisateur Joue

Code film
Titre
1.1 Date acquisition
Mode acquisition 1.n

Les associations de types DF (Dépendances Fonctionnelles) comme CIF (Contraintes


d’Intégrité Fonctionnelles) ne peuvent être porteuses de propriétés.
On utilisera la notion de DF lorsque la valeur du lien entre les objets pourra être modifiée
dans le temps.
On utilisera la notion de CIF lorsqu’au contraire cette valeur sera immuable.

EXEMPLE
Un salarié appartient à une catégorie de personnel, mais il peut en changer. Il est employé et devient
cadre. Il y aura donc une DF entre catégorie de personnel et salarié.
A contrario, une facture est liée à un client et un seul et cela n’est pas susceptible de modification
avec le temps.

Ayant posé les bases de la modélisation, nous pouvons maintenant présenter la situation qui
résulte de l’utilisation des DF dans le modèle de la base de données opérationnelle.

119
1 CHAPITRE 2 – Structure du système d’information
PARTIE

2.5 Les opérations de transformation


nécessaires à la construction de l’entrepôt de données
a) L’historisation automatique de certaines données

EXEMPLE

FACTURE

N° de facture 1,1
1,n Date de facture
LIGNE DE FACTURE
CIF
quantité facturée 1,n
Prix unitaire facturé
1,n Client
Code client
Produit Nom
1,1
Code produit Rue 1
Libellé produit rue 2 1,1
Prix actuel
1,1 DF
1,1 1,1 DF

0,n
CIF CIF 1,n
CIF
1,n Ville
1,n 1,n
Code pays
Format Grammage Catégorie + Code postal
Couleur
Code format Code catégorie Bureau
Code couleur Code grammage
Libellé format Libellé catégorie distributeur
Libellé couleur Libellé grammage
1,1

B
0,n
Pays
Code pays
Pays

Modèle de données simplifié de la facturation dans une base opérationnelle.


Il s’agit d’une entreprise qui fabrique et distribue des ramettes de papier.
La catégorie d’un client est unique à un instant donné. Par contre la relation qui existe entre le client
est la catégorie est de type DF, dépendance fonctionnelle. Cela signifie que la valeur du lien peut
changer dans la durée. Autrement, dit le client n’a qu’une seule catégorie à la fois, mais il peut en
changer dans le temps.
Il serait inutile d’alourdir le modèle de l’application opérationnelle, en historisant la catégorie, ce qui
en diminuerait la performance. En effet, l’utilisation de cette codification est utilisée uniquement
pour connaître le taux de remise à pratiquer par rapport au tarif général des produits.

120
CHAPITRE 2 – Structure du système d’information 1
PARTIE

FACTURE

N° de facture 1,1
1,n Date de facture
LIGNE DE FACTURE
CIF
quantité facturée 1,n
Prix unitaire facturé
1,n Client
Code client
Produit Nom
Code produit Rue 1
Libellé produit CIF date fin rue 2 1,1
Prix actuel
0,n 1,n
1,1
1,1 1,1 DF
Date 0,n Historique catégorie 0,n
CIF CIF CIF date

1,n date début Ville


1,n 1,n
Code pays
Format Couleur Grammage + Code postal
Code format 1,n Bureau
Code couleur Code grammage
Libellé format distributeur
Libellé couleur Libellé grammage

Catégorie 1,1
Code catégorie
Libellé catégorie
B
0,n
Pays
Code pays
Pays

Le modèle de la base de données décisionnelle sera transformé de cette manière pour obtenir une date
de début et une date de fin de l’appartenance d’un client à une catégorie. Cela réalisera l’histori-
sation de cette donnée. On pourra ainsi transformer la notion d’appartenance à une catégorie en une
dimension explicative du comportement des clients.

Certaines données dont la valeur se modifie au cours du temps n’ont pas besoin d’être
historisées dans les bases de données utilisées par les applications opérationnelles. On a
uniquement besoin, à ce niveau, de la dernière valeur connue. En décisionnel, il en ira tout
autrement.

EXEMPLE
Il suffit, dans une application de gestion commerciale, de connaître l’appartenance actuelle d’un
magasin à une enseigne pour éviter les erreurs de référencement de produit ou les erreurs de tarifi-
cation. Par contre, pour l’analyse de la relation commerciale avec le magasin, il sera utile d’historiser
son appartenance successive à plusieurs enseignes, afin de voir l’incidence sur la relation commerciale
du changement d’enseigne. Un hypermarché a changé quatre fois d’enseigne en une quinzaine
d’années. Il a appartenu successivement à l’enseigne Mammouth (Docks de France), puis est passé
sous l’enseigne Carrefour, pour ensuite redevenir un hypermarché Mammouth et enfin, appartenir à
l’enseigne Auchan. Un fabricant de produits alimentaires, qui fabrique des articles à sa marque et aux
différentes marques des distributeurs, pour pouvoir analyser efficacement ses données commerciales,
aura besoin d’historiser les appartenances aux enseignes. En effet, comment expliquer qu’un magasin
Auchan a été livré en produits Carrefour à une certaine période ? Comment expliquer un référencement
plus large à certaines périodes, si ce n’est par la politique de l’enseigne ? Cette appartenance est un
facteur explicatif essentiel du comportement d’achat. Ne pas l’historiser ferait perdre toute lisibilité à
l’analyse sur la durée.

121
1 CHAPITRE 2 – Structure du système d’information
PARTIE

b) Mettre en place le nettoyage des données


Certaines données ne sont pas pertinentes pour l’analyse et pourraient occasionner des
bruits.

EXEMPLE
Il arrive fréquemment, dans une application qui sert à la facturation des clients, de voir apparaître des
éléments importuns, liés à des litiges par exemple, qui ont entraîné des facturations à des tiers, ou des
cessions d’emballages perdus ou autres opérations marginales de ce type. Ces factures n’entrent pas
dans le chiffre d’affaires généré par les clients, mais constituent des créances sur des débiteurs divers.
Il est commode de « détourner » le logiciel, pour réaliser ces types de factures, dans le cadre de l’appli-
cation opérationnelle. Mais, si ces informations sont retranscrites comme telles dans la base de
données décisionnelle, elles vont perturber l’analyse.

Il faut ajouter qu’il subsiste actuellement bon nombre d’applications opérationnelles, qui
ne respectent pas l’intégrité et la cohérence des données, ce qui entraîne des erreurs
d’analyse dans la base décisionnelle. Un traitement de remise en cohérence des données sera
donc nécessaire, dans le cadre du nettoyage des données.

EXEMPLE
Dans une application opérationnelle, il était possible, lorsqu’on ne travaillait plus avec un client ou
un fournisseur, de réattribuer son code à un autre tiers au début de l’exercice suivant. Dans l’appli-
cation opérationnelle, cela n’entraînait pas de conséquences trop fâcheuses dans la mesure où il n’y
avait pas de lien direct entre le code du tiers dans la gestion commerciale ou les achats, d’une part,
et le compte d’imputation des créances et dettes dans l’application comptable, de l’autre. Par contre,
c’était un problème à résoudre lors du basculement des données dans l’application décisionnelle.

EXEMPLE
Une application de gestion commerciale ne contrôlait pas l’intégrité référentielle entre la codifi-
cation des catégories de clients, la codification de leur appartenance à une zone géographique et le
contenu du dossier client. Il était possible de saisir dans la fiche du client des valeurs absentes de la
codification de ces paramètres dans la base de données. Ce défaut d’intégrité des données n’était pas
bloquant dans l’application opérationnelle. Certes, cela interdisait des contrôles automatiques de
cohérences dans les procédures, mais l’application ne les prévoyant pas, cela ne changeait pas grand-
chose. Par contre, il était impossible de garder cette situation dans la base décisionnelle, car les
dimensions d’analyse que représentent ces codes devenaient de ce fait inutilisables.
Pour s’en persuader, imaginons que nous cherchions les clients de la zone Nord, codifiée « NO » dans
le paramétrage des zones. S’il n’y a pas de contrôle d’intégrité référentielle dans l’application, on
peut imaginer que des clients appartenant à cette zone géographique n’ont pas ce code dans leur
fiche. Soit il n’ont pas de code zone géographique du tout, soit ils ont un code erroné, par exemple
« ON », parce que la frappe du code a été inversée par inadvertance. On ne pourrait pas faire des statis-
tiques fiables, sachant que les codes ne sont pas justes. Le contrôle d’intégrité référentielle, ne nous
garantira pas que la donnée soit juste. Il sera toujours possible d’affecter le code « NO », pour région
Nord, à un client de Marseille. Mais ce contrôle nous garantira que l’information est vraisemblable.

Lorsque les applications opérationnelles présentent des défauts de cohérence ou de contrôle


d’intégrité des données, il faut ajouter des procédures de nettoyage permettant de traiter le
problème à l’intégration des données dans la base décisionnelle.

122
CHAPITRE 2 – Structure du système d’information 1
PARTIE

c) Opérations de synthèse des données


La définition d’agrégats peut permettre d’améliorer les performances des applications
décisionnelles, sans pour autant interdire au décideur d’accéder au niveau de finesse
d’analyse requis (granularité). Tout agrégat de données élémentaires fera perdre une
certaine quantité d’informations, mais si cela ne nuit pas à l’analyse, cela permettra
d’augmenter la performance. Il faut donc mettre en balance les deux critères pour définir les
agrégats pertinents et mettre en place les procédures de synthèse de données requises, à
l’intégration dans la base décisionnelle.

EXEMPLE
Les données de base de l’analyse commerciale sont issues des lignes des factures qui ont été établies
dans l’application opérationnelle de gestion commerciale.
Les lignes de factures correspondent à ce que l’on appelle une table de faits, qui comporte les données
numériques mesurant l’activité (l’intensité des flux) et fait le lien entre les objets du système. Dans le
cas des lignes de factures, on trouvera la quantité et le prix facturé à un client et pour un produit. Les
dimensions d’analyse structurelles de ces données numériques seront donc constituées par les
produits et les clients. Ces objets pivots du système seront eux-mêmes classifiés, suivant des dimen-
sions codifiées, comme les familles de produits et les enseignes des clients.
La table des lignes de factures de la base de données opérationnelle comporte un enregistrement pour
chacune des lignes présentes sur les factures et les avoirs.
Un fabricant établit une facture par jour ouvrable pour chacun des 150 magasins d’une enseigne. Sur
chaque facture on trouve une ligne par produit référencé par l’enseigne, soit 10 lignes en moyenne par
facture. En terme de volume, sachant que les magasins sont livrés donc facturés 6 jours par semaine,
on a environ 9 000 lignes de factures par semaine pour cette enseigne et 36 000 lignes par mois.
Sachant que les analyses souhaitées par la direction commerciale ne descendent jamais en dessous
d’une périodicité mensuelle, on peut envisager un agrégat sur le croisement produit/client qui
totalise les opérations du mois. Cela permettrait de remplacer, pour un mois, 36 000 lignes de factures
par 1 500 lignes de l’agrégat. Certes cela interdira certaines analyses. Par exemple, il sera impossible
de savoir s’il y a une tendance à des fluctuations liées aux jours de la semaine. Est-ce que les factures
sont plus élevées le jeudi que le mardi ? Mais les analyses décisionnelles nécessitant la compilation
d’informations sur une longue période, le gain de performance lié à la division par un facteur supérieur
à 20 du nombre d’enregistrements à lire dans la base de données représentera un avantage décisif.

2.6 Utilisation d’un ETL pour effectuer les transformations


L’outil d’extraction des informations pour construire l’entrepôt de données à partir des
données opérationnelles s’appelle un ETL (Extract Transform Load).
L’extraction est facilitée dans le cadre des bases de données relationnelles, notamment
lorsqu’elles sont homogènes pour les différentes applications opérationnelles. On possède
un modèle de la base représentant les relations entre les tables et un langage de requête
permettant d’extraire des informations issues de plusieurs tables et conformes à certains
critères de sélections. En règle général, les applications qui utilisent ces structures de
données s’efforcent d’en maintenir l’intégrité, dans la mesure où cette tâche peut être
dévolue au moteur de la base de données. Il est donc possible, grâce à des requêtes,
d’alimenter une base de données décisionnelle qui respectera de nouveaux critères propres
à ses objectifs.

123
1 CHAPITRE 2 – Structure du système d’information
PARTIE

LES TROIS FONCTIONS D’UN ETL

Fonctions Objectifs
Extract Extraction paramétrée des données à partir de différentes sources de
données, éventuellement hétérogènes.
Transform Algorithme de transformation permettant de filtrer ou de modifier les
données sources préalablement à leur intégration dans la base déci-
sionnelle.
Load Chargement des données transformées dans l’entrepôt de données.

a) La phase Extract
Elle permet d’extraire automatiquement des données contenues dans les tables d’une base
de données, dont le moteur est connu. L’extraction peut être sélective sur les deux dimen-
sions de la table. Cela signifie que l’on peut décider, par paramétrage de cette fonction, de
n’extraire que certains champs de la table source. Mais on peut également décider, éventuel-
lement en prévoyant un questionnement de l’utilisateur à l’exécution, que seuls certains
enregistrements (ou lignes de la table) seront extraits.

EXEMPLE
Lorsqu’on veut extraire les données des clients, dans la base décisionnelle on n’a pas besoin de
l’adresse complète, du numéro de téléphone ou de fax. Ces données signalétiques n’auront aucun
intérêt en analyse décisionnelle. On extraira donc uniquement les champs utiles, afin de limiter le
volume de la base qui doit inclure des informations sur une longue durée pour effectuer les compa-
raisons et les analyses d’évolution.

EXEMPLE
Lorsqu’il faudra extraire, à la fin de chaque mois, les lignes de factures de la période, on demandera à
l’utilisateur la période d’intégration qui l’intéresse. Seules les lignes de factures de cette période
seront extraites, cela permettra de limiter le traitement d’intégration des données.

b) La phase Transform
Elle permet d’appliquer une procédure de transformation des données pour les rendre
conformes aux besoins de la base de données décisionnelle.

EXEMPLE
Une procédure de transformation sera nécessaire pour synthétiser les données des lignes de facture et
obtenir un seul enregistrement par mois pour le couple produit/client.
Une procédure sera utilisée pour historiser les données qui ne le sont pas dans la base source.

c) La phase Load
Elle permet de créer les enregistrements dans les tables de la base de données décisionnelle.
Elle doit fournir un état des anomalies permettant de détecter les données qui n’ont pas pu
être intégrées. WEB ETL

124
CHAPITRE 2 – Structure du système d’information 1
PARTIE

2.7 Les types de résultats que l’on peut obtenir des applications décisionnelles

LES DIFFÉRENTS TYPES DE RÉSULTATS

Types Utilisations

Rapports Mise en place d’un système de tableaux de bord, produits de manière


périodique et récurrente.

Hypercubes Constitution d’une structure de tableaux croisés multidimensionnelle,


correspondant aux points de vue des décideurs, permettant l’interro-
gation libre des données.

Data Mining Modélisations exploratoires des données, s’appuyant sur différents


algorithmes du domaine probabiliste ou de la gestion de l’incertain.

a) Le reporting
La principale utilisation des bases de données décisionnelles consiste à définir et mettre en
place un système d’outils de « reporting ».
La caractéristique essentielle de ce type d’outils est la répétitivité et la régularité de leur
production.

LES TYPES DE RÉSULTATS FOURNIS

Types de résultats Objectifs

Des tableaux Résultat en colonnes de l’exécution d’une requête, pouvant inclure :


– des ruptures avec totaux ;
– des filtres.

Des tableaux transposés Résultat d’une requête de synthèse dont les colonnes et les lignes sont
inversées pour des raisons de clarté de la présentation. Par exemple,
une requête donnant en résultat le CA total, les charges totales et le
résultat total de la période, apparaîtra dans un premier temps comme
possédant une ligne et trois colonnes. La transposition permettra
d’avoir un tableau de trois lignes et une seule colonne. Cette nouvelle
présentation sera plus facile à lire.

Des tableaux croisés La présentation d’analyses multidimensionnelles sera facilitée par les
tableaux croisés. On aura la possibilité de croiser :
– plusieurs dimensions imbriquées en lignes et en colonnes ;
– d’obtenir plusieurs données, présentées sous différentes formes
(valeurs absolues, pourcentages) dans les cases à l’intersection des
lignes et des colonnes élémentaires.

Des graphiques Plusieurs types de graphiques sont disponibles :


– différents histogrammes ;
– graphiques en secteurs ;
– courbes.
Le style du graphique doit être adapté aux données à représenter, de
manière à être pertinent par rapport aux données à représenter et
facilement interprétable.

125
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Le principe du reporting consiste à exécuter la requête à chaque fois que l’on demande un
rapport. Pour des raisons de performance, il est possible de désactiver cette option de base.
Cependant, ce principe permet dans ce type d’outils d’avoir une information à jour en
permanence. WEB Reporting

b) Les hypercubes
La constitution d’une structure multidimensionnelle de type hypercube OLAP correspond
au point de vue du sujet destinataire Pour des raisons de performances dans l’exécution des
requêtes à finalité décisionnelle, on est amené à créer des agrégats de données, soit sur
l’horizon temporel, soit sur des dimensions d’analyse des données, afin de regrouper
l’information. Cela permettra de disposer d’une information suffisamment synthétique
pour percevoir les caractéristiques essentielles du phénomène.
Pour simplifier la représentation mentale de ce qu’est un hypercube, on peut l’assimiler à
un tableau croisé dynamique dans un tableur. La différence réside dans le volume de
données qui peut être manipulé et dans la nature de leur stockage.
Pour accélérer l’accès aux données on a recours à différentes techniques dont :
– l’index binaire, qui correspond pour toutes les variables statistiques utilisables à créer un
tableau disjonctif complet, sur toutes les modalités, et à l’indexer ;
– l’enregistrement par colonnes ou stockage vertical, où on enregistre non pas une ligne
correspondant à toutes les variables d’un individu, mais une colonne correspondant à
toutes les réponses concernant une variable.
La structure en hypercube permet :
– une modélisation des données qui est intuitive puisque chaque dimension correspond à
une variable pertinente ;
– un accès aux données facile et direct, puisque toutes les données sont dans un même
tableau.
Pour utiliser un hypercube, plusieurs étapes seront nécessaires :
– définition des dimensions à croiser, à partir de la description logique des données ;
– génération des modalités existantes sur les différentes dimensions, pour préparer les cases
de l’hypercube ;
– calcul des métriques de chaque case ;
– enregistrement de l’hypercube.
Contrairement au cas du « reporting », lorsqu’on utilise un hypercube, l’information n’est
pas remise à jour à chaque fois. WEB Hypercube OLAP

c) Le data mining
À partir des volumes importants de données, contenues dans la base de données décision-
nelle, les approches du data mining vont permettre de définir des modèles pour leur donner
du sens et aider à la prise de décision.
Le data mining va consister à explorer les données à travers différents types d’outils, tels que
les modèles statistiques, probabilistes, modèles d’analyse multidimensionnelle, modèles de
réseaux neuronaux, etc. WEB Datamining

126
CHAPITRE 2 – Structure du système d’information 1
PARTIE

2.8 Les outils de la Business Intelligence


Les outils du marché respectent les règles définies par l’OLAP. Pour cela, ces outils offrent
des visions métiers de données qui s’appuient sur la structure de la base de données mais
échappent à ses contraintes techniques.
On aboutit à la définition d’une Forme Normale Décisionnelle (FDN) différentes des
formes normales relationnelles. La forme normale décisionnelle est caractérisée par :
■ la non-existence de hiérarchie cyclique dans le domaine
Cela signifie qu’il ne peut y avoir de boucles dans les dépendances entre données.
Le schéma ci-dessous montre que, si deux associations existent entre les mêmes objets, cela
entraîne la création de circuits. Pour résoudre ce problème, dans les applications décision-
nelles, on utilisera la notion d’alias ou de contextes, afin de créer des copies virtuelles des
objets qui sont impliqués dans plusieurs associations (utilisation des alias) ou d’isoler des
sous-chemins dans le schéma (utilisation des contextes).
■ l’existence, au sein d’un dossier, d’une seule association les données numériques
Pour simplifier la navigation dans un dossier qui représente un point de vue métier sur les
données, on préférera recourir à une seule association porteuse de propriétés, qui contient
les faits du contexte, c’est-à-dire les données numériques. Cette association comporte
toutes les données quantitatives sur lesquelles l’analyse va porter dans ce domaine métier.

EXEMPLE
Dans le schéma ci-dessous, les lignes de facture correspondent à l’activité du domaine. L’objet
« factures » intègre les données numériques ou métriques, par exemple la quantité facturée et le prix
unitaire de facturation. L’objet est relié aux objets pivots du domaine (clients et produits), qui sont eux-
mêmes liés aux dimensions structurelles d’analyse (catégorie de clients et familles de produits).
À partir du moment où l’on introduit un deuxième objet contenant des données numériques, comme
les commandes, on doit, soit créer des alias, soit des contextes pour éviter les circuits.

Catégories familles
de clients de produits
2 7
3 6

Clients Produits

4
5

Commandes
1 8

Liens entre les objets de la base Factures

Circulation dans la base pour la requête

127
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Sur le schéma ci-dessus, représentant une structure de base de données décisionnelle, on


veut réaliser des requêtes entre les différents objets, sachant que les liens entre eux, peuvent
être parcourus dans les deux sens.

EXEMPLE
Nous voulons connaître le chiffre d’affaires facturé (à partir de l’objet factures) concernant les
produits vendus aux clients, ceux-ci étant classés respectivement par familles et par catégories. Par
exemple, quel est le chiffre d’affaires réalisé avec la grande distribution concernant les produits de la
famille ramettes de papier A4, couleur.
Les dimensions d’analyse des clients et des produits sont reliées dans ce modèle par deux tables de
fait (contenant les données numériques), Commandes et Factures. Les liens entre les objets peuvent
être parcourus dans les deux sens. Cela entraîne la création d’un circuit (ou boucle) et notre requête
va tourner en rond indéfiniment. Le circuit se fera de Factures à Clients et Catégories, on passe par
Commande et Produits et familles et on repart vers Factures, et ainsi de suite.

Catégories Alias catégories Familles Alias familles


de clients clients de produits de produits
C 4
2
D
B
3
Clients Produits
Alias clients
Alias
produits
A

Commandes
1

Circuit Factures
Factures
Circuits Commandes

Liens dans la base

Pour éviter le problème relatif aux boucles infinies, le modèle de la base décisionnelle
prendra en compte des alias ou des contextes qui ne sont pas des copies physiques des
données mais des doubles virtuels. Leur incidence ne se fera sentir que sur les circuits. Ainsi,
quand on fera des requêtes concernant les factures, on utilisera les objets clients, catégories
de clients, produits et familles de produits. Dans les requêtes concernant les commandes, on
utilisera leurs alias. On peut faire le même raisonnement avec la notion de contexte : un
contexte Commandes et un contexte Factures, qui séparera les deux plans.
Certaines bases de données telle qu’Oracle ou SQL Server propose des moteurs OLAP.

128
CHAPITRE 2 – Structure du système d’information 1
PARTIE

Des produits du marché tels que Business Objects, Cognos, ou SAS sont spécialisés vers la
production d’outils d’aide à la décision. WEB Business Objects • Cognos • outils décisionnels

Des sociétés comme Sunopsis sont spécialisées dans la fourniture d’ETL. Cette société a été
rachetée par Oracle en 2006. WEB Sunopsis – http://www.oracle.com/sunopsis/index.html

Ces outils proposent les trois catégories de résultats :


– des outils de « reporting » périodiques qui, à partir d’un catalogue des données ou d’un
univers lié directement à la base de données décisionnelle, permettent de concevoir et
d’exécuter des requêtes qui généreront des états possédant différents niveaux de regrou-
pements et de tris ;
– des outils d’hypercubes permettant de croiser des données multidimensionnelles, à partir
de données précalculées et stockées ;
– des outils d’exploration des données complexes, de type data mining.
La diffusion des résultats utilise de plus en plus les navigateurs WEB. L’intérêt de ce mode
de diffusion est le caractère universel et uniforme de la présentation et de la navigation et la
rapidité de mise à disposition des résultats par rapport à la forme papier.
2.9 Démarche pour construire un SIAD au sein de l’organisation
De nombreuses organisations sont déçues de l’efficience de leurs applications décision-
nelles.
De manière générale, les décideurs ont l’impression que « la montagne a accouché de la
souris ». En effet, ce sont des outils très coûteux et le résultat obtenu n’est souvent pas à la
mesure de l’investissement.
Les raisons de ces échecs sont assez constantes. On peut donc les analyser et essayer d’y
remédier.
Les deux explications de base de ce problème sont les suivantes :
– absence de réflexion sur les besoins. Le problème est posé uniquement en termes de choix
d’outils à acquérir,
– construction des outils d’aide à la décision sur les bases opérationnelles. Devant le
caractère ingrat de la construction d’un datawarehouse, on renonce à s’engager dans cette
démarche.
Pour éviter ces déboires, il faut mettre en place une démarche de réflexion et de
construction.
Celle-ci part d’une réflexion des décideurs concernant les indicateurs pertinents pour
mesurer leurs performances et disposer de signaux d’alertes par rapport à leurs différents
objectifs. Ils peuvent ainsi définir les tableaux de bord et dimensions d’analyse qui leur
seraient utiles et exprimer leurs besoins. (Voir figure ci-contre.)
La tentation est grande de ne pas accorder suffisamment d’importance à la réflexion
préalable. On part souvent du principe que les décideurs connaissent a priori les indicateurs
dont ils ont besoin et qui sont pertinents pour leur domaine de responsabilité. L’expérience
prouve qu’il n’en est rien. Pour cartographier les processus, on utilisera le diagramme
Ishikawa, permettant de définir les objectifs et les sous-objectifs visés.

129
1 CHAPITRE 2 – Structure du système d’information
PARTIE

MÉTHODE POUR CRÉER UN SYSTÈME DE TABLEAUX DE BORDS ADAPTÉS AUX BESOINS DE L’ORGANISATION

Diffuser
Cartographier les rapports
les processus aux destinataires

Ajouter
Définir les indicateurs demandés
les indicateurs par les acteurs
externes Structurer
pertinents les rapports
(tableaux de bord)

Construire
l'entrepôt
de données

EXEMPLE
Le diagramme Ishikawa ci-après permet à la direction informatique de définir les objectifs de son
action et de les faire valider en comité de direction.
À partir de ce diagramme, le responsable va définir pour chaque branche au minimum un indicateur
de performance et un indicateur d’alerte. Le résultat de cette démarche constituera le cahier des
charges pour la structuration de l’application décisionnelle. (Voir figure ci-après)
Indicateurs de performance et de non-qualité proposés pour cette branche
Performance :
– amplitude du service.
– nombre de connexions.
– durée depuis le dernier redémarrage d’un serveur.
– nombre d’interventions auprès des utilisateurs par natures d’intervention.
Non-qualité :
– nombre de pannes réseau sur une période.
– délai de remise en fonctionnement.
– nombre d’arrêts serveurs.
Rappelons qu’un bon indicateur doit être :
– objectif : il ne doit pas être susceptible d’interprétations différentes suivant les sujets qui l’analyse ;
– automatisable : il faut pouvoir calculer sa valeur périodiquement sans intervention manuelle.

130
CHAPITRE 2 – Structure du système d’information 1
PARTIE

Sécurité de Qualité du taux Sur les Assistance


l'information de service aspects aux utilisateurs
techniques
Mise en place Temps
de pare-feu Fiabilité des d’ouverture
Cryptage Plan de serveurs Sur les aspects
des données sauvegarde métiers
sensibles
Fiabilité Stabilité Qualité du réseau
Cryptage Stabilité
des serveurs des OS
des données diffusées
à l'extérieur Fiabilité Sécurité
Application des BD Rapidité
d’antivirus
à jour

Mettre à disposition
l'information
Groupe de manière qualitative
Data Respect groupware Complétude
ETL
Nature Warehouse du facteur Évolution homothétique de la collecte
des outils de zoom à celle de l'organisation
Orientation
Hypercube processus
Reporting Data Orientation
Respect sujet
Mining de l'angle Rapidité Fiabilité
Gestion de la collecte de la collecte
de vue workflow

Qualité des applications Qualité des applications Qualité de la collecte


décisionnelles opérationnelles des données

Qualité du taux
de service

Assistance
Sur les aspects aux utilisateurs
techniques
Temps
d’ouverture

Fiabilité des Sur les aspects


serveurs métiers

Fiabilité des
OS Stabilité Qualité du réseau
Stabilité
des serveurs
Fiabilité des BD
Sécurité
Rapidité

131
1 CHAPITRE 2 – Structure du système d’information
PARTIE

Cela permettra aux informaticiens de structurer le datawarehouse et de construire les outils


fournissant les indicateurs.
Par rapport à ces objectifs, la problématique de l’outil du marché à mettre en œuvre est
secondaire dans la mesure où ils fournissent tous, plus ou moins, les mêmes possibilités.

Base
de données Outils
relationnelle 1 de « Reporting »

Datawarehouse
entrepôt
de données
ETL Base de données Hypercubes
Base décisionnelle
de données unique
relationnelle 2

Datamining

Base
de données
relationnelle 3

Utilisateurs : les modules Traitement périodique Utilisateurs :


opérationnels, qui collectent les modules pilotes
les données

Par contre, quel que soit l’outil, si la démarche précédente n’est pas menée correctement, le
résultat sera mauvais.

EXEMPLE
Dans une grande entreprise de services, le contrôleur de gestion souhaitait obtenir des indicateurs sur
la progression de son chiffre d’affaires par produits et le comparer aux charges de différentes natures
engagées.
Malgré l’utilisation d’un produit leader du marché en matière d’applications décisionnelles et le
temps passé par les informaticiens spécialisés sur l’élaboration des requêtes et rapports, il n’arrivait
pas à obtenir des résultats cohérents.
En fait, l’étude du problème a révélé que les requêtes étaient effectuées à partir de plusieurs bases de
données opérationnelles aux référentiels incohérents.
Les décideurs n’avaient jamais pris conscience de l’importance de la démarche aboutissant à la
création de l’entrepôt de données.

132
CHAPITRE 2 – Structure du système d’information 1
PARTIE

En conclusion, la qualité du système d’information implique que chaque élément du système joue
son rôle correctement.
Les modules opérationnels doivent être conscients de l’importance de leur rôle dans la collecte des
données. La qualité des données dépend d’eux et elle est fondamentale, aussi bien dans le cadre des
applications opérationnelles que décisionnelles.
Rappelons qu’une collecte de données de qualité repose sur trois critères :
– absence d’erreurs de collecte ;
– absence d’omissions ;
– pas de délai de transmission.
Le système d’information doit offrir tous les outils conformes aux besoins, c’est-à-dire à la nature
des activités et à la finalité de l’organisation.
Les décideurs doivent définir leurs objectifs et les indicateurs permettant de les mesurer.

133
APPLICATIONS

APPLICATION 4
L’entreprise Sauciflar fabrique et vend des produits de charcuterie. Elle souhaite se doter d’un système
d’information s’appuyant sur des outils adaptés aux problèmes de son secteur d’activité.

QUESTIONS
1. Décrire les modules applicatifs nécessaires à la prise en main des différents processus.
2. Présenter un schéma des processus concernés.
3. Définir les principales natures d’informations pertinentes, qui doivent être gérées dans le
système, avec leurs structures schématiques pour chacun des processus retenus.

APPLICATION 5
Une entreprise a sa structure commerciale structurée de la manière suivante :
– la force de vente en France est composée de cinquante commerciaux ;
– ils sont répartis en cinq secteurs géographiques, chacun sous la responsabilité d’un chef de secteur ;
– les secteurs sont regroupés en deux régions (région Nord avec trois secteurs et région Sud avec deux
secteurs) ;
– la direction commerciale France supervise les deux régions. Elle dépend de la direction Europe qui
regroupe dix filiales dans l’Union européenne.

QUESTION
Définir la structure du système de « reporting » à construire dans le système décisionnel, afin
d’offrir à chacun les informations dont il a besoin.

134
3
CHAPITRE
Structuration
des systèmes d’information
section 1 Position de la fonction informatique au sein de l’organisation
section 2 Stratégie informatique
section 3 Urbanisation des systèmes d’information
applications

section 1
position de la fonction informatique
au sein de l’organisation
On peut envisager cette question d’un double point de vue :
– quelles sont les structures dans l’organisation qui gèrent les problèmes relatifs à l’informatique ?
De ce point de vue, la taille de l’organisation aura un impact important sur la réponse, que l’on
pourra donner ;
– qui gère les problèmes relatifs au système d’information, dont on a vu dans les chapitres précé-
dents qu’il s’agissait d’une toute autre nature de problèmes ? De ce point de vue, la taille aura
encore une importance, mais l’histoire et le type d’organisation seront tout aussi déterminants.

1. Le cas des grandes organisations


Les grandes organisations, qu’elles soient privées ou publiques, présentent des caractéris-
tiques communes influant sur la structuration de leur système d’information.
1.1 L’existence d’un service informatique interne
Ces organisations possèdent un service informatique interne, chargé d’intervenir dans le
cadre des problèmes de toutes natures relatifs à l’informatique.
La question est d’en définir le périmètre de compétence et d’action.
a) La direction informatique interne
et le développement des applications informatiques
On a constaté ces dix dernières années une évolution dans la place des DI (directions infor-
matiques) et dans la perception que les directions générales en avaient.
Les directions générales des grandes organisations se sont mises à considérer des facteurs
décisifs pour choisir entre recourir à des développements de logiciels en interne ou acquérir
des progiciels sur le marché.

135
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

LES FACTEURS DE CHOIX ENTRE DÉVELOPPEMENT DE LOGICIELS ET ACHATS DE PROGICIELS

Facteurs Actions
Le coût de développements des applications Le fait de devoir amortir sur un seul exemplaire le coût du déve-
informatiques spécifiques, réalisés par leur loppement rend l’opération très onéreuse (rapport de 1 à 10 ou
service informatique de l’organisation. 20, entre le coût du développement d’un logiciel spécifique et
l’acquisition d’un progiciel sur le marché).
Le délai de réalisation prévu et atteint. Le délai de mise en œuvre est beaucoup plus long (3 à 5 fois)
pour un logiciel spécifiquement développé par rapport à la mise
en place d’un progiciel.
Le délai est plus aléatoire pour un logiciel spécifique compte
tenu des nombreuses dérives entre les délais prévus et les délais
réellement constatés.
La qualité fonctionnelle du résultat. En principe, le logiciel spécifique devrait couvrir la totalité des
besoins exprimés par la maîtrise d’ouvrage. A contrario, le progi-
ciel ne permettra pas de répondre exactement à l’expression des
besoins. Dans la réalité, les logiciels spécifiques ne cadrent pas
toujours exactement avec l’expression des besoins.

Le coût, évalué jours ou en mois/hommes, par les directions informatiques est apparu de
plus en plus prohibitif par les directions générales.
Le délai de réalisation prévu était souvent beaucoup trop long par rapport aux besoins de
mise en œuvre des décisions stratégiques et d’obtention des outils de pilotage.
La prise en compte des besoins des utilisateurs était souvent insuffisante.
Jusqu’aux milieu des années 1990, les directions générales des grandes organisations se sont
dons senties souvent otages de leur direction informatique et dans l’incapacité de satisfaire
les besoins d’information et d’outils informatiques que la gestion requérait.
Vers la fin des années 1990, la conjonction de plusieurs événements a permis aux directions
générales de grandes entreprises d’échapper au diktat de leur direction informatique.
D’un côté, il y a eu la nécessité de changer d’applications pour le passage à l’an 2000, puis à
l’euro. Cela concernait entre autres les domaines comptables et financiers.
Pour ces entreprises, cela impliquait de développer de nouvelles applications.
En effet, la plupart d’entre elles utilisaient à l’époque des applications écrites dans les
années 1970, puis migrées, de système en système, au fur et à mesure des évolutions de plate-
formes techniques. Dans les années 1970, le stockage des données sur support magnétique
était très coûteux, on utilisait donc des représentations des informations les plus condensées
possible. C’était notamment le cas des dates, qui étaient stockées avec des millésimes sur
deux caractères. Autrement dit 1991 était représenté par 91. Le passage à l’an 2000 provo-
quait un problème de cohérence et de classement des dates. 00 serait considéré comme 1900
et non 2000. Il était donc nécessaire de modifier les structures des données et les procédures
de traitements pour passer de ce type de représentation à des millésimes sur 4 caractères.
Autrement dit, une réécriture des applications était nécessaire.
Le passage à l’euro a exigé pendant un certain temps de posséder la double évaluation franc/
euro et des procédures de traitement permettant la conversion conformément aux règles

136
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

édictées, ce que les applications précédemment évoquées ne permettaient pas de faire non
plus.
D’un autre côté, c’est à ce moment que sont apparus sur le marché des progiciels standard
de nouvelle génération, pour l’époque, que l’on appelle les ERP. Part. 3, chap. 9
C’était l’occasion pour les directions générales de se libérer du joug de leur direction infor-
matique, notamment pour les applications standard ne présentant pas un caractère straté-
gique par rapport à leur cœur de métier. C’est le cas, en particulier, de la comptabilité et de
la finance.
C’était également une aubaine pour les directions de groupes internationaux qui pouvaient
ainsi imposer une application comptable unique, facilitant le « reporting » mensuel et la
consolidation.
Actuellement, la direction informatique intervient dans l’intégration de ces progiciels.
Dans de nombreuses activités, elle conserve le développement des applications orientées
vers leur cœur de métier. Encore que le développement de solutions conformes à une
activité donnée, si il ne fournit pas en lui-même un avantage concurrentiel, peut faire l’objet
d’acquisition de progiciels développés par des éditeurs spécifiquement pour une branche ou
une niche.
Cette évolution présente cependant un certain nombre de problèmes.
Le centre de décision s’étant déplacé en ce qui concerne le choix des applications informa-
tiques, ce sont souvent des décideurs ne possédant pas particulièrement de compétences en
la matière, plutôt spécialisés dans la finance, qui effectuent les choix.
Le service informatique ayant l’impression d’être mis l’écart et d’être dévalorisé, va
développer des résistances au changement par rapport à la mise en place des progiciels.
En conclusion, dans la plupart des grandes organisations, on constate actuellement un
malaise quant au rôle de la direction informatique dans le développement des applications
utilisées. Elles ont souvent été exclues de ce processus et le vivent comme une dévalorisation
de leur fonction.
b) La direction informatique interne et la maîtrise des moyens techniques
La direction informatique est responsable de la disponibilité permanente des moyens
techniques adéquats.

LES DIFFÉRENTS DOMAINES CONCERNANT LES MOYENS TECHNIQUES

Domaines Usages
Serveurs Ces ordinateurs permettront le partage des données et des applications.
Systèmes d’exploitation Le choix influera sur les outils disponibles pour les utilisateurs.
Moteurs de bases de données Le choix influera sur les logiciels disponibles pour les utilisateurs.
Réseaux et de moyens Vecteur de la communication et du partage entre les utilisateurs.
de communication
Postes clients Ordinateur à disposition de l’utilisateur final.
Logiciels outils (tels que traitement Outre les logiciels applicatifs, les utilisateurs ont besoin d’une boîte
de texte, tableur, navigateur, etc.) à outils logiciels pour les tâches standard.

137
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

La résolution des ces problèmes est complexe dans les organisations de taille importante,
car les problèmes de nature quantitative peuvent devenir des problèmes qualitatifs
orientant la nature des choix.

EXEMPLE
Le choix d’une suite bureautique dont la licence est payante ou d’une suite bureautique libre se pose
différemment pour une organisation qui a besoin de 10 versions et pour celle qui a besoin de plusieurs
milliers de versions. Dans les grandes organisations, le changement rapide de versions de systèmes
d’exploitation des postes clients ou de suites bureautiques représente un budget d’une telle impor-
tance, qu’il pose un problème d’une toute autre nature.
La direction informatique d’une grande organisation doit donc effectuer des choix dans ces domaines
par rapport à l’affectation d’un budget, qui ne doit pas être uniquement consacré au changement de
versions de licences de logiciels de base. Or, modifier les versions de logiciels de ce type d’une manière
partielle provoquerait des problèmes de suivi pour le service informatique et des problèmes de compa-
tibilité et d’échanges de données entre les utilisateurs. Cette solution n’est donc pas envisageable.

c) La direction informatique interne et la qualité des services offerts


aux acteurs de l’organisation
Dans les grandes organisations, la direction informatique, n’ayant plus pour mission exclusive
le développement des applications de gestion utilisées, a pour objectif de rendre des services
aux utilisateurs.
Dans cette optique, on demandera au service informatique d’adopter une démarche qualité
pour améliorer les services rendus aux utilisateurs. La direction informatique pourra s’engager
dans une optique de certification, de type ITIL ou CMMI. Part. 3, chap. 10, sect. 2

1.2 La division du travail et la structuration des équipes informatiques


Les problèmes à résoudre, dans le domaine de l’informatique, sont de natures très diverses.
Ils deviennent de plus en plus complexes au fur et à mesure de l’évolution technologique. Ils
impliquent donc une spécialisation et une division du travail au sein du service informatique.
La structure adoptée permet d’avoir une équipe par nature de services à rendre et donc par
spécialité technique.

STRUCTURATION TYPE DES ÉQUIPES INFORMATIQUES DANS LES GRANDES ORGANISATIONS


Équipes Sous-équipes Rôles
Une équipe Les serveurs, l’installation et l’optimisation des systèmes d’exploita-
système tion.
Une équipe bases Administre les bases de données, gère les plans de sauvegarde des
de données données, gère les profils utilisateurs et les droits d’accès aux données.
Équipe réseau Gère les problèmes relatifs aux communications internes et externes :
et communication réseau local câblé et sans fil, Intranet, Extranet, accès Internet,
appareils actifs du réseau.
Une équipe Web Gère et développe le ou les sites de l’organisation.
Une équipe S’occupe des postes clients, installation, renouvellement, dépannage,
micro-informatique adjonction d’équipements ou de logiciels, assistance aux utilisateurs.

138
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE


Équipes Sous équipes Rôles
Une équipe S’occupe d’installer et de mettre à jour les versions des progiciels,
progiciels d’assister les utilisateurs, de gérer l’intégration des progiciels dans
le système d’information.
Une équipe Assure le développement d’applications à destination des utilisa-
développements teurs et d’interfaces entre les applications.
Équipe méthodes Définit les méthodes de travail et les outils standard pour le déve-
loppement des applications.
Équipe chargée Réalise les analyses à partir des cahiers des charges et qui peut éga-
des études lement, en amont, avoir un rôle d’assistance à maîtrise d’ouvrage
dans la rédaction des cahiers des charges.
Équipe développement Chargée de l’écriture et des tests des programmes.
des applicatifs
Équipe déploiement Chargée du déploiement des applications et de la mise en produc-
tion des versions successives.

1.3 L’impact de la taille sur les choix et les modalités de gestion


du système d’information
La taille d’une organisation entraîne nécessairement des phénomènes d’inertie importants
dans la gestion du système d’information et des outils informatiques qu’il utilise.
Cette règle est universelle dans le règne du vivant. Les êtres de petite taille s’adaptent plus
facilement que les êtres de grande taille.
a) L’inertie dans la prise de décision en la matière
est tout d’abord un problème financier
Toute modification des choix en matière de système d’exploitation, de plateforme techno-
logique, de logiciel applicatif, a des conséquences budgétaires qui peuvent être énormes et
qui feront hésiter à prendre la décision.
Il n’y a pas de solutions miracles à ce problème.
Certains imaginent que le recours aux logiciels libres dans tous les domaines, depuis les
systèmes d’exploitation jusqu’aux applications opérationnelles et décisionnelles en passant
par les outils bureautiques, est la solution du problème. Il ne faut pas confondre logiciels
libres et gratuité. Dans la société dans laquelle nous vivons au niveau mondial, la gratuité
n’est pas envisageable.

EXEMPLE
Google, célèbre moteur de recherche sur Internet, offre ses services librement et propose même depuis
peu des outils bureautiques comme Star Office sans les facturer.
Quelle est la contrepartie, puisque cette société annonce de très confortables bénéfices ?
La première contrepartie, c’est l’acceptation de la publicité.
La seconde contrepartie, plus conséquente, c’est le renoncement à un certain niveau de performances
ou à certains fonctionnalités ou services qui existent dans d’autres produits payants.
On peut choisir des produits libres, mais il faut évaluer les coûts indirects et induits, car rien n’est
gratuit, afin de juger objectivement de l’adaptation de la solution.

139
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

EXEMPLE
Si l’outil libre ne comporte pas certaines fonctions, il y aura perte récurrente de temps des salariés ou
indisponibilité de certains résultats. Ces lacunes ont un coût pour l’organisation qu’il faut essayer
d’évaluer.

On entend souvent dire, que les compétences des utilisateurs sont telles qu’un produit
moins performant leur suffit.
C’est peut être vrai. Mais ne pose-t-on pas le problème à l’envers ? Le niveau de qualité du
traitement de l’information dans les organisations est actuellement très mauvais. On n’est
donc pas dans une situation où les gains de qualité en la matière puissent paraître marginaux.
Le raisonnement sur le véritable coût d’un choix est rarement fait de manière correcte, dans
la mesure où les décideurs :
– considèrent que les termes libre et gratuit sont synonymes. Ce qui est loin d’être le cas ;
– ne prennent en considération que les charges externes ou évidentes de l’opération, sans consi-
dérer le coût d’obtention d’une information et la valeur de celle-ci pour l’organisation.
C’est ainsi que les directions financières, qui ont un poids prépondérant dans la prise de
décision en matière d’outils informatiques dont sera doté le système d’information,
décident souvent de limiter les développements spécifiques autour d’une solution progi-
cielle, en ne prenant en compte que les charges directes que cela représenterait.

EXEMPLE
Dans une grande entreprise, la direction financière a pris la décision d’acquérir un ERP pour la gestion de
la plupart de ses processus. La consigne a été donnée par le directeur financier qu’aucun développement
spécifique ne devrait être réalisé, la solution standard devrait suffire à la satisfaction des besoins.
Les outils de gestion n’étant pas conformes aux besoins, de nombreux retraitements manuels à partir
d’extraction des données de l’ERP et utilisant des tableaux Excel sont effectués, qu’il est impératif de
réaliser dans la mesure où cela permet de répondre à des exigences des clients. Le service informatique
a mené une petite étude pour savoir ce qu’impliquerait le développement spécifique manquant. Il en
est arrivé à la conclusion que 50 jours hommes de développements et tests suffirait à résoudre le
problème. En l’absence de ce développement, le service utilisateur a évalué qu’il lui était nécessaire de
consacrer 2 500 h de travail par an des employés, soit un poste et demi environ. De plus, les informa-
tions étaient disponibles avec 6 mois de retard, au grand désagrément des clients.

Ce genre de situation aberrante est malheureusement fréquent, dans la mesure où les


décideurs n’ont pas la compétence et l’information nécessaire pour prendre une bonne
décision. Ils n’ont que le pouvoir d’imposer leur décision, bonne ou mauvaise.
Mais il faut dire à leur décharge qu’ils disposent d’un budget et que modifier les choix, en
un point quelconque, entraîne des impacts budgétaires très importants et parfois difficiles à
maîtriser, a priori.

EXEMPLE
Dans l’exemple précédent, si on entre dans la logique d’accorder le développement spécifique décrit,
qui paraît absolument nécessaire, si les évaluations fournies sont correctes, ne va-t-on pas mettre le
doigt dans un engrenage que l’on ne maîtrisera pas ? Chaque service s’appuiera ensuite sur cet
exemple, pour faire céder les décideurs et obtenir de nouveaux développements. Or les décideurs ont

140
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

peu de moyens et de compétences pour s’assurer de l’exactitude des informations d’évaluation qui
leurs sont fournies. La solution la plus simple, sinon la meilleure, semble alors être de tout refuser.

b) Cette inertie de la prise de décision constitue, par la suite,


un problème organisationnel
Dès que l’on veut modifier un aspect du système d’information et remplacer un outil infor-
matique par un autre, on se heurte à des difficultés liées à la taille.
Le nombre de personnes à former nécessite un plan de formation long, lourd à mettre en
œuvre et représentant un poids fort dans le budget de formation.

EXEMPLE
La Poste a décidé, il y a quelques années, de changer son logiciel de comptabilité, utilisé dans tous ses
bureaux. Il a fallu former des dizaines de milliers d’agents, qui devaient être opérationnels le jour J à
l’heure H. En effet, tous les bureaux ont basculé le même jour sur le nouveau logiciel. Et un agent ne
pouvait quitter son poste sans clôturer sa caisse, donc sans avoir terminé toutes les opérations de sa
journée comptable. La formation des agents a duré plusieurs mois. Certains on été formés trois ou
quatre mois avant le démarrage de l’application, tandis que d’autres ont reçu la formation a posteriori.
Il fallait donc s’arranger pour que, dans chaque bureau, on dispose de suffisamment d’agents opéra-
tionnels sur le logiciel, avant le jour du démarrage. Inutile de préciser que cette opération a été le
projet essentiel du plan de formation de cette année là.

Le changement organisationnel, bien que nécessaire, est difficile à conduire à cause du


nombre de personnes concernées. Les risques de résistance au changement sont plus diffi-
ciles à analyser. Les mesures à prendre pour éviter que ce risque ne se réalise sont plus diffi-
ciles à mettre en œuvre. Les conséquences de la mauvaise conduite du changement seront
plus lourdes et peuvent aller jusqu’au conflit collectif. Les traces d’une conduite du
changement ratée seront plus profondes et poseront longtemps problème.

EXEMPLE
Dans une grande industrie, au milieu des années 1990, on pouvait s’étonner du fait qu’une techno-
logie datant de 20 ans (utilisation des bases de données hiérarchiques) soit maintenue alors que des
modifications conséquentes étaient effectuées sur l’application de gestion des approvisionnements.
Compte tenu du coût de l’opération et du fait qu’elle ne permettrait pas de satisfaire totalement les
besoins, on pouvait se poser légitimement la question de la validité de la décision prise. Lors d’une
discussion avec le directeur informatique, il est apparu que ce choix n’était pas souhaité, mais le seul
possible à ce moment là dans cette organisation.
Dix ans plus tôt, lors du dernier changement d’applicatif dans ce domaine, les employés avaient vécus,
pendant presque deux ans, un véritable scénario catastrophe. Ils avaient dû refaire et saisir l’inventaire
physique un certain nombre de fois. Ils avaient dû faire des heures supplémentaires pour vérifier
manuellement les données et calculer des résultats vitaux que le système n’arrivait pas à leur fournir.
Lorsque l’idée d’un changement d’application avait été évoquée, une levée de boucliers avait
immédiatement eu lieu dans l’organisation et la menace de grève brandie. Dans l’esprit des
employés, quelle que soit la solution choisie, la mise en place d’un logiciel était synonyme du renou-
vellement de la situation qu’ils avaient connue. Ils étaient totalement sourds aux explications ration-
nelles que les dirigeants et les informaticiens essayaient de leur fournir. La direction avait donc du
reculer et se satisfaire d’une replâtrage de la solution existante.

141
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

1.4 L’impact du caractère multinational de l’organisation


Certaines décisions prises en matière de choix de progiciels sont liées au caractère multina-
tional de l’organisation.
Les directions de groupe souhaitent, en effet, que leurs filiales disposent dans tous les pays
des mêmes outils informatiques, notamment en termes de comptabilité et de finance. Cela
permet de faciliter le reporting et la consolidation. Cela facilite également la mise en œuvre
des règles du groupe.
Ce désir d’uniformisation va être présent également en matière d’applications décisionnelles.
Ce qui, pour des raisons de normalisation des référentiels de données et de similitude des
outils de contrôles de gestion, va se répercuter également sur les applications orientées
métiers. La discrimination se fera alors par métiers, pour les organisations diversifiées et
non par pays.
Mais ce qui paraît légitime du point de vue d’une direction générale d’un groupe multina-
tional, apparaîtra souvent comme une ingérence difficile à supporter du point de vue des
filiales nationales. Cela va provoquer de leur part une résistance importante au changement,
au moment de la mise en place des outils choisis par le groupe.
1.5 La tendance à l’externalisation des services informatiques
Malgré leur taille, les grandes organisations ont de plus en plus tendance à choisir d’exter-
naliser tout ou partie des services informatiques.
Cela permet une meilleure maîtrise des coûts et du niveau des services rendus. On se
retrouve en effet dans un cadre contractuel qui permet beaucoup mieux de prévoir les coûts
et d’exiger le niveau de qualité des services.
Les grandes organisations utilisent donc l’infogérance (ou outsourcing) pour externaliser la
gestion de certains de leurs services informatiques.
Le recours à l’infogérance peut porter sur différents domaines, en termes de matériels ou de
logiciels.
Il faut se méfier de ne pas exagérer le recours à l’externalisation des services informatiques.
Le système d’information étant le système nerveux de l’organisation, il y a un risque à en
perdre la maîtrise et à déléguer à l’extérieur le contrôle, y compris sur des outils techniques
mais qui conditionnent la régularité du service et l’adéquation permanente de ceux-ci aux
besoins. WEB Infogérance – http://www.acheteursinfo.com/actualites_infogerance.html

2. Le cas des petites organisations


La problématique des petites organisations en matière de fonction informatique est très
différente.
En règle générale, leur taille ne leur permet pas de posséder un service informatique interne,
ni même des personnes ayant des compétences avérées dans ce domaine.
Elles sont donc amenées à traiter avec des services externes, voire à externaliser totalement
certains services.
2.1 Le recours aux services externes
Les organisations de taille modeste, ne possédant pas toujours un service informatique
interne, vont devoir faire appel à des services externes. Les plus importantes d’entre elles

142
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

pourront néanmoins posséder, au sein de leur personnel, des salariés ayant une formation
en informatique. Elles peuvent recruter des salariés exerçant un des nombreux métiers de ce
domaine. Néanmoins, par rapport à la diversité des domaines d’expression des besoins, il
n’y aura pas couverture totale.

EXEMPLE
On trouve souvent dans les PME un ou plusieurs postes de techniciens en micro-informatiques et
réseaux. Ces personnels ont pour mission l’assistance aux utilisateurs, le dépannage et les évolutions
matérielles et logicielles au quotidien.
Ils peuvent faire l’interface avec les prestataires extérieurs.

Recourir à des services externes commence par choisir un prestataire pour auditer le
système d’information et assister la maîtrise d’ouvrage, dans l’expression de ses besoins
jusqu’à la rédaction des cahiers des charges.
En matière d’applications informatiques, les petites organisations n’auront pas d’autres
choix que de faire développer leurs logiciels de manière externe ou d’acquérir des progiciels
du marché. Compte tenu du coût des développements spécifiques, elles seront le plus
souvent contraintes à un achat de progiciel. Le rapport des coûts entre les deux types de
développement est en effet d’un facteur 10.
En ce qui concerne les aspects techniques des outils informatiques, comme les réseaux, la
gestion de leur site, elles auront intérêt à sous-traiter des compétences spécialisées qu’elles
ne pourront pas avoir en interne.
2.2 L’impact de l’absence de compétences internes
Ne pas avoir de compétences dans l’ensemble des domaines de l’informatique implique de
devoir faire confiance à des prestataires extérieurs dans des domaines stratégiques pour
l’organisation. Acquérir des compétences extérieures est souvent possible, mais cela repré-
sente des coûts qui ne sont pas toujours à la portée d’une petite organisation. Il arrive donc
souvent que ces organisations, ayant un budget modeste et aucune compétence interne,
aient recours à des solutions dégradées par rapport à leurs besoins.

EXEMPLE
Une entreprise avait besoin d’une application de gestion d’affaires. Elle ne possédait pas le budget
nécessaire pour l’acquérir et s’est donc contentée de détourner l’application de gestion commerciale
standard, qu’elle avait achetée et installée elle-même, pour essayer de satisfaire ses besoins de gestion.
Elle a donc utilisé une des codifications disponibles dans le logiciel pour simuler la notion d’affaires.

EXEMPLE
Une association a besoin d’une application pour gérer ses adhérents. Elle confie à un stagiaire de BTS
Informatique la réalisation de celle-ci. N’ayant pas les moyens d’investir dans des outils de dévelop-
pement elle lui demande de réaliser l’application avec Access, logiciel dont elle a déjà la disposition.

Les outils informatiques de toutes natures, permettant de constituer les briques du système
d’information, représentent un puzzle complexe et mettent en œuvre des techniques diffé-
rentes et de plus en plus complexes et spécialisées. Bien que différentes, elles doivent être
cohérentes.

143
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

Pour limiter les coûts, les dirigeants des petites organisations ont tendance à vouloir gérer
eux-mêmes la coordination des prestataires des différentes spécialités. En cas d’incohérence
du résultat, ils ne sont pas capables de démêler les arguments des uns et des autres, afin
d’obtenir un ensemble capable de fonctionner.
Le coût d’obtention d’un maître d’œuvre concernant les aspects techniques du système
informatique n’est pas négligeable, mais il peut s’avérer rentable d’y recourir car c’est une
garantie de bonne fin dans la mise en place du système.
Il faut donc se méfier des fausses économies.

EXEMPLE
Dans une PME, le dirigeant trouvant exorbitant le tarif à payer pour avoir un prestataire qui coordonne
l’ensemble des fournisseurs participants à la mise en place de son système informatique, a décidé de gérer
les prestataires lui-même et d’en coordonner les actions. Lors de la mise en fonction du système, il a
constaté de nombreuses anomalies qui bloquaient les utilisateurs et endommageaient les données.
Mais il n’arrivait pas à savoir si l’origine du problème était matérielle et venait de l’installation du réseau
local ou s’il s’agissait d’anomalies du logiciel. Les deux prestataires se renvoyaient la balle et il ne possédait
pas les compétences pour trancher. Après plus d’un an de dysfonctionnements, dont il ne voyait pas l’issue,
le dirigeant s’est décidé à s’associer les services d’un cabinet conseil pour faire un audit de son système
et y voir clair. Il s’est avéré que le type d’installation réseau n’était pas compatible avec l’environnement
industriel de l’entreprise, ce qui provoquait de nombreux problèmes. En conséquence, l’intervention du
cabinet conseil qui a réalisé l’audit lui a coûté plus cher que le fait de prendre un prestataire, maître
d’œuvre, dès l’origine. Son entreprise a acquis un système qu’il n’a pu faire fonctionner correctement qu’au
bout de deux ans, après avoir subi, de surcroît, un coût complémentaire pour faire modifier l’installation
de son réseau. Le prestataire a fait valoir que les contraintes environnementales n’étaient pas explicitées
dans le cahier des charges et il a de ce fait facturé la modification de l’installation.

section 2
stratégie informatique
1. Relation entre la stratégie de l’organisation
et la stratégie informatique

Forces et faiblesses Opportunités et menaces


de l’organisation de l’environnement

Intelligence du problème

Le processus
Modélisation des solutions possibles de prise de décision
stratégique

Choix de la solution à implémenter


D’après H. Simon.

Dans sa mise en œuvre, ce point est abordé ultérieurement ⇒ Part. 2, chap. 8, sect. 1

144
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

Toute décision stratégique va entraîner une variation du volume ou de la complexité des


flux à maîtriser. Cela implique que toute décision stratégique va rendre nécessaire l’évolution
du système d’information.
Reprenons l’idée que le système d’information est le système nerveux de l’organisation.
Les décisions stratégiques sont des décisions concernant le développement de l’organisation.
Si elles relèvent de l’expansion, elles sont assimilables à la croissance d’un être biologique,
tel que l’être humain. La taille du système nerveux grandit de manière homothétique par
rapport à la croissance de l’être, mais le nombre de dimensions, à développer et à coordonner,
reste le même. Nous grandissons mais nous conservons toujours deux bras et deux jambes.
Si les décisions stratégiques s’orientent vers une certaine diversification, la complexité va
augmenter. Le phénomène est comparable à l’ajout de dimensions. Nous nous retrouvons
avec quatre bras au lieu de deux. Cela pose de nouveaux problèmes et notamment des
besoins de coordination différents, beaucoup plus importants.

En résumé, toute décision stratégique va entraîner un besoin d’évolution du système d’informa-


tion. Si ce besoin n’est pas satisfait, au lieu d’être un facteur clé de succès dans la mise ne œuvre de
la stratégie, le système d’information deviendra un facteur d’échec.

Cependant, mettre en œuvre des décisions stratégiques n’est pas immédiat. Entre la
décision et la réalisation, il se passe des mois, voire un an et plus.
La mise en place de la stratégie n’est pas non plus instantanée. Il y a une montée graduelle
en puissance des effets de la mise en action des décisions.
À partir de l’analyse de l’impact des décisions prises sur les besoins d’évolution du système
d’information, on dispose donc du temps nécessaire pour réaliser les opérations nécessaires
à la mutation du système d’information.
On pourra :
– définir les directions des évolutions et les objectifs à atteindre ;
– planifier les évolutions afin qu’elles existent au bon moment.
Tout ceci sera réalisé dans le cadre de ce qu’on a l’habitude d’appeler le schéma directeur.
La démarche décrite ci-dessus paraît simple et on peut se demander pourquoi elle n’est pas
appliquée de manière systématique, avec un succès constant. Force est de constater que la
réalité est plutôt inverse.
On peut citer deux raisons majeures à ce phénomène :
– la première raison : de très nombreux dirigeants ne font pas le lien entre prise de décision
stratégique et évolution du système d’informations ;
– la seconde raison : le cadre de la prise de décision stratégique n’est pas toujours très clair.
Connaître l’organisation n’est pas simple, c’est un exercice d’introspection qui exige une
parfaite connaissance de tous les éléments de l’organisation et une très grande lucidité sur
leurs qualités et leurs défauts. Analyser les opportunités et les menaces de l’environnement
n’est pas plus simple. Un fait n’est ni opportun ni menaçant en lui-même. C’est l’inter-
prétation que les dirigeants vont en faire, dans un certain contexte, qui leur permettra de
le percevoir d’une manière ou d’une autre. La subjectivité du dirigeant va jouer de
manière importante dans cette perception. Si l’analyse de la décision stratégique est
biaisée, l’analyse des conséquences sur le système d’information le sera également.

145
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

2. Notion de schéma directeur informatique


et son utilisation au sein de l’organisation
Le schéma directeur aura pour objectif de définir les axes d’évolution du système d’information
nécessaires à la cohérence avec la stratégie. Il mettra en perspective les évolutions à réaliser sur une
durée de un à trois ans. Il permettra de définir les priorités et de lister les projets à réaliser pour
atteindre les objectifs. Il permettra de mettre en place une planification des réalisations pour
qu’elles soient synchronisées avec la satisfaction des besoins de la stratégie.

Le schéma directeur sera rédigé et proposé à la direction générale par la direction des
systèmes d’information et la direction informatique, au vu des décisions stratégiques prises.
Une fois approuvé, il servira de repère au comité de pilotage des projets, afin de réaliser
l’ensemble des projets qu’il contient, dans les conditions prévues.
La notion de schéma directeur présente le risque de donner une vision figée des besoins et
des projets à réaliser. En effet, les besoins de l’organisation évoluent en permanence. Un
document prévu pour comporter les projets à réaliser au cours d’un certain délai peut donc
introduire un facteur de rigidité dans la démarche, qui constituerait un handicap.
De plus, on associe l’idée de schéma directeur à un processus de prise de décision straté-
gique de la part des dirigeants de l’organisation. De nombreuses évolutions dans le système
d’information sont issues de décisions exogènes, prises par des acteurs de l’environnement
(concurrents, administrations, etc.).
WEB Schéma directeur – http://www.infoclick.fr/ccm/projet/projetmet.htm

3. Mise en œuvre du schéma directeur : les aspects tactiques


La réalisation des projets inclus dans le schéma directeur va suivre la méthodologie classique
de la conduite de projets. Part. 2, chap. 6
Entre autres, cela signifie que des contraintes de types budgétaires et de planning vont
s’imposer dans le cadre de la réalisation des projets du schéma directeur.
Dans la mesure où les projets du schéma directeur doivent permettre, par leur réalisation,
le succès des décisions stratégiques de l’organisation, la mise en œuvre de ces projets va
subir les aléas de l’avancement de la mise en œuvre des décisions elles-mêmes.

section 3
urbanisation des systèmes d’information
1. Les concepts fondateurs
LA DÉMARCHE D’URBANISATION DU SI

Inscrit l’évolution du SI Permet l’intégration Prend en compte Prend en compte


dans un mouvement du SI de l’organisation le maintien optimum les points de vue
permanent avec ceux de son des acquis positifs métier, organisationnel
environnement antérieurs et technique

146
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

Le concept d’urbanisation du système d’information applique les principes de l’urbanisme


dans la cité au système d’information.
Un certain nombre de critères peuvent se déduire de cette transposition. Ils vont nous
permettre de dresser le parallèle entre l’urbanisation de la cité et l’urbanisation du système
d’information.

LES PRINCIPES DE L’URBANISATION À METTRE EN OEUVRE DANS LES SYSTÈMES D’INFORMATIONS

Principes Modalités
L’évolution est permanente. Une ville évolue en permanence, plus ou moins rapidement et
profondément suivant les périodes, mais l’évolution ne s’arrête
jamais.
L’évolution est au service de l’utilisateur. Les évolutions mises en œuvre dans les villes ont pour objectif
d’améliorer la qualité de la vie des habitants et des usagers.
L’évolution suit une politique définie, ou plan Ce sont des choix politiques qui amènent à limiter l’usage des
d’urbanisme. véhicules automobiles, à développer les transports au commun
ou l’usage du vélo, à protéger les espaces verts, à éviter que cer-
tains quartiers se dépeuplent, au profit des activités économi-
ques, ou perdent leurs commerces de proximité.
L’évolution n’est pas une révolution. Cela signifie que le processus normal n’est pas de raser la ville
pour la reconstruire. C’est arrivé en cas de guerre, mais cela mon-
tre que c’est à éviter. Lorsqu’il y a des travaux dans un quartier,
temporairement les conditions de vie et de circulation sont
dégradées. Néanmoins, on n’interdit pas aux habitants l’accès à
leur immeuble.
Certains immeubles vétustes sont réhabilités, Certains monuments sont entretenus, car ils appartiennent au
au lieu d’être détruits et remplacés. patrimoine.
La ville est connectée au monde extérieur. Il existe des voies de communication pour y entrer et en sortir.
L’évolution d’un quartier nécessite la prise en Géologie pour connaître les terrains, fouilles archéologiques
compte d’aspects techniques. pour découvrir et éventuellement préserver l’existant antérieur,
etc.

Urbaniser les systèmes d’information consiste à appliquer ces méthodes et ces principes à l’évolu-
tion du système d’information de l’organisation.

EXEMPLE
L’évolution permanente, mais non destructrice, est l’opposé de la méthode de mise en place d’un ERP
en « big bang ». Dans cette méthode, on supprime et remplace tout l’existant en une seule opération.

Part. 3, chap. 9
WEB Urbanisation système information

147
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

2. Les outils pour la mise en œuvre de l’urbanisation


LA PRISE EN COMPTE DES CHOIX STRATÉGIQUES :
EXEMPLE DE DIAGRAMME ISHIKAWA DANS UNE DÉMARCHE D’URBANISATION DU SI

S’implanter Développer
dans les pays Avoir un site
Racheter l’e-commerce marchand
de l’UE des enseignes Développer (B to C)
existantes une logistique
spécifique
Ouvrir Créer une Développer Être le leader
de nouvelles franchise une activité européen de la
surfaces de crédit à la distribution
de ventes consommation d’articles
Améliorer Réduire de bricolage
Adapter la rotation les délais
les achats des stocks de livraison

Améliorer
l’assortiment
Développer Développer le des points de ventes
la veille « supply chain » Améliorer
technologique management l’offre Améliorer la gestion
et marketing de produits du cadencier des rayons

Pour définir une politique d’évolution du système d’information, il faut tout d’abord
définir les objectifs de l’organisation.
Les objectifs et sous-objectifs liés à la stratégie de l’organisation peuvent être modélisés en
utilisant le diagramme Ishikawa. Il s’agit d’une utilisation moins habituelle de ce modèle
que le diagramme causes-effets, mais qui est très fructueuse.
Une fois définis les objectifs stratégiques, donc la politique à mener ou si l’on préfère le plan
d’urbanisme, on va pouvoir en tirer un certain nombre de conséquences opérationnelles
concernant la structure et l’évolution du système d’information.
LES OBJECTIFS D’ÉVOLUTION DU SI QUI SONT LIÉS À LA STRATÉGIE :
EXEMPLE DE DIAGRAMME ISHIKAWA DANS UNE DÉMARCHE D’URBANISATION DU SI

S’implanter Étendre les Développer Avoir un site


dans les pays fonctionnalités l’e-commerce marchand
de l’UE de la logistique Développer (B to C)
commerciale une logistique
Disposer spécifique
d’un logiciel Développer Avoir un SI
de gestion une activité facteur clé
des franchisés de crédit à la de succès dans
consommation la mise en place
Application EDI de la stratégie
Application de gestion avec les
de gestion des flux JAT fournisseurs
des achats
Application
gestion
Fonctions Fonction gestion merchandising
GRC de la chaîne Intégration des points de ventes
logistique des applications Application de gestion
achats/ventes de cadencier en rayon
connectée aux
platefomes logistiques

148
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

Ce deuxième diagramme Ishikawa permet, comme par un jeu de calques, de définir les
outils applicatifs qui devraient être présents dans le système d’information pour servir les
objectifs du diagramme précédent.
Afin d’en faciliter la lecture et l’utilisation, nous proposons d’ajouter un code couleur sur le
diagramme.
• Uneflèche vert foncé signifiera que le composant applicatif existe et donne satisfaction,
dans le cadre des besoins actuels. C’est le cas de l’EDI avec les fournisseurs.
• Une flèche vert pâle signifiera qu’il existe une solution dans le système d’information mais
qu’elle n’est pas pleinement satisfaisante, pour diverses raisons. C’est le cas des fonctions
GRC.
• Une flèche vert franc signifiera qu’aucune solution n’existe actuellement dans ce domaine.
Les informations à traiter le sont éventuellement manuellement ou les résultats souhaités
sont totalement indisponibles. C’est le cas de l’application de gestion des flux JAT.
Ce code couleur permettra de définir :
– les priorités dans les projets d’évolution du système ;
– les composants qui seront conservés, donc avec lesquels il faudra faire dialoguer les
nouveaux éléments.

3. L’influence de l’urbanisation sur la structure


du système d’information
La logique d’urbanisation amène à définir un plan d’occupation des sols du système
d’information, qui permettra de définir les caractéristiques requises pour chacun des
quartiers et des îlots.

Le POS de la démarche d’urbanisation permet de définir les outils applicatifs


et leurs natures technologiques, par rapport à la cartographie des processus à gérer,
en s’appuyant sur une vision conceptuelle

Les zones Zone gisement de données, zone référentiel données,


en clients zone décisionnel (structuration de outils de reporting
de gestion et d’hypercubes), zone ressource (gestion RH et comptabilité-finances…)

Les zones Zone échange (acquisition/restitution),


en client zone opérations (flux d’activités métiers),
léger zone décisionnel (exploitation décentralisée des outils et résultats)

Cette approche permet de faire un sort au dilemme habituel en matière de contexte


technique des applications. Il y a de nombreuses batailles d’Hernani autour de la question :
faut-il adopter le tout client de gestion ou le tout client léger ?
Pour des développements concernant ces techniques ⇒ Part. 1, chap. 4

Par rapport à la cartographie des processus à gérer, la réponse montre qu’il y a des
quartiers mieux adaptés au client de gestion (fonctions structurantes et à usage

149
1 CHAPITRE 3 – Structuration des systèmes d’information
PARTIE

centralisé) et d’autres naturellement plus adaptées au client léger (fonctions d’échanges


d’information).

EXEMPLE
Prenons le cas des applications décisionnelles.
Une partie des tâches à réaliser consiste à structurer la base de données décisionnelle, ainsi que les
conditions de production des résultats : états du système de reporting, hypercubes… ; peu de
personnes disposent des droits et des compétences pour réaliser ces tâches. Il n’y a donc pas d’intérêt
particulier à les mettre dans la zone client léger.
Par contre, ces outils vont être mis à disposition des différents décideurs de manière qu’ils puissent
obtenir les résultats dont ils ont besoin. Il s’agira de permettre une diffusion commode et rapide des
informations à de nombreuses personnes localisées dans des endroits différente. Ce type de tâches
convient parfaitement en client léger. WEB POS

Interconnexion EAI : Intégration


des systèmes L’entreprise d’Application
d’information d’Entreprise

Achat Vente
PGI : gestion
des processus
SCM : CRM : gestion Consommateurs
Fournisseurs supply chain de la relation et canaux
management client de distribution
Gestion
de la logistique
flexible
Frontière entre
l’entreprise et son Transport/stockage/
environnement dégroupement
Transporteurs
Logisticiens

L’urbanisation du système d’information implique la solution de deux problèmes :


a) L’intégration d’applications hétérogènes
À partir du moment où on ne fait pas table rase de l’existant, mais où, au contraire, on
recherche à protéger l’investissement antérieur en conservant ce qui donne satisfaction, il
devient nécessaire d’assurer l’interfaçage, et même l’interopérabilité, entre les nouveaux
applicatifs et les anciens.
La solution de cette problématique réside dans ce qu’on appelle l’EAI ou bus applicatif, qui
permet aux modules applicatifs de se connecter sur une épine dorsale assurant la commu-
nication entre eux. Il existe des techniques offrant des solutions de ce type, notamment des
métadonnées permettant d’avoir des embryons de référentiels communs, adoptés par tous

150
CHAPITRE 3 – Structuration des systèmes d’information 1
PARTIE

les applicatifs, pour les objets essentiels du système. Cette approche n’est pas actuellement
généralisée dans toutes les applications existantes. L’approche offerte par l’urbanisation
laisse à penser qu’elle ne le sera que sous un délai assez long. Mais le fait que l’EAI ne soit pas
une réalité actuelle sur le plan technique n’empêche nullement de généraliser l’approche
qu’il recouvre. Il suffit d’un élément dans le système qui joue le rôle d’interpréteur vis-à-vis
des autres pour rendre l’ensemble du système inter opérable.
b) La communication avec les systèmes extérieurs
Elle doit devenir naturelle et permanente, tout en assurant le niveau de sécurité requis pour
ce qui se passe à l’intérieur de l’organisation.
WEB Interface • Interopérabilit • SCM • CRM • EAI

151
APPLICATIONS

APPLICATION 6

QUESTIONS
1. Rechercher les différents types de produits que l’on trouve couramment en distribution en
libre-service.
2. Décrire le circuit des informations pour mettre en place un mécanisme de traçabilité amont
(en partant d’un lot de produit fini retrouver les lots de matières premières utilisés à sa fabri-
cation) et aval (en partant d’un lot de matière première retrouver les lots de produits finis
qui l’ont utilisé.
3. En gestion de la qualité, on appelle les 5M les sources possibles de phénomènes de non-
qualité. Il s’agit des matières, des méthodes, des machines, des milieux, de la main-
d’œuvre. Dans une industrie alimentaire fabriquant des fromages, on veut mettre en place
dans le système d’information un système de prévention des risques à la norme HACCP.
Décrire la structure des informations nécessaires. WEB HACCP

4. Rechercher des produits ayant fait l’objet de modifications de packaging ou de déclinai-


sons diversifiant les modèles et accroissant le nombre des références dans leur famille. En
déduire l’incidence sur les informations à gérer dans le système d’information.

APPLICATION 7
Une grande enseigne de la distribution décide de proposer un modèle de robot ménager à un tarif excep-
tionnellement bas pour la fête des mères. Elle négocie un an à l’avance avec la direction commerciale du

152
CHAPITRE 3 – Structuration des systèmes d’information 1
partie

fabricant pour un volume de 100 000 unités. La livraison devrait intervenir, au niveau des cinq plates-
formes logistiques spécialisées, un mois et demi avant la date de la fête des mères.

QUESTION
Décrire la méthode de calcul de coût et de marge que vous préconisez pour une telle opération.
Quelles informations seraient nécessaires, que le système d’information devrait fournir, pour
faciliter et sécuriser la négociation commerciale.

APPLICATION 8

QUESTION
Dans le cas de l’exemple précédent, décrire les fonctionnalités qu’il faudrait implanter dans le
système d’information afin qu’il possède la complexité suffisante pour maîtriser le fonctionne-
ment du système de manière satisfaisante. Cela implique de ne pas provoquer de coût supplé-
mentaire en personnel, ni de dégradation dans la sécurité et les délais de gestion des créances.

153
2
PARTIE
Gestion
des projets
en système
d’information
CHAPITRE 4 La conduite et la gestion de projet
CHAPITRE 5 L’implantation du système d’information
CHAPITRE 6 Gérer le système d’information de l’organisation

155
4
CHAPITRE
La conduite et la gestion
de projet
section 1 Principes généraux de la gestion de projets
section 2 Aspects spécifiques des projets en système d’information
section 3 Rédaction du cahier des charges fonctionnel
fiches pratiques 1 et 2• applications

De très nombreux projets lancés dans les organisations de toutes tailles et de toutes natures n’abou-
tissent pas. Cela entraîne un gaspillage de ressources et la démotivation des personnes impliquées.
On peut donc s’interroger sur les causes de ce phénomène, afin d’essayer d’y remédier.
On peut se demander si la première cause ne réside pas dans le fait que ce que l’on a appelé
« projet » au sein de l’organisation n’en est pas vraiment un.

section 1
principes généraux de la gestion
de projets
1. Définir le projet
Pour s’assurer que l’on a bien affaire à un projet, il faut commencer par considérer avec
attention la définition de ce terme.

Projet :

Ensemble d’activités ou
de travaux qui concourent
tous à la réalisation d’un Besoin :
objectif unique et mesurable.
Un projet vise à réaliser un Nécessité ou désir éprouvé
résultat apte à satisfaire le par un utilisateur.
besoin d’un utilisateur.
Il est conduit par un chef de
projet responsable unique
de sa réalisation.

157
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

1.1 Analyse de la définition de la notion de projet


Les éléments de la définition de la notion de projet Caractéristiques
Ensemble d’activités Liées de manière logique et chronologique.
Pour réaliser un objectif Il faut avoir un but unique et mesurable.
Visant la satisfaction d’un besoin Le résultat est attendu par un utilisateur.
Conduit par un chef de projet unique La responsabilité ne se partage pas.

Détaillons ci-dessous les éléments de cette définition :


a) Ensemble d’activités
Un projet est un ensemble d’activités ou tâches à réaliser qui sont liées par un enchaî-
nement logique et chronologique. Cela constitue l’élément le plus évident de la défini-
tion de la notion de projet, mais il n’est pas suffisant pour s’assurer qu’il existe bien un
projet.
b) Un projet poursuit la réalisation d’un objectif
Ces activités ou tâches concourent toutes à la réalisation d’un objectif unique et mesurable.
■ Pourquoi doit-on avoir un objectif unique ?
Dans les organisations, on constate souvent que de nombreuses tâches sont réalisées sans
objectif. De nombreux acteurs opérationnels agissent par habitude et n’ont pas une idée
très claire des objectifs pour lesquels ils effectuent leur travail quotidien. L’adoption de la
méthode projet va permettre aux différents acteurs de situer leurs tâches quotidiennes
dans un cadre objectif global et finalisé, dans lequel va s’inscrire leur poste de travail. Ils
seront alors en mesure de mieux cerner les résultats à atteindre au service de cet objectif
global.
Un projet peut être assimilé à un chemin à parcourir entre un point de départ et un point
d’arrivée, qui en constitue l’objectif ou but. L’unicité de l’objectif poursuivi est nécessaire
pour identifier le point d’arrivée du chemin à parcourir. Cela justifie que tout projet
possède un objectif unique, afin d’identifier la cible à atteindre. On pourrait résumer ce
principe en rappelant le proverbe populaire, qui dit qu’il ne faut pas « poursuivre plusieurs
lièvres à la fois », faute de quoi on n’en attrape aucun.
Le corollaire de ce principe, sachant que l’organisation a souvent plusieurs objectifs à
atteindre pour assurer son développement stratégique, consiste à définir plusieurs projets,
avec chacun leur objectif et à les mener en parallèle. C’est ce que nous appellerons par la
suite la « méthode projets ».
■ Pourquoi l’objectif d’un projet doit-il être mesurable ?
Il faut que l’objectif soit mesurable afin que l’on puisse être certain de l’avoir atteint. Il ne
faut pas que la personne qui analyse le résultat obtenu pour un projet ait une influence
subjective sur le jugement de l’atteinte de l’objectif. Il faudra donc posséder un indicateur
de mesure qui permettra de dire si le projet a atteint son but ou non. Cela implique que, dès
que l’organisation décide de lancer un projet, ayant défini clairement son objectif, elle
recherchera un ou plusieurs indicateurs qui permettront de statuer sur la bonne fin de la
réalisation de celui-ci, sans contestation possible.

158
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

c) Un projet vise la satisfaction d’un utilisateur


Un projet doit concourir à la satisfaction d’un besoin d’un utilisateur.
Pour qu’il y ait projet, il est nécessaire qu’il existe un besoin à satisfaire. Cette condition de
l’existence d’un projet, qui peut paraître évidente, est loin d’être toujours remplie. On
retrouve souvent dans les organisations de soi-disant projets, qui ont été lancés dans le but
de complaire à l’auteur de l’idée de projet, alors qu’il n’existe aucun besoin de cette sorte
chez un utilisateur identifié.
Il faut donc s’attacher fermement à l’idée que, sans besoin à satisfaire, il n’y a pas de projet.

EXEMPLE
Certains établissements publics de santé se sont trouvés confrontés depuis quelques années à
l’obligation de définir des projets d’établissement, en matière de qualité, afin de satisfaire aux
exigences de l’Agence qui les évaluent. Elle statuera sur la réalisation de leurs objectifs, en conformité
avec des actions définies au niveau politique par l’État, en tant qu’autorité de tutelle. Dans le cadre du
projet qualité de l’établissement, chaque service est amené à définir ses projets, tout en les insérant
dans les actions proposées et en prenant en compte l’éventuelle transversalité du problème à résoudre.
Il est alors possible de confectionner le projet global d’établissement, valable pour les cinq ans à venir.
Dans la plupart des cas, les personnels concernés n’ont suivi aucune formation en matière de gestion
de projets.
Sans méthodologie, le projet d’établissement regroupant tous les projets des différents services a
tendance à ressembler à l’inventaire de Prévert.
Soucieux de bien faire et de répondre aux attentes de l’agence d’évaluation, les acteurs de l’établis-
sement multiplient le nombre des projets de leur liste, assimilant la notion de projet à une simple idée.
Ils pensent de manière générale que la qualité de leur contribution est fonction du nombre de projets
proposés.
De plus, aucune méthodologie de travail commune n’étant en place dans les services, on constate
l’utilisation de vocabulaires divergents d’un recueil de projets à l’autre. Cela rend particulièrement
difficile la communication, l’émergence de projets transversaux et la consolidation au niveau de
l’établissement.

d) Un projet est conduit par un chef de projet unique


Le quatrième élément de la définition de la notion projet consiste à affirmer que tout projet
doit être conduit par un chef de projet, unique responsable de la réalisation de celui-ci.
On peut remarquer que ce principe est un principe de bon sens, car la responsabilité ne se
partage pas. Si on nomme plusieurs chefs de projet sur un même projet, la dilution de la
responsabilité aboutira inexorablement à l’irresponsabilité de tous. Il ne faut donc jamais
déroger au principe d’avoir un chef de projet unique pour chaque projet.
On constate dans de nombreuses organisations, de toutes tailles et de toutes natures, que de
nombreux projets sont lancés sans structure, et notamment sans chef de projet. L’absence
de chef de projet va entraîner que le projet ne sera pas piloté. La conséquence inéluctable
sera qu’il n’aboutira pas. Si l’on poursuit la métaphore de la conduite de projet comme
étant similaire au parcours d’un chemin, on imagine tout à fait ce qu’il adviendrait d’un
véhicule qui n’aurait pas de conducteur. Il en est de même pour la conduite de projet.
Le fait d’avoir désigné un chef de projet est une condition nécessaire, mais pas suffisante.

159
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Il faut avoir un « bon » chef de projet. Savoir conduire et gérer un projet nécessite à la fois
des connaissances et savoir-faire s’appuyant sur une formation à cette discipline, mais
également sur une connaissance approfondie du domaine concerné par le projet (compé-
tence métier).
On constate malheureusement souvent que les chefs de projet désignés n’ont reçu aucune
formation à cette fonction. Or, force est de constater que la mission de chef de projet n’est
pas innée.
Il faut également observer qu’un bon chef de projet doit posséder des qualités humaines et
relationnelles que tout individu ne possède pas. Il devra être capable de communiquer et de
convaincre afin de faire avancer son projet et de gérer les avatars et les conflits qui
pourraient surgir dans le cours de sa réalisation.
Le choix d’un chef de projet ne doit donc pas être le fruit du hasard, mais d’une réflexion
prenant en compte les compétences et les qualités personnelles.
Le chef de projet peut partager ses tâches avec des membres d’un groupe de projet, constitué
autour de lui. Pour des raisons de volume des tâches à accomplir dans le cadre de la conduite
et de la gestion du projet lorsque celui-ci est d’importance, ou pour des raisons de technicité
de certains aspects du projet qui seraient hors du domaine des compétences du chef de
projet, on est souvent amené à constituer un groupe de projet pluridisciplinaire. Mais il ne
doit y avoir qu’une seule personne finalement responsable du projet, le chef de projet.

Il est essentiel de comprendre la portée pratique de cette définition. Chaque élément qui précède
doit être pris en compte en permanence lors de la définition et la conduite d’un projet. Cette défi-
nition est d’une utilité constante dans la mise en œuvre de la « méthode projets ».
La première question à se poser pour définir l’existence d’un projet consiste à vérifier que la situa-
tion correspond bien aux différents éléments de la définition de la notion de projet et d’attribuer le
projet à une personne unique responsable

1.2 Préalables à la mise en place de la méthode projets


La mise en place de la méthode projet au sein de l’organisation implique plusieurs
préalables :
a) Définir un langage commun
Il est nécessaire de définir un langage commun entre les services, au sein de l’organisation.
Le développement stratégique des organisations se construit à travers la réalisation de
projets parallèles et concurrents, à différents stades d’avancement. Ils sollicitent les diffé-
rents types de ressources de l’organisation, nécessitant une consolidation des besoins en
ressources. Les projets possèdent le plus souvent un aspect transversal par rapport à la
structure organisationnelle, exprimée dans l’organigramme. Mettre en place de bonnes
conditions de réalisation des projets implique une qualité de communication entre les
services qui exige l’utilisation d’un langage commun. Or, on constate que cette exigence
n’est pas satisfaite naturellement. Au contraire, chaque acteur de l’organisation ayant un
rôle et un vécu différent de celui des autres, il a tendance à avoir un angle de vue différent
sur les objets gérés dans le système. Derrière un terme, il y aura, en général, une très grande
diversité d’idées, ce qui entraînera la confusion et l’incommunicabilité entre les services. Il
est donc impératif de commencer la mise en place de la méthode projets par l’élaboration
d’un dictionnaire des termes utilisés au sein de l’organisation.

160
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

b) Évaluation par rapport à la définition de la notion de projet


Il faut passer au crible des éléments de la définition de la notion de projet, les idées listées
par chacun des services. Cela permettra d’éliminer les faux projets, les projets irréalisables
ou sans valeur ajoutée pour l’organisation.
Ces deux préalables sont indispensables pour que la direction générale puisse consolider les
projets conformément à sa stratégie.
Ils permettent de distinguer une idée d’un projet.
Rappelons que la différence essentielle entre un projet et une idée réside dans l’existence ou
non d’un besoin à satisfaire.
Passer de l’idée au projet nécessite donc une étude des besoins.
c) Vérifier l’existence d’un besoin
La notion de besoin étant définie comme « la nécessité ou le désir éprouvé par un
utilisateur », circonscrire son périmètre n’est pas chose aisée.
C’est d’autant plus vrai dans les sociétés développées dans lesquelles nous vivons. L’analyse
de la structure des besoins élaborés par Maslow, si elle reste d’actualité, est arrivée à un stade
où on se situe en haut de la pyramide. Les besoins physiologiques, de sécurité et d’apparte-
nance étant satisfaits, la nature des besoins à satisfaire devient plus complexe. Ils intègrent
une part importante de facteurs sociologiques et psychologiques. WEB Maslow

Cela signifie qu’aujourd’hui dans notre société ce sont les besoins les plus élaborés et les
plus subjectifs qui sont ressentis comme non satisfaits ou insuffisamment satisfaits.
Cela entraîne qu’en règle générale, la définition du périmètre des besoins, dont la satis-
faction constitue l’objectif du projet, est complexe. Elle inclut de nombreux facteurs
psychologiques et sociologiques difficiles à déterminer avec précision et certitude mais
néanmoins fondamentaux dans le sentiment de satisfaction de l’utilisateur.

EXEMPLE
On pourrait se dire que, dans ce domaine qui semble parmi les plus objectifs, seul le résultat obtenu
présente un intérêt. On constate qu’actuellement pour les utilisateurs la manière d’obtenir ce résultat
est largement aussi importante que le résultat lui-même.
Il y a quelques années, les utilisateurs de logiciels se satisfaisaient de modes de saisie de données en
mode texte, sans utilisation de la souris, sans aide en ligne et sans possibilité de recherche évoluée
dans les données. Actuellement, la généralisation des interfaces graphiques utilisateurs, telle que
Windows, a imposé une nouvelle génération d’interfaces homme-machine, qui est devenue indispen-
sable aux utilisateurs. La définition du besoin à satisfaire lors du lancement d’un projet doit donc
prendre en compte le contexte du besoin, dans son époque. Si on s’en tient à la définition de la notion
de besoins, les exigences des utilisateurs concernant la manière d’obtenir les résultats, ne doivent pas
être considérées comme étant du domaine du « caprice », mais bien de l’expression de leur besoin à un
moment donné. À ce titre, ces exigences doivent être prises en compte.

2. Mettre en place une structure autour du projet


À l’heure actuelle, les organisations ne se contentent plus de mener des projets individuels
et indépendants. Leur stratégie de développement s’appuie sur un flux continu de projets,
menés en parallèle. Il est donc nécessaire d’instaurer, au sein de l’organisation, une véritable

161
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

« méthode projets », au-delà de simples principes de conduite et de gestion de projet,


considéré de manière individuelle.
L’existence en permanence de plusieurs projets en cours de réalisation, en concurrence par
rapport à l’attribution de ressources limitées, rend nécessaire l’existence d’une direction de
projets ayant une vision stratégique globale et disposant du pouvoir de lancer, accélérer ou
stopper un projet.
STRUCTURE POUR LA MÉTHODE PROJETS

PROJET

Comité de pilotage : Conduite Gestion Contrôler


direction des projets de projet de projet la réalisation

Intégration Responsabilité
dans la stratégie unique sur
de l’entreprise le projet

Module pilote :
Groupe
autorité Chef de revue
sur l’ensemble de projet de projet
des projets
de l’organisation

Les projets actifs étant à différents stades de leur cycle de vie, dans le cadre de la mise en
œuvre de la stratégie, cela constitue une méthode efficace d’implémentation des principes
d’équilibre de la croissance présents dans des méthodes comme la matrice du Boston
Consulting group (BCG). WEB Matrice BCG

2.1 La structure à mettre en place se compose de trois éléments


a) Premier élément, la direction de projet
Il s’agit le plus souvent de la direction générale de l’organisation ou d’une émanation de
celle-ci. Pourquoi faut-il une direction de projets ?
Pourquoi ne peut-on se contenter d’un chef de projet pour chacun des projets ? La
« méthode projets » nécessite de s’assurer de la cohérence des projets entre eux et de leur
conformité aux axes de développement de l’organisation. Elle implique l’existence d’une
structure, qui ait l’autorité et le pouvoir nécessaires pour pouvoir lancer, accélérer, freiner,
voire arrêter définitivement un projet. La vie des projets au sein de l’organisation doit être
en cohérence avec la prise de décisions stratégiques et tactiques des dirigeants. Le fait de
mettre en place la méthode projets au sein de l’organisation va entraîner que différents
projets seront en cours de réalisation au même moment. Ils vont donc entrer en concurrence

162
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

en ce qui concerne la répartition des ressources. Par conséquent, il est nécessaire qu’une
structure existe afin d’opérer des choix et de prendre les arbitrages nécessaires à la gestion
de cette concurrence entre les différents projets.
Deux raisons à la nécessité d’un arbitrage :
– les ressources disponibles de différentes natures étant limitées, on ne pourra satisfaire
tous les projets en même temps ;
– il importe que la répartition de ses ressources limitées soit conforme à la stratégie globale
de l’organisation et aux décisions tactiques imposées aux dirigeants par l’analyse de la
situation interne et externe à un moment donné.
Or, il serait irréaliste de demander à chaque chef de projet de renoncer à celui-ci, ou même
d’accepter de le freiner, alors qu’on attend de lui, tout au contraire, qu’il défende au mieux
son projet pour l’amener à l’objectif.
De plus, chaque chef de projet a un point de vue partiel sur l’organisation, correspondant
au périmètre du projet qui lui a été confié. Il n’est donc pas en mesure d’avoir le point de
vue global qui lui permettrait une prise de décision objective.
Il est donc absolument nécessaire de posséder une direction de projet, qui gérera l’ensemble
des projets de l’organisation.
Cette structure aura la capacité de prendre des décisions sur chacun des projets, car elle aura
une vision globale de la stratégie, au-delà de la simple somme des projets actifs.

EXEMPLE
L’Agence Spatiale Européenne possède plusieurs grands projets. Parmi ceux-ci, on compte le dévelop-
pement d’une navette européenne, concurrente de la navette spatiale américaine, qui serait censée
devenir un véritable avion de l’espace. Mais elle poursuit également un projet de participation à la
construction de la station spatiale internationale. Sans être dans les secrets de la prise de décision straté-
gique de cette agence, on peut constater que celle-ci a dû faire des choix entre ces projets, compte tenu
des ressources disponibles et du contexte environnemental. À un certain moment, il a été opportun de
favoriser la participation de l’agence à la construction de la station spatiale internationale. Les autres
participants de cette construction, les États-Unis et la Russie notamment, étaient particulièrement actifs
et pressés d’aboutir. La possibilité pour l’Europe de pouvoir utiliser, dans le futur, une partie de cette
ressource pour ses propres recherches, était conditionnée à sa participation à la construction de la
station. A contrario, la navette spatiale américaine connaissait de nombreuses difficultés et la disponi-
bilité industrielle des matériaux pour construire un nouveau concept de navette, véritable avion de
l’espace, n’était pas encore totalement avérée. De ce fait, on a constaté que le projet participation à la
station internationale a fait, pendant un certain temps, l’objet de la priorité des efforts de l’agence.
L’accident, qui a cloué au sol les navettes américaines pendant de nombreux mois et qui a entraîné un
frein à la construction de la station internationale, a permis à l’agence spatiale de redéployer ses
ressources sur ses autres projets et notamment sur le projet de navette spatiale. Cet exemple montre
tout l’intérêt qu’il y a à posséder une direction de projet dont la vision globale et stratégique permet une
bonne affectation des ressources disponibles aux différents projets concurrents.

La non-existence de cette structure pourrait avoir des conséquences dommageables au


niveau de l’organisation. On pourrait constater le développement de forces centrifuges de la
part de chacun des projets, qui pourraient entraîner l’incohérence et le gaspillage au sein de
l’organisation et qui pourraient à terme entraîner la disparition de celle-ci.

163
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Cela étant, la direction de projet ne doit pas se substituer aux chefs de projet. Dans l’action
et la réalisation des projets, on ne peut être juge et partie. La prise de décision concernant la
vie des projets et leur rythme de réalisation, n’est pas compatible avec la gestion quoti-
dienne de chacun des projets. Les deux structures sont donc également nécessaires et ne
peuvent être confondues.
b) Deuxième élément, le chef de projet
En ce qui concerne le chef de projet, on a l’habitude de dire qu’il conduit et gère son projet.
Ces deux termes, conduire et gérer, ne sont pas synonymes. Chacun d’entre eux permet
d’éclairer une partie de la fonction de chef de projet.
Le parallèle a été fait précédemment entre le conducteur d’un véhicule, qui d’un point de
départ amène à un point d’arrivée en parcourant un chemin, et la conduite d’un projet.
Le terme conduire un projet fait référence au parcours d’un chemin, jalonné d’un enchaî-
nement logique et chronologique de tâches à accomplir pour atteindre l’objectif. Conduire
un projet correspond essentiellement aux préoccupations de planification de projet.
Gérer un projet correspond à un aspect plus économique du rôle du chef de projet. Il s’agira
de respecter les coûts relatifs à la réalisation du projet et de vérifier la qualité du résultat
obtenu par rapport au cahier des charges.
Lorsqu’un projet est de taille importante, ou lorsqu’il nécessite des compétences techniques
spécialisées dans des domaines variés, le chef de projet peut s’entourer d’un certain nombre
de personnes, qui constitueront, autour de lui, le groupe projet.
Il restera toujours le seul responsable des modalités de conduite et de gestion du projet
devant la direction de projet.
c) Troisième élément, le groupe de contrôle ou de revue de projet
Le troisième élément, concernant la structure, consiste à mettre en place un contrôle de la
réalisation du projet, qui soit à la fois techniquement compétent et indépendant des deux
éléments précédents de la structure.
Pourquoi le contrôle doit-il être indépendant à la fois du chef de projet et de la direction des
projets ? Pour des raisons d’objectivité évidente, il ne faut pas que le chef de projet soit celui
qui contrôle la réalisation de l’objectif qui lui a été assigné. Mais, si le contrôle est réalisé par
la direction de projets, on risque également d’obtenir des effets indésirables, suivant que la
direction de projet fera confiance ou non au chef de projet.
Le contrôle va porter à la fois sur l’atteinte de l’objectif et sur les conditions de la réalisation
du projet, en termes de délais, de coûts et de qualité du résultat, par rapport au cahier des
charges.
Par conséquent, les instances de contrôle doivent posséder les compétences techniques leur
permettant d’exercer efficacement leur mission, sur les différents aspects de la conduite du
projet et du résultat obtenu.
Leur indépendance, tant de la direction de projet que du chef de projet, constitue une
condition préalable à leur efficacité.
En l’absence de contrôle extérieur, le chef de projet risque de commettre des erreurs et de ne
pas avoir le courage de les corriger. Il est toujours difficile de reconnaître ses erreurs. Mais
une erreur non corrigée aura des effets néfastes, en général proportionnels à sa durée
d’action avant correction.

164
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

Une erreur se comporte comme un caillou qu’on lance dans l’eau, plus le temps passe et
plus le périmètre de son action s’élargit.

EXEMPLE
Dans une industrie agroalimentaire, au niveau du conditionnement des produits, il était interdit de
faire usage d’un objet métallique lorsque les produits se bloquaient sur le tapis roulant. Un ouvrier
récemment embauché a dérogé à cette règle et la lame métallique utilisée s’est ébréchée sous la
pression subie. Craignant les remontrances, il a essayé de dissimuler son erreur, n’a rien dit et a rangé
discrètement l’objet métallique utilisé. Un des produits conditionnés comportait donc un morceau de
métal, corps étranger dangereux en cas d’ingestion par un consommateur. Le responsable de la fabri-
cation découvrit la lame métallique ébréchée en fin de journée. Il en tira les conclusions sur le scénario
qui s’était déroulé et loua un détecteur de métaux pour trouver le produit défectueux, en reprenant
toute la fabrication de la journée de cette ligne de conditionnement. Fort heureusement les embal-
lages des produits étaient en plastique et non en métal ! On imagine ce qui aurait pu se passer si
l’erreur n’avait pas été détectée. Mais on voit bien le coût, qui aurait pu être évité, si l’erreur avait été
signalée immédiatement par l’intéressé.

Le chef de projet peut également, dans le pire des cas, tomber dans la malversation,
l’absence de contrôle lui laissant supposer une faible probabilité d’être découvert.

EXEMPLE
Dans une agence immobilière qui exerçait parmi ses activités la fonction de syndic de copropriété, une
employée encaissait les chèques des locataires pour le compte des propriétaires. Elle était également
responsable du rapprochement bancaire des comptes sur lesquels étaients encaissés ces chèques et
des relances des locataires mauvais payeurs. Ayant quelques difficultés financières personnelles, elle
détourna certains chèques, pensant régulariser rapidement la situation. Mais il n’en fut rien et elle pris
l’habitude de poursuivre ses détournements. La mise en place d’une nouvelle organisation et d’un
nouveau système informatique révéla la chose, plusieurs années après, alors que le montant détourné
était très élevé.

Bien que ce découpage structurel puisse paraître obéir au simple bon sens, afin d’obtenir une répar-
tition efficace des tâches et responsabilités, on rencontre de très nombreux cas où il n’est pas
respecté.
Cela participe à la fréquence importante des déboires et des échecs dans les projets menés au sein
des organisations.

2.2 Appliquer la méthode projets avec un logiciel de planification de projets


La mise en œuvre de la méthode projets nécessite l’utilisation d’outils communs au sein de
l’organisation.
D’une part, chaque chef de projet devra être en mesure d’élaborer un suivi de la planifi-
cation et un tableau de bord de gestion.
D’autre part, la direction de projets devra disposer d’outils lui offrant une vision synthé-
tique des projets et de leur avancement, ainsi que de leur consommation de ressources, afin
de pouvoir effectuer des arbitrages dans les affectations, en fonction des choix stratégiques
et tactiques.

165
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Pour mettre en œuvre cette méthode, il sera nécessaire de disposer d’outils, facilitant la
tâche des chefs de projet et permettant la consolidation facile et rapide des projets en cours.
Part. 2, chap. 6, fiche 2 • Part. 2, chap. 6, appli. 2

3. Les étapes de la conduite d’un projet


Afin d’assurer le succès des projets et d’éviter à l’organisation de gaspiller ses ressources, il
est nécessaire de respecter un enchaînement d’étapes dans la conduite des projets, et des
jalons, ou points de décision, afin de choisir entre la poursuite et l’arrêt du projet.

Les étapes de la conduite d’un projet Objectifs


Étude préliminaire S’assurer qu’il existe bien un objectif à atteindre permet-
tant de satisfaire un besoin.
Étude de faisabilité et de rentabilité S’assurer qu’il existe des solutions techniques pour
résoudre le problème et qu’elles sont économiquement
viables.
Définition du projet (spécifications) Détermination des résultats partiels à obtenir, des res-
sources à mettre en œuvre, de leurs coûts d’obtention et
de leur planification.
Développement et réalisation du projet Exécution de l’ensemble des actions permettant d’obte-
nir le résultat attendu et de faire vivre le projet.
Mise et maintien hors service Opérations à mettre en œuvre lors de la fin de vie du
projet afin d’éliminer tout effet négatif résiduel.

1) Les premières étapes de la conduite de projet vont permettre de s’assurer de l’intérêt de


réaliser le projet.
On a en effet trop souvent tendance à penser que le fait d’entamer une conduite de projet
implique de devoir le mener jusqu’à son terme, coûte que coûte.
Le but est de s’assurer :
– qu’il y a bien un projet au sens de la définition précédente, c’est-à-dire un objectif unique
et mesurable à poursuivre, dont la réalisation sera apte à satisfaire le besoin d’un
utilisateur ;
– que l’on dispose de la possibilité de réaliser un produit ou un service apte à satisfaire ce
besoin, à des conditions économiques rentables.
2) Par la suite, les étapes de la conduite de projet consisteront à réaliser le projet et à suivre
son cycle de vie jusqu’à sa disparition.
En effet, rien n’est éternel et toute solution est appelée à être remplacée par une autre. Il faut
évaluer d’emblée la fin de vie du projet et ses conséquences.
3) Les étapes de la conduite de projet seront séparées par des jalons.
Un jalon est un point de décision où le chef de projet rendra compte à la direction de
projets, afin que celle-ci puisse définir s’il convient de poursuivre ou d’arrêter le projet et
où elle définira le niveau des ressources de toutes natures qu’il est nécessaire de lui
affecter.

166
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

3.1 L’étude préliminaire


La première étape consiste à définir le contenu du projet.
Il s’agit, tout d’abord, d’en définir le but et de s’assurer que celui-ci existe réellement, qu’il
ne s’agit pas d’une simple vue de l’esprit.

EXEMPLE
Au sein d’une organisation de taille importante, un projet avait été mis à l’étude. Il avait pour but
d’améliorer la circulation du courrier interne. Un projet avait été lancé et un chef de projet avait été
nommé. Appliquant la méthode, le chef de projet commença par vérifier l’intérêt de l’objectif qui lui
était assigné. Pour une organisation, notamment si elle est de taille importante, la problématique de
la circulation du courrier de manière qualitative, c’est-à-dire sans omission, sans erreur et sans délai, est
importante. On imagine les désagréments, voire les conséquences néfastes de la non-réception de
certains courriers dans les délais ou de leur transmission à un mauvais destinataire. On peut donc
conclure, a priori, qu’un projet visant à améliorer la circulation du courrier est un projet apte à satis-
faire le besoin des utilisateurs, que sont les destinataires de ces courriers. Néanmoins, continuant à
appliquer les étapes de la méthode, le chef de projet essaya de déterminer le niveau de l’objectif à
atteindre ainsi que le point de départ du projet, correspondant à la situation actuelle, dans ce
domaine. En effet, pour déterminer la conduite du projet, il lui fallait savoir quel chemin il avait à
parcourir, ce qui nécessitait d’en fixer et le point de départ et le point d’arrivée. L’enquête qu’il réalisa
sur les taux d’erreur dans la transmission du courrier dans les mois précédents fit apparaître que, sur
environ 10 000 courriers, on avait à déplorer la perte d’un seul courrier pendant cette période. Certes
celui-ci était important et concernait le directeur général. Il était alors facile de conclure, que bien que
l’objectif soit en lui-même important, la marge de progression que l’on pouvait attendre de la conduite
du projet était quasiment nulle. Il n’y avait pas matière à lancer un projet sur ce thème.

Il arrive fréquemment, lorsqu’on lance un nouveau projet, que l’on pense bien à définir l’objectif,
c’est à dire le point d’arrivée, ainsi que les tâches à réaliser pour atteindre cet objectif. Mais on
oublie souvent de définir le point de départ, c’est-à-dire la situation actuelle, avant le lancement du
projet.
Dans la mesure où les ressources de l’organisation sont limitées, il est plus efficient de lancer des
projets d’amélioration dans les domaines où il existe une forte marge de progression que de cher-
cher à élever le niveau de performances, là où celui-ci est déjà très bon.

Cette première étape de la conduite de projet consiste donc à faire un état des lieux, c’est-à-dire :
– à déterminer l’objectif du projet et à s’assurer d’un besoin à satisfaire ;
– à fixer le point de départ, c’est-à-dire la situation actuelle dans le domaine ;
– à fixer le point d’arrivée, c’est-à-dire le niveau de résultat à atteindre.
On raisonnera en termes de qualité des résultats, c’est-à-dire de niveau fixé comme objectif
et non en termes de perfection. La définition du niveau de résultat attendu sera effectuée
dans une optique de démarche qualité au sens de l’ISO 9000. WEB ISO 9000

Part. 2, chap. 7, sect. 3


À l’issue de cette première phase, qui aboutira de la part du chef de projet à un rapport
d’étude préliminaire fixant l’état des lieux et l’objectif à atteindre, la direction de projets
définira si on doit passer à la seconde phase ou si, n’ayant pas matière à projet, on
abandonne cette idée.

167
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

3.2 L’étude de faisabilité


La seconde étape consiste à rechercher une solution techniquement et économiquement viable
pour résoudre le problème posé.
La réponse à la première question, l’existence de solutions techniques, consiste à rechercher
les différentes solutions possibles pour apporter une réponse au problème posé et, par là
même, satisfaire le besoin qui constitue la finalité ou raison d’être du projet.
La réponse à la seconde question consiste à vérifier que les ressources de toutes natures que
l’on est capable d’accorder au projet sont compatibles avec l’une des solutions techniques
que l’on a trouvées. Si l’organisation utilise la « méthode projets », elle aura à gérer des
projets concurrents, se déroulant en parallèle, avec des ressources disponibles limitées. Il
sera alors nécessaire de classer les différents projets concurrents par rapport à un indice
d’efficience. Rappelons que l’efficience est mesurée par le rapport entre le résultat obtenu et
les ressources utilisées pour l’obtenir.
WEB Efficience
L’étude de faisabilité pose à la fois le problème de l’existence de solutions techniques dispo-
nibles au moment où l’on étudie le projet, mais également l’existence de solutions sociolo-
giquement, psychologiquement, moralement ou politiquement acceptables dans le
contexte.
Lorsque la réalisation d’un projet bute sur la disponibilité d’une solution technique, le
problème peut être de deux natures différentes :
– soit la solution technique n’existe pas. Il faudra remettre la réalisation de ce projet, sine
die, jusqu’à ce qu’une solution technique se présente ;
– soit la solution technique existe mais elle est trop coûteuse ou le budget peut-être utilisé à
d’autres projets de manière plus efficiente. Il faudra attendre, dans ce cas, soit de posséder
plus de ressources, soit une diminution du prix d’obtention de la technologie. Cela
arrivera avec le temps dans la plupart des cas.

EXEMPLE
Dans les années 80, mettre en place des solutions informatiques en réseau, permettant à l’ensemble
des acteurs de l’organisation de communiquer en temps réel, n’était pas à la portée des organisations
de taille modeste. Malgré tout l’intérêt qu’elles auraient eu à posséder un tel réseau, elles devaient y
renoncer. On commençait, à cette époque, à prendre conscience de la nécessité de construire le
système d’information de l’organisation comme un système nerveux, innervant la totalité de ses
membres. Cependant le coût de la mise en réseau des moyens de traitement de l’information dépassait
les capacités financières des petites structures organisationnelles. Aujourd’hui, le coût d’obtention de
ces solutions ayant chuté de manière impressionnante, cela a permis la banalisation des outils de
communication informatiques à l’intérieur des organisations et dans leur communication avec
l’extérieur.

Lorsque la réalisation d’un projet bute sur une considération de type moral ou politique, il
faudra l’abandonner tant qu’une autre solution ne permettra pas d’éviter cet obstacle.
EXEMPLE
Il y a quelques années dans les hôpitaux, la sécurité des personnes atteintes de maladies dégénéra-
tives du cerveau ou de maladies psychiatriques posait des problèmes difficiles à résoudre de manière
satisfaisante, dans la mesure où cela passait quasi systématiquement par une atteinte à la liberté

168
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

individuelle. La recherche scientifique dans ces domaines et les progrès technologiques permettent
aujourd’hui d’envisager des solutions techniques plus efficaces, tout en étant moralement plus
tolérables.
Un projet irréalisable aujourd’hui peut donc devenir réalisable demain. Ces projets ne
seront pas totalement abandonnés par la direction de projets, mais simplement remis à plus
tard, en attendant qu’une solution techniquement et économiquement satisfaisante se
présente.

Le deuxième jalon permet à la direction de projets de choisir, parmi les solutions possibles éven-
tuelles, celle qui lui paraît la plus pertinente et la plus efficiente au moment où elle prend sa déci-
sion. La décision sera prise d’après le dossier d’orientation réalisé et présenté par le chef de projet.

3.3 La définition du projet


La troisième étape consistera à définir le contenu du projet décomposé en trois domaines :
– la planification du projet, qui permet de déterminer les délais de réalisation des tâches ;
– les ressources nécessaires à la réalisation des tâches et leur coût d’obtention ;
– la nature des résultats attendus, se présentant généralement sous la forme d’un cahier des
charges fonctionnel.

QUALITÉ TECHNIQUE DU RÉSULTAT

COÛT DÉLAI

Pour réaliser cette troisième étape, on utilisera des outils de décomposition cartésienne,
sous forme d’organigramme, qui permettront de déterminer :
– quels sont les résultats partiels à obtenir ;
– quelles sont les tâches à effectuer pour les obtenir ;
– quelles sont les ressources à utiliser et à quels coûts.
Le principe de la décomposition cartésienne consiste à décomposer le tout en parties
élémentaires, de manière à éviter les oublis et les incohérences dans la réalisation du projet
global. Il est très difficile intellectuellement d’envisager la globalité d’un projet.
Le fait de lister, suivant un fil conducteur propre au métier de chaque projet :
– les résultats partiels à obtenir ;
– les tâches à effectuer pour atteindre ces résultats partiels ;
– les ressources à mobiliser pour chaque tâche ;
permettra d’éviter les omissions, les retards, les dépassements de budget et les défauts du
résultat obtenu. WEB René Descartes

Le premier organigramme de décomposition, le Product Breakdown Structure ou PBS,


consiste à décomposer l’objectif global du projet en résultats partiels à obtenir afin
d’atteindre cet objectif global. WEB PBS

169
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Le deuxième organigramme de décomposition, le Works Breakdown Structure ou WBS,


consiste à définir l’ensemble des tâches à réaliser pour obtenir les différents résultats du
PBS. WEB WBS

Le troisième organigramme de décomposition, l’Organization Breakdown Structure ou


OBS, permet de définir pour chaque tâche du WBS :
– quelles sont les natures de ressources nécessaires ;
– quels sont les rôles joués par les ressources dans la réalisation de chacune des tâches à
accomplir ;
– quelle quantité de chaque ressource sera nécessaire à la réalisation de la tâche et pour quel
coût.
Pour pratiquer la décomposition cartésienne d’un projet ⇒ Part. 2, chap. 7, Fiche 1
Grâce à cette décomposition, il sera possible de constituer des lots homogènes de tâches à
effectuer et de résultats à obtenir, en fonction d’un budget alloué.
Ces lots seront ensuite confiés par le chef de projet à des fournisseurs, prestataires internes
ou externes.
En effet, un chef de projet ne réalise pas les tâches, mais les fait faire par autrui.
Il a donc besoin de constituer des lots de tâches et de résultats, dont chacun sera sous la
responsabilité d’un fournisseur unique. Ce fournisseur peut être un prestataire extérieur ou
un des services de l’organisation.
Cette remarque va permettre de donner une réponse générale à la question du degré de
décomposition pertinent dans la conception du PBS et du WBS.
Dans la mesure où il s’agit de constituer des lots de résultats et de tâches homogènes qui
seront sous la responsabilité d’un fournisseur unique, le degré de décomposition pertinent
est celui de la visibilité et de la responsabilité du chef de projet sur les éléments de l’organi-
gramme.
À partir du moment où, pour un ensemble de tâches et de résultats, le chef de projet choisit
un maître d’œuvre pour la réalisation de l’ensemble, que ce soit un prestataire externe ou
interne, il perd la visibilité sur le détail de ce qui se passera à un niveau plus élémentaire. Il
n’a donc pas à décomposer plus finement la branche concernée de son projet.
Chaque lot devra comporter les informations nécessaires à sa réalisation, c’est-à-dire les
spécifications en termes de délais de réalisation, de niveau et de nature des résultats
attendus ainsi que de budget alloué.
Un lot d’un projet comporte donc toujours ces trois natures d’information, qui serviront à
sa réalisation mais également au contrôle ultérieur des conditions de réalisation.
Les contrôles seront effectués, dans un premier temps par le chef de projet lui-même,
durant la phase de réalisation par le prestataire, puis, à réception du résultat et dans un
second temps, par le groupe de contrôles des projets.
Une autre question importante se pose concernant la méthodologie à employer pour mettre en
œuvre la décomposition cartésienne.
Pour passer du projet global à la tâche élémentaire ou au résultat élémentaire, il est néces-
saire d’utiliser un fil conducteur. Ce fil conducteur doit permettre, par association d’idées,
de passer du général au particulier. Ce type de raisonnement permettra de constituer des

170
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

lots homogènes de résultats à obtenir. Il permettra également de ne rien oublier des


éléments qui doivent être présents. Le fil conducteur à utiliser est de type métier. Cela
implique que le chef de projet maîtrise le métier qui correspond au projet qu’on lui
demande d’encadrer. À partir de là, la recherche du bon fil conducteur, celui qui sera
pertinent dans le domaine, ne lui posera pas de problème.
Le premier niveau de décomposition consiste à définir les grands domaines de résultats
qu’il faut obtenir pour atteindre le résultat global.

EXEMPLE
Si nous raisonnons sur un projet d’informatisation dans une organisation, nous devrons nous
demander quels sont les domaines concernés par la mise en place de ce type de projets. Pour faire
fonctionner un sous-ensemble d’un système d’information, il faut du matériel et des logiciels, des
utilisateurs formés et, avant toute chose, un cahier des charges. Voilà quatre branches du premier
niveau de la décomposition cartésienne du résultat, sous forme d’un PBS. Dans chaque branche, il
faudra peut-être préciser et détailler, de manière à avoir des lots homogènes sous la responsabilité
d’un seul prestataire. Dans le domaine du cahier des charges, il est possible que le chef de projet,
aidé de son groupe, ait à réaliser l’analyse fonctionnelle, voire la rédaction du cahier des charges,
l’élaboration de l’appel d’offres et le dépouillement des réponses à l’appel d’offres. Si chacun de ces
thèmes fait partie de la visibilité du groupe projet, le PBS devra descendre à ce niveau de granu-
larité. Si nous considérons la branche concernant le matériel, une configuration informatique
aujourd’hui comprend des serveurs, des postes clients et des éléments de réseau. Si l’organisation
possède des équipes informatiques spécialisées dans ces différents domaines, le chef de projet devra
décomposer cette branche suivant ces trois axes, de manière à constituer des lots qu’il confiera à
chacune des équipes du service informatique. Par contre, si nous sommes dans une organisation où
aucun personnel informatique compétent n’est présent dans le domaine des configurations
matérielles et des architectures réseau, il sera préférable de ne pas décomposer la branche
concernant le matériel. Le chef de projet devra alors choisir un maître d’œuvre qui sera responsable
de toute la branche configuration matérielle et architecture réseau. Il serait inefficace pour le chef
de projet de vouloir garder la responsabilité sur un domaine hors de ses compétences et de celles de
son organisation.

En opposition à ce qui précède, il arrive parfois que le chef de projet soit contraint
d’effectuer la décomposition des résultats et des tâches, non pas en fonction de règles de
compétences et de capacité de contrôle sur les résultats ou de capacité à réaliser les tâches,
mais en fonction de natures de charges et de ressources disponibles. Ce n’est jamais une
bonne solution pour l’organisation, mais c’est une pratique courante, qui s’impose au chef
de projet.
EXEMPLE
On prendra un prestataire externe parce que l’on dispose d’un budget dans ce domaine, au lieu de
faire appel à des services internes. La seconde solution nécessiterait peut être l’embauche de
personnel, et on ne dispose pas de ressources budgétaires dans ce domaine ou la politique de l’organi-
sation en matière de recrutement interdit cette possibilité. Il serait préférable que la prise de décision
quant à la nature de la ressource à mettre en œuvre, quant à son statut interne ou externe et quant au
niveau de granularité de la responsabilité du chef de projet, soit fondée sur les compétences et
l’efficacité de l’obtention des résultats et non sur des contraintes de nature de charges. Cependant,
dans de nombreuses organisations de grande taille, les charges par nature dans l’affectation budgé-
taire imposent une rigidité qui peut s’opposer à l’efficience dans le déroulement du projet.

171
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Il faut gérer les trois natures d’informations relatives aux lots des projets : les coûts, les
délais et la qualité des résultats obtenus. La gestion des deux premiers types, coûts et délais,
sera de la responsabilité directe du chef de projet et nécessitera de sa part un suivi régulier
et la réalisation d’un tableau de bord. En ce qui concerne la qualité des résultats obtenus, le
chef de projet aura souvent à s’entourer de personnes possédant les compétences
techniques, nécessaires à l’évaluation des résultats.

Lorsque le projet a été validé au niveau du deuxième jalon, la troisième phase va permettre de
définir précisément son contenu, afin de décider les conditions de sa réalisation.
Cette phase a pour but de définir le projet suivant trois axes :
– le contenu fonctionnel. Il correspond au cahier des charges fonctionnel, qui exprime le besoin et le
niveau à atteindre dans le résultat attendu. On se positionnera aujourd’hui dans une optique de
certification et d’approbation de la qualité du résultat ;
– le budget prévisionnel, en fonction de la nature des ressources nécessaires, internes et externes,
pour la réalisation du projet ;
– le délai de réalisation, s’appuyant sur la planification du projet, sur la base de la mise en œuvre
d’un algorithme d’ordonnancement des tâches de type PERT (Program Evaluation & Review
Technique, traduit parfois en France par « Pour Éviter les Retards Traditionnels » !).

WEB PERT

3.4 Développement, réalisation du projet


Cette étape correspond à la phase de réalisation du projet
Elle consiste à mettre au point le système à exploiter, ou à industrialiser le produit ou le
service concerné.
Elle aboutira au quatrième jalon, qui constatera l’état vivant du projet et jugera de
l’adéquation du résultat obtenu par rapport au résultat visé dans le cadre du projet.
Dans le cadre du cycle de vie du projet, les trois premières phases correspondaient à la gestation
et au développement, cette quatrième phase correspondra à la croissance et à la maturité.
WEB Cycle de vie
Cette étape demande au chef de projet d’exercer de nombreuses compétences.
Il doit, à la fois :
■ faire preuve d’aptitude en termes de relations humaines
Il doit amener des prestataires, externes ou internes, à effectuer les tâches nécessaires à la
réalisation du projet qu’il a en charge. Un chef de projet ne réalise pas les tâches, il doit les
faire réaliser par autrui. Cela implique qu’il possède des compétences en termes de
négociation, tant auprès des prestataires externes qu’internes, mais également des compé-
tences en matière relationnelle et humaine, notamment lorsqu’il a à faire à des salariés de
l’organisation.
■ faire preuve d’aptitude en termes de gestion
À cet égard, il doit suivre en permanence l’affectation des ressources, afin de ne pas dépasser
les budgets alloués. Mais il doit également contrôler les résultats obtenus, afin de juger de
l’efficience atteinte dans la réalisation des tâches et dans l’obtention des résultats partiels des
lots.

172
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

Il doit coordonner les différents prestataires afin d’éviter toutes dérives sur les trois aspects
du projet (coûts, délais, qualité des résultats).
Il doit donc être capable de structurer un tableau de bord conforme aux besoins de la
conduite de son projet. Il doit suivre ce tableau de bord, en permanence, en détectant les
écarts entre réalisation et prévision pour corriger les dérives.
■ faire preuve d’aptitude en termes de planification
Durant la phase de réalisation du projet, une des tâches essentielles du chef de projet
consistera à gérer les écarts de planification et l’ordonnancement des tâches. Il utilisera une
représentation de la planification sous forme de graphe PERT ou GANTT, de manière à
éviter que les incidents de planning n’entraînent un rallongement de la durée globale de
réalisation du projet. WEB GANTT

Pour gérer son projet, le chef de projet aura intérêt à utiliser un outil informatique de plani-
fication, du type de MS Project.
WEB MS Project – http://www.microsoft.com/france/office/project/decouvrez.mspx
Part. 2, chap. 6, fiche 2

3.5 Phase de mise et de maintien hors service


Cette phase aboutit au jalon 5, qui permet de s’assurer sur le plan interne et sur le plan de
l’environnement, du point de vue économique et social, que la mise hors service ne crée pas
de nuisance et de perturbation.
Cette idée n’a pas été mise systématiquement en application dans les projets conduits par le
passé.

EXEMPLE
On peut constater qu’aujourd’hui encore de nombreuses friches industrielles subsistent, suite à la
disparition d’industries qui se trouvaient antérieurement dans les villes ou à leur proche périphérie. Si
nous nous situons dans le cadre d’une conduite de projet qui respecte le cinquième jalon, la démobili-
sation de ses industries aurait dû prendre en compte la dépollution des sites, afin de les rendre utili-
sables à un autre usage. Si l’on poursuit cette idée jusqu’à son terme, on doit en conclure que, lors de
l’étude initiale d’un projet préalable à son lancement, la phase de mise hors service et son coût doivent
être pris en compte.

Si nous transposons cet exemple au domaine des systèmes d’information, il apparaît à


l’évidence que, lors du choix d’un nouvel outil d’informatisation, on doit prendre en
compte la facilité et le coût de passage à son futur successeur. Notamment, on doit étudier
la possibilité de transférer les données, que le système aura gérées pendant une période de la
vie de l’organisation, à un futur logiciel de remplacement. Cette approche est malheureu-
sement rarement effectuée. L’absence de la prise en compte du 5e jalon dans la conduite des
projets entraîne souvent des dommages importants : rupture dans l’accessibilité aux
données, perte de l’histoire de l’organisation, etc.
C’est pourquoi cette cinquième étape doit être prévue dès l’étude initiale du projet, car elle
a un coût, qui doit être pris en compte par l’étude de faisabilité. Lors de la comparaison des
solutions possibles, l’absence de prise en compte des coûts de mise hors service peut
entraîner une erreur de jugement dans le choix. Une solution peut être moins coûteuse
dans ses quatre premières phases, mais avoir un coût très important lors de la mise hors

173
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

service. L’attitude habituelle, qui consiste à ignorer cette phase de mise hors services du
projet, s’apparente tout à fait à la maxime bien connue « après moi la fin du monde ». Il
arrive souvent que la mise hors service d’un projet, n’ayant pas été prévue initialement,
mette en cause la bonne mise en place de son successeur, voire la stabilité et le
développement de l’organisation, pendant une période plus ou moins longue. En
conclusion, ne pas prendre en compte ce cinquième jalon risque fort d’hypothéquer
l’avenir de l’organisation.

EXEMPLE
Lorsqu’une organisation change de logiciel de comptabilité, si elle ne peut reprendre que les « à
nouveau », elle n’aura plus la possibilité de faire de comparatifs avec les exercices antérieurs. Pour ce
qui est de la tenue de la comptabilité au sens strict du terme ce n’est pas dramatique. Mais si les
décideurs avaient l’habitude d’analyser les évolutions des postes de charges et de produits sur la base
des données comptables de plusieurs exercices, c’est une perte d’informations d’aide à la décision très
importante pour eux.

4. L’utilisation de la notion de jalon


La notion de jalon est fondamentale en gestion de projets.
Au cours des deux premières phases, elle permettra de prendre des décisions de poursuite
ou au contraire d’arrêt d’un projet, avant d’avoir consenti des dépenses importantes.
Elle s’intercalera entre chaque phase du cycle de vie du projet.
Prévoir ces phases de prise de décision est donc très important pour éviter de gaspiller des
ressources.
Elles consisteront, pour le chef de projet, à présenter un rapport d’étape au comité de
direction, afin de faciliter la prise de décision, concernant la vie du projet et son intégration
dans la stratégie de développement de l’organisation.
Le premier jalon, comme nous l’avons vu précédemment, consiste à statuer sur l’étude
préliminaire, qui permet de déterminer si l’idée étudiée correspond bien à un projet,
présentant un intérêt en termes de satisfaction des besoins, au sein de l’organisation ou vis-
à-vis de ses marchés.
Le second jalon permet de déterminer s’il existe une solution technique au problème et si
celle-ci est compatible avec les ressources disponibles. Il s’agit de l’étude de faisabilité et de
rentabilité, pris ici au sens d’efficience dans l’allocation des ressources aux différents
projets.
Le troisième jalon permet de définir les conditions de planification et de gestion du projet
afin de juger de la possibilité effective de le réaliser, sous conditions de délais à respecter, de
disponibilités des ressources nécessaires et d’adéquation au budget.
Le quatrième jalon correspond à la recette du résultat permettant de juger de son
adéquation avec le cahier des charges du projet. Il correspond à la mise en exploitation du
résultat, et également à la gestion des opérations tout au long de sa vie. Il ne faut pas omettre
cet aspect car c’est souvent l’étape qui dure le plus longtemps et qui pose le plus de
problèmes en termes de suivi et de gestion.

174
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

EXEMPLE
Le projet consiste à mettre en place un nouveau logiciel de comptabilité au sein de l’organisation. Il
est tentant de considérer que le projet est achevé lorsque la recette fonctionnelle, effectuée par les
utilisateurs, est terminée, à partir du moment où la période de tests et de mise en route achevée.
Durant son utilisation, qui va durer plusieurs années, ce logiciel aura besoin d’être maintenu et
d’évoluer. Il faudra se poser régulièrement des questions sur les besoins d’adaptation ou d’extension,
sur son intégration dans le système d’information. Le plus souvent cette phase est sous-estimée et ne
fait pas l’objet d’une organisation précise.

Il ne faut pas oublier le cinquième jalon qui correspond à la fin du cycle de vie du projet et
à sa mise hors exploitation. En effet, quel que soit l’objet du projet, celui-ci sera amené un
jour ou l’autre à être abandonné. À ce moment-là, tout devra être mis en œuvre pour que
l’organisation et son environnement ne supportent aucune nuisance liée au fait que ce
projet a existé.
4.1 La conduite de projet, écart entre théorie et réalité
L’approche du développement de l’organisation par la « méthode projets » développée ci-
dessus est une approche idéale et théorique. Les règles de la conduite de projet ne sont pas
toujours respectées, dans la réalité.
4.2 Premier motif de divergence
Dans la mesure où des motivations répondant à d’autres préoccupations que la conduite
cohérente d’un projet, notamment des considérations politiques internes ou externes,
interfèrent avec la conduite de projet, on pourra constater de nombreux cas où les principes
précédents ne sont pas respectés.

EXEMPLE
On a pu voir certaines entreprises, tels les opérateurs téléphoniques, être amenées ces dernières années
à investir dans des projets tout en sachant qu’ils avaient une forte probabilité de ne pas aboutir. Cela
leur offrait, en contrepartie, un pouvoir de négociation vis-à-vis des autorités et la possibilité d’obtenir
des marchés dans d’autres secteurs d’activité.

4.3 Second motif de divergence


Il arrive également assez fréquemment que l’ensemble des phases de la conduite de projet ne
soit pas respecté.
Dans certains cas, les études préliminaires ne sont pas conduites. C’est souvent un motif
invoqué, au sein des organisations, pour ne suivre aucun des principes et aucune des étapes
de la conduite de projet.
Certaines organisations se voient imposer un choix logiciel, soit parce ce que c’est le choix
du groupe auquel elles appartiennent, soit parce qu’une organisation de tutelle propose un
outil à l’ensemble des organisations de même type.
Dans ce cas, le projet ne possédera pas de phases d’étude préliminaire, ni de phase d’étude
de faisabilité.
On peut alors se demander à quoi pourrait bien servir de mener, malgré tout, une étude des
besoins, puisque le choix de la solution est déjà effectué.

175
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Il est malgré tout utile, dans ces cas-là, d’effectuer une étude des besoins, afin de mesurer
l’écart entre la solution imposée et l’expression des besoins des utilisateurs.
Cela évitera au moment de la mise en place du projet de découvrir des facteurs de résistance
au changement, liés à un écart trop important entre la solution et le besoin ressenti.
Cela évitera également qu’un sentiment de frustration se développe, causé par l’absence de
prise en compte préalable du besoin des utilisateurs.
En disposant d’une marge d’anticipation grâce à l’étude préalable des besoins, il sera
possible d’aménager la solution et de faire évoluer l’organisation. On évitera ainsi que le
risque de résistance au changement ne devienne réalité.

EXEMPLE
1) LA MISE EN PLACE DE LA COMPTABILITÉ SAP DANS UNE FILIALE D’UN GROUPE
La filiale s’est vue imposer la mise en place du module comptabilité finance de l’ERP SAP par la
direction du groupe international auquel elle appartient. Ce choix était lié notamment à la facilité et
la rapidité de consolidation du « reporting » financier et comptable mensuel.
D’une manière générale, les dirigeants et le personnel de la filiale acceptaient mal qu’on leur impose
un logiciel, en prenant des décisions à leur place de cette manière.
Ils s’apprêtaient donc à subir, passivement et avec le maximum d’inertie, cette mise en place. Mais,
ayant recruté une étudiante en stage qui avait du mal à comprendre cette attitude, ils ont décidé de
lui laisser mener la conduite du projet. Elle a donc étudié l’expression des besoins, ainsi que les risques
de résistance au changement. Au fil de la démarche, l’organisation a évolué d’une attitude passive à
une attitude active. Cela s’est accompagné d’une remise à plat de l’organisation et des habitudes, afin
de définir les méthodes de travail et les fonctionnalités auxquelles ils tenaient absolument et les points
sur lesquels ils pouvaient modifier leurs habitudes, voire mettre en place de meilleures pratiques. La
mise en place ultérieure du logiciel en a été facilitée par une attitude active, une bonne connaissance
des marges de manœuvre et une plus faible résistance au changement
2) LA MISE EN PLACE D’UN NOUVEAU LOGICIEL POUR GÉRER LES ÉTUDIANTS
DANS UNE UNIVERSITÉ
Avant la mise en place de cet outil, chaque composante (ou UFR) gérait la manière de réaliser ses
procès-verbaux d’examen de façon indépendante, avec des outils qui lui étaient propres, soit acquis sur
le marché, soit réalisés en interne par le service informatique.
Le périmètre fonctionnel des outils était plus ou moins développé. Il s’agissait le plus souvent d’outils
bureautiques améliorés et détournés, comme des feuilles de calcul Excel ou des applications sur bases
de données Access.
L’inconvénient majeur de la multiplicité des outils au sein d’un même établissement est constitué par
la difficulté des échanges de données et l’impossibilité d’avoir les informations nécessaires à l’aide à
la décision, pour le pilotage de l’établissement.
Autre conséquence de cette diversité d’outils non communicants, la réalisation des statistiques
demandées par les tutelles exigeaient un temps de traitement manuel considérable, avec un grand
risque d’erreurs et omissions.
L’avantage de cette solution résidait, par contre, dans la souplesse d’utilisation et l’adaptation à
chaque cas particulier.
L’équipe présidentielle de l’université avait donc décidé d’acquérir le logiciel proposé aux établisse-
ments par l’agence de mutualisation des universités. Lors d’une discussion sur la conduite du projet, il
est apparu qu’aucune étude des besoins n’avait été réalisée ou envisagée. Le débat a donc porté sur

176
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

la nécessité d’entreprendre, malgré tout, une telle étude. La très grande indépendance des compo-
santes pouvait amener celles-ci à refuser l’utilisation du produit et à entrer dans une situation de
conflit avec la direction de l’établissement. Il est donc apparu comme opportun d’étudier l’expression
des besoins des utilisateurs. Cela a permis de mesurer le travail d’interfaçage nécessaire entre l’existant
et le nouveau produit et de détecter les besoins de formation aux nouveaux outils et au nouvel environ-
nement. Les profils de poste des secrétaires de scolarité allaient être notablement modifiés. Certaines
personnes n’avaient jamais utilisé de micro-ordinateurs sous Windows et cette perspective les effrayait
grandement. Le fait d’étudier les besoins a donc permis à l’établissement de résorber les facteurs de
risque de résistance au changement avant la mise en place du logiciel. Cela a permis d’éviter que de
telles résistances ne se manifestent lors de la mise en production du logiciel.

5. L’implantation de la méthode projet


et la structure de l’organisation
Un des principes définis précédemment consiste à dire que le chef de projet est responsable
unique de la conduite et de la gestion du projet.
Cela signifie qu’il doit disposer d’une certaine indépendance vis-à-vis de la hiérarchie au
sein de l’organisation afin de pouvoir se comporter en tant que client vis-à-vis des services,
qui sont pour lui des fournisseurs, face aux besoins liés à la réalisation de son projet.
Plusieurs structures organisationnelles se rencontrent de manière classique dans les organisations.
WEB Structure fonctionnelle, structure par projet
Certaines d’entre elles constituent des freins à la mise en place de la méthode projets.
D’autres, au contraire, constituent un facteur clé de succès pour cette mise en place.
5.1 Les structures qui constituent un frein
a) La structure hiérarchique d’Henri Fayol
WEB Fayol, Fayolisme
En termes de pouvoir, elle repose sur une vision verticale stricte de la pyramide hiérarchique.
Dans ce type de structure où il est impératif pour prendre une décision de suivre la voie
hiérarchique, le chef de projet, qui n’a pas le niveau hiérarchique requis pour imposer ses
vues, se trouvera dans une situation de rigidité et d’inconfort pouvant mener au conflit et, en
tout état de cause, constituant un risque de ralentissement dans la réalisation de son projet.
b) La structure fonctionnelle, proposée par Taylor, s’adapterait-elle mieux
à la méthode projets ?
WEB Taylor
En fait, dans cette méthode, un acteur opérationnel qui doit réaliser une tâche va se trouver
recevoir des consignes et des ordres de deux sources, une source technique et une source
hiérarchique. Cette structure va donc compliquer énormément la tâche du chef de projet
qui, suivant le problème à résoudre, devra s’adresser à des personnes différentes afin
d’obtenir le résultat escompté.
5.2 Les structures favorables à la méthode projets
a) La structure par projet
On peut se demander s’il serait possible d’adapter la structure de l’organisation à la
structure des projets en cours. Il s’agirait d’adopter une structure par produit ou par projet.

177
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Nous sommes face à ce que l’on peut appeler une fausse bonne idée. Au premier abord,
structurer l’organisation en fonction des flux de projets semble une idée apte à résoudre les
problèmes, puisque chaque projet serait doté, dès son lancement, des différentes natures de
ressources dont il aura besoin au cours de sa réalisation.
En fait, ce type d’organisation présente deux inconvénients majeurs.
Le premier inconvénient consiste à gaspiller des ressources. Effectivement, la consommation
des ressources de différentes natures par un projet est fonction de son stade d’avancement. Il
ne servirait donc à rien d’affecter dès l’origine des ressources à un projet. On pourrait
imaginer d’affecter les ressources au fur et à mesure de l’avancement des projets, mais dans ce
cas on reviendrait à une structure identique aux organisations classiques et l’on n’aurait plus
aucune garantie de la disponibilité de la ressource nécessaire au bon moment.
Le deuxième inconvénient correspond au développement de forces centrifuges dans
l’organisation.
La structuration par projet amènerait l’affectation de personnes sur un projet. Or un projet
a une durée de vie limitée contrairement à l’organisation. Il a également un point de vue
partiel, puisqu’il poursuit un objectif particulier au sein de l’organisation. Cette structure
aurait donc pour conséquence la tendance à développer chez les salariés de l’organisation,
un sentiment d’appartenance non plus à l’organisation globale mais au projet, ce qui
induirait des tendances aux forces centrifuges et des tendances aux conflits entre les salariés
affectés sur les divers projets.
Un sentiment de malaise se développerait lors de la fin d’un projet pour les salariés qui
perdraient leurs repères ne sachant pas où à quel projet il pourrait être réaffectés, ni si leur
groupe de travail serait reconstitué. On risque donc de développer des forces amenant à
terme à l’éclatement de l’organisation.
b) La structure matricielle
Il faut donc trouver une structure qui permette la cohésion au sein de l’organisation, afin de
lui assurer un développement équilibré et harmonieux, tout en évitant à chaque chef de
projet de subir des pesanteurs excessives de la hiérarchie.
La structure préconisée, pour être en cohérence avec la méthode projets, est la structure
matricielle.
Comme son nom l’indique, cette structure possède deux dimensions.
Une dimension verticale, où sont affectés les différents types de ressources. Elle correspond
à une structure par services. Elle constitue une vision fonctionnelle des dimensions de la
structure.
Une dimension horizontale, où chaque ligne de la matrice représente un projet, sous la
conduite d’un chef de projet.
Dans cette structure, le chef de projet se trouve en position de client. Il passe des
commandes aux services, qui sont en position de fournisseurs. Il sollicite l’affectation des
ressources dont il a besoin pour réaliser son projet, sans avoir à considérer le statut de son
interlocuteur.
Le périmètre de responsabilité de chacun est ainsi bien délimité :
– le chef de projet est responsable de la réalisation de son projet, dans une perspective de
qualité, c’est-à-dire en respectant les délais, le budget, la qualité des résultats obtenus ;

178
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

– le chef de service est responsable de l’affectation efficiente des ressources, qu’il gère et de
la satisfaction de son client, c’est-à-dire des chefs de projets.
Cette structure semble donc parfaitement bien adaptée à une stratégie de développement de
l’organisation s’appuyant sur la mise en œuvre de la méthode projets.
Cependant, elle constitue, le plus souvent, une révolution dans les idées et les comporte-
ments au sein de l’organisation. Elle nécessite non seulement d’être définie en tant que
nouvelle structure d’organisation, mais également elle implique la mise en place d’une
conduite du changement qui permette aux différents acteurs de bien comprendre leurs
rôles et leurs obligations dans ce nouveau cadre.
Il y a donc des organisations « déçues » de la structure matricielle, lorsque les dirigeants se
sont contentés de modifier la structure sur le papier sans faire les efforts de communication
et faire preuve de la patience nécessaire à la conduite du changement.
Et pourtant, ce type de structure convient parfaitement à la mise en place de la méthode
projets, comme vecteur de la stratégie de développement de l’organisation.

section 2
aspects spécifiques des projets
en système d’information
Les projets en matière de système d’information présentent des caractéristiques particu-
lières qui influent :
– sur leur complexité ;
– sur la nature des problèmes à résoudre ;
– et sur la manière de les aborder.

1. La relation « maîtrise d’ouvrage – maîtrise d’œuvre »


La première particularité réside dans la relation entre maîtrise d’ouvrage et maîtrise
d’œuvre.
Dans les autres domaines de la conduite de projets, on peut répertorier de manière
habituelle deux situations diamétralement opposées :
– soit la maîtrise d’ouvrage est totalement incompétente dans le domaine technique de la
maîtrise d’œuvre. Ce sera le cas lorsque l’on fait construire un bâtiment, par exemple.
Dans ce cas, la maîtrise d’ouvrage aura recours à un maître d’œuvre apte à transcrire
l’expression de ses besoins en termes techniques. On fera appel à un architecte pour
définir les plans, c’est-à-dire les spécifications techniques du résultat recherché, et pour
coordonner tous les corps de métiers du bâtiment devant intervenir dans la construction
de l’immeuble. Le chef de projet, du côté de la maîtrise d’ouvrage, se déchargera de tous
les aspects techniques auprès de l’architecte ;
– soit la maîtrise d’ouvrage appartient totalement au domaine de compétence du projet. Ce
sera le cas dans les services de recherche et développement chargés de concevoir les
nouveaux produits dans l’industrie. Dans ce cas, le dialogue entre la maîtrise d’œuvre et
le chef de projet sera facilité par la compétence technique de ce dernier.

179
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Dans ces deux cas, le dialogue entre maîtrise d’ouvrage et maîtrise d’œuvre est donc relati-
vement clair.
En matière de systèmes d’information de gestion, il en va tout autrement.
1) L’expression du besoin est difficile. Les besoins en matière de traitement des informa-
tions de gestion au sein d’une organisation ont une complexité très grande et, dans le
contexte mouvant qui est le nôtre, cette complexité est fortement et rapidement croissante.
Nous sommes en présence de systèmes vivants et ouverts donc inscrits dans un processus
dynamique permanent. Dans un tel contexte, l’expression des besoins ne peut être ni finie,
ni stable très longtemps.
Il est donc particulièrement difficile à la maîtrise d’œuvre, dont les compétences techniques
n’appartiennent pas au domaine de la gestion mais à celui de l’informatique, de comprendre
les besoins de manière satisfaisante. Il lui est encore plus difficile de prendre en compte les
modifications de cahier des charges, liées à la dynamique d’évolution des besoins.
2) La confusion entre système d’information et informatique entraîne souvent la
maîtrise d’ouvrage à s’imaginer des compétences techniques qu’elle n’a pas. A contrario,
elle entraîne la maîtrise d’œuvre à positionner les solutions proposées en termes de
technique informatique et non en termes de traitement efficient de l’information, au sein
d’une organisation.
Dans les organisations de taille importante possédant un service informatique interne, afin
d’organiser de manière satisfaisante la relation entre maîtrise d’œuvre et maîtrise d’ouvrage, on
est amené à désigner deux chefs de projets, un chef de projet utilisateur et un chef de projet infor-
matique. La qualité du résultat sera liée à la qualité du dialogue entre ces deux chefs de projet.
Cette structure sera favorable à la mise en place des méthodes de travail itératives ou agiles.
Part. 2, chap. 7, sect. 3

2. La relation « contraintes environnementales –


logiciel mis en œuvre »
La deuxième particularité réside dans la relation entre les obligations imposées par les différents
acteurs de l’environnement et leur transcription dans le cadre d’un logiciel à mettre en œuvre.
Dans les domaines relatifs à la fabrication de produits manufacturés, les obligations régle-
mentaires ou normatives pèsent directement sur la conception et la formulation des carac-
téristiques techniques du produit. Ainsi, un jouet pour jeunes enfants ne devra pas
comporter de pièces pouvant se détacher facilement, entraînant le risque d’ingestion par le
bébé. De la même manière, une prise électrique correspondra à des normes strictes.
Dans le domaine des systèmes d’information de gestion, les obligations de toutes natures ne
portent pas directement sur la conception et la fabrication du produit, c’est-à-dire du
logiciel, mais sur le contenu et la nature des résultats qu’il produira.

EXEMPLE
Ainsi, aucune spécification technique n’est donnée sur la manière d’écrire un logiciel de paie, mais des
mentions légales sont spécifiées comme devant apparaître ou au contraire comme ne devant pas
figurer sur le bulletin de paie. Que celui-ci soit réalisé manuellement ou avec un logiciel, les mentions
obligatoires restent les mêmes.

180
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

L’évolution des contraintes techniques dans l’industrie peut faire l’objet d’anticipation. Elle
représente une tendance générale vers la sécurité, le développement durable, le recyclage en
fin de vie, etc.
Dans les systèmes d’information de gestion, deux phénomènes vont influer sur l’expression
des besoins et son évolution :
– la stratégie des dirigeants ;
– les mesures de politiques économiques et sociales des gouvernements ;
– les évolutions géopolitiques, notamment dans un contexte de mondialisation.
Tous ces facteurs ne peuvent être anticipés par la maîtrise d’œuvre. La maîtrise d’ouvrage
elle-même ne peut anticiper les deux derniers types de phénomènes dans son expression du
besoin. Cependant, ces facteurs influent de manière fondamentale sur l’adaptation du
logiciel au besoin de la maîtrise d’ouvrage.

3. La relation « projet d’évolution du système d’information –


conduite du changement organisationnel »
Parmi les aspects particuliers des projets en système d’information, il faut considérer
l’interaction entre l’évolution du système d’information lié au projet et le changement qui
doit être opéré au sein de l’organisation, afin que le projet réussisse.
Part. 1, chap. 4, sect. 2
Suivant le taux d’évolution du système d’information, en termes de périmètre et en termes
de modification des méthodes de travail, le changement peut nécessiter une réingéniérie des
processus de gestion.
Dans ce cas, l’organisation va être confrontée à un changement organisationnel profond,
qui va remettre en cause :
– la nature et le contenu de certains postes de travail ;
– la structure des groupes de travail ;
– la répartition du pouvoir au sein des groupes de travail.
Cela va entraîner un fort risque de résistance au changement et une situation propice au
déclenchement de conflits.
La réflexion sur l’évolution de l’organisation est inéluctable lors de la conduite d’un projet
en matière de système d’information. Et la conduite efficace de ce changement constitue la
condition sine qua non de la réussite du projet d’évolution du système d’information.

4. La prise en compte des jalons du projet


Le respect des jalons est important dans la conduite de tout projet, quel qu’en soit le
domaine. Cependant, certaines règles en la matière sont souvent bafouées dans les projets
en matière de système d’information, ce qui est dommageable pour l’organisation.
Part. 2, chap. 6, sect. 1
■ Le cas des 1er 2e
et jalons
De nombreux projets en système d’information ne respectent pas les 1er et 2e jalons. Cela
signifie que l’on choisit d’acheter et d’implanter un logiciel sans avoir vérifié :
– qu’il correspondait à un besoin à satisfaire, préalablement étudié ;

181
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

– qu’il constituait bien, parmi les solutions disponibles, une solution efficiente pour satis-
faire ce besoin.
En conséquence, le fait de ne pas respecter les deux premiers jalons entraîne que le choix de
logiciels est le plus souvent un simple choix d’outils.
De ce fait, un biais est introduit dans la conduite de projets, pour des motifs qui sont
rarement fondés.
Cela pèse de manière fortement négative sur la suite du projet et sur ses chances de réussite.
■ Le cas du 5e jalon
Ce jalon prévoit que, lors du lancement d’un projet, considérant son cycle de vie, il faut
prévoir ce qu’il sera nécessaire d’entreprendre lors de la fin de vie du projet.
En termes de logiciel, l’action primordiale au niveau du 5e jalon consiste à prévoir la possi-
bilité de reprise des données dans un nouveau système.
Cette règle étant rarement respectée, on se retrouve face à deux écueils :
– le coût ou la possibilité de reprise des données n’étant pas prévu dès le départ, l’organi-
sation accepte souvent de perdre une grande partie de ses données. Elle perd ainsi une
part de son histoire et de ses possibilités d’analyse d’aide à la décision ;
– n’ayant pas songé aux possibilités de sortir les données du précédent système, on oubliera
souvent la nécessité de mettre la fonction de reprise de données dans le nouveau système,
comme une fonction impérative au cahier des charges.

section 3
rédaction du cahier
des charges fonctionnel
1. La réalisation de l’analyse fonctionnelle
1.1 Principes
Dans quasiment trois cas sur quatre, les utilisateurs se déclarent partiellement insatisfaits
des produits et services qu’ils utilisent. Lorsqu’on les interroge sur les causes, ils attribuent
leur insatisfaction à des lacunes fonctionnelles par rapport à leurs attentes.
Il est donc fondamental, lorsque l’on s’engage dans la réalisation d’un projet, de rédiger un
cahier des charges fonctionnel (CdCF).
Afin d’obtenir un cahier des charges de qualité, la première étape constitue à réaliser une
analyse fonctionnelle. Dans la mesure où l’insatisfaction de l’utilisateur est liée au constat de
lacunes dans ce domaine, le premier objectif de la pratique de l’analyse fonctionnelle sera de
ne rien oublier des attentes des utilisateurs potentiels. La méthodologie à mettre en œuvre
doit permette de penser à toutes les fonctions, qui peuvent être nécessaires pour la satis-
faction du besoin.
La solution la plus efficace consiste à constituer un groupe pluridisciplinaire qui, en
utilisant les méthodes de créativité ou « brainstorming », fera émerger les idées utiles à la
constitution d’un tableau d’analyse fonctionnelle, le plus exhaustif possible.

182
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

a) Catégories de fonctions
Les fonctions attendues par les utilisateurs peuvent être classées en plusieurs catégories.
Les deux catégories essentielles sont les fonctions principales et secondaires d’usage.
Les fonctions principales d’usage sont celles qui créent les résultats attendus dans le
domaine concerné.

EXEMPLE
On pourra dire que la fonction principale d’usage d’un lave-vaisselle est de laver la vaisselle. Bien qu’il
s’agisse d’une évidence, ce n’est généralement pas le critère qui fera acheter tel ou tel modèle de lave-
vaisselle.

Les fonctions principales d’usage ne sont pas celles qui permettent de discriminer les
produits, puisque par principe tous les produits d’une même catégorie vont présenter les
mêmes fonctions.
Les fonctions secondaires d’usage expriment la manière d’obtenir le résultat.

EXEMPLE
Il est usuel aujourd’hui de différencier les modèles de lave-vaisselle en insistant sur leurs différences en
termes de consommation d’énergie, de consommation d’eau ou de niveau sonore. Et ce sont ces
fonctions secondaires d’usage qui permettront de discriminer les différents modèles et qui amèneront
un acheteur potentiel à choisir celui-ci plutôt que celui-là.

Nous pouvons résumer la signification des fonctions principales d’usage en disant qu’elles
permettent de répondre à la question « quoi », c’est-à-dire qu’elles permettent de spécifier
les natures de résultats que l’on peut attendre de l’usage du produit ou du service.
A contrario, les fonctions secondaires d’usage répondront à la question « comment », c’est-
à-dire apporteront des informations sur la manière d’obtenir les résultats.
b) Spécificité des fonctions secondaires dans les systèmes d’information
On a souvent l’habitude de caractériser les applications informatiques d’ergonomique et de
conviviale.
Ces caractéristiques appartiennent au domaine des fonctions secondaires et demandent à
être précisées :
En matière de fonction secondaire, dans le domaine des systèmes d’information, on
pourrait retenir les aspects suivants :
■ L’ergonomie
L’ergonomie du travail est une discipline qui a pour but l’adaptation du poste de travail à
l’être humain qui l’occupe.
Comment peut-on caractériser l’ergonomie d’un système informatique ?
L’ergonomie au travail a pour but d’éviter les fatigues inutiles de l’homme dans l’exercice de
son travail.
Les sources de fatigue qui nous intéressent sont donc :
– la fatigue visuelle ;
– la fatigue intellectuelle.

183
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Comment peut-on minimiser ces deux sources de fatigue ?


En ce qui concerne la fatigue visuelle, on privilégiera dans les logiciels des écrans où les
informations sont facilement lisibles et repérables, donc bien contrastés et, a contrario, on
évitera les couleurs agressives à l’œil.

EXEMPLE
Certaines applications possèdent des champs de saisie en vert clair sur fond gris. Les informations ne
se détachent pas visuellement. Cela entraîne une fatigue visuelle inutile
Certains sites Web notamment offrent des pages éclatantes de couleurs et confuses avec des informa-
tions dans tous les sens.

En ce qui concerne la fatigue intellectuelle, on évitera d’obliger l’utilisateur à chercher


comment obtenir un résultat ou à mémoriser des informations inutiles.

EXEMPLE
Pour rechercher un produit ou un client, il faudra disposer d’un accès multicritères de recherche qui
évitera d’avoir à mémoriser des codes
Pour obtenir une fonctionnalité, créer ou modifier par exemple, la localisation et la manipulation
seront toujours les mêmes, d’un endroit à l’autre de l’application. Par exemple, il faudra éviter dans la
fiche client d’avoir, pour atteindre ces fonctions, des boutons de type texte en bas à gauche de l’écran
et, dans la fiche produit, d’avoir des boutons graphiques en haut à droite de l’écran
WEB Ergonomie

■ La convivialité
Qu’est-ce que la convivialité d’une application informatique ? Il s’agit de sa facilité d’utili-
sation. On parle parfois de son caractère intuitif.
Pour cela, il faut aider l’utilisateur dans ses manipulations grâce :
– à l’aide en ligne qui lui permet facilement de retrouver comment utiliser une fonction ;
– aux listes de valeurs disponibles pour les codes et objets du système, accessibles par les
libellés ;
– au respect dans le logiciel de la vision métier de l’utilisateur. WEB Outil convivial

■ La navigation
Cette qualité d’une application informatique, qui en grande partie pourra être déduite de
son modèle de données, consiste à permettre à l’utilisateur de naviguer dans ses données de
manière naturelle sans avoir à quitter l’action entreprise.

EXEMPLE
La bibliothécaire de l’établissement ouvre son logiciel en arrivant le matin sur le choix de menu
« gestion des prêts ». En effet, la plupart des actions qu’elle doit faire dans la journée consistent à
prêter des ouvrages ou à gérer le retour de prêts antérieurs.
Mais, il lui arrive parfois, lorsqu’elle veut enregistrer un nouveau prêt, de constater que la personne
n’est pas inscrite à la bibliothèque. Avant de pouvoir enregistrer la fiche de prêt, elle doit donc créer la
fiche de la personne concernée.

184
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

Si son application est mal pensée en termes de navigation, elle va devoir abandonner la fiche de prêt
en cours de saisie, changer de menu, accéder à la saisie des adhérents de la bibliothèque. Lorsqu’elle
aura créé la fiche de la personne, elle devra passer à nouveau par le menu, sélectionner la gestion des
prêts, recommencer toute l’opération qu’elle avait interrompue.
Dans le cas contraire, un bouton sur la fenêtre de saisie des fiches de prêt lui permettra d’accéder à la
saisie des fiches « adhérents ». Elle procédera à la création de la fiche de la personne, et en validant
cette création se retrouvera directement là où elle en était dans sa fiche de prêt, avec les informations
relatives à la personne reprises de manière automatique.

c) Types d’analyse fonctionnelle


Une autre distinction importante est à faire entre la pratique de l’analyse fonctionnelle
externe et la pratique de l’analyse fonctionnelle interne.
L’analyse fonctionnelle externe est celle pratiquée par la maîtrise d’ouvrage. Elle exprime
le besoin. Elle constitue le point de vue de la demande.
L’analyse fonctionnelle interne, au contraire, est celle pratiquée par la maîtrise d’œuvre. Elle
exprime la recherche de solutions techniques permettant de formuler un produit ou un service,
apte à satisfaire le besoin de la maîtrise d’ouvrage. Elle constitue le point de vue de l’offre.
Au sein des organisations, les décideurs en matière de systèmes d’information constituent la
maîtrise d’ouvrage. Ce sont les responsables de services et les dirigeants de l’organisation,
qui ont des besoins en matière de traitement de l’information et de production de résultats.
Les informaticiens, internes à l’organisation ou prestataires extérieurs, sont donc en
position de maîtrise d’oeuvre et d’offre d’outils aptes à satisfaire les besoins.
1.2 La mise en œuvre de la méthode d’analyse fonctionnelle externe
La mise en œuvre de la méthode d’analyse fonctionnelle externe repose sur l’enchaînement
de plusieurs pistes de réflexion, de manière cumulative. Cette méthode est à pratiquer dans
le cadre d’un groupe de créativité (« brainstorming ») à caractère pluridisciplinaire, de
manière à obtenir le point de vue le plus large possible sur le problème étudié.
a) Analyse de l’existant
La première piste qui doit être explorée consiste à analyser l’existant.
Dans la plupart des cas, l’organisation dispose déjà d’outils pour résoudre les problèmes
auxquels elle est confrontée. Il est, en effet, assez rare aujourd’hui que, dans quelque
domaine que ce soit, il n’y ait aucun existant au sein de l’organisation. Celui-ci ne prend pas
nécessairement la forme d’un logiciel, mais si des données sont à traiter et des résultats à
produire, d’une manière ou d’une autre l’organisation aura adopté une solution.
L’analyse de l’existant va permettre de repérer les éléments positifs que l’on souhaite
conserver, mais également, et c’est peut-être l’essentiel, de lister les défauts et les lacunes de
la solution actuelle.
C’est également l’occasion de poser la problématique des pratiques organisationnelles dans
le domaine et d’essayer de les améliorer. On peut les faire évoluer pour les adapter aux
conditions présentes, mais également essayer d’anticiper le futur.
À ce stade, il ne s’agit pas de raisonner en termes de produit à mettre en place, mais en
termes de besoin à satisfaire. Le risque de confusion des deux points de vue est important.

185
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Il faut donc bien insister sur l’objectif organisationnel de la démarche, répondre aux
questions :
– « quoi » ou quels résultats doivent être produit ;
– « comment » ou dans quelles conditions veut on les obtenir.
Il faut également poser la question « pourquoi », ou quelle est l’utilité du résultat que l’on
veut obtenir de cette manière.
La question avec quel outil et quelle technique n’a pas lieu d’être à ce stade de l’analyse
fonctionnelle externe. C’est cependant trop fréquemment la seule question abordée dans le
cahier des charges.
Une des difficultés repose sur la confusion des rôles entre la maîtrise d’ouvrage, c’est-à-dire
les gestionnaires qui ont besoin de traiter l’information au sein de l’organisation, et celui de
la maîtrise d’œuvre, ou informaticiens, qui vont apporter des produits et des solutions
techniques permettant de traiter les informations et d’obtenir les résultats souhaités, dans
les conditions demandées.
b) Analyse des offres sur le marché
La deuxième source d’idées, en matière d’analyse fonctionnelle externe, consiste à collecter
des informations concernant les produits existant sur le marché.
Il existe de nombreuses sources d’information, notamment grâce à Internet, mais il faut se
méfier des informations à caractère commercial émanant des créateurs des logiciels. Ils ont
souvent tendance à enjoliver la réalité de leur solution et à la déclarer adaptée à de très
nombreuses situations afin d’élargir leur potentiel de marché.
Il peut être intéressant d’aborder l’existant sur le marché à travers une démarche de
« benchmarking », qui consiste à s’intéresser aux solutions mises en place par des organisa-
tions similaires en termes d’activité et de taille. L’analyse des avantages et des inconvénients
in situ, présentée par des utilisateurs, permet à la maîtrise d’ouvrage de mieux cerner
l’adéquation d’un outil par rapport à ses propres besoins.
Il y a des nombreux salons qui permettent de collecter des informations sur les produits.
Certains organismes fournissent des monographies sur l’existant en matière de logiciels.
Le CXP est spécialisé dans l’aide au choix des logiciels en proposant une information très
complète sur ce qui existe dans les différents domaines. WEB CXP – http://www.cxp.fr/

c) Analyse de la législation et de la réglementation


Une troisième source d’idées à explorer, en matière d’analyse fonctionnelle externe, est
constituée de la législation et de la réglementation en vigueur dans le domaine concerné.
En effet, les principes édictés par les lois et réglementations, ainsi que par les normes,
s’imposent aux concepteurs et fournissent un cadre fonctionnel impératif.
Cependant, dans le domaine des systèmes d’information et des outils informatiques,
l’action des réglementations est différente de celle qu’elle exerce dans les autres domaines.
Dans le domaine des produits industriels, les réglementations et les normes agissent direc-
tement sur la définition des caractéristiques du produit. Par contre, dans le domaine des
logiciels, les réglementations et les normes qui doivent être prises en considération par la
maîtrise d’ouvrage concernent les résultats qui seront obtenus grâce au logiciel, rarement le
fonctionnement et les caractéristiques du logiciel lui-même. Il est donc plus difficile pour la

186
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

maîtrise d’ouvrage de définir les principes réglementaires à prendre en compte et ensuite de


s’assurer que le produit qu’elle envisage d’acquérir est bien conforme à l’application de ces
réglementations. Il est néanmoins impératif de s’intéresser à ce point de vue, afin de ne pas
se retrouver avec une solution non conforme aux obligations normatives.

EXEMPLE
Un bulletin de paie comporte des mentions obligatoires, facultatives ou interdites. Le simple fait de
savoir qu’un logiciel produit un bulletin de paie n’est pas suffisant. Il faut s’assurer du respect des
contraintes de manière détaillée. Il est prudent dans ce domaine de vérifier que les mentions présentes
sur le bulletin peuvent évoluer facilement, car la réglementation est soumise à de fréquentes modifica-
tions.

1.3 Présentation de l’analyse fonctionnelle et rédaction du cahier des charges


L’analyse fonctionnelle, qui va servir ultérieurement à la rédaction du cahier des charges,
peut être présentée dans un tableau.

1- Utile 2-Nécessaire
Fonction principale 3-Important 4 -Très F0 Nulle F1 Faible
secondaire, important 5- Vitale F2 Bonne F3 Forte
technique…

Type de Caractère Classe


Numéro Fonction Niveau à atteindre
fonction impératif de flexibilité

Descriptif précis Descriptif du


de la fonction niveau attendu

Le modèle de tableau présenté ci-dessus va être utilisé de deux façons :


a) le tableau d’analyse fonctionnelle servira de base à la rédaction du cahier
des charges fonctionnel
Les cahiers des charges rédigés par les maîtrises d’ouvrage, avec ou sans assistance, sont très
souvent de mauvaise qualité. Leur lecture ne permet pas de comprendre de manière suffi-
sante l’expression du besoin pour construire une offre adaptée.
■ Certes, il faut renoncer à l’idée qu’un cahier des charges puisse exprimer
en totalité le besoin à satisfaire
Cette impossibilité est liée à deux motifs, bien connus en communication.
Le premier motif est l’incapacité à exprimer la totalité de sa pensée à travers un écrit. Il y a
des éléments d’information qui semblent évidents au rédacteur et qu’il omettra. Il y a

187
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

également des éléments que sa culture ou son éducation lui interdiront de spécifier et qui
manqueront à la compréhension du lecteur.
Communiquer sa pensée par le langage, de surcroît par écrit, nécessite des qualités de
l’émetteur du discours, mais cela nécessite également des qualités du destinataire.
Le second motif est lié aux filtres que le destinataire va mettre, de manière inconsciente,
dans le décodage du message.
Le destinataire va apposer plusieurs filtres dans sa lecture pouvant entraîner, malgré lui, des
faux-sens et des contresens.
Le premier filtre est constitué par ses connaissances, son interprétation de la terminologie
employée par le rédacteur dans le cadre de son propre vécu et de ses compétences.
Le second filtre correspondra à ses propres croyances, liées à sa culture et à son éducation
personnelle, qui l’amèneront à accepter ou rejeter certaines visions des choses.
■ Le cahier des charges fonctionnel peut néanmoins présenter, avec rigueur
et précision, l’essentiel de l’expression du besoin
La rigueur et l’aspect systématique de la pratique de l’analyse fonctionnelle externe vont
permettre de présenter de manière claire la plupart des attentes de la maîtrise d’ouvrage.
La prise de conscience du risque d’incompréhension ou d’erreurs dans la compréhension va
amener à être modeste dans l’objectif à atteindre, mais rigoureux dans la démarche
d’expression du besoin.
L’objectif n’est pas d’obtenir de nombreuses offres, mais des offres bien ciblées par rapport
au besoin exprimé.
Rédiger un cahier des charges, après avoir établi soigneusement un tableau d’analyse
fonctionnelle, sera une tâche assez aisée.
Cette démarche permet de scinder en deux la difficulté de l’exercice.
Pour la réalisation du tableau, on pratique une démarche intellectuelle d’analyse à l’aide de
fils conducteurs permettant d’obtenir une certaine exhaustivité.
Pour la rédaction du cahier des charges, on pratique une démarche de synthèse, permettant
d’éclairer le contexte global de l’expression du besoin et reliant les fonctions attendues,
exprimées de manière ponctuelle dans le tableau précédent, au sein une logique commune.
La pratique de plus en plus courante consiste d’ailleurs à annexer le tableau d’analyse
fonctionnelle externe au cahier des charges.
b) Le tableau d’analyse fonctionnelle servira également lors du dépouillement
des réponses à l’appel d’offres
Le tableau permettra de sélectionner les offres en pointant la présence et le niveau des
fonctions attendues dans les différentes offres reçues.
a) La première colonne de ce tableau permettra de classifier les fonctions par type.
b) La seconde permettra de les numéroter, afin de les repérer plus facilement.
c) La troisième colonne permettra de définir le contenu de la fonction, par un descriptif
précis du résultat attendu.
d) Le caractère impératif permettra de préciser si l’on peut se passer ou non de cette
fonction dans la solution, qui sera retenue.

188
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

e) Le niveau atteint permet de préciser la manière de réaliser cette fonction et le niveau


d’approfondissement de la solution recherchée, c’est-à-dire de préciser l’expression du besoin.

EXEMPLE
Concernant la fonction édition d’un bulletin de paie dans un logiciel de traitement des salaires, on
pourra préciser que l’on souhaite une édition de masse, mais également la possibilité d’un traitement
à l’unité, y compris entre deux période de paie, pour un salarié quittant l’entreprise. On peut souhaiter
pouvoir choisir un critère d’édition comme le service ou la catégorie de salariés.

f) La classe de flexibilité permet de définir la flexibilité d’une fonction par rapport à son
coût d’obtention.
1.4 La rédaction du cahier des charges
Rédiger le cahier des charges va permettre de contextualiser l’analyse fonctionnelle et de lui
donner du sens.
Le tableau précédent offre une vision très analytique du besoin. Son but est de ne rien
oublier et d’offrir par la suite une grille de lecture des offres
Le cahier des charges doit permettre aux destinataires qui le liront de comprendre le
contexte de l’expression du besoin et doit leur offrir une vision globale et cohérente de la
problématique de la maîtrise d’ouvrage, dans son expression de besoin et sa recherche d’un
outil pour le satisfaire.

LES RISQUES À ÉVITER DANS LA RÉDACTION DU CAHIER DES CHARGES

Type de risque Caractéristique

Inversion des rôles Confondre maîtrise d’ouvrage et maîtrise d’œuvre.

Confusion analyse fonctionnelle interne et externe Confondre expression du besoin et solutions techniques.

Confusion entre contraintes techniques Les contraintes s’imposent car elles sont liées
et environnementales et choix techniques au contexte, les choix son réducteurs.

Il faut donc éviter un certain nombre d’écueils dans cette rédaction.


a) Le premier risque consiste à inverser les rôles
Pour une maîtrise d’œuvre, cela consiste à essayer d’exprimer le besoin de la maîtrise
d’ouvrage. Cela arrive fréquemment lorsque le cahier des charges est rédigé par le service
informatique de l’organisation et non par les utilisateurs. On confond alors un rôle d’assis-
tance à maîtrise d’ouvrage, que peut tenir le service informatique, et le rôle de la maîtrise
d’ouvrage, qui est le titulaire du besoin à satisfaire. En aucun cas, la maîtrise d’œuvre ne
peut se substituer à la maîtrise d’ouvrage.

EXEMPLE
Lorsque vous achetez un véhicule automobile, vous n’apprécierez pas un vendeur vous expliquant que
le meilleur modèle pour vous est le coupé sport, si vous venez de lui exposer que vous avez une petite
famille comportant deux jeunes enfants. Votre besoin de déplacement en famille vous orienterait
plutôt vers un modèle spacieux avec hayon. Ce vendeur n’est pas très à l’écoute de son client, mais

189
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

cette situation est fréquente. Ce cas se produit encore plus fréquemment et de manière plus insidieuse
en matière de système d’information, car la situation est beaucoup plus complexe. Mais ce que l’on
accepte pas dans un cas, ne doit pas être accepté non plus dans l’autre.
b) Le deuxième risque consiste à confondre expression du besoin
et solution technique à mettre en œuvre pour le satisfaire
Dans la rédaction d’un cahier des charges, la maîtrise d’ouvrage a pour mission d’expliquer
son besoin à la maîtrise d’œuvre potentielle, le plus précisément et le plus clairement
possible. Elle ne doit pas essayer de définir une solution sur le plan technique, car elle n’en
a pas la compétence et ne serait pas dans son rôle.

EXEMPLE
En matière de sécurité de votre véhicule automobile, vous souhaitez disposer d’un système de freinage
fiable qui permette, quelles que soient les circonstances, d’arrêter le véhicule sur la distance la plus
courte et en conservant la trajectoire choisie. Vous avez entendu parler de systèmes tels que l’ABS et
l’ESP. Cela ne fait pas de vous un spécialiste des problèmes à résoudre en matière de freinage. Par
exemple, un des problèmes consiste dans le refroidissement des freins, car l’échauffement excessif des
plaquettes de frein les rend inefficace. C’est un problème à résoudre par la maîtrise d’oeuvre et non par
la maîtrise d’ouvrage. Celle-ci doit se contenter d’exprimer son besoin en matière de freinage,
instrument essentiel de la sécurité du véhicule.

c) Le troisième écueil consiste à confondre contraintes environnementales


et contraintes techniques avec des fonctions techniques
Il ne faut pas étendre les prescriptions techniques à des domaines non impératifs. Cela
entraînerait un appauvrissement de la réponse aux appels d’offres. Cela ferait peut-être
passer à côté de solutions plus adaptées que celles qui seront proposées, suite à l’appel
d’offres. Il ne s’agit pas pour la maîtrise d’ouvrage de faire étalage de sa culture informa-
tique.

EXEMPLE 1
Si le système doit être implanté dans un environnement industriel sensible aux perturbations électro-
magnétiques, il est indispensable de le noter en tant que contraintes techniques dans le cahier des
charges, afin d’orienter les offres vers des solutions, en matière de réseau, adaptées à un environ-
nement perturbé (recours à un câblage en fibre optique au lieu d’un câblage métallique, par exemple).

EXEMPLE 2
Si les investissements antérieurs ont porté sur le choix d’une plate-forme, en termes matériels de
système d’exploitation ou de moteur de bases de données, on peut souhaiter pérenniser ces investisse-
ments. Il faudra préciser ces contextes dans le cahier des charges. Cela permettra de limiter les offres,
pour le nouveau produit recherché, sur les plates-formes qui assureront cette pérennité.

EXEMPLE 3
Par contre, il est inutile de préciser la structure exacte d’un écran de saisie des commandes. Le contenu
en termes de nature des informations est important, mais la forme doit être laissée libre, pour obtenir
une diversité de propositions. Il en est de même en ce qui concerne le choix d’une version de moteur
de base de données ou de système d’exploitation. C’est d’autant plus vrai qu’en la matière, les durées
de vie sont courtes et font généralement l’objet d’une compatibilité ascendante.

190
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

2. La gestion des appels d’offre


a) Le choix des destinataires
Gérer les appels d’offres consiste tout d’abord à en choisir les destinataires.
Deux cas de figure vont se présenter.
1) Le cas des marchés de gré à gré pour les entreprises privées ou, en dessous d’un certain
seuil, pour les organisations publiques, soumises aux règles des marchés publics. Dans le cas
des marchés de gré à gré, il faut choisir les destinataires de l’appel d’offres auxquels sera
transmis le cahier des charges. Un bon cahier des charges n’est pas celui qui va entraîner un
très grand nombre de réponses. Si la définition du besoin est suffisamment précise, seules
les entreprises qui possèdent le savoir-faire ou le produit qui correspond bien aux besoins
se manifesteront et répondront à l’appel d’offres.
Deux types de risques existent à ce niveau :
– le premier risque dans le choix des destinataires consiste à être imprécis et à obtenir une
masse de réponses très difficile à dépouiller et à traiter ;
– le second risque consiste à envoyer l’appel d’offres à des destinataires mal ciblés, qui ne
correspondent pas exactement à la nature du besoin exprimé.

EXEMPLE
Dans une industrie agroalimentaire, le responsable qualité recherchait un outil logiciel permettant de
faire du contrôle de remplissage de bouteilles par pesée. Cette opération devrait être réalisée à l’aide de
balances électroniques et de micro-ordinateurs en réseau, positionnés près des lignes de condition-
nement des bouteilles. Il souhaitait que le système s’intègre dans son système de gestion de production
et plus précisément, dans son système de gestion de la qualité. Dans un premier temps, il a envoyé son
cahier des charges à des fabricants de balances électroniques qui avaient développé, autour de leur
système de pesée, des logiciels permettant de faire des cartes de contrôle. Bien évidemment, il a été
déçu des réponses obtenues, car aucune d’elles ne permettait l’interopérabilité avec son système de
gestion de production, d’analyses de laboratoire et de gestion de la qualité. Il a donc dû refaire un
nouvel appel d’offres, ciblé cette fois de manière à obtenir une solution plus intégrée.

Il arrive fréquemment que les organisations soient amenées à renouveler leurs appels
d’offres. Dans la plupart des cas, cela vient du fait que les destinataires de l’appel d’offres ne
sont pas bien choisis lors du premier envoi, parce que la maîtrise d’ouvrage n’a pas une
vision claire de la nature du besoin qu’elle exprime. Elle fait alors appel à des prestataires
dans des domaines qui sont voisins, mais pas ciblés sur l’expression de son besoin. Il est
nécessaire, avant d’envoyer l’appel d’offres, de se poser la question de la nature exacte de la
demande que l’on est en train de formuler, et d’analyser quels sont les spécialistes qui
pourraient offrir une réponse à la demande.
On peut s’aider à ce stade de recherche sur Internet, notamment le site du CXP. Ce site
recense et analyse les offres de progiciels dans tous les domaines.
WEB CXP – http://www.cxp.fr/
2) Dans le cas des marchés publics, il est nécessaire d’adopter une démarche très précise avec
des procédures différenciées suivant le montant et la nature du marché. Cela agit peu sur le
cahier des charges fonctionnel en lui-même, mais sur les modalités de l’exécution de l’appel

191
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

d’offres et sur les mentions du cahier des charges général, qui inclut le cahier des charges
fonctionnel.
b) Le dépouillement des réponses aux appels d’offres
Comment utilisera-t-on le tableau d’analyse fonctionnelle dans le dépouillement des
réponses aux appels d’offres ?
■ Le cas des offres de progiciels
Rappelons qu’un progiciel ou programme produit constitue une offre standard.
WEB Progiciel
S’il s’agit d’une offre de progiciel, on cochera les fonctions présentes dans le produit
proposé par rapport à celles attendue dans le tableau. On veillera à ce qu’aucune fonction à
caractère impératif ou très importante ne soit absente d’une solution qui retiendra
l’attention. Toute solution ne répondant pas à cette exigence sera rejetée d’emblée. Les
autres feront partie de ce que l’on appelle la liste réduite, c’est-à-dire la liste des produits
pour lesquels la démarche commerciale sera approfondie. Pour ces offres, on envisagera
une démonstration et une négociation.
■ Le cas des logiciels spécifiques
S’il s’agit d’une démarche de réalisation d’un logiciel spécifique, toutes les fonctions du
cahier des charges devraient se retrouver dans le produit proposé. Celui-ci sera développé
spécifiquement pour répondre à l’expression du besoin. Néanmoins, il est possible que les
offres reçues dépassent le budget octroyé pour la réalisation du logiciel. Dans ce cas, la
colonne de flexibilité au coût permettra de trancher et d’éliminer toutes les fonctions plus
ou moins coûteuses, qui disposent d’une flexibilité importante. Ce sont des fonctions dont
on peut se passer ou des fonctions que l’on peut obtenir différemment.

EXEMPLE
On peut souhaiter avoir un système de sauvegarde automatique intégré à l’application. Si son coût
entraîne un dépassement de budget, on peut y renoncer car ce sera une fonction flexible et on trouvera
une solution externe pour automatiser les sauvegardes de l’applicatif.

192
PRATIQUE 1
FICHE

LES OUTILS DE LA DÉCOMPOSITION CARTÉSIENNE

Dans la deuxième partie de son Discours de la Méthode, René Descartes explique que, pour
appréhender une quelconque réalité, il faut diviser chaque chose en éléments simples afin d’en
maîtriser la compréhension, de les ordonner et de dénombrer les éléments pour s’assurer de ne
rien omettre. WEB René Descartes

Les objectifs de la décomposition :


– ne rien omettre des résultats à obtenir pour garantir que l’objectif global soit atteint ;
– constituer des lots de résultats et de tâches homogènes, qui pourront faire l’objet de commandes
à des prestataires, fournisseurs internes ou externes pour réalisation. Chaque lot devra être
confié à un prestataire unique responsable de sa réalisation, vis-à-vis du chef de projet.
Trois étapes de décomposition sont à réaliser.
1. LE PBS, PRODUCTS BREAKDOWN STRUCTURE
Il fournit une décomposition sous forme d’organigramme des résultats partiels à obtenir pour
atteindre le résultat global objectif du projet. Un résultat élémentaire dans l’organigramme sera confié
à un seul prestataire, chargé de sa réalisation. Ce type de décomposition visant à ne rien omettre suivra
un raisonnement logique et non chronologique. Les branches de premier niveau correspondent à des
axes de réflexion de la décomposition liés au métier ou à la nature du projet. Le degré de décompo-
sition, ou granularité de la décomposition, dépendra du degré de visibilité du chef de projet.

PBS - ORGANIGRAMME PROJET

(000)
Mise en place
logiciel X

(100) (200) (300)


Cahier des charges (400)
Moyens techniques Logiciel Formation
fonctionnel

(210) (220) (410) (430)


(110) (130) (310) (330) Exploitation (420)
Site central Rapport Cahier des Installation Utilisation
Site clients charges Modifications base de Paramétrages
d’audit de l’IHM
données
(120) (320)
Réseau Paramétrage

193
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

2. LE WBS, WORK BREAKDOWN STRUCTURE


Il fournit la décomposition, sous forme d’organigramme, des tâches à effectuer pour obtenir les
résultats du PBS. En dehors du fait que cet organigramme porte sur les tâches et non sur les
résultats, il se construit de la même manière que le précédent, en appliquant les mêmes
principes. Le nombre de tâches étant généralement plus important que le nombre des résultats
à obtenir, l’organigramme de décomposition sera présenté par niveau sous forme de plusieurs
documents successifs.
Le WBS constitue les données de base de la planification. Il faudra y ajouter la chronologie et la
durée des tâches pour réaliser un ordonnancement en PERT Temps et la gestion des ressources
pour passer en PERT Coût.
Le niveau inférieur comportant les tâches élémentaires constituera les tâches du graphe
d’ordonnancement et les niveaux supérieurs permettront de matérialiser la notion de tâches
récapitulatives.

WBS – ORGANIGRAMME DES TÂCHES


mise en place des moyens techniques – niveau 2

Mise en place des


moyens techniques

Mise en place Mise en place Mise en place


du site central du réseau des sites clients

WBS – ORGANIGRAMME DES TÂCHES


mise en place du logiciel X – niveau 3

Mise en place
logiciel X

Mise en place
du site central

Installation Paramétrage Installation Installation du


matérielle du système du logiciel moteur de base
du serveur d’exploitation partie serveur de données

194
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

3. L’OBS, ORGANIZATION BREAKDOWN STRUCTURE


Ce document se présentera sous forme d’un tableau permettant de définir, pour chacune des
tâches du WBS, les ressources à mettre en œuvre, avec leur rôle, leur durée de travail et leur coût.

Tâches Ressource 1 Ressource 2 Ressource 3


Niveau 1 du WBS Niveau 2 du WBS Niveau tâche
élémentaire du
WBS
Tâche Tâche Tâche élémentaire Quantité de Quantité de Quantité de
récapitulative de récapitulative de ressource ressource ressource
niveau 1 niveau 2 Durée de travail Durée de travail Durée de travail
Rôle Rôle Rôle
Coût Coût Coût
Mise en place des Mise en place Appel d’offre pour Service Chef de projet
moyens du site central le serveur informatique 1 personne
techniques 1 personne 1 jour
5 jours Rôle =
Rôle = Production Certification
Mise en place des Mise en place Installation du Service Chef de projet
moyens du site central serveur informatique 1 personne
techniques 2 personnes 1 jour
3 jours Rôle =
Rôle = Production Certification
Mise en place des Mise en place Évaluations Service Chef de projet
moyens des postes clients des besoins informatique 1 personne
techniques 2 personnes 1 jour
2 semaines Rôle =
Rôle = Production Certification
Mise en place des Mise en place Commandes Service Chef de projet
moyens des postes clients des postes informatique 1 personne
techniques 1 personne 1 jour
1 jour Rôle =
Rôle = Production Certification
Mise en place des Mise en place Installation Service Chef de projet
moyens des postes clients des postes informatique 1 personne
techniques 3 personnes 2 jours
1 mois Rôle =
Rôle = Production Certification

Le modèle de tableau ci-dessus appelle les commentaires suivants


• L’organigramme du WBS (Work Breakdown Structure) présente souvent plusieurs niveaux
Les niveaux supérieurs constitueront ce qu’il est convenu d’appeler des tâches récapitulatives et
le niveau feuille, les tâches élémentaires. Afin de faciliter le passage du tableau de l’OBS à un
logiciel de planification, il est conseillé de prévoir autant de colonnes de présentation des tâches
que de niveau dans l’organigramme du WBS.

195
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

• Il existe plusieurs manières de définir et de gérer les ressources


Les ressources peuvent être gérées de manière individuelle (M. X, Mme Y) ou par rôle (informa-
ticien, chef de projet, comptable…). Dans le cadre de la mise en place de la méthode projets, qui
nécessite une gestion commune des ressources pour l’ensemble des projets, la seconde solution
est préférable. La première solution présente un intérêt par rapport à l’interaction avec les
agendas partagés et les messageries électroniques. Par contre, elle sera gênante dans la consoli-
dation des projets, car elle ne permettra pas de gérer la polyvalence des acteurs.
• Quantification des ressources disponibles
Pour chaque ressource, on possédera une information de quantité, en nombre ou en
pourcentage (3 maçons, 20 % de chef de projet utilisateur…). Si la quantification décimale
paraît plus naturelle, elle sera source d’erreurs dans la planification ultérieure. Il est préférable
d’avoir recours à une quantification en pourcentage. Pour deux personnes à plein temps, on dira
200 % et non 2. Pour une personne à 10 % de son temps on dira 10 % et non 0,1.
• Détermination des durées de travail
Pour chaque ressource, on déterminera la durée de travail requise pour la tâche. La durée de
travail d’une ressource est différente de la durée de la tâche en elle-même. Il peut y avoir des
temps d’attente (délai de livraison, par exemple) qui rallongent la durée de la tâche, mais ne
nécessitent pas de travail. Le coût de l’utilisation de la ressource sera donc fonction de son temps
de travail et non de la durée de la tâche en elle-même.
Chaque ressource jouera un rôle dans le cadre de la réalisation d’une tâche
Les rôles définit habituellement sont :
• R : la Responsabilité sur la tâche

EXEMPLE
– Le directeur informatique est responsable du respect du délai pour la fourniture d’un livrable dans le
cadre d’un développement de logiciel.

• P : la Production de la tâche et du résultat qui en constitue l’objectif

EXEMPLE
– le service informatique développe une fonctionnalité dans un logiciel ;
– l’entreprise de maçonnerie monte les murs de la maison.

• S : le Support dans la réalisation de la tâche constitue un apport de conseil dans un domaine


technique

EXEMPLE
– le service informatique offre un support technique pour la mise en place d’un progiciel ;
– le service juridique apporte son assistance dans la rédaction du cahier des charges.

• C : la Certification de la tâche consiste à garantir que les moyens mis en œuvre correspondent
à ceux qui étaient prévus

196
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

EXEMPLE
– le groupe de revue de projet certifie que les moyens mis en œuvre correspondent au cahier des
charges ;
– le chef de projet certifie à la livraison la correspondance avec la commande passée.

• À : l’Approbation définit l’adéquation entre le résultat obtenu et le résultat attendu

EXEMPLE
– le comité de pilotage du projet approuve un résultat obtenu ;
– les utilisateurs effectuent la recette fonctionnelle du logiciel.

Le coût spécifié pour l’obtention d’une ressource nécessaire à la réalisation d’une tâche
Il peut être :

• Un coût fixe à l’utilisation de la ressource.

EXEMPLE
L’achat d’un « équipement fait l’objet d’un devis et la facture sera à régler aux conditions prévues,
après la livraison.

• Un coût variable, proportionnel au temps de travail, tenant compte d’éventuelles heures


supplémentaires à un taux majoré.

EXEMPLE
Le coût des trois maçons présents sur le chantier pour monter les murs de la maison sera proportionnel
à la durée de travail nécessaire. De plus, si, pour éviter un retard par rapport aux autres corps de
métiers ou pour éviter des intempéries annoncées, il est nécessaire de faire travailler les maçons en
heures supplémentaires, le coût de l’heure de travail va être plus élevé, compte tenu du tarif majoré des
heures supplémentaires.

197
PRATIQUE 2
FICHE

RÈGLES DE BASE POUR L’UTILISATION D’UN OUTIL INFORMATIQUE


D’ORDONNANCEMENT DES TÂCHES

La conduite et la gestion de projets, notamment si l’on souhaite mettre en place la « méthode


projets », nécessitent l’utilisation d’un outil informatique pour permettre :
– aux chefs de projets, de planifier et de gérer leurs projets ;
– et à la direction de projets, de disposer d’une vision de synthèse de l’ensemble des projets en
cours et de leurs besoins en ressources.

1. MÉTHODOLOGIE D’UTILISATION D’UN OUTIL DE PLANIFICATION


Les développements qui suivent s’appuient sur l’utilisation de MS Project de Microsoft.
La fenêtre de MS Project présente une ergonomie classique dans le cadre de l’interface utilisateur
graphique Windows. Elle est constituée d’un menu déroulant et d’une barre d’outils qui offrent
des icônes d’accès aux fonctionnalités du logiciel. Parmi celles-ci, on retrouve les icônes
habituelles de tous les outils de la suite logicielle MS Office, en ce qui concerne les fonctions
standard, telles que les manipulations des fichiers ou les fonctions d’impression. On trouve
également des icônes spécifiques du domaine fonctionnel de MS Project.
La fenêtre principale de MS Project de décompose de la manière suivante :
– la partie gauche, appelée la Table, se présente comme un tableau, où seront affichées les
données, avec différents types d’informations disponibles,
– la partie droite, présente la planification, résultant des données saisies, sous forme de graphe Gantt.
Elle fait apparaître :
1) Les jalons, tâches de durée nulle représentées par un losange matérialisant cette notion, essen-
tielle en conduite de projet, que sont les points de décision.
2) Les niveaux de tâches récapitulatives, représentés par des barres noires qui correspondent aux
niveaux du WBS. Elles permettent, pour les gros projets, d’obtenir un effet de « zoom avant »
(vue détaillée) concernant les tâches en cours et de « zoom arrière » (vue synthétique)
concernant les tâches passées ou futures.
3) La durée de réalisation des tâches est matérialisée par des barres, tandis que les délais
d’attente ou marges, sont représentés par des traits. Suivant la mise en forme sélectionnée, les
tâches critiques peuvent apparaître en rouge, tandis que les tâches non critiques apparaissent
en bleu.

198
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

En mode suivi du projet, le pourcentage de réalisation des tâches apparaîtra sous forme d’un
trait noir incrusté dans la barre de la tâche.

L’ordonnancement des tâches dans le cadre de la « méthode projets » implique une réflexion sur
certains concepts de base, ayant des incidences sur la manière de paramétrer et d’utiliser les outils.

2. LA NOTION DE TEMPS ET DE CALENDRIER


La notion de temps et la mesure du temps sont des notions imprécises. Que veut dire, par
exemple, qu’une semaine de travail est nécessaire pour réaliser une tâche ? Est-ce 35h, 39 h ou
7 jours de 24 h, comme dans certaines industries dites « à feu continu » ?
Pour gérer les projets, il est donc nécessaire de définir le calendrier de l’organisation, qui sera
partagé par tous, afin d’avoir une mesure du temps commune, qui tienne compte de la réalité de
l’organisation.
On peut également définir des calendriers spécifiques pour les différentes ressources. Il est
important de savoir qu’une entreprise, qui intervient sur un chantier, est fermée au mois d’août.
Cela risque de rallonger la durée des travaux d’un mois. Mais jusqu’où faut-il aller ? Est-il
justifié, par exemple, de gérer les agendas de chacun pour tenir compte de la RTT ?
Il faut considérer qu’un logiciel d’ordonnancement de tâches, qui aide à planifier et à suivre
l’exécution des projets, n’est pas un logiciel pour gérer les agendas de chaque individu.
La définition d’un calendrier de l’organisation permettra de faire figurer pour l’ensemble des
projets :
– les horaires hebdomadaires de travail ;
– les fermetures pour congés ;
– les jours fériés.

199
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

EXEMPLE
Le chef de projet doit travailler 10 % de son temps sur une tâche, dont la durée de réalisation est de
deux semaines. Le logiciel affectera le chef de projet 10 % de son temps de travail quotidien, tous les
jours que dure cette tâche. Dans la réalité, celui-ci n’interviendra que pour lancer la tâche le premier
jour, ce qui l’occupera toute sa journée, et pour faire le bilan de la réalisation le dernier jour, ce qui
l’occupera tout l’après-midi. Cette répartition sera gérée sur son agenda et ne sera pas prise en compte
par le logiciel de planification du projet.

3. L’UTILISATION DE L’ALGORITHME PERT ET LES OUTILS DE CONDUITE DU PROJET


Le logiciel est fondé sur l’application de l’algorithme du graphe PERT. Il présente le dérou-
lement possible du projet sous forme de diagramme de Gantt, de manière préférentielle, pour
des raisons de lisibilité du graphe. En conséquence de l’application d’un algorithme d’ordon-
nancement des tâches, tel que le PERT, il ne permet pas la superposition conflictuelle des tâches.
Il n’est pas destiné non plus à la gestion de l’agenda détaillé des ressources, dans le cadre de
l’exécution d’une tâche particulière.
Au niveau de la mise en application du PERT Temps par le logiciel, le but est de permettre au
chef de projet de planifier, afin de faire apparaître les tâches critiques et d’arbitrer les dérives de
planning qui remettraient en cause la durée globale du projet.
La mise en application du PERT Coût permet d’offrir au chef de projet des outils d’affectation
des ressources, afin de respecter le budget et d’arbitrer les dérives. Lors de la réalisation du

200
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

projet, il pourra choisir les tâches offrant la possibilité d’une accélération au moindre coût, tout
en permettant le maintien du délai global du projet.
À cette fin, on agira sur les tâches critiques. Rappelons que les tâches critiques sont celles dont la
date de réalisation qui peut être atteinte au plus tôt dans la mise en œuvre du projet est égale à la
date à laquelle elles doivent être réalisées au plus tard, pour respecter le délai global de réalisation
du projet. Ce sont donc des tâches sur lesquelles le chef de projet ne dispose pas de marge de
manœuvre, qui n’entraînent pas d’incidence sur la durée du projet en lui-même. Sur les chemins
critiques, qui sont constituées d’un enchaînement de tâches critiques, le chef de projet ne
dispose :
– ni d’une marge totale, qui représente la marge de manœuvre disponible sur un chemin, c’est-
à-dire de l’ensemble des tâches le constituant, dans le graphe du projet. Cette marge peut être
consommé par une ou plusieurs tâches du chemin ;
– ni d’une marge libre, qui représente la marge de manœuvre d’une tâche considérée seule.
Cette marge libre apparaîtra au niveau d’une tâche non critique se positionnant sur la fin d’un
sous-chemin.
4. LE PILOTAGE PAR LA DISPONIBILITÉ DES RESSOURCES
Le logiciel peut permettre de piloter la réalisation par la disponibilité des ressources. Cela signifie
qu’il ajustera de manière automatique la planification afin d’éviter que la prévision d’utilisation
d’une ressource par le projet n’excède sa disponibilité.
Il évite ainsi, de manière automatique, une prévision d’utilisation d’une ressource au-delà de ses
disponibilités et ne rend pas nécessaire l’analyse des sur utilisations potentielles par le chef de
projet. La durée de réalisation du projet s’en trouve rallongée, s’il y a sur utilisation potentielle
de certaines ressources, mais il n’y a pas à réaliser d’ajustements et d’arbitrages manuels.
Dans la gestion des projets, cette méthode est rarement pertinente. D’une manière générale, il
n’est pas efficace de laisser les arbitrages au logiciel, alors qu’il ne dispose pas de tous les
paramètres d’une situation complexe. C’est d’autant plus le cas pour un logiciel de planification
de projet, qui a une vision macroscopique de la réalisation des tâches.

201
2 CHAPITRE 4 – La conduite et la gestion de projet
PARTIE

Le tableau d’affectation des ressources permet de définir pour chaque tâche :


– les types de ressources nécessaires ;
– leur pourcentage d’utilisation pendant la durée de réalisation de la tâche.

L’histogramme d’utilisation des ressources fait apparaître les éventuelles sur utilisations.
Celles-ci sont calculées par rapport à la disponibilité de la ressource, telle qu’elle a été déclarée
dans le tableau de définition des ressources des projets. Dans l’exemple ci-dessus, le chef de
projet a été affecté à 30 % de son temps au projet. Dès qu’il passe au-delà des 30 %, il apparaît
en sur-utilisation. Ici on voit deux journées où la tâche nécessitera son intervention à 100 %. Le
logiciel considère donc qu’il y a sur-utilisation. Cependant en termes d’organisation du poste de
travail du chef de projet, cette exigence est peut être tout à fait gérable dans la mesure où le projet
ne le sollicite pas du tout le reste de la semaine.

EXEMPLES
1) Reprenons l’exemple du paragraphe précédent. Imaginons que le chef de projet soit positionné en
sur-utilisation d’1 heure par jour le jeudi et le vendredi de la première semaine de réalisation de la
tâche. Le logiciel va décaler la réalisation de cette tâche afin d’éviter la sur-utilisation. En fait, le chef
de projet n’interviendra pas sur cette tâche ces jours là, le problème n’existe donc pas concrètement
dans la réalité. Il est donc inutile de décaler la tâche. De plus, le logiciel sera sans nuance. Une sur-utili-
sation d’une heure peut être acceptable sans problème pour le chef de projet. Par contre, une sur-utili-
sation qui le ferait travailler plus de 24 h la même journée est totalement impossible. Il est donc
préférable, par principe, de laisser les arbitrages au planificateur et non au logiciel.
2) Imaginons deux manières de définir les ressources du service informatique. Dans la première
solution les deux informaticiens chargés de l’assistance aux utilisateurs, Pierre et Paul, sont gérés en
tant que ressource individuelle. Le fait que Pierre soit en sur-utilisation ne signifie pas nécessairement
qu’il faille décaler une tâche. Il faudra d’abord vérifier la disponibilité de Paul.

202
CHAPITRE 4 – La conduite et la gestion de projet 2
PARTIE

5. LES CHOIX À EFFECTUER POUR PILOTER LES TÂCHES


Le logiciel offre des aides à la planification. Notamment, il permet de planifier par rapport à la
date de début ou à la date de fin du projet. Il offre la possibilité d’affiner les choix de planification
pour chaque tâche. On peut ainsi choisir de réaliser une tâche en date au plus tôt ou au plus tard,
ou bien encore en précisant de manière impérative une date de début ou de fin de la tâche.
Par rapport à ces différentes possibilités, il est nécessaire de définir une méthodologie commune
dans l’organisation, qui fera l’objet d’une procédure et d’une formation des chefs de projet
potentiels.
De manière générale, on peut remarquer que, bien que la contrainte porte en général sur la date
de fin du projet, ou date butoir, il est plus facile de planifier par le début du projet. En effet, il
sera impossible de remonter dans le passé, si on constate que le temps disponible pour réaliser le
projet est insuffisant par rapport à la date butoir. Dans ce cas, il faudra rechercher la possibilité
d’accélérer la réalisation du projet au moindre coût. Il est donc préférable, dans la démarche
mise en œuvre, de planifier à partir du début du projet, afin de constater l’éventuel dépassement
de délai par rapport à la date butoir.
6. SAISIE INITIALE SANS PLANIFICATION
On peut également préciser qu’il est nécessaire de pratiquer de manière itérative et incrémentale
dans la planification d’un projet. C’est pourquoi la saisie initiale dans le logiciel doit être
enregistrée, au cours de la saisie, sans planification. Le suivi des modifications de planification
fourni par le logiciel correspondra par la suite à des modifications de plannings lors de
l’exécution du projet, et non à des ajustements ou des corrections d’erreurs lors de la phase de
saisie de la planification initiale.
Dans le cadre de cette démarche itérative, il est préférable, dans un premier temps, de planifier
la réalisation des tâches en dates au plus tôt, de manière à avoir une première vision globale des
chemins critiques et des nécessités éventuelles d’accélération de tâches.
Ensuite, il sera possible d’affiner la démarche. Ainsi, on pourra remettre les tâches corres-
pondant à des investissements en date au plus tard, afin d’éviter d’avancer inutilement la tréso-
rerie ou de faire courir une période de garantie, alors que le matériel ne peut pas encore être
utilisé.
On pourra également gérer certaines tâches avec des dates impératives, comme les comités de
pilotage des projets ou des réunions de suivi de proje