Sommaire
En bref
- 48 méthodes, chacune avec sa fiche technique : données requises, formule, hypothèses, limites et volume minimal de données.
- 480 tests automatisés, exécutés avant chaque compilation, sous Linux et sous Windows. Une version n'est pas publiée si un seul test échoue.
- 48 réponses de référence — une par méthode — calculées de manière indépendante sur un entrepôt d'exemple fictif.
- Test à l'aveugle sur 137 jeux de données publics de 20 pays (214 fichiers) : 0 résultat erroné, 0 plantage, 18 chiffres sur 18 conformes à un recalcul indépendant.
- Aucune IA dans les calculs. Chaque résultat provient d'une formule fixe et documentée. Les mêmes données et les mêmes paramètres donnent toujours le même résultat.
D'où viennent les formules
Les méthodes appliquent les définitions standard, largement utilisées dans la pratique de l'entrepôt et de la supply chain — celles que l'on enseigne dans les formations en supply chain et que l'on retrouve dans les rapports des WMS et des ERP. Exemples :
- Analyse ABC — le principe de Pareto : articles triés selon leur part de la valeur, classes déterminées par la part cumulée (80 % / 15 % / 5 % par défaut, modifiables).
- Analyse XYZ — coefficient de variation de la demande mensuelle,
CV = σ / μ. - Point de commande —
ROP = d·L + SS: demande pendant le délai d'approvisionnement plus stock de sécurité. - OTIF — part des commandes livrées dans les délais et complètes ; taux de service — part de la quantité commandée qui a été expédiée.
- Cartes de contrôle — cartes p de Shewhart, avec des limites de contrôle à trois écarts-types.
- Précision des prévisions — MAE, MAPE, WAPE et biais par rapport à la demande réelle.
La formule exacte, les hypothèses et les limites de chaque méthode figurent dans son onglet Méthodologie du programme et sur la feuille de méthodologie de chaque rapport. LOQMETRA ne se prévaut d'aucune certification par un organisme de normalisation ; il rend chaque calcul visible pour que vous puissiez le vérifier.
Des règles qui protègent le résultat
- Une méthode ne s'exécute que si vos données le permettent réellement. S'il manque une table ou un champ, elle indique lequel — elle ne comble jamais les lacunes avec des valeurs inventées.
- Les noms de colonnes génériques (« Quantité », « Date », « Valeur ») ne sont jamais interprétés en silence : c'est vous qui confirmez leur signification.
- Aucune ligne n'est supprimée ni modifiée sans votre clic ; chaque exclusion est indiquée dans le rapport.
- Les mois manquants ne sont pas considérés comme une demande nulle, sauf si les données le confirment ; un historique trop court est signalé comme une limite.
- Le rapport consigne la version du programme, les versions des méthodes, les paramètres, la correspondance des champs et les exclusions, afin que le résultat puisse être reproduit.
Réponses de référence sur un entrepôt d'exemple
Un générateur distinct crée un entrepôt fictif avec deux ans d'historique répartis en 23 tables : articles, fournisseurs, commandes clients, expéditions, réceptions, contrôles qualité, stock, inventaires tournants, opérations, équipes, coûts, retours et plus encore. Le générateur n'utilise aucun code du programme.
Un second script, indépendant, calcule directement à partir de ces données la réponse attendue pour chacune des 48 méthodes. Les tests automatisés comparent ensuite les résultats du programme à ces réponses de référence — chiffre par chiffre, et table par table lorsqu'une méthode renvoie une table.
Test à l'aveugle sur des données publiques réelles
Des données de test bien propres ne suffisent pas ; le programme est donc aussi exécuté sur des données qu'il n'a jamais vues : 137 jeux de données publics de 20 pays — 214 fichiers provenant de Kaggle, des portails de données ouvertes du Royaume-Uni, du Canada, de l'Australie, de l'Irlande et du Québec, du portail de données de l'UE (France, Allemagne, Autriche, Italie, Grèce, Pologne, Slovaquie, Espagne, Pays-Bas), de Zenodo, de Harvard Dataverse, de la base de données d'exemple Northwind et d'exemples Microsoft.
Avant chaque exécution, on consigne par écrit les méthodes qui peuvent honnêtement être calculées à partir de chaque jeu de données. Résultats de la dernière série (octobre 2026) :
- 133 sur 150 des méthodes attendues ont abouti (89 %) lorsque l'utilisateur suit les suggestions du programme.
- 0 résultat erroné sur 87 tables qui ne sont pas des données d'entrepôt — le programme a refusé à juste titre de calculer.
- 0 plantage sur l'ensemble des 214 fichiers.
- 18 sur 18 des chiffres vérifiés (classes ABC et XYZ, historique de la demande, délai et taux de ponctualité des fournisseurs, coût de transport, lignes de commande) correspondent à un recalcul indépendant effectué à partir des fichiers sources.
À chaque compilation
- La suite de tests complète s'exécute sous Windows sur les serveurs de GitHub ; le programme n'est compilé que si tous les tests réussissent.
- Le ZIP publié est vérifié : le fichier téléchargé depuis le lien public doit être identique, octet par octet, à celui issu de la compilation (somme de contrôle SHA-256, publiée à côté du téléchargement).
- Avant la publication, le programme est également lancé sur un véritable ordinateur Windows, et l'analyse complète de l'entrepôt d'exemple est comparée aux chiffres de référence.
Ce que les tests ne peuvent pas promettre
Les tests montrent que les formules sont correctement mises en œuvre et que le programme se comporte honnêtement sur un large éventail de fichiers. Ils ne peuvent pas garantir que chaque export de chaque système sera lu comme vous l'entendez. C'est pourquoi vous confirmez la signification des colonnes, pourquoi les limites sont toujours indiquées — et pourquoi vous devriez vérifier les résultats importants avant d'agir sur leur fondement (voir Conditions d'utilisation).
Un chiffre vous semble faux ? Écrivez à support@loqmetra.com — chaque erreur confirmée devient un nouveau test.