Une entreprise vient de me commander une petite application.
il s’agit d’une app pour stocker les données clients et le suivi des projets. L’idée est d’abandonner leurs fichiers Excel et pouvoir avoir une base de donnée commune à plusieurs personnes.
Cela ne me semble pas très compliqué à réaliser en suivant les cours de Maxime et en créant un serveur avec Directus (chose que j’ai déjà faite).
Ma question porte davantage sur la facturation et le modèle économique.
Puisqu’il y a un serveur, je vais avoir des frais tous les mois, pendant plusieurs années potentiellement. Mon idée est donc de facturer l’application au départ, puis de faire payer un abonnement à l’entreprise qui couvrirait les frais de serveur plus les taxes et impôts que je vais payer dessus (et pourquoi pas un forfait maintenance du serveur). Est-ce comme cela que vous procédez ? Mon raisonnement est-il le bon ?
De plus, je vais avoir accès à toutes les données de l’entreprise sur le serveur… cela est-il acceptable ?
Pour ceux qui ont déjà livré des applications avec un webservice, comment fonctionnez-vous ?
Bonjour @Behache,
Effectivement tu vas avoir des frais tout au long de la vie du service. Donc inclure un forfait annuel est normal, d’autant plus que tu peux y intégrer quelques heures de maintenance lié à l’appli et au serveur.
Tu vas également avoir la gestion des data stockées à gérer : anonymisation, purge, chiffrement …
En ce qui concerne les data cela ne pose pas de souci que tu y es accès à condition de respecter RGPD et de stipuler dans ton « contrat » avec ton client : quelle données peuvent être sensibles.
J’aimerais rebondir sur ce sujet car je n’ai encore jamais eu de client (je suis encore en formation) mais j’ai déjà beaucoup réfléchi précisément à ta situation @Behache , et selon moi il y a une chose à prendre en compte.
Disons que tu fasses une facturation annuel pour la maintenance comme stipule @alexandre.cane . Ensuite tu vas avoir d’autres clients, un puis deux, puis trois etc … Selon moi, tu vas finir par perdre du temps à réaliser cette maintenance sur l’ensemble de tes clients et perdre en efficacité sur tes projets à venir.
Personnellement ce que je ferrais, je pense, c’est que je dirai au client de, payer lui même l’abonnement pour l’hébergement server / les stores etc … Soit, je prendrais à mes charges et je facturais exactement le prix qu’il doit payer s’il ne veut pas gérer (mais dans ce cas il faut anticiper, les changements d’offres des services, les potentielles augmentations des tarifs et pour toi derrière, de la perte de temps à informer le client, négocier s’il est pas d’accord de payer plus chère ou autre … c’est pour ce que je préfèrerai lui proposer de gérer lui même).
Et en contre partie, lui facturer une seul fois les frais d’un service de « recherche d’abonnement », pour trouver la solution la plus économique et la plus adaptée à son besoin.
Cette solution te décharge d’une accumulation de charges croissante au fil du temps et ne t’empêche pas de vendre une solution de maintenance et de mise à jour une fois tous les 6 mois par exemple afin de mettre à jour les packages de son application ou les services de stockages par exemple.
ça peut-être une idée intéressante. Mais si tu as plusieurs clients, ça peut vite devenir le bazard entre :
ceux qui oublient de payer le renouvellement
ceux qui n’ont pas les bons mots de passes ou perdus
ceux qui ne mettent jamais à jour les services etc.
Résultat : quand on t’appelle pour un problème de ce type, tu peux perdre un temps fou pour trouver la bonne personne avec le minimum de connaissance sur le sujet pour te fournir ce que tu as besoin.
C’est, personnellement, l’expérience que j’en ai eu quand je faisais du dev. web de mon côté.
La question mérite d’être soulevée et est intéressante, mais pour moi, je pense que garder la main est pas mal aussi…
Effectivement @Mrt1, les points que tu soulèves sont très intéressants de par ton expérience avec des clients. Et comme tu dis je pense que ces solutions doivent être adaptées avec ta manière de penser, ton organisation, ton travail etc …
Je pense pas qu’il est y ai de mauvaises solutions car les deux peuvent être travaillées et améliorées afin d’être optimale pour tes clients.
Cela peut être aussi adapté à tes projets selon leurs importances ou même selon tes clients (selon leur taille, les secteurs d’activités, leurs connaissances en informatique …)
Perso je préfère garder la main sur tout ce qui est hébergement et nom de domaine. Mais tu as tout à fait raison selon certains clients je m’adapte, pour certains il gère leur nom de domaine et je leur propose du self-hosting sur leur propre serveur mais bon des fois je dois gérer des merdes dont je me passerai bien et qui n’ont rien à voir avec mes dev…
Merci à tous pour toutes ces réponses.
C’est un sujet plus complexe que je ne l’avais imaginé.
Je vais regarder tout ça et me mettre au point sur la méthode que je souhaite employer.
Merci pour vos riches retours et merci @Mrt1 pour les liens.
Encore une question qui me vient à l’esprit. Peut-être un peu plus tabou, je ne sais pas…
Quels sont les tarifs qui se pratiquent pour ce genre de prestations (maintenance app + serveur + tarif serveur) ?
Je pensais demander environ 300€/an. Suis-je proche de ce qui se pratique ou pas du tout ?
Je dirais que ça dépend du type de serveurs, de services, etc que tu proposes.
Faut que tu calcules aussi ton temps de travail pour le suivi et la maintenance.
Selon moi il faut d’abord que tu calculs ton TJM (tarif journalier moyen). C’est la variable qui sera universel sur ce type de contrat. En résumé c’est le prix, en moyenne, que vaux une journée de travail selon ton expérience, ta formation et tes connaissances, ta zone géographique (principe d’offre et de demande), la techno sur laquelle tu vas bosser et la durée de la mission.
Ajoute à ça le résultat du calcul de tes coûts pour l’hébergement et l’estimation de la maintenance de l’app (même si elle reste approximative pour le moment, tu seras justifier ton prix avec les critères que je t’ai cité plus tôt).
