[Toutes versions] Que ne peut on pas faire avec Excel ?

comme de bien entendu · 19/12/2011, 10h40

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. ;-)

Daniel.C · 19/12/2011, 13h09

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.

Bluedeep · 19/12/2011, 13h15

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).

comme de bien entendu · 19/12/2011, 13h30

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.)

Ormonth · 19/12/2011, 17h24

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

ZebreLoup · 19/12/2011, 18h42

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.

comme de bien entendu · 19/12/2011, 19h37

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.

jfontaine · 19/12/2011, 21h46

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.

AlainTech · 21/12/2011, 20h56

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.

Ormonth · 21/12/2011, 21h46

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

ZebreLoup · 22/12/2011, 08h32

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.

19/12/2011, 10h40	#1
comme de bien entendu Membre régulier Inscription : janvier 2003 Messages : 254 Détails du profil Informations forums : Inscription : janvier 2003 Messages : 254 Points : 76 Points : 76	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. ;-)
	00

19/12/2011, 17h24	#5
Ormonth Rédacteur Didier GONARD Formateur Développeur Office - indépendant Inscription : février 2008 Messages : 2 353 Détails du profil Informations personnelles : Nom : Didier GONARD Localisation : France, Loire Atlantique (Pays de la Loire) Informations professionnelles : Activité : Formateur Développeur Office - indépendant Informations forums : Inscription : février 2008 Messages : 2 353 Points : 4 685 Points : 4 685	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 __________________ Didier Gonard Ps : Pour noter positivement ou négativement un post, vous pouvez cliquer sur les pouces en bas à droite ! Tutoriels : Voir la liste de mes tutoriels et mon site pro sur ma Page DVP N'oubliez pas de mettre : ..quand c'est le cas !
	10

21/12/2011, 20h56	#9
AlainTech Modérateur Alain Gerard Consultant informatique Inscription : mai 2005 Messages : 3 675 Détails du profil Informations personnelles : Nom : Alain Gerard Âge : 58 Localisation : Belgique Informations professionnelles : Activité : Consultant informatique Secteur : Finance Informations forums : Inscription : mai 2005 Messages : 3 675 Points : 7 669 Points : 7 669	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. __________________ N'oubliez pas de cliquer sur quand vous avez obtenu ou trouvé vous-même la réponse à votre question. Si vous trouvez seul, pensez à poster votre solution. Elle peut servir à d'autres! Pensez aussi à voter pour les réponses qui vous ont aidés. ------------ Je dois beaucoup de mes connaissances à mes erreurs!
	20

21/12/2011, 21h46	#10
Ormonth Rédacteur Didier GONARD Formateur Développeur Office - indépendant Inscription : février 2008 Messages : 2 353 Détails du profil Informations personnelles : Nom : Didier GONARD Localisation : France, Loire Atlantique (Pays de la Loire) Informations professionnelles : Activité : Formateur Développeur Office - indépendant Informations forums : Inscription : février 2008 Messages : 2 353 Points : 4 685 Points : 4 685	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 __________________ Didier Gonard Ps : Pour noter positivement ou négativement un post, vous pouvez cliquer sur les pouces en bas à droite ! Tutoriels : Voir la liste de mes tutoriels et mon site pro sur ma Page DVP N'oubliez pas de mettre : ..quand c'est le cas !
	10

22/12/2011, 08h32	#11
ZebreLoup Membre Expert Sebastien L Ingénieur Financier Inscription : mars 2010 Messages : 880 Détails du profil Informations personnelles : Nom : Sebastien L Âge : 33 Localisation : France, Val de Marne (Île de France) Informations professionnelles : Activité : Ingénieur Financier Secteur : Finance Informations forums : Inscription : mars 2010 Messages : 880 Points : 1 867 Points : 1 867	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. __________________ « Compter en octal, c’est comme compter en décimal, si on n’utilise pas ses pouces » - Tom Lehrer « Il est assez difficile de trouver une erreur dans son code quand on la cherche. C’est encore bien plus dur quand on est convaincu que le code est juste. » - Steve McConnell
	00

19/12/2011, 13h30	#4
comme de bien entendu Membre régulier Inscription : janvier 2003 Messages : 254 Détails du profil Informations forums : Inscription : janvier 2003 Messages : 254 Points : 76 Points : 76	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.)
	00

19/12/2011, 18h42	#6
ZebreLoup Membre Expert Sebastien L Ingénieur Financier Inscription : mars 2010 Messages : 880 Détails du profil Informations personnelles : Nom : Sebastien L Âge : 33 Localisation : France, Val de Marne (Île de France) Informations professionnelles : Activité : Ingénieur Financier Secteur : Finance Informations forums : Inscription : mars 2010 Messages : 880 Points : 1 867 Points : 1 867	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.
	10

19/12/2011, 19h37	#7
comme de bien entendu Membre régulier Inscription : janvier 2003 Messages : 254 Détails du profil Informations forums : Inscription : janvier 2003 Messages : 254 Points : 76 Points : 76	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.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email