Lire la norme avant de dessiner une seule vue. J'ai commencé par cartographier le cycle de vie complet de la facture d'après la documentation de la plateforme agréée, en séparant la phase de transmission, qui se joue entre plateformes, de la phase de traitement, qui commence côté acheteur. Cette carte a produit la première décision structurante, et c'est une décision de retrait : tout ce qui relève de la transmission sort de l'interface d'action. L'utilisatrice n'entre dans l'histoire qu'à la prise en charge. Elle ne pose jamais un rejet technique, donc elle n'a aucune raison de le voir comme une option. Classer les statuts par ce qu'ils coûtent, pas par leur ordre. Trois familles, et cette grille commande ensuite toute l'interface. Les silencieux (prise en charge, approbation totale ou partielle) ne portent aucune donnée complémentaire : changement direct, sans modale. Les communicants réversibles (litige, suspension) portent un motif, notifient le fournisseur, et se reprennent. Le terminal (refus) notifie aussi, mais ne se reprend pas. Demander un motif pour une approbation serait une friction injustifiée ; laisser passer un refus sans motif serait une faute de conformité. Sortir le refus du menu déroulant. Le bouton « Refuser » est devenu « Bloquer la facture » : il ouvre une modale d'aiguillage regroupant les trois statuts bloquants, filtrés selon l'état courant, avant d'enchaîner sur le bon gabarit de motif. Deux gabarits, jamais un seul. Le premier pour les réversibles, avec motif filtré, message libre et confirmation neutre. Le second réservé au refus, avec avertissement d'irréversibilité, motif obligatoire, confirmation renforcée et un bouton qui nomme l'action au lieu d'un « Valider » générique. On ne refuse plus par glissement de souris dans une liste : on refuse après avoir traversé un écran qui demandait de choisir. C'est là, et seulement là, que le budget de friction est dépensé. Séparer le statut légal de l'état de travail. J'ai supprimé le statut maison « À traiter » qui cohabitait avec les statuts normés. Le besoin réel passe ailleurs : un filtre de travail dans la liste et un marqueur de ligne qui ne tombe qu'à l'action posée, jamais à la simple ouverture, et qui se réarme si une nouvelle décision devient nécessaire. C'est la réponse directe à la peur de l'oubli : ce qui n'a pas été traité remonte, et remonte encore. Même logique côté paiement, où « Paiement transmis » est le reflet d'un règlement enregistré et non une commande qu'on sélectionne : un flux abandonné ne change rien. La machine propose, l'utilisateur valide. À l'import, un OCR pré-remplit la facture, et les données descendues de la plateforme sont comparées à la base fournisseurs existante. Quand le fournisseur est inconnu, il est détecté et ses informations pré-remplies, à valider. Rien n'est confirmé à sa place, et les champs pré-remplis restent identifiables comme tels. Le point n'est pas que la machine devine, c'est qu'on voie ce qu'elle a deviné. Confronter au réel, et savoir ce qu'on ne tranche pas. Notre gestionnaire comptabilité et facturation, cible exacte du module et impliquée dans aucune décision de conception, a participé aux revues de validation en réagissant aux scénarios que la direction et moi avions anticipés. Focus group de guérilla plutôt que protocole de recherche, mais une source honnête, et infiniment préférable à la validation de ses propres hypothèses en circuit fermé. À l'inverse, plusieurs sujets touchaient la conformité et non le design : mapping exact des libellés, filtrage des motifs par réseau d'origine, règles de renotification du fournisseur. Je les ai documentés comme arbitrages à remonter plutôt que de les résoudre en maquette. Un designer qui tranche seul une question réglementaire ne crée pas une décision, il crée une dette que quelqu'un d'autre découvrira en production.