Les tâtonnements rencontrés en ajoutant une fonction de fact-checking IA à une communauté politique

Bonjour.
Je suis le développeur qui vous avait présenté il y a environ six mois le service de participation citoyenne « Eoheung », qui permet de consulter facilement des projets de loi et de laisser son avis.

Cette fois, nous avons introduit une fonction de fact-checking IA pour tenter de réduire les fake news et les polémiques stériles dans la communauté, et je voudrais partager les réflexions et les tâtonnements techniques rencontrés au cours du processus.

Au départ, j’ai abordé le sujet de manière très simple. Je fournissais le texte cible et j’écrivais un prompt du type : « Vérifie si ce texte est vrai ». Mais une fois déployé en conditions réelles, une série de problèmes imprévus est apparue.

Le système essayait de fact-checker jusqu’aux simples 'opinions' personnelles comme s’il s’agissait de faits, et il tirait des conclusions plausibles même sans fondement. En plus, si l’auteur modifiait le texte après la fin du fact-checking, on se retrouvait avec une situation absurde où le résultat ne correspondait plus au contenu vérifié.

Au final, nous avons jeté toute l’architecture initiale, et nous exploitons désormais le système après avoir largement remanié le pipeline, comme suit.

1. Sélection des éléments à vérifier (opinion vs fait)

Au lieu de vérifier l’ensemble du texte d’un seul coup, nous avons commencé par extraire uniquement les « affirmations factuelles » pouvant être vérifiées objectivement. Les jugements de valeur comme « cette politique est catastrophique » sont ignorés, tandis que seules des phrases comme « ce projet de loi augmente les impôts de 20 % » sont prises comme cibles.
Pour comprendre précisément le contexte, nous ne regardons pas seulement le texte cible : nous regroupons aussi le post original, le commentaire parent, et même les images jointes dans une approche multimodale afin de fournir ce contexte à l’IA.

2. Lui faire répondre « je ne sais pas »

C’est l’un des points sur lesquels nous avons été le plus vigilants. Pour limiter les hallucinations propres aux LLM, nous avons fortement encadré le prompt afin que, lorsqu’il manque des sources fiables permettant une vérification croisée ou qu’un sujet n’est pas vérifiable, le modèle ne force pas une conclusion et réponde plutôt par « impossible à déterminer » ou « jugement réservé ».

3. Conservation d’un snapshot du texte original et transparence des sources

Pour empêcher les problèmes liés à la modification des messages par leur auteur, nous conservons tel quel le texte original (snapshot) au moment exact où le fact-checking est demandé. Ainsi, lorsque d’autres utilisateurs consultent le résultat, ils peuvent voir de manière transparente « sur quel texte / quelles images et à quel moment la vérification a été faite » ainsi que « quelles sources ont été utilisées ».

4. Gestion du trafic et des ressources

Comme ce processus de récupération du contexte et de vérification est lourd, nous avons dû mettre en place une gestion de file d’attente pour les utilisateurs. Toutes les requêtes sont donc envoyées dans une file asynchrone via Redis Cluster + BullMQ, puis traitées séquentiellement par des workers en arrière-plan.
En tenant compte du coût et de la vitesse, nous utilisons Gemini 3.5 Flash comme modèle principal, avec un fallback vers Gemini 3.1 Pro lorsque le taux d’erreur augmente ou que des raisonnements complexes échouent.
(Pour éviter les demandes abusives, nous avons aussi instauré une limite : une utilisation gratuite par jour, puis déduction de points dans l’application.)

Des défis encore en cours

Même si nous avons mis en place notre propre logique défensive, il reste beaucoup de cas difficiles. Lorsque les statistiques ne reposent pas sur la même période de référence, lorsqu’une déclaration comporte des métaphores ou des interprétations propres au discours politique, ou encore dans de longs textes mêlant habilement faits et mensonges, il reste difficile d’obtenir un traitement parfaitement fiable.

Vous pouvez tester directement cette fonction dans l’application Eoheung.
Si vous avez des conseils sur des techniques de prompt permettant de mieux contenir les hallucinations dans ce type de logique de vérification, ou des idées UX/UI pour aider les utilisateurs à mieux accepter des résultats ambigus, je serais ravi de les entendre. Merci d’avoir pris le temps de lire ce long message !

Google Play : https://play.google.com/store/apps/details?id=kr.uhheung.app
App Store : https://apps.apple.com/kr/app/%EC%96%B4%ED%9D%A5/id6751951353