Idée principale

Une échéance de facturation à venir s'affiche dans l'échéancier d'un client. Elle n'existe pourtant pas comme document : elle n'aura d'existence propre qu'au moment où la facture sera émise. Conséquence immédiate — elle est absente des résultats de recherche. L'utilisateur, lui, l'a vue à l'écran ; il la cherche, ne la trouve pas, et ouvre un ticket.

Ce n'est pas un défaut ponctuel, c'est une famille entière de réclamations, traitée au cas par cas depuis des années par un support qui ne dispose d'aucune formulation de la cause. Chaque ticket est refermé sur une explication improvisée, et le suivant recommence.

L'origine est un écart entre deux modèles : ce que l'interface donne à voir et ce que le produit manipule comme objets. Une chose vue par l'utilisateur est un objet pour lui, quelle que soit son existence technique.

Pourquoi c'est important

Cela fournit un angle de recherche à part entière : parcourir ce que l'utilisateur manipule tous les jours et vérifier que chaque élément existe quelque part comme objet du produit. Les écrans ramènent ainsi ce que ni le code ni la base ne signalent.

Cela change aussi le traitement des tickets répétitifs : une famille de réclamations sans cause écrite est un signal de modèle manquant, pas un volume à absorber.

Nuances et limites

Tout ce qui s'affiche n'a pas à devenir un objet : un total, un regroupement d'affichage, une ligne de synthèse peuvent rester des vues sans que personne n'en souffre. Le critère n'est pas la présence à l'écran, c'est que l'utilisateur ait besoin de retrouver la chose, d'en parler, ou d'agir dessus.

Et la correction n'est pas nécessairement de créer l'objet : nommer l'ambiguïté et l'expliquer dans l'interface peut suffire.

Questions ouvertes

• Comment repérer ces cas autrement qu'en lisant les écrans un par un, sur un produit qui en compte plusieurs centaines ?