Transformer la DSI : peut-elle disparaître ?

Où en est la réalité de la transformation du SI et de la DSI ?

La transformation de la DSI est un concept qui a déjà pas mal d'années et il s'est imposé au début des années 2000 : il fallait se transformer pour mieux répondre aux besoins des métiers ainsi qu'à la vitesse des marchés et des innovations. Les sociétés de services, les analystes et les cabinets de conseil ont abondamment utilisé le concept de SOA (service oriented architecture) et l'arrivée des multiples solutions "cloud" pour pousser encore les DSI à se transformer.

De multiples ouvrages et présentations ont convaincu de la nécessité de l'évolution profonde à la fois du système d'information et du rôle de la DSI. Mais qu'a-t-on réussi à achever véritablement ?

Des DSI aux grands moyens d'étude et d'investissement ont effectivement lancé de grands chantiers de transformation, plus ou moins réussis et plus ou moins aboutis. Bravo à celles qui ont réussi, même partiellement. Mais nous observons maintes entreprises de taille moyenne qui vivent un certain désarroi face à cette problématique. Elles font face à l'incompréhension et au manque de support des directions générales et des directions métiers, au manque de moyens d'investissement et parfois même au manque de compétences internes pour élaborer un tel projet.

Des appels à la sortie de la DSI

La charge cumulée du fonctionnement courant et des projets d'évolution met ces DSI "moyennes" dans une situation de tension et d'inquiétude. Viennent s'ajouter à cela les publications qui anncent régulièrement la disparition des DSI.

Un cabinet d'analystes leader du marché a publié plusieurs analyses relayant ce message depuis longtemps, sans que cela ait été vérifié dans les faits, et avec une argumentation qui n'a pas complètement convaincu.  Ce sont les articles d'acteurs plus "modestes" qui maintenant deviennent insistants sur non seulement la mort possible des DSI mais en plus recommandent aux métiers de s'emparer du développement des applications.

Voici des extraits d'un article récent d'un consultant américain relayé par un media de l'informatique  bien connu en France :

-      " Voici une idée radicale : fermez votre service informatique !"

-      " La solution consiste simplement à « extraire » le processus de développement d’applications du service informatique (la DSI), de sorte que le développement de logiciels fasse partie intégrante des activités quotidiennes de l’entreprise."

Et d'inciter tout à chacun à développer soi-même, "grâce aux plates-formes de développement PaaS" des applications en s'affranchissant de la DSI.

D'autres articles, dans toutes sortent de revues de l'industrie, incitent les métiers à se doter de solutions en mode SaaS, de façon "autonome".

Mais où sont passés l'architecte et les chefs de chantier ?

Ces articles poussent leur irresponsabilité à ne même pas mentionner le rôle de la DSI pour au moins s'assurer de l'architecture de l'ensemble, de la viabilité et de la compatibilité des solutions.

Certes nous avons tous critiqué la machine infernale qu'est devenu le SI (les SI monolithiques, les interfaces complexes, le manque de flexibilité), et l'esprit de chasse gardée et d'enfermement de certaines DSI, leur manque d'agilité, leur langage volontairement ésotérique vis-à-vis de leurs utilisateurs.

Entendu. Mais imaginez ce que serait un SI d'entreprise à base de solutions Saas choisies par les métiers sans concertation avec la DSI, des applications développées on ne sait selon quel processus et règles de qualité par des non-informaticiens, et implantées sur des clouds choisis sans avis de la DSI. Imaginez ainsi quelques exemples :

-      Une petite entreprise dont l'informatique est désormais constituée de 5 logiciels SaaS hébergés chez 5 éditeurs différents, 3 applications "maison" développées dans 3 clouds différents.

-      Une entreprise de taille moyenne dont le SI est désormais constitué de 20 applications SaaS dispersées et aux SLAs minimes ou inexistants, une dizaine d'applications développées par des non-informaticiens et implantés chez trois hébergeurs cloud différents sans contrat consistant, et … quelques systèmes anciens dont on a laissé la garde à la bonne vieille DSI.

Puisque certains préconisent cette évolution, nous aimerions qu'ils nous expliquent :

-      Quels SLA ont été négociés avec chacun des opérateurs PaaS et SaaS ? Sont-ils harmonisés ? Et qui les auraient négociés ?

-      Quels standards de développement, quelles procédures de test, quels tests de robustesse et d'intégrité ?

-      Comment sont assurés les workflows d'échanges de données entre les applications ? Comment sont synchronisées les données ? Comment s'assure-t-on que les données clients, constamment changeantes, sont bien tenues à jour dans toutes les bases de données en temps réel ?

-      Comment assure-t-on ce qu'étaient capables de faire les EAI ?

-      Quel ETL sait extraire des données de multiples logiciels SaaS qui ne donnent pas accès à leur structure de base de données ? Et ainsi comment construit-on une solution de BI efficiente ?

-      Comment intègre-t-on des utilisations SaaS avec les applications anciennes ("legacy") sans revenir aux multiples et complexes interfaces que l'on a cherché à réduire ces vingt dernières années ?

-      Que deviennent les investissement faits sur des approches comme ITIL ?

Voici une anecdote, réelle. Une entreprise a retenu une solution SaaS pour sa logistique et la gestion de ses transports. A ma question "Ce logiciel ne devrait-il pas être connecté à votre ERP ?", on me répond "L'éditeur SaaS propose de déposer chaque soir un fichier plat Unix dans Dropbox" ….

Tout cela conduira un SI anarchique, non maitrisé, comme si l'on pouvait construire un immeuble sans architecte, sans plan et sans chef de chantiers.

Réaffirmer le rôle d'architecte et de chef d'orchestre de la DSI

On ne nie pas tout l'intérêt des solutions SaaS, ni celui des espaces de développements rapides sur des PaaS. Mais la construction du SI ne peut se faire que sous la maitrise d'un architecte – la DSI –   qui doit garantir, grâce à ses orientations et ses recommandations de choix de solutions :

-      La compatibilité des choix techniques.

-      La fluidité, l'intégrité et la rapidité des flux d'informations et des évènements au sein du SI.

-      L'homogénéité des standards techniques.

-      L'homogénéité et l'efficience des processus de développement et d'exploitation.

-      Le test, la sécurité et la robustesse des applications.

-      L'efficacité des processus d'industrialisation et de mise en production.

-      La viabilité et la pérennité des solutions commerciales choisies.

-      La viabilité et la solidité des contrats d'externalisation.

-      Des engagements de service homogènes et satisfaisants pour les métiers.

Parce ce que la DSI ne peut plus tout réaliser, parce que les métiers veulent davantage de latitude dans le choix de leurs solutions, et parce que le marché offre des solutions robustes et économiques, alors la DSI doit accepter d'adapter son rôle. Mais elle doit conserver et renforcer son rôle d'architecte et concepteur du SI, de garant de la qualité, de la performance et de la sécurité du SI, de garant des standards, de chef d'orchestre des différentes externalisation.

SOA ne s'est sans doute jamais autant justifié

Puisqu'il faut faire évoluer le SI et utiliser à bon escient les nouvelles opportunités, alors le grand principe d'architecture qu'est SOA (service oriented architecture) prend toute sa valeur. En effet :

-      Une architecture de type SOA garantit la solidité et la cohérence de l'édifice.

-      SOA permet de résoudre les questions d'interface et workflows évoqué précédemment et l'intégration des systèmes "legacy", grâce au principe des Web services. Certes le travail de réalisation et mise en œuvre de ces Web services pour accéder aux "vieux systèmes" est conséquent, mais atteignable.

-      SOA permet l'intégration et l'orchestration de composants internes et de composants externalisés.

La tâche est immense

Maitriser SOA

Nombreux sont les livres, présentations et formations disponibles sur SOA. Peu d'entreprises sont parvenu à un SI "complètement SOA".  Le chantier de transformation du SI est énorme. Parmi les publications, certaines sont à la fois théoriques et enthousiastes (comme tous les nouveaux concepts informatiques nouveaux qui prétendent "résoudre tout"). Heureusement toutes celles qui fournissent des recommandations de mise en œuvre préconisent le pas à pas, les déploiements par étapes, par opposition aux bigs bangs  que les publications initiales pouvaient laisser entendre.

C'est un effort considérable sur le plan conceptuel, sur celui des formations nécessaires, de la vision du futur SI, des investissements nécessaires.

Faire adhérer à la vision de la future DSI

De sont côté la DSI doit appréhender le chantier de sa propre transformation sans sous-estimer :

-      La résistance au changement.

-      L'évolution considérable des métiers et des compétences.

-      L'acceptation de son nouveau rôle et de sa reconnaissance par le reste de l'entreprise.

Le sujet n'est pas clos, bien au contraire, l'itinéraire de l'évolution du SI et de la DSI va continuer dans la décennie qui vient.