Introduction à CodeCourier

CodeCourier est une plateforme d’orchestration de workflows IA qui permet aux équipes de développement d’exécuter des agents de codage IA - Claude Code, OpenCode, Codex, Pi et d’autres - à l’intérieur de sandboxes cloud E2B isolées. Au lieu de faire tourner des assistants IA sur votre machine locale, CodeCourier provisionne à la demande des environnements Linux complets, exécute des workflows de développement multi-étapes et capture le savoir institutionnel que vos agents produisent en chemin.

Que vous ayez besoin d’une seule sandbox pour prototyper une fonctionnalité, d’un pipeline de conception et de revue à plusieurs itérations, d’un sprint entièrement automatisé qui transforme un plan de projet en pull requests, ou d’une tâche récurrente planifiée qui tourne au rythme de votre équipe - CodeCourier vous offre un plan de contrôle unique pour tout gérer.

Pourquoi CodeCourier

Exécuter des agents de codage IA en local crée une série de problèmes concrets : les environnements dérivent d’une machine à l’autre, les tâches longues bloquent votre poste de travail, les secrets fuient dans les shells locaux, et il n’existe aucune trace partagée de ce que l’agent a fait ou appris. CodeCourier répond à chacun de ces problèmes en déplaçant l’exécution des agents dans le cloud et en l’enveloppant d’une couche de workflow structurée.

• Isolation - Chaque sandbox est une VM Linux jetable propulsée par E2B. Les agents peuvent installer des paquets, modifier des fichiers et exécuter des commandes arbitraires sans toucher à votre machine ni aux autres projets.
• Reproductibilité - Les sandbox templates définissent l’image de base, les outils installés et les clients CLI préconfigurés. Chaque run démarre depuis un état connu, enrichi par les contextes de votre projet et les learnings approuvés.
• Observabilité - Chaque message échangé entre la plateforme et l’agent est stocké en temps réel. Vous pouvez relire la conversation complète, inspecter les verdicts étape par étape des checker agents, consulter les scores de qualité de chaque étape de run, suivre le statut des checks CI et tracer le coût et la consommation de tokens jusqu’à l’étape de run individuelle.
• Capture du savoir - Lorsqu’un agent découvre un piège, un pattern ou une préférence, CodeCourier l’extrait dans un enregistrement de learning structuré. Les learnings approuvés sont compilés en markdown et injectés automatiquement dans les sessions futures, de sorte que vos agents deviennent plus intelligents avec le temps.
• Collaboration d’équipe - Les projets prennent en charge les rôles owner, admin et member. Les membres de l’équipe partagent workflows, personas, contextes, assets et learnings au sein d’un projet tout en conservant leurs propres configurations de clés API.

Fonctionnalités clés

Projets

Un projet est l’espace de travail de plus haut niveau dans CodeCourier. Il rattache toute autre ressource - sandboxes, workflows, personas, contextes, assets, plans, learnings, issues et membres d’équipe - à un contexte unique. Les projets sont identifiés par un slug unique et peuvent, en option, être liés à un repository GitHub pour la gestion des branches et la création de pull requests.

Sandboxes

Les sandboxes sont des environnements Linux isolés provisionnés via E2B. Chaque sandbox possède un template configurable (qui détermine l’outil CLI préinstallé, comme Claude Code ou OpenCode), une allocation mémoire de 256 Mo à 8 Go, un nombre de CPU de 1 à 8 cœurs et un timeout de 1 minute à 4 heures. Les sandboxes peuvent être créées manuellement pour une exploration interactive ou démarrées automatiquement dans le cadre d’un run de workflow.

Workflows

Les workflows définissent des processus IA multi-étapes et répétables. CodeCourier prend en charge quatre types de workflow :

• Single Designer - Un seul agent exécute le prompt en une passe.
• Designer & Checker - Un designer agent écrit du code, puis un checker agent le relit. Si le checker rejette, le designer itère. Cette boucle se poursuit jusqu’à un nombre maximal d’itérations configurable.
• Custom Pipeline - Définissez une séquence arbitraire de types d’étapes (designer, checker, optimizer, prompter, investigator, evaluator, judge) avec des boucles optionnelles et des overrides de modèle par étape.
• Persona Pipeline - Chaînez des personas nommées, chacune avec ses propres instructions, ses sets de skills et sa configuration de modèle, en un pipeline séquentiel.

Personas

Les personas sont des configurations d’agent IA réutilisables limitées à un projet. Chaque persona possède un type (designer, checker, optimizer, prompter, investigator, planner, deep-dive, reviewer ou custom), un override de modèle optionnel, un niveau de thinking effort, des instructions personnalisées et des sets de skills, commands et scripts activés. Les personas vous permettent de standardiser le comportement des agents d’un run à l’autre - une persona “security reviewer”, par exemple, pourrait utiliser un thinking effort élevé avec des skills axés sécurité activés et des commands ciblées pour l’analyse statique.

Contextes

Les contextes sont des documents de system prompt et CLAUDE.md réutilisables et versionnés, qui peuvent être rattachés à des types de session spécifiques au sein d’un projet. Plutôt que de maintenir un unique system prompt global, vous pouvez créer des documents de contexte distincts pour chaque type de session - un pour les sessions de scan d’issues, un autre pour les sessions de learning, un autre encore pour les opérations de merge - et les mettre à jour indépendamment à mesure que votre projet évolue. Chaque document de contexte est versionné, de sorte que vous pouvez suivre l’évolution des instructions de vos agents dans le temps et revenir en arrière si nécessaire.

Assets : Skills, Commands et Scripts

Les assets sont des packages versionnés et publiables de façon indépendante, qui étendent le comportement de l’agent dans la sandbox. Il existe trois types d’assets :

• Skills- Des packages de savoir spécialisés composés d’un ou plusieurs fichiers (p. ex., un skill de patterns Convex pourrait inclure un fichier de référence, des snippets de code et des lignes directrices d’architecture). Les skills sont écrits sur le système de fichiers de la sandbox et référencés dans le contexte de l’agent.
• Commands - Des alias de commandes shell que les agents peuvent invoquer à l’intérieur de la sandbox. Les commands standardisent les opérations courantes comme lancer les tests, le linting ou invoquer un outillage spécifique au projet.
• Scripts - Des scripts exécutables qui peuvent être lancés dans la sandbox à des moments précis d’un workflow. Les scripts sont utiles pour la préparation avant le run, le nettoyage après le run, ou l’injection de contexte dynamique dans les sessions d’agent.

Tous les types d’assets sont sélectionnables par persona et par type de session, ce qui vous donne un contrôle fin sur les capacités auxquelles chaque rôle d’agent a accès.

Issues

Les sessions d’issues vous permettent de scanner une codebase à la recherche de bugs, de dette technique ou d’opportunités d’amélioration. CodeCourier analyse le repository et génère des issues structurées avec titres, descriptions, priorités et prompts suggérés. Lorsqu’une session d’issues produit des questions ou des hypothèses nécessitant une clarification, une answering session permet à l’agent IA de résoudre ces questions avant que l’implémentation ne commence. Les issues peuvent ensuite être exécutées individuellement ou regroupées en work chains ou sprint chains.

Sprint Chains

Les sprint chains sont des pipelines d’orchestration en batch qui exécutent plusieurs runs de workflow à travers des branches, en séquence. Contrairement aux work chains (qui traitent une liste d’issues sur une seule branche), les sprint chains définissent une plage de sprints, suivent un index de sprint courant et maintiennent un suivi de pull request par sprint. Les sprint chains sont idéales pour exécuter une roadmap planifiée de fonctionnalités ou de correctifs où chaque sprint produit sa propre PR.

Tâches récurrentes

Les tâches récurrentes vous permettent de planifier n’importe quel workflow pour qu’il s’exécute automatiquement selon un calendrier récurrent. Vous configurez la fréquence (quotidienne, un jour sur deux, hebdomadaire, bihebdomadaire ou mensuelle), le fuseau horaire ainsi que l’heure et la minute d’exécution. CodeCourier suit la prochaine heure d’exécution planifiée et la déclenche automatiquement. Les tâches récurrentes sont utiles pour les runs de tests nocturnes, les audits hebdomadaires de dépendances ou tout workflow répétitif que votre équipe souhaite automatiser.

Learnings

Les learnings capturent le savoir institutionnel issu des sessions d’agent. Chaque enregistrement de learning inclut une description, une condition de déclenchement, le comportement correct, une sévérité (critical, important ou minor) et une catégorie (preference, pattern, gotcha, tool ou architecture). Les learnings passent par un workflow de revue - pending, approved ou rejected - et les learnings approuvés sont versionnés et compilés en markdown, automatiquement inclus dans les prompts de sandbox futurs.

Scoring de qualité

Chaque étape de run inclut un score de qualité structuré qui évalue la sortie de l’agent sur six dimensions : correction, sûreté de typage, style de code, couverture de tests, complétude et un score composite qui les agrège. Les runs suivent un score de qualité global dérivé de leurs étapes. Les scores de qualité permettent aux équipes de surveiller la qualité des sorties dans le temps et d’identifier quelles configurations de workflow produisent les meilleurs résultats.

Checks CI

Les runs suivent le statut des checks CI via un objet ciChecks qui enregistre le statut global, le tableau des résultats de checks individuels et l’heure de la dernière interrogation. Cela vous donne une vue en direct de la réussite ou non du code généré par l’agent dans votre pipeline CI, sans quitter l’interface de CodeCourier.

Comment ça marche

Le flux typique à travers CodeCourier suit ce parcours :

1. Configurez votre projet - Créez un projet, liez votre repository GitHub, ajoutez les clés API pour E2B, Anthropic (ou OpenRouter / OpenAI) et GitHub, puis invitez votre équipe.
2. Mettez en place contextes et assets - Définissez des documents de contexte pour chaque type de session (issues, learning, merging, answering, evaluating, judging) et créez les assets skill, command et script que les agents utiliseront.
3. Définissez personas et workflows - Mettez en place les personnalités d’agent dont vous avez besoin (un designer rapide, un checker rigoureux, un evaluator qualité) et créez des blueprints de workflow qui les chaînent.
4. Exécutez - Déclenchez un run depuis un workflow, une issue ou un calendrier de tâche récurrente. CodeCourier dépêche un job en arrière-plan via Trigger.dev, qui provisionne une sandbox E2B, installe l’outil CLI configuré et lui transmet votre prompt avec le document de contexte actif et tous les learnings compilés.
5. Itérez - Pour les workflows multi-étapes, la plateforme gère automatiquement la boucle designer/checker, en créant de nouvelles sessions de sandbox pour chaque étape, en enregistrant chaque message en temps réel et en notant la qualité de la sortie à chaque étape.
6. Livrez - Une fois le run terminé, CodeCourier peut créer automatiquement une pull request sur votre repository GitHub lié, extraire les learnings de la session et notifier votre équipe. Le statut des checks CI est suivi après le merge.

Aperçu de l’architecture

CodeCourier repose sur quatre services centraux, chacun responsable d’une couche distincte de la plateforme :

• Frontend Next.js - Une application Next.js 16 avec App Router, server components et internationalisation via next-intl. L’interface est construite avec Tailwind CSS, les primitives Radix UI et les composants shadcn/ui, avec Framer Motion pour les animations.
• Backend Convex - Convex fournit la base de données, les subscriptions temps réel, les server functions (queries, mutations, actions) et le stockage de fichiers. Toute la logique métier - vérifications d’authentification, autorisation, validation des données - s’exécute dans des Convex functions. Le schéma définit des tables pour les utilisateurs, projets, sandboxes, workflows, runs, run steps, personas, contextes, assets, issues, sessions d’issues, learnings, tâches récurrentes, sprint chains, enregistrements d’usage, notifications et davantage.
• Sandboxes E2B - E2B fournit les machines virtuelles Linux isolées où les agents IA s’exécutent. CodeCourier gère le cycle de vie des sandboxes (create, pause, resume, kill) et communique avec la CLI de l’agent qui y tourne via le SDK E2B.
• Jobs Trigger.dev - Trigger.dev prend en charge l’orchestration des jobs en arrière-plan. Les opérations longues comme le provisionnement de sandbox, l’exécution de workflows multi-étapes, les sessions d’issues, les sprint chains et le déclenchement des tâches récurrentes sont traitées comme des tasks Trigger.dev, avec des callback secrets pour une communication sécurisée de retour vers Convex.

L’authentification est prise en charge par Clerk, qui fournit OAuth, e-mail/mot de passe et gestion des sessions. Les JWT Clerk sont vérifiés dans les Convex server functions pour appliquer l’autorisation par utilisateur et par projet.

Prochaines étapes

Prêt à démarrer ? Le guide de quickstart vous accompagne dans votre premier run en moins de dix minutes, ou plongez dans les core concepts pour une compréhension plus profonde des briques de la plateforme.