Discussion :

[maxoup]

Bonjour,

Dans le cadre d'un projet dans une entreprise, j'ai développé un programme regroupant plusieurs fonctionnalités dans le langage VBA.
On avait choisit VBA car on utilise des fichiers Excel en entrée et en sortie du programme.

L'étape suivante est de partager le programme nationalement dans plusieurs entités.

Je m'interroge si je ne devrais pas reprendre le programme afin de le migrer dans un autre langage, par exemple Java.

Quels sont les avantages et les inconvénients de cette migration ?

Je pense que je gagnerai en stabilité et une meilleur gestion des versions.

Qu'en pensez-vous ?

Merci d'avance.

[Pill_S]

Je ne pense pas que tu gagnerais en stabilité ou en gestion des versions.

-> un programme, VBA ou pas, une fois stable, c'est stable. Java ça se débug plus facilement, ça se monitore plus facilement, mais si c'est stable alors 0 gain.
-> gestion des versions: qu'est-ce que tu entends par là? Gestion des versions d'Excel, ou autre? Mais je doute que Java fasse mieux que VBA dans ce domaine (au contraire même, les spécs Excel étant plutôt fermées, tout du moins historiquement, tout ce que tu trouves dans le monde Java est issu de reverse engineering et rien ne garantit que cela fonctionne vraiment... VBA à l'opposé, c'est plutôt le contraire: fait par Microsoft pour Microsoft)

Tout ce que tu risques, c'est de perdre le "lien privilégié" qu'a VBA avec les applis M$... et aucun gain réellement significatif en vue

Ha et en plus tu risques de forcer tous tes utilisateurs à installer Java... ce qui est chiant et mal compris par les usagers...

[Gugelhupf]

Je préfère largement le Java au Visual Basic .NET, mais pour ton cas je ne vois que des inconvénients.

• Déjà que faire du VBA en C# n'est pas évident, il faudra très certainement passer par un bridge pour Java : du coup pour la stabilité du programme j'ai des doutes.
• Passer par un bridge demande du temps pour se former sur le bridge et la ré-écriture du code.
• Passer par un bridge veut aussi dire qu'il y a un risque de manque de fonctionnalité.

Est-ce une bonne idée de nationaliser un programme Excel/VBA ? Je pense que travailler sur des fichiers Excel+macro n'est pas une bonne idée car on ne peut pas travailler à plusieurs en même temps sur un fichier et on finit toujours par avoir des problèmes de versionning avec une personne A qui possède une version différente du fichier qu'une personne B (sauf si on force les utilisateurs à se servir d'un outil comme le drive de Google).

Bien sur si le fichier Excel en question ne contient que des données brutes (qu'on peut facilement convertir au format CSV), et dont l'objectif sert à contenir les import/export de donnée, n'hésite pas à travailler en Java, tu pourras facilement gérer le versionning de ton programme avec Git/SVN et tes dépendances avec Maven.

[professeur shadoko]

ce que je vais dire ne va pas t'aider .... mais j'ai travaillé dans une entreprise comme ça qui avait le culte d'Excel.
Or vu la taille de l'entreprise (internationale) c'était une pure hérésie du point de vue fonctionnel: on a eu toutes les peines du monde à leur dire qu'il fallait un serveur avec un base de données relationelle.
Et d'ailleurs on n'y est pas toujours arrivé ... je te raconte pas le b**** résultant des diverses versions de fichiers non-cordonnés qui se baladaient dans la nature (par mail) ....
Mais le manager moyen adore Excel même quand c'est pas pour des utilisations "tableur pur".
Donc la question plus fondamentale est: est-ce vraiment une application qui justifie pleinement des fonctions de tableur (ou juste un moyen d'afficher et de consulter des données)?

[Népomucène]

Comme tu as dit que

on utilise des fichiers Excel en entrée et en sortie du programme

Cela veut dire qu'il y a de la saisie et de la restitution et que les données sont stockées dans Excel.

Mais si tu dois "partager le programme nationnalement dans plusieurs entités"
Alors le premier pas est de sortir du stockage Excel qui n'est pas fiable dans cette situation.
Tu dois passer à :
1) la saisie des données avec des écrans "fixes" -> contrôle de la saisie
2) au stockage des données en base de données -> là tu es stable.
3) restitution, pourquoi pas, en Excel ou alors des "Etats"

Quels outils ?
- Access : développement rapide et proche d'Excel. Accès facile aux bases de données (Access, Sql Server, ...)
- Java : développement plus long mais offre plus de perspectives (communication entre entités par mails, FTP, etc ...)
pour la restitution Excel on doit utiliser une bibliothèque spécique (POI par excemple) mais c'est sensiblement équivalent à piloter Excel depuis Access.
choix plus large de base de données.

@Pill_S "un programme, VBA ou pas, une fois stable, c'est stable. Java ça se débug plus facilement"
juste un (petit) bémol tout de même, si l'entreprise a plusieurs entités nationale,
on peut avoir des cas de version d'Excel différentes qui peuvent bloquer.
Sinon, Excel se débogue également très bien (dans la mesure où le VBA est nettement plus limité que Java !!!)

[philou44300]

Parmi les avantages du Java par rapport au VBA: l'exécution multi-platefome.

[maxoup]

Merci pour les contributions!

Avec VBA, on a l'avantage d'installer rapidement le programme. Sachant que c'est juste un copier coller du fichier contenant touts les modules...

Je souhaitais passer par une base de données pour gérer les données propres à chaque entité.
Aujourd'hui, j'ai un fichier qui regroupent ses informations. Si j'ai une donnée commune à toutes les entités, je dois modifier dans chaque fichiers.

Dans cette optique, je pensais qu'en migrant sur JAVA, ca serait plus facile au niveau création et interface avec la base de données.
Je ne suis pas convaincu par ACCESS.

[Népomucène]

je pensais qu'en migrant sur JAVA, ca serait plus facile au niveau création et interface avec la base de données

Non, c'est le contraire. Access a été construit pour faire des écrans rapidement
et communiquer facilement avec le SGBD.

Maintenant, quel est l'objet de l'application, combien d'utilisateurs ?