L'équipe Renovsecure travaillait directement dans Claude et lui demandait des récapitulatifs.
AI Product DesignUX/UIPrototypageMission client
RenovSecure AI Control
Une interface pour suivre les résultats des agents IA et intervenir quand une automatisation se bloque.
RenovSecure faisait déjà travailler plusieurs agents et automatisations. Mon travail a consisté à rendre leurs résultats consultables, puis à concevoir un parcours qui permet à l'équipe Renovsecure d'intervenir et de vérifier l'issue. C'est mon deuxième projet client en AI Product Design, après RenovSecure Vision.
- Client
- RenovSecure — Belgique
- Année
- 2026
- Rôle
- AI Product Designer · UX/UI & Prototypage
- Périmètre
- Discovery, parcours, wireframes, prototype, brief de réalisation, développement
- Réalisation
- Participation au développement de la version livrée dans un artefact Claude
Le fil conducteur
Rendre les résultats des agents consultables, puis permettre à l'équipe d'intervenir et de vérifier l'issue.
01 — Contexte
Des agents qui travaillent, mais des résultats difficiles à suivre.
RenovSecure, entreprise belge de rénovation, avait mis en place ses agents et automatisations pour le suivi des campagnes, le SEO, le traitement des leads et la production de contenus.
Les résultats, les fichiers et les alertes étaient répartis entre plusieurs outils. Il fallait rechercher les liens.
L'équipe devait le repérer elle-même, puis relancer l'action, sans savoir ensuite si elle avait abouti.
Le besoin principal
Voir ce que les agents ont produit. Savoir ce qui demande une intervention. Vérifier qu'une action a effectivement abouti.
Mon rôle
J'ai mené la discovery, cadré le produit, conçu les parcours, les wireframes desktop et mobile, puis le prototype. J'ai intégré les retours de l'équipe Renovsecure, préparé le brief de réalisation et participé à la réalisation et au développement de la version livrée dans un artefact Claude.
Le rôle de l'équipe Renovsecure
Elle a mis en place et opère ses agents et automatisations. Elle a apporté les situations métier, puis testé le prototype et la version réalisée.
Les quatre tâches à couvrir
- 01RetrouverAccéder à un résultat ou à un fichier produit par un agent.
- 02ComprendreSituer l’état d’une action et la fiabilité de l’information.
- 03IntervenirConfier à Claude une demande déjà contextualisée.
- 04VérifierConsulter la preuve de l’effet dans l’outil métier.
02 — Discovery
Trois situations réelles ont cadré le produit.
À partir du brief que l'équipe demandait à Claude, j'ai vérifié avec elle ce qui avait réellement été accompli et ce qui demandait une action.
Le fichier de recommandations publicitaires existait dans Drive, mais l’équipe Renovsecure a dû demander son lien exact à Claude. Le résultat était là ; il n’était pas consultable.
Le blocage d’un workflow de rappels était passé inaperçu. L’équipe a demandé à Claude de le relancer, mais rien ne confirmait ensuite que les rappels étaient bien partis.
Pour connaître les urgences, l’équipe redemandait un récapitulatif à Claude. Des sujets de gravité très différente arrivaient au même niveau de lecture.
- 01ExaminerReprendre une situation réelle.
- 02ComparerCroiser le récit de Claude et la source métier.
- 03ConfirmerFaire valider le constat par l’équipe.
- 04PrioriserÉvaluer l’impact et l’échéance.
Dans les situations examinées, l'équipe a jugé la réparation des e-mails de test moins importante que d'autres relais. Ce constat a motivé une file d'actions priorisée selon l'impact, plutôt qu'une simple liste chronologique.
03 — Arbitrage 1
Du brief du matin au pilotage opérationnel.
Le premier prototype testait la lecture du compte rendu quotidien. L'équipe Renovsecure l'a trouvé clair et intuitif, puis a demandé à consulter l'évolution des performances, à accéder directement aux livrables et à intervenir sur les problèmes signalés.
- 01V1Tester la lecture du brief du matin.
- 02V2Explorer l’accès aux livrables et l’intervention.
- 03WireframesClarifier les vues, la hiérarchie et la navigation desktop et mobile.
- 04Prototype puis artefactTester les parcours, puis préparer la réalisation dans Claude.
Premier prototype
Brief du matinLe point d’entrée unique
Accueil après les wireframes
01PerformanceSEO, Ads et landing pages en premier
02Actions à menerCe qui demande une intervention
03Brief du matinLa synthèse, toujours accessible
04AgentsL’activité et le dernier état connu
Pourquoi revenir aux wireframes
Les premières itérations laissaient la navigation et les vues métier trop peu visibles. Revenir au wireframe m'a permis de fixer le menu, la hiérarchie de l'accueil et la structure desktop et mobile avant de finaliser l'interface. Le passage au design system sombre n'est intervenu qu'après.
Ce que j'ai décidé
Garder le brief dans l'application, mais donner la première place à la performance. Sur desktop, une navigation latérale persistante ; sur mobile, une navigation compacte avec un accès « Plus ». Un même incident reste accessible depuis l'accueil, le brief, la file ou une fiche agent.
AWireframesDouze écrans desktop pour fixer la navigation, la hiérarchie de l’accueil et le parcours d’incident, avant tout choix visuel.Faites défiler →
BPrototypeLes mêmes écrans dans le design system sombre, testés par l’équipe Renovsecure. Le suivi des réseaux sociaux y figure encore ; il a été retiré du lancement faute de connexion disponible.Faites défiler →
04 — Arbitrage 2 · Le cœur du produit
De l'incident signalé à la résolution vérifiable.
Signaler un problème ne suffit pas. Il fallait passer d'une alerte à une demande exploitable, avec le contexte déjà préparé, puis savoir si l'intervention avait vraiment produit l'effet attendu.
Le parcours, à partir d'un incident fictif
- 01RepérerL’incident apparaît dans « Actions à mener », avec son type, sa priorité et le prochain geste.
- 02Préparer« Corriger » ou « Traiter » prépare une demande avec le contexte du dossier et l’enregistre.
- 03EnvoyerL’équipe ouvre Claude depuis le dossier et envoie la demande préremplie, ou copie le prompt.
- 04SuivreLe dossier affiche l’étape atteinte, la prochaine action et la dernière mise à jour.
- 05VérifierL’issue se confirme par une preuve métier. Sans preuve, le résultat reste « À vérifier ».
Le rôle de la preuve métier
Une demande envoyée n'est pas un problème résolu.
J'ai distingué ce que chaque étape établit réellement. La résolution se confirme dans l'outil concerné : une vérification dans le CRM, la trace d'un envoi, un lien vers le résultat attendu.
- Demande enregistrée prouve que la demande a été créée.
- Accès rétabli permet de reprendre le workflow, sans prouver que le résultat attendu a eu lieu.
- Trace dans la source métier confirme l’effet : le lot de rappels envoyé, la demande synchronisée, le fichier publié.
- Preuve absente le dossier garde le statut « À vérifier » et indique le contrôle à faire.
Niveau d'automatisation de la version illustrée
L'outil
prépare la demande avec son contexte, l'enregistre, affiche l'étape du dossier et la prochaine action.
L'équipe Renovsecure
ouvre Claude depuis le dossier, envoie la demande préremplie et contrôle l'issue dans l'outil métier.
Pas d'envoi automatique
Aucune action n'est déclenchée sans l'équipe. Dans le scénario du prototype, un nouvel envoi demandait même une autorisation distincte.
05 — Arbitrage 3
Un périmètre adapté aux données disponibles.
Le prototype explorait le suivi des réseaux sociaux. Les connexions étant encore indisponibles, la version lancée a donné la priorité aux landing pages, suivies avec Microsoft Clarity. Chaque vue répond à une tâche concrète de l'équipe.
Balayer les priorités du jour
Les indicateurs SEO, Ads et landing pages en haut de page, puis les actions, le brief et les agents.
Lire l’évolution du référencement
Clics organiques, impressions, période et comparaison lorsqu’elle est disponible.
Isoler une campagne et sa recommandation
Plateforme, période, partenaire et campagne explicites ; la recommandation renvoie à son document.
Examiner un signal avant de décider
Données Microsoft Clarity : sessions, scroll, clics sans effet, erreurs JavaScript, et lien vers Clarity.
Comprendre ce que fait un agent
La mission, le dernier état connu avec son horodatage, la tâche suivante ou le blocage signalé.
Retrouver une image ou une vidéo
Recherche et filtres par type, projet et date ; chaque contenu affiche son statut et son fichier source.
Limite assumée au lancement
Sur de petits volumes, un signal Clarity oriente une vérification ; il ne prouve rien à lui seul. C'est pourquoi chaque signal affiche le nombre de sessions sur lequel il repose. Règle similaire pour les agents : « En cours » est réservé à une exécution observable, sinon l'interface montre le dernier relevé et son horodatage.
06 — Interface finale
Six écrans, six décisions.
Captures de la version réalisée dans l'artefact Claude. Les chiffres, incidents et intitulés sont des données de démonstration. Touchez un écran pour l'agrandir.
07 — Résultats
Des résultats qualitatifs de test.
Observé
- Le premier brief a été compris rapidement par l’équipe Renovsecure.
- Ses retours ont orienté l’élargissement du produit et le parcours d’intervention.
- L’équipe a testé le prototype avec succès.
- Elle a partagé un retour positif sur la version réalisée dans l’artefact Claude.
Pas encore mesuré
- Un gain de temps mesuré.
- Un taux de résolution des incidents.
- Un test complet de résolution, de l’alerte jusqu’à la preuve dans la source métier.
- L’effet des signaux landing pages sur les conversions.
La suite : ce que je propose de mesurer lors d'un pilote
- 01Prise en chargeLe temps entre le signalement d’un incident et sa prise en charge.
- 02Résolution prouvéeLa part des incidents résolus avec une preuve vérifiable dans l’outil métier.
- 03Accès directLa capacité à ouvrir le bon livrable sans demande supplémentaire à Claude.