Fonctionnalité IA : 7 choix d’interface pour la confiance

Ces derniers mois, on a redessiné les écrans de deux produits qu’on avait livrés, une néobanque pour PME et une plateforme qui relie médecins et laboratoires, en imaginant ce qu’un assistant IA pourrait y apporter. Prévision de trésorerie, détection d’un paiement suspect, lecture automatique des factures, vérification des inscriptions de professionnels de santé. Des sujets où une erreur coûte cher et où personne n’a envie de faire confiance à l’aveugle.

À chaque écran, on est retombés sur les mêmes questions. Pas « quel modèle utiliser », mais : qu’est-ce que l’utilisateur doit voir pour décider s’il suit la suggestion ? Voici les sept décisions qu’on prend désormais systématiquement.

1. Dire ce que l’IA a fait, pas ce qu’elle est

« Propulsé par l’IA » ne dit rien d’utile. L’utilisateur ne se demande pas quelle technologie tourne derrière l’écran, il se demande ce qui s’est passé et s’il doit vérifier quelque chose.

Comparez « Facture analysée par IA » et « Lue par le copilote en 4 secondes · 5 champs sur 6 sûrs ». La seconde phrase dit ce qui a été fait, combien de temps ça a pris, et surtout où regarder. Elle transforme un badge décoratif en information de travail.

C’est aussi ce qui règle la question réglementaire avec élégance : dire clairement qu’une IA est intervenue, c’est ce que demande l’article 50 de l’AI Act. Autant le faire avec une phrase qui sert à quelque chose.

2. Montrer le doute là où il est, et seulement là

Afficher un pourcentage de confiance à côté de chaque élément paraît transparent. En pratique, au bout de trois écrans où tout affiche 97 %, 98 %, 99 %, plus personne ne lit les chiffres. Ils deviennent du papier peint, et le jour où un 62 % apparaît, il passe inaperçu.

On procède autrement. Le niveau de confiance reste disponible, discret, pour ceux qui le cherchent. Mais quand un élément passe sous le seuil où une vérification est nécessaire, il change de statut visuel : couleur d’alerte, libellé « À vérifier », et une phrase qui dit pourquoi. Sur la lecture de factures, cinq champs sont simplement cochés, et le sixième, l’IBAN, est encadré en orange avec la raison du doute.

Le bon réglage du seuil ne se décide pas en réunion. Il se règle avec les utilisateurs, en observant à partir de quand ils commencent à revérifier d’eux-mêmes.

3. Expliquer avec les mots du métier

« Anomalie détectée, score 0,87 » est une phrase de data scientist. Un responsable financier ne sait pas quoi en faire. « 3,1 fois la moyenne des 12 derniers paiements à ce fournisseur » et « Nouvel IBAN enregistré le 2 octobre, banque différente » sont des phrases qu’il comprend immédiatement, parce que ce sont les signaux qu’il vérifierait lui-même.

Une bonne explication ne décrit pas le fonctionnement du modèle. Elle donne à l’utilisateur les éléments qu’il aurait cherchés s’il avait fait le travail à la main. C’est pour ça que l’écriture de ces explications ne peut pas être confiée uniquement à l’équipe technique : il faut quelqu’un qui connaît le métier de l’utilisateur, et des tests pour vérifier que la phrase est comprise.

4. Relier chaque proposition à sa source

Quand l’IA extrait un montant d’une facture, on surligne l’endroit exact de la facture d’où vient le montant. Quand elle résume un document pour un médecin avant un rendez-vous avec un laboratoire, on affiche sous le résumé les documents utilisés : résumé des caractéristiques du produit, avis de la Haute Autorité de santé, fiche transmise par le laboratoire.

La source fait deux choses. Elle permet de vérifier en un coup d’œil au lieu de tout relire. Et elle change la nature de la relation : l’IA ne demande plus d’être crue, elle montre son travail. Pour les sujets sensibles, santé, finance, droit, c’est souvent ce qui fait la différence entre une fonctionnalité utilisée et une fonctionnalité contournée.

5. Préférer une fourchette à un chiffre

Une prévision affichée au centime près, « 1 362 418,27 € fin décembre », donne une impression de précision que personne ne peut garantir. Le jour où le chiffre réel s’en écarte de 40 000 €, l’utilisateur conclut que l’outil ne marche pas.

« Environ 1,36 M€, entre 1,22 et 1,41 M€ » dit la même chose, honnêtement. Sur un graphique, la zone d’incertitude qui s’élargit avec le temps fait comprendre en une seconde qu’on est plus sûr de la semaine prochaine que du mois de décembre. Paradoxalement, montrer l’incertitude renforce la confiance : la prévision tombe dans la fourchette annoncée, et l’outil a dit vrai.

6. Laisser le dernier mot à l’humain, pour de vrai

Beaucoup d’interfaces disent « vous gardez le contrôle » puis proposent un énorme bouton « Accepter » et un lien gris minuscule pour refuser. Ce n’est pas du contrôle, c’est de la pente.

Trois règles qu’on applique :

Refuser doit être aussi simple qu’accepter. Sur un paiement signalé, « Bloquer et vérifier » et « Valider quand même » sont deux vrais boutons, côte à côte.
Corriger doit être possible sans tout recommencer. Un champ mal lu se modifie sur place, et la correction sert à améliorer les suivantes.
Rien d’irréversible sans validation. L’IA prépare les paiements, elle ne les envoie pas. Elle prépare le dossier d’inscription, c’est l’équipe conformité qui valide.

Cette dernière règle est aussi une protection pour l’équipe produit. Une erreur de l’IA qui a été validée par une personne est un incident. Une erreur exécutée automatiquement est une crise.

7. Mesurer la confiance, pas seulement l’usage

Le nombre de clics sur le bouton de l’assistant ne dit presque rien. Ce qui compte, c’est ce que les gens font de ses propositions. On suit trois indicateurs :

Le taux d’acceptation sans modification, qui dit si les propositions sont bonnes.
Le taux de correction, et surtout sur quels champs, qui dit où le modèle ou l’interface pèche.
La revérification : est-ce que l’utilisateur rouvre la source alors que tout était marqué comme sûr ? Si oui, votre signal de confiance n’est pas cru.

Avant même de mesurer en production, cinq entretiens avec un prototype branché sur un vrai modèle, avec de vraies données, suffisent à voir la plupart de ces problèmes. Les maquettes statiques mentent : une IA qui répond toujours parfaitement dans Figma ne prépare personne au moment où elle se trompe.

Ce qu’on ne fait plus

Pour finir, quelques réflexes qu’on a abandonnés en chemin :

Mettre une étincelle sur chaque bouton qui touche de près ou de loin à un modèle.
Faire du chat l’interface par défaut. Le plus souvent, une suggestion bien placée dans l’écran existant vaut mieux qu’une conversation.
Cacher les limites de l’outil dans une page d’aide. Si l’IA ne sait pas lire les factures manuscrites, on le dit à l’endroit où l’on dépose la facture.
Animer la réponse mot par mot pour faire « intelligent » quand elle est déjà prête. L’effet machine à écrire rassure en démo et agace au quotidien.

Aucune de ces décisions ne demande un meilleur modèle. Elles demandent du temps de conception, des tests avec les vrais utilisateurs, et une équipe où le design et le développement travaillent sur le même écran au même moment. C’est, au fond, tout ce qu’on essaie de faire chez Kapti.

Vous pouvez voir ces principes appliqués sur les écrans de Titane et de Moofize, et dans les démos de nos projets internes.

Questions fréquentes

Faut-il afficher un score de confiance pour chaque suggestion d’une IA ?

Il vaut mieux le garder discret et ne mettre en avant que les éléments qui passent sous un seuil où une vérification est nécessaire. Un score affiché partout finit par ne plus être lu.

Comment tester une fonctionnalité IA avant de la développer ?

Avec un prototype branché sur un vrai modèle et de vraies données, testé avec cinq utilisateurs. Les maquettes statiques montrent une IA qui ne se trompe jamais et ne préparent pas au moment où elle se trompe.

Quels indicateurs suivre pour une fonctionnalité IA ?

Le taux d’acceptation sans modification, le taux de correction par champ, et la revérification, c’est-à-dire les cas où l’utilisateur rouvre la source alors que la proposition était marquée comme sûre.