Temps de lecture estimé : 4 minutes
En bref
- Le réflexe. Pour développer une application métier, on commence par un cahier des charges. Mais exprimer un besoin par écrit, avant d’avoir vu un écran, tombe souvent à côté.
- La méthode. Un atelier de vision pour poser les briques, puis des séances de cadrage de deux heures maximum, avec une maquette produite entre chacune.
- L’outil. Une maquette construite avec Claude, qui s’ouvre dans un navigateur et se clique comme la vraie application.
- Ce qui reste écrit. Le cahier des charges traite ce qui ne se voit pas à l’écran : règles de calcul, droits, volumes, reprises de données.
- Le résultat. Deux livrables qui ne font pas doublon, et une consultation où les prestataires chiffrent un périmètre visible.
Le problème du document écrit
Une entreprise veut développer une application métier. Réflexe immédiat : le cahier des charges. On réunit les métiers, on écrit ce que l’outil devra faire, on envoie le document à des prestataires.
Mais exprimer un besoin par écrit, avant d’avoir vu le moindre écran, c’est difficile. Le document tombe souvent à côté. Et comme il reste flou, les prestataires chiffrent chacun à leur manière : les devis ne sont plus comparables.
D’où notre approche : des ateliers courts, et une maquette.
Un atelier de vision, puis des séances de deux heures
Le premier atelier pose le décor. Quels services sont concernés, quelles informations l’outil devra gérer, à quels logiciels existants il devra se connecter. Pas de détail à ce stade, seulement la vision d’ensemble.
Viennent ensuite les séances de cadrage. Deux heures, jamais plus. Au-delà, le fil se perd et on entre dans un niveau de détail qui ne peut pas encore se décider.
Deux heures suffisent à avoir de quoi maquetter. Le reste se traite à la séance suivante.
Qu’est-ce qu’une maquette change concrètement ?
Entre deux séances, nous construisons une maquette avec Claude, une intelligence artificielle. Elle s’ouvre dans un navigateur, comme un site web. On y voit de vrais écrans, avec des données crédibles, et on passe de l’un à l’autre en cliquant.
Les participants arrêtent alors de valider une intention. Ils cliquent. Et ils disent :
- « ce bouton ne sert à rien »
- « il me manque la date de relance »
- « cet écran, personne ne l’ouvrira jamais »
Ce retour ne sort jamais d’une relecture de document.
Une maquette jetable, et c’est voulu
La maquette ne devient pas l’application. Elle sert à se mettre d’accord. Le développement se fait ensuite avec nos outils no-code.
Ce qui coûte du temps dans un projet, ce n’est pas de reconstruire des écrans déjà dessinés. C’est de se mettre d’accord sur la première version.
Autre avantage : la maquette est faite dans un format standard, que n’importe quel prestataire peut reprendre. Le client ne s’attache pas à nous en acceptant la méthode.
Et le cahier des charges, alors ?
Il reste, et il devient utile. La maquette montre tout ce qui est visible. Le cahier des charges traite ce qui ne se voit pas à l’écran :
- les règles de calcul et de décision
- qui a le droit de voir et de modifier quoi
- le nombre d’utilisateurs et de données à encaisser
- la récupération des données de l’ancien outil
- les échanges automatiques avec les autres logiciels de l’entreprise
Prenons un configurateur de devis, un outil qui aide un commercial à construire son prix en répondant à une série de questions. La maquette montre dans quel ordre les questions arrivent et à quoi ressemble le devis à la fin. Elle ne montre pas les règles qui décident que telle option est incompatible avec telle autre. Ce travail reste à faire.
Mais il va plus vite. L’ordre des questions est fixé, le parcours est validé. On sait quelles décisions doivent être prises, à quel moment, et sur quelles informations.
Le document se concentre sur l’essentiel au lieu de décrire des écrans que personne n’a vus.
Ce que le client récupère
Deux livrables qui ne font pas doublon :
- les maquettes de ses écrans, validées par ceux qui travailleront dessus
- un cahier des charges court, qui traite ce que les maquettes laissent ouvert
Les prestataires chiffrent alors un périmètre visible, pas une intention. Les devis redeviennent comparables.
Et les équipes ont déjà manipulé leur outil avant qu’une ligne de code existe.
C’est la façon dont nous abordons les missions de cadrage et d’AMOA, comme les projets de Digital Factory.
Questions fréquentes
- Combien de temps prend un cadrage par la maquette ?
- Cela dépend du nombre de processus à couvrir. Le format est toujours le même : un atelier de vision, puis des séances de deux heures espacées de quelques jours, le temps de produire la maquette entre deux.
- Qui doit participer aux ateliers ?
- Les personnes qui utiliseront l’outil au quotidien, pas seulement leurs responsables. C’est tout l’intérêt de la méthode : ce sont elles qui repèrent ce qui manque.
- La maquette peut-elle servir à consulter d’autres prestataires ?
- Oui, c’est même un de ses usages. Elle est faite dans un format standard, et elle accompagne le cahier des charges dans la consultation.
- Faut-il déjà savoir avec quelle technologie l’application sera développée ?
- Non. Le cadrage ne présume rien de l’outil de développement. Il décrit ce que l’application doit faire, et le choix technique se fait après.
Crédit photo : picjumbo.com sur Pexels
