Des maquettes cliquables avant d'écrire une ligne de code

Le moment le plus coûteux d'un projet logiciel, c'est celui où l'on découvre, une fois l'outil développé, qu'il ne correspond pas à ce que l'équipe imaginait. Un écran mal pensé, une étape oubliée, un vocabulaire que personne n'utilise sur le terrain. Pour éviter ça, nous commençons chaque projet par des maquettes cliquables : un faux logiciel, sans code derrière, dans lequel vos équipes peuvent naviguer comme dans le vrai. C'est sur cette base que nous fixons le prix, avant d'écrire la première ligne.

Le problème : un cahier des charges ne se teste pas

Un cahier des charges décrit ce que le logiciel doit faire. Mais personne ne lit vingt pages en imaginant précisément chaque écran. Le dirigeant pense à une chose, le responsable commercial à une autre, le développeur en comprend une troisième. Chacun valide le document de bonne foi, et les écarts apparaissent au moment des premiers tests, quand il est tard pour changer de direction.

Une phrase comme « l'utilisateur peut suivre l'avancement de ses commandes » peut donner dix logiciels différents. Liste ou tableau ? Filtrée par client ou par date ? Avec quelles informations visibles d'un coup d'œil ? Accessible depuis un téléphone sur un chantier ? Ces questions trouvent leur réponse en quelques minutes devant un écran, et en plusieurs semaines de développement si on les découvre trop tard.

Ce qu'est une maquette cliquable

Une maquette cliquable ressemble au logiciel final : mêmes écrans, mêmes boutons, mêmes enchaînements. On clique sur « Nouvelle commande », un formulaire s'ouvre ; on valide, on revient à la liste. Mais il n'y a pas de base de données derrière ni de calcul réel : tout est simulé.

Nous la construisons dans un outil de conception d'interface, à partir de ce que vous nous racontez de votre métier. Elle couvre les écrans principaux et les parcours qui comptent : ceux que vos équipes feront dix fois par jour. Pas besoin de tout maquetter au pixel près ; il faut que les choix importants soient visibles.

Comment ça se passe avec vous

1. Nous écoutons d'abord. Comment vous travaillez aujourd'hui, avec quels outils, quels tableurs, quels papiers. Ce qui fait perdre du temps. Qui utilisera le logiciel, sur quel appareil.
2. Nous proposons une première maquette. Les écrans clés et les parcours principaux, avec vos vrais termes métier.
3. Vous la faites tester. Idéalement par les personnes qui utiliseront l'outil, pas seulement par la direction. Un chef d'atelier ou une assistante commerciale repère en cinq minutes ce qu'aucune réunion n'aurait révélé.
4. Nous corrigeons. Modifier une maquette prend quelques heures ; modifier un logiciel développé prend des jours. C'est le moment de changer d'avis, et nous vous y encourageons.
5. Nous fixons le prix. Une fois la maquette validée, nous savons précisément ce qu'il faut construire. Le prix est fixé à ce moment-là, avant le développement.

Ce que les maquettes évitent

Trois problèmes reviennent dans presque tous les projets qui dérapent. Les maquettes les traitent en amont.

• Les malentendus. Tout le monde valide la même chose, visuellement, au lieu d'interpréter un texte.
• Le prix flou. Un prix fixé sur un cahier des charges vague contient soit une grosse marge de sécurité, soit des avenants à venir. Un prix fixé sur des écrans validés est plus juste pour les deux parties.
• Le logiciel que personne n'utilise. Un outil imposé sans que les équipes aient eu leur mot à dire est souvent contourné, et le tableur revient. Des utilisateurs qui ont testé la maquette et vu leurs remarques prises en compte adoptent l'outil plus facilement.

Les limites, pour être honnête

Une maquette ne dit pas tout. Elle montre ce que l'utilisateur voit, pas la complexité de ce qui se passe derrière : un calcul de prix qui dépend de vingt règles, une synchronisation avec votre logiciel de comptabilité, un fonctionnement hors connexion sur le terrain. Ces points-là, nous les identifions pendant la conception et nous les expliquons avec la maquette, parce qu'ils pèsent dans le prix sans se voir à l'écran.

De même, une maquette n'est pas une promesse de pixel. Le logiciel final reprend ses choix, mais il est plus précis, plus rapide, et il traite les cas particuliers que la maquette ne montre pas.

Et ensuite ?

Après la maquette viennent les trois autres étapes de notre méthode : le développement, avec une version testable toutes les deux semaines ; les tests et la recette avec vos utilisateurs ; puis la livraison et la formation, avec le code source et la documentation remis. La maquette reste la référence tout au long du projet : quand une question se pose, on y revient.

Cette approche s'applique à tous nos logiciels métier, à nos applications iOS et Android comme aux plateformes SaaS. Si vous avez un projet, même encore flou, le rendez-vous de 30 minutes est le bon point de départ : nous vous dirons comment nous le maquetterions.