Agents parallèles avec Gemini CLI : exécuter plusieurs tâches Gemini en parallèle

Une session Gemini CLI, c'est un seul agent qui travaille dans un seul répertoire. Dès que vous voulez lancer une deuxième tâche en parallèle — corriger un bug pendant qu'un refactoring tourne, écrire des tests pendant qu'une fonctionnalité est livrée —, vous ouvrez un autre terminal. Puis un troisième. En une heure, vous avez quatre onglets, quatre répertoires de travail, et aucune réponse claire à une question simple : quel agent fait quoi, et lequel vient de toucher le fichier que vous alliez modifier.

Lancer plusieurs tâches Gemini en parallèle n'a rien de compliqué au départ. Ce qui est difficile, c'est de s'y retrouver. Chaque instance est rapide prise isolément ; le coût, c'est la coordination, et c'est précisément ce que le terminal ne vous offre jamais.

Cet article détaille la mise en place manuelle d'agents Gemini CLI en parallèle, nomme le mode de défaillance qui guette à chaque étape, et montre à partir de quand un tableau de tâches prend le relais. Ce tableau de tâches, c'est Sharkly, une plateforme tout-en-un de pilotage et de gestion d'agents. Sharkly ne remplace pas Gemini CLI. Il ajoute une couche partagée de tâches, de Computers, de contexte et de revue autour des runtimes que votre équipe utilise déjà, pour que les exécutions parallèles restent assignables et traçables au lieu d'être éparpillées entre les onglets.

Ce que signifie « agents parallèles » avec Gemini CLI

Gemini CLI exécute un agent par processus. Il lit le répertoire courant, charge le fichier de contexte GEMINI.md s'il existe, et traite votre prompt dans cet unique arbre de travail. Aucun répartiteur intégré ne distribue un objectif à plusieurs sous-agents et ne fusionne leur travail à votre place.

En pratique, « agents Gemini parallèles » ne veut donc dire qu'une chose : plusieurs processus gemini lancés en même temps, chacun dans son environnement isolé, chacun sur sa propre tâche. Gemini CLI est open source et gratuit avec un compte Google personnel, et c'est précisément pour cela que certains en lancent quatre d'un coup. Le goulot d'étranglement n'a jamais été de les démarrer. Il est d'empêcher quatre exécutions indépendantes d'entrer en collision dans le même dépôt et de savoir, une heure plus tard, ce que chacune a produit.

C'est exactement le même problème de coordination qu'avec Claude Code ou Codex. Le runtime change ; le chaos, non.

La configuration manuelle, étape par étape

Voici la plus petite version fonctionnelle de Gemini CLI en parallèle, avec ce qui casse à chaque étape.

Étape 1 : donnez à chaque agent son propre arbre de travail. Ne faites pas tourner deux agents dans le même dossier. Utilisez un git worktree par tâche pour que chaque copie de travail soit physiquement séparée :

git worktree add ../repo-auth   feature/auth
git worktree add ../repo-tests  chore/tests
git worktree add ../repo-bugfix fix/login-redirect

Mode de défaillance si vous sautez cette étape : deux agents qui modifient la même copie de travail s'écrasent mutuellement en cours d'exécution. L'un reformate un fichier que l'autre est en train de modifier à moitié, et les deux laissent l'arbre dans un état que ni l'un ni l'autre ne souhaitait. Les worktrees donnent à chaque agent une branche propre et un répertoire propre. Nous approfondissons le sujet dans git worktrees pour les agents de codage IA.

Étape 2 : lancez un Gemini CLI par worktree. Ouvrez un terminal dans chaque répertoire et démarrez une session :

cd ../repo-auth && gemini

Pour les exécutions non surveillées, utilisez le mode non interactif afin que l'agent traite un seul prompt puis se termine :

cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."

Mode de défaillance : une session interactive s'arrête dès la première demande d'autorisation et attend. Vous revenez vingt minutes plus tard face à un agent qui n'a rien fait parce qu'il attendait un « oui ». Décidez à l'avance quelles exécutions sont interactives et lesquelles sont headless, et donnez à ces dernières un prompt qui inclut sa propre étape de vérification.

Étape 3 : isolez le contexte par tâche. Chaque worktree peut embarquer son propre GEMINI.md avec les règles propres à cette tâche : ce qu'il faut modifier, ce qu'il ne faut pas toucher, comment lancer les tests.

Mode de défaillance : un fichier de contexte unique partagé par tous les agents fait qu'une instruction destinée à la tâche d'authentification se retrouve dans la tâche de tests. Limitez le contexte à l'arbre auquel il appartient.

Étape 4 : surveillez le quota. Chaque instance en cours d'exécution puise dans les mêmes limites de compte. Quatre agents qui enchaînent un gros refactoring atteignent les limites de débit plus vite qu'un seul, et un agent bridé échoue en silence dans un onglet que vous ne regardez pas.

Mode de défaillance : une exécution se bloque sur une erreur de quota et vous ne vous en apercevez qu'en ouvrant cet onglet. Aucune vue partagée ne vous prévient qu'un agent s'est arrêté. Si vous cherchez à assigner les tâches les plus lourdes au bon modèle, quel modèle pour quelle tâche de codage aborde ce compromis.

À trois ou quatre tâches, ça fonctionne. De vraies branches, un vrai isolement, un vrai parallélisme, sans outillage supplémentaire.

Là où la configuration maison montre ses limites

La configuration manuelle ne casse pas au niveau de l'exécution, mais de tout ce qui l'entoure. Voyez ce qui se passe à mesure que le nombre de tâches augmente.

Vous perdez la carte. Avec quatre terminaux, vous gardez la vue d'ensemble en tête. À huit, répartis sur deux dépôts, c'est impossible. Quel onglet correspond à l'agent d'authentification ? La campagne de tests est-elle terminée ou morte sur une erreur de quota ? Surveiller des agents de codage en parallèle est une mission pour laquelle le terminal n'a jamais été conçu.

Les résultats se dispersent. Chaque agent laisse son travail sous forme de diff sur une branche et un mur de scrollback dans un onglet que vous finirez par fermer. Aucun enregistrement partagé ne dit ce que chaque exécution a modifié, pourquoi, ni si elle a passé ses propres tests. Quand un collègue demande ce qu'a fait la correction du login, la réponse se trouve dans un terminal qui n'existe plus.

La revue n'a pas de foyer. Des agents parallèles produisent des diffs parallèles, et chacun doit encore être validé par un humain. Lire quatre branches sans résumé, sans résultats de vérification et sans contexte prend plus de temps que les agents n'en ont gagné. La vitesse gagnée à l'exécution, vous la reperdez à la revue.

Voici le vrai dilemme, en toute honnêteté. Si vous lancez trois ou quatre tâches Gemini de temps en temps, gardez la configuration worktree ci-dessus : elle est simple et efficace, et un tableau de tâches ne serait qu'une charge inutile. Passez à un tableau de tâches quand les exécutions parallèles deviennent la norme : plusieurs agents, plus d'un dépôt, plusieurs personnes qui doivent suivre l'avancement, et une revue qui doit être traçable plutôt que mémorisée. Comparer les outils de gestion d'agents parallèles vaut alors la peine.

Ce qu'apporte un tableau de tâches

Un tableau de tâches change l'unité de travail : on passe d'« un onglet de terminal » à « une Task ». C'est ce seul basculement qui manque à la configuration maison.

Avec Sharkly, vous assignez une Task à un Agent propulsé par Gemini CLI. L'Agent prend la Task en charge, travaille dans un worktree isolé, et l'exécution, les blocages, les résultats et les échanges de suivi reviennent dans la timeline de la Task au lieu de disparaître dans des terminaux privés. Lancez-en plusieurs à la fois : chacun est une ligne que vous voyez, pas un onglet que vous devez retrouver. Gemini CLI continue de coder ; Sharkly gère l'assignation, les Computers connectés, le contexte et la revue pour chaque exécution.

La répartition des rôles reste claire. Les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et valident le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis, et chaque exécution revient avec un résumé des changements et ses propres résultats de vérification : accepter ou rejeter un diff prend un coup d'œil au lieu d'un travail d'archéologue. Contexte, avancement, blocages, résultats et revue humaine restent visibles de la demande à la mise en production.

Vous gardez ce que vous avez déjà. Sharkly ne vous demande ni d'abandonner Gemini CLI, ni de vous engager sur un seul runtime. Parce qu'il est neutre vis-à-vis des fournisseurs, le même tableau de tâches fait tourner des agents Claude Code et Codex aux côtés de vos agents Gemini : votre workflow survit à l'arrivée du prochain meilleur agent, quel qu'il soit. Cette neutralité est justement l'essentiel : vous pilotez vos agents au même endroit, sans changer d'écosystème à chaque nouvelle sortie.

La checklist à appliquer dès aujourd'hui

Passez-la en revue avant votre prochaine série de tâches Gemini en parallèle :

[ ] Un git worktree par tâche ; jamais deux agents dans une même copie de travail.
[ ] Un GEMINI.md propre à chaque tâche, et non un fichier unique partagé entre toutes.
[ ] Les exécutions headless utilisent gemini -p avec une étape de vérification intégrée pour ne pas se bloquer sur une demande d'autorisation.
[ ] Un plafond connu sur le nombre d'instances simultanées, pour que le quota partagé ne bride pas une exécution invisible.
[ ] Un endroit unique qui répond à « quel agent fait quoi, et qu'est-ce qui est terminé » sans ouvrir chaque onglet.
[ ] Chaque exécution terminée laisse un résumé des changements et des résultats de tests qu'un humain peut examiner, pas seulement un diff sur une branche.

Les quatre premiers points sont réalisables ce soir avec des worktrees et des terminaux. Les deux derniers sont là où une configuration manuelle atteint ses limites. Si vous faites déjà tourner plusieurs agents Gemini CLI en parallèle, Sharkly vous offre un endroit unique pour assigner leurs tâches, suivre leur avancement et examiner leurs résultats. Vous pouvez construire vous-même la couche de coordination, ou faire tourner vos agents de codage existants via Sharkly et passer directement à ce qui passe à l'échelle.