Stratégie

Catalogue des services de la DSI : obligatoire, lisible et rendant l'utilisateur heureux

De gauche à droite : Jean-Luc Couasnon (Accenture), Jean-Claude Bellando (Axway), José Diz (animateur), Jean-Marc Defaut (HP) et Anas Safia (Econocom-Osiatis).

Lors d'une table ronde organisée par le Club de la Presse Informatique B2B et réunissant Accenture, Axway, Econocom-Osiatis et HP, les bonnes pratiques pour créer un catalogue de services IT ont été éclaircies.

Publicité« Le shadow IT représente, en moyenne selon notre estimation, au sein des grandes organisations publiques ou privées, 40% du coût IT total » a relevé Jean-Luc Couasnon, responsable conseil en infrastructure chez Accenture. Il s'exprimait le 14 janvier 2015 dans le cadre d'une table ronde organisée par le Club de la Presse Informatique B2B et réunissant, Accenture, Axway, Econocom-Osiatis et HP.
Si le DSI se doit de garantir la solidité et la sécurité du « château fort IT », il ne doit pas bloquer l'innovation, bien contraire. Il lui faut donc permettre les usages qui sont recherchés par les utilisateurs de shadow IT mais en sachant poser des règles. Cela va notamment être le rôle d'un bon catalogue de services, d'autant que les utilisateurs humains ne sont plus seuls à consommer des services IT à l'ère des objets connectés.

Cependant, certains outils peuvent très bien être laissés hors du périmètre de la DSI, typiquement les outils sociaux utilisés par la direction marketing (Twitter, Hootsuite, etc.). Cela peut aussi être le cas pour des usages particuliers à condition de respecter l'architecture générale.
Jean-Luc Couasnon cite ainsi un exemple : « dans beaucoup de grandes entreprises, la recherche et développement possède son bac-à-sable sur une infrastructure gérée par la DSI. » Dans ces cas, on ne peut pas vraiment parler de shadow IT puisque tout le monde est d'accord pour laisser ces outils hors du contrôle direct de la DSI, y compris la DSI elle-même.

Face au Shadow IT coûteux et dangereux, répondre par un catalogue de services

Mais, dans beaucoup d'autres cas, des outils sont achetés ou utilisés par des collaborateurs de l'entreprise en dehors de toute politique de la DSI. Voire en infraction avec la politique de la DSI ou du RSSI. Il en résulte d'une part un surcoût plus ou moins invisible dans le contrôle de gestion de l'entreprise lié à l'achat discret de services extérieurs (via les notes de frais par exemple), d'autre part un risque sur la sécurité ou la confidentialité des entreprises.
Par exemple, il ne peut pas être question de laisser des documents confidentiels qui doivent circuler uniquement entre collaborateurs être hébergés dans un cloud grand public (genre Dropbox ou Google Drive). Mais le DSI ne peut pas interdire l'usage d'un service d'échange ou de stockage de documents lourds, usage métier incontestablement indispensable.

« Si quelqu'un a une tâche à faire, quoiqu'il arrive, il va prendre les outils dont il estime avoir besoin pour accomplir sa tâche » assure Jean-Claude Bellando, Directeur Solutions Marketing d'Axway. Face à cette nécessité, soit le DSI fournit un outil adéquat (et dans ce cas il peut interdire efficacement l'usage d'un outil non-conforme) soit l'utilisateur prendra le risque d'employer un service externe, même interdit. Jean-Claude Bellando juge donc que « le DSI doit offrir l'infrastructure et avoir la souplesse d'accepter des services disponibles sur le marché s'il n'est pas en mesure d'en proposer l'équivalent. Si ce service externe ou public est dangereux, il doit en proposer un équivalent interne ou privé. »

PublicitéCela passe par un catalogue de services IT lisible par l'utilisateur final. Mais pas seulement.

Le magasin d'applications, une concrétisation du catalogue de services

« Dans l'entreprise comme dans le grand public (avec l'exemple de l'Apple AppStore), l'offre lisible créé la demande » indique Jean-Claude Bellando. Si l'utilisateur n'a pas d'effort à faire pour utiliser un service interne dont il a le besoin, il le consommera. Jean-Claude Bellando insiste : « la simplicité est la clé ».
Bien sûr, il faut que le service proposé réponde au besoin réel. Jean-Marc Defaut, directeur cloud computing d'HP France, s'offusque d'une mauvaise pratique encore fréquente : « il est absurde de proposer des VM avec tel OS dans un catalogue de services. Un utilisateur métier ne sait pas ce qu'est une VM ou un OS et un informaticien a besoin non pas d'une machine virtuelle mais d'un environnement de test ou de développement, avec un certain nombre de paramétrages, d'outils et de services. »

Au delà de la seule simplicité, « il faut donc construire avec les utilisateurs, profil par profil, le catalogue des services dont il va avoir réellement besoin, en sachant qui va utiliser quoi » stipule Anas Safia, Practice Manager Cloud chez Econocom-Osiatis. Une fois ce listage opéré et les briques construites, il faut alors mettre en place les outils pour industrialiser, orchestrer, contrôler et garantir un niveau de service. Un service, pour être ainsi qualifié, doit en effet avec une disponibilité définie.
Jean-Marc Defaut observe : « les services mis au catalogue doivent être estimés selon quatre critères, à savoir : la valeur rendue, le prix/le coût, le délai et -il ne faut pas l'oublier- le plaisir. Il faut que l'utilisateur ait du plaisir à utiliser le service, avec une expérience similaire à ce qu'il aurait en usant d'un service proposé en mode public : sexy, rapide, joli, etc. »

ITIL : ni Gémonies ni Empyrée

Le concept de catalogue de services a été popularisé par le référentiel ITIL. Mais, bizarrement, les intervenants n'ont pas évoqué ce référentiel spontanément. « La mise en place d'une démarche de type ITIL ou d'API aux applications précède la création du catalogue de services en lui-même » justifie Jean-Claude Bellando. Pour Jean-Marc Defaut, « quand le but de l'industrialisation est de passer d'une délivrance d'un service de sept semaines à une heure, on a bien sûr tendance à passer outre un dogme bureaucratique qui exige que l'on passe par 852 étapes. »
D'autres concepts à la mode ne sont pas plus épargnés par les intervenants. Par exemple, l'agilité ou le DevOpps sont plutôt vus comme des mots-clés vendeurs. « Il faut d'abord une stratégie claire avant de se poser la question du comment dans les détails » martèle Jean-Luc Couasnon.