- Utilise l’existant
Réfléchissons à un utilisateur qui a fait toute une application de reporting avec Excel et les macros possibles en VBA. Il n’a fait que se servir de technologies fournies par la DSI. Il a appris à se servir des fonctionnalités poussées pour faire d’un simple tableur un outil de reporting.
Réfléchissez à combien coûte le déploiement d’Excel dans une entreprise. Ne serait-ce qu’en termes de licences. N’est-ce pas un peu cher pour ne laisser à vos utilisateurs seulement le droit d’utiliser qu’une fraction des possibilités qu’offre Excel ? Est-il préférable pour la DSI de développer une solution étant tellement polymorphe qu’elle permettrait aux utilisateurs de faire des petits tableaux de bord d’appoint pour représenter un peu tout et n’importe quoi ou vaut-il mieux que les utilisateurs apprennent à utiliser un outil déjà existant dans l’entreprise pour les petits besoins ? Ce genre de solution fait avec Excel ne coûte rien de plus à la DSI, au contraire elle augmente même le ROI de la technologie utilisée, car elle permet de solutionner un besoin de manière rapide.
S’il faut savoir mettre le holà quand la solution commence à prendre de l’importance au niveau business au point de ne plus pouvoir s’en passer alors qu’elle repose sur un développement de faible qualité, il est tout à fait acceptable de vivre avec la solution si elle est réservée à un périmètre très réduit, si elle utilise des technologies déjà présentes dans l’entreprise et que l’éliminer coûterait finalement plus cher que de la laisser vivre.
- Renforce les standards technologiques
Nous pouvons reprendre l’exemple avec d’autres technologies. Un petit logiciel fourni par un prestataire externe, fait en Java pour être compatible avec la JVM version 5, qui tourne dans l’entreprise renforce le standard technologique de l’entreprise qui impose que les logiciels soient développés en Java et non en Python ou en C, car l’entreprise ne dispose pas de compétences en la matière.
C’est important, car certaines applications issues du Shadow IT ne seront pas purement et simplement éliminées. Elles seront parfois à redévelopper par la DSI, car elles apportent un vrai plus au métier, mais par manque de stabilité seront qualifiées de dangereuses par cette dernière.
Pour ce genre d’applications, mieux vaut donc avoir la compétence en interne pour justement pouvoir reprendre une solution dont la DSI ignore l’existence. De plus, certaines solutions issues du Shadow IT ne sont pas à refaire. Elles peuvent être parfois suffisamment bien développées pour être reprises telles quelles par la DSI. Et encore une fois dans ce cas de régularisation du Shadow IT, il est préférable que la solution réponde aux différents critères des standards technologiques déjà imposés par l’entreprise.
À noter que certains standards dictés par les urbanistes sont d’être « cloud ready », c’est-à-dire disponibles en mode cloud. De nombreuses solutions considérées comme Shadow IT sont aujourd’hui contractées en mode cloud, car justement faciles à déployer par le métier. Une enquête publiée dans Cisco Blog a estimé que les DSI pensaient en moyenne avoir une cinquantaine d’applications en mode cloud, alors qu’il en existerait en réalité plus de 730 utilisées, soit 15 fois plus (http://blogs.cisco.com/datacenter/sh...t-you-cant-see). Ici, ce n’est pas juste un standard technologique qui est soutenu par le Shadow IT, c’est la stratégie de la DSI qui en pleine transformation digitale, souhaite favoriser les applications cloud pour se libérer des contraintes d’exploitation et de maintenance d’une application.
- Le shelf-ware
On confond souvent le Shadow IT avec une autre pratique qui est le Shelf-ware, c’est-à-dire acheter un logiciel pour soi ou son département sans essayer de savoir si d’autres ont le même besoin que nous, ou si une solution n’existe déjà pas dans l’entreprise. Cette pratique fait bel et bien monter le coût de possession d’une technologie dans l’entreprise. Car le Shelf-ware ne sert qu’à un petit nombre d’utilisateurs, et peut faire doublon. Si vous trouvez injustifié de payer deux assurances pour une maison par exemple, vous trouverez alors la pratique Shelf-ware injustifiée aussi. Pourtant pour un logiciel, il nous est moins facile de percevoir que nous en avons déjà un qui répond au besoin. Soit parce que nous n’avons jamais vu la première solution sous le bon angle, soit parce que nous la trouvons inélégante ou peu adaptée et qu’une nouvelle, plus dans l’air du temps, nous semble mieux. C’est donc souvent un problème plus humain que technologique. Il est vrai que le Shadow IT peut élever les coûts technologiques quand Shelf-ware et Shadow IT se combinent, mais ce n’est pas systématique.
La réduction des coûts ne se fait que lorsque les produits internes sont détournés de leur usage premier. Il existe donc des stratégies de gestion IT qui permettent d’influencer le Shadow IT afin qu’il réduise les coûts technologiques plutôt que de les augmenter.
- Anticipe le futur
Tout en condamnant l’effet du Shadow IT, Christophe Jorge interviewé dans nos recherches a tout de même reconnu que le Shadow IT pouvait servir parfois de pilote, de nombreux autres experts partagent cet avis.
Car oui le Shadow IT ne se fait pas toujours avec des solutions corporate détournées. Il peut aussi être fait avec des applications externes à l’entreprise. Les solutions SaaS ont l’avantage d’être très faciles à déployer, donc utiles pour le métier, mais aussi d’utiliser des technologies à jour. En réalité, commencer à prendre en main une solution qui utilise des technologies à jour est bénéfique pour l’entreprise. Notamment en termes de savoir-faire. Car l’entreprise devra un jour ou l’autre faire avec cette nouvelle technologie ou ce nouveau standard. Le Shadow IT est en quelque sorte un précurseur sur les technologies utilisées demain en entreprise. C’est le cas pour le cloud, mais aussi des applications mobiles ou des objets connectés. Toutes ces nouveautés informatiques peuvent être demandées par des utilisateurs et voyant la DSI être en retard, ils vont s’en équiper par eux-mêmes. La DSI peut alors transformer une faiblesse en force en laissant une petite zone d’informatique de l’ombre devenir un laboratoire de test pour les technologies de demain, savoir par exemple ainsi un peu mieux quels usages vont émerger de l’hyper mobilité, des appareils tactiles ou bien des objets connectés.
Les commerciaux qui ont besoin, pour leurs visions à 360° des clients, de compétence en Big data peuvent engager un data scientiste qui développera des algorithmes sans doute en Python, c’est ce que nous appellerons plus tard un Citizen Developer. Même si aujourd’hui Python n’est pas dans les standards technologiques de l’entreprise, rien ne dit que ce ne sera pas le cas demain. Le Shadow IT peut donc servir de Digital Lab où de nouvelles technologies vont apparaître. Une fois plus mature, ces technologies pourront alors être intégrées dans les roadmaps des DSI et ce qui était à la base du Shadow IT est devenu un nouveau standard de l’entreprise.
- Pour conclure
Certains cas de Shadow IT amènent les employés à détourner des solutions dans lesquelles l’entreprise a déjà investi, d’autres permettent de devenir plus vite mature sur les nouvelles technologies. Ces pratiques accroissent par conséquent le taux d’adoption de ces technologies, ce qui diminue le coût total de possession et améliore la rentabilité des investissements technologiques. Les pratiques qui en informatique font augmenter les coûts sont souvent l’achat d’applications pour un petit nombre d’utilisateurs ou l’achat d’applications qui font doublon avec des applications déjà existantes. Mais ces pratiques n’ont en réalité rien à voir avec le Shadow IT. Elles peuvent aller de pair avec le Shadow IT du fait de sa gestion difficile, mais ne sont en aucun cas un fait systématique.
Et vous ?
Qu'en pensez-vous ?