Faire son app de suivi

Séance 2 · pour aller plus loin, chez vous

Les slides du chapitre (PDF)

• Dire ce qu'une application apporte de plus qu'un site de synthèse.
• Décrire la chaîne complète : des agents de veille au site du groupe.
• Demander une application à un agent, puis l'améliorer tour après tour.
• Partager le suivi dans un groupe sans laisser l'application ouverte à tout le monde.

Ce chapitre est facultatif. Il prolonge « Écrire son skill » : vos agents écrivent des veilles, des fiches et une liste de sources, et vous voulez un outil pratique pour vous y retrouver, semaine après semaine.

Il montre jusqu'où on peut aller. L'application que vous allez voir n'est pas sortie d'une seule demande : il a fallu quatre tours de corrections, dont le dernier est parti du rapport d'un testeur. C'est l'idée principale du chapitre.

1. Ce qu'un site de synthèse ne fait pas#

Le site de synthèse du chapitre « Trois agents, une veille commune » montre vos résultats. Il a trois limites.

• Il ne retient rien de vous. Vous avez lu une fiche, vous voulez en garder une autre pour le dossier, une troisième ne vous sert pas : le site ne le sait pas. La semaine suivante, tout est à relire.
• Il ne dit pas quoi lire d'abord. Vingt nouveautés à la suite ont toutes le même poids.
• Il ne sert qu'à vous. Vos coéquipiers ne voient pas ce que vous avez gardé, ni pourquoi.

Une application règle les trois. Elle range les nouveautés par importance, elle retient vos décisions, et elle montre celles du groupe.

2. La chaîne complète#

Jusqu'ici, vos agents de veille écrivaient des lignes et des fiches. La chaîne de ce chapitre ajoute trois étapes.

1. Les agents de veille font ce que vous connaissez : chacun écrit son fichier dans veille/.
2. Votre meilleur agent relit ces fichiers et rédige les rapports finaux : un fichier Markdown par nouveauté importante, une synthèse par semaine, un lexique. Il recoupe ce que disent les agents, rouvre les sources, explique les mots difficiles et dessine un schéma quand un schéma aide.
3. Vous relisez, puis vous poussez les fichiers dans votre dépôt GitHub. Un dépôt est un dossier suivi par git ; pousser (git push), c'est envoyer vos dernières versions sur GitHub.
4. Le site se reconstruit à chaque fois que vous poussez. Il ne contient aucun texte à lui : il affiche les fichiers.

Personne n'écrit dans l'application. Pour ajouter un rapport, on ajoute un fichier. C'est ce qui permet à un agent de faire le travail, et à git d'en garder l'historique.

3. Un exemple : l'atelier de veille du cours#

Pendant la préparation de ce cours, le professeur a fait construire cette application par plusieurs agents Claude, à partir du dossier de la veille commune : trois fichiers de veille, treize fiches, une liste de sources. Les trois veilles comptaient 31 lignes. Regroupées, elles donnent 21 nouveautés, parce qu'une nouveauté trouvée par plusieurs agents n'apparaît qu'une fois.

L'application est faite avec Nuxt (un outil pour construire des sites avec Vue), Nuxt UI (sa bibliothèque de composants) et Nuxt Content (qui transforme des fichiers Markdown en pages).

L'accueil répond à une question : quoi lire d'abord ?#

Une phrase résume la semaine. Un bandeau dit ce qui est arrivé depuis votre dernière visite. « À lire en premier » ne montre que trois nouveautés, les plus importantes.

Le tri : une nouveauté à la fois#

Vous lisez l'essentiel en trois phrases, vous décidez d'une touche, la nouveauté suivante arrive. Dix-neuf nouveautés se trient en quelques minutes. La touche U annule la dernière décision.

Sur un téléphone, les quatre boutons restent collés en bas de l'écran :

Le dossier : ce que le groupe a gardé#

Le dossier réunit ce que les membres ont gardé, avec la note de chacun. Le bouton d'export en fait un fichier Markdown : la matière de votre dossier de groupe, et un fichier qu'un agent peut relire.

Trois autres écrans complètent l'outil : la liste complète avec recherche et filtres, les sources (lesquelles ont été recoupées par plusieurs agents, lesquelles n'ont été vues que par un seul) et le lexique.

4. Des rapports, pas des listes de liens#

Une ligne de veille dit qu'une nouveauté existe. Elle ne vous l'explique pas. Dans cette chaîne, votre meilleur agent écrit un rapport pour chaque nouveauté importante, toujours avec les mêmes parties.

Partie du rapport	Ce qu'elle contient
L'essentiel en trente secondes	Trois phrases. Si vous ne lisez que ça, vous savez de quoi on parle.
Pourquoi on en parle	Ce qui rend la nouveauté importante cette semaine.
Ce que c'est	L'explication, pour quelqu'un qui débute. Elle est signée : « Explication du rédacteur ».
Ce que dit la source	Les faits, tels que l'agent les a lus sur la page d'origine.
Ce que ça change pour moi	Pour un développeur web, pour un designer web. Parfois : rien.
Limites et doutes	Ce qui n'est pas prouvé, et ce que les agents de veille ont mal rapporté.
Niveau de confiance	Un tableau : dit par la source, expliqué par le rédacteur, ou non vérifié.

Deux séparations comptent plus que le reste. Ce que dit la source est séparé de ce que l'agent explique : vous savez toujours qui parle. Et chaque affirmation a un statut dans le tableau de confiance.

Un mot souligné ouvre sa définition, sans quitter la page. Un schéma apparaît quand il montre mieux qu'une phrase :

La synthèse de la semaine est un bulletin : trois phrases, les nouveautés par importance, ce que les trois agents ont tous vu, ce qu'un seul a vu.

Ce que le rédacteur a trouvé en relisant les agents#

Pour écrire les rapports du cours, l'agent rédacteur a rouvert les sources. Il a trouvé des erreurs dans les lignes des agents de veille. Deux exemples :

• Une page annonçait un prix de « 50–70% of comparable mainstream offerings » : 50 à 70 % du prix des offres comparables. Un agent de veille avait écrit « 50 à 70 % inférieur ». Lu correctement, le produit coûte 30 à 50 % de moins. L'écart est grand.
• Un agent écrivait que Google ouvrait Gemini 4 Carbon « à tous les développeurs et au grand public ». La page parlait d'une API payante et, pour le grand public, des seuls abonnés à l'offre la plus chère.

Ces erreurs sont écrites dans les rapports, à la partie « Limites et doutes ». C'est la raison d'être de cette étape : un deuxième agent, qui relit le premier en rouvrant la source.

Le rédacteur se trompe aussi. Sur les 21 rapports du cours, 10 sont complets. Les 11 autres sont marqués « En bref » : l'agent y reprend la veille sans avoir rouvert la source, et l'application le dit en tête de page. Avant de pousser, c'est à vous de relire : ouvrez deux rapports, et pour chacun la source.

Voici une demande pour cette étape :

Lis tous les fichiers de `veille/` et `veille/fiches/`. Pour chaque nouveauté importante, écris un rapport dans `content/rapports/`, un fichier Markdown par nouveauté, pour un lecteur qui débute en IA.
Rouvre la source de chaque nouveauté. Si tu n'y arrives pas, écris un rapport court, marqué « en bref », et dis-le dans le rapport.
Chaque rapport a les mêmes parties : l'essentiel en trois phrases, pourquoi on en parle, ce que c'est, ce que dit la source, ce que ça change pour un développeur ou un designer web, limites et doutes, niveau de confiance.
Sépare toujours ce que dit la source de ce que tu expliques toi-même. N'ajoute aucun fait qui ne vient ni des fichiers de veille ni d'une page que tu as ouverte.
Quand deux agents de veille se contredisent, ou qu'une ligne ne correspond pas à la source, écris-le dans « Limites et doutes ».
Ajoute un schéma en SVG seulement s'il montre un mécanisme ou une comparaison. Écris aussi la synthèse de la semaine et un lexique des mots techniques.
Termine par la liste des rapports dont tu n'as pas pu rouvrir la source.

5. Ce n'est pas une seule demande#

La première version de cette application marchait. Elle n'était pas pratique.

Tout y est : la liste, les filtres, le suivi. Mais rien ne dit quoi lire d'abord, les vingt-et-une lignes se ressemblent, et le suivi est un formulaire au milieu de la page. Un agent qui a fait tout ce que vous lui demandiez dit « c'est fini ». C'est à vous de dire que ça ne l'est pas.

Entre cette version et celle de la section 3, il y a eu quatre tours. Un tour, c'est toujours la même boucle :

Voici ce que les captures ont montré, tour après tour.

Tour	Ce que les captures ont montré	Ce qui a changé
1	Sur un téléphone, les boutons de tri étaient sous trois écrans de texte. Le titre de l'accueil répétait un compteur placé juste en dessous. Le nom des sources était gris pâle, moins lisible que leur description.	La barre de décision collée en bas de l'écran. Une phrase qui résume la semaine et un bouton « Trier maintenant ».
2	Toutes les cartes portaient l'étiquette « À trier » : du bruit. Une correction automatique du code avait coupé des phrases (« 22 , triées par priorité »).	Comme dans une boîte mail : un titre en gras tant que la nouveauté n'est pas triée, en gris ensuite. Des phrases entières.
3	La page des sources affichait une grande tuile « Médias : 0 », pour dire « rien ».	Trois chiffres utiles : sources lues, recoupées par deux agents au moins, vues par un seul.
4	Le testeur (voir ci-dessous).	Le mot du lexique réparé, le suivi rafraîchi en quelques secondes, le bandeau « Nouveau depuis ta dernière visite ».

Aucun de ces défauts n'était dans la demande de départ. Vous ne pouviez pas les prévoir : ils se voient sur l'écran, pas dans la consigne.

Un testeur qui ne connaît pas le projet#

Après trois tours, l'agent qui construit ne voit plus ses défauts : il regarde les endroits où ça marche. Le quatrième tour a commencé par un autre agent, dans une nouvelle conversation, avec une seule mission : utiliser l'application comme un étudiant, et dire ce qui ne va pas, sans rien corriger.

Il a trouvé deux défauts que trois tours n'avaient pas vus.

• Un mot du lexique affiché en code. Dans dix rapports, on lisait « l':termAPI payante » au lieu de « l'API payante ». Le mot cliquable ne marchait pas après une apostrophe. L'agent constructeur n'avait regardé que les mots qui marchaient.
• Un suivi en retard de trente secondes. Deux navigateurs ouverts côte à côte : la décision de l'un arrivait chez l'autre trente secondes plus tard, et rien ne le disait. En groupe, on croit qu'un coéquipier n'a rien décidé.

Il a aussi dit ce qui manquait pour s'en servir chaque semaine : voir ce qui est nouveau depuis la dernière visite, et filtrer ce que le groupe a gardé. Les deux ont été ajoutés.

Il reste des défauts connus, laissés de côté : la recherche ne connaît pas les synonymes, et sur un téléphone rien n'indique qu'un schéma s'agrandit quand on le touche. Une application n'est jamais finie. Vous décidez où vous arrêter.

6. La demander à son agent#

Ne cherchez pas la demande parfaite. Faites une première demande claire, puis des tours. Les demandes qui suivent résument ce que le professeur a demandé à ses agents. Elles n'ont pas été rejouées mot pour mot : adaptez-les, et attendez-vous à un résultat différent.

La première demande. Ouvrez votre dossier de veille dans votre agent le plus solide :

Construis dans un nouveau dossier `app-veille/` une application web de veille avec Nuxt, Nuxt UI et Nuxt Content.
Avant d'écrire du code : lis tous les fichiers de `content/` (rapports, synthèses, lexique, sources), puis vérifie dans la documentation officielle (nuxt.com, ui.nuxt.com, content.nuxt.com) les versions actuelles. Si le skill `nuxt-ui` est installé, suis-le. Écris d'abord un fichier SPEC.md : les écrans, le format des fichiers, le suivi. Montre-le-moi avant de continuer.
L'application affiche les fichiers de `content/`. Personne n'écrit de contenu dans l'interface.
Écrans : un accueil qui dit quoi lire d'abord, un tri qui montre une nouveauté à la fois (garder, lu, plus tard, écarter, au clavier), la liste complète avec recherche et filtres, la page d'un rapport pensée pour la lecture, la synthèse de la semaine, le dossier de ce qui est gardé, les sources, le lexique.
Suivi : un état et une note par nouveauté et par membre, enregistrés par une route serveur.
Interface en français, code en anglais, clavier, téléphone, mode sombre, contrastes lisibles.
Avant de dire que c'est fini : lance le lint, la vérification des types et le build, ouvre chaque écran, change un état et relis-le. Montre-moi les sorties réelles des commandes et dis-moi ce que tu n'as pas pu vérifier. Ne fais aucun commit sans me le demander.

Un tour. À répéter tant que vous voyez des défauts :

Lance l'application. Capture chaque écran en grand (1440 × 900), en mode sombre et sur téléphone (390 × 844). Regarde les images une par une. Fais la liste de ce qui gêne la lecture, de ce qui se répète, de ce qui manque pour décider vite. Montre-moi la liste avant de corriger. Note dans ITERATIONS.md ce que tu as vu et ce que tu as changé.

Regardez les captures vous aussi. Ajoutez à la liste ce qui vous gêne, vous : c'est votre outil.

Le testeur. Dans une nouvelle conversation, ou avec un autre agent :

Tu testes cette application sans rien modifier. Utilise-la comme un étudiant qui fait sa veille chaque semaine, seul puis en groupe (deux navigateurs, deux pseudos). Écris dans TEST-CRITIQUE.md : les bogues, avec la façon de les reproduire ; ce qui gêne ; ce qui manque pour un usage chaque semaine ; ce qui est déjà bon et qu'il ne faut pas casser ; ce que tu n'as pas pu tester.

Comptez large. Pendant la préparation du cours, la première version a pris une vingtaine de minutes à un agent ; la seconde a demandé plusieurs agents et quatre tours, dont celui du testeur.

7. Un skill pour bien construire#

Un agent connaît Nuxt, mais souvent une vieille version. Il se trompe sur des détails qui font perdre du temps. Les deux versions de l'application en ont rencontré une vingtaine. Ils sont rassemblés dans un skill, nuxt-ui, avec la marche à suivre : créer le projet, ranger les fichiers, choisir les composants, écrire les routes serveur, et tout vérifier avant de dire « fini ».

Le skill nuxt-ui (zip)

Décompressez-le dans .agents\skills\ : vous obtenez .agents\skills\nuxt-ui\SKILL.md. Pour Claude Code, demandez-lui de copier ce dossier dans .claude\skills\. La première demande de la section 6 dit déjà à l'agent de le suivre.

C'est la même idée que pour votre veille : ce que vous avez appris une fois, vous l'écrivez dans un skill, et l'agent ne refait pas l'erreur.

8. Partager dans le groupe : deux chemins#

Dans un groupe, deux choses se partagent, et pas de la même façon.

Le contenu passe par git. Les rapports sont des fichiers dans le dépôt. Un membre pousse, le site se reconstruit, tout le groupe lit la même chose. C'est lent (le temps d'une reconstruction), mais chaque version est gardée, et un commit dit qui a changé quoi. Un commit, c'est une version enregistrée par git, avec un message.

Le suivi passe par une petite API. Une décision (« gardé », « écarté », une note) doit arriver tout de suite chez les autres. La pousser dans git serait trop lourd. L'application a donc quelques routes serveur qui lisent et écrivent le suivi dans une petite base de données : une ligne par membre et par nouveauté.

Une API ouverte à tout le monde ?#

Non. Une application en ligne a une adresse, et n'importe qui peut appeler ses routes. Une API sans aucune protection laisse un inconnu, ou un robot, remplir votre suivi.

Le prototype utilise la protection la plus simple qui tienne : un code de groupe.

• Celui qui met le site en ligne choisit un code et le range dans les réglages de l'hébergeur, jamais dans le dépôt.
• Chaque membre tape ce code une fois, avec un pseudo. Le navigateur les retient.
• Chaque écriture envoie le code. Sans le bon code, l'API refuse.

Ce n'est pas un vrai compte, et il faut connaître les limites. Le code est le même pour tous : un membre peut écrire sous le pseudo d'un autre. Si le code fuit, il faut le changer. Pour un groupe de trois qui se fait confiance, cela suffit. Pour une application ouverte au public, il faudrait de vrais comptes : demandez à votre agent ce que cela implique avant de vous lancer.

Le suivi ne contient qu'un pseudo, un état et une note. N'y mettez ni nom complet, ni adresse e-mail.

Voir les décisions des autres#

Chaque navigateur ouvert redemande régulièrement à l'API si quelque chose a changé. Mesuré pendant la préparation, avec deux navigateurs sur le même ordinateur : une décision apparaît chez l'autre membre en 1,5 à 8 secondes selon l'écran. Le bloc « Le groupe » affiche « Mis à jour il y a N s », avec un bouton pour actualiser.

9. La mettre en ligne#

Sur votre ordinateur, l'application ne sert qu'à vous. Pour la partager, demandez à votre agent :

Explique-moi comment mettre cette application en ligne sur Vercel avec l'offre gratuite, et comment brancher une petite base gratuite pour le suivi du groupe. Ne crée aucun compte et ne déploie rien sans me le demander. Écris les étapes dans le README.

Rien de ceci n'a été mis en ligne pour le cours. Un agent a lu la documentation de Vercel et de Nuxt, et le build pour Vercel a été essayé sur l'ordinateur du professeur, sans mise en ligne. La base en ligne n'a pas été essayée. Vérifiez chaque point avec votre agent.

• Vercel héberge une application Nuxt gratuitement, avec son offre Hobby, pour un usage personnel et non commercial. Vous lui donnez votre dépôt GitHub, et chaque git push sur la branche principale met le site à jour.
• Le dépôt doit être sous un compte GitHub personnel. L'offre gratuite ne se connecte pas à un dépôt qui appartient à une organisation GitHub. Un seul membre héberge, les autres utilisent l'adresse.
• Le suivi ne peut pas rester dans un fichier. Sur votre ordinateur, l'application range le suivi dans un dossier. Sur Vercel, l'application ne peut pas écrire de fichier durable. Il faut une petite base de données.
• Une petite base gratuite suffit. Le prototype est prévu pour Upstash (Redis), qui se crée depuis Vercel. Neon (PostgreSQL) et Turso (SQLite) ont aussi une offre gratuite. Les limites de ces offres changent : lisez leur page de prix.
• Les secrets vont dans les réglages de Vercel (« Environment Variables ») : le code de groupe, l'adresse et le jeton de la base. Jamais dans le dépôt, jamais dans une conversation avec un agent que vous partagez.
• Les rapports sont publics dès que le site est en ligne : le code de groupe protège le suivi, pas la lecture. Ne publiez que ce que vous acceptez de montrer.

10. Vérifier avant de s'y fier#

Une application qui s'ouvre n'est pas une application juste. Quatre vérifications prennent un quart d'heure.

1. Le nombre de nouveautés. Additionnez les lignes de vos fichiers de veille, puis regardez le nombre de nouveautés affiché. L'écart vient des nouveautés regroupées : ouvrez-en deux et vérifiez que les lignes regroupées parlent bien du même fait.
2. Les oublis. Prenez une ligne au hasard dans chaque fichier de veille et cherchez-la dans l'application.
3. Deux rapports. Ouvrez-les, puis ouvrez leur source. Vérifiez un chiffre et une date dans « Ce que dit la source ».
4. Le suivi à deux. Deux navigateurs, deux pseudos : gardez une nouveauté dans l'un, et regardez combien de temps elle met à apparaître dans l'autre.

Demandez aussi à l'agent un petit script qui contrôle le contenu avant chaque git push : un rapport sans source, un mot du lexique qui n'existe pas, un schéma absent. Celui du prototype signale aussi un mot du lexique mal écrit, qui s'afficherait en code.

À retenir#

• Un site de synthèse montre vos résultats. Une application dit quoi lire d'abord, retient vos décisions et montre celles du groupe.
• La chaîne : les agents de veille écrivent des lignes, votre meilleur agent en fait des rapports, vous relisez, vous poussez, le site se reconstruit.
• Un rapport sépare ce que dit la source de ce que l'agent explique, et dit ses doutes.
• La première version marche, elle n'est pas pratique. Un tour : lancer, capturer, critiquer, corriger. Puis un testeur qui ne connaît pas le projet.
• Le contenu se partage par git. Le suivi se partage par une API, fermée par un code de groupe : jamais une API ouverte.
• Rien n'est sûr tant que vous ne l'avez pas vérifié : le nombre de nouveautés, deux rapports contre leur source, le suivi à deux navigateurs.