Acepe : piloter plusieurs agents IA et livrer jusqu’à la PR dans une seule app
📌 Acepe est une application desktop pensée pour exécuter, coordonner et superviser des agents IA sur de vrais projets, avec une logique de contrôle qualité intégrée plutôt qu’une simple conversation. L’idée est simple : garder la puissance de Claude Code, Codex, Cursor Agent, OpenCode (et d’autres agents compatibles) tout en rendant visibles les actions, les fichiers modifiés et le chemin jusqu’au commit et à la pull request.
Dans un flux “agents partout”, le problème n’est pas de lancer un agent : c’est de garder la main sur ce qu’il fait, de comparer ce qui a changé, d’éviter les modifications silencieuses et de revenir en arrière proprement. Acepe se place comme un environnement dédié à cette boucle complète : session longue, exécution d’outils, historiques, checkpoints, diffs et intégration Git au même endroit.
Concrètement, Acepe vise le travail en parallèle. Plusieurs sessions d’agents peuvent tourner côte à côte sur plusieurs dépôts ou plusieurs tâches, sans perdre le contexte : historique de conversation consultable, reprise d’une session, bifurcation d’un fil, et une organisation qui ressemble plus à un poste de pilotage qu’à des onglets dispersés.
Le gain le plus tangible arrive au moment où l’agent “a fait quelque chose”. Au lieu de deviner ce qui a été touché, l’interface met en avant les changements, leur ampleur, et un affichage de diff lisible. Cela transforme l’agent en producteur de propositions vérifiables : on relit, on accepte, on rejette, on isole un fichier, on revient à un point de contrôle, puis on prépare le commit.
Au milieu, Acepe ajoute des garde-fous autour des actions sensibles. L’idée est d’avoir des permissions fines pour les types d’outils (lecture, écriture, terminal, web) et une file d’attente de demandes à valider. Ce mécanisme évite le “tout auto” ou le “tout manuel” : l’objectif est d’autoriser ce qui est répétitif, et de bloquer ce qui mérite une validation explicite.
Points clés
🧭 Orchestration multi-agents : plusieurs sessions, plusieurs projets, sans perdre le fil
🔎 Visibilité : historique des tool calls, entrées/sorties, timings, et traçabilité
🧾 Revue de code intégrée : diffs lisibles, stats de changements, navigation par fichiers
⏪ Checkpoints : snapshots de l’état des fichiers, comparaison et retour ciblé
🔐 Permissions : approbation/deni/auto-approbation selon le type d’action
🚢 Livraison : branches, staging, commits et pull requests depuis la même interface
Acepe pousse aussi une approche “workflow d’ingénierie” plutôt qu’un chat. Dans ce cadre, une session d’agent n’est pas un résultat final, c’est une séquence d’actions : recherche, lecture, modifications, itérations, puis préparation d’un changement propre. Les checkpoints servent à capturer des états intermédiaires pour comparer ce qui évolue, revenir sur un ensemble de fichiers, ou annuler une piste sans casser le reste.
L’intégration Git devient alors un passage naturel. Quand l’agent propose des modifications, l’outil n’attend pas que tout soit parfait : il facilite l’inspection, le découpage et la mise en forme du changement. Cela convient bien aux tâches où la qualité dépend du contrôle : refactor ciblé, migration, corrections, ajout de tests, nettoyage de dette technique, ou implémentation incrémentale sur plusieurs sous-modules.
Sur le volet “interface”, Acepe se présente comme une app native avec des panneaux redimensionnables et une organisation multi-projets. Un terminal intégré permet de garder l’exécution au même endroit que la session d’agent, et un panneau web sert à vérifier une UI, ouvrir une doc ou reproduire un comportement. L’objectif est d’éviter les allers-retours permanents entre éditeur, navigateur, terminal et fenêtres d’agents.
L’écosystème d’agents est un point important : Acepe n’impose pas un unique fournisseur. L’idée est de connecter des agents existants et de choisir par session le modèle ou le mode, selon le besoin : génération rapide, correction précise, exploration, ou itération plus longue avec contraintes. Cette séparation “interface de supervision” / “agent d’exécution” rend l’outil pertinent même si les agents favoris évoluent.
Pour démarrer, l’usage typique consiste à installer Acepe, ajouter un ou plusieurs agents, puis ouvrir un dépôt. Ensuite, une session se conduit comme une tâche : donner l’objectif, laisser l’agent agir, valider les demandes d’outils au besoin, puis relire les fichiers modifiés. La valeur se mesure surtout quand plusieurs tâches tournent en parallèle : une session peut générer une proposition pendant qu’une autre attend une validation, et l’interface doit signaler clairement laquelle requiert une attention humaine.
Côté confidentialité et contrôle, Acepe se positionne comme un client local qui orchestre des agents plutôt qu’un service qui “absorbe” le projet. Les garde-fous (permissions, file d’attente, historique d’exécution) servent justement à limiter les surprises : ce qui compte est de pouvoir expliquer ce qui a été fait, et de retrouver le pourquoi et le comment d’une modification.
Sur la compatibilité, l’outil vise un modèle simple : si un agent parle un protocole d’intégration supporté, il devient un “runtime” que l’interface peut lancer et superviser. Cela rend possible de mixer des agents selon la tâche, ou de passer de l’un à l’autre sans reconstruire tout le flux de travail. À retenir : l’intérêt n’est pas seulement d’avoir “plus d’agents”, mais d’avoir une supervision cohérente quand les tâches, les dépôts et les changements deviennent nombreux.
Au final, Acepe vise ceux qui veulent exploiter des agents IA sans perdre la rigueur : visibilité, contrôle des changements, points de retour, et un chemin propre jusqu’au commit et à la PR, le tout dans une interface unique.
