Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pensez-vous que VBA n'est pas un langage professionnel ?
Un développeur s'essaie à créer une application de discussion de groupe avec Excel et VBA

Le , par Michael Guilloux

74PARTAGES

10  0 
Considérez-vous VBA comme un langage de programmation professionnel ? Pourquoi ?
Que ça soit sous Excel ou Access, Visual Basic for Applications (VBA) peut parfois permettre de faire des choses extraordinaires, même s’il faut souvent des connaissances très pointues. Vous l’avez probablement remarqué sur developpez.com où Excel et Access disposent de ressources énormes, y compris sur VBA. Mais pour beaucoup de développeurs, VBA -- et parfois VB 6 –- n’est pas considéré comme un langage de programmation pour professionnels. Cela peut être confirmé en partie, parce que le langage semble plus être utilisé par les non-informaticiens en entreprise pour créer leurs propres applications dans le cadre professionnel.

Tristan Calderbank, un passionné de la programmation et de l’électronique a partagé un projet dans lequel il s’est essayé à développer une application de discussion de groupe avec Excel et VBA. L’idée lui est venue lors d’un stage où un autre stagiaire lui a suggéré de trouver un moyen de s’envoyer des messages discrètement à partir de leurs PC sur le réseau local de l’entreprise. Pour ce faire, le choix de Tristan s’est porté sur Excel et VBA. Avec des feuilles Excel et du code en VBA, il a mis en place une application peer-to-peer avant de la transformer en une application de type « client-serveur », toujours avec Excel et VBA.

L’idée de départ consistait à créer deux classeurs Excel sur un lecteur du réseau local. Sur une feuille, chaque classeur contient une cellule « Send Message » et « Inbox ». La cellule « Send Message » correspond au message envoyé et la cellule « Inbox », au message reçu. Pour que ça marche, c’est simple : il faut faire correspondre la cellule « Inbox » de chaque utilisateur à la cellule « Send Message » de l’autre. En d’autres termes, le message reçu par un utilisateur est celui qui est envoyé par l’autre et vice-versa. Cette étape se fait juste à partir d’une formule Excel depuis la feuille de calculs.


C’est un bon départ, mais cela ne peut pas répondre à des besoins réels en entreprise, même au sein d’un petit service, entre collègues. Il faudrait quelque chose qui pourrait s’adapter à plus de deux utilisateurs et de plus dynamique. Tristan est donc passé à une application de type « client-serveur ». Le projet inclut désormais n utilisateurs (donc n fichiers Excel clients) et un fichier serveur dans un même dossier sur lecteur de réseau local.

Chaque fichier client contient une cellule dans laquelle l’utilisateur insère son nom et une autre pour son message.


Avec du code VBA, le fichier serveur est programmé pour parcourir chaque fichier client dans le même dossier. Il récupère les noms d’utilisateurs et messages dans les fichiers clients et les copie dans une plage dédiée au fil de discussion, comme vous pouvez le voir dans la capture d’écran suivante. Chaque message est précédé du nom de l’expéditeur. Le dernier message apparait sur la dernière ligne de la plage dédiée au fil de discussion et un nouveau message fait remonter les messages précédents d’une ligne vers le haut, pour se positionner à la dernière ligne.


Il s’agit d’un travail qui est loin d’être terminé, avec des imperfections. Mais cela montre qu’on peut aller loin avec Excel et VBA, et VBA de manière plus large, surtout quand on n'est pas informaticien. Comme Tristan l’explique, il peut y avoir des doublons dans le fil de discussion. Mais à part ça, pour améliorer l’application, on pourrait par exemple ajouter dans chaque fichier client l’heure d’envoi des messages. Ce qui pourrait permettre d’afficher les messages par ordre chronologique. Espérons que ce petit projet aiguise l’appétit des spécialistes en VBA de developpez.com, qui pourraient peut-être produire quelque chose de plus opérationnel d’ici peu.

Pour le moment, le code source et les fichiers Excel du projet de Tristan sont sur GitHub.

Sources : GitHub, Excel Messenger (site officiel)

Et vous ?

Que pensez-vous de l’application Excel Messenger ?
Avez-vous déjà réalisé de grandes applications ou effectué des tâches complexes avec VBA ? Partagez votre expérience.
Considérez-vous VBA comme un langage de programmation professionnel ? Pourquoi ?

Voir aussi :

Microsoft lance une API Excel pour Office 365 qui permet aux développeurs d'intégrer les fonctionnalités d'Excel dans leurs applications

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Pierre Fauconnier
Responsable Office & Excel https://www.developpez.com
Le 08/09/2016 à 11:57
Sujet à troll, évidemment...

Qu'est-ce qu'un langage professionnel? J'attends toujours la réponse, et celles que vous pourrez me donner ne me conviendront probablement pas. Cela fait des années que je gagne ma vie en développant des applications professionnelles avec VBA sur Excel et Access. J'affirme qu'elles sont professionnelles car elles répondent aux besoins de mes clients, sont évolutives, et me permettent de payer mon loyer.

Ce n'est pas le langage qui est professionnel, c'est la façon de coder qui l'est ou pas.

J'ai plusieurs fichiers Excel avec pas mal de modules, développés en trois tiers, qui ne buguent pas (ou plus), qui sont liés à de l'Access et ou du SQL Server, qui permettent une consolidation de données et la livraison de tableaux de bord sympas, qui attendent toujours une solution "pro" pour être remisés au placard (et qui attendront encore longtemps...).

On bourre le crâne des IT Managers avec des trucs du genre "VBA c'est mal, Access c'est de la merde, ..." mais un de mes clients a une solution VBA fournie par mes soins qui tourne et qui a été livrée bien avant que le service IT ait pu préciser ce qu'il lui fallait comme cahier des charges mais qui avait répondu que "de toute manière, on est overbookés, ton truc, ça attendra l'année prochaine et ça coûtera bonbon"...

J'ai lu également dans les réponses qu'il était préférable de se tourner vers C# pour développer sous Excel... Oui, pourquoi pas, mais il faut penser que l'outil C# développé, il faudra le déployer (souvent avec droits d'admin sur le poste), ce que ne permet pas toujours le service IT (et ce qu'il n'a pas toujours le temps ou la volonté de faire). VBA, c'est inclus dans les installations Office et il n'y a souvent pas besoin de demander la permission pour développer en VBA.

Alors, pour répondre de façon biaisée à la question trollesque du jour: Langage pro? Je ne sais pas ce que c'est , mais oui, on peut faire du développement professionnel, durable, évolutif avec VBA, souvent à moindre coût et souvent plus rapidement que des trucs en C# et autres.

Et pour ceux qui voudraient se lancer, il y a du boulot et de la demande.
21  0 
Avatar de unparia
Expert éminent sénior https://www.developpez.com
Le 07/09/2016 à 18:10
Bonjour et amitiés
Ma réponse va être très simple et très claire :
La vocation d'un tableur est celle ... d'un tableur.
Utiliser le langage de développement d'un tableur à d'autres fins que la vocation d'un tableur est toujours possible.
Accompagner le code d'appel (et d'utilisation) de fonctions de l'Api de Windows est également possible (mais ce n'est même plus alors du VBA)

Mais tout cela est-il vraiment souhaitable ? Je ne le crois pas

Je m'y amuse de temps à autre, mais uniquement pour me divertir.
Pour tout résumer : il est toujours possible de raboter une planche à l'aide d'une perceuse que l'on a dotée d'un disque abrasif ou d'une ponceuse dotée d'un papier abrasif. Un professionnel ne s'y égarera pas et utilisera l'outil adéquat pour ce faire. Il n'utilisera toutefois pas non plus ce dernier outil pour poncer, mais alors une ponceuse.
Ce n'est là que mon avis.
17  3 
Avatar de Omote
Membre averti https://www.developpez.com
Le 07/09/2016 à 21:17
Qu'est-ce qu'un langage professionnel? Au même titre qu'un AutoIT ou bien un AutoHotkey c'est l'usage que l'on en fait qui le professionnalise. L'outil professionnel Test Complete utilise, entre autre, le VBScript pour écrire des tests et cela m'arrive souvent de faire encore des batchs car j'ai moins de connaissance en PowerShell. Donc le VBA a sa place... mais uniquement dans le tableur (comme le fait remarquer unparia) pour faire des opérations sur les tableaux. Utiliser un tel langage pour monter un programme complet c'est contre productif et donc non professionnel. Ce qui montre que ce n'est pas le langage qui n'est pas professionnel mais son utilisation.

Après est-ce que c'est un bon langage? Personnellement, je trouve cela horrible et le peu de fois que j'y ai touché, cela s'est résumé à du copié/collé depuis internet en modifiant les variables. C'était sur des feuilles Excel sans pérennité donc je pouvais me le permettre. Mais je n'aimerai pas devoir supporter ce genre de programme.

Maintenant j'ai vu un vieux formulaire qui traîne dans la compagnie avec une communication vers SAP pour la gestion du stock. Cela date d'une époque où la personne qui a monté cela n'était pas programmeur. Cela perdure car c'est de moindre coût tant que cela ne casse pas et que la production est habitué à l'utilisé. Alors pourquoi changer ce qui fonctionne. À refaire quelque chose aujourd'hui, un site web serait surement monté. Encore une fois, c'est l'utilisation qui est faite de l'outil qui est professionnel ou non, pas le langage.
13  0 
Avatar de Menhir
Expert éminent sénior https://www.developpez.com
Le 08/09/2016 à 12:00
Dans le cadre de ma profession je crée (parfois) des applications avec VBA.
Donc, par définition, j'utilise VBA comme un langage professionnel.

Sinon, il faudra expliquer ce qu'est un professionnel.
Il faudra aussi expliquer ce qu'est un informaticien. Il y a 50 ans, un opérateur de données était considéré comme informaticien. Aujourd'hui, une personne qui développe des programmes n'est pas forcément considéré comme un informaticien. Plus l'informatique évolue, plus l'application de cette étiquette devient floue.

Mais je ne comprends pas vraiment l'intérêt de la question, à part le plaisir de se faire des nœuds au cerveau et d'accentuer les clivages élitistes.
11  0 
Avatar de sacapuces
Nouveau membre du Club https://www.developpez.com
Le 09/09/2016 à 18:44
Vous n'avez peut être pas remarqué, mais tous les langages possèdes les mêmes instructions et les mêmes architectures.
Tant qu(il y aura des "if", des "case" , de "for", des "while"... etc etc j'en passe et des meilleures
cela s"appellera toujours un langage de programmation.

On peut faire des merveilles en Basic
On peut faire le pire en "C++"

Le reste est une affaire de programmation de débrouille, et de neurones.

Sacapuces : Vieux programmeur qui a connu les cartes perforées, les araignées écrasées dans les bandes magnétiques, et les HDD de 250 Ko
(si si..vous avez bien lus)
11  0 
Avatar de patricktoulon
Inactif https://www.developpez.com
Le 08/09/2016 à 23:43
Bonsoir a tous

perso j'ai développé mon app avec exel VBA

éditeur de commande
mailing
facturier
devis
bilan mensuel/trimestriel
TVA
calendrier
planning pour mes employés
et j'en passe

le tout dans un même classeur!!!!!
je m'en sert depuis 2009 que j'ai ouvert
de temps en tant je met a jour ou au propre quand je trouve le moyen de coder plus proprement
on est en 2016 et toujours pas planté
alors bien sur une entreprise ayant 200 employés se tournera peut être sur un développement plus conséquent

mais pour une petite boite comme la mienne c'est parfait !!
oserais-je vous parler de l'application que j'ai payé!!!!!! et qui a été développé pour moi (2300€) et !!!restez assis!!!!! n'a jamais fonctionné correctement a un tel point que j'ai stoppé le développeur qui passait 3 fois par semaine a l'atelier pour déboguer

alors le nez dans la panade j'ai mis les mains dans le cambouis et en tant qu'amateur c'est ca qui est drôle j'ai fait mon app pro

c'est meme devenu pour moi une passion et un dé-stressant

alors pro/pas pro faudrait déjà savoir ce que ca veux dire et dans quel contexte

ca c'est mon opinion
a+
11  1 
Avatar de Simplifi
Membre expérimenté https://www.developpez.com
Le 26/10/2016 à 12:11
Bonjour à tous,
pour moi le langage n'est que l'expression de la pensée du programmeur. Si la pensée est claire et affinée, quasiment n'importe quel langage conviendra, même VBA! Par contre aucun langage ne comblera les erreurs d'analyse. Je dirais même qu'un langage permettant des notions tortueuses n'obligera pas l'utilisateur à simplifier sa pensée, ce qui est absolument indispensable, ne serait-ce que pour la maintenabilité.
10  0 
Avatar de Pierre Fauconnier
Responsable Office & Excel https://www.developpez.com
Le 08/09/2016 à 13:21
Citation Envoyé par Marc-L Voir le message

[...]
Souvent VBA est une solution provisoire pour surseoir à l'incompétence de certains
(le nombre d'extraction pourries d'ERP ou de bases de données alors que c'est pourtant possible)
[...]
Tellement vrai! Je ne compte plus les fichiers Excel dans lesquels j'ai dû écrire des routines de nettoyage parce que les "gros bras" (payés deux fois mon salaire journalier) n'étaient pas fichus de sortir des tables à plat d'un des ERP les plus répandus (ça commence par S, ça finit par P et c'est en trois lettres avec un A au milieu).

Si ces "professionnels" faisaient correctement leur boulot, il suffirait de mettre un TCD en place sans aucune ligne de code pour permettre toutes sortes d'analyses.

Alors, qui est professionnel et qui ne l'est pas?
9  0 
Avatar de joe.levrai
Expert éminent https://www.developpez.com
Le 09/09/2016 à 21:06
Bonjour à tous,

je poste également mon avis ... ou plutôt mon absence d'avis tranché.

A vrai dire, ça va plutôt ressembler à une tranche de vie.

Je ne suis pas informaticien. Pour des raisons pratiques, je me suis mis au VBA afin d'automatiser des petites virgules sur des fichiers excel. Le but était de sortir rapidement des chiffres. Bref, un basique.

Et puis, le temps faisant, j'ai petit à petit complexifié les traitements, établi des formulaires pour que mes équipes puissent renseigner leur activité.

Un jour, ma société (une PME de taille moyenne-grosse) m'a proposé d'user de ces connaissances pour développer des applications complexes, gérer des quantités de données impressionnantes, de sources diverses (SAP - Oracle - SteamServe - SharePoint - Outlook - autres divers et variés)

Je n'avais qu'une contrainte : tout devait être 100% Excel, impossible d'utiliser Access ou d'investir dans des logiciel ou missionner des prestataires pour développer des solutions plus adéquates.

3 ans ont passés, mes applications sont toujours là, elles évoluent, donnent naissance à des enfants, s'enrichissent de colatéraux. Parfois même se voient adoptées par des parents pour les piloter.

Aujourd'hui, ce sont des 100aines d'utilitaires, des base de données (relationnelles ou non) hébergées dans des fichiers Excel, des workflow développés dans Outlook, avec remontée des données (volumétrie, horodatage, cohérence, dispatch etc...) vers Excel. Bien sûr, des reportings partant de Excel et adressés via Outlook, des automation sur des logiciels tiers, j'en passe et des meilleurs ... Des connexions sur des SharePoint (avec parfois manipulation des WebServices).

Bien entendu, tout est écrit dans Excel, avec liaison tardive pour les bibliothèques externes
Et j'ai bien conscience que beaucoup qui me liront, arrivés à ce stade du message, auront les cheveux hérissés sur la tête (s'il leur en reste !)
Je répondrai uniquement : ça marche, ça évolue, et malgré les volumes de données et d'interactions ça répond au doigt et à l'œil (au prix de pas mal d'hectolitres de café, je l'avoue ... et de la motivation).

Pourquoi vous raconter tout ça ?

Tout simplement pour dire que tout le monde a un peu raison et tort sur ce sujet dans le fond.
Je pense que la question n'est tout simplement pas la bonne.

Elle devrait plutôt être : A partir de quand VBA devient une solution déraisonnable ?
Voici ma réponse, ou plutôt mes trois réponses possibles :

- quand les besoins dépassent la capacité des développeurs à les solutionner
OU
- que les solutions apportées représentent une économie trop faible au regard d'une solution passant par d'autres outils/langages
OU
- que les besoins ne sont pas standardisables (et nécessiteraient de nombreuses réécriture au fur et à mesure)

VBA offre des avantages non négligeables, notamment :

- facilité d'apprentissage (j'ai appris seul à coup de nuit blanche et de lecture du forum)
- communauté et documentation importante sur le net en cas de souci
- possibilité (c'est un bien et un mal) de détourner complètement l'usage d'une application pour la retailler (Ils ont été assez supris mes auditeurs Microsoft quand je leur ai dévoilé notre organisation Outlook, qui est devenue une application métier totalement customisée et branchée sur un millier de boite mails partagées). Bien sûr, il ne faut pas faire la fine bouche et accepter deux faits : la solution ne sera pas la plus rapide ET devra nécessairement passer par une réflexion d'algorithmique beaucoup plus poussée
- capacité des procédure à manipuler d'autres langages

Egalement des inconvénients, comme celui du "A" de VBA
Mais dans ce cas là, il reste le Vb, Vbs, VB.NET etc....?

Ma conclusion sera semblable à beaucoup d'autres. A ceci près que je suis plutôt à ranger dans la catégorie des "amateurs qui ont probablement des choses à apprendre à certains se déclarant des pro".

Ce n'est pas le langage qui est le moteur de la réponse, ni même les compétences de celui qui développe.
C'est la fonction qui fait l'organe.
J'irai même jusqu'à dire que la qualité du code importe peu. Que ce soit codé de façon optimale ou totalement hors de toute logique ....

Ce qui compte c'est de se demander si le projet développé est :

- nécessaire (histoire de ne pas créer des fonctions personnalisées qui font des SOMME() simples)
- possible dans le langage souhaité (histoire de ne pas chercher à faire un clavier de piano sur Excel ... encore que .... )
- conforme aux attentes de celui qui a commandé "la chose"
- réversible, convertible, évolutif
9  0 
Avatar de Hephaistos007
Expert confirmé https://www.developpez.com
Le 16/09/2016 à 14:14
Lorsque j'était étudiant en informatique, on ne m'a jamais enseigné le VBA, car considéré comme "pas noble", sans trop savoir pourquoi au final. Cela continue aujourd'hui dans les filières informatique "pures". Le hasard a fait que j'ai été amené à enseigner le VBA Excel à des étudiants et des professionnels. Voir mon cours ici.
Et bien finalement, je suis forcé d'admettre que cette technologie n'est pas si mauvaise, voir même plutôt bonne, mais qu'elle souffre surtout de problèmes externes :

Les +

Le noyau du langage est tout à fait correct (structuration en module, nuance fonction/procédure, système de types, gestion d'erreurs, etc.) et son orientation objet n'a pas à rougir d'autres langages (classes, membres de classes, instanciation, public/private, getter/setter, auto-référence, classe d'énumération, etc.), avec un système d’événements qu'on appellerai "callbacks" aujourd'hui. Idem avec les appels asynchrones http à des webservices, qui avait fait le buzz en JavaScript avec "Ajax". Tout cela est présent, mais en plus discret.

Les -

La communauté historique qui utilise le VBA n'est pas informaticienne de formation. On y trouve pelle-mêle des gestionnaires, des comptables, des secrétaires et des scientifiques d'autres domaines. Il en résulte des tutoriels idiots (sans aucun recul sur ce qui est fait) et des forums pleins de codes absolument horribles. La permissivité de VB sur certaines notations objet n'a pas arrangé la chose je dois dire. De plus, l'existence d'un ovni appelé "enregistreur de macro" a enfoncé le clou, avec l'exploit de générer un code incompréhensible et de ne jamais avoir résolu le moindre problème algorithmique de la terre.
Mais ce qui a achevé VBA selon moi c'est un très mauvais "explorateur d'objets", une sorte de documentation de l'API Excel contenant d’innombrables inconsistances : des sub qui sont en fait des function et vice-versa, des types de retour non mentionnés, des types Object ou Variant (démerdez-vous avec ca !), des paramètres non typés ou oubliés, etc. Pendant ce temps là, l'API Java et son mécanisme JavaDoc produisait des documentations impeccables qu'exige la rigueur de la programmation.
9  0