Une bonne première version ne contient que ce dont le processus principal a besoin pour de vrais utilisateurs, plus la protection des données, les droits d’accès, les sauvegardes et la surveillance. Tout le reste va sur une liste pour plus tard. Cette décision se prend avant la première ligne de code et c’est la plus efficace de tout le projet. Un périmètre restreint vous permet d’obtenir plus tôt de vrais retours et protège votre budget contre des fonctions que personne n’utilisera ensuite.
Dans le métier, on parle souvent de MVP, abréviation de Minimum Viable Product. Nous disons première version, car elle doit fonctionner au quotidien et continuer à grandir ensuite. Un prototype sert au contraire à faire une démonstration et il est souvent abandonné ensuite.
Partez du résultat
Formulez en une phrase ce qui doit être possible après le lancement, par exemple : une cliente peut réserver un rendez-vous en ligne et reçoit une confirmation. Tout ce qui n’est pas nécessaire pour cela devient un candidat pour plus tard.
Écrivez la phrase du point de vue de la personne qui utilise le produit. « Il nous faut un portail client » décrit une solution. « Un client voit ses factures impayées sans devoir appeler » décrit un résultat, et cette phrase permet de vérifier chaque fonction.
Trois questions pour chaque fonction
- Le processus principal fonctionne-t-il aussi sans cette fonction ?
- L’étape peut-elle se faire à la main pour l’instant ?
- Savons-nous avec certitude que quelqu’un en a besoin, ou le supposons-nous ?
Si le processus principal fonctionne sans la fonction, si l’étape peut se faire à la main pour l’instant ou si le besoin n’est qu’une supposition, la fonction va sur la liste pour plus tard. Cette liste ne se perd pas. Elle sert de base à la deuxième version.
Un exemple : la réservation de rendez-vous en ligne
Prenons la réservation de rendez-vous de la phrase ci-dessus comme cas type pour une entreprise de services. Le processus principal a besoin de ces quatre fonctions :
- Afficher les rendez-vous disponibles
- Choisir un rendez-vous et saisir ses coordonnées
- Envoyer une confirmation par e-mail
- Montrer les réservations à votre équipe dans une vue d’ensemble
Ces fonctions peuvent attendre :
- Compte client avec connexion, car au début la confirmation par e-mail suffit.
- Paiement en ligne, tant que le paiement sur place est possible.
- Raccordement à votre calendrier, si l’équipe reporte pour l’instant les réservations à la main.
- Statistiques, jusqu’à ce qu’il y ait assez de réservations.
Ce que coûte la première version et combien de temps elle prend
Sous forme d’application web, une première version peut débuter avec la formule Outil simple, à CHF 9'000 – 13'500. Un portail client se situe à CHF 28'000 – 42'000. Chaque fonction reportée se voit directement dans le calcul. Un raccordement à un ERP ou à un logiciel de branche coûte à lui seul CHF 9'000 – 13'500 et allonge le délai de plusieurs semaines.
Si vous reportez ce raccordement à la deuxième version, vous démarrez d’autant plus tôt. Il faudra certes toujours le payer, mais vous déciderez avec l’expérience de l’exploitation si vous en avez besoin et sous quelle forme. Pour la réservation de rendez-vous de l’exemple, on peut souvent faire encore plus petit : un site web avec un outil de réservation intégré coûte CHF 100 – 170 comme fonction supplémentaire.
Ces valeurs proviennent de notre vue d’ensemble tarifs et valeurs indicatives pour les logiciels. L’article Combien coûte une application web en Suisse ? présente des cas types. Pour un logiciel sur mesure, les formules figurent dans l’article Combien coûte un logiciel sur mesure ?. Seule l’offre établie après l’entretien nous engage.
Là où il ne faut pas couper
Même la plus petite version doit fonctionner de manière sûre et fiable. La protection des données, les droits d’accès, les sauvegardes et la surveillance en exploitation font partie de chaque version, y compris la première. Les ajouter après coup est plus cher et plus risqué. Il en va de même pour les tests et une brève documentation, car la deuxième version s’appuie dessus.
Quand la première version doit être plus grande
Parfois, il n’est pas possible de faire plus petit. Si vous remplacez un système existant, la nouvelle version doit savoir faire tout ce que le quotidien exige absolument, sinon votre équipe fait le travail deux fois. Les exigences légales ou contractuelles ne peuvent pas non plus être reportées. Dans ces cas, un remplacement progressif aide : une partie du processus migre, le reste demeure pour l’instant dans l’ancien système.
Trois pièges du cadrage
- Tout le monde donne son avis et personne ne décide. Désignez une personne qui a le dernier mot sur le périmètre.
- Les cas particuliers reviennent dans le périmètre. Soumettez chacun d’eux aux mêmes trois questions que toute autre fonction.
- Peu avant le lancement tombe la phrase « Tant qu’on y est ». Inscrivez le souhait sur la liste pour plus tard et tenez la date de lancement.
Mesurez avant d’étoffer
Définissez avant le lancement à quoi vous reconnaîtrez le succès : moins d’appels, plus de ventes conclues, un temps de traitement plus court. Notez la valeur actuelle tant que l’ancien processus tourne encore. La deuxième version s’appuie ainsi sur des observations plutôt que sur des suppositions.
La prochaine étape
Si vous pouvez formuler le résultat en une phrase, vous avez l’essentiel pour un premier entretien. Chez SIMPLY CODE SOLUTIONS, nous définissons ensuite ensemble ce qui est nécessaire au lancement et ce qui peut attendre. Vous pouvez directement décrire votre projet. Notre démarche est décrite à la page Développement d’application web. L’article Logiciel sur mesure ou logiciel standard ? vous aide à vérifier si votre propre produit en vaut vraiment la peine.