Dans la plupart des sociétés, les utilisateurs ont des besoins spécifiques liés à la bonne exécution de leurs missions afin de gagner du temps et d’améliorer l’efficacité des processus. Pour ce faire, ils ont recours à l’automatisation de certaines tâches répétitives tels des calculs complexes ou des traitements de données.

Bien souvent, ils reçoivent une réponse négative des services IT à leurs requêtes car leurs besoins ne rentrent pas dans le cadre des applications développées et présentent, la plupart du temps, un ROI trop faible.

En cas d’écoute favorable, les délais de réalisation ou les budgets à allouer sont souvent invoqués pour justifier l’abandon du projet.

Seule solution pour les utilisateurs : développer par eux-mêmes une application avec les outils bureautiques à leur disposition (Ms Excel, MS Access…) souvent installés par défaut ou suivant un corporate policy sur leur PC.

En s’auto-formant, ils arrivent à transposer leur connaissance des règles métiers et à créer des applications répondant exactement à leurs besoins. Suivant leurs aptitudes quant aux outils utilisés, ils recourent à une combinaison de macros et/ou de modules de code pour effectuer les développements.

Cette possibilité est encore renforcée car la nouvelle génération d’utilisateurs possède souvent des connaissances IT développées au cours de leurs études.

Au départ, ces outils remplissent parfaitement leur rôle mais les problèmes de cette informatique non contrôlée par les services IT se font rapidement sentir :

• Diffusion anarchique de l’application dans un département
• Complexification au cours du temps à la suite de l’évolution des besoins et des traitements des exceptions
• Dépendance de la connaissance vis-à-vis du créateur de l’application mère
• Mémorisation locale de données intermédiaires non fiables dans le temps et production de rapports sur ces données
• Backup de ces applications non prévues dans les plans de sauvegarde IT
• Utilisation par de multiples utilisateurs alors que l’application est initialement développée pour un utilisateur unique.
• Maintenance délicate et non planifiée lors des changements des versions des logiciels utilisés pour la création

On ne peut que constater le risque majeur engendré par cette situation si l’IT considère que ces applications n’existent pas et ne sont pas de leur responsabilité.

Aubay peut vous aider à mitiger ce risque via l’approche méthodologique suivante :

Analyse du risque brut

Cette action initiale, réalisée par un spécialiste senior, consiste à répertorier toutes les applications « grises », les classer en 3 catégories (analyse d’impact et probabilité de survenance) et prévoir les actions qui s’imposent :

• 1. Critiques : Celles considérées comme business critical et qui ne sont pas fiables et/ou secure doivent obligatoirement être récrites en respectant les standards (méthodologiques / architecturaux / sécurité) de l’entreprise soit avec les outils bureautiques actuels, soit avec un changement complet de paradigme (le rapport urgence, coût, temps de développement entrant en ligne de compte). Un plan de contingence est proposé pour la période de transition. Un plan de réécriture peut également être élaboré si nécessaire.
  2.  Nécessaires : Celles moins critiques qui ne nécessitent donc pas une récriture complète mais un « simple » recoding pour rencontrer les qualités jugées indispensables. (Les rendre plus efficientes, garantir qu’elles n’ont pas d’effets de bord sur les autres applications, ni sur l’intégrité des SGBD de l’entreprise. Un plan d’amélioration est proposé sur base des qualités requises pour ce type d’application (pérennité, intégrité des données, usage multiple, …)
  3. Nice to have : Toutes les autres applications pour lesquelles une analyse plus fine doit être menée afin de décider s’il est opportun de les maintenir en l’état, de tirer la prise, d’en regrouper plusieurs ensemble… Des actions telles que la mise en configuration des sources, l’intégration dans le plan de sauvegarde peuvent être envisagées.

Définition du Plan de contingence avec risque résiduel et évaluation des charges de travail

Ce plan est élaboré en collaboration avec les responsables des applications et le service IT sur base de l’analyse de risque brut. Il détermine les actions à mener pour rendre ce risque acceptable. Un plan précis d’actions est élaboré et chiffré par les spécialistes d’Aubay.

Exécution du plan de contingence

Les ressources techniques sont mises en place par Aubay afin de réaliser le plan sous la responsabilité d’un spécialiste senior, en charge de la gestion du projet.

Aubay peut vous accompagner dans ces différentes étapes de l’audit initial jusqu’au au développement final avec une équipe dédiée et expérimentée.