Cas client : un MVP livré en 18h de travail, hébergé pour moins de 8 €/mois

Deux questions reviennent systématiquement quand on me confie un projet : combien de temps avant d'avoir quelque chose d'utilisable et combien ça va coûter à faire tourner, une fois en ligne. Ce cas répond aux deux, avec des chiffres réels plutôt que des estimations.

Le besoin

Une coopérative agricole réelle au Bénin avait besoin d'une application pour suivre ses intrants, ses coûts mensuels, sa production et ses marges. Des utilisateurs qui comptent leurs sacs d'engrais au kilo près — pas une démo, pas des données fictives.

Ce qui a été livré, et en combien de temps

Le produit a été conçu, développé, testé et mis en ligne en 18 heures de travail effectif, réparties sur quelques jours. Dans ce délai :

Une application complète, utilisable hors connexion (le terrain au Bénin n'a pas toujours la donnée mobile), avec export des données en Excel multi-devises
Une authentification sécurisée développée sur mesure (pas un module tiers non vérifié)
Une suite de tests automatisés qui filme réellement le parcours utilisateur à chaque mise à jour et publie la vidéo — la documentation n'est pas un fichier qu'on écrit une fois et qu'on oublie, c'est une preuve qui se renouvelle à chaque changement
Un système de déploiement automatique : chaque mise à jour validée part en production sans étape manuelle oubliable

Ce délai n'a été possible que parce que le cadrage était fait en amont — un brief clair, versionné, et une vérification systématique à chaque étape plutôt qu'une confiance aveugle dans l'outil.

La rigueur n'a pas sauté malgré la vitesse

C'est le point qui compte le plus pour un client : livrer vite ne veut pas dire livrer moins bien vérifié.

Sécurité vérifiée, pas supposée. Une limite de tentatives de connexion a été ajoutée après une relecture des journaux de production — la vigilance ne s'est pas arrêtée au premier déploiement.
Zéro raccourci non documenté. Aucun "TODO" ou correctif provisoire oublié dans le code livré.
Une erreur trouvée avant le client. Une coquille dans un fichier d'exemple a été repérée et corrigée avant la mise en service — parce que quelqu'un a pris le temps de tout relire, ce que peu de prestataires font vraiment.
La preuve plutôt que la promesse. La vidéo ci-dessus n'est pas une capture d'écran retouchée : c'est le rapport automatique généré à chaque exécution des tests. Si un doute existe sur un comportement, la vidéo tranche.

Le coût réel d'hébergement, mesuré poste par poste

C'est là que ce cas se distingue : plutôt que d'annoncer "c'est une stack légère" sans le prouver, chaque poste de coût a été mesuré directement sur le serveur de production.

Ce qui a été mesuré	Résultat
Machine utilisée	1 vCPU, 2 Go de RAM — le premier prix du catalogue OVH
Coût mensuel	environ 7,80 €/mois
Mémoire utilisée par l'application	~155 Mo, moins de 10 % de la machine
Utilisateurs simultanés supportés	150 à 300 en usage courant, confortable pour une coopérative de 15 membres avec marge jusqu'à 50-100 utilisateurs actifs
Poids du site pour un visiteur	allégé de 213 Ko à 63 Ko après une optimisation trouvée pendant la mesure — 70 % de moins, sans rien changer pour l'utilisateur

Le choix technique (un langage compilé, sobre en ressources, plutôt qu'une stack plus lourde à exécuter) explique une bonne partie de cet écart : à trafic équivalent, ce type d'architecture consomme couramment 5 à 40 fois moins de puissance de calcul que des stacks plus répandues mais plus gourmandes. Sur un serveur à bas coût, ça se traduit directement par une facture d'hébergement qui reste basse même quand l'usage grandit.

Pourquoi ça compte pour vous

Un budget d'hébergement prévisible et bas, pas une estimation optimiste qui explose au premier pic de trafic.
Une sécurité vérifiée à chaque étape, pas une checklist cochée une fois au démarrage puis oubliée.
Une preuve plutôt qu'une confiance sur parole : chaque livraison peut s'accompagner d'un rapport vérifiable, comme la vidéo ci-dessus.
Un numérique responsable qui n'est pas un argument marketing : les chiffres ci-dessus sont mesurés, avec la méthode et les limites de la mesure documentées en toute transparence — je ne cache pas ce que je n'ai pas pu vérifier directement (pas de wattmètre physique sur le serveur, par exemple, donc les chiffres de CO₂ ne sont pas repris ici : seuls les postes que j'ai pu mesurer directement le sont).

C'est cette même méthode — cadrage clair, vérification systématique, mesure plutôt qu'estimation — que j'applique sur chaque mission, quelle que soit sa taille.