Au cours des derniers mois, GitHub s'est efforcé de faire évoluer Copilot, le faisant passer d'une simple boîte de saisie semi-automatique à quelque chose qui s'apparente davantage à une couche d'exécution pour le développement logiciel. Le dernier signe en date de cette évolution est /fleet dans Copilot CLI : une commande capable de diviser un objectif en plusieurs tâches plus petites, de lancer plusieurs agents à la fois, puis de regrouper les résultats.
Cela ressemble à un titre de démo de produit, mais c'est important car cela modifie la place de l'IA dans le flux de travail des développeurs. Au lieu de demander à un seul assistant de répondre, de réécrire ou d'expliquer une chose à la fois, les développeurs peuvent désormais demander une série de tâches coordonnées sur plusieurs fichiers, tests et documents. En d'autres termes, le terminal n'est plus seulement un endroit où exécuter des commandes. Il devient un lieu où orchestrer le travail.
Ce que GitHub a réellement lancé
Dans son annonce, GitHub décrit /fleet une commande CLI Copilot qui déploie plusieurs sous-agents en parallèle. L’orchestrateur décompose l’objectif en tâches indépendantes, identifie les éléments pouvant s’exécuter simultanément, attend la résolution des dépendances et synthétise le résultat final. Chaque agent conserve sa propre fenêtre de contexte, tandis que le système de fichiers partagé reste commun à l’ensemble de l’opération.
Cette distinction est importante. Un assistant de chat unique est doué pour la conversation. Une flotte d’agents est douée pour la coordination. Une fois que la tâche se transforme en un graphe de petites tâches, le goulot d’étranglement n’est plus la capacité du modèle à générer du texte ; c’est la capacité du système à gérer les dépendances sans créer de chaos.
GitHub présente également cela comme un workflow pratique en ligne de commande, et non comme un prototype de recherche. L'entreprise montre la commande utilisée directement dans Copilot CLI et prend également en charge un mode non interactif pour une utilisation via des scripts. Cela rapproche le travail agentique des outils auxquels les développeurs font déjà confiance : shells, scripts, fichiers locaux du dépôt, tests et habitudes de type CI.
Pourquoi cela va bien au-delà d’une simple fonctionnalité
Le véritable enjeu n’est pas que GitHub ait ajouté une nouvelle fonctionnalité d’IA. C’est que GitHub formalise un nouveau modèle mental pour le travail logiciel. Pendant des années, les outils de développement ont été optimisés pour une personne, une tâche, une fenêtre. Même lorsque les copilotes sont arrivés, ils correspondaient pour la plupart à ce schéma : une invite, une réponse, une modification.
/fleet suggère une approche différente. Les tâches logicielles modernes sont souvent déjà parallélisables. Une refactorisation peut toucher une couche de service, une suite de tests et un élément de documentation. La correction d’un bug peut nécessiter une modification du code, un script de reproduction et une liste de contrôle pour les relecteurs. Une migration peut nécessiter un travail distinct sur l’application, le système de build et les notes de déploiement. Les humains ont toujours décomposé mentalement ce travail ; désormais, l’outil peut effectuer lui-même une partie de cette décomposition.
C'est pourquoi cette annonce s'inscrit dans le cadre d'une histoire de workflow, et pas seulement d'une histoire de produit. Elle offre aux équipes un moyen natif d'exprimer les tâches sous forme d'ensembles de livrables indépendants. Si la consigne est suffisamment précise, l'agent peut paralléliser. Si la consigne est vague, le système revient à un travail séquentiel, qui est généralement plus lent et moins prévisible. La qualité de la consigne devient la qualité du graphe de tâches.
Ce à quoi les développeurs doivent prêter attention
Il y a trois implications pratiques pour les équipes logicielles.
- Les invites deviennent des plans. Une bonne
/fleetinstruction ressemble moins à une question qu'à une mission bien délimitée. Les équipes devront raisonner en termes de livrables, de dépendances et de limites. - La révision gagne en importance, et non l'inverse. Les agents parallèles peuvent agir plus rapidement, mais ils peuvent aussi diverger plus vite si l'objectif n'est pas clair. La supervision humaine reste essentielle pour garantir l'exactitude, le style, la sécurité et l'architecture.
- Les workflows de terminal deviennent partageables. Comme la commande peut être scriptée ou réutilisée, les meilleures invites peuvent finir par se comporter comme des conventions d'équipe : des modèles reproductibles pour les refactorisations, le triage, les mises à jour de la documentation et la génération de tests.
Ce dernier point passe facilement inaperçu. Dès que les workflows des agents sont encodés dans des commandes shell, ils commencent à ressembler beaucoup plus à une infrastructure qu’à une session de chat. Cela les rend plus faciles à enseigner, à documenter et à standardiser au sein d’une équipe.
Dans quels cas /fleet sera le plus utile
Les cas d'utilisation les plus pertinents sont ceux qui présentent des limites claires et un résultat visible. Pensez aux refactorisations multi-fichiers, aux refontes de documentation, à l'extension des tests, au nettoyage des dépôts et au triage des tickets. Ce sont des tâches pour lesquelles un humain sait déjà comment répartir le travail, et l'agent peut aider en exécutant ces répartitions plus rapidement.
C'est moins pertinent pour les tâches étroitement couplées ou mal définies. Si chaque fichier dépend de tous les autres, le parallélisme ajoute une charge de coordination. Si l'instruction est ambiguë, l'orchestrateur dispose de trop peu de structure pour répartir le travail en toute sécurité. Et si la tâche nécessite des identifiants privés, des données de production ou des actions irréversibles, l'équipe a toujours besoin de politiques et de garde-fous avant de privilégier la rapidité.
Cette prudence est importante car les outils de codage agentique s'éloignent de « aide-moi à écrire cette fonction » pour aller vers « aide-moi à atteindre cet objectif ». Dès qu'un outil commence à gérer plus d'une sous-tâche, il devient partie intégrante du problème de conception du système. Les équipes devront décider quelles catégories de tâches peuvent être déléguées en toute sécurité, lesquelles nécessitent une approbation et lesquelles doivent rester manuelles.
Pourquoi le timing est important
Cette fonctionnalité s'inscrit dans la même vague que la récente mise à disposition générale de Copilot CLI par GitHub et l'expansion constante des produits orientés agents de l'entreprise. La tendance est claire : GitHub parie que les développeurs ne veulent pas seulement de l'IA dans l'éditeur. Ils veulent de l'IA tout au long du parcours, de l'idée à la pull request, y compris dans le terminal où une grande partie de la coordination réelle se fait encore.
C'est un pari significatif pour les équipes de développement. Le terminal reste l'un des rares environnements où les développeurs peuvent combiner automatisation, révision, création de scripts et contexte local sans changer d'outil. Si Copilot peut s'y installer et se comporter comme un orchestrateur, il devient utile non seulement pour le codage, mais aussi pour l'ensemble du cycle de maintenance autour du codage.
Le message de GitHub est simple : la prochaine avancée en matière d'IA pour les développeurs n'est pas une nouvelle bulle de discussion. C'est un système capable de répartir le travail, de l'exécuter en parallèle et de restituer un résultat cohérent.
L'évolution majeure du produit
Pendant un certain temps, le marché de l'IA pour le codage a été principalement jugé sur la qualité du résultat : qui écrit le meilleur extrait de code, qui suggère la meilleure ligne suivante, qui crée la plus belle démo. Ces indicateurs comptent toujours, mais ils ne suffisent plus. À mesure que les assistants de codage passent en mode agent, les questions les plus difficiles portent sur l'orchestration, la confiance et la reproductibilité.
C'est pourquoi /fleet est intéressant, même si vous ne l'utilisez jamais exactement comme GitHub l'a imaginé. Cela indique que l'avantage concurrentiel passe de la génération brute à la conception de flux de travail. Les produits qui s'imposeront ne se contenteront pas d'écrire du code. Ils aideront les équipes à gérer la manière dont le code est décomposé, délégué, vérifié et fusionné.
En ce sens, la dernière initiative de GitHub concernant Copilot concerne moins une astuce de terminal que la forme future du travail d'ingénierie. L'assistant devient un gestionnaire de petites tâches. Le développeur devient le réviseur du plan. Et le terminal devient la salle de contrôle.
