“Vous devez nous concevoir un outil dopé à l’IA.”
La phrase est tombée comme une évidence, mais sans contexte, sans preuve. On a tous entendu ce genre de demande venue d’en haut, plus un ordre qu’une idée.
Dans ces moments-là, on se retrouve piégé entre deux risques : exécuter un concept bancal ou oser dire non. Pourtant, il existe une autre voie, plus subtile. Celle qui consiste à formuler une hypothèse, à questionner la logique derrière la demande, à transformer la contrainte en recherche : que cherche-t-on vraiment à résoudre ?
C’est ici que le design retrouve son rôle stratégique : comprendre l’intention, estimer l’impact attendu et faire émerger, à partir du besoin exprimé, une solution qui ait du sens.
Quand une demande de fonctionnalité révèle un problème mal cadré
Pourquoi une fonctionnalité ne dit jamais le vrai besoin
Une demande de fonctionnalité est rarement neutre. Elle est souvent la traduction prématurée d’un objectif implicite, formulé sans avoir été interrogé. Autrement dit, on arrive avec une solution avant d’avoir clarifié le problème.
Le rôle du design n’est donc pas d’exécuter la fonctionnalité telle quelle, mais de déplacer la discussion : passer de « que faut-il construire ? » à « qu’essaie-t-on réellement d’améliorer ? ». C’est à ce niveau que se jouent la pertinence et l’impact du produit.
Relire la demande à travers le modèle de Garrett
Le modèle de Jesse James Garrett rappelle un principe fondamental : les fonctionnalités ne sont jamais un point de départ. Elles se situent en aval d’objectifs, de besoins utilisateurs et de contraintes contextuelles.
Relire une demande à travers cette grille permet de révéler les décalages fréquents : une fonctionnalité pensée pour répondre à un objectif business flou, une solution qui ne traite qu’un symptôme, ou encore une réponse technique à un problème d’usage mal compris.
Recadrer : transformer une injonction en hypothèse
Recadrer ne signifie pas refuser. Cela consiste à reformuler la demande sous forme d’hypothèse testable, en s’appuyant sur un cadre simple : Symptôme → Preuve → Job-to-be-Done → Opportunité.
Ce travail redonne un langage commun à l’équipe produit. Il permet d’aligner objectifs, besoins utilisateurs et impact attendu, avant même de parler de solution. La fonctionnalité cesse alors d’être une injonction à exécuter pour devenir une piste à explorer.
Définir les fonctionnalités à partir du besoin : du Job-to-be-Done au concret
Le JTBD comme moteur de définition
Le Job-to-be-Done (JTBD) permet de recentrer la définition des fonctionnalités sur la motivation réelle de l’utilisateur et la barrière qu’il rencontre. On ne conçoit plus pour satisfaire une demande interne, mais pour améliorer un job critique dans un contexte donné.
Cette approche oblige à vérifier une chose simple : la fonctionnalité proposée aide-t-elle réellement l’utilisateur à mieux accomplir ce qu’il cherche à faire ?
Si la réponse est non, la fonctionnalité, même séduisante, n’a pas lieu d’être.
Traduire en User Stories et scénarios utilisables
Une fois le job clarifié, il s’agit de passer du pourquoi au comment sans perdre la logique d’impact. Les User Stories et les scénarios d’usage servent ici de pont entre intention et conception.
Ce travail est d’autant plus crucial lorsque l’IA intervient dans le parcours. Il faut alors scénariser les interactions, expliciter les moments de décision, de contrôle et d’erreur, pour éviter toute automatisation opaque. La fonctionnalité devient lisible, testable et réellement utilisable.
Prioriser : choisir ce qui crée réellement de la valeur
Objectiver les choix : valeur vs effort
Toutes les fonctionnalités intéressantes ne sont pas prioritaires. Sans cadre, la roadmap devient une accumulation d’idées séduisantes mais peu impactantes.
La matrice Valeur / Effort permet d’objectiver les choix : confronter l’impact réel attendu à l’effort de conception, de développement et de maintien.
Ce travail aide à écarter les fausses bonnes idées et à concentrer l’énergie produit là où elle crée un bénéfice utilisateur mesurable.
Représentation de la matrice Effort / Gain
MoSCoW, RICE et Kano : trois prismes pour arbitrer
Selon le contexte, différents cadres de priorisation peuvent être mobilisés :
- MoSCoW, pour aligner rapidement sous contrainte et clarifier les indispensables ;
- RICE, pour maximiser le retour sur investissement en intégrant portée, impact et effort ;
- Kano, pour comprendre la valeur perçue côté utilisateur, au-delà de la valeur fonctionnelle.
Utilisés intelligemment, ces modèles transforment la priorisation en décision argumentée, et non en compromis politique.
Concevoir des fonctionnalités augmentées : quand l’IA change la donne
Centrer l’IA sur l’humain, pas sur la technologie
L’IA ne crée pas de valeur par elle-même. Elle en crée lorsqu’elle soutient un besoin réel, au bon moment du parcours. Concevoir une fonctionnalité augmentée ne consiste donc pas à automatiser pour automatiser, mais à renforcer la capacité d’action de l’utilisateur.
Dans cette logique, l’IA doit être pensée comme un Job Helper : elle assiste, suggère, anticipe parfois, mais ne remplace ni la décision ni la responsabilité humaine. Une automatisation « magique », sans contrôle ni compréhension, fragilise l’expérience au lieu de l’améliorer.
Construire la confiance : transparence, contrôle, gestion des erreurs
Sans confiance, une fonctionnalité, même performante, n’est pas adoptée. Cela implique de rendre l’IA compréhensible et maîtrisable : savoir ce qu’elle fait, pourquoi elle le fait, et comment reprendre la main.
La transparence utile, la possibilité de corriger ou d’annuler, et la gestion des erreurs « gracieuses » sont essentielles. Elles transforment l’IA d’un système opaque en partenaire fiable, intégré au parcours plutôt qu’imposé.
Mesurer ce qui compte : démontrer l’impact d’une fonctionnalité
Les métriques fondamentales
Une fonctionnalité n’a de valeur que si son impact est mesurable. Les opinions ne suffisent pas ; ce sont les usages qui tranchent.
Trois indicateurs restent fondamentaux :
- le taux de succès (l’utilisateur atteint-il son objectif ?) ;
- le temps sur la tâche, révélateur d’efficacité ou de friction ;
- l’effort perçu, souvent plus parlant que la performance brute.
Les métriques fondamentales : taux de succès, temps sur la tâche et effort perçu
L’impact ne se raconte pas, il se mesure. Ces métriques permettent d’arbitrer, d’itérer ou d’abandonner en connaissance de cause.
Pour les fonctionnalités IA : adoption, qualité d’output, confiance
Lorsqu’une IA est intégrée, la mesure doit aller plus loin. Il faut vérifier :
- le taux d’adoption réel (et pas seulement l’activation) ;
- la qualité de l’output, du point de vue de l’utilisateur ;
- le niveau de confiance, souvent déterminant pour la récurrence d’usage.
Ces signaux indiquent si l’IA améliore réellement le parcours… ou si elle ajoute de la complexité inutile. Ils aident à décider quand renforcer, ajuster ou supprimer.
Une fonctionnalité n’est réussie que si elle change quelque chose
Le design redevient stratégique lorsqu’il questionne avant de produire, structure avant de livrer, et démontre l’impact plutôt que de le promettre.
Une fonctionnalité n’existe pas pour répondre à une injonction, ni pour suivre une tendance, mais pour résoudre un problème réel, au bon endroit du parcours utilisateur.
Clarifier l’intention, prioriser avec méthode, concevoir avec discernement, y compris lorsque l’IA est en jeu, permet de créer des produits utiles, cohérents et durables.
Une fonctionnalité est réussie lorsqu’elle change réellement quelque chose pour l’utilisateur comme pour le produit.
