Idée principale

Un système de veille construit avec Claude Code récupère les vidéos, les articles et les newsletters, les traduit, les classe, les historise et les actualise. Ce que faisait un Product Manager pendant des heures se fait sans lui. Mais le travail ne tombe pas à zéro : il change de nature.

Il faut dire ce qu'on cherche et ce qu'on écarte, vérifier que le système n'a pas silencieusement raté une source, relire ce qu'il a produit, tester après chaque modification, et reprendre la main quand il se trompe lourdement — ce qui arrive, parfois juste après avoir fait quelque chose de brillant.

Le solde reste largement favorable, mais il se compte en nature de travail autant qu'en heures : on échange une exécution longue et prévisible contre une supervision courte et irrégulière.

Couche apportée par « La qualité appartient à ceux qui livrent » (2026-06-03). Le même déplacement s'observe sur le métier de QA, et il y prend une forme plus nette. Ce qui part est l'exécution répétitive : les tests manuels rejoués, les régressions reprises écran par écran à chaque livraison. Ce qui reste est le cadrage — définir quoi vérifier, sur quels risques, avec quels critères et à quel niveau d'automatisation. Le déplacement n'est donc pas seulement quantitatif : il change la position de la fonction dans la chaîne, puisque le cadrage doit être écrit avant que le code existe alors que l'exécution ne pouvait venir qu'après.

Couche apportée par « Quatre jours de vibe coding… » (2026-07-28). Le déplacement prend une troisième forme quand ce qui est délégué n'est plus une tâche annexe mais la construction elle-même. Plus de cent quatre-vingts commits en quatre jours, sans écrire une ligne : ce qui reste est de piloter, relire, tester, corriger, décider, reprendre, surveiller, réexpliquer. La charge ne baisse pas, elle change de rythme — au lieu d'une exécution longue et régulière, une supervision continue calée sur la vitesse de l'outil. C'est l'aspect qui manque aux bilans euphoriques : la puissance n'est pas gratuite, et celui qui pilote devient à la fois architecte de proximité, testeur, relecteur et garde-fou.

Pourquoi c'est important

Cela évite deux erreurs symétriques dans l'évaluation d'une automatisation : compter le gain comme si la tâche disparaissait entièrement, et conclure qu'elle n'a rien changé parce qu'un reste subsiste.

Cela dit aussi quelle compétence devient nécessaire : savoir cadrer une demande et détecter une sortie fausse, plutôt que savoir exécuter la tâche vite.

Nuances et limites

La supervision est irrégulière, donc mal estimée : elle ne coûte presque rien pendant des semaines, puis beaucoup le jour où une sortie fausse est passée inaperçue et a servi de base à une décision.

Et elle ne peut pas être déléguée à quelqu'un qui n'aurait jamais fait la tâche à la main : reconnaître une veille qui a raté l'essentiel suppose de savoir à quoi ressemble une veille correcte.

Questions ouvertes

• Sur quels signaux repérer qu'une sortie automatisée est fausse, quand on a justement cessé de produire la matière soi-même ?