Étude de cas — Spectacles de drones
Le rapport que personne n'ouvrait
Refonte d'un compte rendu de sécurité réglementaire que ses destinataires avaient cessé d'utiliser, remplacé par un contournement manuel de vingt minutes par mission.
Le client n'est pas nommé dans cette étude, ses sites d'exploitation non plus. Le métier, les outils et le poste de contrôle le sont : sans eux, il ne resterait qu'un récit abstrait. C'est la règle que je m'applique à ce que je publie : ce que je conçois pour une organisation ne m'appartient pas, le raisonnement qui m'y a conduit, si.
Contexte
L'exploitant produit des spectacles de drones en essaim sur des sites recevant du public. Chaque vol est encadré par la DGAC : la traçabilité des données de mission n'y est pas une bonne pratique, c'est une obligation réglementaire.
L'écosystème logiciel interne couvrait la préparation de mission, une base RTK pour le positionnement de précision et le poste de contrôle en vol, le Drone Control Center (DCC). J'ai rejoint l'équipe comme Product Designer ; la rédaction de la PRD m'a été confiée très vite, en plus de la direction design. Vision produit et design se sont donc retrouvées entre les mêmes mains, sans filtre intermédiaire.
Problème
À l'issue de chaque vol, le DCC générait automatiquement un rapport PDF tabulaire, interne et peu lisible. En pratique, personne ne l'ouvrait.
À la place, le directeur de vol rédigeait un message Slack récapitulant la vitesse du vent, l'état des batteries et les incidents. Un opérateur recopiait ensuite ces informations dans un Google Sheet partagé, sans format imposé. Résultat : environ vingt minutes de travail manuel par mission, trois sources de vérité qui pouvaient se contredire, et une analyse post-vol structurellement impossible à industrialiser. Pour une activité dont la sécurité est le premier argument commercial, ce trou d'outillage devenait un risque.
Le premier réflexe aurait été de redessiner le rapport. C'est le second qui compte : un livrable réglementaire que ses destinataires contournent n'est pas un problème d'esthétique, c'est un défaut de traçabilité.
Challenge 01 — Comprendre pourquoi le rapport n'était pas lu
Le défi : avant de redessiner quoi que ce soit, comprendre pourquoi un artefact déjà automatisé avait été abandonné par ses propres utilisateurs.
Mon approche : en sprint 1, j'ai mené des entretiens avec les directeurs de vol, les opérateurs terrain et l'équipe d'analyse. Le rapport existant empilait trois choses dans un même tableau : de la télémétrie brute, des champs techniques destinés aux développeurs, et les quelques indicateurs réellement utiles au débrief. Le format tabulaire interdisait d'isoler rapidement l'information critique. En premier lieu le dépassement du seuil de vent à 35 km/h, qui conditionne la décision de décoller.
Résultat : une cartographie des besoins en trois couches. Décision immédiate sur le terrain, débrief opérationnel, archivage réglementaire : trois couches qui n'avaient ni le même destinataire ni le même horizon de temps, et qui ont servi de grille à toute la suite.
Challenge 02 — Concevoir un rapport éditorial tenant en deux pages
Le défi : restituer la télémétrie d'un vol dans un document scannable en moins d'une minute par un directeur de vol, tout en restant conforme aux attentes de la DGAC.
Mon approche : j'ai traité le rapport comme un document éditorial, pas comme une vue d'administration. Page 1 : un bloc Operator Feedback ouvert à la saisie libre du directeur de vol, placé en premier parce que c'est la seule information qu'aucun capteur ne produit, puis un Quick Summary (Flight Score, Pyrotechnic Activated, Hotswaps Used, Detected Issues, Backup Hotswap Drones), les Flight Details et le Wind Summary. Page 2 : les System Versions et la table Issues & Errors, qualifiée par gravité. En parallèle, j'ai construit un design system dédié dans Figma (fondations, composants Vuetify, workflows et états), documenté sur sept itérations versionnées avec les développeurs.
Résultat : un livrable unique qui remplace simultanément le PDF abandonné, le message Slack manuel et la recopie dans le tableur.
Challenge 03 — Raccorder l'interface au pipeline de données
Le défi : un rapport n'a de valeur que si sa génération est fiable et son archivage traçable. Le design s'arrête rarement à la maquette.
Mon approche : j'ai piloté avec le PM la conception du
pipeline. Ingestion des journaux de vol (.ulog,
.bin), corrélation avec les relevés d'anémomètres, génération
du PDF depuis la page d'analyse du DCC, dépôt automatique dans une
arborescence Google Drive conforme aux exigences de la DGAC,
notification Slack au directeur de vol avec lien direct. Côté UX, l'enjeu
était de conserver un point de contrôle humain : le directeur de vol peut
éditer le rapport avant archivage, mais le chemin par défaut ne demande
aucune action.
Résultat : une chaîne continue de la donnée brute à l'archive réglementaire, sans aucune ressaisie.
Les entretiens comme source de vérité
Ils passaient plus de temps à compiler les informations qu'à les analyser. La double saisie, Slack puis tableur, n'était pas une préférence : c'était un symptôme. Le rapport automatique existant ne répondait à aucun cas d'usage réel.
Synthèse des entretiens menés en sprint 1 auprès des directeurs de vol et des opérateurs terrain.
Itérations et décisions de design
Sept versions documentées, dont une seule a réellement changé la direction du projet.
La V0 proposait un rapport d'une seule page dense, proche d'un tableau de bord. Les tests internes ont montré qu'elle reconduisait le défaut d'origine : beaucoup de signaux, aucune hiérarchie.
La V3 a introduit la rupture éditoriale (Operator Feedback en ouverture, Quick Summary devenu visuel, Issues & Errors renvoyé en fin de document) et le passage à deux pages. La décision de conserver deux pages plutôt qu'une a été défendue auprès du PM : une pagination explicite permet l'impression pour le terrain et améliore la lecture linéaire. Deux besoins remontés des opérateurs, pas deux préférences de designer.
Les V4 à V6 ont affiné la typographie et la qualification des incidents par gravité. La V7, livrée en handover au sprint 3, est celle qui est passée en production.
Résultats et impact
- ~20 minutes gagnées par mission sur l'analyse post-vol.
- Centralisation à 100 % des flux contractuels, de la donnée brute à l'archivage réglementaire.
- Seuil critique de vent rendu immédiatement lisible sur le rapport comme dans la notification Slack.
- Conformité réglementaire assurée par un archivage automatisé dans l'arborescence attendue par la DGAC.
- Design system versionné sur sept itérations documentées, transmises aux équipes de développement au sprint 3.
Apprentissages
Un livrable abandonné n'est pas toujours un problème de design. C'était ici un problème de cadrage produit. Porter la PRD en parallèle du design a permis d'aligner le périmètre technique sur les besoins métier réels, sans intermédiaire pour filtrer l'un ou l'autre.
La contrainte réglementaire a accéléré les décisions. Je m'attendais à un frein, c'était un arbitre. L'obligation de traçabilité a forcé l'équipe à désigner une source de vérité unique, ce qui a simplifié l'architecture au lieu de l'alourdir.
J'ai testé trop tard avec une partie des utilisateurs. Les directeurs de vol ont été consultés dès le sprint 1, mais les opérateurs qui lisent le rapport en mobilité, sur tablette, seulement au sprint 2. Le volet tablette a été rattrapé ; il aurait dû être posé en amont.