Curie : la plateforme open source auto-hébergeable qui transforme les agents de code en collègues

Pour qui c'est fait

• Pour les équipes de développement qui veulent la collaboration IA sur leur propre infrastructure : Curie est une plateforme open source auto-hébergeable, qui s'exécute dans votre infrastructure et transforme les agents de code en collègues à qui confier des tâches et dont valider les livrables.
• Le scénario central : « déléguer une issue GitHub et récupérer une implémentation à relire ». Curie prend en charge l'implémentation et la revue de l'issue et renvoie une pull request ou merge request qui attend l'acceptation de l'équipe.
• Cela convient aussi à la collaboration opérationnelle Kubernetes : les vérifications Kubernetes en lecture seule s'exécutent immédiatement, les opérations de mutation configurées demandent une approbation humaine — un bon choix pour confier les tâches de routine à faible risque comme les inspections et les diagnostics.
• Pour les équipes qui veulent garder l'approbation entre des mains humaines : les opérations de mutation configurées exigent une nouvelle approbation humaine, et c'est vous qui configurez quelles actions nécessitent une approbation préalable.
• Les équipes qui maintiennent déjà leur agent de code peuvent l'adopter avec la commande officielle curie init --adopt ./my-existing-agent.
• Quand ce n'est pas adapté : une machine qui ne peut pas exécuter Docker, ou l'impossibilité d'obtenir un identifiant de modèle Anthropic ou OpenRouter — chaque prérequis de la liste officielle est indispensable.

Une première tentative en 3 minutes

Prérequis : une machine avec Docker déjà en cours d'exécution, kind, kubectl et Helm installés, ainsi qu'un identifiant de modèle Anthropic ou OpenRouter. S'il manque un seul de ces éléments, impossible de démarrer selon les instructions officielles.

Exécutez le script d'installation officiel dans un terminal :

curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash

Le script provient de la branche main du dépôt Curie ; une commande en pipe exécute un script distant directement avec vos droits utilisateur — si cela vous gêne, téléchargez-le d'abord et examinez son contenu avant de l'exécuter.

Pour la première tentative, choisissez la voie à faible risque : prenez une issue du dépôt à la description claire et au périmètre réduit, et déléguez à Curie l'implémentation et la revue. À la fin, il renvoie une pull request ou merge request qui attend l'acceptation de votre équipe. Le signal de succès est clair : vous recevez sur votre plateforme d'hébergement de code le PR/MR produit et pouvez passer en revue les changements un par un.

La façon de saisir les identifiants de modèle après l'installation, ou de rattacher votre compte d'hébergement de code, n'est pas décrite pas à pas dans les instructions officielles ; fiez-vous aux messages du script et à la documentation du dépôt.

Cas d'usage

Cas 1 : transformer une issue en PR à relire. Situation : une issue d'implémentation au périmètre clair s'accumule dans le dépôt de l'équipe sans que personne puisse s'en occuper à temps. Lancement : déléguez l'issue à Curie, ce qui correspond au flux officiel « déléguer l'issue pour implémentation et revue ». Déroulé et résultat : à la fin, il rend un PR/MR et vous relisez les changements un par un sur votre plateforme d'hébergement ; le point final vérifiable est d'obtenir un PR/MR qui attend l'acceptation de l'équipe.

Cas 2 : inspection Kubernetes en lecture seule. Situation : vous voulez connaître l'état actuel du cluster sans passer par tout le cycle d'approbation de changement pour une simple vérification de routine. Lancement : demandez à Curie une vérification Kubernetes en lecture seule, qui utilise exactement les outils Kubernetes en lecture seule décrits officiellement. Déroulé et résultat : les opérations en lecture seule s'exécutent immédiatement, sans approbation supplémentaire ; si vous demandez ensuite une opération de mutation configurée, il demande d'abord une nouvelle approbation humaine avant de continuer. Gardez la première inspection en lecture seule et vous n'aurez aucune attente d'approbation ; pour observer l'étape d'approbation, ajoutez une requête de mutation et l'invite d'approbation apparaîtra. Quels outils en lecture seule sont proposés et comment les appeler n'est pas détaillé dans les notes officielles.

Limites d'utilisation

• Prérequis d'environnement : Docker en cours d'exécution, kind, kubectl et Helm en place, plus un identifiant de modèle Anthropic ou OpenRouter ; les exigences d'OS et d'architecture matérielle ne sont pas précisées par la source officielle.
• Effets de bord et points de confirmation : les outils Kubernetes en lecture seule s'exécutent immédiatement ; les opérations de mutation configurées demandent à chaque fois une nouvelle approbation humaine ; le produit d'une implémentation déléguée est un PR/MR qui attend l'acceptation de l'équipe. Ce que le script d'installation crée sur votre machine et quels répertoires il occupe ne sont pas listés officiellement — vous pouvez examiner le contenu du script avant de l'exécuter.
• Lieu d'exécution : une plateforme auto-hébergée, qui tourne dans votre propre infrastructure.
• Adopter un agent existant : la commande officielle curie init --adopt ./my-existing-agent est fournie ; la documentation officielle ne précise pas ce que la commande conserve de l'agent existant. L'initialisation et la configuration au-delà ne sont pas développées dans les instructions officielles.
• Ce qu'il faut vérifier dans le dépôt avant d'agir : les étapes de configuration des identifiants après l'installation, la façon de raccorder votre compte d'hébergement de code, la liste complète des outils en lecture seule disponibles et des opérations de mutation configurables, la prise en charge de fournisseurs de modèles autres que ces deux-là, et la liste exacte des agents de code compatibles. Vérifiez chaque point auprès de la documentation du dépôt avant de vous lancer.