Je construis une veille agentique sur la tech chinoise depuis trois mois. J’y ai appris une règle de gouvernance : un système d’IA fiable se construit en retirant au modèle tout ce qui peut être scripté, en traçant le reste, en lui fournissant de bonnes données et en gardant la main dessus !

Depuis le 23 juillet 2026, je publie chaque jeudi une veille sectorielle autour de l’actualité technologique chinoise et taïwanaise. Quatorze éditions sont parues, plus un hors-série. Derrière chacune, un moteur maison – str puis alfa – prépare les sources, écarte le bruit et prépare un dossier de travail. Ce carnet raconte comment ce projet me fournit – outre apprendre sur le sujet lui-même – un cadre d’expérimentation de l’IA agentique, et comment j’ai appris à retirer des tâches aux LLM plutôt qu’à leur en confier.

Pour les premiers numéros, j’ai défini une structure que je garde encore aujourd’hui : d’abord les modèles d’IA, la partie émergée de l’iceberg ; puis le hardware, plus enfoui ; après une verticale robotique ; ensuite les rétroactions géopolitiques ; enfin la régulation et plus récemment, la standardisation, qui demeure un important levier de puissance. Les tâches de veille sont d’abord passées par des modèles de langage : chercher, lire, trier, résumer, citer. Les modèles m’ont inventé des URLs et du contenu que je devais revérifier pendant des heures.

Au fur et à mesure, le LLM est devenu un orchestrateur d’un outil de curation en ligne de commande, str, qui générait des rapports sectoriels à partir de ce qu’il avait vu. Puis s’est ajouté un embryon d’Event Store, traitant chaque source comme une entrée immuable dans le système avec une phase de pré-qualification. Rejointe par une autre base de connaissances dédiée, organisée autour de l’écosystème technologique chinois et taïwanais. En ce moment, j’y ajoute une ontologie et un knowledge graph.

Créer le moteur lui-même et le calibrer en parallèle des activités d’édition a pesé lourd sur mon temps libre. J’ai d’abord utilisé Gemini pour le code pour le premier moteur qui s’est révélé devenir incontrôlable, avant d’explorer un autre moteur avec Astra d’OpenAI, dont les crédits fondaient comme neige au soleil, mais m’a permis d’ancrer dans le code des spécifications de plus haut niveau et d’améliorer les instructions passées au modèle avant de reprendre les choses avec Claude Code. Je jongle entre les modèles.

Sinotech Radar est donc plus qu’une veille, c’est à la fois un outil qui me permet de faire l’expérience de l’IA agentique, tester des modèles en ayant les mains dans le cambouis. C’est aussi un outil qui me permet d’explorer de nouvelles manières de structurer les connaissances et de les organiser, bref, de faire de la meta-data. Je profite en cela de quelques années passées comme analyste cyber à faire de la veille, concevoir et développer moi-même mes propres outils de travail.

Aujourd’hui, cette expérience m’a permis de préciser cette conviction : un système agentique fiable se construit en retirant toutes les tâches déterministes au modèle. Il ne garde que ce qu’un script ne sait pas faire et là où il est excellent : la sémantique, le rapprochement probabiliste, qualifier la pertinence d’un sujet. Le reste doit être tracé.

Le chantier en bref

Le moteur, alfa, pèse environ 4600 lignes de code, encadrées par des tests. Exécuté en local sur ma machine, il crawle un certain nombre de sources venant de supports différents : flux RSS divers, les newsletters que je reçois par mail, dépêches taïwanaises, pages de l’administration chinoise, etc., et interroge un SearXNG local avec des requêtes spécifiques, majoritairement en anglais et en chinois. La qualification des sujets est, suivant le contexte, confiée à un modèle local, comme Qwen3.6-35B-A3B-MLX-8bit ou à DeepSeek pour leur maîtrise du mandarin.

La collecte ramène les sujets bruts, rien à ce stade n’est lu par le modèle. Vient ensuite un lexique, déterministe, qui contient une liste de termes et écarte ce qui n’a aucun rapport avec le périmètre. C’est un étage volontairement bête, mais lisible et auditable en peu de temps.

Pour qu’un article soit qualifié, il doit être rattaché à au moins l’une des questions de méthode suivantes :

• capabilities : Qu’est-ce que les acteurs deviennent capables de faire ?
• builders : Qui construit ces capacités et avec quels moyens ?
• decisions : Qui décide, et comment ?
• dependencies : Qui dépend de qui ? Où sont les goulots d’étranglement ?
• uses : Quels usages prennent ? Lesquels ne trouvent pas leur marché ?
• understanding : Qu’est-ce qui oblige à revoir notre compréhension ?

Ces éléments sont implémentés dans les instructions passées au modèle, sont tronquées par le code à deux items pour éviter les bavardages et apparaissent dans le brief quotidien généré par le rapport de veille.

Vous imaginerez aisément que, l’actualité et la profusion de sources aidant, ces outils sont assez efficaces. Le modèle qualifie la pertinence de chaque sujet, raisonnement désactivé, et répond en JSON. Il ne produit pas l’URL d’un sujet et des filtres dégagent les URLs non profondes, c’est-à-dire ne renvoyant pas à un article précis. Des vérifications HTTP sont faites pour donner à chaque article un statut d’accessibilité.

Le filtrage constitue cependant une limite et peut sélectionner arbitrairement des signaux faibles qui pourraient pourtant m’intéresser. C’est pourquoi une veille manuelle reste indispensable, pour réinjecter de la nouveauté dans le système. Environ 650 documents entrent dans la veille hebdomadaire, une petite dizaine à la main, 250 sont qualifiés par le modèle et une trentaine sont publiés. C’est sans doute beaucoup, mais l’actualité est dense.

En général, j’interviens ici : un front me permet d’avoir accès au produit de la veille, qui se déroule deux fois par jour, à la présélection et préqualification qui a été faite pour choisir les articles qui entreront ou pas dans l’édition de la semaine, qui sont gardés pour suivi ou au contraire écartés. En un clic, je peux envoyer un modèle croiser les sources similaires et enrichir l’information. Le passage par les sources chinoises est obligatoire.

En ligne de commande, ou en passant par un modèle, je génère l’édition de la semaine, qui garde ma sélection et embarque les textes que j’ai écrits pour chaque article qui entre. Quand le temps me manque, un modèle propose un premier jet de résumé à partir de la source. Je le relis, je le corrige et je vérifie chaque chiffre contre l’article d’origine avant publication. L’édito, lui, reste entièrement de ma main.

Une fois que j’ai vérifié la cohérence des textes et des liens, j’écris l’édito, j’envoie le texte à Gemini qui me génère une image à partir d’un prompt, toujours le même, et j’envoie sur LinkedIn et Substack.

Tracer

Chaque étape est tracée dans un Event Store, disais-je. Une simple base SQLite organisée en journal d’événements enregistre la capture d’un document, la découverte d’un sujet, sa qualification par le modèle, ma sélection et les corrections que j’apporte, sa promotion dans la base de connaissances, les échecs de collecte ou la sauvegarde d’une édition. Mes propres décisions sont également journalisées.

Ce journal est immuable par construction : des triggers SQL refusent toute modification ou suppression sur les tables, les documents originaux sont conservés avec une empreinte SHA-256, chaque commande porte également une empreinte qui empêche de la rejouer plusieurs fois avec un résultat différent. Les URLs déjà vues sont retenues et exclues des nouvelles recherches.

Cette trace permet simplement d’auditer le système et de répondre à des questions précises : pour tout sujet qui a été publié, de quelles pages vient-il, par quels modèles a-t-il été qualifié, qui l’a retenu et quand ?

Projections

Quand on a de bonnes données en entrée, journalisées, il devient plus facile de faire des projections, une notion d’archhitecture logicielle qui consiste à produire une vue dérivée et dénormalisée, prête à l’emploi, à partir d’un journal d’événements. c’est-à-dire d’extraire les données de la base de données et de la base de connaissances pour les assembler de manière particulière. La matière extraite des articles permet de générer un graphe des acteurs : qui apparaît dans quel sujet, avec qui, quelles fiches manquent encore.

Les fiches reposent dans un vault Obsidian dédié exposant une interface en ligne de commande et déclarent leurs liens dans un frontmatter relativement normé : telle boîte fondée par untel, dirigée par untel, concurrente de untel, utilisant le matériel de untel, etc. Rien n’est écrit en base, le graphe est recalculé à partir des sujets qualifiés et des fiches. Pour le moment, le vocabulaire de relations est gardé frugal par design, le RDF et l’OWL sont un chantier en cours.

Ce graphe peut être projeté dans un front qui va l’utiliser (Obsidian gère également très bien cela) et permettre l’exploration des liens à la main.

Corrections de cap

Laya est un modèle de décision sorti peu de temps après Jev, qui a défrayé la chronique. Contrairement aux LLM qui génèrent du texte, les modèles de décision reçoivent du contexte, de l’information, et renvoient une décision simple : oui / non, une sélection dans une liste, ou un score. J’avais branché ce modèle sur trois questions typées : portée géographique, pertinence stratégique, priorité. Je l’ai désactivé au bout de deux semaines après un benchmark : il écartait de bons sujets.

Le problème de placer un filtre en amont, je l’ai déjà évoqué, est qu’il rejette silencieusement des éléments qui pourraient être bons. Il est cependant utile, parce qu’il m’évite de devoir passer du temps à lire des contenus sur les relations entre le cognac français et les consommateurs chinois, par exemple. Sujet passionnant, mais qui n’entre pas dans le cadre de mes recherches. Une commande de vérification permet de rejouer les choix posés sur les archives brutes pour les envisager sous plusieurs angles.

Après chaque édition, une commande spéciale compare les sujets de l’édition publiée avec ce que le moteur alfa avait capté et catégorise chaque sujet, note si j’ai ajouté le sujet à la main, s’il a été collecté mais non qualifié, etc. Elle permet d’évaluer la pertinence de la couverture et de faire évoluer le périmètre en ajoutant du nouveau et de la correction dans le système (feedback loop). C’est le régulateur ou l’homéostat qui permet de réinjecter de nouveaux acteurs, un vocabulaire émergent ou de nouveaux canaux.

Je me suis aussi aperçu qu’un certain nombre de modèles ont du mal à négocier les ordres de grandeur entre les devises. Dans les langues occidentales, ils changent tous les trois zéros (mille, millions, milliards). En chinois, ils changent tous les quatre zéros. Une autre raison tient à la tokenisation des termes en chinois et au traitement par corrélation statistique des LLM à qui il n’est pas demandé une rigueur particulière. Je soupçonne également les erreurs de conversion fréquentes dans les données d’entraînement. Raison de plus pour vérifier !

J’utilise beaucoup de modèles locaux, comme Qwen 3.6, déjà cité. Ils sont bons, mais comme l’inférence locale fait souvent grimper d’un coup le besoin de performances de la machine, scripter ce qui est déterministe est aussi un moyen d’avoir une consommation plus frugale et de gagner du temps d’exécution. Je passe également par de petits modèles d’embedding pour faire de la clusterisation et assembler ainsi des articles qui relaient – parfois différemment – le même sujet ou qui traversent les mêmes thématiques.

Découpler

L’architecture est centrée sur le journal d’événements : collecte, curation, édition, le front ou le serveur MCP y lisent ou y écrivent avec chacun leur responsabilité. Le modèle en lui-même n’est qu’une dépendance injectée et l’outil dans son ensemble doit y demeurer agnostique. La brique de tri ne sait pas si elle parle à Qwen en local, aux API de DeepSeek ou à Claude, voire même à un modèle de décision Jev-like comme Clef, de Cloudflare ou Kev que je vais peut être ajouter d’ici quelques semaines au banc d’essai.

Je m’inspire en cela du Domain Driven Design et de la Clean architecture : le code est structuré par le vocabulaire du domaine et ses contraintes (cf. les questions de méhode ci-dessus) et la technologie doit s’y brancher en périphérie. Ce découplage architectural est essentiel dans un écosystème en constante évolution : les modèles eux-mêmes deviennent des commodités, exposent des interfaces ou des protocoles standardisés (APIs, MCP). Utiliser ces interfaces permet à l’architecture de vivre avec les évolutions techniques.

Quels apprentissages sur la gouvernance de l’IA ?

J’ai l’impression d’avoir fait, sur ce cas d’usage précis, le mouvement inverse de beaucoup : après m’être heurté aux impasses du « tout LLM », j’ai progressivement recalibré l’outil pour qu’il me laisse la place dont j’ai besoin, en tant qu’analyste d’un sujet et responsable de la publication. Cette maîtrise reste nécessaire pour conserver une distance sur la production qui est faite. Les arbitrage d’architecture sont au service de l’exercice critique.

Je suis mon propre utilisateur, certes, et les retours des lecteurs sur la newsletter permettent d’interroger les cas d’usage :

1. Quelle est la finalité, qu’est-ce qui entre dans ce périmètre, qu’est-ce qui n’en relève pas ? La finalité reste de livrer toutes les semaines. Le lexique et la revue d’édition fixent le périmètre. Une revue mesure les écarts et permet de les réduire.
2. Quelles données doivent entrer, comment, avec quel niveau de qualification et lesquelles doivent être exclues ? Ici, uniquement des sources publiques. Les URLs viennent toujours du document collecté, jamais du modèle.
3. Où se situe le point de contrôle humain (human in the loop) ? Qu’est-ce qu’il peut déléguer ? Qu’est-ce qu’il ne délègue pas ? Je garde le contrôle sur l’outil, je sélectionne, j’écris et je corrige les résumés assistés par IA.
4. Comment prend-on conscience de l’erreur ? Comment la mesure-t-on, y compris lorsqu’on ne la voit pas ? Elle se mesure dans l’écart entre la couverture et ce qui est réellement publié, entre le tri et ce qui a été supervisé par l’humain.
5. Peut-on reconstituer une décision après coup, qui l’a prise, sur quelle source, avec quel modèle ? *L’architecture basée sur des événements (Event Sourcing) traite chaque article comme une trace que l’on peut rejouer. *
6. Quels sont les critères qui déclenchent le décommissionnement d’une brique ? La pertinence et l’efficacité : Laya, qui n’était pas le bon modèle pour mon cas d’usage et rejetait les bons sujets.

À mon sens, toutes les organisations peuvent – et doivent – répondre à ces questions. Les réponses ne viennent pas tant des modèles et de leur puissance que de l’écosystème au sein duquel ils évoluent : la qualité des données, le découpage des contextes, des méthodes, des standards, de l’ingénierie et du monitoring et surtout, une maîtrise – par l’humain – de la chaîne de production de valeur.