Méthodologie Trade Health
Version 1.1·En vigueur 1 juillet 2026
BM-THM-v1.1
English version governs. The legally binding version of this document is the English version 1.1 (content fingerprint
bb88bfe44dccad3a8c354a9ddc2468989ba9b0b87e59e53c2649bbf76814f4ea). This translation is provided for convenience only.The binding English version is available at this permalink.
Cette page décrit la manière dont Berry Marketplace calcule le score Trade Health affiché sur chaque profil de Société, chaque carte d'annonce et chaque écran d'offre de la plateforme. Elle documente la manière dont Berry interprète la Section 7 (Système de réputation) des Conditions générales de la plateforme depuis l'entrée en vigueur de ces conditions, et est publiée ici à des fins de transparence. Elle ne constitue pas en elle-même un contrat et ne nécessite aucune acceptation.
Ce qu'est le score Trade Health
Le score Trade Health est un nombre compris entre 0 et 100, calculé par Berry à partir de l'historique de négoce vérifié d'une Société sur la Plateforme. Il est affiché à côté (et jamais mélangé) des avis rédigés par les utilisateurs, afin que les contreparties puissent lire d'un coup d'œil deux signaux distincts :
- Étoiles — ce que d'autres Sociétés ont dit d'une Société, avec leurs propres mots.
- Trade Health — ce que le propre historique de négoce d'une Société dit d'elle, calculé par Berry à partir d'événements objectifs.
Le score d'une Société est mis à jour automatiquement chaque fois qu'un événement de négoce alimentant le score se produit (un contrat se finalise, un litige se résout, une facture est payée, une livraison est enregistrée). Un recalcul de sécurité quotidien s'exécute à 06h30 UTC afin de rattraper les éventuels événements que les déclencheurs en temps réel auraient manqués.
Le score, la bande dans laquelle il se situe et une ventilation par composant sont visibles sur chaque profil de Société. Les Sociétés peuvent consulter les événements individuels qui alimentent leur propre score depuis l'onglet Mon entreprise → Activité Trade Health.
Bandes
| Score | Bande |
|---|---|
| 90–100 | Excellent |
| 75–89 | Bon |
| 60–74 | Correct |
| Inférieur à 60 | Nécessite attention |
| Moins de 3 contrats finalisés | Historique de négoce insuffisant (aucun score publié) |
Une Société comptant moins de 3 contrats finalisés sur la Plateforme affiche « En construction (X sur 3) » au lieu d'un score. Cela évite de pénaliser les nouvelles Sociétés pour cause de données limitées. Une fois le seuil atteint, le score apparaît.
Composants et pondérations
Le score est la moyenne pondérée de quatre composants. Les pondérations totalisent 1,00.
| Composant | Pondération | Ce qu'il mesure |
|---|---|---|
| Taux de litiges | 35 % | La fraction des contrats finalisés qui se sont terminés proprement par rapport à ceux ayant impliqué un problème de qualité ou un litige, pondérée par la gravité du résultat. |
| Livraison à temps | 25 % | À quel point les livraisons d'une Société arrivent dans les délais (signal côté vendeur). |
| Promptitude de paiement des commissions | 20 % | Si une Société paie les factures de commission par transaction de Berry à la date d'échéance ou avant (signal côté acheteur). |
| Taux de réponse aux litiges | 20 % | Si une Société s'engage dans les litiges déposés contre elle dans la fenêtre de réponse du litige. |
Chaque composant est calculé indépendamment sous la forme d'une valeur comprise entre 0,0 et 1,0, puis multiplié par sa pondération. Les valeurs des composants sont additionnées et divisées par la pondération totale des composants ayant au moins un événement pour la Société. Le résultat est multiplié par 100 pour produire le score affiché.
Si une Société n'a aucun événement pour un composant donné (par exemple, une Société qui n'a jamais fait que vendre n'a pas d'historique de paiement de commissions), ce composant est exclu à la fois du numérateur et du dénominateur — il n'aide ni ne nuit au score.
Comment le temps affecte le score
Trade Health utilise un modèle de dilution, pas un modèle de décroissance. C'est une distinction importante.
Un modèle de décroissance dirait : « Les anciens événements comptent moins avec le temps. » Berry ne fait pas cela. Les anciens événements comptent pleinement, indéfiniment.
Un modèle de dilution dit : « Chaque nouveau contrat finalisé s'ajoute à votre historique, et votre ratio global s'améliore automatiquement à mesure que votre bon comportement s'accumule. » C'est ce que fait Berry.
L'effet pratique est qu'une Société ayant un ancien incident et de nombreux contrats propres ultérieurs voit son score remonter naturellement — l'incident n'est pas effacé, mais son poids arithmétique en tant que fraction de l'historique total de la Société diminue à chaque contrat propre ajouté. Vous pouvez vous racheter par le négoce — chaque contrat propre dilue l'impact de tout incident antérieur, sans jamais prétendre que cet incident n'a pas eu lieu.
Nous n'« oublions » pas les anciens événements. Un litige vieux de 3 ans compte au même poids arithmétique qu'un litige vieux d'un mois. Ce qui change, c'est la part que cet événement représente dans l'historique total de la Société.
Une version future de cette méthodologie pourra introduire une surcouche de récence symétrique (les événements anciens pondérés légèrement moins que les événements récents) si les données montrent ultérieurement qu'elle améliore le signal pour les Sociétés inactives. Si elle est introduite, ce sera une surcouche symétrique uniquement — jamais une courbe qui amplifie démesurément les événements récents. Tout changement de ce type sera publié en tant que nouvelle version de cette page (v1.1, v2.0, etc.) au titre de la Section 7.3 des Conditions générales de la plateforme, qui réserve à Berry son pouvoir discrétionnaire sur l'évolution de la méthodologie.
Une version future pourra également introduire un lissage bayésien — une technique statistique qui réduit la volatilité du score pour les Sociétés proches du seuil des 3 contrats en attirant doucement leurs ratios vers la moyenne de la plateforme. La v1.0 utilise une simple coupure (aucun score publié en dessous de 3 contrats) ; la v2.0 adoucira probablement ce mécanisme par un lissage au-dessus du seuil. Nous divulguons son absence en v1.0 afin que son ajout éventuel ne soit pas une surprise.
Détails des composants
Taux de litiges (pondération 35 %)
Source : tout contrat qui atteint le statut COMPLETED. Chaque contrat
finalisé émet une ligne par partie concernée (l'acheteur et le
vendeur), et la valeur de la ligne est déterminée par le pire résultat
qualité de ce contrat. Les transactions propres comptent pleinement ;
les transactions avec des problèmes de qualité ou des litiges comptent
proportionnellement moins, selon la manière dont le problème a été
résolu et la partie en faute.
| Résultat sur le contrat | Valeur pour la partie en faute | Valeur pour la contrepartie |
|---|---|---|
| Transaction propre — aucun problème de qualité, aucun litige | 1,00 | 1,00 |
| Problème de qualité résolu bilatéralement (aucun litige formel ouvert) | 0,85 | 0,85 |
| Litige → réclamation retirée (typiquement résolu hors plateforme) | 1,00 (défendeur) | 0,95 (demandeur) |
| Litige → aucune action convenue (réclamation rejetée d'un commun accord) | 0,95 (défendeur) | 0,92 (demandeur) |
| Litige → faute reconnue, restitution intégrale (remboursement ou remplacement) | 0,50 | 1,00 |
| Litige → remboursement partiel convenu avec attribution de faute | 0,50 | 0,95 |
| Litige → résolu sans partie en faute (compromis) | 0,70 | 0,70 |
| Litige → référé en externe à arbitrage | 0,60 | 0,60 |
| Litige → réclamation expirée (aucun engagement, prescrite) | 0,10 (défendeur) | 0,50 (demandeur) |
Quelques notes sur la lecture de ce tableau :
- Un litige résolu équitablement compte tout de même pour quelque chose. Un vendeur qui a livré un remplacement après une plainte légitime obtient 0,50 sur cette ligne, et non 1,0. Le remplacement était la bonne réponse, mais un vrai problème s'est produit, et le score le reflète. Le remplacement, le remboursement intégral et l'avoir sont traités de manière équivalente — l'attribution de faute est la même quelle que soit la forme que prend la restitution.
- Les réclamations retirées sont lues avec bienveillance. Lorsqu'une réclamation est retirée, la raison la plus fréquente est une résolution amiable hors plateforme. Le défendeur obtient un 1,00 propre ; le demandeur obtient 0,95.
- Ignorer une plainte est le pire résultat habituel. Un défendeur qui laisse une réclamation expirer sans s'engager obtient 0,10. Le demandeur qui a également abandonné obtient 0,50.
- L'arbitrage externe est maintenu à 0,60 pour les deux jusqu'à ce que le résultat arbitral soit enregistré sur la Plateforme, moment auquel le score est recalculé à partir de ce résultat.
Livraison à temps (pondération 25 %)
Source : chaque livraison enregistrée (ligne contract_deliveries ayant
été livrée). Les jours de retard sont calculés comme date de livraison effective − date prévue, plafonnés à zéro (les livraisons en avance
obtiennent le même score que celles à temps).
| Jours de retard | Valeur |
|---|---|
| 0 (à temps ou avant) | 1,00 |
| 1 à 3 jours | 0,70 |
| 4 à 7 jours | 0,40 |
| 8 à 14 jours | 0,20 |
| 15 jours ou plus | 0,10 |
Ce signal est attribuable au vendeur : seul le score du vendeur est affecté.
Promptitude de paiement des commissions (pondération 20 %)
Source : chaque facture de commission (les frais par transaction de
Berry facturés à l'acheteur) avec le statut PAID. Les jours de
retard sont calculés comme date de paiement − date d'échéance,
plafonnés à zéro.
| Jours de retard | Valeur |
|---|---|
| 0 (payé à l'échéance ou avant) | 1,00 |
| 1 à 3 jours | 0,80 |
| 4 à 7 jours | 0,40 |
| 8 à 14 jours | 0,20 |
| 15 jours ou plus | 0,10 |
Légèrement plus indulgent que la livraison à temps pour la seule plage de 1 à 3 jours — le règlement SEPA prend légitimement 1 à 2 jours. Les courbes convergent à partir du 4e jour, où les explications par délai bancaire ne s'appliquent plus.
Ce signal est attribuable à l'acheteur : seul le score de l'acheteur est affecté.
Les factures d'abonnement ne font pas partie de Trade Health. L'abonnement plateforme mensuel ou annuel de Berry est une relation commerciale entre chaque Société et Berry, distincte de la manière dont cette Société est présentée à ses contreparties. Intégrer le recouvrement d'abonnement dans une métrique de réputation orientée contrepartie reviendrait à mêler deux relations sans rapport, et nous ne le faisons pas.
Les paiements de contrat acheteur-vendeur ne font pas non plus partie de Trade Health. Ces paiements ont lieu hors plateforme (typiquement par virement bancaire direct) et Berry n'a pas d'enregistrements faisant autorité sur le moment de leur règlement. Si le rôle de Berry dans la médiation des paiements de contrat s'étend à l'avenir dans d'autres gammes de produits, ce composant pourra être ajouté.
Taux de réponse aux litiges (pondération 20 %)
Source : chaque litige déposé contre la Société (lorsque cette Société est le défendeur).
| Comportement de réponse | Valeur |
|---|---|
| Réponse dans la fenêtre de réponse du litige | 1,00 |
| Réponse après la fenêtre mais avant la résolution | 0,50 |
| Aucune réponse du tout | 0,00 |
La fenêtre de réponse est lue par litige depuis le champ
respondentDeadline du litige — elle n'est pas une durée fixe de
7 jours. Les litiges agricoles B2B nécessitent légitimement des
fenêtres de réponse variables pour l'analyse d'échantillons, les
analyses de laboratoire, les périodes de fêtes et les situations de
force majeure, et le système s'adapte à cela. La question pertinente
n'est pas « avez-vous répondu en 7 jours ? » mais « avez-vous répondu
dans la fenêtre qui s'appliquait à ce litige précis ? »
Ajustements — correction des entrées par Berry Operations
La Section 7.3 des Conditions générales de la plateforme prévoit que les Sociétés peuvent demander un examen des inexactitudes factuelles affectant leur score de réputation. Berry exerce ce pouvoir discrétionnaire à travers un unique mécanisme : l'exclusion d'événements individuels de l'ensemble d'entrée du score.
Nous ne saisissons jamais un nombre différent dans le score d'une Société. Le score est toujours le résultat déterministe d'une formule appliquée à un ensemble d'événements. Ce que Berry Operations peut faire — et uniquement Berry Operations, via un flux audité — est de marquer un événement précis comme ne comptant pas, avec une raison nommée et un enregistrement d'audit permanent.
L'ensemble fermé des raisons pour lesquelles Berry Operations peut exclure un événement du score d'une Société :
| Raison | Quand elle s'applique |
|---|---|
| Bug de la plateforme ou erreur d'enregistrement | Les propres systèmes de Berry ont causé le problème, ou le système a mal enregistré un événement (une livraison était à temps mais consignée comme tardive, une intégration a mal compté un paiement). Les fautes côté données et côté plateforme relèvent toutes deux de cette unique raison — la note libre de la ligne d'audit lève l'ambiguïté. |
| Fraude de contrepartie confirmée | La contrepartie agissait de mauvaise foi et l'événement reflétait cela, pas le comportement de cette Société. |
| Force majeure | Une grève portuaire, un blocage douanier, un événement météorologique ou une circonstance comparable a affecté la transaction sans faute de l'une ou l'autre des parties. |
| Accord parallèle hors plateforme | Les parties ont résolu la transaction en dehors de la Plateforme (typiquement par contact direct) et l'enregistrement sur plateforme ne reflète plus ce qui s'est réellement passé. L'événement sur plateforme est trompeur et ne doit pas alimenter le score. |
| Autre (documenté) | Tout le reste ; l'opérateur doit justifier l'exclusion par écrit dans l'enregistrement d'audit. La note libre est obligatoire. |
Catégories internes uniquement. Une raison non publique séparée —
données de test ou de démonstration — existe dans la base de données
pour nettoyer les fixtures de pré-production qui fuient en production.
Elle ne reflète jamais un comportement réel d'une Société, n'est pas
appliquée aux transactions actives en fonctionnement normal, et est
documentée ici par souci d'exhaustivité plutôt qu'en tant que raison
qu'une Société rencontrerait jamais sur sa propre ligne d'audit. Si
vous voyez une exclusion TEST_OR_DEMO sur une transaction réelle,
contactez le support — il s'agit presque certainement d'une erreur
d'Operations dont nous voulons être informés.
Chaque exclusion est consignée dans une table d'audit en ajout seul qui ne peut être modifiée ni supprimée, même par Berry Operations. La Société dont le score est affecté peut consulter sa propre liste d'exclusions dans l'onglet Mon entreprise → Activité Trade Health, les noms des opérateurs étant masqués en « équipe Berry Operations » par souci de confidentialité des opérateurs. La Société peut demander l'examen d'une exclusion (ou plaider en faveur de son application) via le ticket CRM lié.
Les événements exclus sont silencieusement absents du panneau de ventilation du profil public (une Société comptant un litige exclu et 19 contrats propres affiche un taux de litiges de 5 %, et non « 5 % avec une exclusion »). La piste d'audit réside là où vivent les audits — dans le CRM, et dans le propre onglet Activité Trade Health de la Société affectée. Les profils publics affichent le score nettoyé et défendable.
Les violations d'intégrité — fraude confirmée, suspension de compte suivie d'un rétablissement, violations à motif récurrent — sont traitées différemment des signaux courants. Elles comptent à pleine pondération indéfiniment et ne sont pas soumises au mécanisme de dilution décrit ci-dessus. La v1.0 n'a aucun événement d'intégrité implémenté pour l'instant, mais le cadre est divulgué ici afin qu'une Société en rencontrant un à l'avenir ne perçoive pas cela comme un changement rétroactif.
Droit à un examen factuel
Une Société qui estime qu'un événement précis est enregistré de manière inexacte et ne devrait pas compter dans son score Trade Health peut demander un examen via le canal de support lié depuis son onglet Mon entreprise → Activité Trade Health. Berry Operations examine la demande au regard des cinq raisons ci-dessus, applique l'exclusion ou rejette la demande, et consigne la décision dans le journal d'audit. Berry n'est pas tenu de modifier des scores résultant de transactions vérifiées ou de litiges documentés (conformément à la Section 7.3, deuxième phrase, des Conditions générales de la plateforme).
Portée et avertissement
Les scores de réputation sont des indicateurs à titre informatif uniquement et ne constituent pas des jugements juridiques. Ils sont visibles par les autres Utilisateurs de la Plateforme conformément à la Section 7.2(a) des Conditions générales de la plateforme. Berry se réserve un pouvoir discrétionnaire sur la méthodologie de calcul, laquelle peut évoluer dans le temps, conformément à la Section 7.3 des Conditions générales de la plateforme.
Trade Health est calculé uniquement à partir d'événements survenus sur la Plateforme Berry. L'historique de négoce, les références, les certifications ou la réputation qu'une Société peut avoir en dehors de la Plateforme ne sont pas inclus.
Le score Trade Health n'affecte actuellement pas le classement de recherche ni les résultats de mise en correspondance. Si cela change dans une version future de la Plateforme, cette page sera mise à jour et le changement divulgué.
Versions précédentes
La version 1.1 (1er juillet 2026) a migré cette page vers le rendu HTML de la plateforme, sans modification de la méthodologie. La version 1.0 (20 novembre 2025) était la première version publiée de cette page.