Proposition de design alternatif

[DavidBruant]

Description du problème

Cette section ne décrit que ce que j'ai compris du problème. J'invite les lectrice.eur.s à compléter avec ce que je n'ai pas compris

Le Carrefour des Innovations Sociales (CIS) est un moteur de recherche qui recence les projets d'innovations sociales en France\ Plutôt que de composer sa base de données ex nihilo, le CIS est composé d'un collectif de partenaires (environ 30 actuellement, nombre en croissance) qui fournissent les données\ Plutôt que d'essayer de demander à chaque partenaire sa base de données, puis de travailler à l'uniformiser, la stratégie adoptée par le CIS a été de scrapper les sites des partenaires afin de composer rapidement le moteur de recherche Afin que le moteur de recherche soit à jour, le scraper doit être lancé régulièrement automatiquement

OpenScraper se veut être le morceau de la solution qui va chercher les données chez les partenaires et les uniformise avant traitement puis affichage

Description de la solution actuelle

OpenScraper contient un client et un serveur\ Le serveur stocke dans une base de données MongoDB :

• le modèle de données (unique par instance d'OpenScraper) que l'on souhaite récupérer des scrapings
• la configuration des "contributor" (ou "spider"), qui consiste en un ensemble de xpath pour cibler les données dans les pages et quelques autres informations
• les données scrappées

Le serveur fait aussi tourner le scraper

Le client n'est qu'une interface utilisateur qui rend plus agréable de configurer open scraper, décider quand lancer un scrapping, prévisualiser le résultat, mais n'a pas de code "intelligent"

Singularités

OpenScraper hardcode l'idée que l'on sera toujours dans une des deux configurations :

• toutes les informations du projet sont dans une page listing
• toutes les informations du projet sont dans une page à suivre après la page listing

Les Xpath fournis sont appliqués à la fois sur la "page listing" et la "page projet", donc les données sont mélangées si les XPath s'appliquent dans les deux cas (comme dans le site de Coorace)

Les mêmes Xpath sont appliqués à toutes les pages sans exceptions possibles

Une spider est un document dans une base de données Mongo\ Entre autres choses, cela signifie qu'elle est dépendante d'une version d'OpenScraper et aussi qu'elle n'est pas versionnée par défaut (contrairement à si la spider était un fichier de code Python ou autre)\ Le code des spider est unique et stocké dans masterspider.py (actuellement ~1400 lignes de code)

Process de création et modification de spider

1. Créer une version locale d'open scraper
2. Créer le même modèle de données qu'en production (manuel) (une seule fois)
3. Configurer la spider
4. Tester jusqu'à être satisfait du résultat
   1. Modifier les XPath
   2. Changer le code d'OpenScraper (masterspider.py) si le site ne correspond pas aux pré-supposés hardcodés
   3. Lancer la spider "en mode test"
   4. Lancer la spider "pour de vrai"
5. Copier la spider en production (manuel)

Pour la modification, pareil que le process de création à part que 3 est une copie manuelle de la version en production

Dans les deux cas, le gros du temps est passé dans l'étape 4

Dangers associés à utiliser le même code pour toutes les spiders

L'étape 4.2 n'est pas systématique, mais est nécessaire dès que l'on cherche à scrapper un site qui ne correspond pas aux pré-supposés du fichier masterspider.py. Cela arrive toutefois assez régulièrement et il est impossible de prévoir quel nouveau site va nécessiter de modifier à nouveau masterspider.py

Chaque nouveau cas est souvent résolu par l'ajout d'une nouvelle option dans l'interface de configuration de la spider. La liste des options est condamnée à ne faire que croître sans que personne ne puisse savoir jusque quand, car enlever une option pourrait casser une spider dépendant de cette option

De par le fait que masterspider.py est le même code utilisé pour toutes les spiders, le modifier est un exercice périlleux, car le modifier pour faire marcher une spider comporte le risque de casser une ou plusieurs autres spiders. Ce risque pourrait être réduit par la présence de tests automatisés, mais il n'y en a actuellement aucun

A noter que ce risque pèse sur l'instance du Carrefour des Innovations Sociales, mais pèse sur toutes les instances futures d'OpenScraper : il est possible que dans une future version d'OpenScraper, masterspider.py soit modifié d'une manière qui casse les spiders de l'instance

Aucun retour direct sur les erreurs durant le scrap

L'étape 4.3 est actuellement assez difficile, car beaucoup d'erreurs sont possibles, mais l'outil ne les fait pas remonter facilement. Erreurs possibles :

• XPath non-valide
• XPath qui ne matche aucun élément sur une page (sur toutes les pages ou sur une certaine page)
• Données récupérées non-valides par rapport à un format attendu (par exemple, une adresse postale qui contiendrait le symbole €)
• URLs qui ne fonctionnent pas (404, 403, 500, boucle de redirect infinis, etc.)

On ne se rend compte de ces erreurs que dans des messages dans la console (qui contient beaucoup de messages) ou en constatant que nos attentes ne sont pas satisfaites en inspectant les données récupérées manuellement\ Ce process est aussi limité, surtout quand le scrapper ramène des centaines ou milliers de résultats

Pourtant ces erreurs arrivent avec des causes diverses :

• être humain
• redesign de site
• cas particuliers

Ces causes sont fréquentes. Même les redesign. Si on imagine qu'un site procède à un redesign tous les 5 ans, alors en moyenne, sur 30 partenaires, l'un d'eux fait un redesign tous les 2 mois. Il est donc fréquent de devoir réécrire des spiders cassées pour redesign

Aussi, en relançant la spider régulièrement, il sera découvert des nouvelles pages qui ne correspondent parfois pas aux attentes de la spider

Aujourd'hui la boucle de feedback d'essayer des XPath, de constater que quelque chose ne va pas, de comprendre pourquoi avant de réessayer est un processus très manuel et long\ Le problème ne va être que plus visible et douloureux quand il va s'agir de laisser OpenScraper tourner tout seul pour se mettre à jour automatiquement

Description d'une autre solution possible

Spider en tant que code

Si chaque spider était son propre fichier de code, elle pourrait être versionnée (donc avoir l'histoire des changements), n'avoir qu'une faible dépendance au cœur d'OpenScraper (ou une dépendance forte, mais choisie et non imposée comme actuellement). Elle serait moins fragile aux changements d'OpenScraper. Le cœur d'OpenScraper pourrait être beaucoup plus petit et donc plus facile à maintenir Chaque spider pourrait aussi être facilement testée par des tests automatisés Copier une spider ne serait plus un jeu de copier/coller entre la prod et le dév, mais juste un git push et un git pull

Cette approche aurait un bonus supplémentaire pour les instances qui souhaitent être open source qui pourraient partager leur code contrairement à l'approche actuelle où la configuration de la spider et ses XPath est cachée dans une base de donnée MongoDB

Chemin de transition pour le Carrefour des Innovations Sociales

• Garder masterspider.py pour le moment
• Pour chaque spider :
  • Télécharger en tant que fichier JSON la configuration et la versionner
  • Créer un fichier de code qui se résume à appeler masterspider.py avec la configuration JSON
• Le modèle devient une classe ou interface Python

Quand une nouvelle spider est à créer, la créer "de zéro"\ Quand une spider est à refaire, réécrire le code "de zéro" sans utiliser masterspider.py

"de zéro" est mis entre guillemet, car il est ok dans ce cas-là de copier/coller du code, par exemple de masterspider.py, en le nettoyant pour ne garder que les morceau utile à ce site spécifique\ S'il est nécessaire de traiter un cas non-prévu par l'actuel masterspider.py, le.a développeur.euse aura accès à tout Python pour le faire

OpenScraper pourra fournir des classes et fonctions qui facilitent la vie d'écriture de spider. L'utilisation de ces fonctions et classes dans une spider sera optionnel

Assistance d'OpenScraper dans la gestion des erreurs

A chaque fois que l'on fait tourner une spider ("en test" ou "en vrai"), il s'agit d'un run. Il serait possible qu'OpenScraper, pour chaque run, stocke toute l'activité utile :

• Toutes les URLs visitées, leur code de retour, (le corps de la réponse HTTP si ça pèse pas trop lourd ?)
• Les chemins de navigations
• les XPath (ou sélecteurs CSS ou toute autre forme de sélection/query) essayés sur quelles pages, s'ils sont valides, si elles n'ont rien retourné, si ce qui est retourné est conforme à des attentes fournies
  • les attentes peuvent être fournies à la définition du modèle en tant que classe Python
• Toute autre information utile à la reproductibilité manuelle d'une erreur constatée

OpenScraper pourrait contenir un écran qui affiche les résultats d'un run en mettant en avant les erreurs rencontrées

Pour les erreurs de contenu qui ne se conforme pas aux attentes, il pourrait être possible de manuellement accepter (un par un ou par groupe) que les contenus soient publiés

Si trop d'erreurs sont rencontrées, les données récupérées dans le run sont mises dans un espace temporaires et ne sont pas publiées. Une revue humaine est nécessaire pour validation. L'intervention d'un.e développeur.euse est peut-être nécessaire

Chemin de transition pour le Carrefour des Innovations Sociales

Rien de spécial, il s'agit d'une nouvelle fonctionnalité qui peut être ajoutée en complément du design actuel

Piste alternative et complémentaire

Plutôt que d'essayer de demander à chaque partenaire sa base de données, puis de travailler à l'uniformiser, la stratégie adoptée par le CIS a été de scrapper les sites des partenaires afin de composer rapidement le moteur de recherche

Au vu du travail conséquent que demande de maintenir OpenScraper et les spiders, rencontrer les partenaires pour voir si une solution alternative au scrapping est possible est peut-être une bonne piste\ Cette piste peut être menée en parallèle d'un redesign d'OpenScraper

[JulienParis]

Quelques ajouts/précisions sur les fonctionnalités "core" d'OpenScraper :

1. le but d'openscraper est non seulement de moissonner mais aussi de servir la donnée via l'API d'OpenScraper. Les runs de scraper (quelle que soit la refonte de l'outil de scrapping) doivent aboutir à envoyer ces données dans la base de donnée de telle manière qu'elle soit disponible pour le serveur d'API. Scrapers et API doivent pouvoir bien se coupler pour pouvoir faire "sortir" la donnée autant qu'ils lui permettent de "rentrer".
2. le but d'OpenScraper est non seulement de moissonner mais aussi de pré-structurer la donnée scrapée de telle manière que toute la donnée soit homogénéisée. Cette fonctionnalité et celle précisée auparavant font que le projet ne se concentre pas uniquement sur la partie scrapping, qui est la partie "sous le capot".
3. un autre objectif central de l'outil est de travailler à une interface graphique pour que l'utilisateur puisse "s'éloigner" du code source et des outils purement "dev", même si la tâche reste technique quelle que soit l'angle choisi pour scraper... Renvoyer les utilisateurs vers GitHub pour versionner des scrapers parlera aux développeurs mais peut éloigner de cette vision fondatrice de l'outil.
4. l'outil a été une réponse également au retour d'expérience des personnes au sein de Makina Corpus qui avaient développé un POC du carrefour des innovations sociales avant EIG : ils avaient en effet livré une série de scrappers, tous dans des fichiers différents. Leur retour d'expérience était que de maintenir/configurer de zéro/relancer à la main les scrappers leur avait demandé un temps conséquent par scraper à l'ensemble de leur équipe (a priori plus que ce que demande actuellement OpenScraper pour une personne).
5. enfin cet outil - du moins la démarche consistant à fabriquer une application open source de scrapping mettant en priorité l'interface - a rencontré un intérêt de principe auprès d'autres administrations : le fait que le scrapping soit dédié à des pages de listing et non du scrapping arbitraire est une fonctionnalité qui intéresse pour des usages déjà assez nombreux pour valider ce besoin précis.

Les problèmes principaux à date

• la gestion des erreurs : pas de retours vers l'utilisateur sur ce qui ce passe quand un scraper est lancé/testé.
• nombre de problèmes concernant le scrapping sont aussi liés à l'UX : il n'y a quasiment pas eu de recherche UX sur ce projet. Derrière le scrapping en tant que tel se cachent aussi des besoins divers : exporter ses données, les visualiser, repérer les erreurs...
• la maintenance et la question des ressources humaines : qui pour configurer et maintenir les scrappers (s'il s'agit de bouts de codes à relancer ou d'un applicatif) sur le moyen et long terme ? qui (dans la mesure où on "scrappe" moins mais que l'on demande les données aux différents membres du collectif) s'assure d'envoyer les demandes, de vérifier que les données sont complètes et mises à jour, et de les agréger ?

Pistes complémentaires

• j'abonde avec @DavidBruant sur le fait qu'OpenScraper est aujourd'hui imparfait, et qu'il pose la question de la maintenance, puis conséquemment la question de la stratégie de données du collectif, et enfin plus largement celle de la pérennité d'un projet numérique reposant en son coeur sur l'agrégation de données non structurées.
• comme dit plus haut il serait intéressant de penser OpenScraper en l'état plutôt comme une solution palliative ("faute de mieux", techniquement et humainement) en attendant que la question de la remontée des données au sein du collectif soit abordée de manière plus technique et plus stratégique. En effet jusqu'à maintenant le mot d'ordre au sein du collectif était de demander le moins d'effort et de temps aux partenaires ainsi qu'aux coordinateurs en ce qui concerne la récolte de données, ce qui n'est pas une solution pérenne vue la complexité technique du projet dans son ensemble ou la multiplicité des envies émises sur l'utilisation des données qui ont été émises par le collectif (recommandation, data visualisation, inter-opérabilité...).
• l'idée proposée plus haut d'avoir une page de "log" par scraper est à creuser, avec une réflexion UX également.
• les avantages de la piste du versioning sur GitHub des configurations de scrapers est encore vague pour moi, peut-être faudrait-il élaborer sur cette idée : ce que cela impliquerait en refonte de code, avantages vs inconvénients ? D'autres solutions de versioning existent avec MongoDB (ElasticSearch), benchmark nécessaire...
• un autre élément partiel de réponse est en germe avec solidata, avec la possibilité de pousser des fichiers et de les "mapper", plutôt que de faire du scrapping. L'avantage est que le process est un poil plus simple pour les utilisateurs, le niveau technique demandé est moindre mais demandera de toute manière une prise en main... mais là encore l'outil solidata ne résoudra une partie du problème que si une méthodologie de récolte est pensée en amont jusqu'au sein du collectif. Il peut probable d'arriver à créer un "bouton magique" répondant à tous les problèmes de data du projet global, surtout avec peu de moyens et en externalisant la production.
• une piste (plutôt un pansement) pour open scraper serait déjà de permettre des échanges client-serveur pour faire apparaître les messages d'erreur ou de test durant le scrapping en restant sur l'architecture logicielle actuelle mais en y intégrant la possibilité pour le serveur d'informer le client (avec par exemple en utilisant ce que permet Tornado ou socket-io et un peu plus de javascript en front)
• une dernière piste serait de repenser plus profondément l'interface de scrapping ainsi que le backend, en s'appuyant sur des frameworks plus adéquats pour l'IO entre client et serveur (type headless Chrome

Conclusion (temporaire et pour ouvrir la discussion)

• la récolte de données auprès des partenaires est un problème fondamental dans le projet Carrefour des innovations sociales mais aussi sa principale valeur ajoutée au regard des autres initiatives similaires : sans données mises à jour et propres il n'y a pas de plateforme possible. C'est un problème autant technique que d'organisation ou de vision, bref c'est bien une stratégie de la donnée qu'il s'agit de penser dans le collectif avec ce que cela implique d'y dédier en outillage, en moyens humains, en moyens financiers, et en réflexion sur la feuille de route ou encore la mutualisation des outils avec d'autres partenaires soucieux de l'intérêt général.
• OpenScraper n'est certainement pas un service aussi efficace que celui offert par des plateformes dont c'est le métier principal (import.io, captain data), mais qui sont des plateformes propriétaires. L'objectif a été pour le moment principalement été d'accoucher d'un POC de plateforme open source autonome de scrapping, certainement pas d'un produit fini ni d'un MVP vu le peu de moyens qui ont été mis dans ce projet précis (1 mois de dev, 1,5 mois de debugs, 1 développeur) alors que les plateformes de scrapping propriétaires sont des entreprises qui y dédient des équipes sur plusieurs années. Toutefois il permet en l'état, de manière artisanale, de faire le nécessaire pour avoir des données en aval.
• La vision que ce projet de scrapping cherche à véhiculer c'est de donner envie à des administrations de trouver/mutualiser des moyens afin que de telles applications existent en open source, et non de "laisser ça aux techniciens" (car cette politique court-termiste dans les services publics rencontre de nombreuses limites - budget, RH), ni de "laisser ça à des solutions propriétaires" ou à des experts seuls détenteurs de ce savoir-faire...
• les publics visés par ce projet n'étaient pas tant les développeurs que les personnels en demande d'outil de scrapping moins "code" et plus "interface".
• Des acteurs avec de faibles moyens RH et financiers (assos comme administrations), ainsi que le peu de compétences tech à disposition en interne pose à mon sens la question de formaliser une vision plus large et une prise de position : soit il s'agit de court terme et de besoins très spécifiques - auquel cas on peut apporter des solutions type "one-shot" 100% tech - soit une vision plus long terme qui demande d'avoir une réflexion globale (UX, dev, besoins, partenariats, politique, mutualisation) sur tout ce qui permet d'outiller de tels acteurs en évitant tout solutionnisme technologique.

[bzg]

Hello ! Super discussion, très éclairante sur les enjeux autour d'OpenScraper.

Je vois deux sujets:

1. OpenScraper comme logiciel libre qui apporte une solution générique, d'abord aux besoins de la construction du Carrefour des Innovations Sociales (CIS), potentiellement à d'autres collectifs;
2. OpenScraper tel qu'il est mis en oeuvre dès aujourd'hui comme outil au sein du CIS.

Pour chaque sujet, voici les priorités que j'identifie:

1. Trouver un deuxième utilisateur: le but est de valider le fait qu'il y a effectivement besoin d'une solution générique. L'existence de solutions propriétaires fournissant des fonctionnalités équivalentes est un bon indice du fait qu'il existe, quelque part, un deuxième utilisateur - mais le connaître pour de vrai apportera beaucoup.
2. Construire une interface permettant à un acteur disposant d'un inventaire sur son site de déclarer les XPath pertinents pour la collecte des informations de son inventaire telles qu'elles doivent finalement figurer dans un modèle de données défini.

Je pense que (2) est plus important que les questions de remontée des erreurs sur les spiders et que la question de leur versionnement en base de données ou via des fichiers.

Pour vous donner une idée de ce que j'imagine:

• un service web avec seulement un frontend, pas de base de données;
• une instance du service web déployée en fonction d'un modèle de données pris en paramètre, modèle qui correspond aux données structurées qu'on souhaite collecter;
• l'utilisateur du service est accompagné dans la saisie, pour chaque entrée du modèle de données, du XPath correspondant aux données à collecter sur son inventaire;
• s'il tente de renseigner un XPath renvoyant une erreur, il voit lui-même cette erreur et peut la corriger;
• l'output de l'utilisation du service est un fichier structuré (e.g. json) indiquant la liste des XPath qui serviront à définir un spider;
• cet output peut être envoyé à la personne qui fait tourner le service web ou par mail.

Aujourd'hui, je crois deviner deux points faibles d'OpenScraper: le côté monolithique de masterspider.py et la difficulté, pour un utilisateur non-technicien, de mettre à jour les spiders via l'interface. Je peux me tromper, mais j'ai le sentiment que ce deuxième point faible est le plus critique: si les utilisateurs du CIS disposent d'un moyen de déclarer plus facilement leurs XPath (via un formulaire web les aidant pas à pas), cela rendra moins prioritaire le problème de la remontée d'erreurs et celui de l'évolution de masterspider.py.

Bien sûr, il faut trouver une solution pour injecter les XPath reçus (en json) dans OpenScraper - mais une partie du code pour faire cela doit déjà exister, non?

A terme, il n'est pas inimaginable que ce soit OpenScraper lui-même qui propose cet outil de saisie des XPath facile à prendre en main, mais ce n'est pas nécessaire dans un premier temps; on peut aussi imaginer que la collection des json correspondant aux XPath de chaque site à scraper soit stockée sous forme de fichiers plutôt qu'en BDD, voire que les présupposés cités par @DavidBruant sur les listings ne soient plus hardcodés - mais ces évolutions d'OpenScraper pourraient être priorisées par l'équipe portant OpenScraper plutôt que par le CIS, qui a besoin d'une solution à court terme pour faciliter la mise à jour des points de collecte.

Je vois trois façons pour la discussion de rester dans une impasse:

1. vouloir s'attaquer trop tôt à masterspider.py, donc au « coeur de la bête »: comme la bête va vivre sa vie de logiciel libre ailleurs qu'au CIS, cela risque de remettre en cause l'utilisation d'OpenScraper pour le CIS;
2. arguer du potentiel de généricité d'OpenScraper pour refuser une solution ad hoc comme celle que j'imagine (ou une autre);
3. faire dériver la discussion sur la question de la bonne volonté de tels ou tels acteurs de soutenir une solution libre générique.

L'OpenScraper actuel a permis de collecter des milliers d'infos sur plein de sites: ç'aurait été impossible à la main ou en demandant aux acteurs de le faire dans les temps impartis! Maintenant il y a deux temporalités: à court terme, le souci de la mise à jour des spiders, à moyen terme l'évolution d'OpenScraper comme solution pour son futur deuxième utilisateur.

Je suis disponible pour en parler avec vous la semaine prochaine - il y a certainement beaucoup de naïveté dans mon approche, ce sera plus facile de me déniaiser en IRL :)

[JulienParis]

... petit suivi et réflexions complémentaires

questions d'UX

• effectivement la configuration de scraper est un point clé en terme d'UX : pour le moment il n'y a pas de preview ou d'aide pas-à-pas pour guider l'utilisateur dans l'ajout de xpaths (retours d'erreurs, prévisualisation des pages à scrapper...), mais le formulaire permettant d'ajouter/modifier les xpaths d'un scraper est déjà en place ==> cet aspect à lui seul plaiderait d'ailleurs pour une recherche UX sur OpenScraper : quels besoins, quels "pain points" rencontrent les utilisateurs réels et quelle hiérarchisation des chantiers cela implique-t-il...
• un autre point clé est celui de la documentation : comment faciliter la prise en main (tutoriels, site dédié?), la remontée de bugs, le support...

générique / ad hoc / service saas...

• Moins que de faire dériver la discussion sur la question de la "bonne volonté des acteurs" ou du potentiel générique de l'outil mes remarques plus haut avaient plus pour but de souligner la question de l'adéquation entre outils et moyens humains : qui est en charge de faire le moissonnage, quelles sont ses disponibilités pour faire ce travail, quelle charge le moissonnage représente dans le cadre de son rôle dans le projet, quelles sont ses compétences...? Il me semble que c'est en fonction de la ou des personnes en charges de ce travail de moissonnage et des conditions de travail que peut se faire le choix d'une méthodo (outil générique, payant ou open source, ad hoc...). Même si pour assumer ce rôle il s'agit de profil.s plutôt tech et compétent.e.s en scrapping, les moyens et la charge de travail sont aussi des points clés pour faire ces choix.
• quelques scénarios caricaturaux pour imager mon propos (où la "personne identifiée" est celle en charge du moissonnage) :
  • personne.s identifiée.s + compétences + peu de temps + besoin ponctuel + peu de moyens ==> outil ad hoc certainement plus adapté
  • personne.s identifiée.s + compétences + temps + besoin récurrent + moyens ==> méthodo _adhoc ou outil générique se valent peut-être (choix à faire en fonction de.s personne.s)
  • personne.s non identifiée.s + peu de temps + besoin récurrent + peu de moyens ==> outil générique/service saas peut-être plus adapté.s
  • etc, etc...
• en gros "l'humain d'abord" ;)

OpenScraper comme projet

• concernant la feuille de route, les modifications ou/et la refonte du code actuel il me semble que c'est effectivement un point majeur de la suite du projet OpenScraper, mais cela demande de savoir qui s'implique à moyen ou long terme (quelle équipe/product owner quoi), et de s'accorder sur une manière de décider des choix critiques concernant l'architecture même du code (forks, pivots, projets parallèles...).
• Envisager OpenScraper plutôt comme projet que comme outil implique qu'un ou des product owner.s se manifestent et qu'ils puissent s'accordent sur la vision vers laquelle tendre, vision qui jusqu'à maintenant se résume à :
  • une interface pour scrapper,
  • open source,
  • profil utilisateurs moyennement tech avec relativement peu de moyens,
  • réouverture des données (API sortante),
  • scrapper des listings,
  • maîtrise du degré de réouverture par "colonne",
  • autonomie de l'outil vis-à-vis de plateformes tierces (GitHub ou autre)...
• La question est donc - à mon avis encore - moins celle de "quelles solutions techniques pour résoudre les issues d'open scraper?" (car il y en a à la louche, et tout développeur aura certainement un point de vue différent sur le sujet), mais plutôt de "comment on décide d'une feuille de route, comment on s'organise, et qui fait maintient|conseille|contribue dans le cadre de ce projet particulier qu'est OpenScraper?".

réflexions / synthèse d'étape

• En un mot OpenScraper n'est pas l'outil magique open source de scrapping et les solutions _adhoc ou en saas ont de nombreux avantages. Toutefois plus qu'un outil il s'agit d'un projet en cours de définition, qui demande d'en penser la feuille de route (milestones), d'identifier qui sont les product owners/l'équipe, quelles compétences existent dans l''équipe, etc... Cet aspect est à mon sens totalement indépendant du choix d'une méthodo particulière (ad hoc|générique|saas...) dans le cadre d'un projet tiers (tel que CIS) où le scrapping n'est qu'un aspect technique à résoudre parmi d'autres.
• Dans le cas où OpenScraper est envisagé dans son aspect purement "outil" ou dans l'absence de tout product owner il peut bien évidemment "suivre sa vie de logiciel open source" : son code est de toute manière ouvert et n'importe qui peut le forker et le faire évoluer dans le cadre d'un autre projet ou d'une autre utilisation (mercantile, ad hoc ou autre).
• Le fil de cette discussion m'inciterait à proposer de modifier la définition du problème telle que proposée initialement par David : pour qu'il soit possible de proposer|mettre en oeuvre une solution technique (automatisation, report d'erreurs, aide à la configuration d'xpaths, monolithisme de masterspider.py...) il serait peut-être intéressant en premier lieu de s'accorder sur qui structure l'équipe opérationnelle de ce projet en terme de vision, développement, et d'UX.

note sur les utilisateur.rice.s identifié.e.s

• les utilisateurs effectifs qui ont testé ou testent actuellement OpenScraper (et qui pourraient être les premiers à intégrer dans une recherche UX) :
  • Asso Data for news : - (récupération de listings web et API)
  • APCIS : les devs qui bossent sur le projet CIS - (récupération de listings web et API)
  • Collectivité (Ville) : service informatique - (récupération de listings)
  • Cour des comptes : cadre d'un projet perso - (récupération de listings web et API)
  • Startup d'état Aides-Territoires : (récupération de listings web)

[JulienParis]

...et bien sûr je suis dispo IRL aussi pour en discuter :)

[bzg]

Merci pour ton retour !

(Je pense que la liste des utilisateurs identifiés ne devrait pas être publique...)

Ta réponse éclaircit beaucoup de choses pour moi: tu présentes OpenScraper comme un projet qui n'a pas de mainteneur, faute de moyens pour cette maintenance.

D'accord avec toi pour le point central sur l'adéquation entre les outils et les moyens humains: je pense que c'est aussi ce qui a initialement motivé les remarques de @DavidBruant. Cette adéquation est à trouver de deux côtés: celui du CIS (premier utilisateur d'OpenScraper en "production") et celui du (futur) mainteneur d'OpenScraper.

Dans l'idéal, tout s'aligne: le CIS porte un effort de réflexion sur l'UX porté aussi par la structure qui maintient OpenScraper, ou bien fait du développement fusionné upstream par l'équipe d'OpenScraper. Mais il y a aussi la possibilité que tout ne s'aligne pas.

Donc d'accord avec ta proposition de redéfinition du problème: à mon avis, cela mérite une issue à part, car le problème posé par l'issue initialement ouverte par @DavidBruant reste entier.

See you IRL!

[JulienParis]

L'image qui me vient est qu'un projet open source ressemble un peu à un groupe de jazz : on peut improviser, faire un boeuf, avoir des guests, des demandes du public, avoir un groupe temporairement ou un noyau de musiciens plus constitutif... mais au final c'est mieux de se trouver une identité ou/et des standards|répertoire avec lesquels jouer (ici la vision du projet) si on veut faire quelque chose de vaguement mélodieux pour l'audience...

[bzg]

La cathédrale, le bazar et le blue note ;)

[bzg]

J'ai ouvert une issue sur la maintenance. To be continued.

[DavidBruant]

Ecrire cette issue a été compliquée parce qu'il y avait beaucoup de problèmes différents mélangés J'imagine que lire cette issue a dû être compliqué parce que j'ai mélangé problèmes et solutions

J'ai extrait deux choses que je considère être des problèmes dans des issues séparées : #61 et #62 Je propose de discuter là-bas de si nous sommes d'accord sur le fait qu'il s'agit de problèmes et, si c'est le cas, de solutions possibles