J'avais 47 flux RSS. Oui, 47. Plus trois newsletters quotidiennes, GitHub Trending en bookmark, et un onglet Twitter/X semi-ouvert « juste pour suivre quelques devs ». Le résultat : deux heures par semaine à scroller, une vague impression d'être à jour, et la découverte en prod d'un breaking change dans une lib Go que j'aurais dû voir passer six semaines plus tôt.
J'ai changé d'approche. Pas parce que l'IA est magique — elle ne l'est pas — mais parce que le problème n'était pas le volume d'information. C'était le fait que je lisais sans synthétiser, je consommais sans retenir. J'ai restructuré ma veille autour de ce constat, et l'IA est devenue un outil dans ce processus, pas le cœur du dispositif. Ce que je décris ici est centré sur la veille technique. Pour une approche plus rigoureuse de la recherche sur des sujets complexes — antitrust, géopolitique, fact-checking — j'ai formalisé un protocole distinct dans l'article sur la recherche avec l'IA : sources primaires et étiquetage de certitude.
Le problème avec la veille classique
GitHub Trending est utile pour découvrir des projets sympas un vendredi soir. C'est une très mauvaise source pour suivre l'évolution d'un écosystème. Ce qui remonte, c'est ce qui a eu beaucoup d'étoiles cette semaine — souvent un side-project bien marketé, un générateur de README avec une belle démo, ou un repo de ressources « awesome-quelque-chose ». Les changements importants dans le langage lui-même, les deprecations silencieuses, les migrations d'API : ça ne remonte pas.
Les newsletters, c'est pareil. Golang Weekly envoie 15 liens par semaine. J'en lisais trois en entier, je survolais les titres des autres, et j'avais la sensation d'avoir fait ma veille. En réalité, je collectionnais des onglets ouverts. Le ratio signal/bruit est mauvais parce que ces agrégateurs optimisent pour l'engagement, pas pour la pertinence par rapport à ton stack précis et tes projets en cours.
Le vrai problème : on consomme de l'information de manière passive, sans jamais se demander « qu'est-ce que ça change pour moi, concrètement, cette semaine ? ». Cette question, personne ne te la pose à ta place — sauf si tu construis un système pour ça.
La méthode en pratique
Je n'ai pas tout supprimé. J'ai fait le tri sur ce qui méritait d'être gardé comme source primaire, et j'ai défini ce qui passerait par un filtre IA.
Ce que j'ai gardé, non filtré :
- Les release notes officielles Go — lues en entier à chaque release mineure
- Le changelog PostgreSQL — surtout les sections sur les index, les plans d'exécution, et les fonctions JSONB
- Le blog Symfony — filtré manuellement, une fois par mois
- Hacker News Weekly — le digest hebdo, pas le flux temps réel
Ce qui passe par l'IA :
- La synthèse de changelogs longs (Go release notes font parfois 3000 mots)
- La détection de breaking changes potentiels sur mon stack précis
- Les questions ciblées après lecture d'un titre intrigant que je n'ai pas le temps de creuser
La fréquence est hebdomadaire, pas quotidienne. Quotidien, c'est du bruit déguisé en discipline. Une session structurée par semaine, avec un output concret (un fichier markdown de digest), ça change tout.
Exemples de prompts que j'utilise réellement :
# Après une release Go
"Voici les release notes de Go 1.25. Je travaille principalement avec des goroutines,
des channels, sync/atomic, et le package net/http pour des APIs REST. Quels sont les
changements qui m'impactent directement ? Quelles deprecations dois-je anticiper ?
Donne-moi une liste priorisée, pas une synthèse générale."
# Après une mise à jour PostgreSQL
"Voici le changelog PostgreSQL 17.x. Mes cas d'usage : requêtes JSONB intensives,
index partiels sur des tables > 10M lignes, pg_partman pour le partitionnement.
Qu'est-ce qui change pour moi ? Y a-t-il des comportements qui peuvent modifier
des plans d'exécution existants ?"
# Pour une question ponctuelle
"Dans Go 1.24, qu'est-ce qui a changé dans la gestion du garbage collector
par rapport à 1.22 ? Je cherche spécifiquement l'impact sur les applications
à haute fréquence d'allocation (traitement de messages Kafka)."La différence avec une recherche Google : je pose une question contextualisée à mon stack, pas une question générique. L'IA fait le mapping entre le changelog brut et mes besoins. C'est ça, la valeur ajoutée.
Le workflow automatisé
Au bout de quelques semaines à faire ça manuellement, j'ai écrit un script bash qui tourne
en cron le dimanche matin. Il fetch les sources, construit un prompt, appelle l'API Claude,
et génère un fichier digest dans ~/veille/.
#!/bin/bash
# weekly-digest.sh — Veille tech automatisée
# Nécessite : ANTHROPIC_API_KEY en variable d'environnement
# Usage : chmod +x weekly-digest.sh && ./weekly-digest.sh
set -euo pipefail
DIGEST_DIR="$HOME/veille"
DATE=$(date +%Y-%m-%d)
OUTPUT="$DIGEST_DIR/digest-$DATE.md"
mkdir -p "$DIGEST_DIR"
echo "=== Digest veille tech — $DATE ===" > "$OUTPUT"
echo "" >> "$OUTPUT"
# --- Fetch Go release notes (page releases officielle) ---
echo "[*] Fetch Go release notes..."
GO_RELEASES=$(curl -s "https://go.dev/doc/devel/release" \
| grep -oP '(?<=<h2 id=")[^"]+' \
| head -5)
# Fetch le contenu texte de la dernière release note
LATEST_GO=$(echo "$GO_RELEASES" | head -1)
GO_CONTENT=$(curl -s "https://go.dev/doc/go${LATEST_GO#go}" 2>/dev/null \
|| curl -s "https://tip.golang.org/doc/go${LATEST_GO#go}" 2>/dev/null \
|| echo "Contenu non disponible via curl — voir https://go.dev/doc/devel/release")
# --- Fetch PostgreSQL changelog ---
echo "[*] Fetch PostgreSQL changelog..."
PG_CONTENT=$(curl -s "https://www.postgresql.org/docs/release/" \
| grep -A 2 'class="title"' \
| grep -oP '(?<=>)[^<]+' \
| head -20 \
| tr '\n' ' ')
# --- Construction du prompt ---
PROMPT="Tu es un assistant de veille technique pour un développeur Go/PostgreSQL/PHP senior.
Voici les informations récupérées cette semaine :
## Go — Releases récentes
$GO_RELEASES
## PostgreSQL — Versions récentes
$PG_CONTENT
Mon stack principal :
- Go : APIs REST, goroutines/channels, sync/atomic, net/http, kafka-go
- PostgreSQL : JSONB, index partiels, partitionnement, pg_partman
- PHP/Symfony : APIs secondaires, batch processing
Génère un digest hebdomadaire structuré avec :
1. Les changements Go qui m'impactent directement (si release récente)
2. Les changements PostgreSQL à surveiller
3. Les points de vigilance / breaking changes potentiels
4. Ce que je peux ignorer sans risque cette semaine
Format : Markdown. Sois concis et priorisé. Si tu n'as pas assez d'info sur une version précise, dis-le clairement plutôt que d'inventer."
# --- Appel API Anthropic ---
echo "[*] Appel API Claude..."
RESPONSE=$(curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "{
\"model\": \"claude-opus-4-6\",
\"max_tokens\": 1024,
\"messages\": [
{
\"role\": \"user\",
\"content\": $(echo "$PROMPT" | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()))')
}
]
}")
# Extraire le texte de la réponse
DIGEST_CONTENT=$(echo "$RESPONSE" | python3 -c "
import json, sys
data = json.load(sys.stdin)
if 'content' in data and len(data['content']) > 0:
print(data['content'][0]['text'])
else:
print('Erreur API:', data.get('error', {}).get('message', 'Réponse inattendue'))
print('Raw:', json.dumps(data, indent=2))
")
# --- Écriture du digest ---
echo "$DIGEST_CONTENT" >> "$OUTPUT"
echo "" >> "$OUTPUT"
echo "---" >> "$OUTPUT"
echo "*Généré le $DATE — vérifier les sources primaires avant toute action.*" >> "$OUTPUT"
echo "[OK] Digest écrit dans $OUTPUT"
Pour l'automatiser le dimanche à 8h :
# crontab -e
0 8 * * 0 ANTHROPIC_API_KEY=your_key_here /path/to/weekly-digest.sh >> /var/log/veille.log 2>&1
Note : je mets la clé API directement dans le cron plutôt que dans un .env
pour éviter de sourcer un fichier dans un contexte cron. Sur un serveur partagé, utiliser
plutôt un fichier de credentials avec les bonnes permissions (chmod 600).
Le digest s'ouvre automatiquement dans mon éditeur le dimanche matin via une autre ligne cron. Dix minutes de lecture ciblée plutôt que deux heures de scroll.
Ce que ça change concrètement
Trois exemples réels depuis que j'utilise ce workflow :
sync/atomic en Go : le digest m'a signalé assez tôt les changements dans
le package sync/atomic avec l'introduction des types génériques (atomic.Int64,
atomic.Pointer[T]). J'avais du code qui utilisait les fonctions bas niveau
(atomic.AddInt64) dans un compteur de métriques. J'ai pu planifier la migration
sereinement, avant que ça devienne une dette technique invisible.
PostgreSQL JSONB : les évolutions du planificateur de requêtes autour de JSONB en PG16/17 ont des implications sur les index. Sans le digest, j'aurais probablement découvert le comportement changé en lisant un EXPLAIN ANALYZE bizarre un mardi à 23h. Avec le digest, j'ai lu la note de release et ajusté mes index en avance.
Le gain principal n'est pas la détection : c'est l'état d'esprit. Je ne lis plus des changelogs en mode anxieux « est-ce que j'ai raté quelque chose d'important ». J'ai un process. Ça change le rapport à l'information.
Les vraies limites
Ce serait malhonnête de ne pas en parler. L'IA dans ce workflow a des angles morts réels.
Les hallucinations sur les versions. C'est le problème numéro un. Claude — comme tous les LLMs — peut inventer un numéro de version, confondre deux releases, ou affirmer qu'une feature est disponible depuis Go 1.21 alors qu'elle l'est depuis 1.23. La règle : le digest est un point de départ, jamais une source de vérité. Chaque point signalé comme important doit être vérifié dans la release note officielle avant d'agir. J'ai ajouté la mention explicite dans le prompt (« si tu n'as pas assez d'info sur une version précise, dis-le clairement ») — ça aide, mais ça ne supprime pas le risque.
Le biais de confirmation. Quand je demande « qu'est-ce qui impacte mon stack Go », l'IA tend à me donner ce qu'elle pense que je veux entendre. Si je travaille beaucoup avec les channels, elle va sur-indexer les changements sur la concurrence. Elle ne me dira pas spontanément que la vraie nouveauté de la release, c'est une amélioration du tooling de profiling — si je n'ai pas mentionné que ça m'intéresse. Le prompt doit être calibré régulièrement pour éviter de créer une chambre d'écho.
Ce que ça ne remplace pas. Une conférence GopherCon, c'est trois jours à entendre des gens qui ont des problèmes à l'échelle que je n'ai pas encore, et à comprendre comment ils les ont résolus. Aucun digest ne remplace ça. Un collègue senior qui dit « attention, j'ai essayé cette approche en 2023, ça mord » — ça non plus. Et lire un post-mortem en entier, avec la chronologie, les décisions prises sous stress, les erreurs assumées : c'est une forme de transmission qui ne passe pas par un résumé.
Le coût et la dépendance. L'API Anthropic coûte de l'argent. Pas beaucoup pour un digest hebdomadaire (quelques centimes par appel avec claude-opus-4-6), mais c'est un service externe avec ses propres aléas de disponibilité et de pricing. Et si l'API change, le script casse.
Le risque de ne plus vraiment lire. C'est le plus insidieux. Déléguer la synthèse, c'est risquer de déléguer aussi la compréhension. Si je ne lis plus jamais une release note en entier, je vais perdre le sens du détail, la capacité à repérer moi-même ce qui compte. Le digest doit rester un filtre d'entrée, pas un substitut à la lecture.
Ce que ça remplace, ce que ça ne remplace pas
Ce workflow remplace la lecture de changelogs bruts de 3000 mots quand je cherche deux informations précises. Il remplace aussi la synthèse manuelle de dix articles qui disent tous la même chose avec des mots différents. Il m'a libéré du sentiment d'obligation de tout lire pour ne rien manquer.
Il ne remplace pas la curiosité. Si je ne me pose pas la question « qu'est-ce qui a changé dans la gestion mémoire de Go ces deux dernières versions », aucun script ne va la poser pour moi. L'IA exécute un processus — elle n'en génère pas.
Il ne remplace pas l'expérimentation. Comprendre vraiment un changement dans le scheduler Go, ça passe par écrire un benchmark, observer le comportement, pas par lire un résumé.
Il ne remplace pas la discussion entre devs. La veille la plus utile que j'ai faite cette année, c'est une conversation de trente minutes avec un autre dev qui avait migré une grosse base PostgreSQL vers le partitionnement natif. Aucun LLM n'aurait pu me donner les mêmes nuances sur ce qui s'est mal passé et pourquoi.
La vraie observation méta : la veille technique a toujours été une question de méthode. Les meilleurs devs que je connais n'ont jamais eu 47 flux RSS — ils avaient trois sources choisies, qu'ils lisaient vraiment. L'IA n'a pas changé ce principe fondamental. Elle l'a juste rendu plus visible en m'obligeant à formaliser ce que je voulais apprendre, pour qui, et avec quelle fréquence. C'est peut-être ça, l'apport le plus durable. Si ce sujet vous intéresse au-delà de la veille — jusqu'aux questions de conscience, d'alignement et de biais structurels — j'ai consacré un article entier à une conversation philosophique de deux heures avec Claude sur ces limites.