1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut Est ce la bonne solution ?

    Bonjour,

    j'ai plusieurs applications multi users développées en ACCESS/VBA possédant requêtes, formulaires, états, ... et qui , actuellement sont déployées de la façon suivante
    A) La base de donnée sur un serveur
    B) La base des formulaires sur chaque client par l'intermédiaire de tables liées

    On voudrait se débarrasser de cette façon de faire car les montées de versions (soit système, soit Access) nous mettent systématiquement en difficultés. De plus, d'avoir des éléments sur les poste clients nous gênent

    On voudrait donc s'orienter vers un système client/serveur tel qu'on pourrait en avoir avec un développement Web
    Ceci nous permettrait de gagner suffisamment de temps pour étudier des scénarios de migrations vers JAVA/Postgres

    Après avoir lu pas mal d'articles, il me semble que le mieux pour nous, serait d'avoir une VM portant ACCESS et SQL SERVER afin de migrer nos applications vers ADP, ce qui nous permettrait d'avoir un fonctionnement ne nécessitant plus de poser des éléments sur le client
    Mais ma méconnaissance crasse d'ACCESS ne me permet pas de juger si j'ai raison ou si je me leurre complètement
    J'ai vu que SHAREPOINT ne nous irait sans doute pas compte tenu des limitations actuelles de cet outil et qu'il nous faudrait, sur notre VM être en ACCESS 2010 et SQL 2008 , ce qui nous convient

    Si une bonne âme peut me répondre, je lui en serais gré

    A+

  2. #2
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Bonjour,

    Difficile de dire quelle est "la bonne solution", il y a plein de solutions plus ou moins concurrentes selon les circonstances. Qq remarques en vrac :
    1. pour la dorsale, postgre et SQL server sont concurrents donc il est dommage d'en choisir un provisoirement pour aller sur l'autre ensuite
    2. pour la frontale, access est bien adapté seulement si tous les utilisateurs sont connectés en ethernet (réseau local)
    3. cette frontale n'est pas très complexe à déployer mais si c'est un problème ça marche aussi avec la frontale sur le serveur
    4. le couple access / SQL server fonctionne bien si toutes les requetes sont en ADO (syntaxe SQL server). Les requetes complexes en DAO (syntaxe access) sont très lentes
    5. il me semble qu'adp n'apporte pas grand chose et que d'ailleurs cela n'existe plus dans les versions récentes
    6. la VM est aussi une solution simplement c'est plus contraignant pour les utilisateurs qui devront utiliser les 2 environnements. Personnellement je la réserve aux utilisateurs nomades ou connectés en bas débit (wifi, internet...)

    Cela fait un certain nombre de compétences distinctes à acquérir donc il vaut mieux ne pas trop se disperser !
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut

    Bonjour et merci pour cette réponse

    Effectivement le déploiement sur le client nous gène car on a déjà eu des chose de type "delete du répertoire",pb de droits au déploiement ou montée de version intempestive de certains postes et d'autre non
    D'où l'idée de se retourner vers un pur client serveur
    Pour ce que j'avais vu et testé ici, le frontal sur le serveur provoquait des blocages users et tous les forums indiquent la même méthode
    Dorsale sur le serveur, frontal chez le client
    On passerait toutes nos requêtes en ADO (Ca ferait partie de la migration)
    ADP nous plaisait car il existe des outils de migrations et des tuto très complets dur le sujet.
    Maintenant, c clair que dans les nouvelles versions ce serait SHAREPOINT sauf qu'en l'état, celui ci est trop peu abouti compte tenu de ce qui a été fait
    Pour nous l'avantage de la VM est la stabilité du système et des outils (nous ne sommes pas maitre des montées de version, ce qui explique nos pb)

    A+

  4. #4
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Citation Envoyé par thtioxine Voir le message
    Pour ce que j'avais vu et testé ici, le frontal sur le serveur provoquait des blocages users et tous les forums indiquent la même méthode
    Dorsale sur le serveur, frontal chez le client
    C'est vrai mais en pratique j'ai une appli de taille moyenne connectée à une base access et une base oracle. Tout est sur le serveur avec une trentaine d'utilisateurs (dont la moitié en VPN) et ça marche très bien

    Je ne connais ni adp ni sharepoint donc je n'ai pas d'avis là dessus...
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par nico84 Voir le message
    C'est vrai mais en pratique j'ai une appli de taille moyenne connectée à une base access et une base oracle. Tout est sur le serveur avec une trentaine d'utilisateurs (dont la moitié en VPN) et ça marche très bien

    Je ne connais ni adp ni sharepoint donc je n'ai pas d'avis là dessus...
    Y aurait t'il un paramétrage particulier à faire ?
    Je vais me renseigner la dessus car ça va à l'encontre de tout ce que j'ai lu et ce qu tu dis ouvrirait une voie que nous avions abandonné vue notre expérience et les forums sur le sujet

    A+

  6. #6
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Non rien de particulier...
    L'appli (compilée en accde et sans aucune table) fait 8 Mo, sa base 25 Mo (et la base Oracle beaucoup plus)
    Je pense que le fait de laisser l'appli sur le serveur ne rajoute que 8 Mo de trafic sur le réseau lorsqu'un nouvel utilisateur se connecte, pour le reste cela ne doit pas changer grand chose.

    La base access est liée à l'appli. Les tables Oracle les plus utilisées sont liées aussi, les autres en accès occasionnel par ADO.

    C'est vrai que partout il est conseillé de déployer la frontale mais je n'ai pas constaté de gros gains donc je ne le fais pas systématiquement
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par nico84 Voir le message
    Non rien de particulier...
    L'appli (compilée en accde et sans aucune table) fait 8 Mo, sa base 25 Mo (et la base Oracle beaucoup plus)
    Je pense que le fait de laisser l'appli sur le serveur ne rajoute que 8 Mo de trafic sur le réseau lorsqu'un nouvel utilisateur se connecte, pour le reste cela ne doit pas changer grand chose.

    La base access est liée à l'appli. Les tables Oracle les plus utilisées sont liées aussi, les autres en accès occasionnel par ADO.

    C'est vrai que partout il est conseillé de déployer la frontale mais je n'ai pas constaté de gros gains donc je ne le fais pas systématiquement
    Ahhhhhhh, je crois comprendre
    En fait Access ne contiendrait que les formulaires et les états
    Le reste est supporté par Oracle, ce qui veut dire que tu dois faire de l'ado ou/et de la procédure stockée (ce que fait très bien oracle) et comme oracle est une base client/serveur, tu n'as pas le pb du passage de l'ensemble des données à chaque interaction
    Oui, tu as raison, ça devrait marcher comme ça

    A+

  8. #8
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Citation Envoyé par thtioxine Voir le message
    En fait Access ne contiendrait que les formulaires et les états
    La frontale contient les formulaires
    La dorsale les données saisies dans mon logiciel
    La base Oracle les données de la GPAO (que j'utilise principalement en lecture)

    Mes formulaires access appellent indifféremment des tables access ou oracle liées, je n'utilise ADO que pour des accès spécifiques en lecture ou en écriture sur la base Oracle. Il n'y a pas de procédure stockée.
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  9. #9
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par nico84 Voir le message
    La frontale contient les formulaires
    La dorsale les données saisies dans mon logiciel
    La base Oracle les données de la GPAO (que j'utilise principalement en lecture)

    Mes formulaires access appellent indifféremment des tables access ou oracle liées, je n'utilise ADO que pour des accès spécifiques en lecture ou en écriture sur la base Oracle. Il n'y a pas de procédure stockée.
    Ok , autant pour moi
    J'ai relu le fil et je vois l'architecture.
    En fait ça conforte l'idée que cette architecture est possible à la condition que les données ne soient pas dans ACCESS sinon,outre le formulaire, les données ACCESS vont être transmises et comme ACCESS ne sait pas transmettre juste ce qui est demandé mais des blocs de données, du coup les tps de réponse s'effondrent

    Il y a un lien sur le moteur JET "http://papyturbo.developpez.com/access/articles/devpro/fr/accessdevpro_page3.htm" qui explique ce pb

    En tout cas merci de ton aide pour y voir plus clair
    En définitif, je retiens que :
    A) Soit on va vers sharepoint mais à un coût qui me parait élevé
    B) On fait du pur ADP mais tu as raison quand à sql server : C''est idiot de faire du sql server alors que la cible est postgre
    ou
    C) Un mixte comme toi : La données dans une base client/serveur et le reste dans access : Ça parait pas mal du tout

    A+

  10. #10
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Citation Envoyé par thtioxine Voir le message
    En fait ça conforte l'idée que cette architecture est possible à la condition que les données ne soient pas dans ACCESS sinon,outre le formulaire, les données ACCESS vont être transmises et comme ACCESS ne sait pas transmettre juste ce qui est demandé mais des blocs de données, du coup les tps de réponse s'effondrent
    Avec un réseau ethernet gigabit ça ne s'effondre pas si vite finalement et la base access est presque aussi performante que la base SQL quand les 2 sont vues par access comme tables liées. Surtout cela permet de très bonnes ergonomies car l'utilisateur a beaucoup d'informations sur son écran

    Citation Envoyé par thtioxine Voir le message
    C''est idiot de faire du sql server alors que la cible est postgre
    Je voulais aussi migrer vers postgre mais pour l'instant j'y ai renoncé par manque de support et de forum dynamique. Pour l'instant j'utilise SQL server express dont les limites me conviennent et dont le SQL est plus proche de celui d'access. J'ai eu du mal à avoir une liaison performante entre access et SQL server mais au final ça marche bien et on a même un site de vente en ligne directement connecté à base locale grâce à la technologie .net qui semble assez en avance sur ce point

    Ce sont des choix difficiles à faire car à un moment il faut se décider sans pouvoir tout tester en vraie grandeur
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  11. #11
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut

    Citation Envoyé par nico84 Voir le message
    Avec un réseau ethernet gigabit ça ne s'effondre pas si vite finalement et la base access est presque aussi performante que la base SQL quand les 2 sont vues par access comme tables liées. Surtout cela permet de très bonnes ergonomies car l'utilisateur a beaucoup d'informations sur son écran

    Je voulais aussi migrer vers postgre mais pour l'instant j'y ai renoncé par manque de support et de forum dynamique. Pour l'instant j'utilise SQL server express dont les limites me conviennent et dont le SQL est plus proche de celui d'access. J'ai eu du mal à avoir une liaison performante entre access et SQL server mais au final ça marche bien et on a même un site de vente en ligne directement connecté à base locale grâce à la technologie .net qui semble assez en avance sur ce point

    Ce sont des choix difficiles à faire car à un moment il faut se décider sans pouvoir tout tester en vraie grandeur
    Désolé du tps pour répondre
    J'avoue que je ne saisie pas l'idée du nombre d'infos. Vu que ce sont des formulaires qui sont, in fine, renvoyé, les infos sont les mêmes quelque soit la base non ?
    Notre IT préconise postgres, du coup on aura du support si nécessaire. Ça vaut donc le coup de tenter d'y aller.
    On ira pas vers .net car ces outils sont développés et maintenus par des gens qui connaissent très bien vba mais pas du tout vb.net.

    Oui, je suis d'accord. On va tester ACCESS / POSTGRES et si ça donne pas de résultats probants, on en restera sans doute à ACCESS/JET
    Mais bon, si on arrive à ne plus avoir de frontal chez le client, ce sera déjà une bonne avancée

    Bonne journée

  12. #12
    Rédacteur/Modérateur
    Avatar de argyronet
    Homme Profil pro
    Panseur de bobos en solutions ETL
    Inscrit en
    mai 2004
    Messages
    4 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Panseur de bobos en solutions ETL
    Secteur : Finance

    Informations forums :
    Inscription : mai 2004
    Messages : 4 738
    Points : 11 088
    Points
    11 088
    Billets dans le blog
    5

    Par défaut

    Bonjour,

    J’apporte aussi ma petite contribution à ce sujet en exposant une possibilité qui n'est pas totalement stupide et qui fonctionne plutôt bien, à savoir, une connexion Terminal Serveur qui se traduit par un raccourci sur le bureau du poste utilisateur.

    Le fichier *.rdp est configuré pour pointer sur la version locale de Microsoft Access du serveur complété à la chaîne représentant le chemin dans lequel est installée l'application à ouvrir avec la syntaxe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    "%OfficePath%\MSACCESS.EXE" "%APPPATH%\App.accdb"
    Le seul souci dans ce cas et que l'on ne doit pas partager une base de données dite frontale, en l'occurrence l'application qui est d'ailleurs liée à la base de données ne contenant que les tables dans le même répertoire.

    Pour pallier à cela, il existe une solution pas très élégante certes, mais qui fonctionne : il suffit de dupliquer autant de fichiers représentant les applications frontales que nécessaire en les nommant expressément avec le nom de chaque utilisateur ou plutôt de donner un nom générique à ces applications frontales de manière à ne pas rendre exclusif, en quelque sorte, le nom de application pour un utilisateur donné...
    Ainsi, les fichiers *.rdp verront leur ligne de commande modifiée avec le nom de l'application en conséquence du nouveau nom :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    "%OfficePath%\MSACCESS.EXE" "%APPPATH%\App001.accdb"
    Enfin et surtout, en cas de modification de la base frontale, il faudra faire en sorte que celle-ci possède une fonction de rattache automatique des tables et tout ce qui va avec. En cas de changement ou d'évolution de cette application, il faudra réitérer l'opération de duplication pour autant d'utilisateurs qu'il y a.

    Je conçois que ce n'est pas très conventionnel comme mode opératoire, mais en tout état de cause c'est de loin le moins coûteux et le plus rapide à mettre en œuvre puisqu'il peut même fonctionner avec le Runtime ce qui évite une licence complète à installer sur le serveur.

    Argy
    Ce qui donne son sens à la communication, c´est la réponse que l´on obtient. Si vous n´obtenez pas la réponse voulue, communiquez différemment.

    Ils comptent sur vous...
    Web Site@Mail
    Tutoriels : Déployez vos applications Access 2013 et 2016 */* Réalisez un Assistant de présaisie...
    MDB Viewer : Visionneuse Access v4.0
    *** Je recherche des profils (2 ans min.) Java EE, Fullstack, Front, .Net, Mobile... pour CDI ***

  13. #13
    Membre confirmé Avatar de ypicot
    Profil pro
    Inscrit en
    mai 2004
    Messages
    404
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : mai 2004
    Messages : 404
    Points : 553
    Points
    553

    Par défaut

    Un point important à prendre en compte : la volumétrie des tables.

    En effet, si les tables sont "simplement" attachées, c'est JET qui continue à faire le boulot des requêtes... en local.
    Cela signifie que si on a une table tClient et qu'on recherche seulement ceux qui habitent Trifouilli, toutes les données de tClient (et pas uniquement les trifouillens) vont débouler sur le réseau, pour que la requête soit effectuée sur le poste utilisateur (il y a différentes optimisations, mais l'idée générale est là).

    D'où la nécessité, dès qu'on a des tables un peu volumineuses, de travailler au maximum avec des requêtes stockées sur le serveur, et de limiter au maximum l'accès "en direct" aux tables. C'est ce que faisait en natif le défunt .adp, dans lequel tout le boulot de requête se faisait sur le serveur.

    Si on n'y prête pas attention, cette "petite nuance" peut rendre l'appli inutilisable dès qu'on dépasse certaines volumétries (lesquelles ? bonne question, cela dépend du cache, du réseau et de sa charge moyenne, du nombre d'utilisateur, ...). Donc, vive ADO Direct, mais il vaut mieux en tenir compte dès le début.

    Concernant Sharepoint, il faut faire attention à la limitation des 5000 lignes, qui invalide sérieusement certaines applications.

    Tout cela pour dire que, s'il y a du volume, la solution proposée par Argyronet est à envisager sérieusement.

    Yvan
    Une solution n'est valable que dans un contexte donné

  14. #14
    Membre expert Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 332
    Points : 3 807
    Points
    3 807

    Par défaut

    Citation Envoyé par ypicot Voir le message
    si les tables sont "simplement" attachées, c'est JET qui continue à faire le boulot des requêtes... en local.
    Si les tables sont attachées mais les requêtes en ADO (sur une table MSQL ou postgre) le boulot est fait par le serveur me semble-t-il
    Et les tables attachées restent accessibles directement par les fenêtres.

    C'est surtout sur les requetes complexes que le gain est important. Tant qu'il s'agit d'un select basique sur 2 ou 3 tables JET s'en sort bien (ma plus grande table a 200.000 lignes)...
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  15. #15
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2007
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2007
    Messages : 20
    Points : 17
    Points
    17

    Par défaut Retour et remerciements

    Citation Envoyé par nico84 Voir le message
    Si les tables sont attachées mais les requêtes en ADO (sur une table MSQL ou postgre) le boulot est fait par le serveur me semble-t-il
    Et les tables attachées restent accessibles directement par les fenêtres.

    C'est surtout sur les requêtes complexes que le gain est important. Tant qu'il s'agit d'un select basique sur 2 ou 3 tables JET s'en sort bien (ma plus grande table a 200.000 lignes)...
    Désolé pour ma réponse hyper tardive

    Enfin, bref, voici le retour de ce qui a été finalement développé (et mis en prod)
    Compte tenu de toutes les remarques précédentes, on a choisi de ne plus utiliser de tables liées et on a choisi sqlserver car le driver ADODB est natif sur les postes
    Donc, base sql express et formulaires ACCESS

    Le gain de temps à été phénoménal (compte tenu que l'appli initiale avait peu de tables mais une très grosse)
    Les modifications ont été assez longues (on en a profité pour gérer des transactions, documenter l'appli, nettoyer le code) et la simulation des maj dés qu'un champ change à été "ardue"
    Le retour user est enthousiaste et le productivité pas mal augmentée compte tenu du moindre stress (attente qui énerve) et de l'utilisation de fonctions enfin utilisables (Certaine mettaient tellement de temps à répondre qu'elles n'étaient plus utilisées)

    Merci de vos conseils

    A+

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 3
    Dernier message: 22/01/2016, 07h48
  2. Ca marche mais est-ce la bonne solution ?
    Par l ours blanc dans le forum Mise en page CSS
    Réponses: 0
    Dernier message: 09/12/2011, 13h52
  3. Mon dataset est-il la bonne solution?
    Par Tommy57 dans le forum ASP.NET
    Réponses: 0
    Dernier message: 05/07/2010, 23h45
  4. HierarchicalDataTemplate, est-ce la bonne solution
    Par ludogoal dans le forum Windows Presentation Foundation
    Réponses: 1
    Dernier message: 29/05/2008, 14h22
  5. [EJB2.1 Entity] [CMP] Est-ce la bonne méthode ?
    Par stailer dans le forum Java EE
    Réponses: 8
    Dernier message: 20/06/2004, 19h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo