Votre installation d’agent vit à six endroits et aucun ne s’entend. Une personne garde des compétences dans un dossier pour Claude Code. Une autre garde des invites dans Copilot. Les serveurs MCP, les programmes qui donnent à un agent accès à des outils et données extérieurs, siègent dans un fichier de configuration que quelqu’un a édité à la main et n’a jamais partagé. Un nouveau coéquipier clone le dépôt et obtient le code, mais pas l’installation d’agent qui rend le code facile à travailler.
Microsoft APM existe pour fermer cet écart. APM signifie Agent Package Manager. Il traite le contexte d’agent comme npm traite les bibliothèques de code. Vous déclarez ce dont un projet a besoin dans un fichier manifeste. Quiconque clone le projet roule une commande d’installation, et chaque pièce atterrit dans le bon dossier pour l’outil d’agent qu’il utilise.
Microsoft APM
Site officielUn gestionnaire de dépendances pour les agents IA, décrit par Microsoft comme un gestionnaire pour le contexte d’agent dans le style de npm. Cas d’utilisation principal : déclarer l’installation d’agent pour un projet une fois, dans un fichier qui voyage avec le dépôt, pour que chaque personne et chaque outil d’agent pris en charge parte des mêmes compétences, invites, instructions et serveurs d’outils.
Fonctionnalités clés : un manifeste pour toutes les pièces d’agent; un fichier de verrouillage qui épingle les versions exactes et les hachages de contenu; installations à partir de GitHub, GitLab, Bitbucket, Azure DevOps, Gitea et d’autres hôtes git; un balayage de sécurité à chaque installation; et un fichier de politique qu’une organisation peut appliquer quand des pièces sont installées.
Avantages : l’installation voyage avec le dépôt, les installations répétées produisent le même contenu, et une déclaration sert beaucoup d’outils d’agents à la fois. Limites : le soutien pour chaque pièce varie selon l’outil, le format du manifeste est encore un brouillon de travail dans la documentation, et le fichier de politique contrôle les installations seulement. Ce qu’un agent fait au moment de l’exécution reste avec l’outil d’agent lui même.
Un manifeste, beaucoup de bureaux : APM déploie les mêmes pièces déclarées dans les dossiers que chaque outil d’agent lit. Illustration : Dirty Static
Le problème est la dérive, pas le talent
Les outils d’agents se sont multipliés plus vite que les habitudes pour les partager. Une compétence est un dossier avec un fichier SKILL.md qui enseigne à un agent une tâche. Une invite est un flux sauvegardé. Un fichier d’instructions tient les règles pour un dépôt. Chaque outil lit ces pièces de son propre dossier, dans son propre format, et la plupart des équipes ont plus d’un outil en jeu.
Copier des fichiers à la main fonctionne pendant une semaine. Puis une copie change et les autres non. Deux personnes demandent au même agent le même travail et obtiennent un comportement différent, parce que leurs installations se sont silencieusement séparées. APM fait de l’installation une dépendance déclarée à la place, avec la même discipline que les équipes acceptent déjà pour le code : un manifeste, un fichier de verrouillage, et une révision quand l’un ou l’autre change.
C’est la même question d’approvisionnement que notre regard sur PlugVet a soulevée de l’autre côté. PlugVet note les compétences et les serveurs avant que vous leur fassiez confiance. APM concerne ce qui se passe après ce choix, quand une équipe a besoin des pièces choisies installées de la même façon, sur chaque machine, pour chaque outil.
Un manifeste, trois fichiers qui comptent
Le manifeste est apm.yml. Il siège à la racine d’un dépôt, comme package.json, et il nomme le projet et liste deux genres de dépendance : les paquets APM sous dependencies.apm, et les serveurs MCP sous dependencies.mcp. Un paquet peut être une seule compétence, un seul fichier d’agent, une extension, ou un paquet complet qui porte plusieurs pièces à la fois. Les épingles de version voyagent sur la chaîne de dépendance, alors une équipe peut tenir une compétence à une version fixe pendant que le reste bouge.
Rouler apm install fait le reste. Il résout l’ensemble complet de dépendances, y compris les pièces dont d’autres pièces dépendent. Il récupère chacune dans un dossier de cache local, détermine quels outils d’agents le projet utilise, et écrit chaque pièce dans le dossier que cet outil lit. Il écrit aussi le fichier de verrouillage.
| Fichier | Ce qu’il fait | Le committer |
|---|---|---|
apm.yml | Le manifeste. Déclare les paquets, serveurs MCP, scripts et cibles dont un projet a besoin | Oui |
apm.lock.yaml | Le fichier de verrouillage. Épingle la source, la version et le hachage de contenu exacts pour chaque pièce | Oui |
apm-policy.yml | Le fichier de politique optionnel. Règle ce qui peut être installé, appliqué quand les installations roulent | Oui, quand utilisé |
apm_modules/ | Le cache local des paquets récupérés | Non. APM le marque pour être ignoré par git, et les installations le restaurent à partir du fichier de verrouillage |
Le test de clonage est tout l’argument en une ligne. Selon le démarrage rapide, un coéquipier clone un dépôt, roule apm install à la racine, et obtient les mêmes pièces, aux mêmes versions, avec les mêmes hachages de contenu. Les dossiers déployés pour chaque outil sont aussi commis, alors l’installation reste visible en révision, pas cachée dans un cache.
Ce qu’APM gère
Microsoft appelle chaque unité de contexte d’agent une primitive. Le mot vaut la peine d’être gardé, parce qu’APM en gère huit genres, et un paquet peut en porter tout mélange.
Instructions sont des standards de codage et des lignes directrices, limités aux fichiers par un patron. Prompts sont des flux sauvegardés qu’un agent peut rouler. Agents sont des personnalités spécialistes avec leur propre portée et limites d’outils. Skills sont des guides de tâches dans le format SKILL.md. Hooks sont des scripts qui roulent à des points réglés dans une session, comme avant ou après un appel d’outil. Commands sont les fichiers d’invites dans la forme que les outils avec une palette de commandes attendent. Plugins sont des ensembles qu’APM déballe dans les pièces ci dessus au moment de l’installation. MCP servers sont déclarés dans le manifeste lui même, et APM écrit la configuration MCP pour chaque outil quand il installe.
Deux commandes siègent à côté d’installer. apm compile plie les instructions dans les fichiers de contexte partagés que les outils lisent, comme AGENTS.md et CLAUDE.md, et il peut placer un fichier ciblé à côté de chaque dossier au lieu d’un grand fichier à la racine. apm run roule des scripts nommés déclarés dans le manifeste, dans le style des scripts npm. Chaque script sort vers une commande d’exécution que vous avez déjà installée, comme copilot ou claude. APM ne livre pas ces environnements d’exécution. Il invoque celui que votre script nomme.
Neuf cibles principales, et le soutien n’est pas égal
Une cible est un outil d’agent vers lequel APM peut déployer. La liste principale compte neuf : GitHub Copilot, Claude Code, Grok Build, Cursor, OpenCode, Codex, Gemini, Windsurf et Kiro. Trois de plus, Antigravity, Hermes et Grok Bot, peuvent être nommés exprès mais ne sont jamais choisis par détection. APM trouve les cibles de trois façons, en ordre : un drapeau sur la commande, une liste targets: dans le manifeste, ou les dossiers déjà présents dans un dépôt, comme .claude/ ou .cursor/. Sans aucun signal du tout, l’installation s’arrête avec une erreur plutôt que de deviner.
Un concentrateur, neuf portes : chaque cible décide encore quelles pièces elle peut accepter. Illustration : Dirty Static
| Pièce | Copilot | Claude Code | Cursor | Codex | Gemini |
|---|---|---|---|---|---|
| Instructions | Yes | Yes | Yes | No | No |
| Prompts | Yes | No | No | No | No |
| Agents | Yes | Yes | Yes | Yes | No |
| Skills | Yes | Yes | Yes | Yes | Yes |
| Hooks | Yes | Yes | Yes | Yes | Yes |
| MCP servers | Yes | Yes | Yes | Yes | Yes |
Lisez le tableau comme un outil de planification, pas une liste de défauts. Une équipe qui vit sur les invites dans Copilot obtient une pleine valeur le premier jour. Une équipe répandue sur Codex et Gemini devrait construire son installation partagée autour des compétences et des serveurs MCP, les pièces qui voyagent partout, et garder les extras spécifiques aux outils dans des dossiers spécifiques aux outils. Notre profil de WordPress Studio a montré la même forme de l’intérieur d’une application : le harnais décide ce qu’un agent extérieur peut atteindre, et les outils honnêtes le disent dans un tableau.
Sécurité et politique, énoncées clairement
Installer des pièces d’agent signifie installer de la prose qui dirige un agent, et dans le cas des serveurs MCP, du code qu’un agent peut appeler. APM traite cela comme un risque d’approvisionnement par défaut. Selon la documentation, chaque installation balaye le contenu pour de l’Unicode caché, épingle les hachages de contenu dans le fichier de verrouillage, et bloque les serveurs MCP qui arrivent seulement comme une dépendance d’une dépendance, à moins que ces serveurs soient déclarés dans votre propre manifeste ou de confiance exprès.
Le fichier de politique ajoute le contrôle de l’organisation. apm-policy.yml est appliqué quand les installations roulent, et il couvre les serveurs MCP transitifs aussi bien que les directs. La politique coule du niveau entreprise au niveau organisation au niveau dépôt, et chaque niveau peut seulement resserrer ce que le niveau au dessus de lui a permis. La documentation pointe les organisations vers apm audit --ci pour barrer les constructions sur les mêmes règles.
Le mettre sur une machine
La CLI roule sur macOS, Linux et Windows. Homebrew est le chemin court sur un Mac. La documentation liste aussi un installateur d’interpréteur pour Linux et macOS, un installateur PowerShell pour Windows, et des installations Scoop, pip et d’archive manuelle pour les équipes qui en ont besoin.
brew install apm
apm init my-agent
apm install microsoft/apm-sample-package
Le paquet d’exemple dans la dernière ligne est le propre paquet de départ de Microsoft. C’est la façon la plus rapide de voir la forme d’une vraie installation : invites, agents, instructions et une compétence atterrissant dans les bons dossiers, avec le fichier de verrouillage écrit à côté du manifeste. De là, ajouter une pièce est une ligne dans apm.yml ou une commande d’installation nommant un dépôt et un chemin dedans.
Prix et plateformes
APM ne coûte rien. La CLI et le format de manifeste sont libres sous l’organisation microsoft sur GitHub, sous la licence MIT. Il n’y a aucun frais de registre hébergé et aucun frais par siège dans la documentation, parce qu’il n’y a aucun registre hébergé du tout dans le sens npm. Une chaîne de dépendance nomme un dépôt git, sur GitHub ou un autre hôte git, et APM le récupère de là avec votre propre accès git. Les équipes payent seulement pour les outils d’agents et les modèles qu’elles utilisent déjà.
Une note d’état compte ici. La documentation décrit le contrat du manifeste comme un brouillon de travail, et la page de schéma du manifeste porte la même étiquette. La forme en usage aujourd’hui est documentée en détail, mais un brouillon peut encore changer. Épinglez votre version APM dans la documentation d’équipe, lisez le journal des changements quand vous mettez à niveau, et laissez le fichier de verrouillage faire son travail entre les mises à niveau.
Ce qui fonctionne
- Une installation déclarée pour toute une équipe, livrée dans le dépôt qu'elle décrit
- Le fichier de verrouillage épingle les versions exactes et les hachages de contenu, alors les installations répétées correspondent
- Compétences, invites, instructions, agents, crochets, extensions et serveurs MCP partagent un système
- Fonctionne sur neuf outils d'agents principaux au lieu de verrouiller une équipe à un
- Balayages d'Unicode caché, épinglage de hachages et serveurs MCP transitifs bloqués par défaut
- Le fichier de politique donne aux organisations une vraie barrière au moment de l'installation, avec soutien d'audit CI
Ce qui ne fonctionne pas
- Le soutien pour chaque pièce varie selon la cible, alors la matrice a besoin d'être vérifiée avant un déploiement
- Le format du manifeste est encore étiqueté un brouillon de travail dans la documentation
- La politique s'arrête au moment de l'installation et ne contrôle pas le comportement à l'exécution
- Aucun registre central signifie que la confiance repose sur les dépôts qu'une équipe choisit de dépendre
- APM n'installe pas les environnements d'exécution d'agents que ses scripts appellent, alors chaque machine a encore besoin de ses propres outils
Laquelle devriez vous choisir
Adoptez APM maintenant si votre équipe partage l’installation d’agent par le folklore. Si les compétences vivent dans des messages de clavardage, les invites vivent sur un portable, et les configurations MCP diffèrent par personne, APM remplace cette dérive par un fichier qu’une équipe peut réviser. Commencez avec les compétences et un ou deux serveurs MCP, les pièces avec le soutien le plus large, et ajoutez le reste à mesure que vos outils le permettent.
Adoptez le si vous roulez plus d’un outil d’agent. Un constructeur solo qui change entre Claude Code et Cursor pour des travaux différents obtient le même gain à plus petite échelle. Une déclaration, deux déploiements, et aucune synchronisation manuelle quand une compétence s’améliore. Il se marie bien avec une habitude de vérification : notez une nouvelle pièce avec un répertoire comme celui dans notre profil PlugVet avant qu’elle mérite une ligne dans le manifeste.
Attendez si vous utilisez un outil, seul, avec une installation qui ne change jamais. APM règle un problème de partage et de dérive. Une seule installation stable a peu de dérive à régler, et le manifeste est un fichier de plus à entretenir. La même chose vaut pour les équipes qui ont besoin du contrôle à l’exécution comme leur sauvegarde principale. APM les aidera à gouverner les installations, et elles auront encore besoin des contrôles dans leurs outils d’agents pour le reste.
Réflexions finales
APM est peu glamour de la meilleure façon. Il ne promet pas un modèle plus intelligent ou un agent plus rapide. Il promet que l’installation d’agent dont une équipe a convenu est l’installation que chaque personne roule vraiment, sur chaque outil, après chaque clonage. Cette promesse avait besoin d’un manifeste, d’un fichier de verrouillage et d’une barrière de politique, et Microsoft a construit les trois sur des standards ouverts qu’il nomme dans la documentation : AGENTS.md, Agent Skills et MCP. L’étiquette de brouillon sur le format est la seule vraie prudence. Adoptez le pour la dérive qu’il tue aujourd’hui, épinglez le comme vous le pensez, et gardez vos contrôles à l’exécution où ils appartiennent, dans les outils eux mêmes.
Sources
- Ce qu’APM est, l’exemple de manifeste, les chemins d’installation, les réglages de sécurité et de politique par défaut, la licence : APM home, Microsoft
- Le flux consommateur,
apm init, l’installation d’exemple, le fichier de verrouillage et quoi committer : Quickstart, Microsoft - Les huit primitives, le catalogue des cibles, le placement de compilation et l’ordre de sélection des cibles : Primitives and targets, Microsoft
- Soutien par cible pour chaque pièce, dossiers de déploiement et signaux de détection : Targets matrix, Microsoft
- Scripts d’exécution et la règle qu’APM invoque des environnements qu’il ne livre pas : Run scripts, Microsoft
- Illustrations vedette et du corps : Dirty Static
FIN DE LA TRANSMISSION
Restez curieux. Remettez tout en question.


