Rares sont les organisations qui ne s'appuient pas sur des applications et des technologies importantes de l 'informatique pour l'utilisateur final (EUC) qui sont inconnues de leurs services informatiques.
Ces applications sont aussi souvent appelées "Shadow IT".Elles existent parce que les utilisateurs professionnels décident de construire leurs propres gadgets pour toute une série de raisons, notamment le prototypage rapide, la saisie d'une opportunité de marché et le maintien du contrôle, c'est-à-dire la non-divulgation de leurs propres connaissances, etc.
Ainsi, en appréciant le risque que posent ces applications développées par l'utilisateur final est l'étape n° 1. Et à vrai dire ? Il faut souvent un régulateur ou un auditeur pour attirer l'attention de la direction sur ce point.
Mais par où commencer ? Peu d'organisations ont déjà eu l'idée de s'attaquer à ce problème, et elles manquent donc de connaissances ou d'expérience pour se poser les bonnes questions, sans parler de la mise en œuvre d'une solution.
Les étapes clés du contrôle de l'EUC
Sur la base de nos deux décennies d'expérience à aider les organisations à réfléchir et à mettre en œuvre des solutions durables de contrôle et de gestion des risques liés aux applications destinées aux utilisateurs finaux, nous pouvons affirmer avec certitude qu' il s'agit là des étapes de base à suivre pour mettre en œuvre un projet de contrôle des applications destinées aux utilisateurs finaux :
Clarifier les objectifs de l'organisation
Cela peut être aussi général que "tout employé qui développe une application qui sera utilisée au moins une fois par an". Elle peut aussi être très spécifique, comme "toute feuille de calcul utilisée dans les rapports financiers et réglementaires".
Construire un inventaire durable
C'est à ce stade que les organisations délibèrent sur les mérites de demander aux utilisateurs de s'auto-déclarer ou d'utiliser le balayage pour identifier les applications clés. L'expérience montre que l'auto-déclaration est le meilleur point de départ. Les utilisateurs connaissent leurs applications importantes et savent pourquoi ils les ont développées. Toutefois, l'analyse technique peut être utilisée pour vérifier que rien n'a été oublié. Des flux de travail automatisés peuvent ensuite demander aux utilisateurs de réaffirmer que rien n'a changé depuis leur dernière attestation. Là encore, une analyse judicieuse peut aider à repérer tout ce qui n'a pas été pris en compte.
Évaluer les risques des dossiers en fonction de leur importance relative
À ce stade, l'inventaire peut facilement compter plusieurs centaines, voire des milliers d' applications. Les traiter toutes de la même manière pourrait constituer une ponction inutile de ressources, car elles n'effectuent pas toutes un travail d'égale importance. Il est donc utile de les hiérarchiser. Voici quelques exemples : Le niveau 1 nécessite une surveillance étroite, le niveau 3 des examens occasionnels.
Assurez-vous que vos applications à haut risque fonctionnent comme prévu
Les meilleures pratiques suggèrent que les organisations se concentrent sur leurs applications de niveau 1 et vérifient que chacune d'entre elles fonctionne comme prévu. Il peut être surprenant, étant donné que ces applications sont développées par des utilisateurs finaux, d'apprendre que nombre d'entre elles circulent dans l'organisation et sont utilisées par des personnes qui n'ont aucune idée de la manière dont la feuille de calcul ou l'application fonctionne réellement. Des erreurs peuvent donc facilement être ajoutées, même par les employés les mieux intentionnés.
Après vérification et approbation, enregistrer les modifications matérielles
Une fois qu'une application a été vérifiée, il est vraiment logique de s'assurer que personne ne l'a modifiée après qu'elle a été transmise à l'entreprise. Toute modification importante doit donc être enregistrée, expliquée et approuvée, faute de quoi des risques inconnus sont réintroduits dans l'entreprise.
Conservez une copie de sauvegarde de ces fichiers clés, également appelés versions.
Elles sont importantes s'il est nécessaire de revenir en arrière et de déterminer pourquoi un changement a été effectué, ou quelles données ont servi de base à une analyse.
Consigner les problèmes importants et leur résolution
Même si l'on s'assure que l'application fonctionne correctement, il peut arriver que des erreurs soient commises, comme la saisie de données incorrectes ou l'utilisation d'une hypothèse qui ne s'est pas avérée exacte. L'idéal est d'enregistrer ces "problèmes", ainsi que leur résolution, quelle qu'elle soit.
Déclassement et remplacement par des systèmes centraux
Enfin, chaque application EUC devrait avoir une fin de vie planifiée. Si l'application ne sert pas à grand-chose, sa valeur diminuera probablement avec le temps et s'estompera. Et tout ce qui est utilisé de manière constante devrait être remplacé par un système de base approprié. Quoi qu'il en soit, les EUC doivent avoir une durée de vie limitée et être remplacés par des systèmes centraux adéquats.
Bien que tout cela semble évident, de nombreuses organisations peinent à mettre en œuvre ces contrôles judicieux. La peur de l'inconnu, l'ampleur du problème, ou les deux, sont peut-être à l'origine de cette difficulté.
Heureusement, avec ClusterSeven, vous pouvez bénéficier à la fois d'une solution logicielle et d'un support client que vous pouvez exploiter pour gérer le cycle de vie complet de n'importe quel EUC. N'hésitez pas à nous contacter pour plus de détails et une démonstration.
