Introduction

Le DoliStore joue un rôle central dans l’écosystème Dolibarr : il permet aux développeurs, intégrateurs et éditeurs de proposer des modules, services et extensions à une communauté d’utilisateurs toujours plus large. Sa richesse constitue une force, mais cette croissance soulève aujourd’hui des enjeux importants en matière de qualité, de lisibilité, de confiance et de soutenabilité.

Les échanges récents mettent en évidence plusieurs problématiques concrètes :

Une augmentation rapide du nombre de vendeurs et de modules publiés, rendant plus difficile la navigation et l’identification des offres réellement pertinentes.
La présence de fiches produits insuffisamment documentées, de descriptions ambiguës ou de promesses commerciales ne correspondant pas toujours au périmètre réel du module.
Des difficultés à distinguer les modules activement maintenus de ceux qui ne sont plus suivis par leur auteur.
Des informations de compatibilité parfois trop larges, peu rattachées à une version précise du module ou difficilement vérifiables.
Des situations de duplication, de fork ou de déclinaison commerciale pouvant créer de la confusion chez les acheteurs.
Un traitement des litiges, des remboursements et des signalements qui nécessite des procédures plus claires, plus traçables et plus équitables.
Une visibilité des vendeurs encore trop limitée, alors que la présentation de leur activité, de leurs services et de leur historique est essentielle pour établir la confiance.
Une charge de contrôle et de modération qui repose largement sur un nombre limité de personnes, dans un contexte associatif où les ressources humaines et le temps disponible sont contraints.

L’arrivée massive de modules générés ou assistés par IA a amplifié ces difficultés, sans en être la cause unique. L’IA est désormais un outil de développement utilisé de différentes façons. Le véritable enjeu n’est donc pas de stigmatiser son usage, mais d’évaluer le résultat : un module doit être compréhensible, fonctionnel, documenté, maintenu et accompagné d’un support adapté.

L’objectif de ces évolutions n’est pas de fermer le DoliStore aux nouveaux contributeurs ni de privilégier exclusivement les acteurs historiques. Au contraire, il s’agit de préserver un catalogue ouvert, tout en donnant à chacun les moyens de se différencier par la qualité de son travail, la régularité de sa maintenance, la clarté de sa communication et la qualité de son support.

Pour avancer de manière sereine, il est nécessaire d’impliquer davantage la communauté : développeurs, intégrateurs, éditeurs, utilisateurs, modérateurs et bénévoles. Les évolutions ne pourront pas reposer uniquement sur quelques personnes déjà fortement mobilisées. Elles nécessitent une répartition claire des responsabilités, des contributions variées, des outils adaptés et une capacité à avancer par étapes.

Les propositions présentées dans ce document visent donc à renforcer la qualité sans restreindre l’ouverture, à améliorer la confiance sans alourdir excessivement les processus, et à faire vivre un écosystème où les contributeurs sérieux, qu’ils soient nouveaux ou historiques, peuvent être identifiables et valorisés.

Il ne s’agit pas de tout refondre simultanément. La démarche proposée est progressive : corriger d’abord les points les plus impactants, expérimenter les évolutions les plus structurantes, recueillir les retours, puis généraliser les solutions qui auront démontré leur utilité.

Bases de travail

Ce document s’appuie sur les échanges publics de la communauté ainsi que sur deux réunions communautaires consacrées à l’évolution du DoliStore.

Les principales bases de travail sont les suivantes :

Discussion forum : DoliStore et modules générés par IA
Discussion forum : DoliStore — réorganisation de la fiche produit, avis et discussions
Discussion forum : Dolibarr — comment on fait sa pub ?
Première réunion communautaire du 6 octobre 2026, consacrée notamment à l’état du DoliStore, à la qualité des vendeurs et des modules, aux fiches vendeurs, à la recherche, à la documentation, aux données vendeurs et aux règles de publication.
Seconde réunion communautaire du 15 octobre 2026, consacrée notamment à la visibilité des nouveautés, à la validation des modules, aux fiches vendeurs, aux avis clients, aux litiges et remboursements, aux compatibilités et à l’organisation des prochaines étapes.

Les transcriptions et synthèses de ces réunions ont été utilisées comme support de travail. Elles ne constituent pas des décisions adoptées : elles servent à identifier les problématiques, les pistes d’amélioration et les arbitrages encore à réaliser.

Évolution du DoliStore : qualité, confiance et développement de l’écosystème

Statut : Proposition de travail
Responsable : Alexandre Spangaro
Version : 1.0
Date : 16 octobre 2026
Objet : Propositions d’évolution du DoliStore issues des échanges de la communauté et des réunions de travail.

1. Objet du document

Ce document synthétise les constats et propositions issus des échanges communautaires et des réunions de travail consacrées au DoliStore.

Il a pour objectif de proposer une trajectoire d’évolution progressive, réaliste et ouverte, afin de :

Améliorer la confiance des acheteurs.
Renforcer la qualité des informations publiées.
Faciliter l’identification des vendeurs et de leurs services.
Encadrer la publication et la maintenance des modules.
Préserver l’accessibilité du catalogue aux nouveaux contributeurs.
Rendre le traitement des litiges plus lisible et équitable.
Adapter les outils du DoliStore à l’évolution du nombre de vendeurs et de modules.

Les propositions présentées ici ne constituent pas des décisions déjà adoptées. Elles doivent être discutées, amendées puis arbitrées par les instances compétentes de l’association Dolibarr.

2. Diagnostic général

2.1 Un changement d’échelle

Le DoliStore a connu une forte croissance du nombre de vendeurs, de modules et de publications. Cette évolution ne peut plus être gérée uniquement par l’interconnaissance, la cooptation informelle et quelques personnes assurant les contrôles.

Le défi n’est pas de fermer l’accès aux nouveaux entrants, mais de leur proposer un parcours clair, des règles compréhensibles et des outils permettant de distinguer les offres sérieuses, maintenues et adaptées aux besoins des utilisateurs.

2.2 Des enjeux de confiance

Un acheteur doit pouvoir comprendre rapidement :

Ce que fait réellement un module.
Ce qu’il ne fait pas.
Quelles sont les dépendances et prérequis.
Quelle version de Dolibarr est concernée.
Qui est le vendeur.
Quel support est inclus.
Quel est l’état de maintenance du produit.
Comment obtenir de l’aide ou signaler un problème.

La qualité perçue dépend autant de la qualité de la fiche produit, de la documentation et du support que du code lui-même.

2.3 L’IA n’est pas le seul sujet

Les modules générés ou assistés par IA ont accéléré certains problèmes existants, mais ils ne constituent pas la cause unique des difficultés rencontrées.

L’IA peut être utilisée comme outil de développement. L’enjeu principal reste d’évaluer le résultat et la capacité du vendeur à assurer :

La compréhension du produit.
La maintenance dans le temps.
La documentation.
Le support.
La compatibilité annoncée.
La qualité de la fiche commerciale.

Les mêmes exigences doivent donc s’appliquer aux modules développés manuellement, avec assistance IA ou issus d’un fork.

2.4 Des limites de visibilité et de recherche

Plusieurs difficultés ont été identifiées :

La période de visibilité « nouveautés » ne démarre pas toujours au bon moment.
La date de mise à jour affichée ne distingue pas toujours une évolution du module d’une simple modification de fiche effectué par un administrateur du DoliStore (utilisation galvaudée du tms).
Les catégories et la recherche ne permettent plus de naviguer efficacement dans un catalogue volumineux.
Les compatibilités annoncées ne sont pas toujours rattachées à une version précise du module.
Les acheteurs peuvent acheter un module dont le périmètre réel ne correspond pas à leur besoin.

Ces sujets doivent être traités en parallèle de la question de la qualité des modules.

3. Principes directeurs

Les évolutions proposées reposent sur les principes suivants :

Ouverture : ne pas fermer l’accès aux nouveaux vendeurs, mais clarifier les règles et les parcours.
Transparence : publier les critères de sélection, de validation et de mise en avant.
Proportionnalité : adapter le niveau de contrôle au risque, à la complexité et au type de produit.
Équité : appliquer les mêmes règles à tous les vendeurs et prévoir une procédure contradictoire.
Progressivité : déployer les évolutions par lots testés, sans refonte globale simultanée.
Séparation des rôles : distinguer identité, adhésion, statut partenaire, contribution communautaire et qualité d’une version précise.
Respect du support vendeur : laisser au vendeur le choix de son canal de support, tout en le rendant visible et explicite.
Traçabilité : conserver les décisions, les motifs, les versions concernées et les éléments de preuve utiles.

4. Chantier prioritaire : fiches vendeurs

4.1 Créer une fiche vendeur native

La création de fiches vendeurs est proposée comme priorité. Elle doit permettre de centraliser l’identité du vendeur, son catalogue, ses services, son canal de support et sa présence dans l’écosystème.

La fiche vendeur ne doit pas se limiter aux sociétés. Elle doit également permettre aux développeurs individuels de présenter leur activité.

4.2 Contenu proposé

Rubrique	Informations proposées
Identification	Nom public, raison sociale ou statut adapté, pays, langues
Présentation	Logo, description de l’activité, spécialités
Catalogue	Modules actifs, nouveautés, modules gratuits et payants
Services	Développement, intégration, formation, maintenance, selon l’activité réelle
Support	Canal de support, langues, périmètre inclus, exclusions éventuelles
Historique	Présence sur le DoliStore, publications et évolutions
Écosystème	Contributions, statuts reconnus, liens publics pertinents
Informations commerciales	Réductions éventuelles, offres, liens vers les fiches produit

4.3 Distinguer les notions

Il est important de distinguer :

L’identité vérifiée du vendeur.
L’adhésion à l’association.
Le statut de partenaire.
La participation communautaire.
La revue d’une version précise d’un module.

Un statut commercial ou associatif ne doit pas être présenté comme une garantie automatique de fonctionnement de tous les produits proposés.

4.4 Annuaire des vendeurs

Un annuaire des vendeurs peut compléter les fiches vendeurs. Il permettrait notamment de :

Rechercher un vendeur par nom, pays ou spécialité.
Accéder directement à son catalogue.
Identifier les vendeurs proposant des services complémentaires.
Mettre en avant les nouveaux vendeurs ayant complété leur fiche.

5. Chantier qualité : validation des modules

5.1 Renforcer la validation avant publication

Il est proposé de renforcer la validation avant publication plutôt que de publier systématiquement puis de retirer les modules posant problème.

L’objectif n’est pas de créer un filtre bloquant ou une barrière à l’entrée, mais de fournir un parcours clair, des contrôles proportionnés et un accompagnement vers la mise en conformité.

5.2 Trois niveaux de contrôle

Niveau	Périmètre proposé	Résultat attendu
Contrôle automatique	Archive, métadonnées, règles techniques, cohérence des informations	Rapport de contrôles
Revue de publication	Fiche produit, documentation, support, captures et promesses commerciales	Publication ou demande de correction
Revue fonctionnelle approfondie	Installation, activation et scénarios représentatifs	Rapport de test associé à une version

Les contrôles automatiques doivent distinguer les anomalies bloquantes des alertes nécessitant une appréciation humaine.

Un score de similarité, par exemple, ne doit pas produire seul une accusation de copie. Il doit déclencher une revue.

5.3 Grille de revue proposée

La revue pourrait vérifier les points suivants :

L’archive correspond-elle au produit annoncé ?
L’installation et l’activation fonctionnent-elles dans l’environnement retenu ?
Les principales fonctions annoncées sont-elles accessibles ?
Les prérequis et dépendances sont-ils expliqués ?
La documentation permet-elle une prise en main raisonnable ?
Le périmètre du support et les exclusions sont-ils explicites ?
Les captures correspondent-elles au produit distribué ?
Les contrôles techniques bloquants sont-ils satisfaits ?

Chaque résultat doit préciser la version du module, l’environnement de test, la date et les limites de la revue.

Le libellé public recommandé est « version revue » ou « contrôle réalisé », plutôt qu’une « certification » générale dont la portée ne serait pas définie.

5.4 Validation communautaire

Il est proposé d’étudier une équipe initiale de trois à quatre validateurs, avec des règles claires :

Déclaration des conflits d’intérêts.
Interdiction de valider son propre produit.
Réattribution possible d’un dossier.
Motivation écrite des refus.
Recours examiné par une autre personne.
Accès limité aux seules données nécessaires.

Le nombre d’approbations requises doit être adapté au niveau de contrôle. Une revue simple peut être confiée à une personne ; une seconde lecture peut être demandée pour les dossiers sensibles, les désaccords ou les décisions de refus.

5.5 Suivi visible pour le vendeur

Le vendeur doit connaître l’état de son dossier :

Brouillon → Déposé → Contrôles en cours → À corriger → En revue → Publié

Prévoir également des états « refusé », « suspendu » et « archivé », accompagnés d’un motif.

L’objectif est d’éviter les modules bloqués sans explication.

6. Chantier visibilité : accueil, recherche et fiche produit

6.1 Réorganiser la page d’accueil

La page d’accueil pourrait distinguer :

Les modules officiels.
Les modules ayant fait l’objet d’une revue ou d’une sélection éditoriale.
Les meilleures ventes sur une période définie.
Les nouveautés.
Une découverte aléatoire limitée.

Il est proposé de limiter le bloc aléatoire à 24 éléments dans une première expérimentation.

Les meilleures ventes et la sélection qualitative doivent rester deux notions distinctes.

6.2 Règles de mise en avant

Pour éviter les déséquilibres, il est proposé de :

Limiter la présence d’un même vendeur dans un bloc.
Réserver une place aux nouveaux entrants.
Publier les critères de sélection.
Dater et réexaminer les sélections.
Identifier séparément toute mise en avant sponsorisée.

La simple ancienneté ou le volume historique de ventes ne doit pas constituer l’unique critère de mise en avant.

6.3 Corriger les nouveautés

La période de 30 jours de visibilité doit commencer à la première publication effective, et non à la demande de validation.

Une modification de texte, une traduction ou un simple changement d’intitulé ne devrait pas réinitialiser cette période.

Une nouvelle version peut alimenter un espace « mises à jour », sans faire systématiquement réapparaître le produit comme nouveau module.

6.4 Améliorer la recherche

Les évolutions proposées sont :

Des catégories métier et techniques mieux structurées.
Des mots-clés multilingues.
Des filtres par version Dolibarr, langue, prix et statut de maintenance.
Des filtres par revue réalisée ou compatibilité testée.
Une recherche par vendeur.
Des tris explicites : pertinence, nouveautés, mises à jour et ventes récentes.

Les volumes de ventes peuvent être présentés par tranches, sous réserve d’arbitrage. Ils doivent être accompagnés d’une période de référence et ne pas devenir l’unique signal de qualité.

6.5 Revoir la fiche produit

La fiche produit devrait suivre une structure claire :

Besoin auquel répond le module.
Fonctions incluses.
Limites et exclusions.
Captures en situation.
Prérequis et compatibilités.
Installation et documentation.
Support inclus et prestations complémentaires.
Historique des versions et conditions de mise à jour.

Il est proposé de demander au moins une illustration représentative du fonctionnement réel. Pour une API ou un service sans interface exploitable, une démonstration adaptée peut être acceptée.

La suppression du carrousel n’étant pas consensuelle, il est proposé de tester une maquette avec images intégrées dans les sections de contenu avant décision définitive.

7. Chantier technique : versions et compatibilités

7.1 Rattacher la compatibilité à chaque version distribuée

La compatibilité ne doit plus être gérée uniquement au niveau global du module. Elle doit être rattachée à chaque version distribuée.

Modèle cible :

Vendeur
└── Produit / module
    └── Version distribuée
        ├── Archive
        ├── Date de publication
        ├── Compatibilité Dolibarr
        ├── Compatibilité PHP et dépendances
        ├── Changelog
        ├── Statut de maintenance
        └── Contrôles et revues

Cela permet de conserver une fiche produit unique tout en présentant plusieurs versions techniques ou générations commerciales.

7.2 Distinguer compatibilité déclarée et testée

Il est proposé d’afficher clairement :

La compatibilité déclarée par l’éditeur.
La compatibilité testée par l’éditeur.
La compatibilité contrôlée par un tiers, avec environnement et date.

Une extension de compatibilité sans modification de code doit être possible si un test la justifie. Elle ne doit pas être présentée automatiquement comme une nouvelle version.

7.3 Séparer les dates

Prévoir des champs distincts pour :

La demande de publication.
La première publication.
La publication de la dernière version.
La modification de la fiche.
La dernière vérification de compatibilité.

La simple modification d’une fiche ne doit plus être assimilée à une mise à jour du module.

7.4 Gérer la dépréciation

Prévoir des états lisibles :

Maintenu.
Ancien mais disponible.
Déprécié.
Indisponible.
Retiré de la vente.

Les versions dépendant d’un service externe devenu inutilisable doivent être explicitement signalées.

L’accès des anciens acheteurs, la visibilité publique et le retrait de la vente doivent être traités séparément.

8. Forks, duplications et marketplaces externes

8.1 Distinguer les situations

Il convient de distinguer :

La copie directe de code.
La concurrence fonctionnelle entre modules différents.
Les « auto-forks » publiés périodiquement pour retrouver de la visibilité.
Les déclinaisons linguistiques ou commerciales d’un même produit.

Un outil de comparaison de modules et un seuil de similarité peuvent être utilisés comme signal de revue, mais pas comme verdict automatique.

8.2 Procédure de signalement

Une procédure contradictoire est proposée :

Signalement documenté.
Accusé de réception et attribution.
Conservation des éléments utiles.
Demande de réponse au vendeur.
Analyse technique et, si nécessaire, juridique.
Décision motivée.
Possibilité de recours.

Les règles d’accès aux archives ou aux preuves demandées par un plaignant doivent être définies avec le conseil juridique.

8.3 Réduire les fiches artificiellement dupliquées

Une fiche principale peut regrouper les déclinaisons essentiellement linguistiques, techniques ou commerciales d’un même produit.

Une fiche distincte devrait correspondre à une offre réellement distincte, et non à un simple changement de nom ou de secteur destiné à recréer une nouveauté.

8.4 Clarifier les liens externes

Il est proposé de publier une doctrine courte, validée juridiquement, précisant :

Les liens autorisés.
Les destinations interdites ou encadrées.
Les règles applicables aux promotions et aux prix.
Les délais de mise en conformité.
Les sanctions et recours.

L’existence d’une boutique externe ne doit pas remplacer l’examen des pratiques effectivement reprochées.

9. Avis, support, litiges et remboursements

9.1 Avis clients

Les avis clients ne doivent pas être déployés sans cadre clair. Il est proposé de :

Déployer d’abord les informations objectives.
Formaliser le traitement des litiges.
Expérimenter ensuite des avis textuels contextualisés.
Reporter la note globale tant que sa pertinence et sa modération ne sont pas établies.

Les conditions proposées pour un avis sont :

Usage ou achat vérifiable.
Rattachement à une version du module.
Indication de l’environnement Dolibarr.
Droit de réponse du vendeur.
Signalement à un modérateur indépendant.
Historique des corrections et réponses.

Le vendeur ne doit pas pouvoir bloquer indéfiniment un avis négatif. Inversement, l’avis ne doit pas devenir un moyen d’obtenir une prestation non incluse.

9.2 Support vendeur

Le vendeur doit conserver la liberté de choisir son canal de support : forum, tickets, adresse email, téléphone ou autre outil.

Le DoliStore doit :

Rendre ce canal visible.
Expliquer les prestations incluses.
Orienter les demandes techniques vers le vendeur.
Centraliser les litiges commerciaux sans imposer un outil unique de support.

9.3 Dossier de litige

Il est proposé de créer un dossier de litige dans l’administration du DoliStore.

Le dossier devrait contenir :

Commande, module et version.
Motif de la demande.
Échanges et justificatifs.
Notification au vendeur.
Délai de réponse annoncé.
Proposition de résolution.
Décision et trace du remboursement éventuel.

Les modalités de remboursement et la répartition des frais doivent être formalisées, puis validées avant publication dans les conditions applicables.

10. Données, outils vendeurs et communication

10.1 Tableau de bord vendeur

Il est proposé de fournir aux vendeurs un tableau de bord contenant :

Visites agrégées et méthode de comptage.
Ventes et téléchargements.
Évolution par période.
État des validations.
Litiges et remboursements.
Alertes sur les informations à actualiser.

Le partage de données collectives doit être autorisé et agrégé. Un accès éventuel à des outils d’analyse devra respecter les droits de chaque vendeur.

10.2 API

Les usages doivent être distingués :

API de lecture du catalogue public.
Accès authentifié aux données propres du vendeur.
API d’édition des fiches.
Dépôt d’archives, ultérieurement.

Les écritures automatisées devront respecter les mêmes règles de contrôle et de visibilité que les opérations manuelles.

10.3 Place du forum

La fiche vendeur doit devenir le lieu de présentation commerciale.

La fiche produit doit décrire le produit.

Le forum doit rester un espace d’entraide et de retours d’expérience.

Il est proposé de publier une charte illustrée pour éviter les décisions de modération perçues comme fondées sur la seule notoriété du contributeur.

11. Arbitrages économiques et associatifs

Plusieurs pistes ont été évoquées sans constituer un modèle adopté :

Contrôle renforcé au-delà d’un certain prix. (Évocation d'une limite de contrôle renforcé si prix de vente du module supérieur à 100 € HT)
Frais de revue. (Évocation d'un prix de 75,00 € HT de vérification d'un module en lien avec le point ci-dessus)
Exemptions éventuelles pour les Preferred Partner.
Prix minimum. (Évocation passage de 2 € HT à 10 € HT minimum)
Adhésion vendeur obligatoire à l'association Dolibarr. (Non obligatoire aujourd'hui alors que cela l'était pas le passé)
Accueil réservé à certaines catégories de vendeurs.
Critères du statut de Preferred Partner.

Sujet	Recommandation
Contrôle lié au prix	Ne pas utiliser le prix comme seul critère ; intégrer complexité, risques et historique
Frais de revue	Mesurer d’abord le temps et le coût sur un pilote
Exemption partenaire	Ne pas supprimer le socle minimal de contrôle
Prix minimum	Étudier les coûts réels ; ne pas le présenter comme un outil qualité
Adhésion obligatoire	Arbitrage associatif distinct de l’évaluation du produit
Accueil réservé aux adhérents	Évaluer l’impact sur l’ouverture et la découverte
Statut partenaire	Publier critères, renouvellement, suspension et recours
Réductions et commissions	Produire une documentation avec exemples validés

Un simple litige en cours ne devrait pas suffire automatiquement à exclure un vendeur d’un statut. Il convient de définir des manquements objectivés et une procédure contradictoire.

Les questions de TVA, commissions et réductions doivent faire l’objet d’une note comptable et commerciale distincte et d'un vote du bureau de l'association

12. Gouvernance et feuille de route

12.1 Répartition des responsabilités

Rôle	Mission
Bureau	Arbitrer politique, budget et règles
Coordination DoliStore	Organiser le programme et publier l’avancement
Équipe technique	Développer, tester et maintenir
Référent qualité	Définir la grille et accompagner les validateurs
Équipe UX/contenu	Concevoir les modèles et tester les parcours
Conseil juridique	Valider les dispositions sensibles
Représentants utilisateurs et vendeurs	Participer aux tests et retours

12.2 Lots de réalisation

Lot	Contenu	Condition de lancement
0 — Cadrage	Inventaire, chiffres fiables, état des travaux, arbitrages	Responsable identifié
1 — Corrections rapides	Nouveautés depuis validation, dates distinctes, motifs d’attente, miniatures	Vérification technique
2 — Fiches vendeurs	Annuaire, catalogue regroupé, support, services, statuts	Modèle de données et maquette
3 — Validation pilote	Dashboard, grille, équipe de revue, historique	Capacité humaine confirmée
4 — Parcours d’achat	Accueil, recherche, fiches produit, langues	Tests utilisateurs
5 — Versions et litiges	Compatibilités par version, dépréciation, dossiers de litige	Règles et modèle validés
6 — Données et extensions	Dashboard vendeur, API, avis expérimentaux	Gouvernance des données

Il est préférable de lancer peu de lots simultanément et de vérifier leur fonctionnement avant généralisation.

12.3 Migration de l’existant

Proposition :

Appliquer les nouvelles exigences aux nouveaux dépôts après information préalable.
Accorder un délai de mise en conformité aux fiches existantes.
Traiter en priorité les signalements, incompatibilités et informations manifestement insuffisantes.
Revoir progressivement le catalogue lors des mises à jour.
Ne pas qualifier rétroactivement un produit de « testé » sans revue correspondante.

13. Indicateurs de suivi

Objectif	Indicateurs proposés
Réduire l’attente	Dossiers en attente, délai médian et dossiers les plus anciens
Améliorer les fiches	Complétude, documentation et illustrations représentatives
Fiabiliser les compatibilités	Versions renseignées, déclarations et tests distingués
Équilibrer la visibilité	Concentration des impressions, exposition des nouveaux vendeurs
Faciliter la recherche	Recherches sans résultat, usage des filtres
Traiter les litiges	Délais, motifs, taux et coûts rapportés aux ventes
Maîtriser la charge	Temps de revue, coût et retours pour correction

La croissance du nombre de modules ou du chiffre d’affaires global ne doit pas constituer le seul critère de réussite.

14. Décisions attendues

Les prochaines discussions devraient permettre de trancher :

La priorité donnée aux fiches vendeurs et aux corrections de visibilité.
Le principe et le périmètre de la validation préalable.
La composition de l’équipe de revue et ses règles d’indépendance.
Les critères de mise en avant sur l’accueil.
Le modèle de gestion des versions et compatibilités.
La procédure de litige et de recours.
L’expérimentation éventuelle des avis.
Les conditions d’accès vendeur et les avantages partenaires.
Les moyens bénévoles et financés.
Le responsable et les critères de réception de chaque premier lot.

15. Prochaines étapes

Valider ou amender les priorités proposées.
Identifier les responsables de chaque premier lot.
Vérifier les données et l’état technique des travaux déjà engagés.
Publier ce document sur le wiki. OK
Recueillir les retours de la communauté.
Établir un cahier des charges pour les premiers lots retenus.
Organiser un pilote avant généralisation.
Présenter les résultats lors du prochain DevCamp de Lyon - novembre 2026

Ce document évoluera avec les retours de la communauté. Il ne vise pas à figer des décisions, mais à proposer un cadre commun pour faire progresser le DoliStore de manière sereine, ouverte et durable.

Commission dolistore