A qui est destiné cet article : aux Directeurs/Managers de tous les secteurs de l’entreprise, à la DSI, aux utilisateurs de VBA/Excel eux-mêmes
Pour ceux qui sont pressés :
- VBA (Visual Basic pour Applications) est bien plus utilisé qu’il n’y paraît, et parfois pour des applications critiques pour le service utilisateur qui en est responsable.
- Les DSI sont rarement impliquées dans les développements VBA, parfois à juste titre, mais elles devraient au moins s’y intéresser et cadrer le sujet.
- 10 recommandations à la fin de cet article permettent de reprendre rapidement le contrôle d’une situation qui peut dégénérer à tout moment, et éviter la catastrophe en cas de changement de système informatique.
Pourquoi cet article ?
Il y a quelques semaines, je suis intervenu au sein d’une entreprise pour un grave problème applicatif, qui compromettait le fonctionnement de l’entreprise. Cette application, développée en VBA (Visual Basic pour Applications), servait à intégrer des données venant des clients de l’entreprise, et à créer tout un tas de choses allant des plannings d’intervention des techniciens à… la facturation. Malheureusement, les temps de réponse étaient tellement désastreux, et les plantages si fréquents, que la situation ne pouvait durer. Après un diagnostic complet, j’ai remis à la direction mes recommandations. Cette situation catastrophique dans laquelle se trouvait l’entreprise aurait pu être évitée, et c’est pour qu’elle le soit à l’avenir dans d’autres entreprises que je partage cet article.
La petite histoire de VBA dans les entreprises
VBA est un langage de programmation spécifique aux applications Office, et notamment à Excel et Access. Enfin, à Excel sur le poste de travail car maintenant de plus en plus d’entreprises utilisent Excel ou Google Sheets sur le Cloud pour partager plus facilement les données. VBA a été lancé en 1993 avec MS Excel 5. Depuis, l’eau a coulé sous les ponts.
Lors de la quasi-totalité de mes interventions, je découvre que l’application VBA a été mise au point sur l’initiative d’un utilisateur, voire d’un service utilisateur (Direction Financière, Supply Chain, Qualité, etc.), sans que la DSI ne soit au courant. Et cela pour une bonne raison : historiquement, et c’est encore souvent le cas, la DSI met – à juste titre – la priorité sur les infrastructures et équipements, la messagerie, le partage de fichiers, l’ERP. Et quand le service informatique entend l’acronyme VBA, la plupart du temps, elle se bouche les oreilles (surtout, on ne veut pas se mêler de cela !). Je le sais, j’ai longtemps fait partie de la DSI et je suis encore DSI à temps partagé !
Et pourtant !
A quoi sert VBA dans les entreprises ?
VBA est parfois utilisé pour :
- offrir une interface conviviale et pratique pour la saisie de données. Par exemple, le service qualité d’une ETI propose une interface de saisie plus conviviale qu’une feuille Excel pour remplir les détails concernant les incidents qualité (source, analyse, suivi du problème, etc.) et partage les rapports qui en sont extraits. Bien sûr, des applications « off the shelf » existent, mais elles ne correspondaient pas ni aux besoins ni au budget du service Qualité..
- Produire automatiquement des graphiques et des tableaux croisés dynamiques mis à jour automatiquement en fonction de données issues d’un ERP. Bien sûr l’entreprise aurait pu payer des ressources externes pour mettre en place le Reporting complet, mais…
- Importer automatiquement des données issues des machines-outils pour en déduire une organisation de la production, une supply chain efficiente, et des investissements optimaux.
- Consolider les résultats financiers de plusieurs filiales en attendant qu’elles utilisent toutes le même ERP.
- VBA est également très utilisé dans les banques et les assurances, pour développer des applicatifs métiers.
- etc.
Qui est responsable de l’application ?
A part dans les secteurs où l’on utilise VBA pour réaliser des applicatifs métiers complexes et stratégiques, comme la finance et les assurances, le responsable de l’application est souvent… celui qui l’a développée. Et tant que tout va bien… tout va bien.
Parfois, c’est un stagiaire qui a initié le développement, parfois c’est un cadre ou un employé qui voulait éliminer de son agenda des tâches répétitives. La plupart du temps, il s’est auto-formé. Parfois, il a eu la chance de partir en formation. Il s’agit rarement d’un informaticien, plutôt un utilisateur avancé soucieux d’amélioration continue. Toujours est-il qu’on ne lui a pas toujours donné les moyens de développer quelque chose de robuste et d’évolutif…
Quand la crise arrive, il est bien temps de se poser la question. Et d’impliquer la DSI qui viendra – ou pas – faire le pompier, proposer une solution fiable, stable, conforme à la stratégie et aux outils décidés en comité de direction.
Alors comment reprendre le contrôle ?
1. Réaliser un inventaire des programmes VBA présents dans l’entreprise
Informations à récupérer :
•Nom et service du développeur
• Titre et localisation de l’application (quel fichier)
• Echanges/Dépendances vis-à-vis d’autres données
• Fonctionnalités principales
Il ne s’agit pas de créer une usine à gaz que les gens ne voudront pas remplir ou qui leur prendra énormément de temps, la DSI peut faire passer une feuille Excel (ou bien sûr mettre à disposition une page spécifique sur l’intranet s’il y en a un), pour récupérer rapidement ces informations. On peut aussi ajouter à cet inventaire ce qui se passe, en quelques mots, si l’application ne fonctionne plus. Si l’entreprise a un système de gestion des compétences (GPEC), il serait intéressant que VBA en fasse partie, comme d’ailleurs toute compétence en développement ou en informatique d’une manière générale.
2. Clarifier les rôles
S’il n’y a personne à la DSI pour faire le support ou aider en interne, il faut le dire. Mais cela ne signifie pas qu’il ne doit pas y avoir du tout de contrôle et que l’utilisateur reste le seul responsable. Certaines applications deviennent critiques, voire vitales, sans que l’on s’en rende compte. Du coup, il faut un manager responsable pour toutes les applications d’envergure.
3. Transmettre des bonnes pratiques de programmation, et de sécurité
Voir la liste de bonnes pratiques spécifiques à VBA. Ajouter les bonnes pratiques en termes de protection contre les virus et ransomware, etc.
4. Encourager la formation
Objectif : solidifier les compétences des développeurs improvisés et leur éviter de commettre des bourdes ou de développer des applicatifs qui ne tiendront pas la route. Cela doit évidemment se faire en lien avec le service Formation/RH de l’entreprise.
5. Favoriser le transfert de compétences et le partage de macros
Inutile de réinventer la roue à chaque fois : certaines parties de code peuvent être mutualisées. Une solution efficace consiste à créer un groupe utilisateurs qui se rencontre régulièrement, et qui communique – brièvement mais efficacement – sur ce qu’ils font. Pas besoin de réunions de 3 heures !
6 . S’appuyer sur des “champions” et des « sponsors »
Objectif : propager les compétences en interne, soutenir les efforts d’amélioration de l’entreprise, mais aussi propager les bonnes pratiques et améliorer la communication entre la DSI et les utilisateurs sur ce sujet spécifique. Le champion est un spécialiste de VBA, très pédagogue et passionné d’amélioration continue. Le sponsor est un manager / directeur qui s’engage à soutenir les projets d’amélioration continue qui reposent sur VBA.
7. S’assurer que chaque “utilisateur développeur” a un backup
Il m’arrive régulièrement de voir des entreprises en détresse parce qu’une personne clé a quitté la société, ou simplement changé de poste. Un «backup» est quelqu’un qui pourrait à moindre frais et relativement rapidement prendre en charge un applicatif important, ne serait-ce que pendant les vacances du premier. Sans avoir autant de compétences, il est en mesure de comprendre le programme et de rechercher des solutions à d’éventuels problèmes.
8. Communiquer sur les autres possibilités de stocker et manipuler les données
Si la DSI dispose d’un serveur MS SQL, ou MySQL, ou autre, cela serait probablement une meilleure solution que ce que j’ai vu dans une ETI : des données critiques du personnel sauvegardées dans des fichiers Excel, bien sûr “protégés” par un mot de passe, et des données redondantes, parfois avec des valeurs différentes d’un fichier à l’autre. Non sérieusement, un peu de professionnalisme dans la gestion des données d’entreprise ne ferait pas de mal, dans certains cas. Par ailleurs, Power BI permet de réaliser certaines opérations aujourd’hui beaucoup plus simplement et rapidement que VBA, donc il faut former/informer les utilisateurs de ces possibilités (et d’ailleurs pas seulement les “utilisateurs développeurs” mais tous ceux qui ont besoin d’analyser et de présenter de l’information).
9. Trouver des ressources externes, au cas où.
Dans mon exemple du début de l’article, l’entreprise était perdue dans sa misère, toute seule, sans connaître de prestataires prêts à l’aider. Il est toujours utile de savoir où s’adresser en cas de problème, et si possible avoir des gens qui connaissent l’environnement dans lequel la société évolue, son métier, etc.
10. Anticiper
Est-ce que la société va passer à Excel on-line (sur le cloud), à Google Sheets (sur le cloud également) ? A autre chose ? Car, pour sûr, cela va avoir un impact sur toutes ces applications VBA, et donc sur le fonctionnement de l’entreprise. Autant avoir anticipé…