Cadrer une application avant de la chiffrer

Une application se chiffre mal pour une raison simple : ce que le client décrit est l’écran, et ce qui coûte est en dessous.

« Une appli où mes clients réservent un créneau » peut être trois semaines ou six mois. La phrase est la même. Ce qui suit est ce qui fait la différence, et qu’il faut avoir demandé avant d’avancer un chiffre.

Sur quoi elle doit tourner

La première question, et celle qu’on saute parce qu’elle a l’air évidente.

Un site que l’on consulte au téléphone, une application installée depuis un store et un outil interne utilisé sur un poste de travail sont trois projets différents, avec trois coûts différents et trois délais différents. Le client, lui, dit « appli » pour les trois.

La distinction qui coûte le plus cher est celle des stores. Publier, ce n’est pas exporter : c’est un compte développeur, une revue qui peut refuser, des règles qui changent, et une mise à jour qui met plusieurs jours à sortir. Si personne n’en a parlé, personne ne l’a chiffré.

Les comptes, et le vrai piège des rôles

« Il faudra que les gens se connectent » est une phrase que les clients disent vite. Elle ajoute une inscription, une connexion, un mot de passe oublié, une vérification d’adresse, et un endroit où l’on supprime un compte.

Mais ce n’est pas encore le piège. Le piège est la question d’après : qui voit quoi.

Un rôle, c’est un ensemble de droits. Deux rôles, c’est déjà une matrice à tenir dans chaque écran, chaque bouton et chaque requête. Trois rôles avec des exceptions, c’est la moitié du projet. Le client qui répond « il y aura juste un admin et des utilisateurs normaux » a répondu vite, et il ajoutera « ah oui, et les managers qui voient leur équipe » la semaine où vous pensiez avoir fini.

Posez la question sous cette forme, qui empêche la réponse rapide : listez les types de personnes, et pour chacun, ce qu’il ne doit pas pouvoir voir.

À quoi elle doit se connecter

C’est la question qui transforme un devis, parce qu’une intégration n’est pas une fonctionnalité : c’est une dépendance à quelque chose que vous ne contrôlez pas.

Un paiement, un agenda, un logiciel de facturation, un outil que le client utilise déjà et dont il parle comme d’une évidence. Chacun apporte une documentation à lire, des cas d’erreur à gérer, des identifiants à obtenir, et une panne possible qui ne sera jamais de votre fait mais toujours votre problème.

Deux précisions valent leur poids en heures :

• Qui détient les accès. Un client qui n’a pas les identifiants de son propre outil met souvent deux semaines à les retrouver, et c’est deux semaines de projet à l’arrêt.
• Dans quel sens ça circule. Lire des données et en écrire ne sont pas le même travail, et le client qui dit « synchroniser » veut presque toujours dire les deux.

Les données sensibles, avant plutôt qu’après

Si l’application manipule des données de santé, des données bancaires ou des données personnelles au-delà d’un nom et d’une adresse e-mail, cela change l’hébergement, la durée de conservation, ce qu’il faut écrire dans une politique de confidentialité et ce que le client doit pouvoir prouver.

Ce n’est pas une question technique et ce n’est pas à vous de trancher seul. C’est une question à poser tôt, parce que la réponse déplace des choix d’architecture qui ne se déplacent plus une fois le projet commencé.

Ce qui existe déjà

Une dernière question, la plus rentable de toutes : est-ce que ça remplace quelque chose ?

Si oui, il y a des données à reprendre, des habitudes à respecter et des utilisateurs qui compareront votre travail à ce qu’ils connaissent. Une reprise de données est un projet dans le projet, et elle n’est jamais dans le devis quand elle n’a pas été demandée.

Et s’il existe des maquettes, un croquis ou un cahier des charges, même mauvais, il faut les voir avant de chiffrer. Un document approximatif dit plus sur les attentes qu’une heure de réunion.

La liste complète des questions que ce métier demande est ici : le brief d’une application ou d’un logiciel. C’est un point de départ, à raccourcir et à reformuler selon votre façon de travailler.

Et sur le fait de refuser proprement quand les réponses ne viennent pas : quand refuser une mission.

Questions fréquentes

Quelles questions poser avant de chiffrer une application ?

Sur quoi elle doit tourner, s’il faut des comptes utilisateurs et quels rôles, à quoi elle doit se connecter, si elle manipule des données sensibles, et ce qui existe déjà. Ces cinq réponses écartent la plupart des écarts entre un devis et la réalité.

Pourquoi les rôles utilisateurs coûtent-ils si cher ?

Parce qu’un rôle n’est pas un réglage : c’est une règle à tenir dans chaque écran, chaque bouton et chaque requête. Deux rôles se gèrent. Trois rôles avec des exceptions représentent souvent la moitié du travail, et ils apparaissent rarement dans la première description du client.

Faut-il compter la publication sur les stores dans un devis ?

Oui, et séparément. Publier demande un compte développeur, une revue qui peut refuser, des règles qui évoluent et des délais de mise à jour. Ce n’est pas un export en fin de projet, c’est une étape avec son propre risque de délai.

Que faire quand le client n’a pas les accès à ses propres outils ?

Le découvrir tôt et l’écrire comme une dépendance. Retrouver des identifiants prend souvent deux semaines chez le client, et pendant ce temps le projet ne peut pas avancer. Une intégration sans accès n’est pas une intégration à moitié faite : elle n’est pas commencée.