AstroWay/api v2.190.0 · fr
tous les systèmes sont opérationnels

Comment nous maintenons l'exactitude sous contrôle : CI contre swetest et NASA

L'exactitude dans l'API astro se dégrade facilement d'une refonte des éphémérides. Nous décomposons la protection : un noyau Swiss Ephemeris sur navigateur et serveur, des centaines de snapshots gelés sur les cartes de référence et la triangulation de chaque PR contre swetest CGI, Kerykeion, Prokerala et le catalogue d'occultations de NASA.

Précision, c’est ce dont l’utilisateur vérifie silencieusement votre exactitude sur Astrodienst. Si la carte actuelle se déchire sur une minute de quadrant, la plainte arrivera vite. Et le pire dans tout cela, c’est que la précision peut être facilement brisée sans le faire : un refactoring dans le code des éphémérides, et la moitié des points d’entrée s’en vont en secondes d’arc.

Voici comment nous empêchons cela de se produire.

Les positions planétaires sont comptées par Swiss Ephemeris, compilé en WASM. Clé : c’est le même noyau dans le navigateur de notre application et sur le serveur API. Une seule base de code core/, tirée dans le backend via alias de cross-repo et intégrée dans le bundle sur le bâtiment. Aucune « version navigateur » et « version serveur » qui peuvent diverger - diverger de rien.

Pour les dates en dehors du domaine principal des éphémérides, il y a un fallback analytique (Moshier), un peu plus grossier, mais sans rupture aux limites. Honnêteté avouée : nous ne déclarons pas publiquement la version réelle de la roue, car la vraie version du noyau est inférieure à la dernière version upstream, et écrire un grand nombre aurait été une fausseté.

Chaque point d’entrée de calcul a un ensemble de snapshots gelés - 873 JSON-fichiers au moment de ce bâtiment. Le runner lance l’entrée sur les cartes de référence et vérifie avec la fiches. Toute divergence de longitude planétaire supérieure à 5e-5° (0.18”) fait échouer le test.

Les cartes de référence sont choisies pour frapper aux bords, et non seulement au « centre agréable » :

  • Monroe, Diana, Einstein, Bowie - les cartes historiques avec des données de naissance connues
  • la latitude - où les systèmes de maison se déforment
  • l’équatorial - où ils se comportent différemment
  • la latitude sud - vérification de la symétrie

Les cas limites attrapent exactement les regressions qui ne sont pas visibles sur la carte de l’habitant conditionnel.

Les snapshots attrapent les regressions par rapport à elles-mêmes. Pour vérifier l’exactitude absolue, chaque version est vérifiée avec des sources indépendantes :

Contre quoiCe qui vérifieDivergence
swetest CGI (Astrodienst)longitudes planétaires, cusps de maison0.000"
Kerykeion (Python, pyswisseph)implémentation indépendante de SwEph< 0.2"
Prokerala (sidereal Lahiri)positions sidérales8-17", différence systématique de la formule Ayanamsha, pas de roue
NASA 5-Millennium Eclipse Catalogtemps et type de l’éclipse< 1 min

La divergence avec Prokerala - ce n’est pas une erreur : c’est différentes implémentations de la formule Lahiri, et nous documentons cela explicitement, et non pas caché. Avec swetest, qui est l’étalon de l’industrie, la dérive est nulle.

Les lignes aérométriques sont vérifiées géométriquement - la précision est meilleure que 1,5 km sur l’équateur.

La précision - c’est le CI-gate, et non la vérification unique :

  • api-accuracy.yml - sur chaque PR dans le code backend, lance tout le jeu de snapshots + triangulation. Le test rouge bloque la fusion.
  • check-eclipse-accuracy.yml - une fois par an vérifie les éclipses avec le catalogue NASA ; les divergences supérieures au seuil engendrent automatiquement un problème.
  • check-sweph-updates.yml - chaque semaine surveille la mise à jour de Swiss Ephemeris et du paquet WASM ; une nouvelle version - problème sur la revue, sans auto-merge (mise à jour de la roue des éphémérides - trop sensible pour l’auto-mise à jour).

Garantie simple : les positions planétaires dans les limites de < 0.1 secondes d’arc de l’étalon Swiss Ephemeris, et cette limite est protégée automatiquement, et non par une promesse dans README. Si jamais une regression apparaît, elle tombera dans notre CI, et non dans la plainte de votre utilisateur.

La version publique de ces chiffres, avec la table des divergences sur des cartes spécifiques, vit sur la page Précision.

MakSeong · AstroWay

Je fais l'API AstroWay : j'enveloppe Swiss Ephemeris dans du REST pur et j'écris sur les détails ennuyeux qui sont en fait importants.

// construis avec ça

Le même Swiss Ephemeris que Solar Fire - en 4 lignes de code.

Clé gratuite sans carte. 5 000 appels par mois avant le premier paiement.

Plus d'articles du blog voir tous les articles →

Engineering 2026-07-15

Trois SDK officiels : TypeScript, Python, PHP au lieu de curl brut

Le HTTP brut fonctionne, mais le client typé économise des heures : autocomplétion des chemins, types de requête et de réponse, retry intégré pour 408/409/429/5xx et hiérarchie de erreurs à la manière de Stainless. Nous démontons les trois SDK officiels - @astroway/sdk (npm), astroway (PyPI), astroway/sdk (Packagist) - et comment ils sont générés à partir d'un même contrat OpenAPI.

Industry 2026-06-05

Free Astrology API: Which One Has the Best Free Tier in 2026?

A side-by-side of free tiers across the major astrology APIs - credits, request caps, card requirements - and how much you can actually build for free.

Engineering 2026-06-05

Horoscope API Tutorial: Build a Daily Horoscope Feature

Add daily, weekly and monthly horoscopes to your app via API - sign-based text vs transit-based personalization - with TypeScript and Python code.