Un score a l’air d’un calcul. En réalité, c’est une suite de décisions métier déguisées en formule. Chez LEVANNA, nous l’avons vérifié sur un outil d’aide à la décision construit pour un client : il note des territoires sur plusieurs dizaines d’indicateurs pour aider à choisir où s’installer. En auditant notre propre première version, nous avons découvert que 63 % de sa note venait d’une valeur par défaut, et non des données.
Cet article reprend les sept problèmes que nous avons rencontrés en construisant ce modèle. Ils ne sont pas propres à la géographie : on les retrouve dans un scoring de prospects, une notation de fournisseurs, un tableau de bord RSE ou la sortie d’un modèle d’IA. La méthode complète, avec les formules et les références, est détaillée dans notre guide Agréger sans trahir.
1. Que se passe-t-il quand une donnée manque dans un score ?
Elle devient toujours quelque chose : un zéro, une valeur par défaut ou une ligne qui disparaît. Aucun de ces choix n’est neutre.
Dans la première version que nous avions livrée, chaque indicateur non renseigné recevait silencieusement la note de 50 sur 100. Le choix paraissait raisonnable : une note neutre plutôt qu’un trou. Mais l’axe le plus lourd du modèle n’était renseigné que pour 6 % des lieux. Résultat : la note avait l’air d’un calcul, mais elle était aux deux tiers une constante, et tous les lieux mal documentés se ressemblaient. Nous l’avons vu en mesurant, pour chaque note, la part réellement issue de données.
Ce que nous avons décidé : un indicateur absent est déclaré manquant, il sort du calcul, et aucune note n’est affichée sans sa couverture, c’est-à-dire la part de la note réellement appuyée sur des données. C’est le premier point que nous regardons lors d’un audit de la logique de calcul d’un logiciel.
2. Pourquoi une moyenne pondérée peut-elle donner un classement absurde ?
Parce qu’elle suppose que tous les critères se compensent : un point gagné ici rachète exactement un point perdu là.
Sur l’outil, un lieu très confortable mais sans ressource en eau fiable passait devant un lieu correct sur tous les plans. Le confort « achetait » l’eau. Nous l’avons résumé d’une phrase : on ne boit pas du soleil.
Ce que nous avons décidé : choisir l’opérateur critère par critère. Une moyenne arithmétique là où les critères sont vraiment interchangeables (plusieurs sources d’énergie pour un même besoin), une moyenne géométrique là où ils ne le sont qu’en partie, et le minimum pour la sécurité physique, qu’aucune qualité ne compense. Ce choix est une décision métier : il se prend en cadrant les règles avant de coder, pas au moment d’écrire la requête SQL.
3. Comment empêcher un critère éliminatoire de disparaître dans la moyenne ?
En l’affichant à côté de la note, jamais dedans. Aucun opérateur ne dit ce qui cloche ; seul un seuil le dit.
L’outil pose des planchers sur les thématiques critiques : sous le plancher, la note reste calculée, mais une alerte s’affiche. Un lieu noté 63 avec une alerte sur l’eau n’est pas « un lieu à 63 », c’est un lieu à instruire. Nous avons aussi appris l’inverse : un seuil ne vaut que s’il est rare. Un plancher qui se déclenche partout ne signale plus rien, et deux thématiques n’en ont délibérément aucun.
4. Null et zéro, est-ce la même chose ?
Non. Zéro est une information (aucun site pollué dans le rayon). Null est une absence d’information. Et « on ne sait pas » recouvre lui-même plusieurs situations.
Nous avons fini par distinguer six états pour chaque donnée : zéro vrai, inconnu déclaré (on a cherché, la donnée manque, avec son motif), absent (la question n’a jamais été posée), sans objet, périmé (la source a été abrogée) et contradictoire (deux sources de même rang divergent). Ces états n’appellent pas le même travail : confondre « jamais renseigné » et « source abrogée », c’est aller chercher ce qu’on possède déjà.
C’est un sujet de modélisation de base de données, pas de statistiques. En SQL comme dans un CRM, un NULL ne dit pas pourquoi il est là, et une jointure qui ne trouve rien produit le même NULL qu’un manque constaté. Il faut donc porter le statut dans une colonne à part.
5. Faut-il stocker un score calculé en base ?
Dans notre cas, non. Aucune note globale n’est stockée : elle se recalcule à l’affichage, avec sa couverture et ses alertes.
La raison est simple : un nombre stocké finit toujours par être trié, puis exporté seul, puis pris pour la vérité, sans le contexte qui permettait de le lire. Même logique pour la restitution : le radar qui résume un lieu n’affiche jamais son aire, parce que l’aire d’un radar dépend de l’ordre des branches. Elle est donc arbitraire. Le radar sert à décider où regarder, pas à décider.
6. Peut-on fusionner des données de niveaux différents ?
Rarement. Certaines informations n’existent qu’à une échelle : le réseau d’eau est communal, la pente est locale. Une commune fragile dont un hameau est très bien placé n’est pas « moyenne », c’est un cas à instruire.
L’outil affiche donc les deux notes côte à côte, sans jamais les fusionner. Et quand plusieurs documents répondent à la même question à des échelles différentes (un plan intercommunal, un plan communal abrogé, une étude à la parcelle), il ne les moyenne pas : il retient le document en vigueur le plus précis. La même question se pose dans un système d’information entre un groupe et ses filiales, ou entre un client et ses sites ; c’est souvent elle qui déclenche une refonte du système d’information métier.
7. Où ranger les règles de calcul ?
Hors du code. Tous les barèmes de l’outil (comment une pente, un débit ou une classe de risque devient une note) sont rangés dans un fichier de configuration versionné, daté et relisible par le métier.
Certains barèmes ne sont pas croissants : un couvert forestier rafraîchit jusqu’à un certain point, puis enferme et augmente le risque d’incendie. Ce genre de nuance ne se discute que si la règle est lisible par ceux qui la connaissent. Enfouie dans une fonction, elle n’est jamais remise en question.
Ce qu’il faut retenir
- Un score sans sa couverture ne veut rien dire.
- Le choix de la moyenne est une décision métier : il dit combien un bon critère a le droit d’en racheter un mauvais.
- Ce qui est grave et rare doit traverser l’agrégation, par un seuil affiché à part.
- Null n’est pas zéro, et « on ne sait pas » a plusieurs sens.
- Un chiffre stocké devient la vérité ; recalculez-le avec son contexte.
Ces sept points ne sont pas des raffinements mathématiques. Ce sont des questions que personne ne pose quand on demande « une note sur 100 », et qui décident pourtant de la fiabilité de l’outil. C’est précisément le rôle d’un CTO externalisé hands-on de les poser avant que le code ne les tranche à votre place.
D’autres projets où cette question s’est posée : l’évaluation d’éco-quartiers avec Écologie Urbaine & Citoyenne et le Passeport Efficacité Énergétique.
Questions fréquentes
Comment traiter les données manquantes dans un score multicritère ?
Déclarez-les manquantes, retirez-les du calcul et publiez toujours la couverture avec la note. Remplacer un manque par une valeur par défaut revient à inventer une donnée ; le remplacer par zéro revient à le traiter comme la pire note.
Moyenne arithmétique ou géométrique pour un score ?
L’arithmétique si les critères sont interchangeables, la géométrique s’ils ne se compensent qu’en partie : un critère faible y pèse beaucoup plus lourd. Pour un critère éliminatoire, aucune moyenne ne convient ; il faut un seuil affiché à part ou le minimum.
Faut-il stocker un score en base de données ?
Si le score dépend de règles qui évoluent ou de données incomplètes, mieux vaut le recalculer à l’affichage avec sa couverture et ses alertes. Un score stocké circule seul et finit par être lu sans son contexte.
Votre logiciel calcule une note, un classement ou un indicateur et vous n’êtes pas sûr de ce qu’il dit vraiment ? Parlons-en.
