Bonjour à tous,
 
Pour résumer rapidement, j'ai à créer/gérer/maintenir des fichiers Excel/VBA, qui une fois validés sont envoyés aux utilisateurs qui les dispersent un peu partout.
Mon problème est la gestion et la maintenance de ces fichiers, qui sont actuellement une grosse perte de temps.
Je n'ai pas trouvé beaucoup d'informations à ce sujet, j'hésite pour le moment entre deux choix simples :  
 

• Laisser les fichiers aux utilisateurs et aller les modifier là où ils sont (soit à la main, soit automatiquement, mais comment.. ?).
• Faire venir les utilisateurs aux fichiers, de cette façon les fichiers seraient rangés hiérarchiquement et la maintenance serait simple et rapide. Je pense ici à les héberger sur un serveur et les rendre disponibles via un site intranet.. C'est une ébauche de solution qui me semble bonne, cependant je n'ai aucune idée des ressources nécessaires à un tel serveur...

Je suis preneuse pour tout lien, idée, ou même solution, merci d'avance    
 

La seule solution me parait être une action rationnelle et scientifique.
 
1. Délimiter le périmètre de ce processus. Donc, trouver tous les éléments atomiques qui le constituent, y compris les éléments qui sont supposé exceptionnels, car il arrive fréquement que cela soit rapide en temps normal, mais que cela devienne très lent à cause de cas particuliers, par exemple à cause de corrections d'erreurs.
2. Mesurer scientifiquement le temps de traitement de chaque élement atomique du processus.
3. Voir et réfléchir aux réultats trouvés.
4. Trouver des idées pour réduire le nombre d'éléments.
5. Trouver des idées pour réduire le temps de chaque élément.
6. Vérifier si les solutions trouvées sont vraiment intéressantes
 
Eviter les erreurs suivantes très courantes :
- Sous-estimer des cas particuliers.
- Ne pas proposer une autre solution sans avoir évaluer si elle était réllement plus performante que l'ancienne.
- Oublier que l'erreur est humaine, et qu'il faut toujours pouvoir revenir en arrière.
- Oublier que les ordinateurs, les réseaux peuvent tomber en panne et donc qu'il faut avoir des sauvegardes.
 
Bon courage !

Merci de ta réponse, mais que veux-tu dire par temps et élément ?
Pour moi mon système se schématise sous forme hiérarchique, différents fichiers dont la plupart sont attribués à différents utilisateurs.  
Concrètement je souhaite disposer d'un catalogue de fichiers fiables et rapides, ce qui est faisable, le problème commence à partir du moment où je diffuse ces fichiers, c'est là où je perds la maitrise de la gestion du système.
C'est pourquoi je pensais à la deuxième solution, c'est-à-dire faire venir les utilisateurs aux fichiers plutôt que l'inverse.  
Cependant je n'ai pas vraiment d'idée des ressources nécessaires à la mise en place de ce projet.
 
En ce qui concerne la première solution, elle consisterait à accepter une perte de temps et une perte de maitrise, concrètement je pensais à faire, lors de mises à jour, un patch sous forme de fichier excel qui placé dans le même dossier que le fichier à Màj remplacerait l'ancien module à mettre à jour par le nouveau.  
Les limites de ce système seraient :  
 

• Trouver le dossier où se trouve le fichier à Màj (jusqu'à 40 fichiers dans des répertoires différents..),
• Pas de possibilité d'ajouts de code sur un seul fichier (adaptation à un seul utilisateur..).

Le japonais disent que la première condition pour atteindre un objectif, c'est d'en avoir un.
 
Dans le premier message, ce n'était pas clair. Le problème semblait centré sur l'optimisation du temps. Mais en fait, il semble que cela ne soit qu'un prétexte, ou un problème secondaire. L'essentiel semble être la maitrise des fiches.
 
Pour avoir cette maitrise, une solution simple consiste à n'autoriser leur mises à jour que par vous.
 
Ou bien, si vous laisser d'autres personnes faire les mises à jour, il faudrait qu'elles soient responsables et donc qu'elles signent la mise à jour et qu'il y ait une traces des changements. Il existe un merveilleux logiciel qui fait cela : Wiki. Il existe plusieurs logiciels qui font du wiki. Celui qui était utilisé dans une société ou j'ai travaillé s'appelait MoinMoin, mais il en existe beaucoup d'autres, voir http://fr.wikipedia.org/wiki/Liste_de_logiciels_wiki . Un Wiki s'intalle sur un intranet ou sur un internet. C'est très pratique. J'aime beaucoup cette solution.
 
Mais pour le moment, vous êtes sur Excel.  
Vous pouvez protéger le classeur en écriture et demander que l'on vous remonte toutes les modifications à faire, et vous les feriez vous-même.  
Ou vous pouvez habillez le classeur avec des écrans qui ne montrent que certains champs et qui permettent une saisie contrôlée des champs. Mais cela nécessite beaucoup de programmation. Pour avoir des idées de ce qu'il est possible de faire, voir http://excel.developpez.com/
 
 

Le problème ce n'est pas qui fait la mise à jour, mais comment la faire...

Je ne suis pas sur d'avoir tout compris, mais en ce qui concerne les mises à jour, j'ai fait un truc qui permet de forcer les utilisateurs à télécharger la dernière version de mon appli faite sous Access lorsque je fais évoluer celle ci.

Voilà comment je procède :
- l'appli est lancée en local (sur le bureau de l'utilisateur)
- lors de l'ouverture du formulaire principal, l'appli va vérifier si la version utilisée est égale à la version courante : elle va lire à cet effet la version courante dans un fichier appelé version.ini qui est enregistré sur un disque réseau dans un répertoire sources
- si les versions sont différentes, l'appli télécharge la nouvelle version, qui est stockée dans le répertoire sources, sur le bureau de l'utilisateur, puis lance cette nouvelle version avant de se fermer.
- la nouvelle version efface l'ancienne dès qu'elle est fermée

Avec cette méthode, les mises à jours de mes applis sous Access fonctionnent très bien. Bien sûr, contrairement à Access où mes tables de données sont sur le réseau, les données contenues dans tes fichiers Excel seraient perdues en cas de mise à jour.

Merci pour ton aide, en effet apparemment je ne suis pas très claire, mais le problème est un peu complexe et je ne peux pas trop détailler non plus.
En tout cas ta réponse est tout à fait appropriée, mais (ce serait trop simple sans mais  ;-)) :
 

• Il y a différents disques réseaux, les utilisateurs n'ont pas accès aux mêmes. A la limite c'est un problème facile à résoudre donc je laisse ça entre parenthèses.
• Pour le reste, c'est tout à fait le genre de solutions que je recherche, effectivement le problème c'est que les fichiers contiennent des données et des requêtes sql qui sont propres à chaque utilisateur et qu'il n'est pas possible de supprimer. Concrètement je pense que la Màj du fichier ne peut consister au maximum qu'à importer les modules màJ, supprimer les anciens, renommer les nouveaux. La limite de cette solution c'est que si des utilisateurs demandent des fonctionnalités particulières dans leurs fichiers (et ça arrive souvent..), les procédures ajoutées seraient perdues en cas de mise à jour, mais on ne peut pas tout avoir..  

Donc déjà la première partie de ta réponse m'irait bien, à l'ouverture des fichiers une procédure irait vérifier si la version utilisée est la plus récente, le problème c'est ce que je pourrais mettre dans le if...
Pour le moment je me dis qu'au pire je pourrais créer un fichier de listing, chaque fichier à màj irait inscrire son chemin d'accès dedans, j'aurais ainsi la liste des fichiers à patcher manuellement.. Bien sûr je cherche encore une meilleure solution (quand je parlais de problème de temps...  )
Quand je dis patcher manuellement, je pense à faire un fichier-patch, qui à l'ouverture lancerait une fenêtre de sélection de fichier, une fois le fichier à màj sélectionné l'ouvrirait, y importerait les nouveaux modules, supprimerait les anciens, renommeraient les nouveaux, changerait le n° de version, puis l'enregistrerait...
 
 
 

C'est possible d'intervenir en vba pour charger/supprimer/ des modules vba ?
Un module devant être un objet, ça doit être possible mais j'ai jamais fait !
 
yo dawg ! j'ai appris que tu aimais le vba, alors j'ai mis du vba dans ton vba, comme ça tu peux faire du vba tout en faisant du vba !

Oui c'est possible, comme ça je pourrai aussi mettre à jour mon fichier de mise à jour via une fichier de mise à jour de mises à jour    
Un bon tuto là-dessus : http://silkyroad.developpez.com/VBA/VisualBasicEditor/
 
Bon j'ai pas encore testé, mais ça a l'air pratique pas mal..

Alors, en passant par un fichier ini (par exemple) tu devrais pouvoir gérer les versions une par une. Mais je pense que tu as intérêt à être sacrément organisé, parce que ça peut vite devenir le bazar !
Voir ici comment lire/écrire dans un fichier INI en vba
Et il faudra probablement que tu passes par un répertoire accessible à tous, au moins en lecture, pour faire tes diffusions automatique.

Merci pour le lien, effectivement il faut de l'organisation, en fait c'est déjà le bazar et j'essaie d'inverser l'ordre des choses    
Donc première étape validée, maintenant il faut que je trouve un moyen de faire les mises à jour automatiquement, parce que même si mon fichier de mise à jour est une solution, ça implique une grosse perte de temps (surtout que c'est pas super rigolo d'aller chercher à la main les fichiers perdus au fond de répertoires improbables   )

Je te fais un copier/coller de mon code qui me sert à vérifier une nouvelle MaJ et copier le nouveau fichier sur le bureau de l'utilisateur, le cas échéant.
C'est le code brut, il est assez commenté et fonctionne pour Access 97. Il est évidemment à adapter suivant ton cas. Il se peut qu'il te manque quelques fonctions (dont le lire dans un fichier ini, mais c'est le même que je t'ai donné plus haut). Il y a peut être moyen de faire plus simple, mais celui là fonctionne très bien, je n'ai jamais eu de problème, et des mises à jours, j'en ai fait un paquet !
 

Access 97 ? Whaouh je me plains avec sql server 2000 et office 2000 mais il y a pire apparemment    
Merci pour le fichier  

Ca marche bien Access97 ! On vient de passer à la version 2003 au boulot et je n'ai pas remarqué de différence notable. A part peut être la possibilité d'intervenir dans le code des formulaires à la volé, chose que ne permettait A97.

Bonjour
 
2003 a aussi un petit avantage au niveau des TDC et des Graphiques. Plus besoin d'exporter les données, piloter Excel pour avoir de beaux graphiques. (Meme si depuis longtemps j'exporte du xml avec des graphique 'animé' en flash)
Ainsi que deux-trois fonctions vba.
Et un point qui me facilite la vie, l'explorateur de projet vba dans une fenetre independante...
 
Je mets aussi a jour mes bases Access (prog ou données d'ailleurs) a l'aide de .ini
Pour les fichiers excel, je fais autrement, j'ai un 'fichier type' (en gros le fichier de démarrage, qui permet d'ouvir les 'differents applis Excel') qui va verifier que le fichier Excel sur le client est le meme que celui sur le serveur (derniere version). En fonction du type de fichier, soit il est carrément remplacé, soit mis a jour en fonction de criteres saisis dans le .ini
 
Rondoudoudou = Ctplm ?
 
Cordialement

Oui Rondoudoudou = Ctplm, j'ai laissé mon mdp dans ma boîte mail au bureau donc j'ai recréé un compte ce week-end.
 
Je ne connais pas bien Access (un peu le 2007 et encore..), je travaille avec SQL Server.
 
Que veux-tu dire par "fichier de démarrage" et "différentes applis Excel" ?
 

Au lieu que les utilisateurs aillent dans leurs dossiers pour ouvrir les applicatifs créés sous Excel, j'ai créé un fichier Excel qui lance ces applicatifs.
Donc le premier fichier, sert juste a lancer tel ou tel fichier et/ou a regarder si une nouvelle version existe.
Une sorte de tableau de demarrage si tu preferes. Ca evite d'avoir a mettre le code qui regarde les versions dans chaque fichier.

Ok, merci pour le détail...

C'est vrai, j'apprécie cela aussi. Le vba est plus standard en 2003 qu'en 97 (où il manquait des fonctions telles que remplace) et que la fenêtre vba est indépendante est un vrai plus.
Les graphiques, j'en fait peu, donc je n'ai pas encore testé.