Tu ne peux pas tout suivre. Arrête d'essayer.
Jamais il n’a été aussi facile d’apprendre. Et pourtant, jamais il n’a été aussi difficile de savoir quoi apprendre.
Chaque semaine : un nouveau framework, un nouveau protocole, un nouvel IDE, un nouveau modèle. Sans compter les centaines de vidéos YouTube, les fils LinkedIn, les newsletters, les dépôts GitHub. La réaction naturelle, c’est d’essayer de tout absorber. De s’abonner à plus de newsletters. De suivre plus de gens. D’ouvrir plus d’onglets.
C’est exactement ce qu’il ne faut pas faire.
La veille exhaustive te rend moins compétent
Il y a une idée reçue tenace dans les métiers techniques : rester à jour, c’est lire beaucoup. Le développeur qui suit 40 newsletters tech est forcément plus au courant que celui qui en suit 5.
Sauf que ce n’est pas comme ça que ça fonctionne.
La compétence technique ne se construit pas par accumulation passive d’information. Elle se construit par compréhension profonde et pratique répétée. Les deux prennent du temps. Du temps que la veille exhaustive consomme sans rien restituer.
En pratique, quelqu’un qui passe trois heures par semaine à lire des annonces sur des frameworks qu’il n’utilisera jamais est moins compétent à la fin de l’année que quelqu’un qui a passé ces mêmes trois heures à construire quelque chose, à casser quelque chose, à comprendre pourquoi.
La peur de rater quelque chose d’important, le FOMO, est le moteur principal de la veille exhaustive. Et c’est un très mauvais moteur, parce qu’il optimise pour la couverture, pas pour la profondeur.
Personne ne maîtrise tout. Même ceux qui en parlent le mieux.
Les gens qui produisent le plus de contenu sur l’IA agentique, les créateurs YouTube, les auteurs de newsletters, les conférenciers, ne maîtrisent pas l’ensemble de l’écosystème. Ils ont leurs domaines de prédilection, leurs angles morts. Ce qu’ils ne couvrent pas, ils l’ignorent délibérément ou simplement ne le connaissent pas.
Quelqu’un qui suit de près les modèles et les benchmarks n’a probablement pas le temps de creuser les protocoles d’interopérabilité entre agents. Quelqu’un qui construit des workflows multi-agents au quotidien ne sait peut-être pas exactement comment fonctionnent les fine-tuning récents. L’écosystème est trop large pour une seule tête. C’est inévitable.
Le problème, c’est quand on compare sa propre profondeur partielle à la surface totale de quelqu’un d’autre et qu’on conclut qu’on est en retard.
Tu n’es pas en retard. Tu as juste des priorités différentes.
Ce qui dure, ce ne sont pas les outils
Dans six mois, une partie des frameworks dont on parle aujourd’hui auront disparu. D’autres auront pivoté. Quelques-uns auront survécu et seront devenus des standards. On ne sait pas encore lesquels.
Ce qui ne changera pas : les questions fondamentales.
Qu’est-ce qu’un agent, vraiment ? Comment découper un problème pour qu’un LLM puisse le résoudre par étapes ? Comment gérer un contexte sans qu’il dégénère ? Comment orchestrer plusieurs agents sans que ça devienne ingérable ? Comment évaluer si un système agentique fait ce qu’on lui demande, et pas juste ce qu’il dit faire ?
Ces questions n’ont pas changé avec les frameworks d’hier. Elles ne changeront probablement pas avec ceux d’aujourd’hui. Après ça, qui sait. Mais c’est un horizon à dix-huit mois, pas à six semaines.
Courir après chaque nouveauté, c’est repartir de zéro tous les six mois.
Veille intentionnelle
La question utile n’est pas “qu’est-ce qui sort cette semaine ?”. C’est : est-ce que cette information change quelque chose à ce que je fais dans les prochaines semaines ?
Pas “est-ce que c’est intéressant”. Pas “est-ce que je pourrais en avoir besoin un jour”. Est-ce que ça change quelque chose à maintenant.
Si la réponse est non, l’information peut attendre. Ou disparaître. La plupart des annonces font les deux, dans cet ordre.
Il y a un paradoxe évident dans cette approche : pour décider qu’une information ne vaut pas ton temps, il faut d’abord savoir qu’elle existe. Le tri suppose l’exposition. Un titre suffit à déclencher la curiosité, et la curiosité n’a pas de bouton off.
C’est pour ça que le filtre ne peut pas être uniquement personnel. Personne ne peut lire 200 titres par jour et s’arrêter là. Le vrai levier, c’est de déléguer le tri en amont : suivre quelques personnes dont le jugement a déjà prouvé sa valeur plutôt que de tout scanner soi-même. Accepter que leur filtre laissera passer des choses imparfaites. Accepter surtout qu’il en bloquera d’autres que tu ne verras jamais. Et que ça ira quand même.
Concrètement : dix sources solides plutôt que cent moyennes. Des plages de lecture délibérées plutôt qu’un flux continu qui s’intercale entre deux tâches. Et surtout, la permission de ne pas lire quelque chose juste parce que “tout le monde en parle”.
Arriver un peu en retard sur une technologie qui a survécu à l’effet d’annonce est presque toujours préférable à être parmi les premiers sur une technologie qui disparaît trois mois plus tard.
Construire plutôt que consommer
Lire dix articles sur un framework apporte souvent moins qu’une heure passée à l’utiliser. Pas en suivant un tutoriel pas à pas, mais en l’utilisant sur un vrai problème, même petit. Créer un agent qui fait quelque chose d’utile. Tester un protocole sur un cas concret. Modifier un prompt et observer ce qui change.
C’est comme ça que se construisent les intuitions qui durent, pas en lisant des résumés d’articles sur ce que d’autres ont construit.
Et l’autre avantage de construire : ça révèle naturellement ce qu’on ne comprend pas encore. Une heure de pratique génère de vraies questions. Ces questions guident la veille suivante. La veille devient utile parce qu’elle répond à quelque chose de précis, pas parce qu’elle remplit un quota.
L’objectif n’est pas de tout connaître. Il ne l’a jamais été. On s’était juste convaincu du contraire parce que le volume d’information disponible était encore gérable.
Ce n’est plus le cas.
Dans un domaine qui évolue aussi vite, savoir ce qu’on peut ignorer est au moins aussi utile que savoir ce qu’on doit apprendre.