La demande paraît claire : remplacer les tableurs par une application métier. Au premier atelier, la direction parle de pilotage, les équipes demandent une saisie plus rapide, le contrôle réclame une trace et le support veut arrêter de corriger les mêmes dossiers. Cette friction produit retard, correction manuelle et charge support ; une liste de fonctionnalités peut pourtant réunir tous les mots sans résoudre une seule décision.
Le vrai enjeu est de choisir le travail que le produit doit rendre plus fiable, puis de prouver qu’une tranche étroite peut réellement le transformer. Une discovery d’application métier ne commence donc pas par les écrans. Elle revient aux acteurs, aux décisions, aux objets, aux états, aux exceptions et aux preuves attendues lorsque le cas nominal échoue.
En dix jours, l’équipe observe le terrain, reconstruit un parcours critique, attribue l’autorité sur les données, éprouve droits et règles, prototype les points risqués et découpe un premier lot vertical. La sortie n’est pas un cahier des charges figé : c’est un engagement testable avec exclusions, critères, inconnues, instrumentation et retour arrière.
Cette exécution prolonge l’accompagnement Dawap en développement d’application métier sur mesure. La page service porte le projet global ; la méthode ci-dessous organise les dix jours qui permettent de choisir son premier engagement sans confondre vitesse et précipitation.
Séparer discovery, spécification et prototype
La discovery cherche les décisions qui changent le produit. La spécification décrit un comportement retenu avec assez de précision pour le construire. Le prototype matérialise une hypothèse afin de la confronter aux utilisateurs ou à une contrainte. Les trois peuvent coexister, mais ne produisent pas le même verdict.
Donner une question falsifiable à chaque artefact
Une carte de parcours demande où le travail diverge ; une règle écrite demande quel état est autorisé ; un prototype demande si l’acteur peut prendre la décision avec les informations proposées. Une maquette soignée sans question précise confirme surtout que l’interface peut être dessinée.
Cette frontière protège le budget. La discovery n’écrit pas cent user stories avant d’avoir choisi la capacité critique. Elle ne transforme pas non plus un prototype jetable en architecture implicite simplement parce que sa démonstration a convaincu.
Reconnaître les produits qui exigent une discovery
Le format devient utile lorsque plusieurs rôles modifient le même dossier, que les règles changent selon contexte, que les données viennent de systèmes différents ou qu’une erreur produit une reprise humaine coûteuse. Il concerne aussi les produits existants dont chaque évolution ouvre des exceptions imprévues.
Éviter un dispositif lourd pour une réponse déjà connue
Un formulaire simple, réversible et isolé peut être conçu directement si acteurs, règles, données et fin sont stables. À l’inverse, un petit nombre d’utilisateurs ne réduit pas nécessairement le besoin : dix gestionnaires peuvent porter une décision financière ou réglementaire très critique.
Le coût caché vient rarement du nombre d’écrans. Il apparaît lorsque personne ne sait qui tranche, quel état fait foi, comment corriger une erreur ou mesurer le temps réellement libéré. Dès que ces questions changent l’estimation ou la responsabilité, la discovery possède une valeur propre.
Contractualiser les sorties des dix jours
Avant le premier entretien, le responsable publie les artefacts attendus, leurs validateurs et le verdict qu’ils servent. Chaque séance alimente une décision nommée. Une information intéressante sans effet sur la première tranche rejoint le parking plutôt que d’allonger silencieusement le périmètre.
Assembler un dossier de lancement cohérent
- Une décision cible : acteur, déclencheur, résultat, délai et dommage actuel.
- Un parcours observé : cas nominal, attentes, outils, transferts et exceptions réelles.
- Un modèle métier : objets, états, règles, identifiants et sources autorisées.
- Une preuve de valeur : métrique initiale, seuil attendu et mode de mesure.
- Un prototype ciblé : uniquement les inconnues d’usage qui peuvent invalider la tranche.
- Un lot vertical : périmètre, exclusions, tests, observabilité, migration et rollback.
Les sorties doivent se contredire utilement. Si le prototype demande une donnée que le modèle ne possède pas, la difficulté devient visible avant le code. Si la métrique ne peut pas être capturée, la promesse de valeur doit être reformulée.
Jour 1 : choisir la décision à améliorer
Le groupe part d’une décision ou d’un résultat : accepter un dossier, planifier une intervention, libérer une commande, valider un devis ou clôturer un incident. Il nomme celui qui décide, les informations utilisées, le délai utile et ce qui arrive quand le résultat manque.
Refuser les objectifs qui ne commandent aucun comportement
« Digitaliser », « centraliser » ou « gagner en visibilité » ne suffisent pas. La formulation devient : « un superviseur doit affecter un dossier complet en moins de trois minutes sans demander une information déjà présente ». Elle relie acteur, action, qualité et temps.
Trois décisions maximum entrent dans la discovery, avec une priorité explicite. Les besoins secondaires restent visibles mais ne sont pas développés par anticipation. Si aucune décision ne concentre assez de valeur, le projet retourne au cadrage stratégique au lieu d’inventer un MVP arbitraire.
Jour 2 : observer le travail sans l’idéaliser
L’équipe regarde des dossiers réels, du déclenchement à la fin, en incluant emails, appels, exports, notes et corrections. Elle demande à l’opérateur de commenter ce qu’il vérifie, ce qu’il craint et ce qui le force à quitter l’outil. Les procédures officielles sont comparées aux pratiques.
Traiter le contournement comme une information
Un tableur parallèle peut révéler une règle absente, une attente trop longue ou un besoin de simulation. Le reproduire tel quel serait pourtant une erreur : certains contournements compensent une organisation devenue obsolète ou une étape qui devrait disparaître.
Chaque observation porte fréquence, population et conséquence. Un entretien isolé ne devient pas une règle générale. L’équipe recherche au moins un cas ordinaire, un cas limite et un dossier corrigé après erreur pour comprendre la vraie charge cognitive.
Jour 3 : reconstruire le parcours critique
Le parcours aligne événements, décisions, états, temps d’attente, transferts et outils. Il distingue travail utile, contrôle nécessaire, saisie redondante et reprise. Les zones où le dossier perd son owner ou attend sans échéance deviennent visibles.
Compter les boucles, pas seulement les étapes
Une fiche en huit écrans peut être rapide si elle avance sans retour. Un formulaire court peut coûter une journée si trois acteurs se le renvoient. Le parcours mesure reprises, demandes de précision, changements d’état et temps humain mobilisé.
La cartographie des tâches critiques approfondit le diagnostic du travail existant. Ici, cette carte sert directement à choisir la tranche produit qui supprimera une boucle ou sécurisera une décision précise.
Jour 4 : cadrer objets, états et autorité
Les noms métier remplacent les écrans : dossier, demande, commande, pièce, décision, affectation ou preuve. Chaque objet possède identifiant, états autorisés, transitions, données nécessaires et événements. L’équipe distingue fait observé, donnée saisie et calcul dérivé.
Attribuer l’écriture avant de dessiner le formulaire
Un champ n’est pas seulement visible ou obligatoire. Il possède une source, un moment, un rôle autorisé, une règle de correction et parfois une date d’effet. Si deux équipes peuvent écrire la même valeur, la discovery explicite priorité et conflit.
Les états intermédiaires sont conservés lorsqu’ils commandent une action ou une reprise. « En cours » masque souvent attente client, validation, erreur technique et travail opérateur. Des états trop génériques rendent l’interface simple au prix d’un support aveugle.
Jour 5 : éprouver droits et responsabilités
Rôle par rôle, l’équipe décide qui voit, crée, modifie, valide, annule, exporte et administre. Elle traite délégation, absence, séparation des tâches et accès temporaire. Les droits portent sur l’action et le périmètre de données, pas uniquement sur une page.
Simuler les situations où l’organisation se déforme
Le test couvre remplaçant, manager multi-équipe, prestataire, changement de poste et compte désactivé. Il vérifie aussi qui reprend un dossier lorsque son owner part. Une matrice RBAC parfaite au jour nominal peut échouer dès la première mobilité interne.
Les actions sensibles conservent auteur, date, motif et ancienne valeur. L’audit ne journalise pas tout par défaut : il capture les décisions dont la preuve doit rester compréhensible. Les données sensibles sont minimisées dans les traces et les exports.
Jour 6 : concevoir la preuve de valeur
La baseline mesure le travail actuel : délai de décision, reprises, dossiers incomplets, erreurs, sollicitations support et minutes humaines. Elle segmente par rôle et type de dossier afin qu’une amélioration moyenne ne masque pas une dégradation critique.
Choisir un indicateur que le premier lot peut déplacer
Le lot ne promet pas immédiatement chiffre d’affaires ou satisfaction globale s’il agit d’abord sur une affectation. Il vise un résultat causal proche : taux de dossiers complets à la première soumission, délai entre réception et décision, nombre de retours ou temps utile rendu.
La méthode pour prouver le temps utile gagné par une application organise ensuite la mesure en production. Pendant la discovery, elle empêche de retenir une métrique impossible à instrumenter ou trop éloignée du changement livré.
Jour 7 : prototyper les décisions risquées
Le prototype se concentre sur le moment où l’acteur hésite, compare ou corrige. Il utilise des données plausibles, des libellés métier et les variantes capables de changer l’architecture d’information. Les écrans évidents restent volontairement sommaires.
Tester la compréhension, pas la préférence graphique
L’utilisateur exécute une tâche sans être guidé. L’équipe observe information cherchée, erreur, retour et explication de la décision. Une question comme « aimez-vous cet écran ? » mesure une opinion ; un dossier résolu avec la bonne justification fournit une preuve.
Contre-intuitivement, un prototype moins complet peut réduire davantage le risque s’il expose la seule décision irréversible. Ajouter navigation, dashboard et réglages donne une impression de produit sans tester la règle qui détermine réellement son utilité.
Jour 8 : traiter exceptions et reprise
Les cas de reprise sont choisis parmi les dossiers observés : pièce manquante, doublon, changement après validation, dépendance indisponible, décision contestée ou erreur d’affectation. Chaque exception possède signal, owner, action autorisée et condition de fermeture.
Concevoir le back-office avec le parcours principal
Le support doit retrouver un dossier, comprendre son état, corriger ce qui peut l’être et laisser une trace. Une application qui traite vite le nominal mais exige une requête SQL pour chaque exception transfère le coût vers l’exploitation.
Les corrections respectent les invariants : une validation ne disparaît pas, une donnée source n’est pas écrasée sans autorité et une relance ne duplique pas l’effet. Le premier lot inclut au moins une exception réelle et sa reprise, pas un vague chantier ultérieur.
Jour 9 : découper une tranche verticale
La tranche suit un dossier depuis son entrée jusqu’à une décision observable. Elle traverse interface, règle, données, droits, notification, trace, indicateur et reprise pour une population bornée. Elle évite les lots horizontaux « base de données », « design system » ou « tous les écrans » sans résultat métier.
Faire porter au lot le risque qu’il prétend réduire
Si le risque dominant est la règle, le lot traite une variante significative. S’il concerne l’adoption, il atteint un acteur réel avec un parcours complet. S’il concerne la donnée, il utilise l’identifiant et la source cibles plutôt qu’un fichier parfait fabriqué pour la démonstration.
Le dossier précise inclusions, exclusions, données initiales, migration, tests, seuils, observabilité et rollback. L’estimation distingue construction, incertitude bornée et dépendance externe. Une inconnue structurante devient une expérimentation datée, avec une preuve attendue.
Exemple concret : douze gestionnaires affectent 240 dossiers par jour, dont 18 % reviennent pour pièce absente. Le premier lot vise une cohorte de deux gestionnaires et un seuil inférieur à 8 % pendant dix jours ouvrés ; si les retours restent au-dessus, alors l’élargissement est bloqué et la règle de complétude est reprise.
Second cas concret : la décision doit rester sous quinze minutes entre réception et affectation. Si le p90 dépasse ce délai pendant deux fenêtres consécutives, alors l’équipe conserve l’ancien routage, analyse attente et données manquantes, puis rejoue le test avant toute nouvelle cohorte.
Jour 10 : tenir la décision sur le prochain engagement
La revue présente la décision cible, le travail observé, le modèle, le prototype, la preuve de valeur, les risques et le lot proposé. Elle montre les divergences encore ouvertes plutôt qu’un consensus artificiel. Chaque validateur confirme son périmètre de responsabilité.
Sortir avec un choix et des conditions
Le comité choisit lancer, lancer sous condition, prolonger une preuve bornée, redécouper ou arrêter. Le verdict porte budget, owner, date et événement de révision. « Approfondir » n’est recevable que si la question, la méthode et la fin sont nommées.
- À valider d’abord : décision cible, source des données, accès et baseline.
- À ouvrir ensuite : cohorte, instrumentation, support et critères de généralisation.
- À différer : les rôles et variantes qui ne testent aucune hypothèse du lot.
- À refuser : un delivery sans acteur disponible ni mesure du résultat.
Les pièces validées sont versionnées ensemble. Une modification du parcours sans mise à jour de la métrique ou du modèle crée une dette de décision. Le journal explique pourquoi le lot possède cette frontière et ce qui autorisera son élargissement.
Piloter les inconnues qui changent le produit
Le registre ne collectionne pas tous les dangers imaginables. Il conserve les inconnues capables de modifier valeur, architecture, sécurité, délai ou exploitation : qualité d’un référentiel, disponibilité d’un rôle, règle contradictoire, volume extrême ou obligation non tranchée.
Transformer chaque inconnue en expérience
Pour chaque risque, l’équipe écrit l’hypothèse, la preuve la moins coûteuse, le responsable et la décision résultante. Si la qualité du référentiel est incertaine, elle profile un échantillon réel ; elle n’ajoute pas automatiquement quatre semaines de marge.
Le signal faible compte autant que le blocage déclaré. Quand les utilisateurs expliquent tous une même règle différemment, ou qu’une même décision exige trois fichiers selon l’équipe, la divergence indique un risque produit avant qu’un bug ne se voie en recette.
Éviter les erreurs fréquentes de discovery
Collecter tous les besoins remplace la priorité par le volume. Dessiner trop tôt fige la solution avant la règle. Écouter seulement les managers masque reprises et contournements. Choisir le nominal reporte le coût du support.
Refuser le consensus qui ne produit aucun arbitrage
Donner le même poids à chaque demande crée un produit moyen. Écrire des user stories génériques cache données et droits. Prototyper avec des données parfaites supprime le vrai risque. Estimer sans exclusions transforme le budget en promesse ouverte.
L’erreur inverse consiste à prolonger la discovery jusqu’à certitude totale. Certaines réponses n’apparaissent qu’avec un produit utilisé. Le travail des dix jours est de rendre le premier apprentissage sûr, mesurable et réversible, pas d’anticiper toutes les phases futures.
Plan d’action : transmettre la preuve au delivery
Le backlog reprend décisions, objets, états, règles, exemples et critères sans traduire le dossier en centaines de tickets indépendants. Les tests d’acceptation suivent les dossiers observés. Les données d’essai incluent limites et exceptions plutôt qu’un jeu nominal reconstruit.
Conserver un fil entre décision et comportement
Chaque fonctionnalité du lot indique la décision servie et la mesure associée. Un changement qui n’améliore ni capacité, risque ni apprentissage est repoussé. Cette traçabilité protège la tranche lorsque les demandes opportunistes apparaissent pendant le développement.
Le déploiement commence sur une cohorte qui représente le risque retenu. À la fin de deux fenêtres stables, produit compare résultat, temps, reprises et charge support à la baseline. Si le délai baisse mais que les corrections augmentent, alors la généralisation s’arrête.
Le rollback restaure le dernier parcours sûr sans perdre les décisions déjà prises. Les dossiers créés dans la nouvelle version gardent leur état et leur trace. Le support connaît le point de bascule, les populations touchées et la procédure de réconciliation avant l’ouverture.
Les entrées du lot sont dossiers versionnés, identité du rôle et événements métier ; ses sorties sont décision, statut et preuve consultable. Un owner contrôle dépendances, droits et contrat de données avant chaque ouverture de cohorte, puis consigne les écarts dans le journal de delivery.
L’instrumentation publie délai, erreurs, reprises et âge des dossiers dans le monitoring. Chaque seuil appelle un repli nommé ; le rollback, sa traçabilité et la réconciliation sont exercés en recette avec les mêmes identifiants que le parcours nominal.
Relier tâches critiques, valeur et périmètre
La cartographie des tâches critiques identifie les décisions, attentes et contournements qui méritent une intervention. La discovery utilise cette matière pour choisir une frontière livrable au lieu de chercher à corriger tout le travail en même temps.
Mesurer après livraison et retirer ce qui ne crée plus de valeur
La preuve du temps utile gagné juge ensuite l’effet réel de la tranche. Lorsque le produit existe déjà, la méthode pour retirer une fonctionnalité distingue enfin simplification, substitution et abandon. Diagnostic, exécution et arbitrage gardent ainsi des rôles éditoriaux séparés.
Ces lectures construisent une continuité : comprendre le travail, choisir la première preuve, mesurer son effet puis réviser le périmètre. Elles renforcent la même offre sans attribuer au blog l’intention commerciale de la landing.
Conclusion : prouver avant d’accumuler
Une discovery d’application métier ne vaut pas par le nombre d’ateliers ou de maquettes. Elle vaut par les décisions qu’elle rend possibles avant que le coût de construction ne les rende politiquement difficiles.
En dix jours, décision cible, parcours observé, objets, droits, métrique, prototype, exceptions et lot vertical forment une preuve cohérente. Les inconnues restantes possèdent une expérience, un owner et une conséquence explicite.
Le delivery peut alors commencer petit sans être superficiel : une tranche complète, instrumentée et reprenable apprend davantage qu’un socle horizontal sans utilisateur. Son verdict ouvre l’extension, la correction ou l’arrêt sur des faits partagés.
Dawap vous accompagne pour conduire cette discovery et transformer la preuve retenue en application métier sur mesure, du premier parcours critique jusqu’au déploiement observable et à la reprise opérationnelle.
