Le Shadow IT, le nouveau Far West de l’administrateur système

Les innovations de la base de données Postgres contribuent largement à éviter la complexité́ et les silos qui pourraient être créés par le Shadow IT.

M. Martin, directeur des Ventes, demande à son service informatique, d’avoir un espace de stockage plus important. Ce dernier lui a indiqué que sa demande a été enregistrée et prise en compte mais qu’elle ne lui sera accordée que dans 2 mois. Sa demande étant urgente et dans un souci de confort et d’efficacité, il passe outre sa DSI et décide d’utiliser Dropbox. Cette initiative, anodine pour certains employés est le berceau du Shadow IT encore appelé "IT fantôme".

Autrefois, chefs incontestés de l'infrastructure informatique, les administrateurs système deviennent de moins en moins populaires, particulièrement dans le Shadow IT. Beaucoup comparent le modèle de développement agile et les applications web au Far West, notamment parce que surgissent soudainement dans l'entreprise, des données structurées et non structurées qui n’ont pas reçues l'aval du DSI. Tout cela est un vrai casse-tête pour les entreprises car elles doivent faire face à des employés de plus en plus demandeurs de nouvelles technologies, surpassant les capacités de réponse de la DSI. En effet, ces « non-informaticiens » qui créent ces nouvelles applications le font, très souvent, dans une démarche positive afin d’être plus efficaces.

Selon une étude de CliperCloud1, près de 981 applications Cloud employées au sein des entreprises européennes ont été développées sans que les métiers n'en réfèrent à leur DSI. Gartner estime que d’ici 2017, 50% des données stockées sur des systèmes de gestion de bases de données NoSQL auront des répercussions sur les entreprises à cause de politique de gouvernance inadaptées. La cause principale réside dans le fait que les services informatiques créent une nouvelle génération de silos et des systèmes informatiques trop complexes, que les autres départements souhaitent contourner.

Contourner la DSI coûte que coûte...
Malheur aux administrateurs systèmes qui suggèreront la prudence ou l’ajout de procédures qui ralentiraient cette ruée vers le développement de nouvelles applications. Pour pousser encore plus l’analogie du cow-boy, ils sont assimilés à des étrangers indésirables entrant dans un saloon. J’exagère à peine car les relations entre les développeurs et les administrateurs informatiques se sont détériorées au fil du temps et tenter de rétablir la relation entre eux est un défi difficile à relever. Pour les premiers, le Shadow IT est une alternative pour disposer rapidement d'un produit/application qu'ils jugent indispensables car les seconds sont catalogués comme réfractaires au changement et sans aucune once de réactivité.

Les administrateurs système sont responsables et garants du maintien du flux de données, de la stabilité et l’intégrité IT de l’entreprise. Le battage médiatique autour de Hadoop et NoSQL a atteint son paroxysme, donnant le sentiment que les départements IT ont sacrifié les workflow pour démontrer à leur direction comment ils peuvent être agiles et réactifs. Pour la direction également la question est primordiale : doit-elle accepter avec fatalisme l'existence de cet "IT fantôme" contre lequel elle ne semble pas pouvoir lutter, sinon de quels moyens dispose t-elle pour l'éradiquer définitivement ? Cependant cela a mis en avant de nombreux défis que l’ensemble du service informatique devra relever. Par exemple, quelle base de données choisir et quel sera l’impact de son installation ?

Postgres au secours du Shadow IT
Les bases de données NoSQL stockent uniquement les données, elles ne les traitent pas. Les données doivent être acheminées vers les applications pour analyse. Ces dernières (et donc par conséquent chaque développeur d’applications) sont responsables des accès aux données, de la mise en œuvre de règles opérationnelles et de la cohérence des données. Bien entendu cela est compliqué car chaque base de données NoSQL utilise une représentation différente pour ses données et un langage distinct pour y accéder et les manipuler. Les entreprises se retrouvent ainsi avec plusieurs logiciels NoSQL incompatibles.

Les logiciels NoSQL ne supportent pas les procédures stockées et ne représentent pas qu’une seule technologie, inhibant la capacité à réutiliser le code, établir les standards et détecter les talents en interne. In fine, les entreprises utilisant les logiciels NoSQL sont confrontées à la prolifération des silos de données car chaque application requiert son propre espace de stockage. Les données sont ainsi fragmentées et difficilement gérables.

Tout cela constitue une bombe à retardement qui pourrait faire de sérieux dégâts. Fort heureusement, avec Postgres, il existe une solution technique, qui permet de régler ce problème. A savoir, il est possible de combiner les données non-structurées avec des tables relationnelles, tout en maintenant la compatibilité avec ACID et les règles d’un traitement centralisé.

Avec JSON/JSONB pour supporter et traiter les données d’un document et les données de type HStore pour les paires valeurs/clés, Postgres fournit les modèles flexibles de données dont les développeurs ont besoin pour construire des applications capables d’évoluer avec les objectifs de l’entreprise. Postgres permet aussi aux développeurs d’utiliser la syntaxe de documents orientés JSON directement dans les instructions SQL, complétées avec une large panoplie de fonctions pour manipuler des données JSON et les convertir dans les deux sens avec des données relationnelles. La capacité de créer des stocks de données peu structurées et de combiner des composants avec des tables relationnelles de façon instantanée est une capacité très puissante, dans une base de données relationnelle.

Postgres supporte les données non-structurées et permet aux développeurs d’appliquer des règles bien schématisées à des données sélectionnées, et cela selon les besoins des métiers. Avec les « Foreign Data Wrappers », les développeurs peuvent intégrer, avec Postgres, des données externes structurées ou non et permettre au logiciel de lire et d’écrire des requêtes en SQL aux sources de données étrangères (FDW pour MongoDB, CouchDB, MySQL, Redis, Neo4j et même Twitter).

Pour conclure, je soulignerai également un autre point : l’intégration du Shadow IT n’est pas qu’une question technique, bien que je pense que les innovations dans Postgres contribuent largement à éviter la complexité et les silos qui pourrait être créés. Nous devons toutefois éviter cette évolution du secteur informatique qui ressemble plus à un « règlement de compte à la OK Corral ». Les équipes doivent travailler ensemble pour s’assurer que l’informatique soit vue comme une source clé, un avantage compétitif et le soutien à la stratégie de l’entreprise.