FAQ védique

Voici les questions qui reviennent souvent lors de l’intégration des endpoints védiques. Si vous ne trouvez pas la réponse, écrivez à hello@astroway.info, nous l’ajouterons.

Quels ayanamsas sont pris en charge ? Lequel choisir ?

L’API prend en charge 9 ayanamsas :

Code	Nom	Quand le choisir
`lahiri` (default)	Chitra-Paksha	Standard du gouvernement indien ; le plus grand marché grand public. Pour la plupart des applications védiques, c’est celui-ci.
`raman`	B.V. Raman	Si vous intégrez une application mobile pour le marché du sud de l’Inde (Karnataka, Tamil Nadu).
`krishnamurti` (alias `kp`)	KP	Si vous appelez `/v1/vedic/kp/*` : KP a son propre ayanamsa.
`yukteshwar`	Sri Yukteshwar	Distance depuis Spica ; publics théosophiques ou orientés vers l’Occident.
`fagan-bradley`	Fagan/Bradley	Sidéral occidental (non védique). Pour les astrologues qui viennent des traditions sidérales occidentales.
`de-luce`	De Luce	Choix plus ancien des astrologues, rare.
`jn-bhasin`	JN Bhasin	École spécifique, rare.
`true-citra`	True Chitra Paksha	Spica fixée strictement à 0° Balance. Diverge de Lahiri de 0.01°, donc ne le prenez que si vous avez besoin précisément de l’ancrage stellaire.
`djwhal-khul`	Djwhal Khul	École théosophique, rare. Le plus grand écart du tableau.

Les principales écoles divergent peu : Lahiri, True Chitra et KP restent dans une marge de 0.1°, Fagan/Bradley, JN Bhasin, Yukteshwar et Raman jusqu’à 1.45°. À part se trouvent De Luce (3.96° de Lahiri) et Djwhal Khul (3.82°), et avec eux une position proche de la limite d’un signe passe déjà dans le signe voisin. Mesuré le 2026-08-18 sur la Lune d’une carte ; sur les techniques basées sur les degrés (position du Nakshatra, Argala), la différence est visible même dans une marge de 0.1°.

Sidéral ou tropical ? Que renvoie l’API ?

Par défaut, les endpoints védiques renvoient des positions sidérales (zodiaque lié aux étoiles, avec l’ayanamsa appliqué). Les endpoints occidentaux (/v1/chart, /v1/synastry) renvoient des positions tropicales (zodiaque lié au point équinoxial).

L’API ne fournit pas de védique tropical (un cas limite rare proposé par Sanjay Rath et Ernst Wilhelm) : tous les endpoints védiques calculent en sidéral et ignorent zodiacType dans le corps de la requête. Les positions tropicales sont fournies par la branche occidentale (/v1/chart, /v1/synastry), et zodiacType: "sidereal" la bascule vers le zodiaque sidéral avec le même ayanamsa.

Quelle école utiliser et quand ?

École	Région / Public	Point fort
Parashara (BPHS)	Tout le monde védique, base universelle	Le corpus de techniques le plus complet ; commencez toujours ici
Jaimini	Tamil Nadu + praticiens avancés	Prédictions basées sur les karakas ; thèmes de vie pilotés par l’AK
Lal Kitab	Pendjab + nord de l’Inde	Remèdes uniques (upaya), spécificités Manglik
KP (Krishnamurti)	Tamil Nadu + Andhra Pradesh	Théorie des sub-lords, précision dans le timing des événements

Pratyangira, AstroSage et d’autres grandes API fournissent surtout du Parashara. AstroWay couvre les quatre via des groupes d’endpoints distincts.

Ashtakoot ou Dashakoota : pour quel marché ?

	Ashtakoot	Dashakoota
Région	Nord et centre de l’Inde, Pakistan, Népal	Sud de l’Inde (Tamil Nadu, Karnataka, Kerala)
Échelle	36 points max	10 kutas (facteurs)
Composantes	Varna + Vashya + Tara + Yoni + Graha Maitri + Gana + Bhakoot + Nadi	Dina + Gana + Mahendra + Stri-Dirgha + Yoni + Rashi + Rashi-adhipathi + Vashya + Rajju + Vedha
API	`/v1/vedic/compatibility/ashtakoot`	`/v1/vedic/compatibility/dashakoota`

Si le service de mise en relation couvre toute l’Inde, appelez /v1/vedic/compatibility/full : vous obtenez les deux + Manglik + Bhrigu.

Mangal Dosha : pourquoi est-ce important ?

Mangal Dosha = Mars dans la maison 1/2/4/7/8/12 depuis le Lagna, la Lune ou Vénus (les écoles l’interprètent différemment). En Inde, c’est un facteur rédhibitoire pour le mariage : si les deux partenaires ont une affliction de Mangal sans compensation, un astrologue traditionnel ne donnera pas son feu vert sans upayas (remèdes) ou facteurs compensatoires.

Endpoint de l’API : /v1/vedic/compatibility/manglik-check, qui renvoie { chart1: { manglik: true/false, severity, factors }, chart2: ..., compensation: ... }.

D9 (Navamsha) : pourquoi est-ce le varga le plus important ?

D9 = division de chaque signe en 9 = une carte détaillée “au niveau de l’âme”. En védique, elle sert à :

Prédictions sur le mariage : Vénus + le maître de la 7e dans D9 montrent la vraie nature de la vie conjugale
Force des planètes : une planète forte en D1 mais faible en D9 = “promet mais ne tient pas”
Vargottama : une planète dans le même signe en D1 et D9 = force particulière

API : /v1/vedic/vargas renvoie les 16 divisions en un seul appel ; concentrez-vous sur D9 pour les fonctionnalités liées au mariage et aux relations.

Pourquoi l’heure de naissance est-elle critique ? Que faire si elle est inconnue ?

Le védique est très sensible à l’heure :

Le Lagna (Ascendant) change toutes les ~2 heures : c’est TOUTE la carte qui se décale
Le Nakshatra de la Lune change toutes les 6 à 8 heures
La balance de dasha (période initiale) dépend de la position de la Lune dans le nakshatra

Si l’heure exacte est inconnue :

Carte du lever du soleil : utilisez l’heure du lever du soleil au lieu de naissance comme approximation. Le Soleil se trouve alors sur l’Ascendant, donc le Lagna correspond à peu près au signe solaire ; certains astrologues védiques considèrent les cartes du lever du soleil comme valables pour une prévision des tendances générales
Rectification : appelez /v1/rectification avec 2 ou 3 événements de vie connus (mariage, enfant, changement de travail), l’API renvoie une fenêtre probable pour l’heure de naissance
Avertissement à l’utilisateur : indiquez que les résultats avec une heure inconnue sont une approximation, et non une carte exacte

Quels systèmes de maisons sont utilisés ?

Le védique utilise traditionnellement les maisons Whole Sign (un signe entier = une maison). L’occidental : Placidus / Koch / Equal etc.

Par défaut, AstroWay utilise Whole Sign pour le védique. Pour les endpoints KP, Placidus (convention KP). Passez le paramètre houseSystem si vous avez besoin d’autre chose : whole-sign, placidus, koch, equal, porphyry.

Peut-on mélanger védique et occidental dans une même application ?

Oui, et c’est même recommandé pour les publics multi-traditions. Architecture :

La carte natale est calculée une fois : les endpoints occidentaux et védiques partagent la même entrée (date/time/lat/lon)
Affichez un commutateur “Vue occidentale” / “Vue védique” dans votre UI
Le signe lunaire védique (rashi) est souvent confondu avec le signe solaire occidental : prévenez l’utilisateur de la différence
Compatibilité : vous pouvez montrer LES DEUX, synastrie occidentale + Ashtakoot védique en même temps

L’endpoint de l’API /v1/compat/astro-vedic le fait automatiquement : pont synastrie occidentale × Ashtakoot védique.

Quelle éphéméride est utilisée ? Quelle est sa précision ?

Swiss Ephemeris (LGPL), la même que dans Solar Fire, Kepler, Astro Gold, Janus, AstroSeek. Précision :

Positions planétaires : ±1 seconde d’arc vs l’éphéméride NASA JPL
Cuspides des maisons : ±1 minute d’arc
Ayanamsa : table Lahiri validée par recoupement avec les tables officielles du gouvernement indien

Pour les calculs spécifiques au védique (position du Nakshatra, balance Vimshottari, Vargas), recoupement avec PyJHora (référence Python de facto) ; écarts < 0.01° là où ils existent. Le rapport sur les écarts se trouve dans docs/AUDIT-TRAIL.md du dépôt.

Puis-je mettre les résultats en cache ? Comment ?

Oui, la plupart des endpoints védiques sont déterministes pour une même entrée de carte. Clé de cache stable : hash(date + time + lat + lon + ayanamsa + endpoint).

L’API propose aussi l’en-tête X-Idempotency-Key, un cache de 5 minutes côté api-calc. En cas de cache hit, les crédits ne sont pas débités.

Comment les textes des réponses sont-ils localisés ?

Les endpoints védiques qui renvoient des interprétations (descriptions de yogas, significations des doshas, raisons des muhurtas) acceptent le paramètre lang. Prise en charge : 20 langues (T0 - uk/en/de/ru manuellement ; T1 - pl/es/pt/hi/fr/ko IA Beta ; T2/T3 - prévues). Détails : /languages/.

Si l’endpoint renvoie des données numériques (degrés, dates, indices de signes), elles sont neutres vis-à-vis de la langue. Les champs texte (note, meaning, manifestation) sont localisés.

Que faire d’un statut YELLOW ?

YELLOW = l’endpoint fonctionne, mais présente l’une de trois caractéristiques :

École d’un seul auteur (Lal Kitab, KP) : pas de cross-verification avec d’autres écoles, car il n’y en a pas
Basé sur un scoring ou une heuristique (compatibility 0-100, breakup-timing) : l’évaluation numérique est subjective par nature
Limite de précision intrinsèque (rectification, Bhrigu match) : l’algorithme a un plancher de précision inhérent

Consultez docs/AUDIT-TRAIL.md pour l’endpoint concerné : il y est écrit pourquoi YELLOW et s’il existe un chemin vers GREEN. Pour la plupart, non (intrinsèque), et c’est un disclaimer honnête pour l’intégrateur.