Un CMS gère du contenu. Il n’est pas conçu pour porter une logique métier, un workflow avec plusieurs rôles utilisateurs, un calcul spécifique à votre activité ou une synchronisation avec plusieurs outils externes. C’est pourtant ce qu’on lui demande souvent, à coups de plugins empilés les uns sur les autres, jusqu’à ce que le site devienne plus fragile que le processus qu’il était censé simplifier.
Quand un CMS ne suffit plus
Le signal est presque toujours le même : vous avez un processus métier — gestion de contrats, suivi d’interventions, espace client avec des documents personnalisés, tableau de bord de pilotage — et vous essayez de le faire tenir dans WordPress ou Prestashop à coups d’extensions. Ça fonctionne un temps, puis chaque nouvelle règle métier devient un bricolage. Les plugins se marchent dessus, les mises à jour cassent des choses, et personne dans votre équipe ne sait plus vraiment pourquoi telle case se coche automatiquement ou pourquoi tel export ne contient pas les bonnes colonnes.
Une application sur mesure part de l’inverse : on modélise votre métier — vos objets, vos rôles, vos règles — puis on construit l’interface et l’API autour. Rien de superflu, rien à contourner. C’est plus long à développer qu’un site vitrine, mais c’est un outil qui vous appartient et qui évolue avec votre activité plutôt que de la contraindre. La base de données reflète exactement comment vous travaillez, pas comment un éditeur de plugin imagine que tout le monde travaille.
Ce choix n’est pertinent que si le besoin le justifie. Un formulaire de contact ou une page produit n’ont pas besoin de développement sur mesure — voyez plus bas les cas où je vous déconseille cette voie plutôt que de vous vendre un projet disproportionné.
Ce que je développe
Je conçois des outils métier de bout en bout : base de données, API, interface, gestion des droits d’accès. Selon votre besoin, ça va d’un espace client simple à une plateforme avec plusieurs types d’utilisateurs et des intégrations tierces — paiement, facturation, emailing, CRM externe, outil de comptabilité. Voici les quatre familles de projets qui reviennent le plus souvent.
Espaces clients et back-office
Un espace où vos clients suivent leurs commandes, contrats ou dossiers, avec un back-office pour votre équipe qui gère les mêmes données côté administration.
API et intégrations
Une API qui expose vos données à un front web, une application mobile ou un partenaire externe, avec authentification et gestion fine des droits.
Outils métier internes
Un outil pensé pour un processus précis — planification, facturation, suivi d’interventions — qui remplace un tableur ou un enchaînement d’outils qui ne communiquent pas entre eux.
Plateformes et places de marché
Une plateforme qui met en relation plusieurs profils d’utilisateurs, avec des règles métier propres à chaque rôle et une logique de mise en relation ou de transaction.
Ces quatre familles se combinent souvent sur un même projet : un espace client s’appuie sur une API, un outil métier interne devient parfois la base d’un espace client externe quelques mois plus tard. Je conçois toujours l’architecture en pensant à cette évolution possible, même quand le premier lot livré reste modeste.
Les technologies que j’utilise
Je choisis la stack en fonction du projet, pas l’inverse. Trois technologies reviennent le plus souvent dans mes missions, et je ne les mélange pas par habitude mais parce que chacune répond à un contexte précis.
Symfony quand le projet s’inscrit dans un écosystème PHP existant, ou qu’il a besoin d’un framework mature avec un ORM solide et un back-office généré rapidement. Le détail sur la page développement Symfony.
NestJS quand je construis une API structurée, testable, avec une architecture claire à faire évoluer sur plusieurs années — c’est le choix que j’ai fait par exemple pour la plateforme e-learning CMDQ. Plus de détails sur la page développement NestJS.
Next.js côté front quand l’interface doit être réactive, rapide, et parfois indexable par les moteurs de recherche — utile pour un espace client public ou une plateforme avec une vitrine associée. Voir la page développement Next.js.
Ces briques se combinent souvent : une API NestJS ou Symfony derrière, un front Next.js devant. Si votre besoin est avant tout un CRM ou un outil de suivi métier plutôt qu’une plateforme complexe, la page CRM et outils métier détaille cette famille de projets en particulier, avec ses propres repères de budget.
Un exemple concret
Sur ce projet, la séparation entre API, front et gestion de contenu a permis à l’équipe CMDQ de publier ses formations en autonomie tout en gardant une logique métier — droits d’accès, progression, certification — centralisée et fiable côté API. C’est ce découpage que je reproduis, adapté à chaque contexte : parfois un seul bloc suffit, parfois il faut vraiment séparer les responsabilités pour que chaque partie de l’équipe travaille sans marcher sur les pieds de l’autre.
Le même principe s’applique à des projets plus orientés gestion interne, comme une application Next.js développée pour One Incendie afin de suivre clients, contrats et interventions dans un seul outil plutôt que dans plusieurs tableurs disjoints.
Quand je vous déconseille une application sur mesure
Je ne vends pas du sur-mesure par principe. Si votre besoin correspond à un CMS, à un plugin existant ou à un outil du marché, je vous le dis, même si ça veut dire vous orienter vers une prestation plus modeste que celle-ci.
Un site vitrine, un blog, une boutique avec un catalogue classique n’ont pas besoin d’application sur mesure : Prestashop ou WordPress couvrent largement le besoin, pour un budget très inférieur. De même, si un outil existant du marché répond déjà à 80 % de votre besoin, l’écart ne justifie presque jamais un développement spécifique — le coût de maintenance d’un outil maison dépasse vite l’inconfort de composer avec un outil générique un peu moins parfait.
L’application sur mesure devient pertinente quand votre processus est vraiment spécifique à votre métier, qu’aucun outil du marché ne le couvre correctement, et que vous avez la capacité — budget et temps — de le faire vivre dans la durée. Un outil métier qu’on développe puis qu’on abandonne sans maintenance devient un risque : failles de sécurité non corrigées, dépendances obsolètes, plus personne pour le faire évoluer quand un besoin change.
Un besoin métier précis à cadrer ?
Je réponds sous 48h avec un premier avis sur la faisabilité et l’approche technique la plus adaptée à votre budget.
Budget, délais et suite du projet
Une application complète démarre à 5 000 € HT ; un besoin plus modeste — automatisation, connecteur, script métier — se règle en régie en quelques jours. Comptez 5 000 € pour un outil simple à un seul rôle utilisateur. Le budget monte avec le nombre de rôles, les intégrations tierces à mettre en place et la complexité des règles métier à modéliser.
Le déroulé type : un cadrage pour définir le périmètre, les rôles utilisateurs et les priorités, puis une phase de développement découpée en lots livrables pour éviter l’effet tunnel d’un projet qu’on ne revoit qu’à la fin. Chaque lot est testé et validé avant de passer au suivant. Vient ensuite la mise en production, avec un accompagnement de démarrage pour que votre équipe prenne l’outil en main sans blocage. Pour les missions longues ou les besoins ponctuels d’un développeur en renfort dans votre équipe, je travaille aussi en régie, entre 400 et 700 € HT par jour selon la complexité du sujet.
Une fois l’application livrée, elle a besoin d’un suivi : mises à jour de sécurité, corrections, petites évolutions au fil des retours d’usage. Je propose un forfait de maintenance à partir de 80 € HT par mois, pour ne pas laisser un outil métier sans surveillance une fois le développement terminé.
Questions fréquentes
Questions fréquentes
Combien de temps prend le développement d'une application sur mesure ?
Ça dépend du périmètre : un outil simple à un rôle utilisateur peut être livré en quelques semaines, une plateforme avec plusieurs profils et des intégrations tierces prend plusieurs mois. Je découpe toujours le projet en lots pour livrer des versions utilisables tôt plutôt qu’un seul bloc à la fin.
Quelle différence entre une application sur mesure et un CRM ou outil métier ?
Un CRM ou outil métier est une catégorie d’application centrée sur la gestion de clients, contrats ou interventions — je le développe avec les mêmes technologies. La page CRM et outils métier détaille ce cas précis, avec ses propres repères de budget.
Pouvez-vous reprendre une application existante développée par quelqu'un d'autre ?
Oui, à condition d’avoir accès au code et de pouvoir l’auditer avant de m’engager sur un budget. Je préfère toujours passer par une phase de découverte courte plutôt que de m’engager à l’aveugle sur un existant que je ne connais pas.
Travaillez-vous seul ou avec une équipe ?
Je travaille seul, en direct avec vous, du cadrage à la mise en production. Pour un projet qui nécessite plusieurs profils en parallèle, je peux intervenir en renfort d’une équipe existante, en régie.
Que se passe-t-il après la mise en production ?
Je propose un accompagnement de démarrage puis un forfait de maintenance à partir de 80 € HT par mois pour les mises à jour de sécurité et les correctifs. Les évolutions plus importantes se traitent au cas par cas, en régie ou au forfait.
Le code m'appartient-il une fois le projet livré ?
Oui. Le code source vous appartient et vous est transmis à la livraison, avec la documentation nécessaire pour qu’un autre développeur puisse reprendre le projet si besoin.
Pour discuter de votre besoin et savoir si une application sur mesure est vraiment la bonne réponse, la demande de devis reste le point de départ le plus rapide.
Guides sur le sujet