|
On a pris l’habitude, en
France, d'appeler « DSI » le directeur chargé de la plate-forme
technique informatique et télécoms. Cet acronyme se déploie en « directeur
du système d’information » et parfois – comme si une entreprise
pouvait avoir plusieurs systèmes d’information – en « directeur des
systèmes d’information » au pluriel. Aux États-Unis, on le nomme
« CIO » (« Chief Information Officer »).
Il est malencontreux que l’on
ait donné un tel titre à celui qui dirige la maîtrise
d’œuvre du système d’information : le système d’information
n’est-il pas également l’affaire des métiers utilisateurs, ces maîtrises
d’ouvrage qui doivent le modéliser, le « spécifier », le définir
de façon pertinente en regard de leurs besoins ? les maîtrises
d’ouvrage ne sont-elles pas, à l’intérieur de l’entreprise, les « clients »
de la direction informatique ? le système d’information n’est-il pas
de la responsabilité conjointe de ses maîtrises d’ouvrage et de sa maîtrise
d’œuvre ?
Une crise
Mais laissons là les questions de
terminologie. Le DSI, puisque DSI il y a, est aujourd'hui en crise : sa
« durée de vie » diminue. Au milieu des années 90, un DSI restait
en fonction 4,7 ans en moyenne ; aujourd’hui, cette durée se réduit à
deux ans.
Le « turn over » est donc très rapide. L’entreprise n’est pas sûre
d’avoir, demain, besoin d’un DSI alors qu’il est (semble-t-il) si simple
d’externaliser l’informatique ou de recourir à des progiciels. La
fonction informatique se serait-elle banalisée ?
La « simplicité de
l’informatique », quelle illusion ! les illusions fleurissent lors
des périodes de transition, quand un changement de repères suscite le
désarroi ; et nous sommes dans une période de transition. Le rôle de l’informatique
dans l’entreprise s’est transformé à la fin des années 90, avec
l’introduction du traitement du langage naturel dans l’informatique
de communication, la fusion de la donnée et du commentaire dans
les documents XML, l’approche du système d’information par les processus
etc. Les outils se sont diversifiés, le discours commercial est devenu de
plus en plus séduisant (mais pas plus sincère). Les
directions générales, qui n'ont jamais été un repaire d'experts en système
d'information, sont complètement dépassées. Alors il est tellement reposant de croire que l’« outsourcing »
peut résoudre
tous les problèmes !
Définir les frontières
Bien sûr il peut en résoudre
quelques-uns. La direction informatique, tout comme l’entreprise dans son ensemble,
doit savoir modifier son périmètre. Quelles sont les tâches qu’il
convient de réaliser en interne ? celles qu’il vaut mieux confier à un
fournisseur ? quelles sont, parmi les spécialités selon lesquelles s'est
diversifiée la compétence de l'informaticien, celles dont on pourra rentabiliser
la formation et l’entretien au sein de la DSI, et celles que l’on devra se
procurer auprès des SSII, mieux placées pour les rentabiliser ? Faut-il
conserver quelques développeurs en interne, ou transformer la direction des études
en gestionnaire de contrats ? Parmi les logiciels dont
l’entreprise a besoin, quels sont ceux qu’il vaut mieux acheter sur étagère,
sous forme de « progiciels » ou même d’ERP, et quels sont ceux
qu’il est préférable de spécifier et de réaliser soi-même (ou de faire réaliser
sur mesures par des fournisseurs ?) Lorsqu’un produit est développé par
une SSII, comment se l’approprier, comment s’approprier les outils qui ont
servi à l’élaborer ?
Ces questions préoccupent le
DSI. Les solutions extrêmes sont inefficaces : tout développer
en interne serait absurde (que l’on pense au traitement de texte, aux tableurs).
Tout acheter sous forme de progiciels, de boîtes noires, serait risqué :
dans le cœur de métier l’entreprise a plus d’expertise que le
fournisseur d’ERP, il ne faut donc pas espérer que celui-ci puisse rendre le
service nécessaire. Mais dans la graduation qui s'étale entre ces extrêmes, où se trouve
la frontière raisonnable ?
Il est d’autant plus délicat
de la situer que ses paramètres sont évolutifs. La solution raisonnable
aujourd’hui ne le sera plus demain : la technique aura progressé, un nouveau
produit sera sorti, etc. Le DSI doit donc assurer une veille technologique.
Comment évolue l’offre des SGBD ? des EAI ? des ERP ? des
machines, réseaux, langages ? que penser (et faire) de Linux ? de XML ?
des Web Services ? de XQuery ?
Dans sa relation avec une innovation, le
DSI passe par des étapes. Tout d’abord il l’ignore parce qu’elle est née
loin de lui. Puis elle est portée à sa connaissance (les commerciaux sont à l'informatique ce que les visiteurs médicaux sont à
la médecine) : une alarme s’allume dans son esprit, mais il reste en
observation. Alors il lance une expérience à petite échelle pour voir comment cela marche et
faire acquérir par ses personnels un premier savoir-faire. Ensuite il
étudie la possibilité de l’utiliser dans l’entreprise : il en parle
au DG, la présente au CSSI, prépare l’investissement, forme ses personnels.
Enfin, l’innovation est introduite « en vraie grandeur » dans
l’entreprise. Parfois l'ensemble de cette démarche est rapide, parfois elle prend
des années. Comment faire pour ne pas prendre trop de risques tout en
évitant de se mettre en retard par rapport à l’état de l’art ?
comment faire pour ne pas être dupe d’un discours commercial toujours séduisant ?
Fonctionnement et ressources
humaines
Tout en réfléchissant
à ses frontières et en observant l’évolution technique, le DSI doit veiller au bon fonctionnement de l’informatique. Il est en effet à
la tête d’une usine qui ne doit jamais s’arrêter. Peu importe qu’un PC
se « plante » ici ou là, mais une panne générale serait une
catastrophe : les chaînes de production s’arrêtent, les files d’attente
s’allongent, les agents râlent tout en essayant de se débrouiller, les
clients s'énervent, l'image de l'entreprise en prend un coup.
L’architecture des mainframes, serveurs, routeurs, réseaux, doit donc être sécurisée,
robuste, supervisée en continu. Les informaticiens doivent être insérés
dans une organisation qui garantit la qualité de leurs travaux.
Or cette ressource humaine est
difficile à gérer : il s’agit d’une population de spécialistes et
les spécialistes sont toujours tentés de s’organiser en corporations
mutuellement hostiles. On trouve donc à l’intérieur de la DSI plusieurs sociologies ombrageuses :
les opérateurs qui font tourner les mainframes et les serveurs ; les développeurs qui écrivent les codes
et les chefs de projet qui pilotent les contrats
avec les SSII ; le support aux utilisateurs, dispersé sur le territoire
et dans des centres d’appel ; les administrateurs, les superviseurs ;
les hommes des
réseaux télécoms ; les responsables de la qualité, de la sécurité, des méthodes,
de l’architecture etc. Le DSI doit les recruter, les organiser,
arbitrer leurs conflits, faire prévaloir l'intérêt de l'entreprise sur celui
de leurs corporations.
Fournisseurs
L’architecture informatique,
c’est un ensemble de « solutions » qui chacune combinent des machines, réseaux, systèmes d’exploitation, logiciels et interfaces. Le choix d’une solution suppose d’évaluer, au milieu d’un
charivari commercial assourdissant, la qualité des « briques » qui
la composent, leur aptitude à s'intégrer, la réalité des performances, la pérennité des fournisseurs, la
viabilité des techniques.
Il faut savoir se faire
respecter des fournisseurs : comme tout fournisseur a dans son catalogue
quelques mauvais produits qu’il doit pourtant fourguer, et dans ses équipes
quelques mauvais ingénieurs qu’il doit pourtant caser, le client incompétent
sera
nécessairement mal servi. Pour
obtenir un service convenable le DSI doit connaître les fournisseurs,
comprendre les contraintes auxquelles ils sont soumis, savoir parler leur langage.
Maîtrises d'ouvrage
Le DSI est lui-même un fournisseur
pour les métiers de l’entreprises, les maîtrises d’ouvrage. Il doit percevoir leurs
besoins réels à
travers des demandes souvent non priorisées, confuses,
inflationnistes et versatiles. Sa tâche sera facilitée s’il a en face de
lui une maîtrise d’ouvrage professionnelle, capable d’exprimer des besoins
pertinents, sobres, cohérents, stables, de modéliser son système
d’information, fournir des spécifications claires, suivre les projets, former les utilisateurs, bref d’utiliser au mieux les ressources que
l’informatique lui apporte.
Il est vrai que la cohabitation
avec une maîtrise d’ouvrage professionnelle suppose une négociation d’égal à égal. Cela sera
parfois difficile pour le DSI car, pour se soulager des préoccupations que nous venons de décrire,
il peut être tenté par l’ivresse du pouvoir. Quiconque
dispose d’un budget annuel de quelques dizaines ou centaines de millions
d’euros, dont une bonne partie consacrée à des marchés, est la cible des
flatteries que prodiguent les fournisseurs (voir « Corruption
et honnêteté dans l'entreprise »). Soumis à l’alternance de cette
douche tiède et de la douche froide qui leur est administrée en comité de
direction, certains DSI deviennent susceptibles et irritables : le mauvais
caractère est chez les DSI une maladie professionnelle.
A chacun ses soucis ! la
maîtrise d’ouvrage a aussi les siens (voir « Servitude
et grandeur de la maîtrise d’ouvrage »). Il serait logique, et
certainement salubre, de faire en sorte que les budgets informatiques fussent
administrés par les maîtrises d’ouvrage, qu’il s’agisse des projets ou
des coûts de maintenance. Il est bon en effet qu’elles supportent le coût
de leur SI, puisque celui-ci est pour elles un actif comme les autres et
peut-être plus important que les autres. Mais cela ne pourra se faire que
lorsque les maîtrises d’ouvrages seront devenues assez professionnelles.
L'entreprise peut-elle se
passer du DSI ?
Revenons au DSI. Les
responsabilités que nous venons de décrire, sont-elles vides, négligeables ?
certes non. Les entreprises qui croient se débarrasser des difficultés de
l’informatique en faisant sauter leur DSI se font des illusions.
- Lorsqu’elles
signent un contrat d’« outsourcing », le fournisseur est tout
sourire ; mais bientôt elles découvriront que la relation avec lui est plus difficile que la relation avec une DSI interne, car il est
moins proche et se retranchera derrière le contrat en utilisant s'il le faut
toutes les
astuces de la procédure judiciaire.
- Lorsqu'elles accélèrent le « turn over »
des DSI, elles empêchent la capitalisation de l’expertise et dégradent le climat
chez les informaticiens.
- Lorsqu’elles se jettent à corps perdu dans les bras
d’un ERP (et, pourquoi pas, d’un EAI aussi pour faire bonne mesure), elles
s’engagent dans une démarche plus complexe qu'elles ne le pensent et dont elles auront tôt fait
de découvrir les coûts cachés.
Est-ce à dire qu’il ne faut
rien « outsourcer », qu'il ne faut jamais recourir aux ERP et EAI ?
certes non ! Mais il faut que quelqu’un sache définir avec précision la
frontière de ces prestations, les articuler avec l’architecture de
l’entreprise, négocier avec les fournisseurs et les utilisateurs, éclairer
la perspective sur les quelques années qui viennent, encadrer la population
ombrageuse des informaticiens : cela, c’est la tâche du DSI. Comment
l’entreprise pourrait-elle se passer de lui ?
|
