Question 1

Sur quels langages et stacks Apollo travaille-t-il aujourd'hui ?

Accepted Answer

Apollo lit les conventions de votre dépôt et travaille dans les langages que votre équipe utilise déjà — TypeScript / JavaScript, Python, Go, Ruby, Java, et les familles de frameworks qui s'y rattachent. Le runtime est agnostique du langage ; le travail se fait dans la branche labo et dans votre CI.

Question 2

Que fait Apollo avec mon CI ? Le remplace-t-il ?

Accepted Answer

Non. Votre CI existante tourne telle quelle sur chaque branche labo. Apollo y ajoute des tests de régression pour le changement et, là où le plan le prévoit, quelques tests de propriétés. Les tests qui échouent bloquent la PR — jamais l'humain.

Question 3

Comment fonctionne la revue de code — qu'est-ce qu'Apollo annote sur la PR ?

Accepted Answer

Chaque PR arrive avec un résumé, le plan signé, le diff, le rapport de tests, et la liste des risques qu'Apollo a signalés pendant la construction. Les relecteurs font ce qu'ils font d'habitude ; les annotations rendent le diff plus facile à lire, pas plus rapide à fusionner.

Question 4

Quelles permissions Apollo demande-t-il sur mon dépôt ? Puis-je les restreindre ?

Accepted Answer

Apollo se connecte par le modèle de permissions de votre hébergeur de code, avec lecture+écriture sur les branches labo et lecture seule sur le reste du dépôt. Il ne peut pas pousser sur les branches protégées, ne peut pas fusionner, et ne peut pas s'octroyer de droits de fusion. La frontière de confiance est tenue par la couche de permissions, pas par une règle interne.

Question 5

Comment les données sont-elles isolées entre missions ?

Accepted Answer

Les branches labo sont éphémères, cloisonnées par mission, et démontées dans les 24 h après fermeture de la PR. Elles n'ont aucun secret de production ni accès à la base prod. Les logs et événements du fil d'activité sont partitionnés par mission et conservés 30 jours, supprimables sur demande.

Question 6

Que se passe-t-il quand Apollo reçoit un plan qu'il ne peut pas construire ?

Accepted Answer

Apollo réessaie avec le même plan jusqu'à trois fois sur des échecs transitoires. Sur un vrai blocage — critère d'acceptation en échec, contexte manquant, spec ambiguë — il s'arrête, pose une question de clarification dans le fil d'activité, et attend un humain. Il ne redéfinira pas le périmètre en silence.

Question 7

Peut-on exécuter Apollo sur un runner auto-hébergé ?

Accepted Answer

Au programme de la GA. Le runtime labo est déjà conçu pour tourner sur du compute contrôlé par le client ; l'intégration à l'hébergeur de code et le fil d'activité prendront en charge un runner auto-hébergé à la GA. Avant la GA, le runtime hébergé est la seule voie.

Question 8

À qui appartient le code écrit par Apollo ?

Accepted Answer

À vous. Apollo ouvre des PR dans votre dépôt. Rien ne sort de votre codebase. Nous n'entraînons pas de modèles sur votre code, et nous ne le conservons que le temps du contexte de travail nécessaire à la tâche.

Question 9

Combien coûte Apollo ?

Accepted Answer

L'accès bêta est gratuit pour la cohorte invitée. Des tarifs indicatifs figurent sur la page tarifs ; les tarifs définitifs sont arrêtés avant la disponibilité générale.

Question 10

Comment rejoindre la bêta ?

Accepted Answer

Postulez avec l'URL du site de votre équipe. Un relecteur humain répond sous 72 heures, dans tous les cas.

Ce qui construit votre logiciel ne dort plus.

Ce qu'est Apollo, en quatre cartes.

Pendant que vous n'êtes pas là.

Plan → signature humaine → build.

Six étapes. Un seul point de signature.

Brief en entrée. Plan en sortie.

Trois surfaces. Une source de vérité.

Ce que les équipes nous demandent sur Apollo.

Postuler à la bêta Apollo.