La question qui vient avant toutes les autres
Avant de choisir une technologie, un prestataire ou un abonnement, il faut trancher quelque chose de plus simple : votre besoin est-il celui de tout le monde, ou le vôtre ? Si votre façon de travailler est celle de votre secteur, un éditeur l'a déjà outillée mieux que vous ne le ferez, et il la maintient pour vous. Si elle ne l'est pas, aucun paramétrage ne comblera l'écart — vous passerez votre temps à le contourner.
Le piège est que la réponse ne se lit pas dans une démonstration commerciale. Elle se lit dans ce que vos collaborateurs font déjà, tous les jours, à côté de l'outil en place.
Quand le logiciel du marché gagne, et il gagne souvent
Il faut le dire clairement, parce que c'est vrai : dans plusieurs situations, acheter un logiciel existant est le bon choix, et construire quoi que ce soit serait une perte de temps et d'argent.
Le cas le plus net est celui des domaines RÉGLEMENTÉS, où la conformité EST le produit : comptabilité, paie, facturation certifiée. Ce que vous achetez n'est pas un écran, c'est le fait qu'un éditeur suive la loi à votre place et mette à jour l'outil à chaque changement. Personne ne devrait reconstruire ça.
Vient ensuite le cas des plateformes qui apportent autre chose que du logiciel : une place de marché, un annuaire, un réseau de clients. Là, le logiciel est le prétexte ; ce que vous payez est l'audience, et elle ne se génère pas.
Enfin, le cas le plus fréquent et le plus banal : votre processus est réellement standard. Vous faites ce que font vos confrères, dans le même ordre, avec le même vocabulaire. L'outil de tout le monde est alors le bon, et son prix se partage entre tous ses clients.
- Conformité réglementaire à maintenir (comptabilité, paie, facturation certifiée)
- La plateforme apporte des clients, pas seulement des écrans
- Votre processus est celui du secteur, sans particularité
- Le sujet est couvert par un spécialiste installé, à un tarif proportionné
Le signal qui dit que le logiciel ne couvre pas votre besoin
Il n'y a pas besoin d'une étude pour le savoir. Le signal est matériel, et il est déjà sous vos yeux : un tableur tenu À CÔTÉ du logiciel. Pas un export ponctuel — un fichier vivant, mis à jour chaque semaine, que quelqu'un maintient parce que l'information dont l'équipe a réellement besoin n'est pas dans l'outil officiel.
Les variantes du même signal se repèrent aussi bien : le champ « Notes » ou « Commentaire » qui porte l'information structurante, parce qu'aucun champ prévu ne convenait ; la double saisie, où la même donnée est entrée deux fois dans deux systèmes ; et la phrase qui revient en réunion, « on ne peut pas le sortir de l'outil ».
Quand ces contournements durent depuis plus de quelques mois, ils ne sont plus des contournements : ils sont le vrai processus, et le logiciel du marché en est la pièce partielle. Le tableur qui vit à côté est alors la meilleure spécification que vous puissiez avoir — il décrit exactement ce que vous suivez, avec vos mots.
Le coût qu'on ne compte pas
Un logiciel du marché se compare rarement à son vrai coût, parce que deux postes sont invisibles sur la facture. Le premier est le temps de contournement : les heures passées à ressaisir, à recoller des exports, à expliquer à un nouveau pourquoi il faut regarder à deux endroits. Il ne se voit nulle part et il se paie tous les mois.
Le second est le tarif par utilisateur. Il est raisonnable à trois personnes et devient structurant à quinze — surtout quand une partie de l'équipe n'a besoin que de consulter. On finit par restreindre les accès pour contenir la facture, c'est-à-dire par dégrader volontairement l'outil qu'on paie.
Le calcul honnête n'est donc pas « prix de l'abonnement contre prix d'une application ». C'est « prix de l'abonnement, plus le temps de contournement, plus le coût de sortie le jour où l'on change », contre le coût de l'application et de son hébergement.
Ce qu'une application sur mesure change vraiment
Une application faite pour votre activité ne fait pas plus de choses : elle fait les vôtres. Les entités portent les noms que votre équipe emploie, les statuts sont ceux de votre processus réel, et l'écran d'accueil montre le chiffre que vous regardez le lundi matin plutôt que celui qu'un éditeur a jugé universel. C'est un gain d'adoption avant d'être un gain de fonctionnalités.
Le second changement est patrimonial : le code d'une application générée par Blueprint Maker est exportable, et l'application tourne sur une base PostgreSQL standard. Vous ne louez pas le droit de continuer à utiliser votre propre outil — vous le possédez, et vous pouvez l'héberger ailleurs.
Deux limites doivent être dites, sans quoi la comparaison serait malhonnête. Une application sur mesure ne vous dispense pas de savoir ce que vous voulez suivre : si le besoin n'est pas clair, aucun outil ne le clarifiera. Et elle ne remplace pas un logiciel réglementé : on ne fabrique pas sa propre conformité.
La grille de décision
En cinq lignes, sans zone grise inutile :
- Le sujet est réglementé et la conformité est le produit → logiciel du marché, sans hésiter.
- Votre processus est celui de votre secteur, sans particularité → logiciel du marché.
- Un tableur vit à côté du logiciel depuis plus de six mois → application sur mesure ; ce tableur est déjà votre cahier des charges.
- Aucun éditeur ne couvre votre métier, ou le tarif par utilisateur dépasse ce que le suivi vous rapporte → application sur mesure.
- Vous ne savez pas encore ce que vous voulez suivre → ni l'un ni l'autre pour l'instant : écrivez d'abord le tableau que vous aimeriez lire chaque lundi.
Le plus souvent, les deux
La réponse réelle est rarement exclusive. On garde le logiciel réglementé pour ce qu'il fait le mieux — tenir la comptabilité, produire la paie — et on construit une application pour la partie opérationnelle qu'il ne couvre pas : le suivi des chantiers, des interventions, des adhérents, des stocks. Chacun son métier.
Sur ce point, une précision honnête : il n'existe pas aujourd'hui de connexion automatique entre les deux. Les applications générées exposent bien une API, mais protégée par la session — pas encore de clé permettant à un autre logiciel de s'y brancher seul. La circulation se fait donc par export CSV ou JSON, ou par accès direct à la base si vous hébergez vous-même. Et comme le code vous appartient, ajouter cette clé reste un travail de développement ordinaire.
La bonne question à se poser n'est donc pas « lequel des deux », mais « quelle part de mon activité est réellement la mienne ». Cette part-là mérite un outil qui lui ressemble ; le reste s'achète.