Aquila ajoute une couche de gouvernance au-dessus de vos pipelines GitHub.
Au lieu de remplacer votre orchestrateur, Aquila le supervise : règles de déploiement, conformité, sécurité, visibilité. Une API unique contrôle l’ensemble des éditions FREE, SOLO, PRO et ENTERPRISE.
Le problème adressé
Dans la plupart des organisations, la CI/CD GitHub se développe par couches successives : équipes autonomes, workflows copiés-collés, secrets dispersés, absence de modèle commun. Résultat : dette de configuration, risques de sécurité et difficulté à démontrer la conformité.
Flux non maîtrisés
Multiplication de workflows, absence de vue globale et de règles homogènes entre équipes.
Sécurité & conformité
Permissions trop larges, gestion hétérogène des secrets, difficulté à prouver qui déploie quoi, où et quand.
Manque de visibilité
Impossible de répondre simplement aux questions : “Quels projets déploient en prod ? Selon quelles règles ?”.
Comment fonctionne Aquila ?
Aquila n’exécute pas vos jobs à la place de GitHub. Il se place en amont : un workflow lui envoie un contexte (projet, environnement, type de déploiement, etc.), Aquila applique vos politiques, puis renvoie une décision structurée.
Vous décrivez vos organisations, projets, environnements et règles dans un modèle central (JSON / API).
Chaque workflow critique appelle l’API Aquila (GitHub Actions → API) pour demander une décision de gouvernance.
Aquila renvoie un résultat (autorisé / refusé / averti), journalise la décision et alimente vos dashboards.
Cas d’usage typiques
Aquila cible principalement les équipes Plateforme / DevOps, les référents sécurité et les responsables d’applications critiques.
Plateforme DevOps
Industrialiser un modèle de gouvernance CI/CD commun à plusieurs équipes, sans leur retirer l’autonomie sur leurs pipelines.
Sécurité & conformité
Imposer des règles globales (séparation des environnements, validations managériales, contraintes de secrets) et disposer d’un audit exploitable.
Produits critiques
Encadrer les déploiements sensibles (prod, pré-prod, clients stratégiques) via une API claire plutôt que des scripts ad hoc.
Éditions et trajectoire d’adoption
Toutes les éditions partagent la même API. Vous pouvez commencer en FREE ou SOLO, puis évoluer vers PRO ou ENTERPRISE sans changer de modèle ni de code d’intégration.
FREE
Sandbox / PoC- Instance unique, non redondée
- Règles de base sur les workflows
- Swagger et dashboards techniques
SOLO
Équipe ou produit- Règles de gouvernance avancées
- Intégration complète GitHub Actions
- Supervision et journaux d’audit
PRO
Organisation- Multi-org GitHub / multi-projets
- Policy Engine avancé, scoring, traces détaillées
- Observabilité : métriques, dashboards, alertes
ENTERPRISE
Grand compte- Multi-tenants, cloisonnement fort
- Règles renforcées, conformité et audits
- Supervision N3, accompagnement et support prioritaire
Étapes concrètes pour un pilote
Pour un pilote réaliste, l’approche recommandée est la suivante :
- Choisir 1 à 3 projets GitHub représentatifs (un produit critique, un service transverse, un repo “standard”).
- Modéliser les environnements, règles de déploiement et validations dans Aquila (fichier de configuration / API).
- Brancher 1 ou 2 workflows GitHub Actions sur l’API Aquila (appel REST simple).
- Suivre les décisions dans les journaux et dashboards, ajuster les règles avec les équipes.