Quand une application métier sur mesure vaut-elle le coup ?
Un logiciel du marché suffit tant que votre métier ressemble à celui des autres. Le sur mesure devient pertinent quand une règle propre à votre activité ne rentre dans aucun outil existant, quand vous passez vos journées à recopier des données d'un tableur à l'autre, ou quand votre produit est lui-même une plateforme. Pour Eco-Actives, par exemple, une seule animatrice ne peut tenir qu'un atelier à la fois : réserver un créneau doit faire disparaître les autres ateliers proposés au même moment. Aucun module de stock ne sait exprimer cette règle, il a fallu l'écrire.
À l'inverse, si un outil existant couvre 90 % de votre besoin, je vous conseillerai de l'adopter et, au besoin, de l'étendre par une intégration plutôt que de tout réécrire.
Ce que j'ai déjà construit
Pour Pitchichi, un service de conseil qui aide les entreprises à choisir leur agence de communication, j'ai écrit l'essentiel de l'API Django REST : 18 modèles répartis en 6 applications, un parcours de qualification du besoin, un annuaire d'agences avec portfolios, des tâches asynchrones supervisées, trois environnements. Pour ScienceProtect, j'ai participé à une plateforme de veille scientifique : API Django puis FastAPI, ingestion de publications, graphe de connaissances.
Ces projets ont des points communs : un modèle de données pensé avant les écrans, des tests automatisés sur la logique métier, un déploiement reproductible, et un code que quelqu'un d'autre peut reprendre.
Ma méthode, du cadrage à la mise en production
Je commence par écrire avec vous les objets de votre métier et leurs règles, puis le contrat de l'API avant la première ligne de code. C'est ce qui a été fait pour le site d'Arbre Agile, dont le contrat HTTP était spécifié dans un fichier OpenAPI avant l'implémentation. Ensuite je livre par petites étapes que vous pouvez essayer sur un environnement de recette, jamais un gros livrable au bout de trois mois.
Chaque modification passe par une branche, une vérification automatique (lint, tests, typage) et une revue avant d'atteindre la recette puis la production. Vous voyez le projet avancer, et vous gardez la main sur ce qui part en ligne.
Une stack sobre et répandue
Côté serveur, j'utilise Python avec Django quand il faut un back-office et des permissions riches, FastAPI quand il faut une API rapide et typée. Les données vivent dans PostgreSQL, parfois dans une base en graphe comme Memgraph quand les relations sont le cœur du sujet. Côté interface, React et TanStack. Le tout est conteneurisé avec Docker et déployé derrière Traefik.
Ce sont des outils largement utilisés : si demain vous recrutez un développeur ou confiez le projet à une autre équipe, elle trouvera un code standard, documenté et testé, pas une technologie maison.
Sécurité, données personnelles et suite du projet
Une application métier manipule souvent des données sensibles : clients, patients, dons, paiements. Je stocke le minimum nécessaire, je hache les mots de passe avec des algorithmes adaptés (argon2 sur 24hprojects), je préfère des liens de connexion signés et à usage unique quand l'utilisateur n'a pas besoin de compte, comme pour les donateurs de TapToSupport, et je limite le nombre de requêtes par visiteur sur les points d'entrée exposés. Les secrets restent sur le serveur, jamais dans le code, et les accès d'administration sont séparés des accès utilisateurs.
Après la mise en production, l'application continue de vivre : nouvelles règles, nouveaux utilisateurs, mises à jour des bibliothèques. Je peux en assurer la maintenance moi-même, ou la transmettre à votre équipe avec une documentation de reprise, des tests qui décrivent le comportement attendu et un déploiement que quelqu'un d'autre peut relancer. Sur 24hprojects, par exemple, l'API est couverte par 55 tests qui servent aussi de documentation vivante.
Web ou mobile ?
La plupart des applications métier que je construis sont des applications web : elles s'ouvrent dans un navigateur, sur ordinateur comme sur téléphone, sans passer par un magasin d'applications, et une mise à jour touche tout le monde en même temps. Une application mobile native se justifie quand elle a besoin d'une fonction du téléphone qu'un navigateur ne donne pas. C'est le cas de TapToSupport, où le paiement sans contact exige une application installée depuis le Play Store : l'application Android est prévue en premier, l'iPhone ensuite, et l'API est commune aux deux.
Un lien direct avec celui qui code
Vous parlez directement à celui qui conçoit et écrit le code. Il n'y a pas de chef de projet qui reformule, pas de perte d'information entre le commercial et l'équipe technique. Quand un projet demande plus de monde, je le dis dès le départ et je m'appuie sur des développeurs avec qui j'ai déjà travaillé, comme sur ScienceProtect ou Pitchichi, en l'annonçant clairement.
Je ne suis pas le bon choix pour une application mobile native complexe à livrer en quelques semaines.
