RECHERCHE :
Bienvenue sur le site de Michel VOLLE
Powered by picosearch  


Vous êtes libre de copier, distribuer et/ou modifier les documents de ce site, à la seule condition de citer la source.
 GNU Free Documentation License.

Interview avec Pierre Berger
(Publié dans Stic Hebdo n° 52, 25 avril 2005)

7 avril 2005


Pour lire un peu plus :

- Urbaniser un SI
- A propos de la production
- Référentiels et annuaires
- Approche du SI par les processus
- Langage de modélisation UML
- A propos de la modélisation
- Histoire d'un tableau de bord
- Club des maîtres d'ouvrage des systèmes d'information

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.