Pour une IA plus vérifiable que magique

Je me méfie d’une partie du discours actuel sur l’intelligence artificielle. Nous parlons beaucoup de modèles plus grands, de contextes plus longs et d’agents capables d’appeler davantage d’outils. Nous parlons moins de la question la plus simple : comment vérifier qu’une sortie peut réellement être utilisée ?

Mon point de vue est le suivant : une IA utile n’est pas celle qui donne toujours une réponse. C’est celle qui sait distinguer une réponse suffisamment étayée, une réponse incertaine et une situation qui doit être transmise à une personne.

Le problème n’est pas seulement l’hallucination

Le mot hallucination est pratique, mais il donne parfois l’impression d’un défaut isolé du modèle. Dans un système réel, une réponse peut être problématique parce que la source est ancienne, que la permission d’accès manque, que l’outil appelé a reçu de mauvais paramètres ou que la règle métier a changé.

La fiabilité est donc une propriété de la chaîne, pas seulement du LLM. Le LLM (Large Language Model) propose une formulation ; le système doit ensuite retrouver la source, vérifier le format, contrôler les contraintes et conserver la provenance. Cette division des responsabilités me paraît plus prometteuse que la recherche d’un modèle présenté comme infaillible.

Ma préférence : des preuves courtes et vérifiables

Je préfère une réponse qui cite deux sources vérifiables à une réponse très élégante qui ne permet pas de remonter à son origine. Un evidence trail, ou chaîne de preuve, peut rester simple : identifiants des documents, version de la règle appliquée, outil utilisé et raison d’une éventuelle abstention.

Cela ne signifie pas que chaque utilisateur doit lire un journal technique. L’interface peut montrer un résumé et laisser le détail disponible pour l’audit. La transparence n’est pas la publication de tous les logs ; c’est la possibilité de retrouver la bonne preuve au bon moment.

Ce que cela change pour les équipes

Une équipe qui adopte cette approche doit accepter trois contraintes :

• mesurer la qualité des sources et pas seulement la qualité du texte produit ;
• tester les cas où le système doit refuser, demander une précision ou transmettre à un humain ;
• conserver assez de contexte pour rejouer une décision sans créer une nouvelle base de données personnelle.

Cette orientation peut ralentir une démonstration, mais elle accélère souvent le diagnostic. Un système qui explique pourquoi il s’est abstenu est plus facile à améliorer qu’un système qui répond vite sans laisser de trace.

L’objection du coût

On me répondra que cette couche de vérification ralentit le service et augmente le coût. C’est vrai. Une recherche de source, un contrôle de permission et une revue humaine prennent plus de temps qu’une réponse générée sans contrôle.

Mais le coût doit être comparé au risque. Pour une question sans conséquence, une réponse rapide peut suffire. Pour une démarche universitaire, une décision administrative ou un conseil lié à la santé, le temps de vérification fait partie du service. Le bon objectif n’est donc pas une preuve maximale partout, mais un risk-based verification : une vérification proportionnée à la gravité d’une erreur.

Dans un contexte marocain, cette règle permettrait de réserver la validation humaine aux situations réellement sensibles, tout en gardant des réponses rapides pour les demandes informatives et réversibles.

Une question ouverte

La recherche devrait comparer non seulement la précision, mais aussi le coût de vérification. Combien de secondes faut-il à une personne pour confirmer une réponse ? Combien de sources contradictoires peut-elle examiner ? À partir de quel niveau de preuve la confiance augmente-t-elle réellement ?

Je préfère une IA un peu moins spectaculaire, mais auditable, c’est-à-dire inspectable après coup. La prochaine étape ne consiste pas à retirer l’intelligence aux modèles ; elle consiste à entourer leur puissance d’un cadre qui rende leurs erreurs visibles, discutables et réversibles.