|
Stic Hebdo : Urbaniser le
système d’information d’une entreprise ou d’une institution, comment peut-on
définir cette activité ?
Michel Volle. Je vais
vous répondre avec un exemple vécu dans une
grande institution. L’idée directrice était de donner une « portée de
phare » de cinq ans aux discussions budgétaires, d’avoir une vue précise pour
l’année suivante et des données globales pour les autres années. Le plan ainsi
élaboré serait revu chaque année, parce que même si les phares éclairent devant,
la route, elle, tourne !
Il faut d'abord se faire une
idée de la manière dont est construite l'entreprise elle-même. Pour cela, on la
découpe en grands domaines de production de
valeur, dont les frontières correspondent souvent à peu près à celles des
grandes directions. On distingue :
- la production tournée vers l'extérieur (attention à ne pas la mesurer par le
nombre des dossiers traités ou des personnes passées au guichet; on risque de se
gargariser de volumétries sans signification réelle),
- la production tournée vers l'intérieur et autoconsommée (ressources humaines,
informatique, fonctions de support).
Ensuite, à l'intérieur de
chacun de ces grands domaines, on identifie les processus de production, ce qui
suppose que l’on identifie d’abord les produits eux-mêmes. Dans le tertiaire, il
n'est pas toujours évident de savoir ce que sont vraiment les produits ; et dans
l’industrie, qui produit des biens, on a trop souvent tendance à négliger les
services qui leur sont associés (avant et après-vente, commercialisation).
Le déroulement du processus
d'analyse, en lui-même, fait souvent apparaître un certain nombre de "petits
problèmes" (par exemple la circulation des documents techniques internes, ou la
qualité des procédures administratives). Il met aussi en lumière un certain
nombre de beaux actifs, par exemple des nomenclatures bien faites. Ou il repère
des possibilités, comme celle de transformer un répertoire des personnes en un
outil d'authentification et d'habilitation exploitant les profils que contient
l'annuaire des personnels.
On répertorie et on trie, avec
les maîtrises d'ouvrage, les besoins des divers métiers. Cela permet d’aboutir
au calendrier de développement des nouveaux outils informatiques. En parallèle,
avec la DSI, et dans la même perspective temporelle, on élabore un plan
d'urbanisme technique (administration, sécurité, middleware, dimensionnement des
mémoires, processeurs et réseaux...). Enfin on s'astreint au travail, un peu
laborieux, de mise en cohérence des calendriers fonctionnel et technique pour
s'assurer qu'à telle date on aura bien, par exemple, le débit des réseaux et le
middleware permettant le déploiement de telle fonction sur l'ensemble des postes
de travail.
S.H. : A l'origine, dans
l'idée d'urbanisme des systèmes d'information, il y avait aussi l'idée de
renoncer à un grand système intégré comme on en rêvait depuis les années 1970.
D'un point de vue fonctionnel, on laissait une large autonomie à chaque
direction opérationnelle (avec sa maîtrise d'ouvrage), et on allégeait les
échanges de données. Du point de vue technique, on renonçait à un système
transactionnel unique pour faire coopérer plusieurs systèmes d'information par
des échanges asynchrones (du type MOM, Message oriented management). Ces
concepts sont-ils toujours pertinents ?
M.V. On a compris,
depuis l'apparition de ces idées au début des années 1990 (**) qu'il était
trompeur et dangereux de pousser trop loin la métaphore de l'urbanisme avec ses
rues et ses quartiers. Ce qui importe, ce sont les
processus de production, leurs échanges
mutuels et notamment les contraintes de synchronisme. Le concept d'application a
perdu de sa pertinence. Il est trop lié à une analyse en termes d'algorithmes.
Ce qui importe aujourd'hui, ce sont les services que l'on déclenche pour
traiter des données encapsulées dans des objets, le tout pour
outiller les processus de production. Ceux-ci doivent-ils par exemple
coopérer en temps réel (transactionnel) ou supporter l’asynchronisme de la
messagerie ? Ce sont là des points du plan d'urbanisme qu'il faut documenter
avec précision et qui seront déterminants par la suite pour la réalisation
technique.
Il y a une dizaine d'années, on
parlait de Java, Corba et UML. J'ai vu que des
utilisateurs de base, mobilisés comme experts du métier pour participer à la
modélisation, pouvaient au bout de
quelques semaines parler en « UML natif » et maîtrisaient suffisamment ce
langage plutôt technique, pour présenter brillamment les processus de leurs
directions à la direction générale. Cela m’a donné confiance dans le réalisme de
ce langage.
On parle plutôt, aujourd'hui,
d'EAI (Enterprise Applications Integration), de services Web et de SOA (Services
Oriented Architecture). Les SOA et les Web services me semblent fournir une
bonne solution, à condition de les restreindre au périmètre de l'entreprise et
de ne pas prétendre monter une de place de marché où l'on pourrait se procurer,
en temps réel, n'importe quel service sur le Web ! En pratique, cela revient
toujours à installer dans l’entreprise un commutateur (ou un bus) qui traite les
problèmes de transcodage, de synchronisme et de traçabilité entre les diverses
bases de données et les divers algorithmes de traitement dont dispose
l’entreprise... Ce commutateur doit être capable de router les messages en
fonction de leur adresse, de les transcoder, ainsi que de les mettre en mémoire
éventuellement pour les réexpédier plus tard, de gérer les files d’attente etc.
Il existe différents types de
plans d'urbanisme. La solution peut consister à intégrer des applications jusque
là séparées (je pense par exemple à une prise de commandes d'une part et à une
logistique de livraison de l'autre).
Une des difficultés réside dans
la prise en compte de l'héritage (« legacy »). Sur ce point, le passage de l'an
2000 (dont les risques étaient bien réels, quoiqu’on dise) a été l'occasion
d'un mise en ordre des applications anciennes, dont on avait parfois perdu le
code source (ou dont on ne savait plus si le code source correspondait à la
version effectivement employée).
On peut considérer un processus
comme un moteur qui tourne et qui propulse l’entreprise. Certains tournent très
vite (traitement des demandes de raccordement à un réseau télécom, des lettres
de réclamation, des réservations de places dans les théâtres etc.) : sur
ceux-là, on peut faire la volumétrie, placer des indicateurs, faire des
statistiques sur les délais de traitement, etc., ce qui permet de contrôler le
respect de certaines des contraintes de qualité. D’autres tournent beaucoup plus
lentement (préparation du budget annuel, révision du plan d’urbanisme etc.), et
les contraintes de qualité s’expriment et se gèrent autrement.
Il y a une différence
essentielle entre back-office et front-office. Le back-office traite des
documents qui sont déjà formulés dans le langage de l’entreprise ; le
front-office, lui, est confronté au vocabulaire d’un interlocuteur externe et il
doit donc accomplir un travail de traduction, de codification dans le langage de
l'entreprise. Il n'est pas maître non plus de l'ordre dans lequel se déroule la
conversation. L'outil fourni à l’opérateur du front-office doit lui permettre de
jongler avec les diverses fonctions sans perdre le fil de la conversation.
Un utilisateur du système
d’information est quelqu'un qui lit, écrit et lance des traitements. Il faut
donc lui fournir à tout moment une interface qui comporte les plages de lecture,
les plages de saisie et les boutons pour lancer les traitements, le tout
correspondant exactement à son activité. Ni plus, ni moins. C'est facile à dire,
mais extrêmement difficile à réaliser. Cela implique la suppression des doubles
saisies et des déconnexions/connexions pour sortir d'une application et rentrer
dans une autre (avec parfois l'obligation de se ré-identifier et ré-habiliter),
ainsi que l’uniformisation des touches de fonction, onglets et menus déroulants.
Le problème de double saisie se
trouve parfois, aujourd'hui, reporté sur les interlocuteurs externes de
l'entreprise. Je connais un cas où le client communique avec l’entreprise par
quatre canaux différents : le service présentiel, fourni en agence par un
opérateur qui dispose d'un PC connecté, le courrier postal, le site web et le
centre d'appel téléphonique. L'harmonisation de ces services est souvent
difficile car ils relèvent de responsables différents qui peuvent avoir des vues
opposées, voire se trouver directement en conflit.
Le service informatique risque
d’ignorer les difficultés que rencontrent les utilisateurs parce qu'il n'est pas
sur le terrain. L'informatique d'une grande entreprise a parfois tendance à
vivre pour elle-même. Par exemple (je l'ai vu !) en se réservant les bonnes
adresses de courriel. Ou en sélectionnant les projets en fonction de la
disponibilité des équipes ou de son désir d'explorer telle ou telle technologie
nouvelle. Quand la DSI exagère dans cette sorte d'autisme, la direction générale
et les directions opérationnelles se décident à monter une maîtrise d'ouvrage.
Cela fournit à l’entreprise un dipôle dont la pression fait avancer les choses.
Il y faut un engagement personnel du directeur général.
Enfin, le
tableau de bord du comité de direction est la
cerise sur le gâteau du système d'information (ou, pour les amateurs de
métaphores, c'est le coq en haut du clocher du village : il indique le sens du
vent...). J'ai vu des présidents recevoir chaque mois des dizaines de tableaux
de bord, incohérents et tous incompréhensibles... en tant que statisticien et
ancien conjoncturiste, je me suis souvent demandé comment ils pouvaient
interpréter des données aussi mal construites. En fait, ces tableaux de bord
sont inutilisables mais, conscients des problèmes politiques que pose la
construction d'un bon tableau de bord, ils hésitent à imposer les mesures
nécessaires. Il faut en effet distinguer la comptabilité du contrôle de gestion,
qui doit s’appuyer sur un raisonnement économique et donc oser produire des
estimations alors que la comptabilité y répugne. Un bon tableau de bord, c'est
un ensemble léger, comportant un petit nombre d'indicateurs bien choisis,
vérifiés et éventuellement redressés, sous forme de séries corrigées des
variations saisonnières, accompagnés d’un bref commentaire en français naturel
pour signaler les points importants.
S.H. : Dans une ville, un
plan d'urbanisation exige toujours la recherche d'un consensus, des arbitrages
et des négociations. Je suppose qu'il en est de même pour l'urbanisation du
système d'information...
M.V. ... Bien sûr. La
discussion du plan d'urbanisme en comité de direction est d’ailleurs rarement
d'une parfaite clarté, ne serait-ce qu'en raison de l'obscurité des données
budgétaires (dotations non totalement consommées, projets en cours, projets
nouveaux...). L'urbanisme oblige à des négociations difficiles parce que,
contrairement à un ensemble d'immeubles, un SI ne se voit pas, ou ne se voit
qu’à travers la fenêtre étroite d'un écran toujours partiel. La représentation
visuelle d'un SI ne peut s'acquérir qu'à force de l’étudier et de le fréquenter.
Et elle est très difficile à partager.
Il faut savoir faire valoir des
avantages (vous allez gagner des clients à tel endroit, votre centre d'appels va
enfin être apprécié des utilisateurs...), et surtout ne jamais faire de
démonstration. Face à un dirigeant ou à un comité directeur, la démonstration
est la pire forme d'argumentation, contrairement à ce qui se passe dans un cours
de maths. Dans l'entreprise, démontrer quelque chose, c'est faire violence au
libre arbitre des interlocuteurs ; ils n'auront alors qu'une chose en tête: vous
donner tort. Mais il faut parfois avoir le courage de dire que si l’entreprise
viole la logique elle viole la nature elle-même, et que celle-ci se vengera…
L'urbanisme peut procurer à
ceux qui le pratiquent des sensations esthétiques fortes. Je pense à des
innovations architecturales comme la mise en place d'un moteur d'identification
des clients permettant de fonder des analyses marketing et de personnaliser le
service. J'ai parfois éprouvé une vraie souffrance à ne pas parvenir à faire
partager cette beauté, cette utilité qui me semblaient évidentes et qui
restaient inaccessibles à la compréhension d'une direction générale polarisée
par la maîtrise des coûts. Cette même DG, d’ailleurs, tolérait que persistent
dans le SI des anomalies stupéfiantes dont l’analogue, en termes d’architecture,
serait un escalier qui débouche dans le vide, une pièce murée ou jamais
personne ne va, etc.
Il arrive aussi qu’une
direction opérationnelle refuse de dépendre d'une autre (par exemple, le système
d’aide à la décision ne veut pas dépendre de la direction statistique). Chacun
veut maîtriser un système complet qui lui soit propre. C’est un peu comme si
chaque immeuble parisien devait comporter ses quatre murs, avec 50 centimètres
d'écart entre les immeubles, et s’alimenter en eau par un puits creusé au milieu
de la cour ! Et l’exigence de coopération, de solidarité ne se limite plus
aujourd'hui aux services internes à une entreprise. Il faut prendre en compte
les sous-traitances et l’interopérabilité avec d'autres entreprises. Ici
l’urbanisme confine à la politique, car chaque partenaire pense d'abord à
assurer son autonomie et à défendre étroitement ses intérêts propres.
Propos recueillis par Pierre
Berger, avec la coopération des membres du Club de l'Hypermonde ainsi que de Guy
Lapassat, qui ont participé à la réunion où est intervenu Michel Volle.
(*) Le
club des maîtres d'ouvrage des systèmes
d’information
Le club est un lieu où les
maîtres d'ouvrage peuvent échanger leurs pansements/pensements, si je puis dire.
Cela fait du bien de savoir que l'on n'est pas seul à souffrir ! Et aussi, plus
positivement, de coopérer pour construire. Le club a donné la priorité à la mise
au point des méthodes et à la professionnalisation de la maîtrise d’ouvrage.
Qu'est-ce qu'un bon maître d'ouvrage ? Que doit il savoir en informatique ? Que
doit-il savoir en organisation ? (il est à la charnière des deux mondes). Que
doit-il savoir faire en matière de "manipulation" (pour la bonne cause) ? Le
club monte des formations avec trois universités qui auront son label. Le club
compte actuellement une trentaine de membres, appartenant plutôt au secteur
tertiaire (banque, assurance, opérateurs de télécommunications, fonction
publique). L'industrie, en fait, est un autre monde ; ses systèmes d’information
sont physiquement plus compliqués, mais du point de vue sociologique et humain
leur urbanisme est moins difficile à concevoir et à partager. |
