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

Comment nous gardons la précision sous contrôle : la CI contre swetest et la NASA

Dans une API d'astrologie, la précision se dégrade facilement après un seul refactoring des éphémérides. Voici notre protection : un seul noyau Swiss Ephemeris pour l'application et l'API, des centaines de snapshots figés sur des thèmes de référence et la triangulation de chaque PR contre swetest CGI, Kerykeion, Prokerala et le catalogue d'éclipses de la NASA.

La précision, c’est ce que l’utilisateur vérifie en silence en te comparant à Astrodienst. Si un thème natal s’écarte d’une minute d’arc, la plainte arrive vite. Et le pire, c’est que la précision se casse facilement sans que personne ne le remarque : un refactoring dans le code des éphémérides, et la moitié des endpoints dérive discrètement de quelques secondes d’arc.

Voici comment nous empêchons que cela arrive.

Les positions planétaires sont calculées par Swiss Ephemeris. Le point clé : notre application et l’API partagent un seul noyau de calcul, une seule base de code. Il n’existe pas deux implémentations susceptibles de diverger, donc rien ne peut diverger.

Pour les dates hors de la plage principale des éphémérides, il existe un fallback analytique (Moshier), un peu moins précis, mais sans discontinuité aux limites. Par honnêteté assumée, nous n’annonçons pas publiquement de version précise du moteur : la version réelle du noyau est antérieure au dernier upstream, et afficher un chiffre flatteur serait un mensonge.

Chaque endpoint de calcul dispose d’un jeu de snapshots figés : 873 fixtures JSON au moment de ce build. Le runner exécute l’endpoint sur des thèmes de référence et le compare octet par octet (dans la limite d’une tolérance) à la fixture. Tout écart de longitude planétaire supérieur à 5e-5° (0.18″) fait échouer le test.

Les thèmes de référence sont choisis pour frapper les cas limites, pas seulement le centre “confortable” :

  • Monroe, Diana, Einstein, Bowie : des thèmes historiques aux données de naissance connues
  • latitude polaire : là où les systèmes de maisons dégénèrent
  • équatoriale : là où ils se comportent autrement
  • hémisphère sud : vérification de la symétrie miroir

Ce sont justement les cas limites qui attrapent les régressions invisibles sur le thème d’un habitant de Kyiv lambda.

Les snapshots détectent les régressions par rapport à eux-mêmes. Pour vérifier la vérité absolue, chaque release est confrontée à des sources indépendantes :

Contre quoiCe qui est vérifiéÉcart
swetest CGI (Astrodienst)longitudes planétaires, cuspides des maisons0.000″
Kerykeion (Python, pyswisseph)implémentation indépendante de SwEph< 0.2″
Prokerala (sidereal Lahiri)positions sidérales8-17″, différence systématique dans la formule de l’ayanamsa, pas dans le moteur
NASA 5-Millennium Eclipse Catalogheure et type des éclipses< 1 min

L’écart avec Prokerala n’est pas une erreur : ce sont deux implémentations différentes de la formule de Lahiri, et nous le documentons explicitement au lieu de le cacher. Avec swetest, qui est la référence du secteur, la dérive est nulle.

Les lignes d’astrocartographie sont vérifiées séparément, de façon géométrique : la précision à l’équateur est meilleure que 1.5 km.

La précision est une CI gate, pas une vérification ponctuelle :

  • api-accuracy.yml : sur chaque PR touchant le code backend, exécute tout le jeu de snapshots + la triangulation. Un test rouge bloque le merge.
  • check-eclipse-accuracy.yml : une fois par an, compare les éclipses au catalogue de la NASA ; un écart au-delà du seuil ouvre automatiquement une issue.
  • check-sweph-updates.yml : chaque semaine, surveille l’upstream de Swiss Ephemeris ; une nouvelle version ouvre une issue pour revue, sans auto-merge (mettre à jour le moteur d’éphémérides est trop sensible pour une mise à jour automatique).

La garantie est simple : des positions planétaires à < 0.1 seconde d’arc de la référence Swiss Ephemeris, et cette limite est protégée par l’automatisation, pas par une promesse dans un README. Si une régression apparaît un jour, elle fera échouer notre CI, pas la réclamation de ton utilisateur.

La version publique de ces chiffres, avec un tableau des écarts par thème, se trouve 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 un client typé fait gagner des heures : autocomplétion des chemins, types de requête et de réponse, retry intégré sur 408/409/429/5xx et hiérarchie d'erreurs à la Stainless. Tour d'horizon des trois SDK officiels, @astroway/sdk (npm), astroway (PyPI), astroway/sdk (Packagist), et de la manière dont 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.