Que ne peut on pas faire avec Excel ?

Bonjour,
Plus je fais de l'Excel, et plus je m'apercois que l'on peut faire multitudes de choses avec. Notamment on peut faire des applis à partir d'Excel sans même savoir que l'on est dans un tableur à la base.
On peut aussi faire de l'implémentation d'interface facon Java et manipuler des classes. Voir faire de l'héritage en copiant des classes.
D'où cette question : Qu'est ce que l'on ne peut pas faire avec Excel ? (avant que dise cela à la machine à café devant le directeur technique de la boîte. ;-)

Bonjour,

Excel a des limites, par exemple, tu ne peux pas disposer de 257 colonnes si tu utilises Excel 2003 ou 16385 colonnes si tu disposes d'Excel 2010. Excel n'est pas un SGBD. Excel n'est qu'un traitement de texte rudimentaire. Si l'on excepte Office 2010 64 bits qui a d'autres inconvénients, Excel 2010 32 bits ne sait gérer que 2 Go de mémoire etc.

Bonjour,

Citation:

---

Envoyé par Daniel.C

Si l'on excepte Office 2010 64 bits qui a d'autres inconvénients

---

Lesquels ? (ce n'est pas une question pour polémiquer, juste pour savoir).

Bonjour,
Oui effectivement Excel n'est pas un traitement de texte, mais je pensais surtout au moment du choix sur le développement d'une application, où la question peut se poser : Excel, Java ou Autre...
En ce qui concerne les SGBD, Excel n'est certes pas une application de gestion de bases puissante, mais peut servir de frontal.
Dernièrement on vient de remplacer un script PHP qui moulinait par un modèle XLT, avec des SommeProd qui se lancent en une fraction de seconde.
J'ai l'impression que lorsque l'on cherche à faire efficace et rapide, le choix d'Excel peut être intéressant.
J'ai vu des équipes en salle de marché développer des moulinettes pour les traders en Excel/VBA.
Je cherche pas à polémiquer mais à montrer que l'on a un outils qui peut rendre beaucoup de services. (en ce moment j'en suis à ma quatrième application deployée pour la vente de matériels avec des interfaces graphiques très pratiques.)

Bonjour,

déjà à la base, il y a une énorme confusion !

Il ne faut pas confondre Excel et le VBA, aux niveaux Applis que tu cites, je te fais la même chose avec PowerPoint en pilotant Excel à partir du VBA PPT si besoin est.
Mon utilisateur incrédule ne verra que le fait qu'il lui faille ouvrir un fichier PPT pour faire tourner la chose ;)

à partir de là, je peux manipuler des API etc... et je suis bien loin de l'application Office nommée Excel de base.

Reste en dernier lieu à ne pas confondre efficacité et efficience.

cordialement,

Didier

Je pense que le choix de la technologie va dépendre de l'ambition qu'on se donne et de la complexité du projet dans lequel on se lance.

Pour moi, le principal intérêt de VBA est qu'il est assez facile d'accès quand on débute. N'étant pas du tout informaticien de formation, j'ai commencé comme ça, un petit enregistreur de macro, la compréhension des variables, des objets, des procédures, des fonctions... C'est motivant car on peut faire des trucs sympa rapidement. Alors que rien que l'installation d'un environnement de développement peut s'avérer laborieux pour certains autres langages quand on n'est pas averti.
En plus, dans le monde de l'entreprise, Excel est très implanté et l'application sera sans doute accessible facilement pour l'utilisateur.

Je pense qu'on peut vraiment quasiment tout faire avec VBA, mais que ça peut devenir assez compliqué au bout d'un moment.
J'en arrive donc aux limites...

Tout d'abord le temps d'exécution par rapport à un langage compilé. J'ai commencé à programmer en C++, Java, C#, VB.Net pour cette raison. Dès qu'il y avait beaucoup de calculs, je passais d'un temps de traitement sous Excel de plusieurs minutes à seulement quelques secondes.

Ensuite, même s'il y a un modèle objet en VBA, il n'est pas complet. Et pour des applications plus élaborées, l'héritage, le polymorphisme, les interfaces... peuvent nous simplifier la vie. De même, on a souvent des fonctionnalités plus nombreuses incluses dans les frameworks. Je fais plutôt du C# maintenant, et j'avoue que maintenant que j'ai gouté aux joies de LINQ par exemple, j'ai du mal quand je reviens en VBA.

Pour conclure, comme toujours il y a du pour et du contre. Je pense qu'il faut limiter VBA à des applications pas trop complexes même si on peut aller assez loin avec.

Merci pour ces commentaires qui permettent de moduler l'intéret que j'ai actuellement pour cet environnement de développement.

Je suis en train de découvrir les outils statistiques présents par défaut sur Excel et cela permet aussi de faire des choses rapidement. Mais cela est aussi peut être à moduler.

Je voulais souligner qu'avec une certaine expertise Excel on peut apporter des solutions rapides aux différents problèmes de traitement des données. Cela vaut le coup de se pencher sur l'outils pour en tirer le meilleur.
(Dans certaines boites où le SI est lui même très volatile, il y a une majorité d'applications Excel VBA)

Bon après il vaut mieux pour son employabilité penser à étudier d'autres choses. Le tout étant de trouver le temps... Merci au DIF quand il peut être fait pendant les heures de bureau.

Content de susciter des réactions, cela permet de lever le nez du guidon.

Bonjour à tous,

Pour moi qui utilise énormément Excel, j'ajouterais qu'il faut surtout l'utiliser pour ce dont il est fait.

On peut faire beaucoup de chose avec Excel, mais dans bien des cas, il n'est pas la meilleur solution.

Chose que je vois souvent et qui bien des fois m'exaspère => Excel n'est pas une Base de données. :aie:

Bonjour à tous,

Je vais ajouter mon grain de sel.

Je travaille actuellement dans une (très) grande entreprise où les politiques de sécurité sont très strictes.
Pas d'outils de développement dans l'environnement production.

Je suis donc forcé d'utiliser le seul outil disponible dans cet environnement: la suite Office.
Comme tout les utilisateurs n'ont pas Access, il me reste Excel.

Et je fais tout ce dont j'ai besoin à partir du VBA d'Excel.

• Du reporting en allant chercher des données dans des bases Oracle, Access, dBase ou même propriétaires.
• Des outils d'aide au traitement ou à la décision y compris le pilotage d'Internet Explorer ou d'applications propriétaires.
• Si j'ai besoin d'une base de données locale, je crée une base Access à partir d'ADO.

Bref, oui, j'arrive à faire tout ce que je veux depuis Excel qui, dans bien des cas, ne me sert que de support au VBA. Les utilisateurs oublient qu'ils sont dans Excel.

Bonsoir,

très intéressant AlainTech ;)

Car foin des polémiques stériles, le cœur du problème est là, j'ai déjà fait des applis pro où tout se faisait en instance cachée, les utilisateurs n'ayant que des USF pour interfaces.

Les utilisateurs avaient un "lanceur" en raccourci bureau dont la seule tâche était de démarrer l'appli et qui se refermait lui-même et ensuite ils avaient parfois, sous une instance visible, des extractions de données pour des besoins propres non listés en cahier des charges, mais ces données n'avaient aucun lien avec l'appli et représentaient celles de l'appli à un instant "T".

Et comme dit précédemment, c'est la différence entre efficacité et efficience, l'environnement et la volonté client créant le contexte qui fait que 2 situations ne sont par forcément comparables.

C'est un peu le cas d'une TPE dont le bureau d’étude devra tenir compte de l'équipement de la boîte et du planning de charge pour choisir le moyen de fabrication.

Mais encore une fois, c'est le VBA qui en est le moteur et non Excel lui-même.

Didier

Pour ma part je suis aussi sur un poste où je ne peux pas avoir d'environnement de développement et donc j'ai beaucoup travailler sur Excel/VBA, même si ce n'est pas mon principal métier.

Par contre, dans quelques cas, ça ne me suffisait pas (temps de calcul, utilisation de dll tierce, envie de faire de l'objet un peu poussé...) et donc pour ceux que ça intéresse, j'utilise SharpDevelop en version portable pour faire du VB.Net et du C#.

Je suis d'ailleurs assez impressionné qu'ils aient réussi à faire une version portable d'un environnement de développement ! Chapeau !

Il y a quelques désagréments (soit dus à cette version, soit c'est moi qui n'arrive pas à mettre les bons fichiers au bon endroit) comme le fait que dans le débuggeur, je peux mettre un Objet et l'ouvrir pour voir ses propriétés, mais si je mets Objet.Propriété, j'ai une erreur. Je n'arrive pas non plus à utiliser les add-ins de versionning. Mais dans l'ensemble c'est un bonheur. C'est d'ailleurs parfois assez difficile de revenir à VBA à cause de l'intellisense qui n'est pas aussi complète et efficace.

Citation:

---

Envoyé par jfontaine

Bonjour à tous,

Pour moi qui utilise énormément Excel, j'ajouterais qu'il faut surtout l'utiliser pour ce dont il est fait.

On peut faire beaucoup de chose avec Excel, mais dans bien des cas, il n'est pas la meilleur solution.

Chose que je vois souvent et qui bien des fois m'exaspère => Excel n'est pas une Base de données. :aie:

---

Bonjour Elie1211
Il est vrai que l'on peut toujours s'amuser à bricoler en se servant du manche d'un tournevis pour enfoncer un clou, d'une clé à molette pour remplacer une clé à pipe (en faisant moult contorsions et des petits gestes successifs), de deux gros boulons et de leurs écrous pour remplacer (en les maniant en diagonale et avec adresse) une extractrice, etc ... Mais au prix de quelles lourdeurs ??? :roll:
Et je n'ose pas parler d'autres aspects (sécurité, multiutilisateurs, etc ...)

Non ! Excel n'est pas fait pour être utilisé avec autant de souplesse qu'un vrai système gestionnaire de bases de données.:no:

Bonjour,

Citation:

---

Envoyé par Bluedeep

Bonjour,



Lesquels ? (ce n'est pas une question pour polémiquer, juste pour savoir).

---

À partir d'Office 2010, Office est disponible en versions 32 bits et 64 bits (pas juste Office 2010, mais tous les autres après, c'est pareil). Mais Microsoft n'a pas recompilé ses ActiveX VB6 et avant pour qu'ils soient compatibles avec les applications VBA à 64 bits. Donc Calendar, DateTimePicker, ListView et les autres ne peuvent pas être utilisés avec des versions 64 bits d'Office et c'est un vrai problème quand on a des parcs hétéroclites d'office 32 et 64 bits. Également, il y a des appels à l'API Windows qui doivent être réécrits.

Regarde ici pour pousser plus loin

Citation:

---

Envoyé par Elie1211

Si je te montre des bases de données fait avec excel je pense que tu supprimerais ton msg

---

Oh que non. Une base de données ce n'est pas juste des données rangées en tableaux. Il faut assurer la sécurité des données et Excel est un pied bot en matière de sécurité. ET il faut reprogrammer en VBA tout ce qui n'est pas standard dans un SGDB, comme la vérification de l'intégrité référentielle, les mises à jour, les index et un paquet d'autres choses.

Et surtout, contrairement à ACCESS, Excel a toujours besoin de tous ses classeurs ouverts, et des tous les classeurs au complet, en mémoire vive. Et dès que Windows a de la difficulté à fournir la mémoire, c'est le risque de plantage et de pertes de données. Mais bon, si tu penses que c'est trop cher de s'équiper convenablement et que tu préfères payer les amendes en cas de fuite de renseignements personnels, ou que cela ne te dérange pas que tes états financiers se retrouvent entre les mains de de tes concurrents ou de payer pour récupérer toute l'information que tu pourrais perdre en un tournemain, tu peux t'obstiner avec Excel.

Mais quand que pense que l'on peut trouver des SGBD gratuits...

Bonsoir,
Excel est un tableur et a pour vocation de gérer et organiser des tableaux.

bien sur il y a VBA qui permet d'étendre c'est possibilités. si on compare avec ACCESS qui est une base de données relationnelles, qui dispose également de VBA, d'un assistant de requêtage, d'un assistant de formulaire ,et peux exporter ses donnes vers EXCEL.... avec access on peut faire une application sens connaitre VBA!

il est vrai que certaine personnes
ne peuvent compter que sur EXCEL c'est déjà ça!