L'informatique d'entreprise doit revoir ses missions

Le démarrage de la nouvelle année budgétaire donne aux directions informatiques d’entreprise l’opportunité de faire le point sur leurs « fondamentaux » par rapport à l’environnement économique des entreprises et aux stratégies d’investissement dans les technologies de l’information. Dans des budgets de plus en plus contraints, l’investissement dans les technologies de l’information ne fait plus rêver et est soumis à une analyse de plus en rigoureuse. Comment pourrait-il en être autrement ? A quoi servent les ressources financières confiées aux DSI ? Quelle est l’utilité des multiples projets qui nourrissent le portefeuille de projets ?

Ces questions sont légitimes et appellent une gouvernance de plus en plus stricte de l’allocation des ressources dans les systèmes d’information dont les directions des systèmes d’information elles-mêmes doivent prendre le leadership. Il s'agit bien en effet de sortir d'une logique de "services votés", mue par l'inertie de la gestion du parc applicatif qui absorbe de plus en plus de ressources pour entretenir des volumes d'activité et de services croissants, pour dégager les moyens de gérer des projets de rupture qui apportent aux processus méteur un nouvel oxygène de créativité et d'ambition. Le poids de l'histoire informatique tire vers le passé et entretient des modes opératoires souvent dépassés. Or les technologies, et la puissance de l'internet en entreprise étendue, conduisent à imaginer des processus et des modèlés d'affaire nouveaux inconcevables sans l'apport de ces outils.

Tout le monde a retenu l’article de Nicholas Carr, en mai 2003, « IT doesn’t matter ». L’auteur* a habilement tiré parti de l’émoi suscité par ce texte, jugé aussi agressif qu’erroné par la plus grande partie de la profession, éreinté par Bill Gates, pour développer sa thèse dans un livre "Does IT Matter? Information Technology and the Corrosion of Competitive Advantage", qui promet à l’informatique d’entreprise le même sort que l’électricité au début du XXe siècle, découverte scientifique majeure devenue utilité industrielle totalement banale, et donc non différenciatrice. Puisque investir dans l’informatique ne crée pas d’avantage compétitif, il faut donc limiter strictement les dépenses ! Cet appel à la frugalité n'est pas resté sans écho dans les conseils d'administration des firmes utilisatrices, tout en désespérant l'industrie des technologies de l'information. La voie de la raison conduit à un jugement plus nuancé, mais surtout implique de revisiter les habitudes souvent simplement budgétivores d'une profession qui a parfois négligé de se remettre en cause.

Cette thèse volontairement réductrice, centrée sur les seules infrastructures, fait peu de cas de la dimension applicative de l’informatique. Si le mouvement de rationalisation des infrastructures ne fait pas de doute, c’est aujourd’hui dans le domaine applicatif que le que la complexité résiste, héritière d’années de développement informatique « bottom up » sans projet global, sans architecture d’ensemble des données. Ce foisonnement applicatif a conduit les informaticiens au fil des années à construire des interfaces multiples dont l’entretien se révèle complexe et donc coûteux, et cet édifice fragile de technologies et d’outils de générations différentes est délicat à exploiter dans les conditions de fiabilité aujourd’hui exigées en entreprise.

Si simplifier les infrastructures est une tâche légitime pour les informaticiens, même si elle n’est pas tout à fait naturelle, remettre en cause le patrimoine applicatif est une tâche d’une autre ampleur. L'informatique sait construire, à coups de projets, mais n'a pas encore encore appris la rénovation urbaine qui impose de détruire intelligemment. Cette entreprise de rénovation implique le soutien des utilisateurs et des propriétaires de processus et suppose la mobilisation d’importants moyens de reconstruction de ces applications pour produire un environnement de travail plus rationnel, plus stable et plus fiable. La qualité et l’agilité sont désormais plus importants dans ce modèle que la réponse instantanée à des « besoins clients » routiniers et mal évalués.

Cette démarche vise à actionner simultanément trois leviers d’action :
- supprimer les applications coûteuses, inefficaces, peu utilisées, inadaptées au nouveau contexte métier, pour alléger le parc applicatif et technique et dégager des moyens nouveaux par simple redéploiement,
- faire cesser la complexification inutile du portefeuille applicatif par une démarche d’urbanisme volontariste qui s’appuie sur les standards et les référentiels,
- (re)construire différemment, plus vite et moins cher, en exploitant le potentiel des nouvelles technologies, l’interface internet et les architectures orientées service (SOA).

Cette transformation est lourde de conséquences. Elle remet en cause le traditionnel travail en projets isolés, pour promouvoir les composants réutilisables et donc une mise en commun le plus en amont possible. Elle conduit la maîtrise d’ouvrage à réfléchir à une nouvelle approche de ses besoins, moins court termiste et volatile, pour construire de vrais composants métiers, robustes, pérennes et inter-opérables. Bien entendu, la compétence des architectes, chefs de projet et développeurs doit être revisitée car ce modèle est exigeant.

Mais l’enjeu est majeur : apporter au business un support créatif, rapide et de qualité tout en réduisant les budgets. Certes cette nouvelle équation paraît presque trop idéale, conceptuelle. Il faut la confronter à l'épreuve des faits - "proof of concept" - en passant sans délai de la théorie à la pratique.

* http://www.nicholasgcarr.com/articles/matter.html Voir un grand nombre d’articles développant la controverse autour de la thèse de Nicholas Carr.