> -----Message d'origine----- > De : Samuel Mounier (Liste CGO) [mailto:[EMAIL PROTECTED] > Envoyé : lundi 17 mars 2008 12:04 > À : [email protected] > Objet : Re: [dev-fr] Pérennité VBA > > > Patrick a écrit : > > Bonjour, Bonjour,
[..] > Personnellement je pense que les macro sont une aberration. Il faut être moins catégorique, car il y a une gamme très étendue de situations entre la tâche unique et la production intensive sur une longue période : logiciel métier. Tout ce qui est dit ensuite s'applique à des applications de nature "informatique". En revanche, je peux avoir une longue séquence d'opérations à répéter quelques centaines de fois dans la journée. Dans cette situation, l'enregistrement automatique d'une macro peut être suffisant et la macro pourra être détruite à la fin. On peut imaginer de nombreuses situations intermédiaires dans lesquelles une macro est un bon compromis. Souvent, il est plus rapide et plus confortable pour l'utilisateur d'écrire une macro que d'écrire une notice d'opérations à réaliser manuellement. Bien entendu, comme la gamme des situations est très étendue il est impossible de fixer une frontière rigide entre les divers modes d'automatisation. Chacun fera selon ses habitudes dans la zone médiane. > > Car que faisons nous la plupart du temps avec ? > - Nous réalisons des tâches qui peuvent l'être d'un autre manière. Exemples ? > - Nous cherchons à personnaliser l'interface des logiciels de > bureautique pour une tâche spécifique (métier la plupart du temps). > > Dans le cas de problème métier, mieux vaut développer une interface > indépendante adaptée qui sera réalisée après une étude > sérieuse puis > éventuellement faire appel à OOo pour les tâches qu'il traite > correctement et simplement. L'intérêt de la démarche bureautique est de ne pas avoir à faire une longue étude mais de travailler par essais, de s'adapter, voire de toujours laisser une possibilité à l'utilisateur de reprendre la main pour traiter un cas imprévu ou tellement rare que son automatisation n'est pas justifiée. > > Tous les outils réalisés par des utilisateurs avancée sous forme de > modèle de fichier qui intègrent des macro sont la plupart du temps > in-maintenable au fil des versions (changement des noms des > objets, etc.). > > Pourquoi favoriser ces pratiques ? D'une part rien n'interdit de bien travailler avec des macros langages : dictionnaire de données, structuration du code, commentaires, documentation, etc. Ceci ne se justifie que pour des applications à durée de vie longue. Je connais au moins une application qui en 2006 tournait encore avec des macros Word 5 pour DOS. D'autre part, le périssable peut-être rentable, voire la seule solution rentable. Il faut seulement avoir conscience de ses faiblesses. Il faut aussi savoir qu'il y a une énorme différence entre l'utilisation d'un outil que l'on a réalisé et l'utilisation d'un outil réalisé par un autre. Quand un utilisateur se crée un outil "à sa main", pour son seul usage personnel, il n'a pas besoin d'investir dans ce qui serait indispensable pour que cet outil soit auto portant pour être utilisé par un autre utilisateur sans contact physique avec le concepteur. Il faut probablement multiplier le temps par dix entre les deux situations. Pourquoi faire cet investissement quand il n'est pas nécessaire ? Il est vrai que dans ce cas il faut tout détruire au départ de l'utilisateur mais pourquoi le regretter ? Dès lors que cela a été rentable, que demander de plus ? Il en est de même pour la formation : quand une personne quitte l'organisation sa formation et son savoir-faire sont perdus. Certains de ses outils font partie du paquet perdu au départ. Chaque organisation doit prendre en charge ces changements et faire des compromis. > > Le cycle de vie d'un outil de gestion, n'est pas le même > que celui des > versions des suites de bureautique arrêtons de vouloir > toujours y coller. Il y a de nombreuses situations où les outils de gestion ont un cycle de vie plus court que celui des suites bureautiques. Il ne faut donc pas raisonner seulement grosse application qui va durer vingt ans. Tous les cas existent. La bureautique est dédiée aux nombreux petits problèmes à traiter à une fréquence faible et dont la durée de vie peut être très courte et non aux gros problèmes à traiter en grande série pendant une longue période. > > > Déjà en ne basculant pas systématiquement sur la dernière > version si ça > n'a pas d'intérêt (bug, etc.). Je signe des deux mains ! > > Et si les personnes ont réussi à comprendre mon > raisonnement (chapeau > déjà... ;-) ) alors je pense que la question à se poser > n'est pas sur la > viabilité d'un langage ou d'un autre mais plus sur la > méthode de travail > et de développement qu'il faut appliquer à vos futures > développements. J'espère avoir compris. J'espère aussi avoir contribué avec d'autres réactions à élargir la vision des situations. Pour illustrer, un exemple : en 1975, au cours d'une soirée festive, j'ai dû m'absenter une bonne heure pour apprendre un macro langage de machine à calculer automatique et créer une séquence de calcul pour qu'en collègue puisse l'utiliser des centaines de fois avant d'aller se coucher. Cette séquence n'a plus jamais été utilisée et moi je n'ai plus jamais travaillé sur cette machine. En attendant, ce macro langage nous avait permis de faire le travail sans erreur dans le délai imparti. Cet exemple, montre qu'un macro langage peut être utile même si l'application est périssable. Il faut seulement réfléchir avant de réaliser l'investissement. Concernant la bureautique, il ne faut pas négliger l'enregistrement automatique de séquences. Quelques retouches manuelles et on a un système qui fait gagner du temps avec quelques lignes de code. Les macros les plus courtes sont en général les plus rentables. Il y a aussi toutes les applications mixtes : noyau dur avec des programmes compilés pour des fonctions critiques bien contrôlées autour duquel on peut avoir des applications intermédiaires avec des macros pouvant être adaptées par des utilisateurs avertis et des applications totalement manuelles pour les cas exceptionnels. Cordialement. Jean-Yves ROYER Qui n'est pas informaticien. > > > > -- > Samuel Mounier > Formateur Centre de Gestion Océan > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
