Domínio Visual n'est pas une startup. C'est une entreprise de signalétique visuelle — lettres en relief, façades, panneaux, signalétique intérieure — qui travaille pour des clients qui ont besoin que le travail soit posé à une date précise, pas lors d'un sprint hypothétique.
Cet article parle de ce qui se passe quand un vrai métier de services décide d'arrêter de gérer les commandes dans des feuilles Excel, des cahiers et des conversations WhatsApp, et bascule vers une plateforme numérique sur mesure. Ce qu'on y gagne, ce qu'on y perd, et ce qui tourne presque toujours mal à la première tentative.
Résumé exécutif
Un métier de services a trois problèmes opérationnels chroniques : l'état réel de chaque chantier est réparti dans plusieurs têtes, l'historique client vit dans des conversations, et la facturation dépend de qui se souvient de ce qui a été fait. Un logiciel générique ne résout rien à cela parce que le vocabulaire est faux. La solution est une plateforme pensée autour du flux réel de l'entreprise, avec des états qui correspondent aux phases physiques du travail et une interface que n'importe quel membre de l'équipe sait utiliser sans formation.
Dans le cas de Domínio Visual, cela a signifié modéliser dix états allant de « visite technique » à « facturation », une base de données MariaDB conçue autour des ordres de service, et un frontend qui part du principe que l'utilisateur est au milieu d'un chantier et non devant un tableau de bord de métriques.
Le problème métier
Une entreprise de signalétique fonctionne par projet. Chaque ordre de service passe par plusieurs étapes physiques : quelqu'un se déplace pour prendre les mesures, quelqu'un dessine le visuel, le visuel part en validation chez le client, on imprime ou on découpe la matière, on monte la structure métallique si c'est en extérieur, on assemble en atelier, on planifie la pose, on livre, et on ne facture qu'après.
Chacune de ces étapes implique des personnes différentes. Le commercial qui a fait la visite n'est pas le graphiste qui conçoit le visuel. Le graphiste n'est pas celui qui pilote la découpe. Celui qui installe sur site est rarement celui qui était à l'atelier. Et le client appelle pour demander « alors, où en est mon chantier ? » à n'importe lequel d'entre eux.
Sans plateforme, la réponse à cette question dépend de qui décroche. Chacun détient une pièce du puzzle. La vue consolidée n'existe nulle part, elle est éclatée.
Pourquoi cela compte plus qu'il n'y paraît
Il y a trois coûts cachés dans ce modèle, et tous grignotent la marge sans jamais apparaître dans le compte de résultat.
D'abord, le coût de coordination. Chaque chantier génère dix à vingt micro-conversations WhatsApp pour confirmer l'avancement. Multiplie ça par trente ou quarante chantiers en cours et tu as plusieurs heures par jour de personnel qualifié qui fait le travail d'un système.
Ensuite, le coût de reprise. Sans historique centralisé, on refait souvent le travail parce que la version validée du visuel est enfouie dans un mail d'il y a trois semaines, ou parce que les mesures ont été griffonnées au crayon et que personne n'arrive à les relire.
Enfin — et c'est le plus coûteux — le coût de la facturation oubliée. Des chantiers installés mais jamais facturés parce qu'ils sont sortis du radar. Des avenants convenus à l'oral qui ne sont jamais arrivés jusqu'au devis final. Une étude de l'Aberdeen Group d'il y a quelques années suggérait que les entreprises sans processus numériques structurés perdaient entre 1 % et 3 % du chiffre d'affaires annuel en facturation non émise ou non recouvrée. Ce n'est un chiffre qu'on ne retrouve nulle part : il disparaît en silence.
Ce que « plateforme numérique » veut dire pour ce genre d'entreprise
Ce n'est pas un CRM. Ce n'est pas un ERP. Ce n'est pas un Trello avec des états personnalisés. C'est tout cela à la fois, mais avec un vocabulaire qui correspond exactement à ce que l'entreprise fait.
La différence est subtile mais décisive. Si le logiciel appelle un ordre de service un « deal », une « opportunity » ou une « task », l'équipe ne l'utilisera jamais de façon régulière. S'il parle d'« OS » et qu'il affiche les états que l'équipe utilise déjà mentalement — visite, visuel, validation, impression, découpe, serrurerie, production, pose, expédition, facturation — l'adoption est immédiate.
C'est l'argument central en faveur du logiciel sur mesure dans les métiers de services : il ne s'agit pas de fonctionnalités. Il s'agit de langage.
Les décisions techniques qui comptent pour le métier
Chaque choix technique ici a été fait en pensant à l'impact opérationnel, pas à ce qui amuse le développeur.
La base de données est MariaDB relationnelle, pas une base NoSQL à la mode. Parce qu'un ordre de service a des relations rigides avec le client, les lignes, l'historique et la facturation, et quand un comptable a besoin de lancer une requête pour la clôture annuelle, SQL est un langage que beaucoup de gens savent lire.
L'authentification utilise bcrypt pour les nouveaux utilisateurs mais garde la compatibilité avec les anciens hashs MD5. Ce n'est pas élégant. C'est pragmatique : cela veut dire que les utilisateurs existants n'ont pas à réinitialiser leur mot de passe le jour de la migration, ce qui fait la différence entre « tout le monde l'utilise » et « la moitié de l'équipe a abandonné ».
Le frontend est une SPA rapide servie par Nginx, avec une API Fastify en Node.js derrière. On aurait pu partir sur une application Rails classique en rendu côté serveur. Le choix de la SPA découle d'une contrainte concrète : les équipes sur le terrain qui posent les éléments doivent mettre à jour l'état depuis leur téléphone, souvent avec une connexion data médiocre. Une SPA avec état local et synchronisation asynchrone fonctionne mieux dans ce contexte qu'un système qui exige un aller-retour complet à chaque clic.
C'est la seule raison pour laquelle cette décision tient la route. Si tout le monde travaillait au bureau en fibre, une application traditionnelle aurait coûté moins cher à construire et à maintenir.
Modéliser le flux réel : le problème des états
L'erreur la plus fréquente quand on numérise ce genre de métier est de traduire le flux réel en un modèle simplifié à trois ou quatre états : en attente, en cours, terminé. C'est propre sur le schéma et inutile sur le terrain.
Domínio Visual fonctionne avec dix états distincts. Chacun correspond à une phase physique du travail et à une équipe ou une personne responsable :
- Clôturée (0) — état final, après facturation
- Visite (1) — le commercial se déplace pour mesurer
- Visuel (2) — le graphiste conçoit la proposition visuelle
- Impression (3) — vinyle ou matière imprimée
- Découpe (4) — découpe des lettres ou de matière rigide
- Serrurerie (5) — structure métallique si nécessaire
- Production (6) — assemblage en atelier
- Pose (7) — installation chez le client
- Expédition (8) — logistique de livraison
- Facturation (9) — émission de la facture
- Validation du visuel (10) — le client valide avant impression
Ce niveau de granularité n'est pas de la sur-ingénierie. Chaque état correspond à une personne précise qui a besoin de savoir « quels chantiers sont dans mon camp en ce moment ». Fondre deux états en un seul veut dire que cette personne commence à voir des chantiers qui ne la concernent pas. L'adoption s'effondre aussitôt.
L'historique : la fonctionnalité invisible qui résout plus de problèmes que toutes les autres
Chaque ordre de service a une table d'historique associée. Chaque changement d'état, chaque note, chaque pièce jointe est enregistrée avec un horodatage et l'utilisateur à l'origine du changement.
C'est la fonctionnalité que personne ne demande en phase de cadrage et qui devient la plus utilisée six mois plus tard. Parce qu'elle résout trois problèmes opérationnels qui semblaient sans solution technique :
Quand le client appelle pour se plaindre, n'importe qui peut reconstituer la chronologie exacte du chantier sans dépendre de la mémoire des personnes impliquées.
Quand une discussion interne tourne autour de « qui a dit quoi à qui », il existe une trace neutre qui tranche le débat en quelques secondes.
Quand un nouvel arrivant intègre l'équipe, il peut saisir le contexte de chantiers anciens sans avoir à cuisiner cinq personnes.
La règle pratique est simple : si quelque chose peut générer une question du type « au fait, quand est-ce que… » ou « qui a… » trois mois plus tard, cela doit être dans l'historique. Toujours.
Ce qui tourne presque toujours mal à la première tentative
Il vaut la peine d'être précis sur les erreurs qui reviennent dans quasiment tous les projets de ce type, pour que quiconque envisage de se lancer sache ce qu'il faut éviter.
Erreur numéro un : commencer par le module de facturation. C'est intuitif : la facturation, c'est là où l'argent entre, donc cela paraît prioritaire. C'est faux. Si le reste du système n'est pas utilisé, la facturation continue d'être faite en dehors du système comme avant. Commence par l'état opérationnel des commandes ; la facturation suivra d'elle-même.
Erreur numéro deux : demander l'avis de toute l'équipe avant de construire. Chacun veut optimiser le logiciel pour sa partie du flux, ce qui produit un Frankenstein de fonctionnalités contradictoires. Choisis une ou deux personnes expérimentées qui voient le métier de bout en bout et ignore le reste jusqu'à avoir une version fonctionnelle à laquelle réagir.
Erreur numéro trois : ne pas migrer les données historiques. Un nouveau système sans les deux dernières années de chantiers est un système vide. L'équipe continue d'aller voir l'ancien pour consulter le passé. La migration de données est pénible, technique et sans gloire, mais sans elle l'adoption reste toujours partielle.
Erreur numéro quatre : les tableaux de bord avant le flux. Les graphiques sont consultés une fois par semaine par la direction. Le flux quotidien est utilisé par tout le monde. Une plateforme sans tableaux de bord mais avec un flux fonctionnel est utile dès le premier jour. L'inverse ne l'est pas.
Bonnes pratiques valables pour tout métier de services
Domínio Visual fait de la signalétique, mais le schéma s'applique à toute entreprise qui vend des projets : agences créatives, bâtiment, architecture, ateliers, imprimeries, intégrateurs AV, agences événementielles.
- Modélise les états que l'équipe utilise déjà mentalement, pas ceux qui semblent propres sur un schéma
- L'historique de chaque chantier est obligatoire, pas optionnel
- Authentification hybride pendant la migration : n'oblige pas tout le monde à réinitialiser son mot de passe le premier jour
- Base de données relationnelle pour les données opérationnelles ; si tu as besoin d'analyses complexes plus tard, exporte
- Interface pensée pour un usage mobile avec une connexion médiocre, pas pour un écran de bureau
- La facturation vient après la consolidation du flux opérationnel, jamais avant
- Un responsable interne doté d'un pouvoir de décision pour le projet, pas un comité
Sur le choix entre logiciel générique et sur mesure
La bonne question n'est pas « ça coûte plus cher de faire sur mesure ? ». Oui, ça coûte plus cher. La question est : combien vaut le fait que l'équipe utilise le système tous les jours et ne l'abandonne pas au bout de trois mois ?
Un logiciel générique — un Monday, un Asana, un HubSpot bricolé avec des champs personnalisés — est moins cher à acheter. Il est aussi systématiquement plus coûteux à maintenir, parce qu'il oblige l'équipe à traduire mentalement le vocabulaire du logiciel vers celui du métier. Cette traduction échoue précisément dans les moments où le système aurait le plus besoin d'être utilisé : sous pression, avec un client énervé, dans un délai serré.
Un logiciel sur mesure avec son propre vocabulaire supprime cette traduction. Le coût initial est plus élevé. Le coût total de possession sur cinq ans est presque toujours plus faible. Et la valeur d'avoir des données opérationnelles structurées dans ton propre schéma — que tu peux interroger, exporter, analyser sans dépendre d'exports bridés d'un tiers — est difficile à surestimer.
Ce n'est pas une règle universelle. Une petite équipe qui démarre doit utiliser Notion ou un tableur jusqu'à ce que ça fasse mal. Quand ça commence à faire mal, c'est le signal pour construire.
Sécurité et continuité
Une plateforme qui gère les ordres de service, les données clients et l'historique de facturation devient rapidement critique pour l'entreprise. Cela impose trois disciplines que les métiers de services sous-estiment traditionnellement.
Les sauvegardes. Pas hebdomadaires. Quotidiennes au minimum, idéalement incrémentales toutes les heures. Et testées. Une sauvegarde jamais testée est un espoir, pas une garantie. Fais une restauration complète dans un environnement séparé au moins deux fois par an.
HTTPS obligatoire et certificats renouvelés automatiquement avec Let's Encrypt. C'est le standard depuis 2016 et il y a encore aujourd'hui des entreprises qui affichent le cadenas cassé dans le navigateur. Il n'y a aucune justification technique en 2026 à servir une application de gestion d'entreprise en HTTP.
Contrôle d'accès par rôle. Tout le monde n'a pas besoin de tout voir. Si le commercial n'a pas besoin de voir les marges, il ne les voit pas. Si le poseur a juste besoin de l'adresse et du créneau horaire, c'est tout ce qui s'affiche. Le principe du moindre privilège, tel que l'OWASP le décrit depuis des décennies, n'est pas de la paranoïa : c'est de l'hygiène de base.
RGPD : ce qui change quand c'est son propre logiciel
Les entreprises de services en France traitent des données personnelles de leurs clients : noms, adresses, contacts, souvent numéros SIRET ou identifiants fiscaux. Le RGPD, dans son Article 6, exige une base légale claire pour le traitement de ces données et l'Article 32 exige des mesures techniques appropriées.
Avoir son propre logiciel apporte des avantages concrets ici : tu peux mettre en place une rétention de données adaptée, une pseudonymisation là où elle a du sens, un droit à l'effacement sans dépendre de tickets de support auprès d'un fournisseur externe, et des journaux auditables du qui-a-fait-quoi. Un SaaS générique offre tout cela en théorie ; en pratique, chacune de ces capacités dépend du plan souscrit et du temps de réponse du support.
Coût réel : ce que personne ne dit dans les devis
Un projet comme celui-ci, bien mené, a quatre composantes de coût que la plupart des devis sous-estiment.
Le développement initial est la partie visible : la construction de l'application, le design, les tests, la mise en production. Généralement entre 40 % et 60 % du coût total la première année.
La migration des données est toujours sous-estimée. Extraire des données d'Excels, de feuilles papier scannées, d'anciens systèmes, et les transformer en quelque chose de cohérent à importer, consomme plus de temps que n'importe quelle estimation raisonnable le laisse penser. Prévois au moins 15 % du budget.
La formation et l'accompagnement les premières semaines. Les deux premières semaines après la mise en service déterminent si l'adoption prend ou non. Avoir quelqu'un de disponible pour répondre aux questions, corriger rapidement les petits bugs et ajuster les détails d'UX, c'est ce qui sépare « l'équipe a adopté » de « l'équipe est revenue sur WhatsApp ».
La maintenance continue. Serveur, sauvegardes, mises à jour de sécurité, petites améliorations mensuelles. Un montant mensuel prévisible que beaucoup d'entreprises aiment faire semblant d'ignorer jusqu'à ce que le système casse.
Signaux qu'il est temps de passer à l'action
Quelques signaux concrets, du plus léger au plus grave, qui montrent qu'une entreprise de services atteint les limites d'une gestion manuelle :
- Tu reçois des appels de clients qui demandent où en est leur chantier et tu dois demander à trois personnes avant de répondre
- La personne qui tient l'Excel principal est partie en vacances et l'activité a ralenti
- Tu découvres des chantiers terminés depuis des semaines qui n'ont jamais été facturés
- Les discussions internes se concluent par « je croyais que c'était toi qui t'en occupais »
- Les nouveaux arrivants mettent des semaines à comprendre où se trouve quoi
- Quand tu grossis de 20 %, la coordination se dégrade exponentiellement au lieu de scaler linéairement
Si tu reconnais deux ou trois de ces signaux, il est probablement temps. Si tu en reconnais quatre ou plus, il était temps il y a deux ans.
À retenir
Un métier de services n'a pas besoin de technologie impressionnante. Il a besoin d'un système qui utilise le bon vocabulaire, capture l'état réel du travail, conserve un historique auditable et fonctionne sur le téléphone de ceux qui sont sur le terrain.
Le choix entre générique et sur mesure est une décision sur le coût total de possession et sur la probabilité réelle d'adoption par l'équipe. Le générique coûte moins cher à démarrer ; le sur mesure coûte moins cher à maintenir et à utiliser. Pour des opérations critiques, le sur mesure l'emporte presque toujours sur trois à cinq ans.
La migration est une question de conduite du changement plus que d'ingénierie. Que le logiciel soit prêt est une condition nécessaire mais pas suffisante. Sans un responsable interne doté d'autorité et sans une migration sérieuse des données historiques, même le meilleur système reste à moitié adopté.
Le prochain volet éditorial regarde l'autre côté : quand garder tout dans des tableurs a du sens et quand résister à la tentation de numériser trop tôt. Toutes les entreprises ne sont pas prêtes, et parfois construire un système n'est qu'une manière de reporter des décisions opérationnelles qui doivent être tranchées avant.