Je pense que les gens manquent le point général ici:
Si vous n'aimez pas tout le développement personnalisé en cours, l'interdire, c'est résoudre le mauvais problème. Vous devriez plutôt vous demander pourquoi ils tournent autour de l'informatique, et pas seulement leur dire que ce n'est pas permis. N'oubliez pas que vous (les TI) avez pour but de les aider à mieux faire leur travail et que les gens n'utilisent pas de logiciels parce qu'ils sont cool, ordonnés ou nouveaux, ils l'utilisent parce qu'ils résolvent un problème qu'ils ont eux-mêmes.
Pourquoi ces applications sont-elles créées en premier lieu?
Dans tous les cas que j'ai vus, il y a une raison commune:
Les groupes d’entreprises accordent plus de priorité à leurs propres besoins que ces derniers ne sont prioritaires dans l’ensemble de la société
Le marketing étant uniquement responsable du marketing, les initiatives qui profitent à leurs objectifs leur paraissent essentielles, tout en étant considérées comme fluff pour d'autres groupes, et ont tendance à être moins prioritaires lorsqu'il s'agit de ressources limitées telles que l'informatique. La hiérarchisation des priorités n'entre en jeu que lorsqu'ils souhaitent utiliser une ressource partagée - s'ils conservent le projet entièrement dans leur propre département, seul le chef de département doit se préoccuper du budget et du calendrier.
Il n'y a aucune raison que j'interdise ce type de développement, car cela allège les contraintes sur les ressources partagées (principalement l'informatique) et permet à chaque groupe de s'autonomiser pour résoudre ses propres problèmes (comme les utilisateurs expérimentés d'Excel avancé sont assez courants, comme il s’agit d’un problème courant, la plupart des départements en ont au moins un).
Cependant, vous ne pouvez pas vous attendre à résoudre les problèmes liés à ces applications, ni à les aider après le départ du développeur d'origine. Comme le mentionne un autre posté, cela n’empêche pas le grand patron d’exiger que vous le souteniez, mais si vous gardez une idée du type d’applications ou de processus personnalisés, vous pouvez avoir une idée de ce qui devient critique et vous pourrait avoir besoin de s'impliquer pour l'amener "en interne". De plus, si quelque chose se connecte et modifie des systèmes sous contrôle informatique, alors le service informatique devrait être impliqué, ne serait-ce que pour assurer la sécurité et l'intégrité de leurs systèmes centraux. Cependant, si c'est quelque chose qui se limite au bureau d'un utilisateur, pourquoi en ressentir le besoin l'interdire?
Mais voici une chose à retenir: chaque application personnalisée développée en dehors du service informatique correspond à un besoin auquel le service informatique ne répond pas . Il peut y avoir une bonne raison pour laquelle ils ne sont pas respectés - pas une priorité dans l'entreprise, un problème très spécialisé, pas aussi performant que d'autres options, langage personnalisé que vos informaticiens ne connaissent pas, etc. - et le manque d'implication de l'informatique peut être légitime, mais ces solutions ont été créées parce que certains départements avaient un besoin que le service informatique ne pouvait pas (ou ne voulait pas) satisfaire.
Essayez de les aider à résoudre leurs problèmes, et si vous n'avez ni le temps ni les ressources, laissez-les résoudre eux-mêmes. Rendre obligatoire une langue nécessitant une courbe d'apprentissage abrupte, dans le seul but d'empêcher les gens de rester en contact avec votre entreprise, ne sert qu'à renforcer l'attitude élitiste que la plupart des utilisateurs estiment que l'informatique a plus du même problème, car les utilisateurs ont peur d’approcher le service informatique et sont convaincus que celui-ci ne comprend pas leurs besoins ou leurs désirs. Ouvrez la relation - comprendre ce dont ils ont besoin est le seul moyen de les empêcher de vous entourer.