Bonjour,

J'ai eu ces derniers jours, et ce à plusieurs reprises, besoin de certaines ressources et aussi l'envie de partager celles que moi j'avais (des données CSV, XML, SQL...).

J'ai regardé sur Internet s'il existait des sites pour le partage de ce type de données, et je n'ai rien trouvé (bien sûr, on a toujours les Open Data du gouvernement et tout ça, mais ce n'est pas ça qui nous intéresse.) De là m'est venue l'idée de le créer : les utilisateurs auraient la possibilité de charger les fichiers sur le serveur (nom, description courte et détaillée, mots-clés...), d'en chercher... Quelque chose d'assez basique dans un premier temps.
Le site serait un dépôt pour données (formatées en CSV, XML...) ayant été le résultats de parseurs et/ou collecteurs, mais on pourrait aussi y trouver le code ces derniers.

Les deux premiers problèmes que je voient sont liés au stockage et à la fiabilité des données soumises, le premier est d'ordre financier et de configuration (on va dire) tandis que le second peut-être résolu avec l'aide de la communauté (signaler un problème...).

L'intérêt du site serait surtout de permettre aux utilisateurs (pas uniquement webmasters) d'avoir accès à des données qu'ils ne pourraient pas avoir ou, dans le cas contraire, éviter de suivre un processus long et fastidieux pour les avoir.
Supposons que je veuille récupérer la liste d'un certain élément sur tel ou tel site (ne disposant pas de l'API nécessaire) je pourrais, au lieu de tout de suite me lancer dans un collecteur fait maison, voir s'il ne s'agit pas de données déjà disponibles sur le site.

Ensuite, pour les données évoluant et changeant rapidement, j'avais pensé à aussi stocker (partager) les scripts permettant de collecter ces données.

J'avais dans un premier temps demandé des avis sur un autre site, et un point soulevé m'a fait réfléchir : le respect des CGU des sites web. Etant donné qu'on pourrait retrouver des données interdites à la consultation en dehors du site-auteur, ou encore des scripts (collecteurs) que la plupart des sites risquent de ne pas apprécier.
Mais je pars du principe que ce n'est pas parce qu'une chose peut être utilisée à des fins illégales qu'elle est à proscrire, parce qu'on pourrait aussi trouver des données du genre :
- Liste de personnages d'un roman (nom, date de naissance, statut..)
- Liste des langages de programmation
- Liste des forums de JVC (titre, lien...)
- Liste d'adresses électroniques utilisées pour du fishing...

Sur le dernier point, je pense que des sites pourraient s'échanger des données pour compléter leur liste (d'emails servant à spammer par exemple).

Voyez ?

Vos avis sur l'éventuel intérêt d'un tel site, parce que moi ça m'arrangerait beaucoup.

Stocker les données en elles-mêmes, selon la source, l'intérêt peut être très limité.

Imagines que si un tel site existe, j'upload un fichier qui contient les différents posts d'un topic sur JVC. On a plusieurs problèmes :

- Le format est arbitraire (un autre utilisateur peut avoir fourni des données similaires pour un autre topic dans un format complètement différent)
- Les informations présentes peuvent rapidement être dépassées (un nouveau post sur le topic en question)
- Les données peuvent avoir été altérées ou être corrompues
- Tu mets directement à disposition les données d'un site (selon les CGU ça peut poser problème, comme tu le soulèves)

En revanche la partie qui consiste à regrouper des scripts de collection/parsage de données est intéressante.

Le code source serait ouvert et différentes personnes pourraient reporter des bugs, y contribuer, voir cloner un script pour l'adapter à une autre utilisation, ou mettre à jour le code lors d'un changement de format du site ciblé.

Et ça, GitHub le fait très bien.

Merci d'avoir pris le temps de répondre, vava740.

Je connais GitHub mais le problème que je lui trouve - il s'agit d'un excellent site, je ne dis pas le contraire - est qu'il n'est pas "accessible" à celui qui n'y connait rien. Si, par exemple, Mr. DUPONT veut récupérer la liste de tous les articles sur un blog (on se fiche de savoir pourquoi, même si la raison reste absurde) il pourrait soit voir si un document répondant à ses attentes est déjà disponible - bien sûr, on n'est jamais sûr de la véracité des données et le format change mais ça on n'y peut pas grand chose, sauf peut-être compter sur la communauté pour le contrôle et l'aide à la conversion vers d'autres formats - ou si un script permettant de le faire a été publié, celui-ci devant être possible à utiliser le plus facilement possible, pour ne pas contraindre l'utilisateur à se former (ne serait-ce qu'une heure) sur tel ou tel langage.

Sur le stockage de scripts, c'est vrai que GitHub est parfait mais j'aimerais avoir quelque chose de centralisé et permettant facilement de trouver ce qu'on cherche. Un peu à la manière de userscripts.org. Un repaire de scripts collecteurs/parseurs.

- Si je cherche un collecteur pour jeuxvideo.com, je n'aurais peut-être à qu'à préciser cette URL dans le champ adéquat pour voir ce qu'il y a.

- Si je cherche la liste de tous les présidents de France (date de naissance, date d'élection, statut conjugal...) je pourrais récupérer un CSV tout prêt. En fait, ce que je veux surtout dire avec ce dernier point, est qu'il y a certaines données qu'on ne peut pas toujours trouver formatées comme il faut (liste de personnages d'un roman, liste de romans d'un auteur, liste d'auteurs ayant participé à un événement...). Je ne sais pas si tu vois ce que je veux dire là... Il ne s'agit pas toujours de données ayant collectées (frauduleusement ou pas) mais de données pouvant être immédiatement utilisées, parce que leur constitution peut prendre énormément de temps.
Je monte un site sur ma saga favorite qui compte une centaine de personnages, j'aimerais bien avoir un document pouvant tout de suite initialisé par ma base de données un minimum.

Bien sûr, je ne réponds pas encore intégralement au point que tu soulèves sur la fiabilité des données mais je pars du principe qu'"aucun" contenu sur Internet n'est sûr...

Si Mr. Dupont veut récupérer les articles d'un blog, et que cette liste a été générée hier, ça peut passer (quoique ça dépend du blog). Si la liste a été générée il y a 6 mois, il y a de fortes chances qu'elle ne soit pas à jour.

Et si Mr. Dupont "n'y connaît rien", il ne saura sûrement pas faire grand chose avec un fichier XML, CSV ou SQL. Il pourra éventuellement afficher un CSV avec Excel pour peu qu'il sache importer des données d'une source texte, et qu'il connaisse le délimiteur.

Si je cherche la liste des modérateurs de JVC et qu'une telle liste a été publiée, je n'aurai aucun mal à la trouver avec un moteur de recherche. Pas besoin d'annuaire dédié pour ça, et j'ai plus de résultats qu'en me limitant à une seule source centralisée mais incomplète. C'est pareil pour les présidents de France.

Les données ne sont pas en CSV, mais Mr. Dupont va être content puisqu'il a les images d'affichées et des tas de liens intéressants [ http://fr.wikipedia.org/wiki/Liste_des_pr%C3%A9sidents_de_la_R%C3%A9publique_fran%C3%A7aise ], et il peut même y avoir une recherche [ http://jvflux.com/moderateurs.htm ].

Quel est le but de ton application en fait ? Parce que là je vois deux cas probables d'utilisateurs :

1) Mr. Dupont qui n'y connaît rien, et qui cherche une information. Il utilise un moteur de recherche et a de fortes chances de tomber sur une page web qui affiche des données formatées, avec une interface facile d'utilisation.

2) Quelqu'un de plus technique qui veut des données brutes. Si les données brutes ont été publiées, elle seront trouvables via un moteur de recherche. Si un webservice existe pour les récupérer, idem. Si un script existe pour récupérer ces données, idem.

Si j'ai bien compris, ton projet serait utile dans un troisième cas :

3) Mr. Dupont veut des données brutes (qu'il ne saura vraisemblablement pas utiliser). Il ne cherche pas de format précis (qu'il ne saura vraisemblablement pas convertir ou adapter à l'utilisation qu'il veut en faire). Il ne possède personne dans son équipe ayant les connaissances techniques nécessaires pour utiliser un script existant ou un webservice.

Si c'est bien ça, alors l'intérêt de ton application dépend essentiellement du nombre d'utilisateurs potentiels qui rentrent dans la catégorie 3.

Merci pour vos remarques qui, tout en m'inspirant me font comprendre que, peut-être, le site pourrait pas ne pas fonctionner et donc me dissuade de continuer (ce n'est pas un problème), même si le message de gamer1037564946, ayant bien compris ce que je voulais faire, m'y a encouragé : les deux premiers liens qu'il partage représentent en gros ce que je voudrais faire. Mais sa dernière phrase, sur l'actualisation des données - point déjà noté par vava740 -, me rappelle encore une fois à quel point il s'agit d'un facteur important et non à négliger. Mais encore une fois, et en même temps pour répondre au message de mon voisin je dirais - tout comme la fiabilité des informations sur Internet est presque toujours à remettre en question - que l'actualité d'une donnée est aussi à vérifier et que parfois, on se va se contenter de ce qu'on a.
Prenons l'exemple du taux de change de l'euro, on en voudrait la valeur pour chaque mois depuis 2007 : où est le problème si, malheureusement, on n'a que les deux premières années ? Ce n'est pas actuel, mais on a déjà quelque chose. D'autant plus que si le script permettant de créer ce document là est disponible, on pourrait compléter la liste.

Avec cet exemple là, je voudrais aussi répondre à une autre remarque de vava740, celle sur la première catégorie de personne (données formatées avec une interface soignée) : le problème est que si on veut récupérer ces informations là pour les utiliser ailleurs ça risque d'être un peu plus délicat. Supposons que je veuille afficher la liste des personnages d'un roman pour un fan-site, remplirais-je ma BDD à coup de "(ALT+TAB, CTRL+C, ALT+TAB, CTRL+V)*n" ?
Ces données-ci doivent être formatées non pour être uniquement lu, mais aussi pour pouvoir être traitées ou juste affichées mais dans un contexte complètement différent.

Sur ton deuxième point, on finit par trouver ce qu'on cherche en passant par un moteur de recherche de toute façon, je ne suis pas entièrement d'accord dans la mesure où tu peux avoir une collection d'informations - saisies manuellement, collectées au fil des années... - que, peut-être, tu aimerais mettre à disposition parce que tu pars du principe que d'autres pourrait en avoir besoin.
- J'ai 471 adresses électroniques en XML (courriel + message exemple) servant à envoyer des arnaques, ça serait bien de la partager.
- J'ai 43 articles traitant de HADOPI en JSON (lien, titre, auteur, date, mots-clés), ça serait pratique si quelqu'un voulait immédiatement mettre à disposition sur son site un ensemble de liens vers HADOPI
...

Pour la troisième catégorie de personnes, je reste convaincu qu'il peut y avoir énormément de monde ; c'est un peu comme les millions d'utilisateurs qui entretiennent un blog et téléchargent des extensions pour le CMS, pourquoi ne pourrait-on pas avoir un centre de téléchargement de données qu'on pourrait ensuite importer dans un "logiciel/site/base" d'un simple clic ?

Dans l'absolu, un site qui donne gratuitement des bases de données sur une multitude de thèmes est intéressant. Le truc c'est qu'il faut avoir les données, et si possible qu'elles soient à jour.

Si je comprends bien, le contenu proposé par ton site dépend des gens, qui aujourd'hui ont des données brutes sur différents sujets, et qui souhaitent les partager, mais comme aucun site de centralisation de base de données n'existe, sont contraints de laisser dormir ces données sur leur disque dur ?

Admettons, le premier objectif de ton site est alors de permettre à des gens de partager des données dans un format arbitraire.

Maintenant, on prend le point de vue de l'utilisateur qui cherche des données. Personnellement, si je veux des données sur l'évolution du taux de change de l'euro par rapport au dollar américain, je vais me diriger vers un site spécialisé plutôt que vers un site généraliste qui affiche des données financières à côté d'un XML de la liste des forums de JVC. Idem si je veux des listes d'adresses mail pour le spam.

Dans d'autres cas, ça pourrait sûrement être très utile, à vrai dire c'est difficile à évaluer dans la mesure où il n'y a rien de précis.

Ça je vois bien, mais y'a aucun des exemples qui est utilisable dans une situation réelle, et dans tous les cas on est très loin de "un centre de téléchargement de données qu'on pourrait ensuite importer dans un "logiciel/site/base" d'un simple clic" (pour ça il faudrait se concentrer sur un thème précis, par exemple un site de téléchargement d'articles préfaits pour un certain nombre de CMS, avec un plugin d'import maison quand c'est pas natif).

Le mec qui veut faire une appli sur la bourse, il a besoin de données à jour, peut-être même en temps réel. Il faudra plutôt se tourner vers un webservice sur un site spécialisé, quitte à payer, à moins bien sûr de vouloir faire une application non professionnelle (et peu crédible).

Celui qui veut faire un site de vente de voitures : tiens, aujourd'hui j'ai envie de vendre des voitures, et si je trouvais une base de données de toutes les voitures ? ~ ~

Non, le mec devra trouver des fournisseurs et construire son catalogue en fonction. Et pour le coup il aura sûrement (j'ai jamais revendu des voitures, donc dans l'absolu j'en sais rien) toutes les données qu'il veut sur les modèles qu'il a choisi de revendre, peut-être même dans un format directement compatible avec son ERP.

Pour les coordonnées GPS, on trouve un base SQL complèteen quelques secondes sur un moteur de recherche, qui plus est faite par un site spécialisé, qui met même à disposition un webservice.

Le cas du site de recettes, en théorie c'est intéressant. En pratique, le site a déjà une certaine structure de base de données. Un site de recettes basique sera construit sous forme de pages titre/contenu avec association à des catégories. Ça veut dire que les différents aliments seront pour la plupart des sites dans une liste HTML, sans aucun moyen de les identifier dans la base de données. Admettons que le mec se décide à reconcevoir sa base de données pour intégrer des données sur chaque ingrédient ; il devra faire la correspondance à la main entre les ingrédients qu'il identifie sur son site et les ingrédients présents dans la base de données téléchargée, quand bien même il y ait une correspondance pour tous les ingrédients. Il faudrait aussi que la granularité de la base de données téléchargée soit similaire à celle avec laquelle il identifie les ingrédients sur son site. Et dans tous les cas, il faudrait qu'une telle base de données ait été publiée gratuitement (gl). Bref, on est loin du "je télécharge, je clique sur un bouton et c'est fini".

Et encore une fois, si un site spécialisé propose une base de données de ce type, ce sera un meilleur choix ; même si elle est payante, il y aura sûrement un support, et la source des données est connue.

Pour les personnages d'un roman, film, série, etc... pour faire un fansite, il est fort probable qu'un fansite existe déjà et qu'il répertorie (sur une page, ou même quelqu'un qui aurait publié ça sur un forum) la liste des personnage. Et si aucun fansite n'existe, la liste n'existe sûrement pas non plus. Y'a pas un mec qui va s'amuser à lister tous les personnages, et à la fin se dire "merde, y'a aucun site communautaire de partage de bases de données, j'ai fait tout ça pour rien !". Non, il la publiera sur un forum, et quand un fansite sera créé, cette liste sera peut-être réutilisée.

Après faut savoir que je me base juste sur mes impressions personnelles, j'ai pas fait d'étude/statistiques sur ce sujet. J'essaie juste de confronter ton idée à des contraintes techniques, professionnelles ou commerciales, et dans la plupart des cas ça ne tient pas. Bien sûr je ne connais pas la proportions des bloggeurs qui veulent importer 43 articles sur HADOPI sur leur blog (j'ose espérer qu'il y en a peu, voir aucun), ni le nombre d'actionnaires qui sont prêts à faire confiance à une application qui a trouvé ses données sur un site de partage...

Merci à vous deux d'avoir répondu avec autant de précision, figurez-vous que je prends bien note, si bien qu'il ne reste plus d'espace pour commencer le projet parce que je me dis qu'effectivement l'entretien du site (actualité des données) et la fiabilité des données risquent de me poser tant de problème que ça risque juste de ne pas fonctionner.

Mais je reste convaincu que ça peut avoir son intérêt, certes pour des données officielles et graves (le taux de change par exemple) on ne risque pas d'être une référence, mais pour des choses qui le sont moins, pourquoi pas.
Pour ça je reprend ce que tu dis sur la disponibilité des informations sur les personnages d'un univers donné : on est bien d'accord pour dire que les données ne seront pas formatées et que les importer dans un tout environnement n'est pas possible.
Si, par exemple, j'ai un fan-site une certaine saga et que je demande à l'utilisateur à quel personnage il s'identifie le plus (liste déroulante) pour ensuite indiquer cette information sur son profil (nom, âge... du personnage indiqué) j'aurais eu, au préalable, besoin d'importer un liste_personnages.csv
En fait, je crois qu'on pourrait même - un peu exagéré - mais dire que ce sont des tables (provenant d'un SGBD) qu'on partage.

Enfin voilà, je crois que je vais encore y réfléchir un peu. Maintenant qu'on a discuté je me rends compte que c'est un peu flou aussi chez moi, et que peut-être ça ne me marchera pas comme je l'aurais espéré.

Merci de m'avoir donné vos avis.

je n'ai pas lu les posts donc désolé si je répète ce que tu veux faire est assez similaire a github et les services similaires, non ?

Si tu veux rentabiliser tonsite regarde de ce coté la http://www.cklm.fr/forums/forum/affiliation/