Pour qui

Suivre ce que livrent les autres produits

Une veille gardée en favoris se dégrade en une liste de liens qu’on ne peut pas fouiller. Capturée en Markdown, elle devient un corpus que vous pouvez chercher, comparer et citer dans une note de décision. Chaque entrée garde la date que la page annonçait, pas celle du jour où vous l’avez lue.

Une veille qui ne se cherche pas

La veille concurrentielle s’accumule vite et se relit mal. Trente onglets deviennent trente favoris, puis un document de liens que personne n’ouvre, et six mois plus tard il est impossible de dire quand tel concurrent a livré telle fonction. La page de changelog, elle, a été réécrite, et les entrées anciennes ont disparu de la version publiée.

Quand il faut trancher, l’information manque au mauvais moment. Vous écrivez une note de décision et vous voulez appuyer une affirmation sur ce que fait un concurrent ; il reste un souvenir et un lien mort. Refaire la recherche prend une demi-journée, et rien ne garantit que la page dise encore ce qu’elle disait.

La veille est en plus rarement le travail d’une seule personne, et c’est là qu’elle se perd vraiment. Trois personnes suivent les mêmes concurrents, chacune dans ses propres onglets, et aucune ne peut montrer aux autres ce qu’elle a vu ni quand. Un dossier de fichiers .md change cela sans rien installer : il se synchronise comme n’importe quel dossier de l’équipe, chaque note porte la date annoncée par la page et son adresse, et la recherche en texte intégral traverse le travail de tout le monde d’un coup.

Ce que devient la veille

• La date de publication est lue sur la page, donc une entrée de changelog garde son vrai calendrier
• Les règles par site rangent chaque concurrent dans son propre sous-dossier
• Le motif d’une règle ignore le protocole et le www., et * remplace n’importe quelle suite : exemple.com/blog/* couvre tout un blog
• Les tableaux d’offres, de limites et de compatibilité passent entiers
• L’adresse source figure dans chaque note, donc chaque affirmation reste traçable
• Les fichiers vivent dans votre vault, à côté des décisions qu’ils appuient
• Un dossier de captures se partage et se synchronise comme n’importe quel dossier de l’équipe
• La recherche en texte intégral de votre système traverse tout le corpus

---
title: "Notes de version – Firefox 128.0"
source: "https://www.mozilla.org/fr/firefox/128.0/releasenotes/"
published: "2024-07-09"
extraction: "dom"
---

## Nouveautés

## Correctifs

## Problèmes connus

Mettre la veille en place

Une veille tient si la capture coûte moins qu’un marque-page. Six réglages, faits une fois, après quoi suivre un concurrent revient à lire sa page et à taper un raccourci.

1. Dans les paramètres, section « Où enregistrer », désignez avec « Choisir… » un dossier partagé ou synchronisé avec l’équipe, puis mettez veille dans « Sous-dossier des téléchargements ». Le dossier reste un dossier ordinaire : aucun outil n’est nécessaire pour le lire.
2. Réglez « Nom du fichier » sur {date} - {domain} - {title}. Le tri se fait alors par date annoncée puis par concurrent, ce qui est exactement l’ordre dans lequel on relit une veille au moment de décider.
3. Ouvrez « Règles par site » et créez une règle par concurrent suivi. Un motif comme exemple.com/changelog/* reçoit son propre sous-dossier ; le motif est comparé sans le protocole ni le www., et * remplace n’importe quelle suite de caractères.
4. Passez « Images » sur « ignorer » dans ces règles. Les pages de produit sont surtout composées de captures d’écran promotionnelles, dont les liens encombrent la note sans porter d’information.
5. Réglez « Clic sur l’icône » sur « Placer dans un dossier ». La capture se fait sans fenêtre, ce qui compte quand vous parcourez dix pages de suite ; Alt+Shift+M fait la même chose sans quitter le clavier.
6. Vérifiez le résultat sur une entrée de changelog : ouvrez le fichier et contrôlez que published porte bien la date de l’entrée. Les pages de notes de version sont l’endroit où les dates sont les plus irrégulières, et il vaut mieux le savoir par source que le découvrir en réunion.

Réglages conseillés pour la veille

Ces valeurs supposent un suivi régulier de quelques concurrents, pas une collecte massive. Les règles par site font l’essentiel du travail.

---
title: "Comparer les offres"
source: "https://www.scaleway.com/fr/pricing/"
extraction: "dom"
---

## Offre Essentiel

Sauvegarde quotidienne · deux utilisateurs · assistance par courriel

## Offre Avancée

Sauvegarde horaire · utilisateurs illimités · assistance téléphonique

## Offre Entreprise

Engagement de disponibilité contractuel · interlocuteur dédié

Trois usages réels

Suivre un changelog qui se réécrit

Beaucoup d’éditeurs ne gardent en ligne que les dernières entrées de leurs notes de version, et réécrivent les anciennes sans le dire. En capturant la page à chaque passage, vous construisez la série que le site ne publie plus : chaque fichier porte la date que l’entrée annonçait et l’adresse d’où elle venait.

Sur ces pages, la date vient le plus souvent d’un élément de temps balisé dans la page. Quand une entrée n’en porte aucune, le champ published n’est pas écrit du tout – c’est une information sur la source, et il vaut mieux la voir que recevoir la date du jour à la place.

Appuyer une note de décision

Vous défendez un arbitrage et vous voulez montrer qu’un concurrent a livré telle fonction à telle date. La capture correspondante est dans le dossier de veille, avec son adresse et sa date en tête de fichier : vous citez la note, pas un lien qui peut avoir changé entre l’écriture et la réunion.

Ce que l’extension ne fera pas : comparer deux captures et vous dire ce qui a bougé. Il n’y a ni différentiel, ni surveillance, ni alerte. La comparaison se fait dans votre éditeur ou avec un outil de diff, sur deux fichiers texte, ce qui reste rapide mais reste manuel.

Une veille partagée sans outil supplémentaire

Le dossier de veille est synchronisé par l’outil de l’équipe. Chacun capture ce qu’il lit, avec la même convention de nom, et tout le monde cherche dans le même corpus. Aucun compte à créer, aucun service à administrer, aucune donnée qui sorte des machines : l’extension ne fait aucune requête réseau.

Le format y est pour beaucoup. Ce sont des fichiers Markdown ordinaires, que chacun ouvre avec ce qu’il utilise déjà – éditeur de texte, application de notes, coffre Obsidian – sans que personne n’ait à adopter l’outil du voisin.

Comparé aux façons de faire actuelles

La veille produit se fait déjà, d’une manière ou d’une autre. Le tableau compare ce que chaque méthode donne le jour où il faut citer une source.

Quand la veille ne prend pas

Pourquoi la page de tarifs répond-elle « aucun article » ?

Parce qu’elle n’a pas de corps d’article. Une page entièrement faite de blocs promotionnels, de boutons et de libellés courts est structurellement proche d’un fil de liens : au-delà de 800 caractères, quand plus d’un quart des caractères se trouvent dans des libellés de liens, la capture ne garde que l’en-tête et le champ extraction porte no-article.

Sélectionnez le tableau de comparaison ou la section qui vous intéresse et capturez la sélection : ni la coupe ni ce refus ne s’appliquent à un texte que vous avez désigné à la main.

Pourquoi la grille de comparaison est-elle devenue du texte ?

Parce que c’était une mise en page et non un tableau. Une grille qui contient un autre tableau, une grille dont moins d’un tiers des cellules portent du texte, ou une grille d’une seule colonne sont reconnues comme des dispositifs de positionnement : elles sont dépliées, et leur contenu ressort dans l’ordre du document.

Le résultat est souvent plus lisible que l’original : chaque offre devient une section avec sa liste de fonctions. Quand la page utilise un vrai tableau, en revanche, il reste un tableau – c’est le cas des grilles de compatibilité et des tableaux de limites techniques.

Pourquoi la date de l’entrée manque-t-elle ?

Parce que la page ne l’expose pas dans ses métadonnées. Les pages de notes de version affichent souvent la date en texte, dans le titre de l’entrée, sans la baliser : l’extension ne cherche jamais de date dans le corps du texte, précisément pour ne pas ramasser un nombre qui n’en est pas une.

La date reste alors visible dans le texte capturé, et c’est le nom du fichier qu’il faut surveiller : quand la page n’annonce aucune date, le jeton {date} du modèle retombe sur la date du jour. Ajoutez {domain} au modèle pour que le classement reste utilisable dans ce cas.

Pourquoi ma règle par site ne s’applique-t-elle pas ?

Presque toujours à cause du motif. La comparaison se fait sur l’adresse sans son protocole et sans le www. de tête, et le motif est ancré au début : exemple.com/blog/* fonctionne, alors que blog/* ne correspondra à rien, puisque l’adresse ne commence pas par là.

Le joker * remplace n’importe quelle suite de caractères, y compris des barres obliques, et la comparaison ne tient pas compte de la casse. En cas de doute, capturez une page du site et vérifiez le chemin affiché après l’enregistrement : il indique le sous-dossier réellement utilisé.

Ce qu’il ne fait pas

Il ne surveille rien : aucune vérification périodique, aucune alerte quand une page change, aucun robot d’exploration – la capture part de votre clic. Il ne compare pas deux captures et ne produit pas de différentiel. Il ne capture pas plusieurs onglets d’un coup, c’est une page à la fois. Et sur une page entièrement faite de blocs marketing, sans corps d’article, il peut répondre « aucun article » plutôt que de rendre une page de liens.

Questions