weerapat1003 - stock.adobe.com

Comment ajouter des applications Shadow IT à la chaine d'outils DevOps officielle

Parfois, des développeurs et d'autres membres de l'équipe informatique installent des applications non approuvées pour combler une lacune dans la chaîne d'outils DevOps. Le Shadow IT est risqué, mais on peut lui laisser une chance.

Les équipes DevOps avancent rapidement et elles ont besoin des bonnes briques logicielles et des techniques adéquates pour le développement et le déploiement des applications qu’elles soient approuvées ou non par les services informatiques.

Le phénomène du shadow DevOps s’inscrit dans le shadow IT, c’est-à-dire lorsqu’une équipe ou un département met en œuvre des outils informatiques sans l’approbation de la DSI. Ce scénario peut mettre en péril le pipeline de développement d’applications et parfois même l’entreprise dans son ensemble. Cela peut entraîner des violations de conformité aux normes industrielles et gouvernementales, voire des pénalités légales et financières.

L’absence de tests et de contrôle de changements posent des problèmes de gestion des versions et menace d’endommager la base de données de configuration management.

En réalité, le shadow IT est un phénomène positif : les employés qui les adoptent veulent améliorer leur productivité et font mieux leur travail. Par exemple, ils peuvent considérer que Jenkins est plus facile à utiliser que le système d’intégration continue choisi par leur société. Ou ils ont découvert un projet de gestion des correctifs qui permet de gagner du temps lors des mises à jour des applications. Mais en cours de route, ils sont devenus hors-la-loi.

Détecter les poches de shadow DevOps

Il y a de nombreux moyens de détecter et de gérer le shadow IT au sein d’un pipeline DevOps. Par exemple dans une culture de travail qui récompense la prise d’initiative au mépris des règles, l’utilisation de logiciels non approuvés devient un secret de Polichinelle. Sinon, les administrateurs pourraient analyser l'entreprise pour trouver des briques non sécurisées et qui ne sont pas du ressort du DSI.

Au-delà, des revendications de développeurs freinés par des cycles de développement obsolètes, ce phénomène est symptomatique de la nécessité d’améliorer la productivité IT. Au lieu d’une menace, le shadow IT représente une opportunité pour parfaire les pratiques et les solutions DevOps. Les programmeurs et les ingénieurs comprennent bien les outils, les applications et les fonctionnalités dont ils ont besoin afin d’accomplir leurs tâches. Par exemple, la mauvaise expérience client auprès des services d'assistance technique conduit au Shadow IT. Ce type de goulet d’étranglement se traduit par de longs délais de mise en œuvre au terme d’un processus ardu rythmé par une pluie de requêtes.

Il convient de se renseigner sur les problèmes et les préoccupations de l’équipe DevOps. Faire appel au service financier permet d’évaluer les options en vue de l’intégration des programmes non autorisés dans la chaîne officielle de production. L'informatique doit non seulement formaliser les pratiques de DevOps, mais aussi mettre à jour et améliorer les environnements disponibles.       

La première étape vers la guérison est de déclarer l'amnistie au shadow IT tout en prenant des mesures immédiates pour atténuer les conséquences de ces ajouts « en dehors des clous ». Les utilisateurs peuvent continuer à s’en servir, à condition qu’ils souscrivent à une chaîne d’outils sécurisée officielle qui répond à ce besoin. Ce compromis conduit invariablement à rendre les DevOps plus volontaires parce que leurs attentes sont prises en compte et plus satisfaits par l'action.

Concevoir une nouvelle chaîne d’outils DevOps règlementaire

Pour restaurer l’ordre, cela demande de mettre sur pied une équipe interfonctionnelle qui inclut les développeurs, les responsables des opérations informatiques, de la cybersécurité et des gestionnaires d’actifs. Elle doit renforcer :

  • L’infrastructure des outils et leur résilience
  • Une politique exhaustive concernant les mises à jour et les patchs
  • Le budget pour faciliter la souscription aux licences
  • une expertise interne capable de gérer les correctifs de sécurité, les mises à jour et l'embarquement et le débarquement des utilisateurs du pipeline.

Outre l’importance de la sécurisation des processus, cela requiert une bonne communication entre les équipes qui sont souvent séparées par des silos. Par ailleurs, les suites de développement et d’exploitation à l’abonnement facilitent la gestion des dépenses tout en fournissant des indications sur consommation des services.

Cependant, la plupart des organisations n’ont pas suffisamment d’experts en cybersécurité. Une option consiste à faire appel à un prestataire externe. Il construit la chaîne d’outils en respectant le cahier des charges internes. Si le personnel possède les compétences nécessaires à la création du pipeline DevOps, il peut être intéressant de confier le déploiement des éléments de sécurité des consultants afin d’obtenir la solution la plus complète possible. Les services cloud sont évidemment très pertinents surtout quand on manque des ressources nécessaires.

Ensuite, maintenir le niveau de conformité s’avère essentiel. La mise en place d’un journal de bord officiel ou l’abonnement à des solutions comme celles de Puppet ou XebiaLabs viennent répondre à cette question.

Si la DSI adopte un service cloud, un logiciel d’estimation de coût comme CloudCheckr ou CloudBolt devient intéressant.

Enfin, l’établissement d’une nouvelle chaîne d’outils demande d’informer les utilisateurs quant aux modifications en cours. La création de tutoriels, d’un Wiki ou une collaboration étroite avec les spécialistes DevOps permet d’établir les processus qui amélioreront la productivité et de les tester en profondeur. Cela devient un effort collectif à valoriser.

Pour approfondir sur DevOps et Agilité

Close