Conseils pour une utilisation facile d'Excel

bonjour

Organisation générale des fichiers

  • Un ou des onglets de saisie de tes données, en colonnes toutes simples, tu feras. Pour voir tes données ordonnées et synthétisées, des onglets avec TCD et graphiques tu créeras.
  • Un total de 4 classeurs dans ton système jamais ne dépasseras.
  • Jamais de fusion de cellules tu ne feras.
  • jj/mm/aa les dates tu saisiras, et "01/11/18" au lieu de "Novembre 2018" tu taperas

Fonctions à apprendre

  • SI
  • RECHERCHEV

Fonctionnalités

  • VBA tu n’utiliseras pas, mais les menus de ton Excel tu apprendras.
  • Les Tableaux et les TCD de toute urgence tu utiliseras.
  • La fonction RECHERCHEV pour lier des Tableaux entre eux tu utiliseras.
  • Le menu Données tu étudieras de très très près.
  • Pour Excel 2010 et 2013, Power Query tu téléchargeras, et tu ne payeras pas.
  • La mise en couleurs avec des MFC et non à la souris tu feras.
  • Un classeur par an, avec un onglet par mois jamais ne feras.
  • Des tris et des filtres de fou avec un TCD tu feras.
  • Des éléments calculés dans les TCD jamais ne feras (le langage est minable). Power BI tu utiliseras.

Présent et avenir

  • Les extractions et transferts de données avec le menu Données/Obtenir (ou Power Query pour Excel 2010/2013) tu apprendras.
  • Power BI Desktop gratuit pour faire des analyses top du top tu apprendras.

Quand tu sauras tout cela, tu seras un bon utilisateur d’Excel, rapide et apte à répondre à 99 % des besoins

amicalement à tous

Bonjour jmd,

c'est la nouvelle Table des Dix Commandements ?

la règle la plus importante est celle-ci : ne JAMAIS faire de VBA !

la punition serait TERRIBLE ! bien pire qu'après avoir commis la faute du Veau d'Or !

errer pendant 40 ans dans le désert, ce serait de la gnognote, à côté !

"cliquer ici"
screen

dhany

jmd, bonsoir,

Pour tout ce qui est d'une utilisation conforme à un tableur, je suis d'accord avec vous !

Le soucis, c'est que pour beaucoup (et moi le premier) Excel n'est plus un tableur mais une application support pour faire tourner du VBA afin de transformer le tableur en une application "a part entière" comme un bon vieux .exe...

La preuve : Le jeu du pendu...

Voilà, la puissance d'un tableur juste pour servir de support au langage VBA qui peut être assimilé plus facilement grâce à ce support.

J'ai essayé VBE en direct sans le A pour application et j'avoue ne pas avoir tester longtemps car j'ai trouve que tout était plus compliquer car il manquait ce support...

Maintenant, si vous me montrez un jeu du pendu avec PowerQuery et les TCD je pense que je tombe sur mes fesses !

Ou bien alors un site qui explique en prenant "par la main" comment faire une application 100% VBE sans application en support, alors je suis preneur. En effet une application de gestions de stock où tout est "archivé" dans des fichiers ".doc" je trouve cela plus complexe que d'écrire les données dans des cellules de feuilles Excel, mais vous avez raison ce doit être par méconnaissance ou par facilité pour ne pas dire fainéantise !

Donc pour moi Excel va de paire avec VBA (du fait du A) et j'espère m'améliorer afin que ces applications soient encore mieux de jour en jour.

@ bientôt

LouReeD

bonjour à vous

LouReeD,

non, Excel et VBA ne servent plus du tout à créer des jeux ou "applis" (ce fut le cas par le passé).

disons que 99,99% des fichiers Excel font de la gestion de données. Il suffit de lire les questions sur le forum pour le constater.

Et dans ces 99,99% , les 3/4 concernent des bases liées (Excel possède RECHERCHEV pour gérer les liaisons). Mais on a vite des problèmes dès 3 bases.

rem : ce fil ne parle que de gestion de données, comme dit dans son titre. Il est donc étrange que tu y parles de jeux

si on veut faire un jeu ou une appli par lignes de programme, VBA n'est pas la bonne solution car c'est un "mauvais" langage. Il y a en a bien d'autres, plus stables, plus structurés, plus universels, moins sujets aux virus.

il faut être lucide

VBA est un langage qui a eu son heure de gloire

il est aujourd'hui dépassé

mais je peux comprendre que tous ceux qui le maîtrisent le préfèrent.

que conseillerais-tu à tes enfants pour leur avenir d'informaticiens ?

pour moi ce sera Python, R ou C++, en complément d'"Excel avec M et DAX mais sans VBA".

amitiés excelliennes

Bonsoir,

je suis d'accord, si ce n'est sur le 99,99% des sujets

Soit il y en a beaucoup qui parle de classeur de données (d'où le sujet du topic "...gestion de données et surtout parce que ACCESS malgré son nom n'est pas si accessible que ça ! ) mais bien souvent il arrive que dans cette gestion on veuille créer une nouvelle feuille contenant certaines données, qu'on veuille imprimer certaines choses et pas d'autre, en fait on veut se "simplifier" la vie car toutes les demandent sont faisables mais en plusieurs clics.... et plusieurs manipulations.

Je me suis mis à parler des jeux, bien que VBA ne soit pas fait pour cela, mais j'aurais pu parler de gestion de location de chambre, ou bien de gestion de compte. Ce que je voulais dire c'est que pour des débutants comme moi, le fait d'avoir une application support sur laquelle on peut "voir" les effets du code VBA, voir même que ce soit celle-ci qui écrit les lignes de codes en fonction de ce que l'on fait, et bien cela semble plus accessible que certain autre langage qui paraissent obscures.

De mémoire le C++ est moins visuel (moins anglophone) que le VBA, non ?

Quand vous dites : (ce fut le cas par le passé).

je répondrais : c'est encore le cas pour ceux qui se mettent sur Excel aujourd'hui... Que ce soit autour de moi ou ici, beaucoup veulent s'y mettre car les changements comme PowerQuery et autre sont trop flou encore à leur yeux.

Et comme les dix commandements, ceux-ci sont valables avec les nouvelles versions, combien d'employeur aujourd'hui tourne encore avec Excel 2003 ? Même pas 2007 et ses 1 000 000 de lignes et 16 000 colonne ! Non 2003 et ses 256 colonnes avec même pas une par jour !

Il y a un nouveau terme que je n'ai pas sous la main, mais c'est l'illettrisme rapporté à l'informatique, et bien hormis les informaticiens et les greffés du portable il y a encore pas mal de monde pour qui MFC ne veut rien dire.

Bref , oui Excel sert à gérer des données, d'ailleurs Microsoft "fait tout" dans ce sens, non ?

Oui il faut apprendre à connaître Excel, ses menus et ses possibilités.

Mais le VBA est là pour certaine que des TCD ne peuvent pas gérer car la demande "sort" du contexte "gestion de données", c'est juste pour le "skin" l'interface et se faire plaisir

Je m'aperçois que je tourne en rond, je n'essaie pas de convaincre d'utiliser VBA, mais d'un autre coté, en étant sur un forum "VBA" (c'est celui qui tourne le plus) je n'essaie pas non plus d'en détourner ceux qui veulent l'utiliser.

@ bientôt (enfin si vous m'avez compris ! )

LouReeD

Bonjour LouReeD, jmd,

LouReeD a écrit :

ACCESS malgré son nom n'est pas si accessible que ça ! )

c'est vrai pour une application avec plusieurs tables qui ont des liens entre elles, et qu'il faut savoir gérer ; mais pour une application avec une seule table, c'est plutôt très facile ! bien sûr, comme pour tout logiciel (dont Excel et Word), il y a quand même un temps d'apprentissage ; on peut se contenter de saisir les données directement dans les tables, des formulaires instantanés et des états instantanés, ainsi que des types de données choisis par défaut, mais bien sûr, ça sera pas optimum ! on peut affiner après-coup, mais celui qui connaît bien pourra créer dès le début ses tables avec les types adéquats bien précis et optimums, réaliser des formulaires et des états plus élaborés que ceux obtenus automatiquement par les boutons « instantané », et quitte à révulser jmd, même pour une application d'une seule table, VBA peut s'avérer très utile !

à propos, jmd, tu m'avais écrit qu'il n'y a qu'un seul langage VBA, car c'est « Visual Basic for Applications » ; désolé, c'est faux : il y a un noyau VBA commun à tous, auquel une partie a été ajoutée pour gérer les spécificités de l'application et en tirer profit ; exemple : en plus du noyau de base, VBE (= VB for Excel) doit gérer les feuilles, les cellules, et tout ce qui fait partie intégrante d'Excel ; tu penses bien que VBW (= VB for Word) n'a pas besoin de gérer des feuilles de calcul vu que Word en contient aucune ! par contre, il doit gérer les paragraphes, les styles, et tout c'qui fait Word ; ni VBE ni VBW n'ont besoin de gérer des diapositives, mais VBP (= Visual Basic for PowerPoint) doit le faire, lui, forcément ! idem pour le VBA adapté spécifiquement pour d'autres applications Office comme Access (gestion des tables, requêtes, formulaires, états, relations) ; idem pour VBA pour Publisher, pour OneNote, et pour Outlook. pour ce dernier, y'a qu'à lire les codes VBA chargés de gérer les emails (en envoi ou en réception) ; est-ce que cela est inclus dans le VBE ? pas du tout ! Excel ne sait pas gérer lui-même les emails, et n'en n'a aucunement besoin ! car quand on veut par exemple envoyer des mails depuis Excel, il suffit de faire référence à l'API (Application Program Interface) adéquate, en l'occurrence celle d'Outlook ; même chose quand on a besoin de piloter Word à partir d'Excel (exemple : créer directement une lettre contenant des données calculées dans Excel).


note bien que dans un code VBA Excel, la partie qui gère une lettre Word ou un email Outlook ne peut marcher que si on a référencé la bonne API ; sans cela, c'est tout simplement pas possible, puisque c'est pas inclus dans VBE ! mais ce jeu de légo offert par les API rend les choses si subtiles que j'comprends parfaitement qu'tu as pu penser qu'il n'y avait qu'un seul VBA !


c'est volontairement que j'ai pas écrit : « VBW n'a pas besoin de gérer les cellules » ; pourquoi ? pa'c'que Word doit gérer les cellules des tableaux Word, même s'il n'a pas besoin de le faire de façon aussi complète que pour des cellules Excel ; exemple : les cellules des tableaux Word n'ont pas de format numérique ou de protection Verrouillée / Masquée ; et quand on insère dans une page Word un tableau Excel avec liaison, et qu'on double-clique dessus, c'est géré par VBE et non par VBW ; CQFD.

dhany

re

LouReeD,

  • pour faire un jeu, oui il faut VBA mais parce qu''on a mal choisi son programme en prenant Excel.
  • avec Excel, pour faire de la gestion de chambres d'hôtel ou une compta perso ou pro simple, il n'y a aucun besoin de VBA
tout ceci reste vrai pour les anciennes version d'Excel.

note importante : 3/4 des questions sur le forum sont professionnelles (ou personnelles "sérieuses" comme une compta perso) et ne concernent donc pas un "plaisir personnel de hobbyiste". Il faut de la rigueur, de la stabilité, de la durabilité et de la maintenabilité par un collègue. VBA répond mal à ces exigences.

dhany,

certes il y a des fonctions différentes selon la version de VBA pour Word ou pour Excel ou PPoint

mais il s'agit bien d'un unique langage, avec les mêmes règles (ou absences regrettables de règles )

l'insertion d'un objet W dans E ou inversement ne change rien à ce fait.

amitiés à tous

[...]à propos, jmd, tu m'avais écrit qu'il n'y a qu'un seul langage VBA, car c'est « Visual Basic for Applications » ; désolé, c'est faux : il y a un noyau VBA commun à tous, auquel une partie a été ajoutée pour gérer les spécificités de l'application ...

Il n'y a qu'un seul VBA, (pour Application). Il n'y a pas de VBA pour Excel, VBA pour Word, VBA pour FSO, ...

Ce n'est pas une partie spécifique pour chaque application qui est ajoutée mais simplement le fait que la référence à l'application support est implicite (il n'y a pas besoin de la déclarer). Que ce soit dans Excel, Word ou autre la syntaxe du VBA est rigoureusement la même pour peu qu'on ait établi la référence à chaque application utilisée. En outre, le VBE est l'IHM du VBA : le Visual Basic Editor.

Je suis entièrement d'accord avec jmd quand aux problèmes de portabilité et maintenabilité qu'engendre l'utilisation du VBA, il est préférable de s'en passer chaque fois que c'est possible.

Bonsoir Patrice33740,

je ne suis pas du tout d'accord avec toi : j'ai bien longuement expliqué qu'il y a effectivement un noyau VBA qui est le même pour tous les VBA (Visual Basic for Application) ; ce noyau est en grande partie inspiré ou repris de celui du VB (Visual Basic) indépendant ; ensuite, chaque VBA est complété par les spécificités de l'application support (Excel, Word, PowerPoint, ou autre...) pour donner un Visual Basic adapté spécifiquement à l'application, comme VBE (Visual Basic for Excel) ; c'est dans ce sens où je persiste à dire qu'il n'y a pas qu'un seul VBA mais plusieurs ; après, « chacun voit midi à sa porte » !

et de toutes façons, que mon VBE favori soit considéré comme un langage VBA identique aux autres ou non, ça ne change rien à l'appréciation que j'en ai, et j'aime toujours autant l'utiliser !


source Wikipédia :

screen

dhany

@Patrice33740 et jmd

lisez d'abord mon post précédent, puis celui-ci.

screen

dhany

Bonsoir dhany,

Ce n'est ni Wikipédia, ni quelques bouquins de vulgarisation, mais Microsoft qui défini le VBA :

http://interoperability.blob.core.windows.net/files/MS-VBAL/[MS-VBAL].pdf

Et tu remarquera qu'il n'y a ni Workbook, ni Worksheet, ni aucun Objet qui appartienne à l'Application support !

@Patrice33740

tu a écrit :

Ce n'est ni Wikipédia, ni quelques bouquins de vulgarisation, mais Microsoft qui défini le VBA

je suis entièrement d'accord là-dessus !


tu a écrit :

il n'y a ni Workbook, ni Worksheet, ni aucun Objet qui appartienne à l'Application support !

ben oui, c'est normal : ta doc est pour le noyau VBA dont j'parlais, et c'est ce noyau qui est identique pour toutes les applications Office.


extrait de ta doc :

screen

1.3 Vue d'ensemble des spécifications du langage VBA

VBA est un langage de programmation pour ordinateur qui est censé être utilisé en conjonction avec une application logicielle hôte telle qu'un traitement de textes. Dans une telle situation, l'utilisateur final d'une telle application hôte utilise le langage VBA pour écrire des programmes qui peuvent accéder aux données et aux fonctionnalités de l'application, et aussi les contrôler.


alors par rapport à Excel : tu as écrit que ce VBA ne contient aucun objet de l'application hôte (ni Workbook, ni Worksheet ou autre) ; exact, vu que c'est le noyau ; mais alors, c'est bien car une autre partie y a été ajoutée pour former le VBE (Visual Basic for Excel) qu'on peut écrire des codes VBA qui peuvent manipuler des objets Excel : un classeur Excel (Workbook), une feuille de calcul (Worksheet), des cellules (Range), etc... CQFD !

Word ne contient pas de classeur Excel, ni aucune feuille de calcul, ni beaucoup d'autres choses propres à Excel : son VBA n'a donc pas besoin de les gérer ; par contre, il doit gérer les paragraphes, styles, et autres particularités de Word ; comme le noyau du VBA de Word est identique aux autres, il faut bien, forcément, que là aussi, une autre partie lui ait été ajoutée pour pouvoir écrire des codes VBA gérant les objets de Word !

c'est donc ces différentes parties ajoutées qui font que VBA n'est pas un seul et unique langage ! le noyau seulement : oui ; mais c'est tout !

donc ta doc Microsoft elle-même me permet de confirmer ce que j'ai écrit ! re-CQFD !


maint'nant, si jmd ou toi vous tenez absolument à penser qu'y'a un seul et unique VBA, ça m'dérange pas du tout ! mais si un jour on m'avait dit qu'jmd allait s'convertir au monothéisme VBA, j'l'aurais jamais cru !!!


comme déjà écrit dans un post précédent, que VBA soit un langage unique ou non, ça change rien à mon utilisation perso d'VBA.

dhany

Bonjour,

@[dhany

Comme tu l'as très justement écrit :

[quote=dhany post_id=710490 time=1543280074 user_id=51200]

1.3 Vue d'ensemble des spécifications du langage VBA

VBA est un langage de programmation pour ordinateur qui est censé être utilisé en conjonction avec une application logicielle hôte telle qu'un traitement de textes. Dans une telle situation, l'utilisateur final d'une telle application hôte utilise le langage VBA pour écrire des programmes qui peuvent accéder aux données et aux fonctionnalités de l'application, et aussi les contrôler.[/quote]

Rien n'est ajouté, C'est tout simplement que VBA utilise les fonctionnalités qui existent déjà dans l'Application référencée.

PS : C'est là l’intérêt du VBA, une simple référence permet d'utiliser les fonctionnalités d'une application qu'elle soit MS ou autre.

Bonjour Patrice33740,

j'ai écrit : « car une autre partie y a été ajoutée pour former le VBE (Visual Basic for Excel) »

par « ajoutée » je voulais parler d'une extension VBA par rapport au noyau de base.

dhany

par « ajoutée » je voulais parler d'une extension VBA par rapport au noyau de base.

Mais il n'y a aucune extension, tout ce que tu décris, sont des fonctionnalités qui existent dans Excel, Word, ... pour leur propre fonctionnement, indépendamment du VBA.

VBA ne fait que "s'y connecter".

tu a écrit :

des fonctionnalités qui existent dans Excel, Word, ... pour leur propre fonctionnement, indépendamment du VBA.

oui, et heureusement ! j'suis d'accord avec ça ! c'est bien des fonctionnalités de l'application, qui existent déjà ; mais pour ce qui est de pouvoir les manipuler par VBA, le noyau de base ne le peut pas, lui, car ce noyau commun de tous les VBA ne connaît pas les spécificités d'une application ; et c'est justement pour ça que Microsoft a dû développer une extension du langage VBA propre à chaque application ; et c'est cette extension qui peut gérer les fonctionnalités propres de l'application ; c'est aussi cette extension spéciale pour chaque application qui fait qu'il n'y a pas qu'un seul VBA ; exemple : le VBE d'Excel : « Visual Basic for Excel ».

dhany

bonjour à vous

au-delà de la discussion VBA ou VBpourexcel, il faut reconnaître qu'on peut s'en passer et qu'on DOIT s'en passer

je cherche plutôt à compléter mes conseils du message #1 de ce fil. Lâchez-vous

amitiés à tous

connaissez-vous Microsoft Flow ?

[...] VBA ou VBpourexcel, il faut reconnaître qu'on peut s'en passer et qu'on DOIT s'en passer

je cherche plutôt à compléter mes conseils du message #1 de ce fil. [...]

Bonjour jmd

Entièrement d'accord, tu peux y ajouter les 13 règles d'or de Gaëtan Mourmant :

http://www.xlerateur.com/divers/2010/05/14/les-13-regles-d%E2%80%99or-pour-utiliser-excel-comme-gestionnaire-de-donnees-612/

Tiens ce fil m'avait échappé ! Bonjour tous !

Quand on joue sur les mots, les discussions peuvent s'allonger indéfiniment !

Le langage de programmation en tant que tel est unique, mais est bien décliné en versions par application...

2018 12 04 162648

En ouvrant le menu Outils > Références de l'éditeur dans Excel on peut vérifier que la référence à la bibliothèque d'objets Excel y est automatiquement établie. Ce qui ne sera pas le cas si on ouvre Word ou Powerpoint...

C'est ce qui permet en travaillant avec VBA pour Excel d'avoir accès directement aux composants d'Excel.

Par ailleurs, je persiste toujours à ne pas comprendre les oppositions que l'on fait entre VBA et des fonctionnalités d'Excel. L'intérêt ou non d'utiliser VBA pour telle ou telle chose peut s'apprécier selon des critères très divers, mais dès lors que l'on peut trouver un intérêt, même minime, à utiliser VBA, si l'on s'en sert pour actionner les fonctionnalités Excel, elles ne seront pas actionnées différemment que si l'on opérait manuellement. Je ne vois vraiment pas pourquoi un TCD ne devrait pas être actualisé par une procédure VBA.

Cordialement.

Rechercher des sujets similaires à "conseils utilisation facile"