Comment nous mesurons

1. Pourquoi cette page existe

Les acheteurs sceptiques ne devraient pas avoir à rétro-ingénierer un texte marketing. Maguyva indexe des dépôts et affiche, sur l'ensemble du site, des affirmations de précision, de couverture linguistique et de coût. Ces affirmations ont besoin d'une page de méthodologie honnête sur le périmètre de la mesure : ce qui repose sur des fixtures, ce qui repose sur un jugement, et ce qui relève de la mise en forme plutôt que d'une certification indépendante.

2. Ce que nous mesurons

La qualité de l'intelligence du code se mesure principalement sur le moteur de langages — l'extraction de symboles, de relations et de graphes depuis le code source — pas sur des scores subjectifs de « satisfaction des agents ».

• Suites de fixtures par langage : les arêtes et symboles attendus que le handler doit extraire correctement
• Classification de l’exactitude sur les cas de test : GREEN exige une précision ≥ 0.95, un rappel ≥ 0.99, un F1 ≥ 0.97 et au moins 20 arêtes attendues, sous réserve de contrôles supplémentaires de la curation des cas. C’est une règle pour des cas de test connus, pas une estimation de confiance statistique ni l’affirmation que chaque langage activé est GREEN.
• Dimensions du language-audit : exactitude, intégrité structurelle, exhaustivité, qualité et performance sur le tableau de validation
• Boucles de corpus et de contrôle par échantillonnage : des arêtes échantillonnées dans de vrais dépôts, classées selon une grille de critères (correct, faux positif, erreur de type/scope/métadonnée) — décrites dans nos articles de blog sur le language-grind
• Indicateurs de capacité produit : ce que le serveur annonce (AST, locals, extraction de graphe), distinct de la taille du catalogue

Important : Les fixtures valident par rapport à des fixtures que nous avons nous-mêmes écrites. GREEN (vert) signifie que les cas connus passent. Cela ne signifie pas automatiquement que chaque cas réel s'extrait proprement. Cette distinction est délibérée et publique.

3. Vert vs vérifié de façon indépendante

Le tableau du language-audit utilise plusieurs axes, afin qu'un simple voyant vert ne puisse pas être lu comme « prouvé parfait ». Les chiffres clés du tableau se répartissent généralement ainsi :

• overall_green — sans régression par rapport aux fixtures self-snapshot et aux contrôles de validation du corpus associés (nécessaire, mais pas suffisant)
• independently_verified — dispose d'un signal de jugement fort tel qu'un échantillon initial contrôlé (inclut des langages qui présentent encore des erreurs jugées)
• verified_clean / zéro erreur jugée sur les arêtes échantillonnées — un sous-ensemble plus strict des langages jugés
• curation / confiance oracle — si les fixtures elles-mêmes sont traitées comme des oracles de confiance
• indicateurs structurels — l'extraction de graphe et la capacité AST ne sont pas identiques à l'appartenance au catalogue

Le nombre de langages affiché en marketing (par exemple « 285+ langages ») correspond à la taille du catalogue : langages configurés et entrées serveur. La taille du catalogue n'est pas un SLA de qualité AST. Nous préférons un reporting par niveaux à un simple chiffre vitrine. Pour l'état actuel du produit, voir Compatibilité et Guides de langages ; pour le détail narratif, voir l'article de blog sur l'auto-amélioration récursive des langages.

4. Qualité de la recherche et du retrieval

La qualité de la recherche sémantique est multimodale : texte, AST, graphe et embeddings sont fusionnés. Nous documentons des compromis d'ingénierie délibérés plutôt que de revendiquer un retrieval imbattable :

• Les embeddings utilisent une famille de modèles commerciaux (voyage-4-large à la date de l'article de blog de juin 2026), choisie sur la base des classements publics de retrieval au moment de la décision
• Les vecteurs sont quantifiés en binaire pour le stockage et le coût ; cela échange délibérément un peu de précision de retrieval contre une recherche de Hamming moins chère et plus rapide, sans base de données vectorielle séparée
• Le routage par intention et les poids de fusion sont des heuristiques conçues par nos soins. Une proposition de décembre 2025 estimait le taux initial de requêtes sans résultat à environ 15 % et fixait un objectif inférieur à 5 % ; nous n’avons fourni ni jeu de requêtes ni relevé de mesure démontrant cette baisse. Le dossier de preuves corrige l’affirmation antérieure d’une amélioration obtenue.
• Les articles de blog incluent des sections « ce qui reste imparfait » — les signaux imparfaits font partie du dossier, ce ne sont pas des notes de bas de page qu'on cache

5. Affirmations de coût

Le discours sur le coût chez Maguyva porte sur la structure tarifaire et la transparence opérationnelle, pas sur une étude formelle de TCO certifiée par un tiers.

• Tarification par workspace : facturée en fonction des dépôts, des lignes indexées et de la fréquence de reconstruction — pas par siège humain ou agent. La FAQ et les descriptions des plans détaillent ces dimensions.
• L’exemple tarifaire compare 25 places payantes à un tarif illustratif de $19–$59 par place à Crew à $49/mois. Les économies varient selon la taille de l’équipe et le produit alternatif ; il ne s’agit ni d’une comparaison à fonctionnalités égales ni d’un benchmark concurrentiel indépendant.
• Honnêteté sur les coûts opérationnels : la page /team publie une véritable ventilation mensuelle du burn logiciel (abonnements, outillage MCP/recherche, coûts liés à l'usage). C'est de la transparence customer-zero, pas un état financier audité.
• Les coûts d'embedding et d'infrastructure sont des coûts produit assumés (embeddings premium, stockage, reconstructions de graphe). Nous les payons délibérément et le disons dans l'article voyage-4-large et dans le discours sur la tarification.

6. Ce que nous ne prétendons pas

Cette page est aussi une liste de non-affirmations. Si quelque chose n'apparaît pas sur le tableau de mesure, ne prenez pas le ton marketing pour une preuve.

• Aucune garantie générale de précision absolue pour chaque langage. Les seuils des fixtures s'appliquent par langage sur des cas connus ; une part résiduelle d'erreur en conditions réelles est attendue et fait l'objet d'un travail de réduction continu.
• Aucune affirmation selon laquelle overall_green équivaut à une extraction parfaite en production pour chaque idiome de dépôt
• Aucun pack de certification de conformité par un tiers n'est présenté comme un artefact de méthodologie sur cette page (voir Sécurité pour les faits sur le traitement des données, pas pour des badges de conformité)
• Aucun comparatif multi-fournisseurs indépendant avec corpus partagés publié comme scorecard permanente
• Les résultats de recherche et les analyses restent du best-effort au titre des Conditions d'utilisation — Maguyva ne remplace ni la revue de code, ni les tests, ni les audits de sécurité

7. Comment vérifier par vous-même

Le parcours prévu pour un acheteur reste le même : indexer un dépôt que vous connaissez déjà, poser une vraie question, et inspecter les citations.

• Commencez gratuitement : de petits dépôts représentatifs valent mieux qu'un index de toute l'entreprise dès le premier jour
• Utilisez les outils MCP (intelligent_search, find_symbol, dependency_search) et ouvrez les chemins cités
• Lisez Comment ça marche pour l'architecture d'ingestion et de retrieval
• Lisez Compatibilité et Guides de langages pour les niveaux de capacité, pas seulement la taille du catalogue
• Lisez Sécurité et Confidentialité pour le traitement des données ; cette page ne les remplace pas