Une expression célèbre affirme : « Ne demandez pas la permission, demandez pardon ». Si elle s’applique au Shadow IT, elle pourrait bien également marquer une dérive de DevOps...
Avec l’adoption croissante des pratiques et des outils DevOps, les équipes de l’entreprise se sont lancées dans le déploiement d’outils DevOps divers, de manière locale et autonome. De là à ce que DevOps provoque la réapparition ou l’accélération des pratiques de Shadow IT, il n’y a qu’un pas que certains experts n’ont pas manqué de franchir pour pointer certaines dérives de DevOps.
L’exemple flagrant de ces dérives provient de la multiplication des instances Jenkins. Ces dernières pourraient même servir de KPI du succès de DevOps dans les entreprises. Sans pour autant être le reflet de la réalité, car nombre de ces instances n’ont qu’une durée d’usage limitée, et sont maintenues dans le système sans que pour autant personne ne s’en préoccupe plus !
Le spectre du Shadow IT
C’est d’autant plus dommageable pour l’entreprise qu’une grande partie du Shadow IT concerne des applications qui ont été acquises par des utilisateurs professionnels, sans approbation ni communication à leur hiérarchie ou à l’informatique. Mais également sans l’expertise nécessaire pour maintenir et mettre à niveau le logiciel comme l’instance.
Cela se traduit par un spectre du Shadow IT qui vire en cauchemar pour les équipes en charge de la conformité, de la sécurité et de la gouvernance. Et en casse-tête pour les équipes de la DSI.
4 risques de Shadow IT liés à l’outillage DevOps
- Software Asset Management : le risque de découvrir des logiciels non approuvés et sans licence est énorme et le DSI risque potentiellement de se voir sanctionné pour l'utilisation de logiciels sans licence.
- Conformité aux normes de l'industrie et des réglementations pour démontrer la qualité aux clients.
- Manque de tests et de contrôle des modifications et mises à jour : la gestion du cycle des changement et des nouvelles versions devient compliquée.
- Gestion de la configuration : les équipes informatiques s'appuient sur la véracité des informations contenues dans la base de données de gestion de configuration CMDB… que l'informatique fantôme compromet.
La tentation de prendre le contrôle...
La DSI pourrait être tentée de prendre le contrôle des outils DevOps afin de rationaliser les applications et d’éviter les dérives. Mais cette pratique vient heurter la philosophie DevOps, et surtout elle risque de braquer les équipes et de tuer l’innovation.
Par contre, fournir des outils pour augmenter la productivité avec des outils adaptés à leur contexte d’usage via des piles d’applications logicielles pourrait apporter une réponse pragmatique. Et satisfaire les équipes autonomes souvent opposées à toute tentative de centralisation.
Une telle stratégie peut se décliner dans la fourniture d’une plateforme d'outils réactive ; l’anticipation des besoins et tendances dans l’outillage et leur construction ; un focus sur l'expérience utilisateur ; un accompagnement pour la transition vers la plate-forme d'outillage ; et le lancement d’une campagne de communication interne sur les outillages disponibles pour les équipes.
Image d’entête 636869548 @ iStock nadia_bormotova
