Gortex : donner aux agents une carte exploitable du code

Un graphe plutôt qu'un fichier entier

Gortex se présente comme un moteur de code-intelligence pour agents et IDE. Il analyse le code dans un graphe persistant, puis l'expose par CLI, serveur MCP et interface Web. Le README affirme une analyse tree-sitter de 257 langages et des résolveurs intégrés, complétés par une résolution de niveau compilateur pour plusieurs langages, dont Python, TypeScript, Go, Java, Rust et Ruby. L'objectif déclaré est de faire demander à l'agent les sources utiles au lieu de lui faire lire un fichier complet. Cette approche change le contexte fourni, mais elle ne dispense pas de contrôler la qualité de l'index.

Un dépôt n'est pas toujours une frontière

Le support multi-dépôts est activé par défaut. Gortex construit un graphe commun où les références, chaînes d'appels et contrats peuvent traverser les limites de dépôt, avec une résolution présentée comme fondée sur des preuves. La section Cross-Repo API Contracts décrit la détection de routes HTTP et leur rapprochement entre fournisseur et consommateur. Les identifiants canoniques comme http::GET::/api/users/{id} servent à repérer des fournisseurs orphelins, des consommateurs orphelins et des incompatibilités. Cette vue est intéressante pour un système distribué, mais elle doit être confrontée aux conventions de vos frameworks.

Le cycle CLI en quatre commandes

L'installation proposée pour macOS et Linux utilise curl -fsSL https://get.gortex.dev | sh, tandis que Windows dispose d'un script PowerShell. Le programme annonce la détection de l'architecture, la vérification SHA256 et cosign, puis l'installation dans PATH. Le démarrage rapide enchaîne gortex install, gortex daemon start --detach, gortex track ~/projects/myapp et, depuis le dépôt, gortex init. Cette dernière commande configure notamment .mcp.json et les hooks du dépôt. La documentation ne transforme pas ces commandes en garantie opérationnelle : contrôlez les permissions, les fichiers créés et le cycle de redémarrage du daemon.

MCP, recherche et changements simulés

Le catalogue décrit plus d'une centaine d'outils MCP, des ressources et des prompts pour rechercher des symboles, suivre des appels, calculer un blast radius, repérer des clones et proposer des actions de code. La recherche sémantique combine FTS5, BM25 et vecteurs, avec un modèle GloVe intégré de 3,8 Mo ; MiniLM, Ollama et OpenAI sont optionnels. preview_edit et simulate_chain permettent d'examiner un WorkspaceEdit sans toucher au disque. Les overlays d'éditeur accueillent les buffers non sauvegardés et les sessions peuvent être branchées. Ces fonctions sont puissantes, mais chaque intégration mérite une vérification indépendante.

Installer puis mesurer sur un vrai changement

Après gortex track et gortex init, choisissez un symbole dont les appelants sont connus. Comparez la sortie de l'outil d'impact avec une recherche manuelle, puis utilisez preview_edit avant toute modification. Testez aussi contracts sur deux dépôts qui partagent une route, en vérifiant la normalisation de l'ID et les faux positifs. Le README annonce jusqu'à 50 fois moins de tokens par réponse et cite des benchmarks reproductibles ; ce chiffre doit être traité comme une affirmation du projet jusqu'à sa mesure sur vos données. Le binaire est présenté comme sans dépendances externes et la télémétrie est désactivée par défaut, avec gortex telemetry on|off|status et prise en compte de DO_NOT_TRACK. Apache-2.0 encadre la distribution du code, sans remplacer votre revue de sécurité.

Contrôle ciblé · zzet gortex

Avec Gortex, choisissez un changement réel et demandez appelants, blast radius et contrats. Contrôlez les résultats dans le code, puis utilisez preview_edit ou simulate_chain sans écrire sur le disque. Répétez après indexation pour mesurer les trous de résolution et la précision du contexte MCP.

Limites observables · zzet gortex

Cette vérification doit rester liée au projet : relisez le README, utilisez les chemins et commandes cités, et comparez les sorties obtenues. Notez aussi les erreurs et les cas non couverts, car aucune donnée absente de la documentation ne doit être présentée comme une capacité. La décision finale dépend du format, du système et du niveau de maintenance attendus. Cette vérification doit rester liée au projet : relisez le README, utilisez les chemins et commandes cités, et comparez les sorties obtenues. Notez aussi les erreurs et les cas non couverts, car aucune donnée absente de la documentation ne doit être présentée comme une capacité. La décision finale dépend du format, du système et du niveau de maintenance attendus.

Conclusion éditoriale

Gortex cible les équipes qui veulent fournir à leurs agents un contexte de code structuré, local et traversant plusieurs dépôts. Il est moins adapté si votre besoin se limite à une recherche textuelle simple ou si les affirmations de réduction de tokens ne sont pas mesurées sur vos dépôts. Installez v0.63.8, lancez gortex daemon, indexez un dépôt avec gortex track, puis comparez une analyse d'impact et une lecture directe avant d'activer les outils MCP.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes