Discussion :

[barpasc]

En effet, VBA n'est plus très soutenu par l'éditeur et puis il sera de moins en moins. Cependant, il y a quand même une grande quantité de macro VBA qui existent et tournent dans le monde professionnel. C'est relativement pratique, il n'y a pas besoin d'une infrastructure dédiée au développement d'un outil. En quelques jours en écrivant un script Excel/Access/... sans accès à une licence visual studio ou un serveur, vous pouvez ajouter de la valeur ajoutée à une application existante. Ca ne nécessite pas un projet de développement avec ce que ça entraîne cahier des charges, réunion avec des équipes offshore, tests divers.

En termes de coûts pour une entreprise, c'est significatif. A ça, s'ajoute le fait que le l'outil est versatile, il propose de faire des tableaux de bord et puis il peut accéder au système de fichiers... Par contre, le tableur n'est pas multi-utilisateurs et les données ne sont pas en sécurité. Alors ça peut compliquer les automatisations...

J'ai développé un certain nombre d'outils en vba (un exemple parmi d'autre, compilation de fichier csv reçu par mail mais avec des nouvelles informations spécifiques à chaque fichier, automatisation réalisée en 3-4 jours), l'activité une fois automatisée ne demandait plus que 3-4 minutes au lieu de plusieurs jours voire semaines. Dans le traitement manuel, quand il y avait des erreurs dans la manipulation des csv, il fallait tout effacer dans la base de donnée et reprendre le traitement des fichiers depuis le début... L'automatisation a loggé toutes les actions et a obligé l'utilisateur a valider toutes ses actions avant l'export en base et surtout pas de données saisie très propice aux erreurs mais des listes déroulantes et cases à cocher... Fin des erreurs, les erreurs restantes étaient dûes à l'administrateur qui n'avait pas mis à jour les tables mais l'administrateur n'avait plus a annuler entièrement des imports.

C'est un exemple parmi d'autre. Je pourrais en citer en RH dans la paie. Il y avait des erreurs depuis années qui rendaient les formules incohérentes au moment de l'automatisation. Je pensais que mes formules étaient fausses. Mais c'était des erreurs dans les données que j'avais en exemple. Avant c'était un travail manuel approximativement 100 lignes (1 ligne par employé) et une vingtaine de colonne sur lesquelles il fallait être très attentif et regarder pour chacune dans d'autres données si les valeurs étaient à jour, soit 100x20= 2000 vérifications. Il y avait une stagiaire pour ça qui le faisait toute la semaine en fin de mois... Sans macro vba, juste des formules et avec un simple copié coller des données, les calculs étaient faits (un quart d'heure max.) et quelques graphiques pour être sûre qu'il n'y ait pas d'incohérences. Avec VBA, ça aurait été moins de 2 mn mais après s'il faut changer quelque chose ce n'est pas simple alors que des formules ça peut plus ou moins aller si c'est bien documenté.

Ce sont des situations fréquentes avec Excel que j'ai rencontré. Je comprends que les entreprises ne vont pas toujours donner accès à un serveur web pour ces situations surtout les grandes entreprises qui ont des procédures qui peuvent prendre des semaines... Une licence à Visual Studio pour développer quelque chose en js avec un fichier manifest xml qui ne fonctionne pas sur toutes les distributions office, javascript est plus orienté vers la gestion de données web non tabulaire (JSON....) et dans un tableur graphique, c'est plus souvent des données tabulaire ligne x colonne.

Je m'oriente actuellement vers les outils open sources Python, obasic pour libreoffice ou openoffice et je proposerai des automatisations qui peuvent s'implémenter facilement et ne nécessite pas un environnement de développement "lourd". En plus, openoffice/libreoffice est portable, indépendant du système d'exploitation. Je ne sais pas si c'est le bon choix. Si l'éditeur actuel force le passage vers le cloud, peut-être qu'il y aura des nouveaux adhérents et peut-être qu'il y en aura qui feront marche arrière. Comme je n'ai pas de boule de cristal, je continue sur la logique de ce qui m'a amené à apprendre vba.

[barpasc]

Et pour illustrer ma réponse précédente, les récents choix "stratégiques" de l'éditeur même s'ils sont mis en avant avec des chiffres mirobolants de ventes sur les technologies OLAP et OLTP intégrées dans la suite office, ce n'est pas quelque chose que j'ai vraiment utilisé.

Et même si ça avait été mon souhait, dans la majorité des entreprises où j'ai été sans avoir les droits admin, ces outils (powerview, powerpivot, powerquery), n'étaient pas du tout installés et il fallait les droits admin pour les installer et il fallait aussi expliquer ce que c'était et très souvent ils trouvaient ça obscure... Des fois, c'était un peu long même dans des grandes institutions qui ont les derniers produits de l'éditeur et qui ont les versions les plus récentes de l'éditeur.

Plus l'entreprise est grande, plus la procédure peut être longue. Je préferrais me concentrer sur les drivers odbc plutôt que des technos qui sont très bien pour l'analyse, c'est top rapide mais ce n'est qu'en lecture. Il ne faut pas espérer mettre à jour des données avec ces outils. C'est la contrepartie d'utiliser les registres du processeurs, c'est très rapide par rapport au bus qui transfère entre la RAM et le processeur mais il n'y a pas de mémoire cache pour faire des modifs...

Similairement mais avec moins de fonctionnalités, les tcd sont plus simples et accessibles. En plus, il fallait apprendre une nouvelle syntaxe pour les formules DAX et déjà que la syntaxe des formules excel est technique alors s'il faut oublier pour quelques manip cette technique pour passer à une autre technique qui doit produire le même résultat, en ce qui me concerne, il me faudra beaucoup de café...

C'est pour dire que si l'éditeur va vers les technos web backend et frontend (ce sont chacuns des sujets techniques) pour de la gestion de données (automatisations, migrations, fiabilisations...), je ne suis pas sûre qu'au vu des choix précédents, tout le monde va suivre. Le formulaire classique Win32 winform reste quelque chose d'accessible. Les fonctions asynchrones en javascript ne sont pas toujours évidentes. Evidemment, je peux me tromper.

[FMJ]

Il ne faut pas perdre de vue l'objectif premier de VBA : permettre à l'utilisateur final de développer lui-même des fonctions avancées, de façon relativement simple et rapide, avec un niveau de formation très limité. Le langage a été structuré pour cela, il le fait bien et il existe des millions et des millions de ces bouts de code en VBA qui sont utilisés tous les jours à travers.
Le seul motif d'en changer serait une incompatibilité technologique ou une lacune fonctionnelle majeures.
Avant de penser à un successeur, Microsoft est obligé de penser à l'existant et à une façon de le migrer facilement et efficacement vers un nouveau langage qui soit utilisable par les utilisateurs finaux.

La question des applis métier déloppée en VBA est d'un autre ordre.