Discussion :

[clementmarcotte]

Bonjour,

Avec VBA, il y en a trop qui font l'ânerie de vouloir transformer Excel en Access. Comme s'il suffisait qu'un psychiatre dorme une nuit pour installer une prothèse de la hanche.

[Pierre Fauconnier]

[...]

Mwouais... On n'a pas toujours le choix des armes, pour de multiples raisons. Mon expérience m'a amené à être pragmatique et à développer en Excel de la gestion de données, simplement parce le client, après d'âpres discussions, voulait Excel et un seul fichier, et rien d'autre (même pas un mdb lié à Excel, juste une fichier xlsm). Et les raisons du client l'emportaient sur la volonté de mettre en place les bonnes techniques.

je ne suis pas sûr que ce soit toujours un choix "d'âne" que de vouloir (devoir) "refaire de l'Access" avec Excel... Bien sûr, tu peux aussi refuser le boulot et le laisser faire à d'autres "plus ânes" que toi. Tu peux aussi développer des outils +/- génériques pour gérer les données au sein du fichier Excel, en spécifiant au client les limitations d'un choix qui, in fine, reste le sien.

Et perso, j'ai pris du plaisir à développer un framework générique de gestion de données avec Excel, qui me permet de répondre rapidement à des besoins de clients qui font le choix d'Excel "pur et dur", à nouveau pour des questions qu'il ne m'appartient pas de juger ou de remettre en question...

Ne pas trop vite juger le travail ou le choix des autres par mon petit bout de lorgnette, c'est quelque chose qu'une expérience de plus de vingt ans d'indépendant en IT m'a permis d'apprendre...

[clementmarcotte]

Bonjour

Mwouais... On n'a pas toujours le choix des armes, pour de multiples raisons. Mon expérience m'a amené à être pragmatique et à développer en Excel de la gestion de données, simplement parce le client, après d'âpres discussions, voulait Excel et un seul fichier, et rien d'autre (même pas un mdb lié à Excel, juste une fichier xlsm). Et les raisons du client l'emportaient sur la volonté de mettre en place les bonnes techniques.

je ne suis pas sûr que ce soit toujours un choix "d'âne" que de vouloir (devoir) "refaire de l'Access" avec Excel... Bien sûr, tu peux aussi refuser le boulot et le laisser faire à d'autres "plus ânes" que toi. Tu peux aussi développer des outils +/- génériques pour gérer les données au sein du fichier Excel, en spécifiant au client les limitations d'un choix qui, in fine, reste le sien.

Et perso, j'ai pris du plaisir à développer un framework générique de gestion de données avec Excel, qui me permet de répondre rapidement à des besoins de clients qui font le choix d'Excel "pur et dur", à nouveau pour des questions qu'il ne m'appartient pas de juger ou de remettre en question...

Ah, c'es sûr que le client a toujours raison et qu'aucun développeur ne peut refuser d'exécuter la commande reçue.

Ne pas trop vite juger le travail ou le choix des autres par mon petit bout de lorgnette, c'est quelque chose qu'une expérience de plus de vingt ans d'indépendant en IT m'a permis d'apprendre...

Je ne peux pas de donner tort dans l'absolu. Mais j'avoue que là, ma formation de gestionnaire prend le dessus sur le reste. C'est vrai qu'Access, dans la mesure où il est, disons restreint, à une utilisation spécialisée, un peu comme Project, nous pourrions dire que cela semble faire hésiter beaucoup d'organisations. La plupart vont dire que c'est trop cher. Et, ils semblent croire que pour utiliser Access, il faille payer plus de formation que juste pour Excel. La vérité, c'est que la formation nécessaire, ce sont des bénévoles qui la dispensent sur des forums. Et grâce aux forums, il arrive qu'il soit possible de prévenir les gens qu'ils sont à deux pas du précipice.

Toujours avec ma vision de gestionnaire, il n'y a aucune économie à faire à vouloir transformer Excel en Access ou en Project, ou de transformer Word en Publisher. Les coûts pour juste implanter en VBA dans Excel ce qui existe déjà dans Access dépassent probablement déjà la différence de prix. Ils peuvent sans doute économiser un peu en engageant quelqu'un qui peut réutiliser son code pour économiser du temps, mais Excel ne peut pas gérer des fichiers aussi imposants que ceux qu'Access peut gérer. À toutes fins pratiques, l'utilisation d'Excel devient un frein à la croissance de l'entreprise.

Même que le Runtime d'Access permet de construire une application sur Access et de l'utiliser sur des postes sans Access.

Ce qui m'irrite le plus dans tout cela, c'est le refus de juste envisager des solutions gratuites de SGBD.

Visual Studio Community est gratuit, même pour utilisation commerciale, pour des individus et des boîtes d'au plus 5 programmeurs. Même qu'une grosse boîte peut utiliser VS Community gratuitement pour produire des applications dites "Open Source". Il inclut une version de base gratuite de SQL Server, et il est compatible avec Office Tools for Visual Studio, anciennement Visual Studio Tools For Office. Il y a aussi Microsoft SQL Server Express qui est gratuit et qui peut gérer des bases de 4 Go, ou peut-être même plus. Visual Studio peut également piloter Office à distance. À strictement parler, ce n'est pas par automation, nais c'est tout comme. Il faut quand même modifier un peu les noms d'objets, mais cela n'a rien d'un Calvaire. Même que Visual Studio .net peut écrire n'importe quel fichier compatible Open XML, directement sans passer par Automation. Même que pour Excel, Word et PowerPoint, il y a un SDK que MS a mis en Open Source. Même que VB.net (en fait tout langage .net), peut construire une base de données dans un fichier XML qui peut être enregistré sur disque, ou relu, avec une seule ligne de code.

Même si certains intervenants du Forum .net mettent en doute l'appellation SGBD, il y a MySQL.

Et il y a tous les Open et Libre Offices de ce monde.

C'est pour cela que je deviens rouge quand je vois passer dans le même message Excel et base de données

[Pierre Fauconnier]

Clément,

Je te rejoins sur l'entièreté de ton analyse, mais dans la pratique, je la nuance en fonctions des outils qui seront utilisables. J'ai travaillé pour une grosse boîte disposant d'une équipe IT interne avec un DBA. Hors de question pour eux de m'ouvrir l'accès à leur sql server et hors de question d'utiliser Access. Hors de question également de developper en vsto car " ils perdraient le contrôle sur l'outil " malgré que je donnais le code source.

Jai donc développé en vba sur excel. Cest moins rapide, pas partageable et ils ont de toute façon perdu le contrôle de l'outil. "Mieux", ils se le sont fait piquer par un indélicat lorsqu'il a quitté la boite.

Il y a toujours du bon et du moins bon dans le choix des technos. Par pragmatisme et dans la mesure où j'en maitrise plusieurs, j'utilise celles qui constituent, à mon aune, le moins mauvais compromis possible.

😉

[Invité]

Bonjour,
La gestion des parcs informatique ce fait informatiquement par ouverture de ticket!

La demande est formulé par le chef de service qui coche des options.

La machine du nouveau est installé en fonction du bon master et arrive sur le bureau du nouveau comme par magie!

Si sa mission est prolongé , l'ordinateur lui est automatiquement repris si l'informatique n'a pas été prévenu!

Il est plus facile de se passer de quelque que chose plutôt que de l'obtenir pour tous les utilisateurs de l'application!

Le mode production implique des profils généraux!

[Pierre Fauconnier]

Robert,

Ok. Mais à nouveau, c'est dans une certzine taille de boîte. J'ai comme clients des boites de trois personnes et des boites de 700 personnes avec plusieurs sites. Les demandes et les besoins ne sont pas les memes. Et paradoxalement, dans les grosses boites, les services fonctionnent parfois comme des pme distinctes.

Il nexiste donc pas Une configuration qui soit universelle.

[Invité]

Bonjour Pierre,
Je suis d'accord,mais il y a une tel gabegie financière autour des licences petite ou grosse boîte!

Je travail dans une PME et le temps de de définir une personnalisation de configuration d'installation est plus rentable qu'une personnalisation individuel!

La notion du confidentialité n'est pas un lié a Access par exemple! Et pourtant...!

[bigs3232]

merci pour vos conseils fort utiles.je commence à vraiment aimer VBA avec une communauté très active et en francais en plus