Acheter une application métier au forfait, puis la faire vivre
Un développement sur mesure se paie deux fois : à la livraison, puis pendant des années. Voir le second coût avant de signer change complètement la décision.
Une application métier sur mesure se compare rarement au bon adversaire. On la met en face d’un logiciel du marché, on regarde les deux prix d’achat, et le sur-mesure perd - parfois à raison.
La comparaison honnête porte sur autre chose : ce que coûte, sur cinq ans, un outil qui ne fait pas tout à fait ce que vous faites.
Les deux coûts d’une application
Le premier est la livraison. Il se chiffre, il s’écrit, il se paie une fois. Au forfait, il est connu avant que la première ligne soit écrite : c’est tout l’intérêt du modèle, et la seule façon d’arbitrer sereinement contre une solution du marché.
Le second est l’exploitation. Hébergement, sauvegardes, mises à jour de sécurité, corrections, petites évolutions au fil de l’usage. C’est celui qu’on oublie de chiffrer, et c’est celui qui décide si l’application sera encore là dans cinq ans.
Une application qu’on n’entretient pas ne meurt pas d’un coup. Elle se dégrade : une dépendance qui n’est plus maintenue, un navigateur qui change, une règle métier qui évolue sans que personne ose toucher au code. Puis un jour l’équipe recommence à tenir un fichier Excel à côté, « en attendant ». C’est le vrai mode de décès, et il est silencieux.
Ce qui a été fait dans le cas dont je tire cette note
Une application de gestion d’hôpital de jour : dossiers, planning, suivi quotidien des prises en charge. Développée sur mesure, en production depuis plusieurs années.
Le modèle : forfait à la livraison, puis redevance mensuelle d’exploitation. Deux lignes, deux natures de dépense, aucune ambiguïté sur ce que couvre laquelle. La redevance n’est pas un abonnement déguisé au logiciel - le client n’achète pas le droit de l’utiliser, il paie qu’elle reste en état de marche.
Une démonstration en ligne est ouverte, sur données entièrement fictives. C’est la façon la plus courte de répondre à « à quoi ça ressemble, concrètement ».
SaaS ou chez vous : la question à se poser
Les deux fonctionnent, et le choix ne se joue pas sur la technique.
- En SaaS, je m’occupe de l’hébergement, des sauvegardes et des mises à jour, sous redevance mensuelle. Vous n’avez pas d’infrastructure à tenir.
- En on-premise, l’application est déployée dans votre infrastructure et vos données n’en sortent pas. Vous gardez la main, vous portez l’exploitation.
La question utile est : avez-vous une équipe qui tient déjà des serveurs ? Si oui, l’on-premise ne vous coûte presque rien de plus. Sinon, il vous coûte un métier que vous n’avez pas.
Sur la propriété
À poser avant de signer, avec n’importe quel prestataire : à qui appartient ce qui est développé, et que se passe-t-il si vous changez d’avis sur le prestataire ?
Une application sur mesure dont vous ne pouvez pas récupérer le code n’est pas un actif, c’est une dépendance de plus. La réponse doit être écrite dans le contrat, pas donnée à l’oral.