Notre lecture
Augment Code convient aux équipes dont la difficulté est de comprendre un gros dépôt avant d'y toucher : un moteur de contexte indexe le code, et le changement peut partir de VS Code, JetBrains, de la CLI ou des agents Cosmos. Les points de validation restent aux ingénieurs, et la documentation ne détaille pas le traitement des dépendances : testez-le d'abord sur votre code.
Pourquoi tout commence par le dépôt
Avant de modifier du code sans risque, un assistant doit savoir ce que ce code touche. Pure Storage décrit ce problème dans une étude de cas publiée par l'éditeur : un dépôt monolithique en C++, Python et Go où, selon son CTO chargé de la sécurité et de la GenAI, une petite modification dans un pilote de périphérique peut avoir de larges effets ailleurs. Ses responsables techniques disent que Copilot apportait peu dans ce dépôt, et qu'une équipe transverse a retenu Augment après évaluation. C'est le récit du client, pas une comparaison indépendante.
La description d'Augment place le moteur de contexte au centre : des agents de code construits sur un moteur qui indexe de grandes bases de code. Ce moteur est cité dans le noyau de la plateforme Cosmos et dans la CLI Auggie ; la compréhension est donc partagée entre les points d'entrée, au lieu d'être reconstruite dans chacun.
Ce que l'indexation apporte, et la question des dépendances
L'exemple le plus concret de compréhension entre couches vient encore de Pure Storage. Son CTO affirme que d'autres outils ne savaient pas suivre une fonction encapsulée dans un wrapper C++ jusqu'à un appel de pilote de périphérique, alors que le moteur de contexte d'Augment le pouvait. C'est la déclaration d'un client sur un dépôt précis.
Les pages qui décrivent le moteur de contexte donnent son but, pas sa mécanique. La représentation des dépendances, la rapidité avec laquelle l'index reflète un nouveau commit et la gestion de plusieurs dépôts n'y sont pas expliquées : considérez ces points comme inconnus, et non comme absents.
Suggestion éditoriale, et non fonction de l'éditeur : avant de vous engager, choisissez une fonction d'une bibliothèque partagée par plusieurs services, demandez à Augment tous ses appelants et comparez avec votre propre recherche. Un oubli vous montre où un humain doit continuer à vérifier.
Modifier : IDE, CLI ou Cosmos
Il existe trois points d'entrée. Des extensions couvrent Visual Studio Code et les IDE JetBrains, la CLI Auggie amène l'agent et le moteur de contexte dans le terminal, et Cosmos lance des agents sur déclencheur ou selon un calendrier. Cosmos fournit des experts comme PR Author, qui prend la description d'une tâche et la conduit du premier commit à la fusion, et Tester, qui exécute le changement et publie les résultats avec captures d'écran. Les déclencheurs incluent GitHub, GitLab, Slack, Linear et Jira, et les agents tournent dans des bacs à sable gérés ou sur vos machines pour le code qui ne peut pas sortir.
MoneyGram illustre le parcours par l'IDE. Dans son étude de cas publiée par l'éditeur, un ingénieur explique avoir automatisé des migrations Spring Boot qui prenaient des semaines et durent désormais environ deux heures, en décrivant la migration et en demandant à l'outil de confirmer qu'elle est terminée. Le même récit mentionne des liaisons Jira et Confluence via des outils MCP dans IntelliJ et VS Code, et l'usage d'Augment pour expliquer du code inconnu sans courir après son auteur. Ce sont des résultats déclarés par une équipe, pas un benchmark.
Le travail change de forme : l'ingénieur définit le changement et la condition d'achèvement, l'outil fait les modifications répétitives. La documentation lue ne décrit pas de parcours ticket vers PR détaillé au-delà des experts Cosmos cités.
Où se fait la validation
Cosmos traite les points de contrôle comme un élément de conception : le travail s'arrête pour relecture et reprend à la réponse, et les actions importantes sont approuvées par une personne. Dans la boucle de revue de code, chaque pull request reçoit une première revue, pour que les ingénieurs seniors se concentrent sur l'intention et l'architecture. L'éditeur associe à cette boucle un chiffre de 66 % de délai de fusion en moins, sans préciser la population ni la référence : ne le lisez pas comme un benchmark.
La revue de code est disponible sur tous les forfaits et porte sur les pull requests GitHub. L'offre Enterprise ajoute des analyses d'usage, des listes d'utilisateurs autorisés, des connexions MCP vers Jira, Linear et Notion pour enrichir le contexte, l'installation sur plusieurs organisations, et des sièges et dépôts illimités.
Le CTO de Pure Storage décrit un projet personnel où un système construit à partir de spécifications formelles a passé plus de 1 000 tests sans qu'il lise le code. Notez d'où venait la confiance : la spécification qu'il avait écrite et les tests qui l'exerçaient, pas l'outil seul.
Ce que coûte un parcours
Standard coûte 20 $ par mois et Business 100 $ par mois, chacun au tarif unique pour 50 postes au plus, avec le même montant inclus en usage. L'usage couvre l'inférence des modèles, le Context Engine et le calcul Cosmos. Les modèles sont facturés au prix public du fournisseur plus 40 % de frais de service fixes, sans frais sur le calcul. L'usage inclus et les recharges sont mutualisés dans l'équipe, et les recharges restent valables 12 mois. Enterprise se négocie avec les ventes.
Conséquence : le coût suit l'activité, pas les effectifs. Un agent qui relit chaque pull request puise dans le même solde que les ingénieurs qui posent des questions dans l'IDE ; mesurez donc une semaine d'usage réel avant de choisir un forfait. Le support Standard et Business passe par la communauté et un portail de tickets ; le support dédié relève d'Enterprise.
Ce qui reste à la charge du développeur
Côté données, l'éditeur indique que le code des clients n'est pas utilisé pour entraîner les modèles par défaut et que les forfaits payants excluent l'entraînement par IA dans ses conditions commerciales. Il cite SOC 2 Type II et ISO 42001, et les clés de chiffrement gérées par le client ainsi qu'ISO 42001 figurent parmi les options Enterprise. Ce sont des déclarations de l'éditeur : demandez les rapports avant de vous y fier.
Le reste vous revient : formuler la tâche et ce que « terminé » signifie, lire le diff, approuver les actions importantes et vérifier que les tests exercent bien le comportement modifié. Le produit place les ingénieurs à des points de contrôle ; il ne décide pas à leur place de ce qui est correct.
Méthode et limites
2026-10-28
Cet état daté compte les entreprises distinctes disposant de preuves clients publiques. CONFIRMED désigne une étude de cas, un témoignage nommé ou une source de presse ; DECLARED, une déclaration de l’entreprise elle-même ; OBSERVED, une liste de clients publiée par un éditeur ; SIGNAL, une offre d’emploi. Les quatre niveaux comptent, avec des forces différentes. Les lignes retirées ou sans niveau sont exclues. Les exemples forment une sélection limitée, vérifiée dans les 90 jours. Les faits éditeurs sont sourcés et vérifiés dans les 60 jours. La couverture est inégale ; une preuve absente reste inconnue. Ces chiffres ne mesurent ni les parts de marché ni les performances. Les dates de collecte ne sont pas des dates d’adoption.
