Spotify Xirp : centre de contrôle des agents de code

Si vous n’avez qu’une session de programmation ouverte dans un seul dépôt, vous n’avez pas besoin d’un nouveau centre de contrôle. Un terminal, un agent et une branche Git propre suffisent souvent.

La situation devient confuse dès que Codex développe une fonction, que Claude Code analyse un bug et que Gemini explore en parallèle une deuxième idée. Quel agent attend une autorisation ? Dans quelle branche se trouvent les modifications ? Quelle session appartient à quel projet ? Et comment empêcher deux agents de modifier simultanément le même checkout ?

C’est précisément le problème que Xirp veut résoudre. Le nom vient de Spotify, mais il n’a rien à voir avec la musique, les playlists ou l’application Spotify. Xirp est une application macOS destinée au travail avec des agents de programmation basés sur l’IA. Elle rassemble projets, terminaux persistants, worktrees Git, fichiers, règles et skills dans une seule interface.

Cela ressemble d’abord à un nouvel IDE avec IA, mais cette description est trop réductrice. Xirp n’intègre pas son propre modèle de langage et ne remplace ni Codex, ni Claude Code, ni Gemini. L’application organise les agents déjà installés et configurés sur le Mac.

Ce qu’est réellement Xirp

Spotify présente Xirp comme un agentic development environment. Plus simplement, il s’agit d’une surface de contrôle graphique pour plusieurs sessions locales d’agents de programmation.

Une session est un terminal persistant dans lequel un agent s’exécute. Elle peut appartenir à un projet local et à son propre worktree Git, ou démarrer sans contexte de projet. Lors de sa création, on choisit Codex, Claude Code ou Gemini, on décrit l’objectif et on décide si l’agent doit travailler dans le checkout existant ou dans un nouveau worktree.

Xirp continue d’utiliser les outils en ligne de commande natifs des fournisseurs. Identifiants, modèles, abonnements, autorisations et réglages propres à chaque agent restent dans leur configuration respective. Installer Xirp ne donne donc pas automatiquement accès à Claude, Codex ou Gemini et n’ajoute aucun quota de modèle.

Xirp est actuellement en bêta et fonctionne uniquement sous macOS. Le logiciel est propriétaire et non open source. Spotify exige une adresse e-mail professionnelle lors de l’inscription. Selon la FAQ, les adresses personnelles de services comme Gmail, Yahoo ou Outlook.com ne sont pas acceptées.

Ce que Xirp peut faire concrètement

Son intérêt pratique ne vient pas d’un bouton spectaculaire. Il vient du regroupement, au même endroit, de plusieurs tâches aujourd’hui souvent séparées.

Projets et sessions persistantes

Un projet est d’abord un dossier local sur le Mac. Il peut s’agir d’un dépôt Git unique, d’un dossier sans Git ou d’un dossier parent contenant plusieurs dépôts. Xirp l’utilise comme répertoire de travail des sessions.

Les terminaux sont persistants. On peut fermer l’application, la rouvrir plus tard et reprendre une session. La vue du projet affiche les sessions actives et passées ainsi que leurs branches et worktrees. Des indicateurs signalent notamment si un agent travaille, attend une réponse ou a terminé. Des notifications peuvent prévenir lorsqu’une session demande de l’attention.

Ce n’est pas spectaculaire, mais c’est précieux au quotidien. Avec trois ou cinq tâches parallèles, la question la plus difficile n’est souvent plus de savoir si un agent peut écrire du code. Il faut surtout savoir quel agent fait quoi et où se trouve son résultat.

Des worktrees Git plutôt que plusieurs agents dans le même checkout

Pour une nouvelle session, Xirp peut créer un worktree Git dédié avec une branche et un répertoire de travail séparés. Plusieurs agents peuvent ainsi travailler sur le même dépôt sans réécrire simultanément les mêmes fichiers dans le même checkout.

Un worktree n’empêche pas les conflits par magie. Si deux branches modifient la même fonction de manière différente, il faudra toujours comprendre et résoudre le conflit plus tard. Les modifications accidentelles en dehors du worktree ne sont pas automatiquement bloquées non plus. L’isolation organise le travail, mais elle ne remplace ni la revue de code, ni les tests, ni la protection des branches.

Lors du nettoyage, Xirp traite volontairement la session, le worktree et la branche comme trois éléments distincts. C’est logique, car fermer un terminal ne doit pas supprimer automatiquement un checkout contenant des modifications non validées.

Terminal, fichiers, Git et plusieurs agents dans une seule vue

La vue de session est un terminal interactif. On peut répondre, autoriser des permissions et utiliser les commandes de l’agent exactement comme dans la CLI native. On peut aussi rechercher et modifier des fichiers, examiner les diffs, consulter branches et commits, et ouvrir un éditeur ou un terminal externe dans le bon worktree.

La vue en grille place plusieurs terminaux actifs côte à côte. Elle est particulièrement utile lorsque deux sessions travaillent et qu’une troisième attend une décision. Il est également possible de bifurquer une conversation pour explorer une autre approche sans abandonner le fil initial.

Selon la documentation, on peut passer à un autre agent installé pendant une session. Le répertoire de travail et l’état du projet restent disponibles. Xirp ne traduit toutefois pas les réglages propres à chaque agent. Passer de Claude Code à Codex ne garantit donc pas que chaque détail de configuration se comporte automatiquement de manière identique.

Règles et skills réutilisables

Xirp affiche les fichiers d’instructions globaux et propres aux projets, comme AGENTS.md ou CLAUDE.md. L’application détecte aussi les skills réutilisables dans les dossiers pris en charge. Un skill peut par exemple décrire un contrôle de version, une migration ou une procédure de vérification fixe.

Cette partie est plus importante qu’elle n’en a l’air. Un agent privé de règles locales peut produire un code syntaxiquement correct tout en violant les conventions du dépôt. Xirp n’améliore pas la qualité de ces règles, mais il rend plus visibles les instructions et les procédures répétables associées au projet.

Un flux de travail réaliste

Imaginons qu’une application web nécessite une mise à jour importante. Une dépendance doit être actualisée, un bug existant analysé et la documentation adaptée. Dans Xirp, cela pourrait devenir trois sessions distinctes :

• Codex met à jour la dépendance dans son propre worktree et exécute les tests.
• Claude Code analyse le bug existant dans une deuxième branche.
• Gemini vérifie la documentation concernée ou explore une solution alternative.

Les trois terminaux restent visibles dans la grille. La vue Git montre quelle branche a modifié quels fichiers. Lorsqu’un agent attend une autorisation, il n’est plus nécessaire de chercher parmi plusieurs fenêtres de terminal. Les résultats peuvent ensuite être examinés, testés et fusionnés séparément.

C’est là que Xirp trouve son véritable intérêt. Il n’aide pas surtout avec le premier agent, mais avec le troisième, le cinquième ou le dixième flux parallèle. Dans son article de lancement, Spotify évoque même plus de 50 sessions parallèles et plus de 36 000 sessions exécutées en interne. Il s’agit de chiffres du fournisseur dans l’environnement Spotify, pas d’une étude indépendante sur la productivité.

Davantage de parallélisme ne signifie pas automatiquement davantage de productivité. Chaque agent supplémentaire produit des résultats, des questions, des conflits potentiels et des coûts. Lancer dix sessions oblige à comprendre et assumer dix états de travail. Xirp rend cette charge plus visible, mais ne la supprime pas.

Ce qu’ajoute Spotify Portal

Xirp fonctionne sans Spotify Portal. Terminaux persistants, projets locaux, worktrees, grille, fichiers, Git, skills et règles font partie de l’application autonome.

Portal ajoute la couche organisationnelle. Il maintient un catalogue logiciel contenant services, dépendances, responsables et autres métadonnées. Les Workspaces peuvent aussi réunir pages wiki, décisions techniques, liens, tâches, membres et sessions antérieures. Xirp peut lancer une session depuis une entité du catalogue ou un Workspace et fournir le contexte adapté via MCP.

L’objectif est de résoudre un problème bien connu dans les grandes organisations : un agent voit le dépôt, mais ne sait pas automatiquement qui possède un service en amont, pourquoi une décision d’architecture a été prise ou quelles contraintes une autre équipe a déjà documentées.

Portal peut fournir ce contexte à la demande au lieu de placer chaque document dans le prompt initial. Après une session, son historique peut être envoyé manuellement dans le Workspace. Les membres de l’équipe et les futurs agents peuvent alors poursuivre à partir des connaissances déjà acquises.

C’est l’aspect stratégiquement le plus intéressant de Xirp. C’est aussi celui qui dépend le plus de métadonnées bien entretenues, d’autorisations correctes et d’une bonne documentation. Un catalogue logiciel obsolète ne produit pas automatiquement un savoir organisationnel fiable. Il fournit simplement à l’agent un contexte périmé avec davantage d’assurance.

Pour les petites équipes, Portal peut donc représenter une infrastructure inutile. Pour une organisation avec de nombreux dépôts, des responsabilités changeantes et des tâches régulièrement dupliquées, une couche de contexte partagée peut apporter une vraie valeur.

Sécurité : local ne signifie pas automatiquement hors ligne

Spotify précise clairement que l’enregistrement d’un projet local n’envoie pas ses fichiers vers Portal. Xirp travaille avec le dossier du Mac et l’envoi d’une session vers Portal doit être déclenché manuellement.

Cela ne signifie pas que tout le flux de programmation reste hors ligne. L’agent choisi continue de communiquer avec OpenAI, Anthropic, Google ou un autre fournisseur configuré selon ses propres réglages. Les prompts, extraits de code et résultats d’outils transmis dépendent de la configuration native de l’agent. La gestion locale des projets par Xirp ne modifie pas ces flux de données.

Les envois de sessions contiennent plus que la conversation

Selon Spotify, envoyer une session vers Portal partage la conversation complète, les appels d’outils, les modifications de fichiers, le raisonnement de l’agent et les chemins de fichiers. Cela peut inclure des extraits de code et toute information traitée par l’agent pendant la session.

Point essentiel : Xirp ne supprime pas les secrets, identifiants, données personnelles ou contenus confidentiels avant l’envoi. L’utilisateur doit examiner l’historique et éviter d’envoyer les sessions problématiques.

Pour un usage en production, j’imposerais au minimum les règles suivantes :

• Démarrer les agents uniquement avec les droits nécessaires à la tâche précise.
• N’utiliser les modes autonomes et les contournements d’autorisation que dans des environnements clairement limités.
• Utiliser un worktree séparé et jetable pour les travaux risqués.
• Vérifier les transcripts avant chaque envoi vers Portal afin de détecter secrets et données clients.
• Conserver protection des branches, tests, revue de code et détection de secrets indépendamment de Xirp.

Les worktrees protègent contre les chevauchements accidentels dans le même checkout. Ils ne constituent pas une frontière de sécurité pour les commandes shell, l’accès réseau ou les autorisations sur le Mac. Ces aspects restent sous la responsabilité du sandbox et des contrôles d’approbation de l’agent concerné.

Données locales et télémétrie

Par défaut, Xirp stocke son état local dans ~/.xirp. Spotify décrit la télémétrie d’usage facultative comme pseudonyme et indique qu’elle exclut prompts, code, chemins de fichiers et texte libre. Elle peut être désactivée dans les réglages ou avec XIRP_TELEMETRY=0.

Ces déclarations sont positives, mais Xirp reste un logiciel propriétaire. Contrairement à un projet open source, son implémentation ne peut pas être entièrement examinée dans un code source public. Les organisations doivent donc évaluer non seulement l’interface, mais aussi les conditions contractuelles, les flux de données, la conservation et les permissions accordées aux agents connectés.

À qui Xirp est-il utile ?

Xirp n’est pas indispensable à toute personne qui ouvre occasionnellement un agent de programmation. Son intérêt dépend fortement du nombre de sessions, de dépôts et de personnes à coordonner.

Pour moi, la limite est simple : tant que les onglets du terminal, les noms de branches et une liste de tâches classique suffisent, Xirp reste une couche supplémentaire. Si plusieurs agents travaillent régulièrement dans des worktrees séparés et que la vue d’ensemble se perd, l’application répond à un problème réel.

Premiers pas et limites actuelles

Spotify propose des téléchargements de Xirp pour les Mac Apple silicon et Intel. Un script d’installation pour le terminal est également disponible. Comme avec tout installateur curl | sh, il est préférable d’examiner le script avant de l’exécuter ou d’utiliser le téléchargement direct de l’application.

Après l’installation, les principales étapes sont simples :

1. Créer un compte Spotify Technology avec une adresse e-mail professionnelle.
2. Installer et authentifier séparément les CLI des agents souhaités, puis configurer leurs autorisations.
3. Enregistrer un projet local dans Xirp.
4. Utiliser un nouveau worktree plutôt que le checkout principal pour la première vraie tâche.
5. Décrire l’objectif et les critères de fin assez clairement pour que l’agent sache quand la tâche est terminée.
6. Examiner les modifications et le transcript avant toute fusion ou tout envoi vers Portal.

La bêta présente encore des limites claires. Xirp ne fonctionne actuellement ni sous Windows ni sous Linux. Il n’existe pas de mode serveur ni de possibilité d’héberger des sessions distantes via SSH. Les envois automatiques de transcripts ne sont pas pris en charge, les sessions Workspace éligibles sont volontairement partagées manuellement. Les écrans et le comportement peuvent évoluer rapidement pendant la bêta.

La page du produit propose actuellement un accès bêta et annonce un essai gratuit de Portal. Je n’y verrais ni la promesse d’un produit gratuit à long terme, ni une indication sur les futurs prix pour les équipes. Une organisation qui adopte Xirp doit prévoir, en plus des abonnements aux modèles, les licences Portal, l’administration, le travail de revue et la gestion des sessions stockées.

Base et limites de cet article

Je n’ai pas testé Xirp dans un environnement de production multi-agents pour cet article. La description des fonctions et les informations de sécurité reposent sur la documentation officielle de Xirp, la FAQ, la page du produit et l’article de lancement de Spotify, vérifiés le 25 août 2026.

Je ne peux donc pas avancer d’affirmations fiables sur la stabilité, la consommation de ressources, la vitesse ou le gain de temps réel. Pendant une bêta, l’interface, les agents compatibles et les fonctions de Portal peuvent évoluer rapidement.

Ma conclusion

Xirp répond à un problème qui n’apparaît que lorsque les agents de programmation ne sont plus utilisés un par un, mais comme des travailleurs parallèles. Terminaux persistants, worktrees Git, indicateurs d’état, diffs et grille ne sont pas des idées révolutionnaires prises séparément. Leur regroupement dans une interface pensée pour les agents peut néanmoins rendre le quotidien beaucoup plus lisible.

L’ambition la plus importante réside dans la connexion à Spotify Portal. Si les services, les responsabilités, les décisions d’architecture et les sessions précédentes sont réellement maintenus et disponibles au bon moment, un agent ne doit pas repartir de zéro à chaque fois. C’est plus intéressant qu’un sélecteur de modèles supplémentaire.

Les risques se trouvent aussi dans cette connexion. Un transcript complet peut révéler bien plus qu’un commit. Un worktree n’empêche pas les commandes shell dangereuses. Et un projet local ne dit rien des données que l’agent choisi envoie à son fournisseur de modèles.

Je ressens déjà très clairement cette charge. Plusieurs projets tournent dans Codex, un terminal est ouvert à côté, mon Hermes Agent travaille lui aussi et d’autres questions et autorisations attendent dans la boîte de réception. Tout fonctionne en parallèle, tout finit par réclamer de l’attention, et je dois garder simultanément en tête le contexte, les priorités et les résultats. Cela ressemble parfois à une forme d’épuisement mental, si l’expression convient.

Le travail n’est pas seulement devenu plus rapide. Il m’arrive aussi par un nombre croissant de flux parallèles. Il y a peu, le goulot d’étranglement consistait à accomplir une tâche plus vite. Aujourd’hui, il s’agit souvent de réaligner cinq tâches en cours. Projets, sessions, questions, autorisations et résultats ont besoin d’un flux compréhensible, sinon la vitesse gagnée devient elle-même une charge.

De nombreux fournisseurs et projets open source tentent actuellement de résoudre ce nouveau problème de coordination. Xirp est une approche. Buzz en est une autre : le projet veut réunir personnes, projets et agents sous un même toit. J’ai récemment présenté plus en détail l’idée derrière Buzz et son espace de travail partagé.

Pour un développeur individuel avec une seule session, la CLI native reste probablement la voie la plus directe. Toute personne qui coordonne plusieurs agents, branches et projets en parallèle sur un Mac devrait surveiller Xirp. Non pas parce que Spotify aurait construit un meilleur agent, mais parce que la coordination des agents existants devient un problème d’outillage à part entière.

À la prochaine,
Joe

FAQ