Commission dolistore - Revision history

Aspangaro: /* 11. Arbitrages économiques et associatifs */

2026-10-16T07:34:27Z

11. Arbitrages économiques et associatifs

← Older revision		Revision as of 07:34, 16 October 2026
Line 521:		Line 521:
	*Frais de revue. (Évocation d'un prix de 75,00 € HT de vérification d'un module en lien avec le point ci-dessus)		*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.		*Exemptions éventuelles pour les Preferred Partner.
	*Prix minimum. (~~Passage~~ de 2 € HT à 10 € HT minimum)		*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é)		*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.		*Accueil réservé à certaines catégories de vendeurs.
	*Critères du statut de Preferred Partner.		*Critères du statut de Preferred Partner.

Aspangaro: /* 11. Arbitrages économiques et associatifs */

2026-10-16T07:33:31Z

11. Arbitrages économiques et associatifs

← Older revision		Revision as of 07:33, 16 October 2026
Line 518:		Line 518:
	Plusieurs pistes ont été évoquées sans constituer un modèle adopté<span> </span>:		Plusieurs pistes ont été évoquées sans constituer un modèle adopté<span> </span>:

	*Contrôle renforcé au-delà d’un certain prix.		*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.		*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 ~~partenaires~~.		*Exemptions éventuelles pour les Preferred Partner.
	*Prix minimum.		*Prix minimum. (Passage de 2 € HT à 10 € HT minimum)
	*Adhésion vendeur obligatoire.		*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.		*Accueil réservé à certaines catégories de vendeurs.
	*Critères du statut de ~~partenaire~~.		*Critères du statut de Preferred Partner.

	{\| class="wikitable"		{\| class="wikitable"
Line 557:		Line 557:
	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.		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.		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. Gouvernance et feuille de route==
Line 687:		Line 687:
	#Identifier les responsables de chaque premier lot.		#Identifier les responsables de chaque premier lot.
	#Vérifier les données et l’état technique des travaux déjà engagés.		#Vérifier les données et l’état technique des travaux déjà engagés.
	#Publier ce document sur le wiki.		#Publier ce document sur le wiki. '''''OK'''''
	#Recueillir les retours de la communauté.		#Recueillir les retours de la communauté.
	#Établir un cahier des charges pour les premiers lots retenus.		#Établir un cahier des charges pour les premiers lots retenus.
	#Organiser un pilote avant généralisation.		#Organiser un pilote avant généralisation.
	#Présenter les résultats lors du prochain DevCamp.		#Présenter les résultats lors du prochain DevCamp de Lyon - novembre 2026

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

Aspangaro: /* 2.4 Des limites de visibilité et de recherche */

2026-10-16T07:23:22Z

2.4 Des limites de visibilité et de recherche

Show changes

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

2026-10-16T07:21:10Z

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

← Older revision		Revision as of 07:21, 16 October 2026
Line 41:		Line 41:

	'''Statut :''' Proposition de travail<br>		'''Statut :''' Proposition de travail<br>
			'''Responsable :''' Alexandre Spangaro<br>
	'''Version :''' 1.0<br>		'''Version :''' 1.0<br>
	'''Date :''' 16 octobre 2026<br>		'''Date :''' 16 octobre 2026<br>

Aspangaro at 06:44, 16 October 2026

2026-10-16T06:44:08Z

← Older revision		Revision as of 06:44, 16 October 2026
Line 23:		Line 23:

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

			* [https://www.dolibarr.fr/forum/t/dolistore-et-modules-generes-par-ia/51035 Discussion forum : DoliStore et modules générés par IA]
			* [https://www.dolibarr.fr/forum/t/dolistore-reorganisation-fiche-produit-avis-et-discussions/49053 Discussion forum : DoliStore — réorganisation de la fiche produit, avis et discussions]
			* [https://www.dolibarr.fr/forum/t/dolibarr-comment-on-fait-sa-pub/51960 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 =		= Évolution du DoliStore : qualité, confiance et développement de l’écosystème =
Line 28:		Line 42:
	'''Statut :''' Proposition de travail<br>		'''Statut :''' Proposition de travail<br>
	'''Version :''' 1.0<br>		'''Version :''' 1.0<br>
	'''Date :''' 15 octobre 2026<br>		'''Date :''' 16 octobre 2026<br>
	'''Objet :''' Propositions d’évolution du DoliStore issues des échanges de la communauté et des réunions de travail.		'''Objet :''' Propositions d’évolution du DoliStore issues des échanges de la communauté et des réunions de travail.

Aspangaro at 04:41, 16 October 2026

2026-10-16T04:41:05Z

Show changes

Aspangaro: Ajout introduction

2026-10-16T04:38:56Z

Ajout introduction

← Older revision		Revision as of 04:38, 16 October 2026
Line 1:		Line 1:
			== 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é.

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

Aspangaro at 04:35, 16 October 2026

2026-10-16T04:35:25Z

Show changes

Aspangaro: Publication v1.0

2026-10-16T04:34:43Z

Publication v1.0

New page

<nowiki>#</nowiki> Évolution du DoliStore : qualité, confiance et développement de l’écosystème

<nowiki>**</nowiki>Statut :** Proposition de travail

<nowiki>**</nowiki>Version :** 1.0

<nowiki>**</nowiki>Date :** 15 octobre 2026

<nowiki>**</nowiki>Objet :** Propositions d’évolution du DoliStore issues des échanges de la communauté et des réunions de travail.

<nowiki>##</nowiki> 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.

<nowiki>##</nowiki> 2. Diagnostic général

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

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

<nowiki>##</nowiki> 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.

<nowiki>##</nowiki> 4. Chantier prioritaire : fiches vendeurs

<nowiki>###</nowiki> 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é.

<nowiki>###</nowiki> 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 |

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 5. Chantier qualité : validation des modules

<nowiki>###</nowiki> 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é.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 5.5 Suivi visible pour le vendeur

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

```text

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.

<nowiki>##</nowiki> 6. Chantier visibilité : accueil, recherche et fiche produit

<nowiki>###</nowiki> 6.1 Réorganiser la page d’accueil

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.

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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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é.

<nowiki>###</nowiki> 6.5 Revoir la fiche produit

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.

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.

<nowiki>##</nowiki> 7. Chantier technique : versions et compatibilités

<nowiki>###</nowiki> 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 :

```text

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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 8. Forks, duplications et marketplaces externes

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 8.2 Procédure de signalement

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.

<nowiki>###</nowiki> 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é.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 9. Avis, support, litiges et remboursements

<nowiki>###</nowiki> 9.1 Avis clients

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.

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.

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 10. Données, outils vendeurs et communication

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 10.2 API

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.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 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.

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

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.

<nowiki>##</nowiki> 12. Gouvernance et feuille de route

<nowiki>###</nowiki> 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 |

<nowiki>###</nowiki> 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.

<nowiki>###</nowiki> 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.

<nowiki>##</nowiki> 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.

<nowiki>##</nowiki> 14. Décisions attendues

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.

<nowiki>##</nowiki> 15. Prochaines étapes

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.