Bonjour,
 
 
je me posais aujourd'hui une question
 
 
comment faites vous pour reproduire les problemes (de vos clients) qui ne se produise jamais devant vous
 
la plus part du temps c'est tout simplement des utilisateurs qui ont besoin d'être rassuré mais il arrive vraiment parfois qu'un problème existe

up

Quel type de problèmes ?

La question est vaste, mais voici mes propres elements de reponse, a une epoque pas tres eloignee pour moi.
 
A une epoque ou j'etais a 100% dans le support (que dis-je ... 150%   ), devant un pb PC que je pensais interessant a essayer de resoudre (car intellectuellement stimulant, surtout quand je "sentais" que c'etait juste un "petit truc", que j'etais a 2 doigts de trouver, mais que cela risquait de prendre du temps a troubleshooter, donc d'impacter l'utilisateur dans la productivite de son travail) et que le temps et les moyens etaient appropriées a faire cela (c'est plus possible maintenant, faut tout faire vite-vite et a bas prix partout....), je clonais le disque et je travaillais sur le clone (de preference sur une machine identique a l'originale, souvent a la revision de BIOS près ).
 
Entretemps, si le pb etait handicapant pour l'utilisateur (Pc crashé ou fonction importante defectueuse), je lui (re)preparait un poste de travail tout neuf.
Comme ca, j'avais souvent tout le temps de bosser tranquille sans embetter l'utilisateur, et surtout en experimentant des solutions parfois dangereuses.
 
Bien sur, le top du top etait d'arriver a resoudre le pb (facilement de preference), plus encore de savoir se rappeler toutes les etapes de comment le resoudre (de preference preventivement) par la suite lorsque des cas identiques se presentaient.
 
Quant le pb etait plus simple, j'essayai autant que faire se peut de regrouper un maximum d'elements pour essayer de le reproduire et de le resoudre sur mon propre systeme.
 
Dans la meme optique, lorsque l'environnement de travail etait en passe de changer en profondeur (introduction d'un nouvel OS, migration vers une nouvelle application, etc..), je veillais a etre en avance de plusieurs mois sur les utilisateurs, afin d'imaginer bien en avance le type de pb qu'ils pourraient rencontrer.
Comme certains pbs venaient des utilisateurs, il fallait avoir une bonne dose d'imagination et de sagacité (j'en ai parait-il   ) pour imaginer le maximum de situations plus "tordues" les unes que les autres ("Qu'est ce qu'ils vont bien pouvoir m'inventer cette fois ci .. ?"    )
 
Idem lorsqu'un patch allait etre publié : il etait souvent vital (surtout pour une tres grosse boite, car ca a un cout important) d'etre en partenariat etroit avec tel ou tel editeur pour disposer de tel ou tel patch bien avant la publication, pour s'assurer de ne pas subir tel ou tel effet de bord avec le "produit" final.
Pareil avec les beta.
 
Et quant on travaillait sur un environement tres heterogene, il m'etait utile de disposer de plusieurs des systemes supportés, tant en terme de hardware (j'avais souvent plusieurs types de PC a mon bureau, ou une salle systeme specifique avec tel ou tel type de serveurs) que de software :
pour les OS, je travaillais souvent avec des machines virtuelles (Vmware) ou des sessions distantes pour ne pas avoir a entreposer et allumer ouatmille machines dans mon local.
 
Evidemment, et pour finir, une bonne partie des solutions devaient etre documentees, pour alimenter des problem reports et/ou des bases de connaissances: il fallait partager l'info pour que les autres ne perdent pas de temps et d'argent a reinventer la roue.

Ah oui... j'oubliais  
Ca aussi c'etait important    
 
http://video.google.fr/videoplay?d [...] 7517487531

en fait tu decris le travail d'un support technique bien pensant.....

oui tout a fait merci de ces infos
 
mais moi par contre je ne travaille pas à la meme echelle donc je n'ai pas les mêmes moyens que toi
 
 
mais toute info est bonne à prendre!