Aller au contenu
AstroWay/api v2.158.7 · fr
tous les systèmes sont opérationnels

Précision des calculs

L’API AstroWay utilise Swiss Ephemeris (le code C officiel d’Astrodienst, les créateurs d’astro.com) - le même moteur que les astrologues professionnels utilisent depuis plus de 30 ans dans Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mois) et Janus. Nous l’avons compilé en WebAssembly et exposé comme une couche d’API REST, sans majoration intermédiaire. Chacun des endpoints de calcul de base est couvert par des tests de régression snapshot ; la précision du moteur est vérifiée par triangulation avec trois sources indépendantes + contre le NASA 5-Millennium Eclipse Catalog :

  • Positions planétaires : médiane 0.0013", maximum 0.561" vs swetest CGI Astrodienst officiel (mesuré le 29/07/2026 sur 130 mesures). Répartition par corps ci-dessous
  • Cuspides des maisons Placidus : 0.000" correspondance exacte
  • Éclipses : < 1 minute vs NASA Eclipse Catalog
  • Lignes ACG : < 1.5 km à l’équateur vs swetest
  • Lever/coucher du soleil : < 10 secondes vs timeanddate.com
  • VOC de la Lune, ingressions, conjonctions planétaires : précision à la fraction de seconde

Méthodologie : comment les mesures sont effectuées

Section intitulée « Méthodologie : comment les mesures sont effectuées »

Ces chiffres ne sont pas une estimation, mais le résultat d’une exécution. Le script prend 10 cartes, réparties de 1900 à 2050, interroge les mêmes moments auprès du swetest CGI Astrodienst en direct et compare les 13 corps que nous renvoyons. Cela représente un total de 130 mesures.

CorpsDérive maximale
Soleil, Vénus, Saturne0.001"
Mercure0.002"
Nœud vrai0.004"
Mars0.007"
Jupiter0.009"
Lune0.022"
Uranus0.083"
Pluton0.097"
Neptune0.223"
Chiron0.561"
Apogée moyen (Lilith)0.000"

Médiane sur les 130 mesures : 0.0013".

Auparavant, cette page contenait une promesse générale de « < 0.1 arcsec ». Les mesures du 29/07/2026 ont montré que Neptune, Pluton et Chiron ne la respectent pas, la promesse a donc été remplacée par les chiffres réels. Chiron et les planètes extérieures ont une dérive plus importante car leurs positions sont tirées d’un ensemble d’éphémérides compressé dans l’assemblage WASM.

Tu peux reproduire cela toi-même : api-calc/scripts/accuracy-vs-swetest.mjs effectue exactement ces requêtes et imprime le même tableau.

Vérifie par toi-même. Le script qui a mesuré les chiffres ci-dessus se trouve dans un dépôt public sous licence MIT : astroway/astrology-accuracy-benchmark. Il ne fonctionne pas seulement avec nous : un adaptateur vers n’importe quelle autre API ne représente qu’une trentaine de lignes, tu peux donc exécuter les mêmes 130 mesures contre un concurrent et comparer. Une clé de sandbox est suffisante.

ComposantValeur
BibliothèqueSwiss Ephemeris C code (aloistr/swisseph)
Versioncode C Astrodienst upstream
Bindingsswisseph-wasm (WebAssembly dans Node.js)
ÉphéméridesDE431 JPL ephemeris (via les fichiers .se1)
FallbackMoshier analytical (pour les dates en dehors de 1800-2399)
Partage de codePartagé @/core avec app.astroway.info - un moteur, deux transports

La précision est vérifiée par triangulation - comparaison avec trois sources indépendantes :

L’implémentation de référence officielle de Swiss Ephemeris par Astrodienst eux-mêmes - l’équipe qui a créé Astro.com et sert des millions d’astrologues dans le monde entier. La source publique la plus fiable. Notre moteur est identique (0.00–0.07 seconde d’arc de dérive).

Une bibliothèque Python indépendante utilise les bindings pyswisseph au lieu de notre WASM. Elle confirme que notre couche WASM ne déforme pas les données.

API Swiss Ephemeris distante (sidéral Lahiri). La dérive systémique de 8 à 17 secondes d’arc est liée aux différentes versions de la formule Lahiri ayanamsa, et non à la précision du moteur.

Cartevs swetest (Astrodienst)vs Kerykeion (Python)vs Prokerala API
Monroe 19260.00”0.19”16.95” (systemic)
Diana 19610.00”0.69”8.18” (systemic)
Einstein 18790.07”artefact LMT Kerykeion14.96” (systemic)

Chacun des endpoints de calcul de base est couvert par des tests snapshot figés sur 3 cartes de référence (Monroe / Diana / Einstein) = 873 snapshots.

La suite de snapshots détecte :

  • Bugs de mappage des données d’entrée - id de planète incorrect, UT, système de maisons
  • Post-traitement - arrondi, conversion d’unités, perte de signe
  • Divergence des valeurs par défaut - nœud moyen vs vrai, géocentrique vs topocentrique
  • Dérive de schéma - la validation a manqué une forme incorrecte
  • Déploiement obsolète - la distribution de production ne correspond pas au code

Tolérance : 5e-5° (≈0.18 seconde d’arc) par défaut pour tous les champs numériques.

CarteDateDérive maximale
Marilyn Monroe1926-06-010.00”
Princess Diana1961-07-010.00”
Albert Einstein1879-03-140.07”
CarteDérive ASCDérive MCDérive maximale de la cuspide
Monroe0.000”0.000”0.000”
Diana0.000”0.000”0.000”
ÉvénementMaximum NASANotre maximumDérive
2025-03-14 Éclipse lunaire totale06:58 UT06:58 UT0.8 min
2025-03-29 Éclipse solaire partielle10:47 UT10:47 UT0.5 min
2025-09-07 Éclipse lunaire totale18:11 UT18:11 UT0.8 min
2025-09-21 Éclipse solaire partielle19:41 UT19:42 UT1.0 min

Toutes les lignes MC/IC/ASC/DSC utilisent la formule correcte longitude = RA − GMST (standard Kenneth Bowser). Dérive par rapport à la référence : < 1.5 km à l’équateur pour toutes les planètes.

LocalisationDateParamètreDérive
Londres2026-04-15Lever du soleil0.6 s
Londres2026-04-15Coucher du soleil9 s

Les localisations polaires (|lat| > 66.5°) renvoient automatiquement polarState + un avertissement indiquant que les heures planétaires habituelles ne sont pas définies.

AstroWay utilise des orbes variables par planète (règle du MIN des deux planètes), comme dans ZET9 et astro.com. Orbes par défaut (pour une carte natale) :

AspectSoleilLuneIntérieurJupiterExtérieur
Conjunction12°10°
Sextile6.5°
Square10°
Trine12°
Opposition12°10°

Les aspects mineurs (36°, 40°, 45°, 72°, 108°, 135°, 144°) sont désactivés par défaut. Ils sont activés explicitement via ALL_ASPECTS.

Pour |lat| > 66.5°, les systèmes Placidus / Koch / Regiomontanus ne sont pas mathématiquement définis. Dans de tels cas, Swiss Ephemeris renvoie automatiquement Porphyry, et notre API ajoute un avertissement :

{
"system": "P",
"warning": "Система Placidus не визначена для lat=68.96° (> 66.5°). Swiss Ephemeris підставив Porphyry..."
}

La régression est vérifiée à chaque PR via CI :

  • api-calc/tests/endpoints/ - 873 snapshots contre les cartes de référence (Monroe / Diana / Einstein) + synastry / composite / davison
  • .github/workflows/api-accuracy.yml - exécution automatique sur PR
  • Triangulation contre swetest CGI + Kerykeion - hebdomadaire
  • Surveillance de Swiss Ephemeris upstream via Dependabot

La précision du moteur est la moitié de la confiance. L’autre moitié est le contrat de sortie, que l’agent (Claude, ChatGPT, Cursor) peut valider. Notre serveur MCP ne renvoie pas de « texte brut, débrouille-toi » :

  • structuredContent typé. Plus de 600 outils MCP, et la grande majorité d’entre eux publient un outputSchema strict - le client MCP reçoit une structure validée, et non une chaîne de caractères à analyser au hasard.
  • Protection contre la dérive de schéma. Le test CI openapi-example-drift valide chaque snapshot de régression contre le schéma dérivé de son propre exemple : si la sortie réelle de l’endpoint diverge du schéma publié, la build échoue. C’est précisément cette classe de divergences qui provoque l’erreur MCP -32602 Output validation error.
  • Les erreurs sont des erreurs. Une défaillance d’outil est toujours renvoyée avec le drapeau isError et un code typé (UPPER_SNAKE). Nous ne renvoyons jamais à un modèle une trace de pile brute ou des chemins de serveur internes comme des « données ».

Autrement dit, l’intégration via MCP est aussi prévisible qu’un appel REST direct : ce qui est décrit dans /openapi.json est ce que l’outil renvoie.

  • Dates hors plage (avant 1800 et après 2399) : Moshier analytical est utilisé, précision ~0.1” (contre < 0.01” pour SWIEPH avec les fichiers DE431)
  • Lilith Vraie (id=13) vs Lilith Moyenne (id=12) : différence jusqu’à 12° - par défaut Lilith Moyenne (comportement stable), Lilith Vraie est disponible via planetIds: [13]
  • Topocentrique vs géocentrique : géocentrique par défaut

Pour les questions de précision : écris à support@astroway.info avec les données de la carte et la référence attendue (astro.com ou autre source fiable).

Utile?
Запропонувати правку

Dernière mise à jour :