La confiance est une fonctionnalité produit, pas une page juridique

La confiance n'est pas une phrase placée sous un formulaire. C'est la capacité du produit à montrer ce qu'il fait, avec quelles données, dans quelles limites et ce qui se passe lorsqu'il se trompe. Pour une fonctionnalité IA, elle doit être visible avant l'usage, pendant la décision et après l'erreur.

Une politique de confidentialité reste nécessaire, mais elle ne compense pas une interface qui collecte trop, une réponse invérifiable ou l'absence de recours.

Pourquoi la confiance devient un moat

Lorsque plusieurs produits accèdent à des modèles comparables, la différence se déplace vers l'expérience complète. Un utilisateur peut essayer rapidement une fonction générative ; il ne lui confiera pas durablement une tâche importante si les erreurs restent opaques.

Dans la santé, la finance, les ressources humaines, l'éducation ou la mémoire d'entreprise, la confiance peut réduire l'adoption à court terme si elle ajoute une validation. Elle augmente pourtant la valeur durable lorsqu'elle évite les erreurs silencieuses et rend la délégation progressive possible.

La thèse à tester n'est donc pas « plus de contrôles produit toujours plus de confiance ». C'est : « le bon contrôle, placé au moment du risque, permet à l'utilisateur de confier davantage au système ».

Sept mécanismes à concevoir

1. Une finalité compréhensible

Expliquer la tâche précise et ce qui n'est pas fait. « Préparer un brouillon » est plus honnête que « gérer votre dossier ». La finalité guide aussi la minimisation des données.

2. Un consentement lié à l'action

Demander l'autorisation au moment où la donnée ou l'enregistrement devient nécessaire. Séparer l'exécution du service d'un éventuel usage secondaire, notamment l'entraînement, l'analyse marketing ou le partage.

3. Des sources et une fraîcheur visibles

Lorsque la réponse dépend d'une information externe ou mémorisée, permettre de remonter à l'origine et à la date. Une citation ne garantit pas que la conclusion est correcte, mais rend sa vérification possible.

4. Des limites explicites

Dire quand le système ne sait pas, quand il extrapole et dans quels cas une validation humaine est requise. Une confiance calibrée vaut mieux qu'une assurance constante.

5. Une validation proportionnée

Plus l'impact est élevé et l'action difficile à annuler, plus la validation doit être forte. Un brouillon d'email peut rester modifiable ; un paiement, une suppression ou une recommandation sensible demande une confirmation distincte.

6. Un recours et une correction

L'utilisateur doit pouvoir signaler l'erreur, comprendre la prochaine étape, corriger la donnée et, si nécessaire, demander l'intervention d'une personne. Le recours est une partie du parcours, pas seulement une adresse générique.

7. Un mode dégradé

Quand le modèle, la source ou l'intégration ne fonctionne plus, le produit choisit explicitement : suspendre, repasser en manuel, utiliser une fonction plus simple ou demander une information. Inventer une réponse pour préserver l'apparence de fluidité est rarement le bon choix.

Mesurer la confiance sans la réduire à un score

Les enquêtes de perception sont utiles, mais elles ne suffisent pas. Observer aussi :

• la part des propositions acceptées sans modification ;
• le taux et le type de corrections ;
• le délai de détection d'un incident ;
• le délai de résolution et la qualité du recours ;
• la part des décisions sensibles validées par la bonne personne ;
• la fréquence des abandons après une demande d'autorisation ;
• la rétention après une erreur correctement traitée.

Chaque métrique a une limite. Un taux d'acceptation très élevé peut indiquer une excellente qualité ou une validation trop passive.

Exemple avant/après

Un assistant prépare une recommandation à partir d'un dossier client.

Avant : une réponse unique, formulée avec assurance, sans origine visible. L'utilisateur copie le texte ou l'abandonne.

Après : le produit affiche le but, les documents utilisés, leur date, les points incertains, les passages à vérifier et l'action proposée. Une personne valide avant l'envoi. En cas de source manquante, le système demande le document plutôt que de compléter.

Le second parcours est moins spectaculaire en démonstration. Il est plus délégable dans le temps.

Ce que nous savons et ce qu'il faut tester

Fait direct : les cadres NIST, CNIL et OWASP demandent d'identifier les risques, protéger les données et gérer les défaillances ; ils ne garantissent pas à eux seuls un produit digne de confiance.

Inférence : rendre provenance, limite et recours visibles peut devenir un avantage commercial dans les domaines où l'erreur coûte cher.

Hypothèse : une checklist intégrée au parcours augmente la délégation sans réduire excessivement l'activation. Elle doit être testée sur une tâche réelle.

Checklist avant mise en production

• La finalité peut-elle être expliquée en une phrase ?
• Les données sont-elles nécessaires et légitimes ?
• L'utilisateur sait-il qu'une IA intervient ?
• Les sources et dates importantes sont-elles accessibles ?
• Le système sait-il refuser ou demander ?
• Les actions irréversibles demandent-elles une confirmation ?
• Le recours humain possède-t-il un responsable et un délai ?
• Le mode dégradé a-t-il été testé ?
• Les traces évitent-elles les données sensibles inutiles ?
• La date de révision des contrôles est-elle fixée ?

FAQ

Plus de transparence suffit-elle à créer la confiance ?

Non. La transparence sans fiabilité peut seulement rendre l'échec plus visible. Elle doit accompagner une qualité mesurée, des droits et un recours efficace.

Faut-il montrer tous les détails techniques ?

Non. Montrer ce qui aide l'utilisateur à décider : finalité, données importantes, limite, source, responsabilité et prochaine action.

Un humain dans la boucle garantit-il la sécurité ?

Non. Il faut vérifier que cette personne possède le temps, le contexte, l'autorité et une interface qui attire son attention sur les bons risques.

Prochaine étape

Passez une fonctionnalité réelle dans la checklist confiance IA, puis choisissez le risque le plus grave qui peut être testé cette semaine. Pour une revue humaine, envoyez le parcours et son mode dégradé à contact@yumea.fr avec l'objet « CONFIANCE ».

Sources

• NIST, AI Risk Management Framework.
• CNIL, recommandations pour le développement des systèmes d'IA et fiche sur la sécurité du développement.
• OWASP, Top 10 for LLM Applications 2025.