L’hébergement est le coût qui apparaît une fois le projet terminé, qui ne figurait jamais dans le devis et qui se poursuit chaque mois pendant toute la durée d’existence de l’application.
Ce dont une application a réellement besoin la première année
La plupart des applications professionnelles en phase de démarrage sont bien plus modestes que ne le pensent leurs propriétaires. Un système utilisé par quelques centaines d’utilisateurs pour effectuer des opérations transactionnelles courantes fonctionne confortablement avec des ressources modestes — prévoir instinctivement une montée en charge qui n’est pas encore arrivée gaspille de l’argent qui serait mieux consacré aux fonctionnalités.
Les composants et leur utilité :
- Serveur d’application — exécute le code. Le dimensionnement dépend du nombre d’utilisateurs simultanés, et non du nombre d’utilisateurs inscrits.
- Base de données — généralement le composant qui compte le plus pour les performances et celui dans lequel il vaut la peine d’investir en premier.
- Stockage de fichiers — téléversements des utilisateurs, documents, images. Il augmente régulièrement et son coût unitaire est faible.
- Domaine et certificat — des coûts annuels réduits ; le certificat doit être renouvelé automatiquement, sinon le site tombe en panne à une date prévisible.
- Distribution des e-mails — les e-mails transactionnels nécessitent un service de distribution adapté, car les e-mails envoyés depuis un serveur d’application arrivent généralement dans les courriers indésirables.
- Sauvegardes — séparées du serveur et testées au moins une fois.
Les coûts faciles à oublier
Les devis couvrent généralement la création. Ces coûts, eux, sont récurrents :
- Hébergement lui-même, chaque mois.
- Stockage des sauvegardes, qui augmente avec le volume de données.
- Transfert de données sortant, qui peut réserver des surprises pour les applications riches en contenus multimédias.
- Distribution des e-mails, généralement facturée selon le volume.
- Services de notifications push, le cas échéant.
- Comptes développeur des stores, chaque année, pour les applications natives.
- Abonnements à des API tierces — cartes, SMS, services d’IA. Il s’agit souvent du poste récurrent le plus important et le plus variable.
- Surveillance et rapports d’erreurs, qui proposent des offres gratuites généralement suffisantes au début.
Demander à un développeur le coût mensuel d’exploitation prévu la première année et pour une utilisation dix fois supérieure est une demande raisonnable ; sa réponse vous renseigne sur le soin apporté à la conception de l’architecture.
Les sauvegardes et l’étape souvent oubliée
Une sauvegarde qui n’a jamais été restaurée reste une hypothèse. C’est la restauration qui compte, et elle doit être testée une fois avant le lancement, puis périodiquement par la suite.
Trois propriétés à définir :
- Fréquence — la quantité de données que vous pouvez vous permettre de perdre. Des sauvegardes quotidiennes signifient une perte pouvant atteindre une journée.
- Rétention — jusqu’à quelle date passée vous pouvez revenir. C’est important, car certains problèmes ne sont découverts que plusieurs semaines plus tard.
- Emplacement — une sauvegarde située sur le même serveur n’est pas une sauvegarde.
Surveillance
Deux éléments méritent d’être mis en place dès le premier jour, et tous deux proposent des offres gratuites :
La surveillance de disponibilité alerte quelqu’un lorsque le site ne répond plus. Sans elle, le premier à remarquer une panne est un client.
Le signalement des erreurs capture les erreurs de l’application avec suffisamment de contexte pour les diagnostiquer. Sans lui, tout ce que l’on peut dire est « cela n’a pas fonctionné », et reproduire le problème prend plus de temps que de le corriger.
Qui doit détenir les comptes
C’est le point qui a les plus grandes conséquences à long terme et qui reçoit le moins d’attention sur le moment.
Le client doit être propriétaire des comptes d’hébergement, du domaine et des services tiers, le développeur bénéficiant d’un accès. Pas l’inverse.
Lorsque les comptes sont au nom du développeur, changer de développeur devient une négociation plutôt qu’une transmission, et si la relation se termine mal, le client peut perdre l’accès à sa propre infrastructure. C’est également un problème pratique dans les situations ordinaires : facturation, renouvellements et e-mails de récupération sont tous envoyés à un endroit auquel le client ne peut pas accéder.
Mettre cela en place correctement ne coûte rien au départ et il est délicat de revenir dessus plus tard. Le domaine, en particulier, doit toujours être enregistré au nom du client.
Les points à régler avant le développement
- Où l’application sera hébergée et sur le compte de qui.
- Le coût mensuel estimé au lancement et pour une utilisation dix fois supérieure.
- La fréquence, la rétention et l’emplacement des sauvegardes — ainsi qu’un test de restauration.
- Qui est averti lorsque l’application tombe en panne et de quelle manière.
- Quels services tiers entraînent des frais récurrents et comment ceux-ci évoluent.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels professionnels pour les CRM, systèmes de réservation, de gestion des stocks et de gestion des workflows.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion du back-end.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander une étude du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.