Le plafond des 70 % : ce que le benchmark FACTS de Google change pour les projets d’IA en entreprise

Le nouveau benchmark FACTS de Google met en évidence une limite structurelle de l’IA en entreprise : même les meilleurs modèles, dont Gemini 3 Pro, GPT‑5 et Claude 4.5, restent en dessous d’environ 70 % de précision factuelle. Pour les DSI, Directeurs des Opérations et responsables data, ce n’est pas une curiosité de laboratoire mais une contrainte d’architecture.
Cela reconfigure la façon de concevoir les assistants internes, copilotes métiers, agents IA et de piloter le risque.
Cet article explique :
• ★ Pourquoi ce plafond des 70 % existe et ce qu’il implique pour les workflows critiques
• 🔎 Comment traduire les sous‑scores FACTS en stratégies de RAG, d’ancrage (grounding) et de relecture
• 🧩 Comment les stacks no‑code/low‑code peuvent industrialiser les patterns “trust but verify”
• 📏 Quelles questions, KPIs et garde‑fous comptent pour une transformation à grande échelle

1. Le plafond de factualité à 70 % : ce que cela signifie réellement pour les entreprises

FACTS (FActuality Coverage and Trustworthiness Suite) évalue à quelle fréquence les modèles sont objectivement corrects, et pas seulement fluides ou “utiles”. Il mesure à la fois :

• Factualité contextuelle : réponses ancrées dans des données ou documents fournis
• Factualité sur la connaissance du monde : réponses basées sur l’entraînement interne + la recherche web

Sur l’ensemble des scénarios, aucun modèle de pointe ne dépasse ~70 % de factualité. En pratique, cela signifie :

• Dans un contexte non contrôlé, environ 1 réponse sur 3 peut être fausse ou partiellement fausse
• Les erreurs sont souvent assurées, plausibles et difficiles à détecter pour des non‑experts
• Les tâches multimodales (graphiques, images, diagrammes) restent nettement moins fiables

Pour un DSI ou un Directeur des Opérations, cela se traduit par trois contraintes concrètes :

1. L’IA ne peut pas être traitée comme un système de référence (system of record)
   Les LLM sont de puissants moteurs de raisonnement, pas des bases de données faisant autorité. Toute chaîne qui permet à un LLM d’écrire directement dans les systèmes cœur (ERP, CRM, SIRH, comptabilité) sans contrôles solides est structurellement fragile.

2. Le “choix du modèle” ne suffit pas
   Passer du modèle A au modèle B peut faire bouger la factualité de quelques points, mais ne brise pas le plafond des 70 %. L’architecture, la récupération (retrieval) et la gouvernance comptent davantage que la course au “dernier modèle”.

3. Le risque dépend du cas d’usage

   • Pour l’exploration (brainstorming, idéation), 70 % peuvent être acceptables
   • Pour les décisions opérationnelles (tarification, conformité, finances, RH), non
   • Pour les domaines réglementés (santé, juridique, banque), la confiance aveugle est intenable

Le message central : les hallucinations IA ne sont pas un bug d’implémentation ; c’est une caractéristique systémique des modèles actuels. Les systèmes doivent être conçus en partant de cette hypothèse.

2. Lire les sous‑scores FACTS comme des exigences d’architecture

flowchart TD
    A[User visits Website] --> B{Tracking Consent}
    B -->|Accept| C[Browser stores tracking data]
    B -->|Reject| D[Only essential cookies used]
    C --> E[Data sent to analytics platform]
    D --> E
    E --> F[Reports generated from user behavior]

FACTS décompose la factualité en quatre grandes dimensions, avec des implications architecturales directes.

2.1 Paramétrique : pourquoi la “mémoire” du modèle ne peut pas être votre source de vérité

La factualité paramétrique ≈ “Ce que le modèle sait grâce à ses données d’entraînement”.

• Questions de type “quiz”
• Connaissances générales sans outils externes

Même les meilleurs modèles plafonnent ici. L’écart entre les scores paramétriques et search dans FACTS montre que les modèles sont plus fiables lorsqu’ils peuvent aller chercher l’information que lorsqu’ils se reposent sur leurs poids internes.

🔧 Implication d’architecture
Pour l’IA en entreprise, ne jamais se reposer uniquement sur la mémoire paramétrique lorsque :

• Les politiques changent fréquemment (conformité, règles RH, prix, seuils de validation)
• Les données sont confidentielles ou propriétaires (contrats, procédures internes)
• La connaissance métier évolue vite (règles fiscales, catalogues produits, normes médicales)

À la place, systématiser la Retrieval‑Augmented Generation (RAG) :

• Utiliser une base vectorielle pour la recherche sémantique sur le contenu interne
• Fournir au modèle les passages pertinents comme contexte
• Laisser le modèle raisonner à partir des faits récupérés, plutôt que les inventer

Tableau : Où la mémoire paramétrique vs le RAG ont du sens

2.2 Search : RAG et outils live comme choix de design par défaut

Le benchmark Search de FACTS évalue la capacité d’un modèle à utiliser un outil de recherche web. Les scores sont en général plus élevés que les scores paramétriques.

Cela confirme un pattern de conception clé :
Pour les faits critiques, les modèles doivent lire depuis des outils ou bases externes.

Dans les stacks d’entreprise, “search” signifie rarement seulement le web public. Cela inclut :

• Des moteurs de recherche internes sur les wikis et systèmes de gestion documentaire
• Des bases vectorielles (Pinecone, Qdrant, Weaviate, pgvector, etc.)
• Des API métier (ERP, BI, CRM, systèmes financiers, ticketing)

🔧 Implication d’architecture

• Traiter le RAG comme défaut, pas comme un add‑on optionnel
• Exposer des API d’outils aux agents IA (ex. “get_invoice(id)”, “search_policies(query)”)
• Journaliser les appels d’outils pour l’auditabilité et le debugging
• Imposer des droits d’accès et du scoping : le modèle ne doit pas voir plus que ce que l’utilisateur est autorisé à voir

Effective RAG design est souvent plus impactant que de changer de fournisseur de modèle, comme le montre en détail l’analyse des limites des systèmes RAG d’entreprise et de la solution de « sufficient context » de Google dans l’article sur les systèmes RAG d’entreprise.

2.3 Grounding : garder les chatbots internes “dans le script”

Le benchmark Grounding mesure la capacité d’un modèle à rester fidèle au texte source fourni sans inventer de faits supplémentaires.

Pour les assistants internes, le grounding est central :

• Chatbot interne répondant à partir d’une base de connaissances
• Copilote métier qui résume procédures, contrats, tickets
• Agents IA orchestrant des workflows basés sur des règles internes

Sans grounding strict :

• Le bot peut paraphraser correctement mais ajouter des contraintes inexistantes
• Il peut “combler les trous” dans les politiques, créant des règles fantômes ou des droits mal formulés
• Il peut ignorer des cas particuliers ou exceptions pourtant cruciaux pour la conformité

🔧 Implication d’architecture

• Formuler les prompts pour un comportement borné par la source :
  • « Ne réponds qu’à partir des documents fournis. Si l’information n’est pas présente, réponds Je ne sais pas. »
• Exiger des citations / extraits :
  • « Pour chaque affirmation, référence la section pertinente du document. »
• Utiliser des vérificateurs de grounding ou des modèles secondaires pour vérifier que les réponses sont bien supportées par le contexte
• Scorer et journaliser : % de réponses avec citations valides et vérifiables

Le grounding n’est pas optionnel pour la gouvernance des données et l’auditabilité.

2.4 Multimodal : automatiser l’insight, pas l’extraction non supervisée

Les scores Multimodal de FACTS (images, graphiques, diagrammes) sont nettement bas pour l’ensemble des modèles. Même pour les leaders, la précision reste souvent en dessous de 50 %.

Domaines typiquement à haut risque :

• Lecture de graphiques financiers et formulation de conclusions chiffrées
• Extraction de montants sur factures, bulletins de paie, formulaires médicaux uniquement via la vision
• Interprétation de schémas techniques complexes sans connaissance de la structure (schema knowledge)

🔧 Implication d’architecture

• Éviter l’extraction entièrement automatisée à partir de PDF, scans et graphiques sans humain dans la boucle
• Utiliser les modèles pour assister la revue humaine : pré‑remplir des champs, mettre en évidence les anomalies, détecter les éléments manquants
• Combiner OCR / parseurs de documents traditionnels avec le raisonnement LLM, plutôt que de se reposer uniquement sur les capacités multimodales brutes
• Suivre les taux d’erreur par type de document et garder les humains aux commandes là où l’enjeu est élevé

En résumé : l’IA multimodale est un assistant puissant, pas encore un extracteur autonome fiable.

3. Construire des workflows IA robustes avec des stacks no‑code / low‑code

Les plateformes no‑code/low‑code (Make, n8n, Zapier, Retool, WeWeb et outils similaires) permettent d’assembler rapidement des stacks IA sans lourd développement. FACTS suggère des patterns clairs à suivre.

3.1 Pattern 1 – Bot FAQ interne avec RAG et double vérification

Objectif : Un chatbot interne fiable pour les politiques RH, IT ou opérations.

🧩 Pattern d’architecture

1. Déclencheur

   • L’utilisateur pose une question via un widget de chat (WeWeb, app Retool, intranet).

2. Couche de récupération (RAG)

   • Le workflow interroge une base vectorielle alimentée à partir de documents de politique interne, wiki, emails, tickets.
   • Les k meilleurs résultats et extraits sont attachés comme contexte.

3. Génération de la réponse principale

   • Le LLM rédige une réponse, contrainte par le contexte et tenue de fournir des citations.

4. Vérification automatique de factualité

   • Un second modèle (plus petit, moins cher) relit la réponse + les sources.
   • Il renvoie :
     • Un score de confiance (0‑1)
     • La liste des affirmations non supportées, le cas échéant

5. Couche de décision

   • Si la confiance ≥ seuil (par exemple 0,8) et aucune affirmation non supportée → la réponse est envoyée.
   • Si en dessous du seuil →
     • Le système envoie une réponse prudente (« Information insuffisante ; voici ce que disent explicitement les documents »)
     • Ou escalade vers un humain (support RH ou IT) avec tout le contexte.

6. Journalisation & gouvernance

   • Stocker la question, les documents de contexte, la réponse, le score de confiance, et le fait que l’utilisateur ait signalé un problème ou non.
   • Utiliser ces logs pour suivre les hallucinations IA, ajuster les seuils et mettre à jour les documents.

🔁 Rôle du no‑code/low‑code

• Orchestrer déclencheurs, appels d’API, logiques de branchement et persistance sans backend custom
• Se connecter directement aux systèmes documentaires (SharePoint, Google Drive, Notion) et bases vectorielles via connecteurs ou webhooks

3.2 Pattern 2 – Copilote finance avec données structurées et escalade

Objectif : Un copilote finance assistant les contrôleurs ou analystes FP&A dans l’analyse budgétaire et le reporting.

🧩 Pattern d’architecture

1. Couche d’intégration de données

   • Des flux ETL ou intégrations no‑code récupèrent les données de l’ERP, comptabilité, BI (Snowflake, BigQuery, etc.).
   • Seules des vues agrégées et autorisées sont exposées au copilote.

2. Analyse de la question et génération de requêtes

   • L’utilisateur demande : « Explique l’écart entre les dépenses marketing et le budget pour le T3 en EMEA. »
   • Le LLM traduit la question en requêtes structurées (SQL, filtres BI) envoyées à une API data.

3. Récupération et vérité terrain chiffrée

   • Le système BI renvoie les chiffres effectifs et leurs ventilations.
   • Ces chiffres deviennent la source de vérité unique ; le LLM ne peut pas les modifier.

4. Génération de l’explication

   • Le modèle produit une explication narrative et des graphiques, uniquement à partir des données renvoyées.

5. Garde‑fous de factualité

   • Un moteur de règles ou un LLM secondaire vérifie que :
     • Tous les chiffres du texte correspondent aux données réelles
     • Les pourcentages et écarts sont correctement calculés
   • En cas d’incohérence, la sortie est signalée pour revue.

6. Humain dans la boucle

   • Pour les rapports destinés au management ou aux régulateurs, exiger une validation humaine obligatoire dans le workflow.
   • Une interface no‑code (Retool, portail interne) présente les données, l’explication IA et les alertes.

🔁 Impact

• Automatise la narrativisation des chiffres, accélère l’analyse
• Maintient la factualité ancrée dans des stores de données vérifiées, pas dans le modèle

3.3 Pattern 3 – Analyse juridique et documentaire avec automatisation prudente

Objectif : Un assistant juridique pour analyser contrats, NDA, politiques et identifier les clauses ou risques clés.

🧩 Pattern d’architecture

1. Ingestion sécurisée

   • Les contrats sont téléversés via une interface low‑code ; les documents sont stockés dans un référentiel contrôlé.

2. Découpage (chunking) et vectorisation

   • Les documents sont segmentés en clauses ; les embeddings sont stockés dans une base vectorielle.

3. Tâche 1 – Extraction de clauses

   • Le LLM récupère les segments pertinents et identifie les clauses (confidentialité, plafond de responsabilité, juridiction).
   • Chaque extraction inclut des références sources (ID de document, section, page).

4. Tâche 2 – Classification du risque

   • Un second modèle ou un moteur de règles classe les clauses (standard / non standard / à risque élevé).
   • Des seuils de confiance définissent quelles clauses sont auto‑validées et lesquelles requièrent une revue.

5. Workflow de validation humaine

   • Les juristes voient les annotations et scores proposés par l’IA dans une interface low‑code.
   • Ils approuvent, modifient ou rejettent, avec motif consigné.

6. Amélioration continue

   • Les corrections alimentent le fine‑tuning ou l’ajustement des prompts.
   • Indicateurs :
     • Précision/rappel par type de clause
     • Temps de revue par document
     • Taux de désaccord entre IA et humain

🔁 Périmètre d’automatisation

• Automatiser tri, pré‑classification et synthèse
• Garder le jugement juridique et les cas limites entièrement humains

4. Du benchmark à la gouvernance : un cadre pratique pour les décideurs

FACTS peut être plus qu’un classement. Il peut devenir un outil de gouvernance des données et d’évaluation des modèles.

4.1 Questions à poser aux éditeurs et intégrateurs

Lors de l’évaluation des solutions, demandez des éléments concrets en lien avec FACTS :

• Quels sous‑scores FACTS sont pertinents pour ce cas d’usage ?

  • Search pour les assistants de recherche ou outils de connaissance dynamique
  • Grounding pour les chatbots de politiques internes
  • Multimodal pour les workflows documentaires ou image

• Comment le système implémente‑t‑il le RAG ?

  • Quelle base vectorielle / quel moteur de recherche ?
  • Comment le contexte est‑il sélectionné, mis à jour, versionné ?
  • Comment les droits d’accès sont‑ils appliqués ?

• Quels garde‑fous de grounding sont en place ?

  • L’assistant répond‑il uniquement à partir des sources fournies ?
  • Comment les affirmations non supportées sont‑elles détectées et traitées ?

• Comment les données multimodales sont‑elles traitées ?

  • Des décisions critiques reposent‑elles uniquement sur l’analyse d’images/graphiques ?
  • Une revue obligatoire est‑elle prévue pour les valeurs extraites ?

• Quel niveau d’observabilité est proposé ?

  • L’organisation peut‑elle voir les logs, citations, scores de confiance ?
  • Existe‑t‑il des dashboards pour les taux d’hallucination et les réponses “Je ne sais pas” ?

4.2 Utiliser FACTS dans les RFPs et spécifications techniques

Dans les cahiers des charges, FACTS peut se décliner en clauses spécifiques :

• « La solution doit supporter des modèles avec des scores FACTS Search documentés supérieurs à X pour notre version au moment du déploiement. »
• « Pour les cas d’usage de connaissance interne, le système doit démontrer des réponses ancrées avec citations explicites des documents. »
• « Toute extraction automatisée à partir de PDF ou d’images qui ne passe pas par une revue humaine doit être justifiée par des métriques équivalentes à FACTS Multimodal, et les taux d’erreur doivent être divulgués. »

L’objectif n’est pas d’optimiser un score composite unique, mais de :

• Aligner le sous‑benchmark avec le risque métier
• Amener les fournisseurs à s’engager sur des métriques observables, pas des promesses vagues

4.3 KPIs pour une transformation “trust but verify”

Pour éviter une dérive “IA d’abord, vérification ensuite”, il faut suivre un petit nombre de KPIs opérationnels.

Ensemble de KPIs suggéré :

• Taux d’hallucination

  • % de réponses signalées comme incorrectes par les utilisateurs ou réviseurs
  • Ventilation par cas d’usage (bot RH, copilote finance, assistant juridique)

• Taux de réponses “je ne sais pas”

  • Indicateur de l’humilité du modèle et de l’efficacité du grounding
  • Trop faible peut suggérer des hallucinations sur‑confiantes ; trop élevé peut refléter un mauvais retrieval

• Coût de vérification

  • Temps et coût passés par les humains à valider ou corriger les sorties IA
  • Doit diminuer dans le temps à mesure que les prompts, le RAG et les modèles s’améliorent

• Couverture vs précision

  • Pour les workflows documentaires : % de documents avec assistance IA vs % traités manuellement de bout en bout
  • Pour les chatbots : % de questions répondues en autonomie vs escaladées

• Taux d’incidents

  • Nombre et gravité des incidents de factualité qui ont atteint des parties prenantes externes ou régulateurs

Ces KPIs soutiennent une stratégie de déploiement progressive : démarrer avec des scénarios à faible risque, suivre les métriques, puis élargir le périmètre ou l’autonomie uniquement lorsque les preuves le justifient.

Points clés à retenir

All evaluated models achieved an overall accuracy below 70%, leaving considerable headroom for future progress.

FACTS Benchmark Team

FACTS Benchmark Suite Release Notes

• Le benchmark FACTS met au jour un plafond systémique d’environ 70 % de factualité sur les modèles de pointe ; l’architecture et la gouvernance comptent plus que le changement de modèle.
• Le RAG et l’usage d’outils doivent être des choix de design par défaut pour l’IA en entreprise ; se reposer uniquement sur la “mémoire” paramétrique est risqué pour la connaissance dynamique ou critique.
• Le grounding et les citations sont essentiels pour les chatbots internes et copilotes métiers, en permettant l’auditabilité et le contrôle des hallucinations IA.
• L’IA multimodale n’est pas encore fiable pour l’extraction documentaire ou visuelle non supervisée ; il faut l’utiliser pour assister les humains, pas pour les contourner.
• Une approche “trust but verify”, avec KPIs explicites et workflows humains‑dans‑la‑boucle, permet une transformation digitale robuste sans surestimer les capacités actuelles de l’IA.