Pourquoi les gens utilisent encore VBA

 (sancarn.github.io)
3 points par GN⁺ 2023-11-16 | 1 commentaires | Partager sur WhatsApp
  • Dans de nombreuses organisations, Excel est devenu la base des processus métier, si bien que lorsqu’une petite automatisation est nécessaire, VBA devient de fait l’option par défaut
  • L’organisation prise en exemple dispose de 13 plateformes de données et de plusieurs outils d’automatisation, mais les seuls outils capables d’accéder largement aux sources de données nécessaires se réduisent essentiellement à VBA et PowerShell
  • La CyberSecurity a refusé l’installation de langages de haut niveau comme Python, Ruby, Node, Rust, et l’alternative Power Platform montre des limites en matière d’accessibilité aux données et de maintenance d’algorithmes complexes
  • Les précédents avec Lotus Notes et IBM BPM montrent que les systèmes pilotés par l’IT peuvent être vulnérables à la fin du support, aux migrations inachevées et aux trous de maintenance
  • VBA est ancien et a ses faiblesses, mais il est inclus dans Office, accessible à tous, et offre aux SME le contrôle nécessaire pour vérifier eux-mêmes la logique métier et la migration des données

Les raisons directes pour lesquelles VBA continue d’être choisi

  • Dans le sondage 2021 de /r/vba, la majorité des utilisateurs de VBA ont répondu qu’ils utilisaient VBA parce qu’ils n’avaient pas d’autre choix
  • Beaucoup d’organisations font tourner l’ensemble de leurs processus métier sur Excel, et lorsqu’un peu d’automatisation est nécessaire, VBA est souvent le premier choix
  • Derrière la critique du type « on contrôle une partie de l’infrastructure avec des feuilles de calcul » se cachent en réalité les contraintes liées aux outils fournis par l’organisation, à l’accessibilité des données et à la structure de maintenance

Les limites liées à l’accès aux données et aux outils d’automatisation

  • La branche ingénierie de l’organisation étudiée peut utiliser plusieurs plateformes d’automatisation
    • OnPrem : PowerShell, VBA d’Excel / OfficeJS limité / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud : PowerApps, Power BI, PowerAutomate non premium
    • Environnements sandbox : ArcGIS avec ArcPy, MapInfo avec MapBasic, InfoWorks ICM avec Ruby, ArcGIS Online
  • Les plateformes de données gérées par l’IT vont de D1 à D13 et incluent une base de données géospatiale, une base SAP, une plateforme de télémétrie, SharePoint, Lotus Notes, IBM BPM, des systèmes de fichiers et des informations de modèles hydrauliques
  • Au final, les plateformes d’automatisation capables de se connecter aux sources de données nécessaires se limitent essentiellement à VBA et PowerShell
    • Power BI Desktop a bien été déployé dans l’organisation, mais il ne couvre pas toutes les plateformes auxquelles VBA accède
    • Même à périmètre d’accès équivalent, Power BI est difficile à utiliser pour l’automatisation de processus, et pour traiter d’autres jeux de données on passe par la création de CSV stockés sur SharePoint
    • Et cette génération de CSV est parfois assurée par VBA
  • Certaines connexions de VBA vers des services OnCloud reposent sur des essais directs, et l’auteur pense qu’il est aussi possible d’interfacer SAP BW4HANA et d’autres services cloud via VBA, mais les exigences d’authentification et les protocoles ne sont pas encore résolus

Les limites des langages de haut niveau et de Power Platform

  • L’organisation voulait utiliser des langages de haut niveau comme Python, Ruby, Node, Rust pour l’automatisation métier, mais toutes les demandes d’installation pour l’équipe ou l’ensemble du métier ont été refusées par la CyberSecurity
  • Le motif du refus était qu’autoriser les utilisateurs finaux à accéder à des langages de programmation de haut niveau allait à l’encontre de la vision stratégique technologique de l’entreprise
  • Les alternatives souvent citées, PowerAutomate et PowerApps, n’accèdent quasiment pas aux données nécessaires
  • Et même lorsque l’accès aux données est possible, Power Platform reste insuffisante pour exécuter la plupart des processus
    • Les algorithmes requis étant complexes, les solutions PowerAutomate sont difficiles à maintenir et peuvent être ardues à comprendre même pour le personnel IT
    • L’exemple donné est celui des projection algorithms
  • En pratique, les seuls outils réellement restants sont donc PowerShell v3 et VBA
    • PowerShell v3 ne prend pas en charge la syntaxe des classes et il est impossible d’y installer des modules
    • VBA est la cible pour laquelle des centaines d’heures ont été investies afin de créer des open source VBA libraries et le renforcer comme langage raisonnable selon des standards modernes

VBA comme garantie de maintenance

  • Dans les années 2000, de nombreux systèmes ont été construits sur des bases de données IBM Lotus Notes
  • Après son acquisition par HCL en 2019, la continuité du support de Lotus Notes est devenue incertaine, et la fin officielle du support était prévue pour juin 2024
  • À partir de 2019, l’équipe technique a tenté de migrer plusieurs systèmes vers de nouvelles technologies, et l’organisation a investi massivement dans le développement d’un système basé sur IBM Business Process Manager pour remplacer une base Lotus Notes
  • Le plan consistait à remplir D11 avec l’ensemble des données de D10, puis à archiver D10, mais la situation en 2023 était différente
    • Il restait 8 mois avant la fin officielle du support
    • L’équipe technique a supprimé le contrat de support IBM BPM
    • Aucun système de remplacement n’était en vue ni pour IBM BPM ni pour la base Lotus Notes
    • La solution IBM BPM manque de maintenance et ne fonctionne pas comme nécessaire
    • Une solution inadaptée à l’usage a été forcée dans IBM BPM
    • Une REST API existe, mais elle est presque inutile pour l’équipe technique comme pour les SME
      • Certains appels REST utilisent du JavaScript encodé sous forme de chaîne
      • D’autres appels exigent d’insérer du HTML dans du JSON lui-même contenu dans du XML
      • Les tables de base de données sont interrogées par GUID et non par nom
      • Aucune documentation n’indique à quelle table ou à quel processus correspond tel GUID
    • Les données de D10 n’ont en réalité pas été migrées vers D11, si bien que le métier utilise deux systèmes au lieu d’un seul
    • Le modèle de données de D11 ne prend pas non plus correctement en charge les données de D10
  • Les SME utilisent les outils au quotidien et sont ceux qui déterminent les besoins d’évolution des systèmes
  • Lorsque les SME utilisent VBA, ils peuvent contrôler et maintenir eux-mêmes le système autant que nécessaire, ce qui agit comme une garantie de maintenance que les systèmes IT ne fournissent pas

Le contrôle et les problèmes de collaboration avec les SME

  • Un projet récent visait à créer un nouveau système IT intégré pour remplacer une feuille de calcul critique pour le métier, et en cas de succès l’importance de D6 devait être abaissée au niveau C
  • La spécification initiale était simple
    • Serveur NodeJS et base de données MySQL
    • Interface React
    • Accès au code source et à git pour les administrateurs et les SME
    • Construction du système en collaboration entre l’IT et les SME
  • L’équipe technique a imposé d’autres exigences
    • Les administrateurs et les SME ne pouvaient pas accéder au code
    • Le front-end devait être construit avec Microsoft PowerApps pour respecter la « Strategic Vision »
    • Le back-end devait être construit avec Microsoft Azure Pipelines pour respecter la « Strategic Vision »
  • Du point de vue des SME, ces exigences créent plusieurs problèmes
    • L’équipe technique ne comprend pas le travail métier au quotidien, et a donc du mal à saisir la logique métier et les calculs
    • Lorsque les développeurs écrivent la logique métier, les erreurs sont faciles à introduire
    • L’équipe technique abandonne souvent les projets technologiques sur mesure, ce qui fait disparaître les ressources de maintenance et d’amélioration
    • En collaborant avec les SME, au moins une équipe peut conserver des ressources pour maintenir le système
    • Les SME doivent pouvoir faire confiance au livrable, mais s’ils ne voient pas le code, il leur est difficile de vérifier qu’il fonctionne dans tous les cas limites
    • Même s’il existe des tests unitaires, il est difficile de vérifier qu’ils existent réellement et qu’ils sont exécutés fréquemment si le code n’est pas visible
    • Les SME améliorent et maintiennent déjà les systèmes legacy existants, et possèdent une grande connaissance des interactions entre systèmes
    • Pour vérifier que toutes les données sont correctement migrées et représentées dans le nouveau système, un accès au back-end est nécessaire
  • Lorsque le code reste en VBA, les SME et le métier conservent le contrôle
  • L’équipe technique transfère très peu de contrôle aux équipes métier, tandis que les SME peuvent vérifier que le logiciel est développé proprement de manière modulaire et ne se transforme pas en amas de technologies vaguement raccordées

L’expérience utilisateur dans un environnement familier

  • La plupart des ingénieurs utilisent des feuilles de calcul dans leur travail quotidien
  • VBA est intégré aux feuilles de calcul, ce qui permet d’apporter des outils inconnus dans un environnement familier
  • Pour les utilisateurs, il peut être plus puissant d’introduire de nouvelles capacités dans un environnement familier que de fournir un outil inconnu dans un environnement inconnu

Conclusion : les faiblesses de VBA et un choix réaliste

  • Les raisons pour lesquelles les organisations choisissent les feuilles de calcul et VBA sont nombreuses
    • Les alternatives fournies par l’IT sont faibles à cause des préoccupations de sécurité
    • Les outils alternatifs ne se connectent pas correctement aux systèmes source et sont souvent encore en cours de déploiement
    • Il existe des problèmes de stratégie IT qui ne reflètent pas certains cas d’usage
    • Par crainte pour la sécurité et la maintenance, l’IT ne cherche pas à collaborer avec les SME
    • Les utilisateurs, administrateurs et SME ne reçoivent pas une formation suffisante sur les systèmes de remplacement
    • Les utilisateurs et les SME veulent conserver un certain niveau de contrôle sur la logique métier du système
    • C’est la seule technologie réellement viable, incluse dans Office et utilisable par tous
  • Cela ne veut pas dire que VBA n’a pas de faiblesses
  • Le texte de mataroa n’a pas entièrement tort sur certains points
  • La gestion est parfois mauvaise, mais beaucoup de personnes dans les organisations essaient malgré tout de faire ce qu’il faut avec les outils qu’on leur donne

À lire aussi

1 commentaires

 
GN⁺ 2023-11-16
Avis de Hacker News

  • Dans les entreprises, il existe déjà, dans Excel, un environnement de développement qui permet d’éviter de passer par la direction, la haute direction, l’enregistrement d’un projet, un budget, l’affectation d’un chef de projet, etc., pour faire approuver un logiciel hors catalogue.
    Si l’on veut en plus un stockage de données réseau et une interface web, il suffit d’y adjoindre SharePoint. C’est dans cette logique orientée utilisateur final que naissent les solutions, et ces solutions sont faites en VBA.

    • Dans l’environnement dystopique qu’est l’entreprise, il ne faut pas s’attendre à pouvoir demander ou installer un logiciel sur sa machine. On ne peut utiliser que ce qui est déjà là, et pour changer cela il faut se battre contre la bureaucratie, ce qui n’en vaut pas la peine.
      À une époque, un horrible moteur de rapports écrit en Word VBA lisait des définitions de rapports sur un partage de fichiers, découpait et collait des morceaux de modèles, puis produisait la sortie. L’IT n’avait pas récupéré le PC d’une personne partie de l’entreprise, alors il servait toute la journée à faire tourner des .doc pour générer des rapports d’ingénierie ; c’était bien plus rapide et moins cher que d’acheter l’option de reporting du logiciel de CAD/CAM. Cette option aurait demandé au moins 18 mois, des consultants et l’absorption d’un budget projet.
      Quand on critique les gens parce qu’ils font des choses horribles avec Excel VBA, la cause se trouve très probablement plus haut dans la pile. Une autre cause, c’est le « marteau de singe » : donnez un marteau à un singe, et il tapera sur tout ; si le seul outil disponible est VBA, tout ressemble à une solution VBA. Aujourd’hui, nous sommes devenus des primates un peu plus évolués.
    • J’ai vu au moins deux fois la scène où un responsable de département a besoin de quelque chose, mais ne peut pas, ou ne veut pas, déranger l’équipe de développement, et commence par « ça ne doit pas être si difficile ». On se retrouve alors avec quelques centaines de lignes de VBA qui répondent à son besoin.
      À l’étape suivante, Jim veut aussi l’exécuter, donc le script est copié ; Jane utilise une autre version de VBA, donc il est modifié ; puis on ajoute « et ça aussi ! ». Au final, on obtient un patchwork de 1 500 lignes, dont on essaie de refiler la maintenance à l’équipe de développement.
    • Un ami a automatisé tout son travail avec Excel. Il dit qu’il termine une journée de boulot en 15 minutes, puis se repose le reste du temps.
      L’ordinateur de l’entreprise est très verrouillé : impossible d’installer quoi que ce soit, ni d’aller sur des sites qui ne sont pas sur liste blanche, mais Excel est là.
    • Visual Basic lui-même est aussi un langage très puissant. Dans des environnements comme les macros Excel, on peut en exploiter une grande partie, et beaucoup de power users en entreprise le font réellement.
      Cela ressemble beaucoup à l’ancien paradigme du « système d’exploitation Emacs », appliqué à un autre contexte.
    • VBA est là, et il fonctionne. C’est un langage très accessible et intuitif pour coder et itérer, sans perdre de temps à installer des dépendances externes, à subir l’enfer des bibliothèques ou à passer par une étape de compilation.
      Il n’est donc pas surprenant que VBA reste très précieux en entreprise. Même dans des environnements disposant d’autres outils et langages, ainsi que de procédures de build matures, j’ai vu des product managers réaliser en VBA des analyses métier d’une complexité à couper le souffle, et c’était l’outil adapté au problème qu’ils avaient sous la main.

  • J’ai été surpris de voir que les développeurs professionnels utilisent eux aussi beaucoup Excel/VBA comme outil d’appoint.
    Il y a quelques années, en travaillant avec un grand hedge fund, un data analyst m’a envoyé un modèle Excel qu’il avait construit lui-même ; en voyant l’extension .xlsm, je me suis dit qu’il devait contenir du code VBA. Je me suis dit : « voyons ce qu’ont bricolé ces cow-boys de l’enregistrement de macros », mais à l’intérieur il y avait beaucoup de VBA, et l’auteur était un data analyst diplômé en informatique de Caltech, excellent en Python.
    Le VBA servait à récupérer des données depuis une base, à les mettre dans des feuilles, à créer des formules et à appliquer une mise en forme agréable ; il y avait aussi quelques UserForms. Je l’ai taquiné avec un « Du VBA ? Et vous utilisez quoi d’autre là-bas, une égreneuse de coton et une pelle à vapeur ? », mais, contre toute attente, il a fait de grands éloges d’Excel et de VBA, ce qui m’a surpris.
    Je me souviens de ce qu’il a dit : « Excel rend facile à comprendre la structure de dépendances impliquée par les calculs. Si j’avais fait ça en Python, j’aurais passé la journée à répondre à des questions. »

    • Plus on gagne en expérience comme développeur, plus il devient important d’utiliser l’outil adapté au travail. Une solution paresseuse est parfois bien meilleure qu’un amas d’idées incompréhensibles.
    • VBA a certes des problèmes (https://sancarn.github.io/vba-articles/issues-with-vba.html), mais il est loin d’être le pire des outils. Il est meilleur, par exemple, que quelque chose comme PowerAutomate.
      VB6 a une communauté assez importante, et https://twinbasic.com/ a beaucoup aidé récemment à rapprocher les communautés VBA et VB6. Il pourrait donc y avoir une légère renaissance dans la communauté des développeurs.
    • L’activité que je gère dépend beaucoup de Google Sheets. En injectant des valeurs et en lisant les valeurs calculées, on peut définir une logique métier assez complexe sous forme de feuille de calcul, que les équipes business et finance peuvent ajuster facilement. Tout le monde est très satisfait de cette solution.
    • Excel est une excellente interface pour beaucoup de choses et, jusqu’à un certain point, il aide les gens à comprendre les données. À l’inverse, les gens sont habitués à ce modèle de données et, quand cela devient un peu complexe, ils ont tendance à se blâmer eux-mêmes plutôt qu’à poser des questions.
      En Suède, il existe même un modèle de prévision des retraites Excel/VBA de 3 Go, accompagné d’un manuel utilisateur de 38 pages. Cela dit, il est difficile d’y voir un très bon exemple d’utilisation d’Excel : https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • Une clinique de préadmission chirurgicale d’un grand hôpital universitaire était gérée avec Excel.
      VBA est puissant, et il permet de prototyper et d’itérer rapidement. On pourrait même dire que VB6 était le sommet des applications CRUD.

  • « Parce que c’est étonnant »
    J’ai entendu dire qu’il y avait autrefois plus de 20 000 bases de données Access sur le réseau de JP Morgan. Dans plusieurs entreprises, des analystes de données se sont un jour lassés de leur travail quotidien et ont regardé de plus près le bouton « Enregistrer une macro ». Certains ont trouvé ça assez pratique et ont continué à l’utiliser. D’autres, plus curieux, ont examiné le code généré par les macros, en ont appris un peu et ont essayé de le modifier
    Une minorité est même allée jusqu’à apprendre les structures de données et les algorithmes pour créer des systèmes d’authentification et d’autorisations imitant Django, refaire des interfaces UserForm de zéro, et implémenter Markdown, du parsing SAX, des barres de défilement personnalisées, du logging, voire des jeux
    La réponse est sans doute que les analystes de données se sont ennuyés dans leur travail quotidien

    • C’est peut-être aussi que les services IT, depuis leur tour d’ivoire, imposent tellement de procédures que les gens sont poussés vers le shadow IT. Dans de grandes entreprises, j’ai vu des analystes capables d’amener leurs Frankensteins à un niveau tout à fait correct se faire bloquer par des « il faut lancer un projet, créer des tickets, un planning, des exigences », etc.
      Bien sûr, le fait de devoir maintenir quelque chose que n’importe qui devra pouvoir rejoindre et apprendre est une préoccupation légitime. Mais tant que le métier a accès à des outils pour résoudre ses problèmes, les gens qui « s’ennuient » trouveront un moyen. La friction est trop forte
    • Le bouton « Enregistrer une macro » est essentiel. Même si Microsoft passait à C#, JavaScript, Python, etc., ce serait possible tant que ce bouton est là
    • C’est l’expérience de beaucoup de gens qui commencent dans la finance puis passent à l’ingénierie des données ou à l’implémentation de systèmes
      Construire quelque chose d’un peu complexe dans Excel et le déposer sur un partage réseau est plus simple que de passer par l’IT, installer un IDE, fabriquer quelque chose, puis passer les procédures de sécurité pour le déployer ; je ne pense donc pas que ça disparaisse de sitôt. Tous les problèmes n’ont pas besoin d’un projet Jira et d’une solution excessivement compliquée
      Cela dit, je suis totalement opposé à l’idée de construire de gros systèmes en VBA. Un petit script qui, en fonction de quelques changements de valeurs de cellules, interroge le cube d’un système et le combine avec les données de tables d’un autre système, pourquoi pas ; mais à partir d’un certain point, il faut aller ailleurs
      Pour la plupart des projets, à condition qu’il existe une licence serveur permettant l’automatisation, je préfère de très loin la stack Alteryx+Tableau/PowerBI
    • Honnêtement, j’ai fait quelque chose de similaire, puis je suis passé à C#, et maintenant je suis simplement développeur logiciel

  • Je devais créer une interface CRUD simple pour des analystes
    Le premier problème, c’est que les analystes voulaient gérer toutes les étapes du CRUD dans Excel. Excel étant l’interface réelle, il fallait quelque chose qui puisse s’exécuter dedans
    Le service IT n’autorisait pas l’accès en ligne de commande et refusait aussi l’installation d’outils de développement non approuvés. Obtenir une approbation pouvait prendre des mois. Les administrateurs de bases de données n’étaient pas ravis d’ajouter une nouvelle base à l’Oracle DB existante, et l’IT n’aimait pas non plus l’idée d’exploiter directement une base de données
    Même ajouter un nouvel add-in Excel obligeait à supplier quelqu’un de l’IT. Avec de la chance, l’add-in apparaissait soudain un jour, mais impossible de savoir si ça prendrait une journée, une semaine ou un mois
    La seule alternative réaliste était donc VBA, et nous avons finalement réussi à mettre en place une solution provisoire mais stable que les analystes utilisaient toutes les deux semaines

  • Quand je travaillais dans une agence de renseignement, je devais créer une app pour des personnes déployées en Afghanistan. Les seuls ordinateurs qu’elles pouvaient utiliser étaient des Windows XP verrouillés, sans aucun moyen d’installer quoi que ce soit
    Comme Office était déjà validé et installé, j’y étais coincé moi aussi, même en tant qu’utilisateur de Linux. J’ai créé pas mal de Frankensteins en VBA pur, qui ont été bien accueillis

    • Même expérience de mon côté, ayant été déployé au Moyen-Orient. Sur des ordinateurs XP totalement isolés du réseau, j’ai automatisé autant de choses que possible en VBA
    • Dans une situation similaire, mais pas identique, je m’en suis sorti avec un fichier HTML contenant du code JavaScript dans une balise script. Je me demande si, même sur une machine isolée du réseau, l’exécution d’IE était bloquée, ou si VBA était simplement plus pratique que JavaScript

  • Reconnaissons-le : l’IT est la bureaucratie moderne ; elle passe 95 % de son temps sur des problèmes qu’elle a elle-même créés, et environ 5 % sur l’orientation service. Pour les personnes extérieures, les processus sont opaques et généralement peu utiles.
    J’ai vraiment ri en lisant ce passage dans la description d’IBM BPM, parce qu’il résume assez bien une bonne partie du problème :
    « IBM BPM dispose bien d’une API REST, mais cette API REST est quasiment inutile pour les équipes techniques et les PME. Certains appels REST utilisent du JavaScript encodé sous forme de chaîne, d’autres exigent du HTML dans du JSON dans du XML. Les tables de base de données sont consultées par GUID et non par nom. Il n’existe pas de documentation indiquant quel GUID est associé à quelle table ou à quel processus. »
    Beaucoup de choses sont devenues absurdement complexes, au point que personne en dehors de l’IT ne veut y toucher, et parfois même pas les gens de l’IT. À partir d’AJAX, la moitié de l’effort de développement a commencé à partir dans la conception du code front-end et des services back-end, ce qui n’a en réalité presque rien à voir avec le problème de l’automatisation par l’utilisateur final. Depuis, ça n’a fait qu’empirer, et les interfaces actuelles ont beau avoir l’air modernes, elles sont aussi hostiles à l’utilisateur que la stack technique qui a servi à les construire.
    Dans Excel, l’UI est tout simplement « là », il y a aussi un générateur de code appelé enregistreur de macros, et le service IT ne vient pas discuter mes droits ni me dire qu’il n’a ni le temps ni le budget pour m’aider sur mon problème métier. C’est pour cela que VBA est une voie de contournement permettant aux utilisateurs de court-circuiter l’IT. Ce n’est pas parfait, mais c’est mieux que les autres options.

    • VBA est le langage de programmation agile ultime. L’IT de l’entreprise, c’est-à-dire la bureaucratie, est engluée dans des trucs comme Scrum ou les squads, tandis que les gens des autres services font le travail avec Excel/VBA.
      Rien n’a changé. Cela existait déjà au siècle dernier et on appelait ça des îlots d’automatisation. À l’époque, autour de moi, c’était considéré comme une bonne stratégie : laisser d’abord les services jouer avec, puis intégrer si on voyait du potentiel.
    • Si l’on cherche assez longtemps, on peut trouver de mauvais exemples dans n’importe quel service. Est-ce qu’il y a, parmi les choses gérées par l’IT, des trucs proches de la folie pure ? Bien sûr. Mais ce n’est pas une bonne excuse pour créer de la shadow IT.
      Quelques analystes qui bricolent leur petit outil VBA dans leur coin, ça ne me dérange pas du tout. Cet état d’esprit est même louable, et le résultat peut m’aider à mieux comprendre leur quotidien.
      Ce qui me dérange, c’est quand ces analystes finissent par s’attendre à ce que mon architecture système s’adapte d’une manière ou d’une autre à leur projet personnel. Si je demande de la documentation, il n’y en a pas ; pas non plus de vue d’ensemble de l’architecture ; et si je demande l’accès au dépôt de ce monstre, on me répond : « C’est quoi, un dépôt ? »
      Ils demandent pourquoi leur feuille de calcul ne pourrait pas injecter des données dans mon pipeline de traitement, et estiment que je devrais écrire un contrôleur correspondant au bout de REST qu’ils ont appris en regardant la moitié d’une vidéo YouTube. En réunion, on entend : « Qu’est-ce que ça veut dire qu’il faut une authentification ? Pourquoi l’IT complique toujours tout ? »
      Que les gens créent des outils, que ce soit en VBA, en low-code ou autre, c’est très bien. Je fais la même chose ; simplement, moi j’appelle ça des scripts shell et je les mets dans un dépôt Git. Mais de même que je ne lâche pas mes outils CLI sur des serveurs de production, je ne laisserais pas non plus y aller quelque chose qui n’a jamais passé la moindre revue de code.
    • L’un de mes premiers vrais postes d’ingénieur logiciel consistait à travailler sur le floor de trading d’une banque, assis à côté d’un trader devises.
      J’avais été recruté par le responsable du risque de marché, dont le rôle était d’éviter que la banque ne perde trop d’argent en une seule journée. Il m’avait embauché parce qu’il ne faisait pas confiance au service IT officiellement approuvé pour écrire correctement le code implémentant ses algorithmes. Par exemple, ils s’étaient déjà trompés parce qu’ils ne comprenaient pas la priorité des opérateurs, à savoir que la multiplication passe avant l’addition.
      Le calcul du risque de marché devait prendre toutes les transactions en entrée et, au début des années 2000, j’avais installé Apache et des CGI Perl sur un PC sous un bureau pour créer une petite appli permettant aux traders de saisir leurs transactions et de suivre leurs positions. Les traders ont commencé à la préférer à la solution officielle de l’IT, parce qu’elle était plus facile à utiliser et permettait de visualiser plus simplement les positions.
      Dans beaucoup d’environnements d’entreprise, trouver un moyen de contourner l’IT est une fonctionnalité importante. Pour revenir à Excel, les traders l’utilisaient pour les calculs et les simulations, et nous fournissions des outils qui s’y branchaient afin de tirer parti de ce qu’ils faisaient déjà.
    • Il y a dans l’article une phrase disant que c’est une décision de politique explicite de l’entreprise :
      « Autoriser les utilisateurs finaux à accéder à un langage de programmation de haut niveau va à l’encontre de la vision stratégique technologique de l’entreprise. »
    • La réponse est là. Parce que le seul langage de programmation qu’une entreprise ne peut pas choisir de ne pas installer, c’est VBA.
      Les merveilles de « l’entreprise ». Je suis toujours surpris quand les gens avancent ça comme si c’était un avantage ou une excuse.

  • Parce qu’il n’y avait pas de bonne alternative jusqu’à récemment. L’avenir est dans le nouveau modèle de compléments Office : https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    Quoi qu’on dise de TypeScript, c’est au moins mieux que VBA. Le gros problème, toutefois, c’est que contrairement à VBA, on ne peut pas programmer directement dans Excel. Parfois, on n’a pas envie de lancer un vrai projet de complément pensé pour être réutilisé ; on veut juste un script bricolé à exécuter une fois, tout de suite, pour corriger quelque chose. En utilisant ça, j’ai découvert Script Lab (https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...), qui pourrait peut-être aider.

    • Le fait que, « contrairement à VBA, on ne puisse pas programmer directement dans Excel » est presque une raison rédhibitoire
      Et il y a en plus une question évidente. Un utilisateur sans droits peut-il installer un complément sans intervention du service IT ? Peut-il être intégré dans une feuille de calcul ? Si la réponse au premier point est « non », c’est vraiment fatal ; si la réponse au second est « non », cela nuit aussi à l’adoption. L’avantage des macros et de VBA, c’est qu’à part les paramètres de sécurité, toute instance d’Excel peut les exécuter immédiatement, sans installation supplémentaire.
    • Je n’avais pas vu la mention de Script Lab à la fin du commentaire. Si c’est Microsoft Script Lab, il permet justement de faire cela : https://www.microsoft.com/en-us/garage/profiles/script-lab/
      L’autre problème, c’est que partager un complément avec des utilisateurs finaux n’a rien de trivial. Il faut le publier sur la marketplace ou sur SharePoint, et le sideloading nécessite un serveur SMB et une GPO. Cela dit, il existe une option dont on parle rarement : l’inclure dans le document, afin qu’il soit installé après confirmation de l’utilisateur lors de la première ouverture.
    • C’est bien si l’objectif est seulement d’afficher une belle UI pour la saisie ou la visualisation de données, mais OfficeJS, malheureusement, ne fait même pas la moitié de ce que VBA permet. S’il y avait seulement une FFI dans le système de compléments, je serais passé dessus pour toujours
      Un autre gros problème, c’est qu’utiliser OfficeJS suppose de pouvoir héberger un serveur web. En général, la plupart des utilisateurs finaux n’ont pas ce type d’accès.

  • VB(A), c’est un peu comme Python. Ce n’est pas joli, mais ça fait le travail. Si vous trouvez ça joli, c’est que vous manquez d’expérience et que vous ne connaissez pas beaucoup de meilleures alternatives
    Un outil doté d’un bon écosystème — outils, bibliothèques, intégrations — qui permet de terminer réellement le travail est utile. En tant que système de développement d’applications desktop, Visual Basic, avec MS Access et ses avantages côté base de données, a été très utile dans de nombreuses situations. Et quand on arrivait au point où il fallait aller au-delà, il y avait sans doute aussi l’argent pour passer à une « vraie » solution
    Il ne fait aucun doute que des systèmes basés sur VBA ont généré des sommes énormes. D’après mon expérience, surtout comme intervenant extérieur dans le développement financier, la plus grosse réécriture Excel/VBA que j’aie vue concernait une société qui avait gagné beaucoup d’argent sur les credit default swaps autour de 2008. Avant la réécriture, le classeur mettait cinq minutes à s’ouvrir, mais VBA faisait une grande partie du gros travail. Les personnes qui détenaient le savoir gagnaient beaucoup d’argent en bonus, pour leur entreprise et pour elles-mêmes
    La leçon à en tirer, c’est que le fait qu’un outil soit accessible à des personnes qui n’ont pas été spécialement formées à l’utiliser compte davantage que son caractère idéal. C’est aussi pour cela que Python est devenu numéro un en dehors du navigateur web côté client. Cela ne veut pas dire qu’il est le meilleur, mais qu’il fait le travail et qu’il est accessible.

    • On peut défendre l’idée que Python est un beau langage : c’est un langage complet, avec prise en charge des classes et des fonctions de première classe, tout en restant relativement simple et accessible
      Mais ce n’est pas la seule raison de sa popularité. Il dispose des outils de data science les plus solides, ce qui a créé un effet écrasant, et il a aussi de bons frameworks web comme Django et Flask. Le fait que beaucoup d’universités l’aient adopté comme « premier langage » à la place de Java a aussi contribué à sa popularité. VBA, non.
    • Python est joli, et je trouve que son usage des espaces est meilleur que les stratégies de délimitation de blocs avec accolades, begin/end ou if/else
      Avoir de l’expérience, c’est aussi savoir qu’il y a une part de subjectivité dans ce qui est joli ou non. VBA a évolué dans des conditions « rudes », ce qui explique en partie ses bizarreries.
    • Python n’est pas Scheme, mais parmi les langages de programmation, il fait clairement partie des plus élégants, et dans beaucoup de cas il n’y a pas de meilleure alternative. Je dis ça après environ 25 ans de programmation dans des dizaines de langages.

  • VBA est un langage correct qui prend en charge la programmation orientée objet. Il n’a pas l’héritage, mais il permet la composition. Il offre un accès et un contrôle profonds sur Excel, et il est mature et stable, parce que Microsoft ne le modifie plus beaucoup.
    Si les « vrais programmeurs » détestent VBA, c’est surtout parce qu’il existe beaucoup de code VBA spaghetti amateur écrit par des responsables métier, et qu’on demande parfois aux programmeurs de le déboguer.

    • En contre-argument, VBA est un langage horrible si l’on met de côté le fait qu’il permet d’accéder à Excel, Word, etc. et de les contrôler.
      Il est plein de bizarreries, comme la localisation des caractères de contrôle dans le code.[1][2] Si l’on veut que le code fonctionne aussi sur des installations non anglophones, il faut utiliser des placeholders comme Application.International(xlDecimalSeparator) pour construire dynamiquement les chaînes passées à cette fonction, ce qui nuit fortement à la lisibilité du code. Quand le code casse pour cette raison, les messages d’erreur sont incroyablement peu utiles, et si le développeur ne sait pas que cela peut être un problème propre à VBA, c’est pratiquement impossible à reproduire. Pour le reproduire, il faut changer la langue de l’interface vers une langue qu’on ne connaît pas forcément.
      Au moins dans Word, environ la moitié des fonctions les plus utiles, comme l’insertion d’un paragraphe après le paragraphe courant, cassent lorsqu’elles sont utilisées sur le dernier paragraphe d’une cellule de tableau, ce qui impose quantité de contournements spaghetti.
      Si l’on veut échanger des chaînes de texte contenant plusieurs mises en forme, comme lorsqu’on référence la propriété innerHtml d’un élément du DOM, ce n’est pas facile, sauf à recourir à une sélection scriptée bricolée et à du copier/coller.
      Quelqu’un l’a comparé à Bash dans un autre fil, et je suis en fait d’accord. Il ne faut rien écrire de complexe dans aucun de ces langages.
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • J’ai énormément investi de temps dans la création d’une bibliothèque VBA (https://github.com/sancarn/stdVBA) et j’aime VBA, mais le langage a de vrais problèmes qui le limitent fortement (https://sancarn.github.io/vba-articles/issues-with-vba.html).
      Cela dit, une bonne partie de la détestation dont VBA fait l’objet vient aussi de l’état des projets VBA (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...).
    • Je trouve juste de voir d’un mauvais œil un environnement qui inclut des fonctionnalités mal conçues comme On Error Resume Next.

  • Quand on pense à Excel et aux tableurs dans leur ensemble, beaucoup de gens à l’extérieur ne comprennent pas à quel point le langage des tableurs implémente bien la programmation fonctionnelle réactive. C’est précisément ce que React/Angular essaient de faire correctement depuis plus de 10 versions.
    Beaucoup de gens ne comprennent pas non plus pourquoi les tableurs sont si pratiques pour les utilisateurs finaux, et proposent en conséquence des UI inférieures qui, en réalité, rendent les choses plus difficiles.
    Il faut parfois prendre du recul et comprendre que, même à l’époque où il n’y avait pas d’interface graphique, les anciens avaient vu juste. Les entreprises tournaient déjà au début, et la plupart du temps, ce dont elles ont besoin, c’est d’une vue tabulaire et de la possibilité d’effectuer des calculs de fonctions réactives dessus. Demandez à un ami qui travaille dans une PME, il vous le confirmera.

    • Une grande partie de l’effort en développement web porte sur la présentation. Si l’on n’a besoin que des données, je suis d’accord pour dire qu’il est difficile de faire mieux qu’un tableur.
    • Excel peut être considéré comme le meilleur IDE pour utilisateurs finaux jamais inventé.