Pourquoi la veille technique laisse l'IA proposer et l'humain trancher

Une veille technique automatisée doit résoudre une tension simple : il y a trop d'actualité pour la lire à la main, mais une IA qui publierait seule finirait par diffuser du bruit et des affirmations fausses. Le point d'équilibre retenu ici est un principe de conception, pas une commodité : l'IA débroussaille, l'humain décide. Ce document explique pourquoi ce partage a été choisi, quels risques il neutralise, et comment il se traduit dans le cycle de vie d'un billet.

Pour le détail structurel du composant (entités, contrats, statuts exacts), voir la fiche de reference « Bundle produit doc-IA ». Ce document-ci n'énumère pas ; il explicite les arbitrages.

Deux impasses symétriques

Le choix se comprend en écartant d'abord les deux extrêmes.

L'automatisation de bout en bout : rapide, mais non fiable

Laisser une IA collecter, résumer et publier sans relecture est séduisant sur le papier — coût humain nul, latence minimale. C'est une impasse pour trois raisons.

• Hallucination. Un modèle de langage produit un texte plausible, pas un texte vrai. Sur un résumé d'article technique ou, pire, sur un billet à portée juridique, une affirmation inventée publiée automatiquement engage la crédibilité de celui qui la diffuse. Le risque n'est pas théorique : il est structurel au fonctionnement d'un LLM.
• Bruit. Les flux d'actualité IA débitent des dizaines d'items par jour. Beaucoup sont redondants, promotionnels ou hors-sujet. Une chaîne entièrement automatique publie ce bruit tel quel ; la valeur d'une veille, c'est justement le tri.
• Faux positifs. Un filtre automatique retient inévitablement des items qui ressemblent au sujet sans l'être. Sans jugement final, ces faux positifs s'accumulent et diluent le signal.

Le tout-manuel : fiable, mais impraticable

À l'inverse, tout lire et tout résumer soi-même garantit la qualité mais ne tient pas à l'échelle. Le volume quotidien d'un thème actif dépasse ce qu'un humain peut traiter en continu sans y consacrer un temps disproportionné. La veille devient alors une corvée qu'on finit par abandonner — le pire des résultats.

Le point d'équilibre : proposer n'est pas publier

Entre les deux, la décision de conception est de découper la chaîne au bon endroit. L'IA prend en charge tout ce qui est fastidieux et à faible enjeu de jugement : aller chercher les sources, dédupliquer, extraire le contenu, produire un résumé court avec son lien, proposer un classement thématique. Le résultat de tout ce travail n'est jamais une publication : c'est une proposition.

La distinction est le cœur du dispositif. Une proposition a un auteur non-humain et un statut explicite : elle attend une décision. Publier reste un acte humain. Ce découpage donne le meilleur des deux mondes — le volume est absorbé par la machine, le jugement final reste chez la personne qui engage sa signature.

Ce principe se double d'une règle non négociable : chaque proposition cite sa source avec son lien. Le résumé pointe toujours vers l'original ; il ne s'y substitue pas. C'est à la fois un garde-fou anti-hallucination (le lecteur peut vérifier) et une exigence de respect des sources (résumé et lien, jamais de copie intégrale).

Le cycle de vie d'un billet, lu comme une décision

Le statut d'un item raconte cette discipline. Un billet traverse des états qui matérialisent qui a la main à chaque instant.

• pending — l'item vient d'être collecté et dédupliqué ; la machine ne l'a pas encore traité.
• proposed — l'IA l'a résumé, classé et transformé en proposition. C'est l'état de bascule : la machine a fini son travail, la décision revient.
• accepted — un verdict favorable ; le billet peut rejoindre la veille publiée.
• rejected — écarté ; le billet ne sera pas diffusé.
• failed — le traitement n'a pas pu aboutir (source injoignable, contenu insuffisant). Cet état est un choix de conception à part entière : plutôt que de résumer un titre seul et d'inviter l'hallucination, le pipeline préfère échouer proprement et le signaler.

L'existence même de l'état failed illustre la philosophie : on préfère un manque visible à une fabrication invisible.

Une IA peut aussi pré-trier, sans jamais confisquer la décision

Un raffinement intéressant : le jugement humain peut lui-même être assisté par une seconde passe d'IA, sans que cela ne rouvre la porte à la publication automatique. Après qu'un item est passé en proposed, un second appel au modèle peut émettre un avis — favorable, défavorable, ou incertain — accompagné d'une raison.

Ce qui est instructif, c'est le traitement du cas incertain. Quand l'IA ne sait pas trancher, l'item ne bascule pas : il reste proposed, en attente d'un œil humain. L'incertitude n'est pas résolue par un coup de dé ; elle est escaladée. De même, une réponse du modèle qui serait malformée ou illisible est traitée comme une incertitude, jamais comme un accord tacite. Le doute retourne toujours vers l'humain — c'est le sens du curseur.

Ce mécanisme montre que « human-in-the-loop » ne signifie pas « l'IA s'arrête net et l'humain fait tout le reste ». L'IA peut porter une partie de la charge de jugement, à condition que son avis reste révocable et que l'ambiguïté remonte. La décision engageante n'est jamais déléguée.

La dégradation gracieuse : le cycle ne casse pas sur une erreur d'IA

Un pipeline qui dépend d'un service externe — ici, un appel à un modèle — doit supposer que ce service peut échouer : réseau, quota, réponse inattendue. Le choix de conception est que l'échec d'un appel au modèle ne fait jamais tomber le cycle entier.

Concrètement, deux garanties se combinent.

• Isolation par item. Chaque billet est traité indépendamment. Une erreur sur l'un ne contamine pas le lot ; les autres continuent leur route.
• Erreur loggée, pas propagée. Quand un appel au modèle échoue, l'erreur est enregistrée pour diagnostic mais n'interrompt pas le traitement des items suivants. Le pipeline poursuit ; l'incident est tracé et statuable plus tard.

Ce principe vaut aussi pour les sources elles-mêmes : une source qui échoue de façon répétée est mise en retrait automatiquement (un état distinct de la désactivation manuelle par un humain), signalée comme « à statuer », et un succès ultérieur réarme le compteur. Là encore, l'automatisme écarte et signale ; il ne supprime rien définitivement à la place de l'humain.

La dégradation gracieuse n'est pas un détail d'ingénierie : c'est ce qui rend la promesse « l'humain décide » tenable dans la durée. Un pipeline qui s'effondre à la première anomalie devient ingérable, et l'on finit par tout automatiser ou tout abandonner — les deux impasses qu'on cherchait à éviter.

Déduplication et classement : réemployer le cœur plutôt que réinventer

Deux tâches de la chaîne relèvent de la proximité entre contenus : ne pas proposer deux fois le même billet (déduplication) et ranger un item dans le bon thème (classification). Le choix retenu est d'économiser le jugement humain sur ces deux fronts avant même la relecture.

• Déduplication. Un même article circule sous plusieurs URLs (variantes, paramètres de suivi). Comparer les URLs ne suffit donc pas ; on compare aussi une empreinte du contenu. Un item déjà vu n'est pas re-soumis au résumé — on ne paie pas deux fois, et l'humain ne voit pas de doublon.
• Classement. Un premier niveau de tri par correspondance de termes suffit pour un thème pilote. Mais l'architecture est pensée pour brancher, quand les thèmes se multiplieront, un classement par similarité sémantique réutilisant les embeddings du cœur déjà en place pour la recherche documentaire. La proximité de sens y est plus robuste qu'une liste de mots-clés.

Le point de conception ici est le réemploi. Le moteur de similarité qui sert la recherche documentaire peut servir la veille : une même brique de « cœur » alimente plusieurs surfaces. On évite de bâtir un second système de rapprochement, et l'on capitalise sur un composant éprouvé.

Ce que ce choix démontre

Le fil rouge est une position sur l'automatisation IA : elle est un démultiplicateur de travail, pas un substitut de responsabilité. On automatise massivement le fastidieux (collecte, extraction, résumé, pré-tri), on laisse la machine porter même une part de jugement quand elle est sûre, mais on garde verrouillé le seul acte qui engage — publier — chez l'humain. Les incertitudes remontent, les erreurs sont isolées et tracées, rien n'est supprimé définitivement par un automatisme.

C'est un patron transposable bien au-delà de la veille : partout où une IA traite du volume à enjeu, la question utile n'est pas « peut-on tout automatiser ? » mais « où couper la chaîne pour que la machine absorbe le volume sans jamais confisquer la décision ? ».

Pour aller plus loin

• Reference du composant (entités, contrats, statuts, interfaces remplaçables) : « Bundle produit doc-IA ».