Moins d'outils, plus de décisions : comment je trie l'actualité IA

Le vrai problème n'est pas l'information

Chaque matin, ma boîte mail m'apporte un nouveau modèle, un nouveau serveur MCP, un nouvel agent « qui change tout ». Les newsletters s'empilent, les liens aussi. Lire tout ça est impossible. Tester tout ça serait pire.

J'ai fini par comprendre que la ressource rare n'était pas l'information. C'était la décision. Qu'est-ce que j'adopte, qu'est-ce que je laisse passer, et qu'est-ce que je retire ?

Je travaille au quotidien avec plusieurs agents de code (Claude Code, Copilot CLI) branchés sur mes outils : tickets, tâches, mails, NAS. Ce setup bouge tout le temps. Pour qu'il reste utile, il me fallait un filtre simple, pas un programme de veille.

Deux façons d'échouer

La première, c'est d'adopter trop. Chaque outil gardé devient une surface permanente : une config qui dérive, un token à renouveler, une chose de plus à déboguer au mauvais moment. Le coût se paie tous les mois. Le bénéfice, souvent, une seule fois.

La seconde, c'est de ne rien adopter. Le setup pourrit alors en silence. Les identifiants de modèles épinglés sont retirés par l'éditeur, les valeurs par défaut ne correspondent plus à l'intention de départ, et rien ne lève d'erreur.

Les deux échecs sont coûteux. Le second est plus sournois, parce qu'on ne le voit pas.

Ce que « mieux » veut dire

Avant de juger un outil, il faut savoir ce qu'on cherche. Voici mes critères, par ordre de priorité. Quand deux critères s'opposent, le plus haut gagne.

1. Justesse. Un agent qui se trompe plus vite n'est pas meilleur.
2. Sécurité et vie privée. Ce qui sort de la machine, et vers qui.
3. Coût par tâche terminée, pas par token. Un modèle moins cher qui demande trois essais ne coûte pas moins cher.
4. Réversibilité. Combien de temps pour revenir en arrière ?
5. Complexité. Le nombre de pièces mobiles, de configs et de secrets.
6. Vitesse. Réelle, mais la moins importante des six.

Regardez les annonces des éditeurs : elles parlent surtout de coût et de vitesse. Ce sont justement les deux critères qui comptent le moins ici.

Le filtre en quatre questions

Tout ce qui arrive passe par le même filtre : un lien, un outil, un modèle, une idée de workflow. On s'arrête au premier non. Et la réponse par défaut est non : c'est à la nouveauté de faire ses preuves.

1. Y a-t-il une douleur précise ? Un incident réel, une friction qui revient, une heure perdue. « Ça a l'air intéressant » mérite un marque-page, pas un changement.
2. Est-ce que ça remplace quelque chose, ou est-ce que ça s'ajoute ? Un remplacement part à égalité. Un ajout doit battre le coût de le porter indéfiniment.
3. Peut-on revenir en arrière en moins d'une heure ? Si annuler demande une migration, ce n'est plus un essai. C'est un engagement.
4. Peut-on le tester en une seule session ? Si l'évaluation est un projet en soi, elle devient un ticket. On ne la démarre pas au milieu d'un tri.

Ce qui échoue au filtre ne part pas à la poubelle. Ça va dans une liste de lecture, ou ça devient un ticket. Ça ne change simplement rien aujourd'hui.

Toutes les preuves ne se valent pas

Les quatre questions restent les mêmes. Le niveau de preuve, lui, dépend du type de changement.

• Changer de modèle (passer à la version suivante) : exigence faible. Vérifier le prix et la disponibilité, c'est réversible en une ligne.
• Modifier un prompt ou une skill : exigence moyenne. Un avant/après sur une vraie tâche, pas sur un exemple inventé.
• Changer un workflow : exigence moyenne. Un passage complet de bout en bout, puis on écrit la règle pour ne pas la rediscuter.
• Ajouter un outil, un serveur MCP, une dépendance : exigence forte. Une douleur que rien d'existant ne couvre, et un plan de retrait.

C'est la dernière catégorie qui s'accumule. Ajouter un outil pour contourner un problème créé par un autre outil : c'est la façon la plus courante de dégrader un setup, alors que chaque décision, prise seule, paraissait raisonnable.

Deux pannes que personne n'a vues

En septembre, en relisant mes propres scripts de lancement, j'ai trouvé deux bugs. Aucun ne levait d'erreur.

Le premier : mon lanceur Claude Code utilisait par défaut le mode « opusplan ». L'intention était « prends le meilleur modèle ». En pratique, Opus ne tournait qu'en mode planification, et un modèle plus petit faisait tout le reste. Depuis des mois. J'ai remplacé la valeur par l'alias « opus », qui suit désormais chaque nouvelle version sans que j'aie à y toucher.

Le second : mon lanceur Copilot CLI pointait vers un identifiant de modèle que l'éditeur avait déjà retiré. La valeur par défaut était morte. Je ne l'ai découvert qu'en testant les identifiants un par un.

La leçon n'est pas « vérifiez plus souvent vos noms de modèles ». C'est qu'une valeur épinglée sans date d'expiration est un bug qui attend son échéance.

Retirer fait partie du travail

L'adoption reçoit toute l'attention. Le retrait, presque aucune. C'est pourtant là que la casse se cache.

Ma règle : préférer un alias qui suit la dernière version à un numéro épinglé. Quand aucun alias n'existe, le pin doit être testé à intervalles réguliers. Je n'épingle que là où la reproductibilité l'exige vraiment.

Ça vaut aussi pour la documentation. Un numéro de version écrit dans un fichier de contexte devient faux à la mise à jour suivante, et personne ne le revérifie. Mieux vaut nommer l'outil et indiquer comment lui demander sa version.

Et un pin vit rarement à un seul endroit. Le jour où j'ai débranché un serveur MCP de mémoire, je l'ai archivé proprement… mais un guide d'installation le listait encore. Depuis, retirer un outil commence par une recherche de son nom dans tout le dépôt, et chaque référence est corrigée avant de dire « c'est fait ».

Les pièges que j'évite

• Courir après les benchmarks. Ils mesurent la charge de travail de quelqu'un d'autre. Si je ne mesure pas sur mes propres tâches, je ne parle pas d'amélioration.
• Changer d'outil pour éviter d'apprendre celui qui est déjà installé.
• Épingler une version par réflexe alors qu'un alias existe.
• Adopter sans plan de retrait. Sans réponse à « comment on revient en arrière ? », ce n'est pas un essai.
• Rejuger chaque mois une décision déjà prise. Une décision enregistrée tient jusqu'à ce qu'une nouvelle preuve arrive.

Pas de nouveau rituel

Ce filtre ne m'ajoute pas de réunion ni de tableau de bord. Il se greffe sur ce qui tourne déjà. Mes tris de mails et de tâches classent déjà les éléments entrants : l'actualité IA n'est qu'une catégorie de plus. Mon audit régulier des paquets et des conteneurs vérifie aussi, désormais, les modèles et les outils périmés.

Une fois par trimestre, ou à chaque nouvelle génération de modèles, je fais une revue courte. Je teste chaque identifiant épinglé, je vérifie que les derniers changements ont respecté l'ordre des critères, et je ferme ou je réduis les tickets ouverts sur le sujet.

L'amélioration continue d'un setup d'agents IA, au fond, ressemble à celle de n'importe quel système. Le plus dur n'est pas d'ajouter. C'est de savoir dire non, et de penser à retirer.