Concepts

Les termes en un coup d'œil#

Comment les éléments s'articulent#

flowchart LR
    Q["Squad Coach<br/>conseils uniquement, aucun état"] -.-> A
    A["init<br/>créer l’équipe"] --> B["Demande de travail<br/>recherche, plan, implémentation, revue"]
    B --> C["Livrables<br/>recherches, plans, changements, revues, docs"]
    B --> D["Mémoire de l’équipe<br/>decisions.md, history/, state.json"]
    D --> E["Nouvelle conversation ?<br/>reprise depuis les fichiers"]
    E --> B
    A -.-> F["promote<br/>facultatif : une équipe devient une fédération"]
      

HVE Squad et HVE Core#

HVE Core est une bibliothèque d'agents, de prompts, d'instructions et de compétences pour un travail d'ingénierie structuré : recherche, planification, implémentation, revue, exigences, architecture et plus encore. Utilisé directement, vous choisissez un agent à la fois.

HVE Squad s'appuie dessus. Il ajoute des coordinateurs qui lisent votre demande, choisissent les rôles qui doivent la traiter, délèguent aux agents HVE Core correspondants et consignent ce qui s'est passé. HVE Squad épingle une révision précise de HVE Core et maintient cette référence alignée avec chacune de ses versions, de sorte que les agents délégués sont ceux avec lesquels cette version a été testée.

Une règle pratique lorsqu'un comportement vous surprend : si la question porte sur le comportement d'un agent de recherche, de plan ou de revue lui-même, il s'agit d'une convention de HVE Core. Si elle porte sur les équipes, les profils, les packs, l'aiguillage, les approbations ou les fichiers que la squad écrit, il s'agit de HVE Squad.

Agents et compétences#

Un agent est un rôle doté d'une mission et d'outils. Une compétence est une procédure réutilisable qu'un agent charge lorsqu'il en a besoin, comme les compétences HVE Core de recherche, de planification, d'implémentation et de revue.

C'est pourquoi un roster présente deux formes. Un exécutant préfixé Squad, comme Squad Researcher, Squad Lead, Squad Implementor ou Squad Reviewer, est un agent léger qui charge la compétence HVE Core correspondante. D'autres rôles, comme le BRD Builder ou l'UX UI Designer, délèguent directement à un agent HVE Core. Ce choix est configuré explicitement dans le roster de l'équipe (team.md) ; le modèle ne le décide pas au fil de l'eau.

Vous ne sélectionnez vous-même que quelques agents. Les autres sont délégués pour vous :

D'autres agents spécialisés, comme ceux du rapport de gouvernance, de la recherche documentaire et des enseignements partagés, sont décrits dans Utilisation. Researcher, Lead, Implementor, Reviewer et les autres rôles ne sont jamais sélectionnés par vous : le coordinateur les délègue.

Équipes et fédérations#

Une équipe (la documentation dit aussi squad) est un roster d'agents qui partagent un plan, un journal de décisions et un historique. Elle vit dans votre dépôt sous .copilot-tracking/squad/ et est créée par init.

Une fédération réunit plusieurs équipes dans le même dépôt, côte à côte. Chaque équipe conserve son propre roster, ses décisions et son historique sous .copilot-tracking/squad/members/<name>/, et un registre (federation.md) ainsi qu'une table d'aiguillage (meta-routing.md) déterminent quelle équipe reçoit une demande. Vous travaillez avec une fédération par l'intermédiaire du Squad Federation Coordinator.

Commencez avec une seule équipe. Choisissez une fédération uniquement lorsque deux flux de travail ou plus ont des responsables, des livrables, des rythmes ou des limites d'accès différents, par exemple une équipe produit et une équipe plateforme qui livrent séparément. Une spécialité technologique n'est pas une raison de fédérer : c'est le rôle d'un pack. La règle de décision complète figure dans Profil, pack ou fédération ?.

Chaque équipe d'une fédération porte un nom unique qui est aussi le nom de son dossier et la valeur que vous transmettez avec squad=<name>. Les noms suivent le kebab-case : des mots en minuscules reliés par des tirets, comme azure-migration.

Les messages que vous envoyez#

Vous dialoguez avec la squad en sélectionnant un agent et en lui envoyant un message. Les messages se répartissent en quelques types, et seul le mot-clé initial les distingue. Aucune commande slash n'est nécessaire dans aucun hôte : les onglets d'hôte de cette documentation indiquent quel agent sélectionner et le texte exact à envoyer.

init, promote et demandes de travail#

Dans la conversation, init et promote demandent toujours votre confirmation avant d'écrire quoi que ce soit, et ils n'acceptent pas de mode. (Le mode Watch n'a aucun humain dans la boucle : il amorce ses propres équipes ; voir Utilisation.) Ajoutez du contexte après init pour aider le coordinateur à proposer un profil adapté, et précisez qu'il doit s'arrêter une fois l'équipe prête, afin qu'il ne se mette pas à travailler de lui-même :

/squad init Use the documents in docs/ as context. Set up one team for this planning work, and stop once the team is ready; I will send the work request next.

Comment écrire un message#

Un message comporte jusqu'à trois parties : un mot-clé facultatif (init ou promote) au début, des options facultatives name=value et votre demande en langage courant. Dans une conversation avec un agent, vous pouvez écrire la demande comme du texte ordinaire. L'enveloppe request="..." que vous voyez dans certains exemples est le nom de l'entrée que les fichiers de prompt utilisent pour transporter ce même texte ; elle est facultative ici.

/squad mode=autopilot Add input validation to the login form, with tests

Les options se placent avant ou après votre demande. Les exemples les mettent en premier, sur leur propre ligne, car c'est plus lisible.

Référence des messages#

Voici toutes les entrées qu'acceptent les prompts Squad livrés. Tout ce qui n'est pas listé ici est du texte ordinaire pour l'équipe.

Le Squad Coach n'accepte que request= et host=vscode|cli|app ; les deux sont facultatifs.

Profils et packs#

Un profil est l'équipe que vous constituez : une distribution de rôles prête à l'emploi pour un genre de travail. Les packs sont des spécialistes supplémentaires facultatifs que vous pouvez ajouter par-dessus. Vous choisissez exactement un profil et zéro ou plusieurs packs.

Si vous choisissez product, vous n'avez pas choisi une fonctionnalité : vous avez choisi une équipe composée d'un chercheur, d'un responsable de plan, d'un développeur, d'un testeur et d'un scribe, plus les rôles pour les exigences, la conception, la responsabilité produit, les présentations et les expériences. Un pack ne remplace jamais cette équipe ; il lui ajoute quelques spécialistes technologiques.

Choisir un profil#

Les membres exacts de chaque profil figurent dans Utilisation → Profils. Un profil est un ensemble de départ, pas un plafond : tout rôle de la distribution peut être ajouté plus tard en le demandant au coordinateur. En cas de doute, acceptez le profil que le coordinateur propose à partir de votre dépôt et de votre demande.

Les packs sont facultatifs#

Un pack ajoute les spécialistes d'une technologie sur laquelle repose votre projet : power-platform, m365-copilot, aws ou foundry. Ignorez les packs sauf si votre projet utilise cette technologie. La question d'initialisation peut lister tous les packs enregistrés, ce qui donne l'impression d'une recommandation ; c'est un menu, et chaque pack est facultatif. Ne choisir aucun pack est une réponse normale.

La plupart des clients permettent de répondre à une question avec vos propres mots au lieu de choisir une option listée. Utilisez-le lorsque vous ne savez pas ce qu'une option signifie : demandez au coordinateur de l'expliquer et en quoi votre projet en aurait besoin. Les packs peuvent être ajoutés ou retirés plus tard sans recréer l'équipe ni perdre son historique. Une application Power Platform qui nécessite aussi une piste d'audit est une seule équipe composée du profil compliance plus du pack power-platform.

Interactif et autopilot#

La squad peut vous solliciter avant chaque étape, ou exécuter tout le pipeline et ne vous demander que les décisions importantes. Vous choisissez à chaque demande de travail en ajoutant mode= au message ; il n'existe pas de paramètre séparé.

init et promote n'utilisent jamais de mode : vous confirmez chaque proposition. Le comportement complet est décrit dans Utilisation → Modes d'autonomie.

L'autopilot de la squad n'est pas l'approbation de votre client#

Deux couches distinctes déterminent quand on vous demande quelque chose. Le mode de la squad décide quelles décisions de travail elle vous soumet : un plan, un déploiement, le résultat final. Le niveau d'autorisation de votre client décide si Copilot demande avant de modifier un fichier, d'exécuter une commande ou d'appeler un outil. mode=autopilot ne change pas la seconde couche.

C'est pourquoi une longue exécution en autopilot peut s'interrompre sur des invites telles que conserver des modifications de fichiers ou autoriser une commande, alors même que la squad ne vous attend pas. Approuvez-les, ou élevez le niveau d'autorisation pour cette session. Dans VS Code, choisissez le niveau d'autorisation dans la zone de saisie du chat, ou envoyez /yolo pour contourner les approbations durant la session en cours (/disableYolo les rétablit) ; consultez Manage approvals and permissions. Dans Copilot CLI, utilisez /allow-all (alias /yolo) dans la session, ou démarrez avec --allow-all-tools ; consultez la référence des commandes CLI.

Où la squad conserve sa mémoire#

La conversation n'est pas la mémoire. La squad écrit ce qu'elle décide et fait dans des fichiers de votre dépôt, puis les relit au début de chaque tour. Vous n'êtes pas lié à une seule fenêtre de conversation : le contexte voyage avec le dépôt.

Le dossier d'état#

Tout se trouve sous .copilot-tracking/squad/ (ou members/<name>/ pour un membre de fédération) :

Une fédération ajoute federation.md et meta-routing.md au niveau supérieur, et chaque membre conserve les mêmes fichiers dans son propre dossier. Comme decisions.md et les fichiers d'historique sont en ajout seul, ils servent de piste d'audit de la manière dont un résultat a été obtenu.

Où vont les livrables#

Chaque rôle écrit son artefact dans un dossier fixe, afin que la squad puisse vérifier qu'une étape a bien produit son résultat. L'entrée d'historique de l'agent indique le fichier écrit sur sa ligne Deliverable:.

Dans une fédération, chaque emplacement .copilot-tracking/ passe sous le dossier du membre, par exemple .copilot-tracking/squad/members/product/plans/. Seuls docs/ et outputs/ restent à la racine du dépôt, car la documentation publiée et les sorties de données appartiennent à l'ensemble du dépôt. Les rôles qui renvoient leurs constats au coordinateur plutôt qu'un fichier, comme le gestionnaire de coûts et le déployeur, sont consignés dans l'historique.

Changer l'endroit où un rôle écrit#

1. Ouvrez .copilot-tracking/squad/team.md (ou le team.md propre au membre dans une fédération).
2. Trouvez la ligne du rôle et modifiez sa cellule Deliverable Root. Utilisez un chemin relatif à la racine du dépôt, dans la même forme que les autres cellules, par exemple research-notes/.
3. Envoyez votre prochaine demande. Le coordinateur transmet à chaque agent la racine lue dans la ligne du roster ; la modification s'applique donc dès la délégation suivante, sans réinitialisation, et une actualisation du roster conserve votre modification. L'agent qui écrit crée le dossier ; vous n'avez pas à le faire.

N'utilisez ni .., ni chemin absolu, ni ~. Dans une fédération, gardez une racine personnalisée dans docs/, outputs/ ou le dossier du membre : un livrable écrit hors du dossier de son équipe a quitté sa racine, et le coordinateur le traite comme une étape en échec et la relance. Ne modifiez à la main que cette colonne : les autres colonnes sont gérées par la squad ; demandez donc au coordinateur lorsque vous voulez changer un rôle, un modèle ou un nom.

Après la délégation suivante, ouvrez le history/<agent>.md de l'agent et vérifiez que son chemin Deliverable: est celui que vous avez défini. Un artefact trouvé au chemin par défaut de l'agent signifie que la délégation n'a pas respecté le roster ; signalez-le plutôt que d'accepter cet emplacement.

Ouvrir une nouvelle conversation est sans risque#

Le coordinateur lit le dossier d'état au début de chaque tour ; une nouvelle conversation reprend donc exactement là où les fichiers indiquent que se trouve le travail. Ouvrir une nouvelle conversation après init et entre les grandes étapes est sans risque et souvent préférable : une conversation neuve garde un contexte réduit, et rien n'est perdu. Dans la nouvelle conversation, ouvrez le même dossier de dépôt, sélectionnez de nouveau le même agent et dites ce que vous voulez ensuite, par exemple Résume où nous en sommes et poursuis depuis la dernière étape terminée.

Vous n'avez jamais besoin de répéter init : il ne s'applique que lorsqu'aucune équipe n'existe encore (ou, avec une fédération, pour ajouter une équipe). Les fichiers sont des fichiers ordinaires de votre dépôt ; vous pouvez donc les valider ou copier le dossier pour continuer sur une autre machine ou transmettre le projet à un collègue.

Ce dont la squad part#

Aucune structure de dossiers n'est exigée. L'équipe part de votre dépôt et de tout ce que vous lui indiquez : exigences, spécifications, transcriptions, base de code existante. Nommez ces fichiers dans votre message, comme le fait l'atelier pratique avec son dossier knowledge-docs/. Ce dossier est l'entrée propre à cet atelier, pas une organisation que HVE Squad vous demande de créer.

Lorsqu'une exécution repose sur des entrées écrites, l'étape de contrôle des exigences les vérifie avant la planification. Lorsque rien n'est encore écrit et que votre équipe est product ou full, l'étape de découverte propose un court entretien qui produit le brief. Voir Étape de découverte et Contrôle des exigences en entrée.

Squad Coach#

Le Squad Coach est un agent de conseil seul. Il lit le code et la documentation de la version que vous avez installée, examine votre projet et répond par une recommandation et un parcours de messages prêts à copier. Il n'initialise jamais d'équipe, ne délègue aucun travail, n'écrit aucun fichier et ne modifie pas votre configuration.

• À qui il s'adresse : toute personne qui débute avec HVE Squad, ou qui hésite sur la forme d'équipe, le profil, les packs ou le message adaptés à un objectif. Il fonctionne avant toute équipe.
• Quand l'ignorer : vous savez déjà ce que vous voulez (initialiser une équipe, puis envoyer une demande de travail), ou vous suivez un parcours figé comme l'atelier pratique, qui utilise volontairement des messages fixes afin de pouvoir comparer les résultats.
• Les mots qu'il emploie : les termes de cette page. Si l'un d'eux vous est nouveau, lisez sa section ici ou demandez au Coach de l'expliquer simplement avant de continuer.

Consultez Bien démarrer → Squad Coach pour savoir comment ouvrir une conversation dans votre client.

Autres mots que vous rencontrerez#