Brancher une vérification factuelle dans un pipeline éditorial

Brancher une vérification automatique dans une chaîne de publication est facile. La rendre utile l'est beaucoup moins, et la plupart des intégrations échouent pour la même raison : elles renvoient un verdict sans ce qui permet d'en juger. Un score de 0,72 ne dit rien à un secrétaire de rédaction qui a douze minutes.

Où placer le contrôle

Trois emplacements possibles, et ils ne servent pas la même chose.

• À la rédaction, pendant l'écriture.C'est le plus utile : l'auteur peut encore changer une formulation ou aller chercher une source. C'est aussi le plus exigeant en latence, parce qu'au-delà de quelques dizaines de secondes personne n'attend.
• À la relecture, avant publication. Le meilleur compromis. La latence importe peu, et le relecteur a le mandat de bloquer.
• Après publication, en surveillance. Utile sur les archives et les contenus repris, inutile pour éviter une erreur.

Le placement le plus fréquent est aussi le moins efficace : un contrôle déclenché à la publication mais dont le résultat arrive après. Personne ne le lit.

Ce que le contrôle doit renvoyer pour être exploitable

Quatre éléments, et le troisième est celui qu'on oublie.

• Les affirmations extraites, une par une. Un article n'est pas vrai ou faux, il contient des affirmations qui le sont séparément.
• Un verdict par affirmation, avec un vocabulaire fermé et stable. Trois ou quatre valeurs possibles, pas une échelle continue que chacun interprète.
• Les sources, cliquables, avec leur niveau de fiabilité.C'est ce qui permet à un humain de trancher en dix secondes au lieu de refaire le travail. Un verdict sans sources est un avis, et un avis de machine ne vaut pas mieux qu'un autre.
• Un état explicite quand rien n'a été trouvé.« Pas assez d'éléments » doit être une réponse possible, distincte de « faux ».

Les quatre erreurs qui rendent l'intégration inutile

Bloquer automatiquement la publication

La tentation est forte et c'est une erreur. Un faux positif bloque un sujet légitime, souvent le jour où il est urgent. Le contrôle signale, un humain décide. La seule automatisation raisonnable est le blocage sur une règle explicite et étroite, décidée par la rédaction, pas par l'outil.

Traiter une panne comme un résultat

Si le service ne répond pas, la réponse n'est pas « aucune source trouvée », c'est « contrôle indisponible ». Confondre les deux fabrique de faux verdicts négatifs et détruit la confiance de l'équipe en quelques jours.

Vérifier le texte entier d'un bloc

Un article de 6 000 signes contient trente affirmations dont quatre sont vérifiables et deux comptent. Envoyer le tout produit un résultat moyen sur un ensemble hétérogène, c'est-à-dire rien. L'extraction par affirmation n'est pas un raffinement, c'est la condition.

Ne pas conserver la réponse

Une vérification non archivée doit être refaite à la première contestation, avec des sources qui ont changé entre-temps. Stocker la réponse complète, avec sa date, coûte quelques kilo-octets.

Les points techniques qui comptent vraiment

La latence d'abord : une vérification sérieuse prend des dizaines de secondes, parce qu'elle va lire des sources. Concevez l'intégration en asynchrone dès le départ, avec un rappel ou un sondage, jamais en attente bloquante dans une interface d'écriture.

La mise en cache ensuite : les mêmes affirmations reviennent, surtout en période électorale ou de crise. Un cache par affirmation normalisée divise le coût et la latence sans rien changer au résultat.

Les quotas enfin : dimensionnez sur les pics, pas sur la moyenne. Une rédaction ne vérifie pas de façon régulière, elle vérifie par rafales.

Pour aller plus loin

• Comment une rédaction trace ses vérifications : ce qu'il faut conserver de chaque contrôle.
• Que signifie la note A, B, C ou D d'un site : comment lire le niveau de fiabilité renvoyé pour chaque source.