Aller au contenu

API Aquila GOV V1

Cette section décrit les principaux endpoints exposés par l’API GOV V1. Les routes présentées ici constituent la base commune, indépendante de l’édition PRO.

Remarque : Les exemples sont fournis à titre indicatif. Les schémas exacts peuvent être consultés dans les tests d’API et les fichiers OpenAPI générés par FastAPI.

1. Santé du service

GET /health

Permet de vérifier que l’instance Aquila est démarrée et fonctionnelle.

Exemple de réponse :

{
  "status": "ok",
  "service": "aquila-governance-v1",
  "version": "1.6.0",
  "edition": "FREE"
}

Points à vérifier côté supervision : - code HTTP 200 ; - status = "ok" ; - version cohérente avec la release déployée.

2. Informations de version

GET /version

Retourne les informations de version détaillées (noyau GOV, build, date de compilation éventuelle).

Exemple de réponse :

{
  "service": "aquila-governance-v1",
  "version": "1.6.0",
  "build": "2025-11-19T10:00:00Z",
  "commit": "abcdef1234567890"
}

3. Gestion des éditions et licences

Même si le cœur de la logique de licence est porté par l’édition PRO, l’API GOV peut exposer un point d’accès permettant de vérifier le type d’édition et la présence d’une licence.

GET /edition

Exemple de réponse :

{
  "edition": "FREE",
  "features": {
    "governance": "basic",
    "history": false,
    "pro_available": true
  }
}

Dans un contexte PRO, l’édition sera généralement exposée via /agent/status côté PRO. Le endpoint /edition peut néanmoins être utilisé par des outils d’inventaire.

4. Principes de sécurité

  • Les endpoints GOV peuvent être exposés en interne uniquement (LAN / VPN).
  • La mise en place d’un reverse proxy HTTPS est fortement recommandée.
  • L’authentification et l’autorisation peuvent être gérées :
  • au niveau du proxy (IP allow‑list, mTLS, etc.) ;
  • ou via des mécanismes d’API key / tokens si nécessaire.

5. Bonnes pratiques d’intégration

  • Limiter l’usage de l’API GOV aux besoins strictement nécessaires (santé, version).
  • Pour toute décision de gouvernance d’exécution, utiliser l’API PRO (pro/api.md).
  • Documenter systématiquement :
  • qui consomme l’API ;
  • dans quel pipeline ;
  • avec quels niveaux de criticité.