La DSI dispose de moyens pour structurer un système d'information avec des technologies comme les portails, les Enterprise Service Bus (ESB) et l'Identity and Access Management (IAM). Ces technologies jouent un rôle fédérateur : les utilisateurs accèdent aux applications via un portail d'entreprise (intégration par rendu XML, iframes, portlets locaux ou distants, portlets indépendants ou communicants...). Les applications internes ou partenaires accèdent aux services par un ESB d'entreprise (intégration  par registre, transformation de messages, orchestration...).  Les accès sont sécurisés par une solution d'IAM qui offre des services techniques configurables (signature, chiffrement, authentification, autorisation...).

Largement fondées sur des standards et sur le paradigme d'architecture orientée services (SOA), ces technologies sont maintenant disponibles dans des produits qui prennent en compte capacité de montée en charge et haute disponibilité.

Où en sont portails, ESB et IAM dans le SI d'aujourd'hui ? Mon retour d'expérience : on en parle beaucoup et on en déploie peu. Certes ces technologies d'intégration ne sont pas sans un ticket d'entrée important en termes de coût global. Les standards n'offrent pas d'entrée le niveau de fonctionnalités idéal, et les produits ne sont pas d'entrée parfaitement rodés.

Mais cela suffit-il à expliquer qu'on ne les trouve que dans des utilisations tactiques locales et non là où elles apportent leur vraie plus value, le niveau stratégique fédérateur à toute l'entreprise ? Je pense que le frein à une utilisation stratégique est plus largement lié à une relation entre la DSI et les métiers entachée de conflits historiques, organisationnels et politiques et qui se résument en un non-alignement entre coûts de l'IT et fonctionnalités offertes.

La DSI promeut un SI agile où la réutilisabilité est au cœur des applications et où le concept de service métier est structurant. Forte de la maturité des technologies d'intégration, elle évangélise les services réutilisables tout en minorant la difficulté clé de l'agilité : l'identification et la gouvernance des services métier.

Pour cadrer cette difficulté, les projets s'organisent autour de méthodologies formelles qui ne remplacent pas un travail laborieux mais nécessaire : la modélisation du domaine, fruit du dialogue entre spécialistes métier et analystes. Pour exemple, je vous cite deux applications sur lesquelles j'ai travaillé à la fin des années 90 : un "exécuteur" et un "ordonnanceur" de procédures d'opération satellites, développées parallèlement, aux standards du moment (MVC, serveur C++, client Java, API de services en Corba). Arrive un appel d'offres dans lequel les deux applications doivent être couplées. Temps estimé par nos équipes IT pour monter ce service : 6 mois ; temps à l'arrivée : 18.

Les scénarios de couplage entre les deux applications ont été plus complexes que prévus. En conséquence, des interfaces et des structures internes des deux applications ont été changées. En RPC, en Corba, en Web Services, via un portail ou un ESB, combiner des services reste un problème théorique qui n'a pas diminué en complexité depuis. Quand la DSI dit que A et B vont former C en 2 temps 3 mouvements alors que cette combinaison tisse indirectement des liens "sociaux" au travers d'un contrat aussi rigide qu'un appel de fonction dans un contexte d'exécution précis, elle se décrédibilise auprès des métiers.

La DSI promet aussi un SI où la mutualisation de l'infrastructure est un facteur d'amélioration de la qualité des services délivrés aux métiers. Dans cette architecture, le portail, la solution IAM et l'ESB deviennent des points de passage obligés pour atteindre les services des différents métiers de l'entreprise. Alors que ces services ont une organisation et une infrastructure parfaitement définies avec des responsables métiers et techniques et des composants dédiés, le triptyque Portail/IAM /ESB arrive avec une gouvernance non maîtrisée.

Cette zone de flou terrorise les responsables métiers qui campent sur leur positionnement historique, le silo, avec les réflexes "je ne partage rien ; je ne dépends de rien ; je contrôle tout". Quand un service est en production et apporte 80% du CA d'une société, il est difficile à l'IT de recommander au métier concerné de positionner un ESB en front end avec des utilisateurs supplémentaires sans penser aux effets de bord désastreux que cela peut engendrer. Sans preuves de performances (robustesse, disponibilité, capacité) et sans monitoring ni supervision d'un Service Level Agreement (SLA) rigoureux, l'IT a encore et toujours du mal à convaincre les métiers d'emprunter ces nouvelles couches de médiations jugées à risque.

C'est de bonne foi que la DSI propose un ESB ou un portail pour un accès centralisé et homogène aux ressources de l'entreprise en interne ou depuis l'extérieur. Mais quel est l'intérêt des métiers ? Ont-ils vraiment envi de collaborer ? Ont-ils même pensé à collaborer ? Mettre tous les services au même niveau en les banalisant dans un portail froisse ou frustre des sensibilités. Afficher ou mettre une information stratégique à disposition peut affaiblir un pouvoir.

Quand la DSI imagine que, puisque c'est techniquement possible, tout service est candidat à une mise à disposition, elle fait preuve d'une candeur bien technicienne et ignore que la composition de service est un exercice hautement politique.

Des pistes pour améliorer ce fossé entre IT et métiers, qui réduit l'adoption de technologies auxquelles je crois ?

Plus d'implication dans le métier et plus de démonstrations de la part de la DSI ! Je suis surpris de ces documents, présentations, plaquettes... produits en masse et que les métiers reçoivent à juste titre avec méfiance. L'agilité, la mutualisation et autres -té et -tion expliqués par du papier ne nous font pas déployer plus de portail ou d'ESB. Ces dissertations ne nous rendent pas meilleurs acrobates ou commerciaux ! Une particularité française que de pousser à la "conceptualisation" à outrance sans pragmatisme avant de passer à l'action (le cas échéant) ? Une maquette avec quelques services et portlets imprégnée d'éléments métier même simplistes est une amorce tellement plus efficace !

La DSI doit avoir un budget propre et doit l'investir à construire des infrastructures sur lesquelles on peut compter en termes (entres autres) de confidentialité, d'intégrité et de disponibilité. Un SLA contractualisé et contrôlé régulièrement (par tierce partie si le souci de neutralité est fort) obtient la confiance des métiers et du poids pour aller de l'avant vers une architecture fondée sur les technologies d'intégration.

Au coeur de l'entreprise et dans son rôle transverse, la DSI doit avec subtilité et diplomatie aider les métiers à dialoguer, à se décloisonner et à combiner l'information pour imaginer de nouveaux services à valeur ajoutée qui créditent la considération de toutes les parties prenantes.