Précision des calculs
AstroWay API utilise Swiss Ephemeris (code C officiel d’Astrodienst, créateurs d’astro.com) - le même moteur sur lequel les astrologues professionnels travaillent depuis 30+ ans dans Solar Fire ($495), Kepler ($995), Astro Gold ($29.99/mois) et Janus. Nous l’exécutons sur nos propres serveurs et le fournissons sous forme de couche REST API, sans marge 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 + par rapport au catalogue des éclipses NASA 5-Millennium :
- Positions planétaires : médiane
0.0013", maximum0.561"vs le CGI swetest officiel d’Astrodienst (mesuré le 2026-07-29 sur 130 mesures). Répartition par corps ci-dessous - Vérification indépendante avec un autre benchmark (RoxyAPI, contre NASA JPL Horizons DE441) : 210 sur 210 dans la tolérance, médiane
0.11", maximum0.60" - Cuspides des maisons Placidus :
0.000"correspondance exacte - Éclipses :
< 1 minutevs le catalogue d’éclipses NASA - Lignes ACG :
< 1.5 kmà l’équateur vs swetest - Lever/coucher du soleil :
< 10 secondesvs timeanddate.com - VOC de la Lune, ingresses, conjonctions planétaires : précision à la fraction de seconde
Méthodologie : comment exactement mesuré
Section intitulée « Méthodologie : comment exactement mesuré »Ces chiffres ne sont pas une estimation, mais le résultat d’un test. Le script prend 10 cartes, réparties de 1900 à 2050, interroge les mêmes moments dans le CGI swetest vivant d’Astrodienst et compare les 13 corps que nous fournissons. Au total 130 mesures.
| Corps | Dérive maximale |
|---|---|
| Soleil, Vénus, Saturne | 0.001" |
| Mercure | 0.002" |
| vrai Nœud | 0.004" |
| Mars | 0.007" |
| Jupiter | 0.009" |
| Lune | 0.022" |
| Uranus | 0.083" |
| Pluton | 0.097" |
| Neptune | 0.223" |
| Chiron | 0.561" |
| mean Apogée (Lilith) | 0.000" |
Médiane sur toutes les 130 mesures : 0.0013".
Avant, sur cette page, il y avait une promesse générale de ’< 0,1 seconde d’arc’. Les mesures du 2026-07-29 ont montré que Neptune, Pluton et Chiron ne la respectent pas, donc la promesse a été remplacée par les chiffres réels. Chiron et les planètes extérieures ont un dérive plus important car leurs positions sont prises à partir d’un ensemble compressé d’éphémérides utilisé par notre build.
Vous pouvez le reproduire vous-même : api-calc/scripts/accuracy-vs-swetest.mjs effectue exactement ces requêtes et imprime la même table.
Vérifiez-le vous-même. Le script utilisé pour mesurer les chiffres ci-dessus se trouve dans le dépôt public sous licence MIT : astroway/astrology-accuracy-benchmark. Il fonctionne non seulement avec nous : un adaptateur vers n’importe quel autre API représente trente lignes, donc les mêmes 130 mesures peuvent être exécutées contre un concurrent et comparées. Une clé de sandbox suffit.
| Composant | Valeur |
|---|---|
| Bibliothèque | Swiss Ephemeris C code (aloistr/swisseph) |
| Version | code C upstream d’Astrodienst |
| Éphéméride | Éphéméride DE431 JPL (via fichiers .se1) |
| Fallback | Moshier analytique (pour les dates hors 1800-2399) |
| Partage de code | Shared @/core avec app.astroway.info - un moteur, deux transports |
Méthodologie
Section intitulée « Méthodologie »La précision est vérifiée par triangulation - comparaison avec trois sources indépendantes :
1. swetest CGI (référence)
Section intitulée « 1. swetest CGI (référence) »Implémentation de référence officielle du Swiss Ephemeris d’Astrodienst - l’équipe qui a créé Astro.com et qui sert des millions d’astrologues dans le monde. La source publique la plus autoritaire. Notre moteur est identique (0,00–0,07 seconde d’arc de dérive).
2. Kerykeion (Python)
Section intitulée « 2. Kerykeion (Python) »Bibliothèque Python indépendante utilisant les liaisons pyswisseph, indépendantes de notre compilation. Elle confirme que notre couche d’enveloppe ne déforme pas les données.
3. Prokerala API
Section intitulée « 3. Prokerala API »API distante Swiss Ephemeris (sidéral Lahiri). Le dérive systémique de 8–17 secondes d’arc est lié aux différentes versions de la formule Lahiri ayanamsa, et non à la précision du moteur.
Résultats de la triangulation
Section intitulée « Résultats de la triangulation »| Carte | contre swetest (Astrodienst) | contre Kerykeion (Python) | contre Prokerala API |
|---|---|---|---|
| Monroe 1926 | 0.00” | 0.19” | 16.95” (systémique) |
| Diana 1961 | 0.00” | 0.69” | 8.18” (systémique) |
| Einstein 1879 | 0.07” | artefact LMT de Kerykeion | 14.96” (systémique) |
Vérification indépendante avec un autre outil
Section intitulée « Vérification indépendante avec un autre outil »RoxyAPI publie leur propre benchmark par rapport à NASA JPL Horizons DE441 : licence MIT, uniquement bibliothèque standard, 21 cartes et 210 positions, et le drapeau --base-url permettant de le pointer vers n’importe quel autre API. Dans leur README, il est indiqué explicitement que les tolérances n’ont pas été délibérément ajustées à leur propre moteur, car le benchmark permettant de vérifier un concurrent doit être honnête.
| AstroWay | RoxyAPI, leur test du 2026-09-29 | |
|---|---|---|
| Dans la tolérance | 210 sur 210 | 210 sur 210 |
| Écart médian | 0.11" | 0.05" |
| Maximum | 0.60" | 0.78" |
Notre mesure du 2026-09-09, 21 requêtes API. RoxyAPI en septembre est passé à la lecture directe de DE440, et leur médiane est maintenant inférieure à la nôtre ; notre maximum est inférieur au leur. Sortie ordonnée de toutes les 210 lignes : CSV.
Jeu de tests de régression au niveau des endpoints
Section intitulée « Jeu de tests de régression au niveau des endpoints »Chaque endpoint de calcul de base est couvert par des tests snapshot figés sur 3 cartes de référence (Monroe / Diana / Einstein) = 873 snapshot-s.
La suite de snapshot détecte :
- Bugs de mappage des données d’entrée : mauvais ID de planète, UT, système de maisons
- Post-traitement : arrondi, conversion d’unités, perte de signe
- Écart des défauts : nœud moyen vs vrai nœud, géocentrique vs topocentrique
- Dérive de schéma : validation a laissé passer une forme incorrecte
- Déploiement obsolète : la distribution prod ne correspond pas au code
Tolérance : 5e-5° (≈0,18 seconde d’arc) par défaut pour tous les champs numériques.
Benchmarks détaillés
Section intitulée « Benchmarks détaillés »Positions des planètes (tropique, contre swetest)
Section intitulée « Positions des planètes (tropique, contre swetest) »| Carte | Date | Dérive maximale |
|---|---|---|
| Marilyn Monroe | 1926-06-01 | 0.00” |
| Princess Diana | 1961-07-01 | 0.00” |
| Albert Einstein | 1879-03-14 | 0.07” |
Cuspides des maisons Placidus (contre swetest)
Section intitulée « Cuspides des maisons Placidus (contre swetest) »| Carte | dérive ASC | dérive MC | dérive maximale du cuspide |
|---|---|---|---|
| Monroe | 0.000” | 0.000” | 0.000” |
| Diana | 0.000” | 0.000” | 0.000” |
Éclipses (contre le catalogue NASA 5-Millennium)
Section intitulée « Éclipses (contre le catalogue NASA 5-Millennium) »| Événement | Maximum NASA | Notre maximum | Déviation |
|---|---|---|---|
| 2025-03-14 Lune Totale | 06:58 TU | 06:58 TU | 0,8 min |
| 2025-03-29 Soleil Partiel | 10:47 TU | 10:47 TU | 0,5 min |
| 2025-09-07 Lune Totale | 18:11 TU | 18:11 TU | 0,8 min |
| 2025-09-21 Soleil Partiel | 19:41 TU | 19:42 TU | 1,0 min |
Astrocartographie (contre les formules RA de swetest)
Section intitulée « Astrocartographie (contre les formules RA de swetest) »Lever / Coucher du Soleil (contre timeanddate.com)
Section intitulée « Lever / Coucher du Soleil (contre timeanddate.com) »| Localisation | Date | Paramètre | Déviation |
|---|---|---|---|
| Londres | 2026-04-15 | Lever du Soleil | 0,6 s |
| Londres | 2026-04-15 | Coucher du Soleil | 9 s |
Localisations polaires (|lat| > 66,5°) retournent automatiquement polarState + un avertissement indiquant que les heures planétaires habituelles ne sont pas définies.
Orbes des aspects
Section intitulée « Orbes des aspects »AstroWay utilise des orbes variables par planète (règle du MIN des deux planètes), comme dans ZET9 et astro.com. Les orbes par défaut (pour une carte natale) :
| Aspect | Soleil | Lune | Intérieur | Jupiter | Extérieur |
|---|---|---|---|---|---|
| Conjonction | 12° | 10° | 5° | 8° | 5° |
| Sextile | 6,5° | 6° | 5° | 5° | 5° |
| Carré | 10° | 8° | 5° | 7° | 5° |
| Trine | 12° | 8° | 5° | 5° | 5° |
| Opposition | 12° | 10° | 5° | 8° | 5° |
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.
Latitudes polaires
Section intitulée « Latitudes polaires »Pour |lat| > 66,5°, les systèmes Placidus / Koch / Regiomontanus ne sont pas définis mathématiquement. Dans ces cas, Swiss Ephemeris retourne automatiquement Porphyry, et notre API ajoute un avertissement :
{ "system": "P", "warning": "Placidus system is undefined for lat=68.96° (> 66.5°). Swiss Ephemeris fell back to Porphyry..."}Vérification continue
Section intitulée « Vérification continue »La régression est vérifiée à chaque PR via CI :
api-calc/tests/endpoints/: 873 snapshot-s contre les cartes de référence (Monroe / Diana / Einstein) + synastrie / composite / davison.github/workflows/api-accuracy.yml: exécution automatique sur PR- Triangulation contre swetest CGI + Kerykeion : hebdomadaire
- Surveillance de l’upstream Swiss Ephemeris via Dependabot
Fiabilité MCP : sortie typée
Section intitulée « Fiabilité MCP : sortie typée »La précision du moteur n’est qu’une moitié de la confiance. L’autre moitié est le contrat de sortie, qu’un agent (Claude, ChatGPT, Cursor) peut valider. Notre serveur MCP ne renvoie pas de ” texte brut, débrouillez-vous ” :
structuredContenttypé. Plus de 600 outils MCP, et la grande majorité d’entre eux publient un strictoutputSchema- le client MCP reçoit une structure validée, et non une chaîne qu’il faut deviner.- Protection contre la dérive de schéma. Le test CI
openapi-example-driftvalide chaque snapshot de régression par rapport au schéma généré à partir de son propre exemple : si la sortie réelle d’un endpoint diverge du schéma publié, la build échoue. C’est précisément cette catégorie de divergences qui provoque l’erreur MCP-32602 Output validation error. - Erreurs : ce sont des erreurs. L’échec d’un outil renvoie toujours le drapeau
isErroret un code typé (UPPER_SNAKE). Nous ne renvoyons jamais à la modèle la trace de pile brute ou les chemins internes du serveur comme ” données ”.
Limitations connues
Section intitulée « Limitations connues »- Dates hors plage (avant 1800 et après 2399) : utilisation de Moshier analytique, précision ~0,1” (contre < 0,01” pour SWIEPH avec les fichiers DE431)
- Vraie Lilith (id=13) vs Lilith moyenne (id=12) : différence jusqu’à 12° - par défaut Lilith moyenne (comportement stable), vraie Lilith accessible via
planetIds: [13] - Topocentrique vs géocentrique : par défaut géocentrique
Références
Section intitulée « Références »- Swiss Ephemeris: https://www.astro.com/swisseph/
- swetest CGI: https://www.astro.com/swisseph/swetest.htm
- Catalogue d’éclipses NASA: https://eclipse.gsfc.nasa.gov/
- Kerykeion: https://github.com/g-battaglia/kerykeion
- Astrodienst: https://www.astro.com/
Contacts
Section intitulée « Contacts »Pour les questions de précision : écrivez à support@astroway.info avec les données de la carte et l’étalon attendu (astro.com ou une autre source autoritaire).