Ton IA n'échoue pas à cause du modèle

Un client m'appelle. Il veut de l'IA dans son produit. Il a le budget, il a l'équipe, il a même déjà choisi le modèle.

Six mois plus tard, la fonctionnalité existe et personne ne l'utilise.

J'ai vu ce scénario assez souvent maintenant pour savoir que le problème n'est presque jamais le modèle.

Le problème, c'est que le produit a été construit pendant des années pour un système qui a toujours raison. Tu cliques, tu obtiens. L'interface existe pour supprimer le doute. Et là tu greffes dessus quelque chose qui a souvent raison, parfois tort, et toujours l'air sûr de lui.

Deux mauvaises réponses, et l'utilisateur n'y revient plus. Pas parce que c'était mauvais. Parce qu'il n'avait aucun moyen de savoir quand ça l'était.

Greffer, c'est plus dur que construire, et personne ne le chiffre

Tous les articles sur le design de produits IA partent du principe que tu pars de zéro. Ce n'est pas ton cas. Tu as des utilisateurs avec des habitudes, une équipe support avec ses scripts, un backlog avec deux ans de dette, et une interface où chaque pixel a été justifié par quelqu'un à un moment.

Ça change trois choses.

Tes utilisateurs n'ont rien demandé. Ils sont venus pour ce que ton produit fait déjà. Une fonctionnalité IA est une interruption tant qu'elle n'a pas prouvé le contraire.

Tes workflows existants sont porteurs. Casses-en un pour faire de la place à l'IA et tu en entendras parler dans la journée.

Et ton interface n'a aucun vocabulaire pour l'incertitude. Tout y est présenté comme un fait. Glisse un résultat probabiliste dans cette grammaire et l'utilisateur le lira comme un fait aussi, ce qui est exactement l'échec que tu ne peux pas te permettre.

Place la première fonctionnalité là où ça fait déjà mal

L'instinct, c'est de mettre l'IA sur le workflow phare, celui de la démo, celui que le CEO montre aux investisseurs. C'est le mauvais choix.

Mets-la sur l'étape que tes utilisateurs redoutent déjà et font déjà mal. Le tagging manuel. Le rapport que personne n'écrit. Le rapprochement de trente minutes en fin de mois.

Deux raisons. La barre est basse, donc une première version moyenne fait quand même mieux que l'existant. Et si ça rate, ça rate sur quelque chose qui était déjà cassé, ce qui ne te coûte rien en confiance.

Demande à ton équipe support, pas à ton équipe produit. Le support sait quel écran génère les tickets.

Décide ce que tu ne vas pas automatiser

C'est la partie qu'on saute, et c'est celle qui décide du résultat.

Tout ce qui coûte cher quand c'est faux et qui est difficile à détecter doit rester manuel. Tout ce dont l'utilisateur est personnellement responsable doit rester manuel, ou au moins rester modifiable avant de sortir du produit.

Des clients m'ont repris là-dessus. L'argument est toujours le même : si on peut l'automatiser, pourquoi ne pas le faire. Parce que la valeur d'une fonctionnalité IA, ce n'est pas la quantité de choses qu'elle fait. C'est la part de ce qu'elle fait que l'utilisateur peut arrêter de vérifier sans risque. Automatise quelque chose que les gens doivent encore vérifier ligne par ligne, et tu as ajouté une étape au lieu d'en retirer une.

Ton IA va se tromper. Conçois cet écran-là

La plupart des équipes mettent 90 % de l'effort sur le parcours idéal, que le modèle gère de toute façon.

L'état qui compte est ailleurs : le résultat a l'air plausible et il est faux. Pas d'erreur, rien en rouge, rien pour attirer l'œil. Juste une réponse sûre d'elle qui se trouve être fausse.

Donc la question que je pose à chaque équipe avant de dessiner la moindre interface : qu'est-ce que l'utilisateur voit à ce moment-là, et comment il le vérifie en une seule action ?

En général, la réponse, c'est une source. Les lignes d'où vient le résumé, la période utilisée, le filtre appliqué. Un clic vers la donnée sous-jacente. Ce seul détail fait plus pour l'adoption que n'importe quelle amélioration du modèle, parce qu'il transforme un acte de foi en vérification.

Rends la correction moins chère que de tout refaire

Si corriger un détail oblige à tout régénérer, tes utilisateurs arrêteront d'utiliser la fonctionnalité. Pas tout de suite. Progressivement, et sans te le dire.

La règle que j'applique : modifier le résultat doit coûter moins cher que le produire à la main. Si l'IA rédige quelque chose, le brouillon doit être modifiable sur place. Si elle catégorise quelque chose, la catégorie doit pouvoir changer en un clic, pas via un panneau de réglages trois niveaux plus bas.

Et quand un utilisateur corrige le résultat, cette correction doit rester visible pour lui ensuite. Les gens ont besoin de voir que leur intervention a compté, sinon ils concluent que le système n'écoute pas et retournent à l'ancienne méthode.

Montre le raisonnement, pas un journal

La transparence est devenue un slogan, et elle est généralement mal mise en œuvre. Soit les équipes ne montrent rien, soit elles déversent une chaîne d'étapes intermédiaires que personne ne lit.

Ce dont l'utilisateur a réellement besoin, c'est d'assez d'information pour décider s'il peut faire confiance à ce résultat. Quelle source. Quelle période. Quels enregistrements. Trois lignes, pas trente.

Le test est simple : si l'utilisateur ne peut pas savoir, avec ton explication, s'il doit faire confiance à la réponse, ton explication est de la décoration.

L'IA dans une interface chargée de données

La plupart des produits sur lesquels je travaille sont des dashboards, et c'est là que l'IA atterrit en général : un résumé en haut, une alerte d'anomalie, un champ de requête en langage naturel.

Le piège, c'est qu'un dashboard a déjà un problème de hiérarchie avant que l'IA n'arrive. Tout est affiché au même niveau, rien n'appelle à l'action, et l'utilisateur lit au lieu d'agir. Ajouter un résumé IA par-dessus ne règle rien. Ça ajoute un bloc de plus qui se bat pour la même attention, avec en prime le risque que celui-là soit faux.

Règle la hiérarchie d'abord. Décide des trois questions auxquelles l'utilisateur ouvre le produit pour répondre, fais tenir ces réponses sur un seul écran, et descends tout le reste d'un niveau. Ensuite seulement, demande-toi si le résumé IA mérite sa place en haut. Souvent, le meilleur choix est de laisser l'IA gérer ce qui est sous la surface, la détection d'anomalies ou la segmentation, plutôt que le titre.

Je détaille ça dans l'article sur les patterns de dashboard.

Ne casse pas ce qui marche déjà

Chaque fonctionnalité IA a besoin d'une sortie. Un moyen de faire le même travail à la main, facile à trouver, pas caché.

Les équipes la suppriment parce qu'elles veulent des chiffres d'adoption. Ce qu'elles obtiennent, c'est du ressentiment, et une file de support remplie de gens qui demandent où est passé l'ancien bouton. Une adoption forcée n'est pas une adoption, c'est un compte à rebours.

Garde le chemin manuel au moins deux cycles de release après le lancement. Si la fonctionnalité est bonne, l'usage bascule tout seul, et tu as alors un vrai chiffre au lieu d'un chiffre contraint.

Cadre le pilote correctement

Un workflow. Une question à laquelle tu cherches à répondre. Un chiffre qui te dirait d'arrêter.

La plupart des équipes définissent le succès et jamais l'échec, ce qui veut dire que le pilote ne peut jamais conclure quoi que ce soit et devient discrètement permanent. Décide dès le départ quel résultat te ferait l'arrêter.

Et simule tout ce qui n'est pas ce que tu testes. Un onboarding manuel, un humain dans la boucle, un tableur au lieu d'un pipeline. Si le mécanisme n'est pas ce que tu valides, ne le construis pas.

Ce que ça coûte, et où va l'argent

Le modèle est la partie la moins chère. Le budget part dans le choix de ce qu'on n'automatise pas, la conception des états d'erreur et de correction, et les tests avec des gens qui utilisent réellement le produit.

Un pilote sur un workflow se compte en semaines. Une intégration complète dans un produit mature prend plus longtemps, et cette durée dépend de la quantité de comportements existants que tu bouscules, pas de l'intelligence de l'IA.

Si tu veux les chiffres équivalents pour le travail d'interface, le détail des coûts de refonte les donne.

En résumé

Ajouter de l'IA à un produit existant n'est pas un problème de modèle. C'est un problème d'intégration déguisé en problème de modèle.

Décide où elle va. Décide ce qui reste manuel. Conçois le moment où elle se trompe, et rends la correction peu coûteuse.

Fais ça et le modèle devient presque secondaire. Saute cette étape et aucun modèle ne te sauvera.

Si tu réfléchis à ça pour ton propre produit, le guide sur les plateformes IA couvre le côté architecture, et je peux regarder ton cas directement.