Construite, pas poussée
Où chaque fonctionnalité de votre catalogue apparaît sur leur site : docs et changelog, blog, prix, page d’accueil. Une fonctionnalité construite mais pas poussée, c’est le signal.
Chaque version de leur site, l’année d’avant, et les signaux qui bougent avant le marketing.
Nagare lit les sites publics de vos concurrents, leurs documents d’API et leur GitHub, garde chaque version et chaque suppression, et vous dit ce qu’ils préparent peut-être. Chaque phrase renvoie à sa preuve.
Pour les product managers et les fondateurs qui portent la stratégie concurrentielle.D’abord votre produit et son catalogue de fonctionnalités, puis vos concurrents, d’une première lecture jusqu’au brief : treize étapes enregistrées dans la console sur un espace de démo, un produit de feature flags face à cinq vrais concurrents, lus sur leurs sites publics, leur GitHub, leurs documents d’API et Common Crawl. Sans son, en anglais.
Un rapport Trajectoire dit ce qu’un concurrent prépare peut-être. Chaque hypothèse s’appuie sur des signaux datés que vous pouvez ouvrir : une fonctionnalité dans leurs docs que leur page d’accueil ne mentionne pas encore, de nouvelles opérations dans leur API, une release de leur SDK, une page publiée mais liée de nulle part.
Il dit « peut-être » et montre ses preuves. Vous lisez les signaux et vous décidez.
Ajoutez un concurrent : Nagare demande à Common Crawl, une archive à but non lucratif du web public, ce que disaient ses pages d’accueil et de prix ces douze derniers mois.
Les périodes archivées sont toujours signalées : moins de captures, des dates moins précises, moins fiables que ce que Nagare lit lui-même. Nagare raconte cette année dans un rapport, mois par mois. À partir du jour où vous l’ajoutez, il garde chaque version.
Une fonctionnalité apparaît souvent dans leurs docs, leur API et leurs SDK des semaines avant leur page d’accueil. Nagare lit ces endroits, date ce qu’il trouve, et dit quand ce n’est qu’un indice.
Où chaque fonctionnalité de votre catalogue apparaît sur leur site : docs et changelog, blog, prix, page d’accueil. Une fonctionnalité construite mais pas poussée, c’est le signal.
Le document OpenAPI qu’ils publient, ou celui que portent leurs SDK publics sur GitHub. Les opérations ajoutées, retirées et dépréciées, chacune datée, et citées dans votre brief.
Dépôts et releases, lus par l’API de GitHub elle-même. Ce qui existait quand Nagare a commencé est de l’historique ; seul ce qui apparaît ensuite est une nouveauté.
Les pages que leur site publie sans qu’aucune autre de leurs pages n’y renvoie : une page de lancement en attente, une offre pas encore listée. Nagare lit ce que le site publie et ne devine jamais d’adresse.
Les clients qu’ils affichent, d’après leurs études de cas et les logos de leurs pages, avec le jour où chacun est apparu ou a disparu. Ceux que vous affichez tous les deux, et leur audience à côté de la vôtre, dans leurs propres mots.
Des noms seulement : Nagare ne copie jamais leurs logos.
Un brief chaque jour, chaque semaine, toutes les deux semaines ou chaque mois, selon ce que vous activez. Ce qui a bougé chez vos concurrents, sur leurs sites, dans leur API et dans leurs recrutements, ce que ça veut sans doute dire, et quoi surveiller ensuite. Il se termine par ce qui a changé sur votre propre site.
Deux concurrents ont bougé sur les prix. Entitly a supprimé son offre gratuite et passé l’offre d’entrée à 49 $/moisE1. L’API de Flagstack gagne des validations : trois nouvelles opérationsS1, un jour après la sortie de son SDK NodeG1. Meterbase monte en gamme : SOC 2 Type IIE2 et deux postes d’Enterprise AEJ1.
Les battlecards, les prix et la matrice des fonctionnalités placent chaque concurrent à côté de votre produit, chaque affirmation prouvée par sa propre page.
Données réelles : ce que Nagare a lu entre le 20 et le 23 octobre 2026 pour Orbital, un produit de démonstration, face à cinq outils de feature flags.
Là où ils sont devant, là où vous l’êtes, et trois arguments avec leurs preuves. Réécrite après chaque crawl, et modifiable par vous.
Chaque offre alignée par palier, les offres d’entrée comparées, chaque prix prouvé par sa page, et chaque changement daté.
Postes ouverts, levées de fonds, publicités Google, trafic, liens qu’ils publient et avis PeerSpot. Chacun cite sa source.
Votre catalogue vient de votre knowledge.md ; chaque case d’un concurrent est prouvée par une citation de son site. Un modèle ne déclare jamais une fonctionnalité absente.
Claude Code ou vos agents interrogent Nagare directement, par son serveur MCP : concurrents, changements, historique des pages, briefs, battlecards, trajectoires, matrice et prix. En lecture seule, avec une clé d’API de l’espace de travail, chaque réponse avec ses preuves et un lien vers Nagare.
Chaque site s’exporte aussi en un seul llms-full.txt propre.
Quatre étapes, et un fil qui garde l’histoire de chaque page.
Collez le site d’un concurrent. Nagare cartographie ses pages et montre sa première lecture en direct : le site, leur GitHub, leurs documents d’API, leur année passée.
Un crawler identifié, à votre rythme, robots.txt respecté, sur le même site seulement. GitHub et Common Crawl par leurs propres API publiques.
Une nouvelle version seulement quand le contenu change. Les suppressions sont datées. L’année tirée de l’archive est gardée à part et signalée.
Briefs, battlecards et trajectoires : ce qui a bougé, ce que ça peut vouloir dire, chaque phrase reliée à sa preuve.
Non. C’est une hypothèse avec les signaux datés qui la soutiennent : une fonctionnalité dans leurs docs mais pas sur leur page d’accueil, de nouvelles opérations d’API, une release, une page publiée mais non liée. Vous voyez chaque signal et décidez de ce qu’il veut dire.
De Common Crawl, une organisation à but non lucratif qui archive une grande partie du web public environ une fois par mois. Nagare lui demande ce que disaient les pages d’accueil et de prix d’un concurrent dans les douze mois avant son ajout, garde au plus une capture par mois, et la signale toujours comme archivée et moins fiable. Elle nourrit les comparaisons et un rapport, l’année d’avant, mois par mois ; jamais une alerte ni un brief.
Les pages publiques des sites que vous déclarez : prix, produit, docs, changelog, recrutement, blog. Une page qu’un site demande aux robots de ne pas lire n’est pas lue. Au-delà de leur site, Nagare lit les documents d’API qu’ils publient et leur GitHub public, par l’API de GitHub elle-même. Jamais LinkedIn, jamais derrière une connexion.
Non, et c’est voulu. Nagare lit selon le rythme que vous choisissez : chaque jour, chaque semaine, ou à la demande avec Crawl now. Les changements majeurs envoient quand même une alerte dès qu’ils sont lus.
Le tri, le brief, la battlecard et la trajectoire sont écrits par un modèle, et chaque phrase porte le changement, la page ou le signal qui la justifie. La lecture des sites, de l’archive, des documents d’API, de GitHub et des clients se fait sans IA. Pas de chat : c’est votre assistant qui lit Nagare.
Oui. Un serveur MCP en lecture seule permet à Claude Code ou à vos agents d’interroger Nagare avec une clé d’API de l’espace de travail, chaque réponse avec ses preuves. Chaque site s’exporte aussi en un seul llms-full.txt propre, régénéré seulement quand son contenu change.
Nagare est en accès anticipé et ses tarifs ne sont pas encore fixés. Rejoignez la liste d’attente : vous serez prévenu en premier.
Oui. Quand une page disparaît, Nagare note le jour où elle est partie et garde sa dernière version. Une offre retirée, un logo client discrètement enlevé : les suppressions sont souvent les mouvements les plus parlants d’un concurrent.
Ajoutez un concurrent : Nagare lit son année passée dans l’archive, signalée moins fiable. Dès ce jour, Nagare garde lui-même chaque version : plus tôt vous commencez, plus leur histoire est la vôtre.