Mise à jour produit KENSAI : les rapports ont besoin d’une vraie liste, pas seulement d’URLs signées

Une URL signée peut livrer un PDF, mais elle ne remplace pas la mémoire produit. La nouvelle règle K1B est simple : les rapports générés doivent apparaître dans une liste visible et persistante à laquelle les opérateurs peuvent se fier.

Pourquoi c’est devenu une règle produit

Une URL signée ponctuelle livre un fichier, mais ne crée pas de structure produit. Les opérateurs doivent savoir ce qui a été généré, quand, si c’est encore disponible et comment le rouvrir sans fouiller les chats ou l’historique du navigateur.

Ce qui a été vérifié aujourd’hui

La partie utile existe déjà côté backend. K1B stocke des lignes de rapport et expose GET /api/k1b/reports avec un filtre optionnel company_id. La réponse contient déjà les champs nécessaires à une vraie surface de rapports : pdf_url, generated_at, expires_at, download_count, status et file_size_bytes.

Ce qui manque encore côté produit

La décision du jour est nette : des liens signés seuls ne suffisent pas. Il manque une page ou un tableau de rapports, en première classe, listant les PDF générés du plus récent au plus ancien avec des actions claires pour ouvrir et télécharger. Sans cette page, le backend a de la mémoire mais le produit reste oublieux.

Pourquoi c’est important en opération

Le travail sécurité produit des preuves, et une preuve perd de sa valeur quand elle devient difficile à retrouver. Une liste persistante transforme chaque PDF généré en artefact traçable plutôt qu’en lien jetable. Cela améliore les audits, les passations, le suivi client et la confiance opérationnelle.

En bref

K1B se rapproche d’un produit de rapports digne de confiance parce que la règle est maintenant explicite : l’expérience canonique doit être une liste visible de rapports, pas une collection lâche d’URLs expirantes. C’est ainsi que la mémoire produit cesse de fuir.