Commission dolistore: Difference between revisions

Jump to navigation Jump to search

Commission dolistore (view source)

Revision as of 04:41, 16 October 2026

276 bytes added ,  5 days ago
no edit summary
VisualWikitext
(Ajout introduction)
Tag: 2017 source edit
No edit summary
Tag: 2017 source edit
Line 24: Line 24:
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é.


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


**Statut :** Proposition de travail
'''Statut :''' Proposition de travail<br>
**Version :** 1.0
'''Version :''' 1.0<br>
**Date :** 15 octobre 2026
'''Date :''' 15 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.


## 1. Objet du document
== 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.
Ce document synthétise les constats et propositions issus des échanges communautaires et des réunions de travail consacrées au DoliStore.
Line 37: Line 37:
Il a pour objectif de proposer une trajectoire d’évolution progressive, réaliste et ouverte, afin de :
Il a pour objectif de proposer une trajectoire d’évolution progressive, réaliste et ouverte, afin de :


- Améliorer la confiance des acheteurs.
* Améliorer la confiance des acheteurs.
- Renforcer la qualité des informations publiées.
* Renforcer la qualité des informations publiées.
- Faciliter l’identification des vendeurs et de leurs services.
* Faciliter l’identification des vendeurs et de leurs services.
- Encadrer la publication et la maintenance des modules.
* Encadrer la publication et la maintenance des modules.
- Préserver l’accessibilité du catalogue aux nouveaux contributeurs.
* Préserver l’accessibilité du catalogue aux nouveaux contributeurs.
- Rendre le traitement des litiges plus lisible et équitable.
* Rendre le traitement des litiges plus lisible et équitable.
- Adapter les outils du DoliStore à l’évolution du nombre de vendeurs et de modules.
* 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.
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. Diagnostic général ==


### 2.1 Un changement d’échelle
=== 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 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.
Line 55: Line 55:
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.
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
=== 2.2 Des enjeux de confiance ===


Un acheteur doit pouvoir comprendre rapidement :
Un acheteur doit pouvoir comprendre rapidement :


- Ce que fait réellement un module.
* Ce que fait réellement un module.
- Ce qu’il ne fait pas.
* Ce qu’il ne fait pas.
- Quelles sont les dépendances et prérequis.
* Quelles sont les dépendances et prérequis.
- Quelle version de Dolibarr est concernée.
* Quelle version de Dolibarr est concernée.
- Qui est le vendeur.
* Qui est le vendeur.
- Quel support est inclus.
* Quel support est inclus.
- Quel est l’état de maintenance du produit.
* Quel est l’état de maintenance du produit.
- Comment obtenir de l’aide ou signaler un problème.
* 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.
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
=== 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.
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.
Line 76: Line 76:
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 :
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 compréhension du produit.
- La maintenance dans le temps.
* La maintenance dans le temps.
- La documentation.
* La documentation.
- Le support.
* Le support.
- La compatibilité annoncée.
* La compatibilité annoncée.
- La qualité de la fiche commerciale.
* 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.
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
=== 2.4 Des limites de visibilité et de recherche ===


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


- La période de visibilité « nouveautés » ne démarre pas toujours au bon moment.
* 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.
* 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 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 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.
* 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.
Ces sujets doivent être traités en parallèle de la question de la qualité des modules.


## 3. Principes directeurs
== 3. Principes directeurs ==


Les évolutions proposées reposent sur les principes suivants :
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.
* '''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.
* '''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.
* '''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.
* '''É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.
* '''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.
* '''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.
* '''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.
* '''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. Chantier prioritaire : fiches vendeurs ==


### 4.1 Créer une fiche vendeur native
=== 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 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.
Line 118: Line 118:
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é.
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é
=== 4.2 Contenu proposé ===


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


Il est important de distinguer :
Il est important de distinguer :


- L’identité vérifiée du vendeur.
* L’identité vérifiée du vendeur.
- L’adhésion à l’association.
* L’adhésion à l’association.
- Le statut de partenaire.
* Le statut de partenaire.
- La participation communautaire.
* La participation communautaire.
- La revue d’une version précise d’un module.
* 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 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
=== 4.4 Annuaire des vendeurs ===


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


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


## 5. Chantier qualité : validation des modules
== 5. Chantier qualité : validation des modules ==


### 5.1 Renforcer la validation avant publication
=== 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.
Il est proposé de renforcer la validation avant publication plutôt que de publier systématiquement puis de retirer les modules posant problème.
Line 160: Line 178:
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é.
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
=== 5.2 Trois niveaux de contrôle ===


| Niveau | Périmètre proposé | Résultat attendu |
{| class="wikitable"
|---|---|---|
! Niveau
| Contrôle automatique | Archive, métadonnées, règles techniques, cohérence des informations | Rapport de contrôles |
! Périmètre proposé
| Revue de publication | Fiche produit, documentation, support, captures et promesses commerciales | Publication ou demande de correction |
! Résultat attendu
| Revue fonctionnelle approfondie | Installation, activation et scénarios représentatifs | Rapport de test associé à une version |
|-
| 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.
Les contrôles automatiques doivent distinguer les anomalies bloquantes des alertes nécessitant une appréciation humaine.
Line 172: Line 202:
Un score de similarité, par exemple, ne doit pas produire seul une accusation de copie. Il doit déclencher une revue.
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
=== 5.3 Grille de revue proposée ===


La revue pourrait vérifier les points suivants :
La revue pourrait vérifier les points suivants :


- L’archive correspond-elle au produit annoncé ?
* L’archive correspond-elle au produit annoncé ?
- L’installation et l’activation fonctionnent-elles dans l’environnement retenu ?
* L’installation et l’activation fonctionnent-elles dans l’environnement retenu ?
- Les principales fonctions annoncées sont-elles accessibles ?
* Les principales fonctions annoncées sont-elles accessibles ?
- Les prérequis et dépendances sont-ils expliqués ?
* Les prérequis et dépendances sont-ils expliqués ?
- La documentation permet-elle une prise en main raisonnable ?
* La documentation permet-elle une prise en main raisonnable ?
- Le périmètre du support et les exclusions sont-ils explicites ?
* Le périmètre du support et les exclusions sont-ils explicites ?
- Les captures correspondent-elles au produit distribué ?
* Les captures correspondent-elles au produit distribué ?
- Les contrôles techniques bloquants sont-ils satisfaits ?
* 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.
Chaque résultat doit préciser la version du module, l’environnement de test, la date et les limites de la revue.
Line 189: Line 219:
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.
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
=== 5.4 Validation communautaire ===


Il est proposé d’étudier une équipe initiale de trois à quatre validateurs, avec des règles claires :
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.
* Déclaration des conflits d’intérêts.
- Interdiction de valider son propre produit.
* Interdiction de valider son propre produit.
- Réattribution possible d’un dossier.
* Réattribution possible d’un dossier.
- Motivation écrite des refus.
* Motivation écrite des refus.
- Recours examiné par une autre personne.
* Recours examiné par une autre personne.
- Accès limité aux seules données nécessaires.
* 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 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
=== 5.5 Suivi visible pour le vendeur ===


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


```text
<pre>
Brouillon → Déposé → Contrôles en cours → À corriger → En revue → Publié
Brouillon → Déposé → Contrôles en cours → À corriger → En revue → Publié
```
</pre>


Prévoir également des états « refusé », « suspendu » et « archivé », accompagnés d’un motif.
Prévoir également des états « refusé », « suspendu » et « archivé », accompagnés d’un motif.
Line 214: Line 244:
L’objectif est d’éviter les modules bloqués sans explication.
L’objectif est d’éviter les modules bloqués sans explication.


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


### 6.1 Réorganiser la page d’accueil
=== 6.1 Réorganiser la page d’accueil ===


La page d’accueil pourrait distinguer :
La page d’accueil pourrait distinguer :


1. Les modules officiels.
# Les modules officiels.
2. Les modules ayant fait l’objet d’une revue ou d’une sélection éditoriale.
# 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.
# Les meilleures ventes sur une période définie.
4. Les nouveautés.
# Les nouveautés.
5. Une découverte aléatoire limitée.
# 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.
Il est proposé de limiter le bloc aléatoire à 24 éléments dans une première expérimentation.
Line 230: Line 260:
Les meilleures ventes et la sélection qualitative doivent rester deux notions distinctes.
Les meilleures ventes et la sélection qualitative doivent rester deux notions distinctes.


### 6.2 Règles de mise en avant
=== 6.2 Règles de mise en avant ===


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


- Limiter la présence d’un même vendeur dans un bloc.
* Limiter la présence d’un même vendeur dans un bloc.
- Réserver une place aux nouveaux entrants.
* Réserver une place aux nouveaux entrants.
- Publier les critères de sélection.
* Publier les critères de sélection.
- Dater et réexaminer les sélections.
* Dater et réexaminer les sélections.
- Identifier séparément toute mise en avant sponsorisée.
* 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 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
=== 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.
La période de 30 jours de visibilité doit commencer à la première publication effective, et non à la demande de validation.
Line 250: Line 280:
Une nouvelle version peut alimenter un espace « mises à jour », sans faire systématiquement réapparaître le produit comme nouveau module.
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
=== 6.4 Améliorer la recherche ===


Les évolutions proposées sont :
Les évolutions proposées sont :


- Des catégories métier et techniques mieux structurées.
* Des catégories métier et techniques mieux structurées.
- Des mots-clés multilingues.
* Des mots-clés multilingues.
- Des filtres par version Dolibarr, langue, prix et statut de maintenance.
* Des filtres par version Dolibarr, langue, prix et statut de maintenance.
- Des filtres par revue réalisée ou compatibilité testée.
* Des filtres par revue réalisée ou compatibilité testée.
- Une recherche par vendeur.
* Une recherche par vendeur.
- Des tris explicites : pertinence, nouveautés, mises à jour et ventes récentes.
* 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é.
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
=== 6.5 Revoir la fiche produit ===


La fiche produit devrait suivre une structure claire :
La fiche produit devrait suivre une structure claire :


1. Besoin auquel répond le module.
# Besoin auquel répond le module.
2. Fonctions incluses.
# Fonctions incluses.
3. Limites et exclusions.
# Limites et exclusions.
4. Captures en situation.
# Captures en situation.
5. Prérequis et compatibilités.
# Prérequis et compatibilités.
6. Installation et documentation.
# Installation et documentation.
7. Support inclus et prestations complémentaires.
# Support inclus et prestations complémentaires.
8. Historique des versions et conditions de mise à jour.
# 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.
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.
Line 280: Line 310:
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 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. Chantier technique : versions et compatibilités ==


### 7.1 Rattacher la compatibilité à chaque version distribuée
=== 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.
La compatibilité ne doit plus être gérée uniquement au niveau global du module. Elle doit être rattachée à chaque version distribuée.
Line 288: Line 318:
Modèle cible :
Modèle cible :


```text
<pre>
Vendeur
Vendeur
└── Produit / module
└── Produit / module
Line 299: Line 329:
         ├── Statut de maintenance
         ├── Statut de maintenance
         └── Contrôles et revues
         └── Contrôles et revues
```
</pre>


Cela permet de conserver une fiche produit unique tout en présentant plusieurs versions techniques ou générations commerciales.
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
=== 7.2 Distinguer compatibilité déclarée et testée ===


Il est proposé d’afficher clairement :
Il est proposé d’afficher clairement :


- La compatibilité déclarée par l’éditeur.
* La compatibilité déclarée par l’éditeur.
- La compatibilité testée par l’éditeur.
* La compatibilité testée par l’éditeur.
- La compatibilité contrôlée par un tiers, avec environnement et date.
* 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.
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
=== 7.3 Séparer les dates ===


Prévoir des champs distincts pour :
Prévoir des champs distincts pour :


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


La simple modification d’une fiche ne doit plus être assimilée à une mise à jour du module.
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
=== 7.4 Gérer la dépréciation ===


Prévoir des états lisibles :
Prévoir des états lisibles :


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


Les versions dépendant d’un service externe devenu inutilisable doivent être explicitement signalées.
Les versions dépendant d’un service externe devenu inutilisable doivent être explicitement signalées.
Line 339: Line 369:
L’accès des anciens acheteurs, la visibilité publique et le retrait de la vente doivent être traités séparément.
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. Forks, duplications et marketplaces externes ==


### 8.1 Distinguer les situations
=== 8.1 Distinguer les situations ===


Il convient de distinguer :
Il convient de distinguer :


- La copie directe de code.
* La copie directe de code.
- La concurrence fonctionnelle entre modules différents.
* La concurrence fonctionnelle entre modules différents.
- Les « auto-forks » publiés périodiquement pour retrouver de la visibilité.
* Les « auto-forks » publiés périodiquement pour retrouver de la visibilité.
- Les déclinaisons linguistiques ou commerciales d’un même produit.
* 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.
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
=== 8.2 Procédure de signalement ===


Une procédure contradictoire est proposée :
Une procédure contradictoire est proposée :


1. Signalement documenté.
# Signalement documenté.
2. Accusé de réception et attribution.
# Accusé de réception et attribution.
3. Conservation des éléments utiles.
# Conservation des éléments utiles.
4. Demande de réponse au vendeur.
# Demande de réponse au vendeur.
5. Analyse technique et, si nécessaire, juridique.
# Analyse technique et, si nécessaire, juridique.
6. Décision motivée.
# Décision motivée.
7. Possibilité de recours.
# 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.
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
=== 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 principale peut regrouper les déclinaisons essentiellement linguistiques, techniques ou commerciales d’un même produit.
Line 372: Line 402:
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é.
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
=== 8.4 Clarifier les liens externes ===


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


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


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


## 9. Avis, support, litiges et remboursements
== 9. Avis, support, litiges et remboursements ==


### 9.1 Avis clients
=== 9.1 Avis clients ===


Les avis clients ne doivent pas être déployés sans cadre clair. Il est proposé de :
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.
# Déployer d’abord les informations objectives.
2. Formaliser le traitement des litiges.
# Formaliser le traitement des litiges.
3. Expérimenter ensuite des avis textuels contextualisés.
# 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.
# Reporter la note globale tant que sa pertinence et sa modération ne sont pas établies.


Les conditions proposées pour un avis sont :
Les conditions proposées pour un avis sont :


- Usage ou achat vérifiable.
* Usage ou achat vérifiable.
- Rattachement à une version du module.
* Rattachement à une version du module.
- Indication de l’environnement Dolibarr.
* Indication de l’environnement Dolibarr.
- Droit de réponse du vendeur.
* Droit de réponse du vendeur.
- Signalement à un modérateur indépendant.
* Signalement à un modérateur indépendant.
- Historique des corrections et réponses.
* 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 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
=== 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 vendeur doit conserver la liberté de choisir son canal de support : forum, tickets, adresse email, téléphone ou autre outil.
Line 412: Line 442:
Le DoliStore doit :
Le DoliStore doit :


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


### 9.3 Dossier de litige
=== 9.3 Dossier de litige ===


Il est proposé de créer un dossier de litige dans l’administration du DoliStore.
Il est proposé de créer un dossier de litige dans l’administration du DoliStore.
Line 423: Line 453:
Le dossier devrait contenir :
Le dossier devrait contenir :


- Commande, module et version.
* Commande, module et version.
- Motif de la demande.
* Motif de la demande.
- Échanges et justificatifs.
* Échanges et justificatifs.
- Notification au vendeur.
* Notification au vendeur.
- Délai de réponse annoncé.
* Délai de réponse annoncé.
- Proposition de résolution.
* Proposition de résolution.
- Décision et trace du remboursement éventuel.
* 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.
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. Données, outils vendeurs et communication ==


### 10.1 Tableau de bord vendeur
=== 10.1 Tableau de bord vendeur ===


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


- Visites agrégées et méthode de comptage.
* Visites agrégées et méthode de comptage.
- Ventes et téléchargements.
* Ventes et téléchargements.
- Évolution par période.
* Évolution par période.
- État des validations.
* État des validations.
- Litiges et remboursements.
* Litiges et remboursements.
- Alertes sur les informations à actualiser.
* 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.
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
=== 10.2 API ===


Les usages doivent être distingués :
Les usages doivent être distingués :


1. API de lecture du catalogue public.
# API de lecture du catalogue public.
2. Accès authentifié aux données propres du vendeur.
# Accès authentifié aux données propres du vendeur.
3. API d’édition des fiches.
# API d’édition des fiches.
4. Dépôt d’archives, ultérieurement.
# 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.
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
=== 10.3 Place du forum ===


La fiche vendeur doit devenir le lieu de présentation commerciale.
La fiche vendeur doit devenir le lieu de présentation commerciale.
Line 469: Line 499:
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.
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
== 11. Arbitrages économiques et associatifs ==


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


- Contrôle renforcé au-delà d’un certain prix.
* Contrôle renforcé au-delà d’un certain prix.
- Frais de revue.
* Frais de revue.
- Exemptions éventuelles pour les partenaires.
* Exemptions éventuelles pour les partenaires.
- Prix minimum.
* Prix minimum.
- Adhésion vendeur obligatoire.
* Adhésion vendeur obligatoire.
- 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 partenaire.


| Sujet | Recommandation |
{| class="wikitable"
|---|---|
! Sujet
| Contrôle lié au prix | Ne pas utiliser le prix comme seul critère ; intégrer complexité, risques et historique |
! Recommandation
| 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 |
| Contrôle lié au prix
| Prix minimum | Étudier les coûts réels ; ne pas le présenter comme un outil qualité |
| Ne pas utiliser le prix comme seul critère ; intégrer complexité, risques et historique
| 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 |
| Frais de revue
| Statut partenaire | Publier critères, renouvellement, suspension et recours |
| Mesurer d’abord le temps et le coût sur un pilote
| Réductions et commissions | Produire une documentation avec exemples validés |
|-
| 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.
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.
Line 496: Line 544:
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.


## 12. Gouvernance et feuille de route
== 12. Gouvernance et feuille de route ==


### 12.1 Répartition des responsabilités
=== 12.1 Répartition des responsabilités ===


| Rôle | Mission |
{| class="wikitable"
|---|---|
! Rôle
| Bureau | Arbitrer politique, budget et règles |
! Mission
| Coordination DoliStore | Organiser le programme et publier l’avancement |
|-
| Équipe technique | Développer, tester et maintenir |
| Bureau
| Référent qualité | Définir la grille et accompagner les validateurs |
| Arbitrer politique, budget et règles
| Équipe UX/contenu | Concevoir les modèles et tester les parcours |
|-
| Conseil juridique | Valider les dispositions sensibles |
| Coordination DoliStore
| Représentants utilisateurs et vendeurs | Participer aux tests et retours |
| 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
=== 12.2 Lots de réalisation ===


| Lot | Contenu | Condition de lancement |
{| class="wikitable"
|---|---|---|
! Lot
| 0 — Cadrage | Inventaire, chiffres fiables, état des travaux, arbitrages | Responsable identifié |
! Contenu
| 1 — Corrections rapides | Nouveautés depuis validation, dates distinctes, motifs d’attente, miniatures | Vérification technique |
! Condition de lancement
| 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 |
| 0 — Cadrage
| 4 — Parcours d’achat | Accueil, recherche, fiches produit, langues | Tests utilisateurs |
| Inventaire, chiffres fiables, état des travaux, arbitrages
| 5 — Versions et litiges | Compatibilités par version, dépréciation, dossiers de litige | Règles et modèle validés |
| Responsable identifié
| 6 — Données et extensions | Dashboard vendeur, API, avis expérimentaux | Gouvernance des données |
|-
| 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.
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
=== 12.3 Migration de l’existant ===


Proposition :
Proposition :


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


## 13. Indicateurs de suivi
== 13. Indicateurs de suivi ==


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


Les prochaines discussions devraient permettre de trancher :
Les prochaines discussions devraient permettre de trancher :


1. La priorité donnée aux fiches vendeurs et aux corrections de visibilité.
# 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.
# 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.
# 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.
# Les critères de mise en avant sur l’accueil.
5. Le modèle de gestion des versions et compatibilités.
# Le modèle de gestion des versions et compatibilités.
6. La procédure de litige et de recours.
# La procédure de litige et de recours.
7. L’expérimentation éventuelle des avis.
# L’expérimentation éventuelle des avis.
8. Les conditions d’accès vendeur et les avantages partenaires.
# Les conditions d’accès vendeur et les avantages partenaires.
9. Les moyens bénévoles et financés.
# Les moyens bénévoles et financés.
10. Le responsable et les critères de réception de chaque premier lot.
# Le responsable et les critères de réception de chaque premier lot.


## 15. Prochaines étapes
== 15. Prochaines étapes ==


1. Valider ou amender les priorités proposées.
# Valider ou amender les priorités proposées.
2. Identifier les responsables de chaque premier lot.
# Identifier les responsables de chaque premier lot.
3. 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.
4. Publier ce document sur le wiki.
# Publier ce document sur le wiki.
5. Recueillir les retours de la communauté.
# Recueillir les retours de la communauté.
6. Établir un cahier des charges pour les premiers lots retenus.
# Établir un cahier des charges pour les premiers lots retenus.
7. Organiser un pilote avant généralisation.
# Organiser un pilote avant généralisation.
8. Présenter les résultats lors du prochain DevCamp.
# 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.
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.
Retrieved from "https://wiki.dolibarr.org/index.php/Special:MobileDiff/68083"

Navigation menu