Comment lire le score de santé de votre propriété dans Seringueiro

Quand une propriété commence à perdre en régularité, le vrai problème n’est pas toujours le rendement du jour. Souvent, c’est l’accumulation silencieuse de petits trous opérationnels : module sans saigneur, limite de propriété absente, activité qui n’a pas été enregistrée, livraison qui n’est plus reliée proprement au terrain.

Dans Seringueiro, le score de santé de la propriété sert justement à lire cela sans recalcul local ni interprétation improvisée. Le backend publie un payload canonique dans stats.propertyHealth, et l’app ne fait que le lire pour montrer le score, le niveau d’attention et la prochaine action prioritaire. Voici comment interpréter cet écran et quoi faire ensuite.

1. Commencez par lire le score global, pas seulement la couleur

Le widget affiche un score sur 100 avec un niveau global : excellent, good, attention ou critical. Ce score n’est pas un ressenti de l’équipe ni une note décorative : il est recalculé à partir des dimensions réellement applicables à la propriété.

Dans la logique actuelle, les dimensions possibles sont : teamCoverage, propertyBoundary, modulePolygonCoverage, traceability, tappingToday, activityFrequency7d et productivityHarvest. Le score final est la moyenne des ratios applicables, multipliée par 100 et arrondie.

Autrement dit, une propriété n’est pas pénalisée pour une dimension qui ne s’applique pas encore à elle, mais elle l’est si une dimension applicable reste mal couverte.

2. Regardez ensuite les deux pills qui résument l’exécution terrain

Sous le score, l’app met en avant deux signaux compacts :

• la couverture d’équipe, avec le rapport entre modules actifs et modules qui ont effectivement un saigneur assigné ;
• l’exécution du jour, avec le rapport entre modules qui ont un saigneur et modules effectivement sangrés aujourd’hui.

Ces deux pills sont utiles parce qu’elles montrent vite si le problème est d’abord structurel ou quotidien. Si des modules restent sans saigneur, la propriété manque de couverture d’équipe. Si les saigneurs existent mais que les modules ne sont pas sangrés aujourd’hui, le blocage est déjà dans l’exécution.

3. Utilisez la prochaine action comme priorité, pas comme simple suggestion

Quand une correction prioritaire existe, le score ne se contente pas d’avertir : il expose une nextAction avec un code et, quand nécessaire, le contexte d’un module spécifique.

Les codes supportés aujourd’hui sont :

• property_boundary_missing
• assign_tapper
• module_polygon_missing
• start_tapping_today
• review_activity_calendar
• register_delivery
• review_traceability

Dans l’app, certains de ces codes ouvrent directement l’écran utile : édition de propriété, détail du module, éditeur de polygone ou zone de production. Cela compte parce que le score a été conçu pour orienter une correction concrète, pas pour créer un diagnostic passif.

4. Descendez dans la checklist pour voir ce qui demande vraiment de l’attention

Dans l’onglet de production, Seringueiro affiche une checklist simplifiée. Elle transforme le score en éléments lisibles, par exemple :

• limite de propriété absente,
• module sans saigneur,
• module sans polygone,
• sangria du jour non réalisée,
• fréquence d’activité à revoir.

Quand le contexte existe, la checklist peut encore enrichir l’alerte avec le module concerné, le nom du seringueiro ou un avatar. Le score ne change pas localement pour cela : l’app enrichit seulement la lecture, ce qui garde le diagnostic cohérent entre backend, app et web.

5. Comprenez ce que le score veut vraiment dire sur votre propriété

Le score de santé ne mesure pas seulement la beauté des données. Il vérifie si la propriété reste pilotable avec un minimum de continuité opérationnelle.

Par exemple :

• sans limite de propriété, certaines dimensions de traçabilité et de couverture cartographique ne peuvent pas être consolidées proprement ;
• sans polygone de module, la lecture par zone productive perd en précision ;
• sans saigneur assigné, une partie du suivi quotidien devient structurellement faible ;
• sans activité récente ni sangria du jour, le score révèle une rupture de routine avant même qu’elle apparaisse comme perte économique.

Ce point est important pour un propriétaire, un admin ou un responsable terrain : un score faible n’annonce pas seulement “un problème de données”, il signale souvent une rupture d’exécution qui va finir par toucher la trace, la supervision ou la productivité.

6. Où lire ce score dans le flux produit

Dans la structure actuelle, la santé de la propriété apparaît dans le flux de production, avant ou junto des blocs de productivité. Cela évite de séparer artificiellement la santé de la propriété du travail qui doit la corriger.

Le backend persiste le payload canonique dans properties/{propertyId}.stats.propertyHealth, le widget le lit, et le client ne recalcule pas le score. Le résultat attendu est simple : que l’app et le site affichent le même état de santé pour la même propriété.

Erreurs fréquentes en lisant ce score

• croire que 100/100 dépend seulement du volume de livraisons,
• ignorer la prochaine action alors qu’elle pointe le vrai blocage prioritaire,
• confondre une propriété empty avec une propriété saine,
• penser que l’app recalcule localement ce que le backend a déjà consolidé,
• regarder la couleur sans lire quelles dimensions sont en train de tirer le score vers le bas.

Ce qu’il faut retenir

Pour bien lire la santé d’une propriété dans Seringueiro, il faut suivre cet ordre : score global, pills de couverture et d’exécution, prochaine action, checklist concrète puis correction dans le bon écran. C’est cette séquence qui transforme un indicateur en pilotage réel.

Une propriété saine n’est pas celle qui affiche le plus beau score, c’est celle dont chaque manque devient une action claire avant de coûter une journée de terrain.