Commission dolistore: Difference between revisions

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

- 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.

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.

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.

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.

- 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.

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.

- 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.

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.

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é.

| 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 |

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.

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.

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é.

| 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 |

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

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 ?

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.

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.

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

```text

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

```

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

La page d’accueil pourrait distinguer :

1. Les modules officiels.

2. Les modules ayant fait l’objet d’une revue ou d’une sélection éditoriale.

3. Les meilleures ventes sur une période définie.

4. Les nouveautés.

5. Une découverte aléatoire limitée.

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

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.

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

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

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é.

La fiche produit devrait suivre une structure claire :

1. Besoin auquel répond le module.

2. Fonctions incluses.

3. Limites et exclusions.

4. Captures en situation.

5. Prérequis et compatibilités.

6. Installation et documentation.

7. Support inclus et prestations complémentaires.

8. Historique des versions et conditions de mise à jour.

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.

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

```text

Vendeur

└── Produit / module

```

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

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.

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.

Prévoir des états lisibles :

- Maintenu.

- Ancien mais disponible.

- Déprécié.

- Indisponible.

- Retiré de la vente.

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

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.

Une procédure contradictoire est proposée :

1. Signalement documenté.

2. Accusé de réception et attribution.

3. Conservation des éléments utiles.

4. Demande de réponse au vendeur.

5. Analyse technique et, si nécessaire, juridique.

6. Décision motivée.

7. 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.

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é.

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.

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

1. Déployer d’abord les informations objectives.

2. Formaliser le traitement des litiges.

3. Expérimenter ensuite des avis textuels contextualisés.

4. Reporter la note globale tant que sa pertinence et sa modération ne sont pas établies.

- 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.

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

- 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.

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

- 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.

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.

Les usages doivent être distingués :

1. API de lecture du catalogue public.

2. Accès authentifié aux données propres du vendeur.

3. API d’édition des fiches.

4. 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.

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

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.

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

- Contrôle renforcé au-delà d’un certain prix.

- Frais de revue.

- Exemptions éventuelles pour les partenaires.

- Prix minimum.

- Adhésion vendeur obligatoire.

- Accueil réservé à certaines catégories de vendeurs.

- Critères du statut de partenaire.

| 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 |

Les questions de TVA, commissions et réductions doivent faire l’objet d’une note comptable et commerciale distincte.

| 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 |

| 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.

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.

| 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.

Les prochaines discussions devraient permettre de trancher :

1. La priorité donnée aux fiches vendeurs et aux corrections de visibilité.

2. Le principe et le périmètre de la validation préalable.

3. La composition de l’équipe de revue et ses règles d’indépendance.

4. Les critères de mise en avant sur l’accueil.

5. Le modèle de gestion des versions et compatibilités.

6. La procédure de litige et de recours.

7. L’expérimentation éventuelle des avis.

8. Les conditions d’accès vendeur et les avantages partenaires.

9. Les moyens bénévoles et financés.

10. Le responsable et les critères de réception de chaque premier lot.

1. Valider ou amender les priorités proposées.

2. Identifier les responsables de chaque premier lot.

3. Vérifier les données et l’état technique des travaux déjà engagés.

4. Publier ce document sur le wiki.

5. Recueillir les retours de la communauté.

6. Établir un cahier des charges pour les premiers lots retenus.

7. Organiser un pilote avant généralisation.

8. Présenter les résultats lors du prochain DevCamp.

Ce document doit évoluer 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.