Un WMS du marché fait très bien ce pour quoi il est conçu : tenir un stock, orchestrer des tâches, tracer des mouvements. Le débat ne porte pas là-dessus. Il porte sur la fraction résiduelle du besoin — celle qui, année après année, ne rentre pas.

La meilleure source sur le sujet est un éditeur

Hardis, qui édite le WMS Reflex, publie lui-même les cas où un développement spécifique se justifie : un contrôle qualité critique propre à un secteur comme la pharmacie ou l’agroalimentaire, des opérations logistiques uniques à une chaîne — cross-docking particulier, flux tendus spécifiques —, une gestion de stock hybride combinant magasins physiques, e-commerce et points relais, et le respect d’obligations légales sectorielles comme la douane ou la traçabilité renforcée.

Le même éditeur documente le cas de Manitou et de son « tribunal des spécifiques » : sur 45 demandes analysées, hors éditions et interfaces, 60 % abandonnées, 26,4 % ramenées au standard, 23,6 % conservées.

Ce chiffre est le plus honnête du marché, parce qu’il vient de quelqu’un qui avait intérêt à ce qu’il soit plus bas. Près d’un besoin sur quatre résiste.

Pourquoi ces besoins résistent

Un progiciel est un compromis entre des centaines de clients. Il modélise ce qui est commun. Ce qui résiste, ce n’est pas ce qui est compliqué — c’est ce qui est propre à une organisation.

Trois familles reviennent.

Les règles issues du secteur. Un plan d’échantillonnage à la réception, un blocage automatique avec libération conditionnelle, une exigence documentaire liée à un agrément. Le progiciel offre un champ de statut ; l’entreprise a besoin d’un protocole.

Les flux qui mélangent des logiques. Le même stock sert un réassort magasin par palette, une préparation e-commerce à l’unité, et un point relais avec ses propres contraintes de créneau. Les règles de priorité ne sont pas les mêmes, et un moteur de tâches paramétrable ne suffit pas toujours. Sur Easy WMS de Mecalux, des utilisateurs décrivent d’ailleurs un moteur de tâches contraint par les restrictions du système, et rapportent que de petites modifications « nécessitent des développements spécifiques avec les coûts correspondants ».

Les obligations qui deviennent des exigences de système. Depuis le 1^er janvier 2022, les entrepôts soumis à enregistrement ou à autorisation au titre de la rubrique ICPE 1510 doivent tenir un état des matières stockées mis à jour au minimum chaque semaine. Produire cet état suppose un stock juste en continu. Côté agroalimentaire, l’article 18 du règlement (CE) n° 178/2002 impose la traçabilité amont-aval, et le règlement d’exécution (UE) n° 931/2011 impose pour les denrées d’origine animale un jeu de données précis incluant le numéro de lot. Le lot cesse alors d’être un attribut optionnel pour devenir une clé.

Le poste le plus rentable, et le plus négligé

L’ergonomie sur douchette. Chaque écran de trop se paie en secondes, multipliées par le nombre de lignes préparées dans l’année. C’est le seul poste où un développement spécifique produit un retour mesurable dès les premières semaines, à condition d’avoir mesuré avant.

Les corpus d’avis vérifiés sur les WMS français sont trop minces pour en tirer une statistique — deux avis pour Reflex WMS, quatre pour Generix WMS —, mais leur formulation converge : un responsable informatique décrit Generix comme « beaucoup trop vieux » et peu ergonomique. Ces retours isolés ne prouvent rien sur les produits ; ils indiquent que l’ergonomie opérateur est un déclencheur d’appel d’offres.

Développer autour, pas à la place

Le montage qui gagne dans la grande majorité des cas conserve le progiciel comme système d’exécution du stock et développe à côté ce qu’il ne modélise pas : l’interface opérateur, le moteur de règles propre à l’activité, les états réglementaires, les flux hors standard.

Il a trois avantages. Il évite une migration de données. Il n’immobilise pas les équipes. Et — c’est l’argument le moins évoqué — il rend le remplacement futur du progiciel plus simple, puisque l’intelligence métier ne vit plus uniquement dans le paramétrage d’un produit tiers.

Pour le détail des besoins d’entrepôt, voir notre page WMS sur mesure pour l’entrepôt.

Une preuve de livraison qui ne tient pas en litige coûte plus cher qu’une absence de preuve, parce qu’elle donne un faux sentiment de sécurité. Cette checklist sert à spécifier avant de développer.

Le contenu de la preuve

• 1. Le statut est-il par colis ou par arrêt ? Trois colis acceptés, un refusé, un endommagé : un statut global ne permet pas de traiter le cas le plus fréquent des litiges partiels.
• 2. Les réserves sont-elles typées ? Une zone de texte libre n’est pas exploitable statistiquement et se prête mal à la contestation. Une liste fermée de motifs, complétée par un commentaire, l’est.
• 3. Les photos sont-elles horodatées et géolocalisées à la prise de vue ? Une photo importée depuis la galerie du téléphone n’a pas la même valeur qu’une photo prise dans l’application.
• 4. L’identité du signataire est-elle capturée ? Nom, qualité — destinataire, gardien, voisin, tiers habilité —, et non seulement un tracé de signature.

Les modes de remise

• 5. Chaque mode a-t-il son régime de preuve ? Remise en main propre, dépôt chez un voisin, boîte à colis, point relais, lieu convenu sans présence : ces situations n’appellent pas les mêmes éléments.
• 6. Le cas de l’échec est-il modélisé ? Absence, refus, adresse introuvable, accès impossible — avec la preuve du passage, qui est souvent le point contesté.

L’intégrité

• 7. La preuve est-elle modifiable après coup ? Si un exploitant peut corriger une saisie après la tournée, la valeur probante de l’ensemble s’effondre. La correction doit exister, mais comme un événement supplémentaire, tracé, jamais comme une réécriture.
• 8. La chaîne est-elle complète en mode hors ligne ? Sous-sols de parkings, zones blanches, ascenseurs : ce qui est capturé sans réseau doit conserver son horodatage d’origine, et non celui de la synchronisation.
• 9. La restitution est-elle possible des années après ? Retrouver la preuve d’une livraison à partir d’une référence de commande client, dans un format lisible et exportable.

La conformité CNIL

Ces points ne sont pas des mentions légales : ce sont des fonctionnalités, et elles se conçoivent au départ.

• 10. Les durées de conservation sont-elles différenciées par finalité ? Deux mois dans le cas général ; un an dès lors que la finalité est l’optimisation des tournées ou la preuve d’intervention ; cinq ans pour le seul suivi du temps de travail. Une purge unique appliquée à toute la base est soit illégale, soit destructrice de preuve — donc la finalité doit être portée par la donnée.
• 11. Le conducteur peut-il désactiver la géolocalisation hors temps de travail ? La collecte hors temps de travail est exclue, pauses et trajets domicile-travail compris. Cela suppose une notion de plage de travail qui conditionne la collecte.
• 12. Les représentants du personnel sont-ils exclus du suivi dans l’exercice de leur mandat ? C’est une interdiction explicite, qui se traduit par un attribut excluant certains collaborateurs du traitement.

Deux précisions utiles. La norme simplifiée NS-051, encore citée par de nombreux prestataires, n’a plus de valeur juridique depuis l’entrée en application du RGPD le 25 mai 2018 ; le cadre applicable est la fiche pratique de la CNIL sur la géolocalisation des véhicules des salariés. Et la liste CNIL des traitements soumis à analyse d’impact vise les traitements ayant pour finalité de surveiller de manière constante l’activité des employés, en citant explicitement le chronotachygraphe des véhicules de transport routier.

Ce que la checklist ne couvre pas

Elle ne dit rien de l’expérience du destinataire — créneau annoncé, notification, replanification — qui relève d’un autre sujet mais se conçoit en même temps, parce que les deux partagent le même modèle d’événement.

Elle ne dit rien non plus de l’ergonomie côté livreur, qui est pourtant ce qui décide de la qualité réelle des données : une preuve complète mais coûteuse à saisir sera contournée dès la troisième semaine.

Pour la traduction en projet, voir notre page application de livraison sur mesure.

Le montage hybride — conserver le progiciel pour l’exécution, développer autour ce qu’il ne modélise pas — est celui que nous recommandons le plus souvent. Il a un point faible unique et prévisible : l’interface.

Voici ce qui casse, dans l’ordre de fréquence.

1. L’API existe, mais pas pour ce dont vous avez besoin

La plupart des progiciels exposent une API pensée pour l’import de commandes et l’export de statuts. Presque aucune n’expose ce qui sert au pilotage économique : les coûts internes, les temps réels d’immobilisation, la structure d’un affrètement.

Le réflexe est de demander « avez-vous une API ». La bonne question est « donnez-moi la liste des ressources exposées en lecture et en écriture, avec leurs champs ». La différence entre les deux se mesure en semaines de projet.

À noter que l’accès à l’API est parfois lui-même un palier commercial : chez AntsRoute, elle n’apparaît qu’à partir de l’offre à 54 € par véhicule et par mois.

2. Les référentiels ne coïncident pas

Le progiciel a ses codes clients, ses codes sites, ses codes véhicules. L’entreprise en a d’autres, souvent hérités de la comptabilité. Le développement doit décider lequel fait foi.

L’erreur classique est de construire une table de correspondance et de la maintenir à la main. Elle est juste le premier mois, fausse le sixième. La règle que nous appliquons : un référentiel maître unique par entité, désigné explicitement au cadrage, et une synchronisation dans un seul sens.

3. Le sens de la vérité n’a pas été tranché

Quand deux systèmes peuvent modifier la même donnée, il faut décider lequel gagne — et le décider par champ, pas par objet.

Sur une mission de transport, il est fréquent que le progiciel soit maître de l’affectation et des statuts, et que le développement soit maître des coûts et des données terrain. Tant que cette répartition n’est pas écrite, chaque incident produit une discussion.

4. Les volumes explosent au premier vrai jour

Une interface validée sur cent missions de test se comporte différemment sur un lundi matin réel. Les points de rupture habituels sont le nombre d’appels par minute toléré par le progiciel, la taille des lots en écriture, et la gestion des reprises après échec partiel.

La règle : tester sur un volume de pointe réel, pas moyen. Un système de transport ne vit pas sur sa moyenne.

5. La mise à jour du progiciel casse l’interface

C’est le risque structurel du montage hybride, et il ne se supprime pas — il se gère. Trois précautions réduisent fortement l’impact : isoler l’appel au progiciel derrière une couche d’adaptation unique, contractualiser un délai de préavis sur les changements d’API, et disposer de tests d’intégration exécutables avant chaque montée de version.

C’est aussi un argument à faire valoir auprès de l’éditeur au moment du renouvellement du contrat.

6. Personne ne surveille l’interface

Une interface qui échoue silencieusement est pire qu’une interface absente : elle donne des chiffres faux avec l’apparence de la fiabilité.

Le minimum est une supervision qui alerte sur trois événements — un lot non traité, un écart de volume par rapport à la veille, un rejet répété sur le même enregistrement. Ce n’est pas un raffinement, c’est ce qui permet de faire confiance au tableau de bord.

Ce qu’il faut décider au cadrage, pas après

• Le référentiel maître de chaque entité.
• Le sens d’autorité champ par champ sur les objets partagés.
• Le volume de pointe à tenir.
• Le comportement en cas d’indisponibilité du progiciel — file d’attente, dégradation, blocage.
• Qui est alerté, et sur quoi.

Ces cinq décisions prennent une demi-journée en atelier. Prises après la mise en production, elles coûtent un ou deux mois.

Le cas le plus parlant dans nos références publiées est Coïncidence, traiteur et lieu de réception de la région lyonnaise gérant des foodtrucks et la privatisation d’un domaine, pour qui nous avons conçu et développé des outils de réservation sur mesure connectés au CRM Dolibarr déjà en place.

C’est exactement le montage hybride décrit ici : le progiciel reste le système de référence commercial, et le développement traite ce qu’il ne modélise pas — dans ce cas des règles de réservation propres à deux activités qui n’ont pas la même logique de disponibilité. Le point qui a demandé le plus d’attention est celui du référentiel maître : décider, avant d’écrire la moindre ligne, quel système fait foi sur le client et quel système fait foi sur la disponibilité.

C’est aussi la leçon la plus transposable au transport. Sur les trois missions d’étude que nous avons publiées — ESLC, Maïa Rail, Grand Lyon et ENFRASYS —, ce sont systématiquement la cartographie de l’existant et l’analyse fonctionnelle, soit les phases 2 et 4 sur six, qui déterminent la difficulté de l’intégration. Une phase de cadrage de 15 à 17 jours, ce qui a été la durée constatée sur ces trois missions, sert d’abord à ça.

Voir aussi notre page logiciel de gestion pour transport routier.

Questions posées à l’équipe technique de SimplX, qui a conçu et développé pour Maïa Rail une solution mobile et web de saisie, de suivi et de diffusion de rapports de soudure aluminothermique — un cas où, comme en chiffrage électrique, un document produit sur le terrain ne vaut que par sa conformité à un référentiel normatif et par sa traçabilité. La mission d’étude, de spécification et de maquettage y a représenté environ 16 jours.

La première erreur d’un développeur qui découvre la NF C 15-100 ?

Croire qu’il s’agit d’un document. Depuis le 21 août 2024, ce n’est plus un document unique assorti d’amendements, c’est une série de 21 normes : une partie 1 pour les règles générales, une série 7-7xx pour dix-sept locaux et installations spécifiques, une partie 8-1 sur l’efficacité énergétique, une partie 10 pour l’habitation, une partie 11 pour les réseaux de communication.

Cette architecture a été conçue pour permettre des révisions partielles indépendantes. Pour un développeur, c’est une information de conception : si vous modélisez le référentiel comme une version globale, vous serez obligé de tout reprendre à chaque révision d’une seule partie. Il faut versionner par partie.

Concrètement, qu’est-ce que ça change dans une bibliothèque de prix ?

Plusieurs choses, et aucune n’est cosmétique.

Les Euroclasses remplacent l’ancienne classification des câbles, avec l’abandon des câbles C3. Les tables de référence changent, et les modes de pose sont renumérotés. Toute bibliothèque construite sur l’ancienne nomenclature doit être remappée, ce qui n’est pas une simple substitution de libellés : les correspondances ne sont pas toujours de un à un.

Le calcul des sections doit désormais tenir compte des harmoniques, ce qui ajoute un paramètre dans les notes de calcul.

Et de nouveaux postes apparaissent au devis : dispositifs de détection d’arc recommandés sur les circuits prises, différentiels de type F pour les variateurs monophasés.

Y a-t-il un piège juridique ?

Oui, et il est rarement écrit. L’arrêté du 3 août 2016, qui réglemente les installations électriques des bâtiments d’habitation, vise toujours le titre 10 de l’ancienne version de la norme. Formellement, la version 2002 reste donc la norme d’application obligatoire au sens réglementaire, sans être annulée.

Dans les faits, la série 2024 s’applique aux installations neuves ainsi qu’aux extensions et modifications depuis le 1^er septembre 2025, et sert de référentiel de contrôle au Consuel.

La conséquence pour l’outil est simple : chaque chiffrage doit tracer sur quel référentiel et à quelle date il a été établi. C’est deux colonnes en base, et c’est ce qui permettra de défendre un dossier deux ans plus tard.

Un exemple de règle qui casse un modèle existant ?

Le paragraphe 551.7.2 de la partie 1 : un générateur ne doit pas être raccordé à un circuit terminal par une prise de courant.

Une seule phrase, et elle disqualifie toute une catégorie de produits — les kits solaires dits « plug and play ». Pour un outil, cela signifie que le mode de raccordement devient un attribut obligatoire de l’ouvrage, avec une validation. Ce n’est plus un commentaire libre dans une ligne de devis.

Le Consuel a d’ailleurs défini plusieurs configurations de raccordement possibles, la dernière imposant un dossier technique complémentaire. Un outil doit savoir dans quelle configuration on se trouve, et déclencher les bonnes pièces.

Et la gestion documentaire ?

C’est la partie qu’on sous-estime toujours. L’attestation de conformité se décline en quatre couleurs — jaune pour l’habitation, verte pour les installations de consommation non domestiques, bleue pour la production sans stockage, violette pour la production avec stockage — chacune avec son formulaire CERFA.

Et les modèles de dossiers techniques ont des dates de validité. Depuis le 29 juin 2026, les anciennes versions des dossiers SC144 ne sont plus acceptées pour les installations de production ; les anciennes versions des certificats de découplage des onduleurs le sont jusqu’au 31 décembre 2026.

Donc un modèle de document n’est pas un PDF stocké dans un dossier. C’est un objet versionné avec une plage de validité, et l’outil doit refuser de produire une pièce périmée.

Un conseil à une entreprise qui hésite à développer ?

Vérifier d’abord si sa méthode de chiffrage lui appartient vraiment. Si l’entreprise chiffre avec les ouvrages standard d’une bibliothèque du marché, elle n’a rien à gagner à développer.

Si elle a construit ses propres ouvrages composés au fil des années, et qu’aucun outil ne sait les représenter sans les déformer, alors le développement protège un actif — sa méthode — qui vaut plus cher que le logiciel.

Le détail des contraintes métier est sur notre page logiciel de chiffrage pour électricien.

Le règlement (UE) 2024/573 est lu comme une contrainte administrative. C’est d’abord un cahier des charges applicatif : presque chacune de ses obligations décrit un calcul, une donnée à conserver ou un document à produire.

Cet article le relit sous cet angle. Toutes les références sont à revérifier à la date à laquelle vous les appliquez.

Ce qui a changé par rapport au règlement précédent

Le règlement (UE) 2024/573 du 7 février 2024 est entré en vigueur le 11 mars 2024 et abroge le règlement (UE) n° 517/2014. Quatre évolutions ont un effet direct sur un système d’information.

Deux unités de mesure coexistent. Les contrôles d’étanchéité sont étendus aux HFO, avec des seuils exprimés en kilogrammes, alors que ceux des HFC restent exprimés en tonnes équivalent CO₂. Un même parc peut donc relever de deux logiques de seuil différentes selon le fluide.

Deux tables de PRP coexistent. Le potentiel de réchauffement planétaire ne se lit plus dans la même table selon le fluide : sixième rapport du GIEC pour les HFO, quatrième pour les HFC. Une table unique produit des résultats faux.

L’étiquetage est étendu à tous les gaz fluorés depuis le 1^er janvier 2025.

Les équipements mobiles — véhicules utilitaires, engins — entrent dans le champ au 12 mars 2027.

Le calcul de la prochaine échéance

C’est le cœur du sujet. La date du prochain contrôle ne peut pas être un champ saisi : elle se dérive d’au moins cinq paramètres.

En dessous de 5 tonnes équivalent CO₂ pour un gaz de l’annexe I, ou de 1 kilogramme pour un gaz de l’annexe II section 1 hors mousses, l’équipement sort du dispositif : aucun contrôle n’est dû.

S’ajoutent des exemptions pour les équipements hermétiquement scellés et étiquetés : en dessous de 10 tonnes équivalent CO₂ pour l’annexe I, de 2 kilogrammes pour l’annexe II section 1, et de 3 kilogrammes en bâtiment résidentiel.

Et une règle qui échappe à tout échéancier périodique : après une réparation, une vérification doit intervenir dans un délai compris entre vingt-quatre heures et un mois. Ce n’est pas une récurrence, c’est un déclenchement événementiel — deux mécanismes distincts à implémenter.

Les données minimales d’un registre exploitable

Pour que le calcul ci-dessus soit possible, chaque équipement doit porter au minimum :

• Le fluide et sa famille réglementaire — annexe I ou annexe II section 1 —, qui détermine l’unité de seuil.
• Le PRP applicable, avec la version du rapport GIEC correspondante.
• La charge, en kilogrammes, et sa conversion en tonnes équivalent CO₂ quand elle s’applique.
• Le caractère hermétiquement scellé et le fait que l’équipement soit étiqueté.
• La présence d’un système de détection des fuites.
• Le type de local — le seuil résidentiel étant différent.
• L’historique complet des contrôles, des manipulations et des réparations.

Un logiciel de gestion d’intervention généraliste n’a aucune de ces notions. C’est pourquoi le suivi des fluides finit presque toujours dans un tableur parallèle.

La fiche d’intervention et la vignette

Chaque manipulation donne lieu à une fiche au format CERFA 15497*04. Attention : la version 03 circule encore dans plusieurs documents, y compris administratifs. La notice de la version 04 se réfère explicitement au règlement de 2024.

Le détenteur doit signer, sauf sous 3 kilogrammes de HCFC ou 5 tonnes équivalent CO₂ de HFC et PFC. Et la fiche vit cinq ans des deux côtés : opérateur et détenteur la conservent chacun, ce qui impose de prévoir la mise à disposition côté client plutôt qu’un simple archivage interne.

S’y ajoute la vignette de marquage d’au moins 4 centimètres apposée après contrôle, rouge si le circuit fuit, bleue s’il est conforme. C’est un état physique lié à un état logique : le système doit savoir laquelle a été posée, et quand.

La déclaration annuelle se prépare toute l’année

Tout opérateur titulaire d’une attestation de capacité déclare avant le 31 janvier, auprès de son organisme agréé, ses stocks de fluides vierges et usagés au 1^er janvier et au 31 décembre, ses achats en poids net, et les quantités chargées, récupérées et retournées au fournisseur. Cette déclaration est due même sans manipulation, avec des quantités à zéro, et un défaut expose à la suspension de l’attestation.

Si les mouvements de fluide sont saisis à l’intervention, la déclaration est une extraction. Sinon, c’est une reconstitution de janvier à partir des bons de commande — et l’écart entre les achats et ce qui est justifiable devient visible au pire moment.

Un point à ne pas figer

Un arrêté du 21 novembre 2025 refond le régime de délivrance des attestations de capacité, avec une application annoncée au 1^er janvier 2027. Les sources professionnelles convergent sur le calendrier mais divergent sur le détail des catégories. Nous ne publions pas de tableau tant que le texte n’a pas été lu directement, et nous vous invitons à faire de même.

Pour la traduction opérationnelle de tout ceci, voir notre page logiciel de suivi des fluides frigorigènes.

Une entreprise de chauffage qui passe de cent à huit cents contrats ne rencontre pas un problème de volume. Elle rencontre un problème de modèle : son outil est construit autour du rendez-vous, alors que son activité est construite autour de l’équipement.

Voici comment nous structurons la donnée dans ce cas de figure, et pourquoi chaque décision compte.

Première décision : l’équipement est l’objet racine

Dans la plupart des logiciels du marché, l’historique technique est rattaché au client. C’est logique commercialement et faux techniquement.

Une chaudière survit à ses occupants. Un logement change de locataire, une copropriété change de syndic, un local commercial change d’exploitant — et si l’historique est attaché au client, il se disloque à chaque changement. L’entreprise perd alors ce qui fait sa valeur : savoir que cette chaudière précise a eu trois interventions curatives en dix-huit mois.

La conséquence pratique : l’équipement porte une identité stable — marque, modèle, puissance, numéro de série, date de mise en service, emplacement — et le client n’est qu’une relation, datée, qui peut changer.

Deuxième décision : la périodicité est calculée, jamais saisie

C’est la source d’erreur la plus fréquente, parce que la réglementation n’applique pas une règle unique :

• Chaudières de 4 à 400 kW : entretien annuel, une fois par année civile.
• Systèmes thermodynamiques de 4 à 70 kW : entretien une année civile sur deux.
• Systèmes de plus de 70 kW : inspection périodique quinquennale.

Un champ « périodicité » saisi à la main dérive dès la première saisie erronée, et personne ne s’en aperçoit avant un contrôle. Dérivée de la puissance et du type d’équipement, la périodicité est juste par construction — et se corrige pour tout le parc si un texte change.

Le corollaire est un moteur d’échéancier qui raisonne en année civile et non en date anniversaire. C’est une différence de conception réelle : « l’entretien est dû une fois par année civile » n’est pas « l’entretien est dû tous les douze mois ».

Troisième décision : l’écran qui compte est celui du retard

La question qui expose l’entreprise n’est pas « quelles visites ai-je demain » mais « combien d’équipements de mon parc n’ont pas été vus cette année, et combien de jours reste-t-il ».

Concrètement, cela donne un tableau de bord avec trois chiffres visibles en permanence : le nombre d’équipements en règle, le nombre en retard, et la charge de visites restante d’ici la fin de l’année civile projetée en jours-technicien. Ce dernier chiffre est celui qui permet de décider en septembre s’il faut renforcer l’équipe ou renoncer à des contrats.

Quatrième décision : l’attestation est un livrable, pas une pièce jointe

Pour une chaudière, l’attestation d’entretien doit être remise sous quinze jours après la visite et conservée deux ans par le client. Pour une installation de plus de 70 kW, le rapport d’inspection est remis sous un mois et conservé dix ans.

Traité comme un document généré, horodaté, envoyé automatiquement et archivé de manière opposable, ce livrable ne coûte rien. Traité comme un PDF que le technicien pense à envoyer, il coûte une relance par visite et un risque à chaque oubli.

Un détail qui distingue un bon outil : la mesure de monoxyde de carbone se lit selon trois seuils — normale en dessous de 10 ppm, anormale entre 10 et 50 ppm, danger immédiat avec arrêt de la chaudière à partir de 50 ppm. Un système qui stocke la valeur sans la qualifier laisse le technicien seul avec la décision ; un système qui la qualifie déclenche le bon protocole.

Cinquième décision : le renouvellement est un processus, pas une date

Un contrat a un cycle de vie : échéance, préavis, revalorisation tarifaire, reconduction ou résiliation, puis facturation récurrente au bon taux de TVA.

Sur ce dernier point, l’année 2025 a changé la donne : les chaudières à combustibles fossiles relèvent du taux de 20 % depuis le 1^er mars 2025, tandis que les pompes à chaleur air/air conformes aux critères de performance bénéficient de 5,5 % depuis le 18 juillet 2026. Une revalorisation de contrat qui ne distingue pas les équipements produit des factures fausses.

Le bénéfice qu’on n’attend pas

Un parc correctement instrumenté ne sert pas qu’à être en règle. Il sait dire quels équipements ont plus de quinze ans, lesquels ont concentré les interventions curatives, et lesquels justifient une proposition de remplacement — désormais avec un argument fiscal.

C’est le tableau de bord commercial que la plupart des outils de gestion d’intervention ne produisent pas, parce qu’ils n’ont jamais considéré l’équipement comme un objet de premier rang.

Le précédent le plus proche dans nos références publiées ne vient pas du chauffage mais des infrastructures : la mission menée pour le Grand Lyon et ENFRASYS, filiale de VINCI Energies, sur le suivi des dysfonctionnements et des interventions de maintenance. La transposition est directe, parce que le point de départ y était celui de la plupart des entreprises de chauffage — un fichier Excel central devenu volumineux et difficile à maintenir, alimenté par des fiches papier et des mails, avec une ressaisie par chaque acteur et aucune traçabilité des modifications.

Ce qui a été le plus difficile n’a pas été technique. Cela s’est joué dans les deux premières des six phases de la mission : les interviews des utilisateurs clés et la cartographie du processus existant. C’est là qu’on découvre que le processus décrit dans les réunions et le processus réellement suivi sur le terrain ne sont pas le même — et que la modélisation doit épouser le second.

L’ensemble — compréhension du besoin, modélisation de l’existant, optimisation de la cible, analyse fonctionnelle, wireframes interactifs et maquettes haute-fidélité — a représenté environ 17 jours. Nos deux autres missions de cadrage publiées ont demandé 15 jours pour ESLC et 16 pour Maïa Rail, ce qui donne l’ordre de grandeur à prévoir avant de pouvoir chiffrer une construction.

Pour le détail des contraintes du métier, voir notre page logiciel de gestion des contrats d’entretien pour chauffagiste.

C’est la question posée en premier et documentée en dernier. La plupart des éditeurs ne publient pas leurs tarifs, et la plupart des agences ne publient pas leurs budgets. Cet article rassemble ce qui est réellement public, et dit ce qui ne l’est pas.

Ce que coûte un abonnement, quand le prix est affiché

Sur le marché français des outils d’intervention et de gestion pour le bâtiment, une minorité d’éditeurs publie une grille complète. Les montants ci-dessous sont ceux affichés publiquement, hors remises et hors options.

• Organilog : 19 €, 35 € ou 59 € par utilisateur et par mois selon l’offre, avec une offre gratuite d’entrée.
• Kizeo Forms : 15 € ou 25 € par utilisateur et par mois en engagement annuel, 22 € ou 37 € en mensuel. Tous les membres de l’équipe doivent être sur le même palier.
• Synchroteam : 24 € par utilisateur et par mois.
• Batappli : 39 € ou 79 € HT par mois et par utilisateur selon l’offre, avec 19 € HT par utilisateur supplémentaire.
• Axonaut : 69,99 € HT par mois pour le premier utilisateur en mensuel, 29,99 € HT par utilisateur supplémentaire.
• ProGBat : 29 €, 42 € ou 138 € HT par mois, sans facturation à l’utilisateur mais avec un plafond de cinq connexions simultanées sur les deux premières offres.
• Codial Bâtiment : 25 à 39 € par utilisateur et par mois pour la version web, les versions PME et Entreprise étant sur devis.

Ne sont pas publics, malgré recherche : les tarifs français de Praxedo, ceux de Sage Batigest et ceux d’Onaya. Nous ne les estimons pas.

Les trois mécaniques qui font dériver la facture

Le prix d’entrée est rarement le problème. Trois structures de coût produisent une dérive que le devis initial ne laisse pas voir.

La double licence. Chez Praxedo, un collaborateur ayant besoin à la fois de l’accès web et de l’application mobile est facturé deux fois. Les utilisateurs signalent également que des fonctions considérées comme essentielles, dont le reporting, sont vendues en option, et que les connecteurs ERP sont facturés séparément.

Le plafond de connexions simultanées. Passer de cinq à un nombre illimité chez ProGBat fait passer de 42 € à 138 € HT par mois, soit un facteur 3,3, sans qu’aucun besoin fonctionnel n’ait changé.

Le spécifique facturé. Sur Easy WMS de Mecalux, des utilisateurs rapportent que de petites modifications « nécessitent des développements spécifiques avec les coûts correspondants ».

Ce que coûte un développement, d’après ce qui est public

Les repères sont rares. Une agence positionnée sur le développement de WMS affiche publiquement un projet à partir de 9 000 € pour une durée de trois mois. Ce montant correspond à un premier périmètre resserré, et non à un système d’information complet.

C’est à peu près tout ce qui est réellement affiché sur ce marché en France. Le reste relève du devis.

Nous ne publions pas de grille tarifaire, et la raison n’est pas commerciale : un prix affiché sans périmètre est un prix faux, et ce marché en est plein. Ce que nous pouvons publier, en revanche, ce sont des durées réelles et un délai de rentabilité.

La phase de cadrage. Sur nos trois missions documentées d’étude AMOA, de conception et de spécifications détaillées, la durée a été de 15 jours pour ESLC dans l’énergie, 16 jours pour Maïa Rail dans le ferroviaire et le BTP, et 17 jours pour le Grand Lyon et ENFRASYS sur les infrastructures. Six phases dans chaque cas : compréhension du besoin, modélisation de l’existant, optimisation du processus cible, analyse fonctionnelle, wireframes interactifs, maquettes haute-fidélité.

Trois secteurs sans rapport entre eux, un ordre de grandeur identique. C’est le premier chiffre à retenir, parce qu’à l’issue de cette phase vous disposez d’un périmètre défini, d’écrans validés et d’un budget de développement fiable — pour un engagement de trois semaines de travail, pas d’un projet.

Le retour sur investissement. Le repère que nous publions est de 13 mois en moyenne pour rentabiliser un développement sur mesure. À comparer à un abonnement, qui ne s’amortit jamais et dont le coût croît avec vos effectifs.

Le diagnostic. Deux heures suffisent à évaluer les opportunités de digitalisation d’une entreprise et à dire si un développement se justifie. Dans une bonne partie des cas, la réponse est non, et elle est donnée là.

Ce que nous ne pouvons pas chiffrer ici. Le budget de construction, parce qu’il dépend intégralement du périmètre arrêté au cadrage : un moteur d’échéancier, une application terrain complète avec back-office et une refonte de système d’information ne se comparent pas. C’est le sens de la phase de 15 à 17 jours — sortir de l’estimation au doigt mouillé, des deux côtés.

Le calcul à trois ans

La bonne comparaison n’est pas « prix de l’abonnement mensuel » contre « prix du développement ». C’est le coût complet sur trois ans, dans les deux hypothèses, avec l’effectif prévu et non l’effectif actuel.

Côté abonnement : nombre d’utilisateurs projeté multiplié par le tarif, plus les options facturées à part, plus les connecteurs, plus les prestations de paramétrage spécifique déjà constatées les années précédentes.

Côté développement : investissement initial, plus maintenance annuelle, plus les évolutions prévisibles. Avec deux différences qui ne se lisent pas dans un tableur — le coût ne croît pas mécaniquement avec le nombre d’utilisateurs, et le résultat vous appartient.

Ce que le prix ne dit pas

Un développement moins cher qu’un abonnement sur trois ans peut rester une mauvaise décision si l’entreprise n’a personne pour porter les arbitrages fonctionnels. Inversement, un abonnement plus économique peut coûter très cher le jour où une échéance réglementaire dépend de la feuille de route d’un éditeur.

Pour la grille complète des sept critères de décision, voir notre article sur le choix entre logiciel du marché et développement sur mesure, et la page gestion d’intervention pour les plombiers.

La question est presque toujours mal posée. Elle se présente comme un choix binaire — progiciel ou développement — alors que la réponse majoritaire est un troisième terme : conserver le progiciel comme système d’exécution et développer autour ce qu’il ne modélise pas.

Voici les cinq questions à passer dans l’ordre. Chacune ferme une branche.

Question 1 — Payez-vous déjà du spécifique à votre éditeur ?

Si oui, la question du sur-mesure est déjà tranchée ; il ne reste qu’à savoir chez qui et à qui appartient le résultat. Les utilisateurs d’Easy WMS, chez Mecalux, décrivent des ajustements mineurs qui « nécessitent des développements spécifiques avec les coûts correspondants ». Financer du développement dans un produit dont on ne détient ni le code ni la feuille de route est un choix, rarement conscient.

Si non, passez à la question 2.

Question 2 — Un processus central vit-il en dehors de l’outil ?

Le test est concret : ouvrez les fichiers partagés de l’exploitation. Si la rentabilité au voyage, le plan de charge des quais ou le suivi des retours à vide se calculent dans un tableur, ce n’est pas un défaut d’usage, c’est que l’outil ne sait pas les représenter.

Si un seul tableur est concerné, il existe souvent une réponse par paramétrage ou par module : cherchez-la d’abord.

Si trois processus ou plus vivent hors de l’outil, le progiciel n’est plus votre système de gestion : il est votre système de saisie. Passez à la question 4.

Question 3 — Le périmètre fonctionnel manquant est-il structurel ?

Certaines absences sont des choix de positionnement de l’éditeur, pas des oublis. Akanea TMS a beau décliner sa gamme par taille d’entreprise, le parc véhicules reste hors de son champ. Shiptify indique lui-même ne pas convenir aux structures réalisant moins d’une expédition par jour.

Une absence structurelle ne sera pas comblée par une montée de version. Si votre besoin est du mauvais côté de la frontière commerciale de l’éditeur, attendre est une stratégie perdante.

Question 4 — Votre coût suit-il votre volume ou votre valeur ?

Les structures tarifaires du secteur méritent d’être regardées de près. Chez Dashdoc, la facture se compose d’un fixe par établissement, d’une variable adossée au nombre d’utilisateurs et au volume transporté, et d’un supplément par module. AntsRoute facture par véhicule : 34 €, 54 € ou 74 € par véhicule et par mois, avec l’API disponible seulement à partir de l’offre à 54 € et les intégrations personnalisées réservées à l’offre Enterprise.

Faites le calcul à trois ans avec l’effectif et la flotte prévus, pas actuels. Si la courbe de coût suit le volume alors que la valeur apportée par l’outil est constante, l’arbitrage bascule mécaniquement à un moment ; autant savoir lequel.

Question 5 — Une échéance réglementaire dépend-elle de votre éditeur ?

Deux sujets à vérifier aujourd’hui.

La facturation électronique : l’obligation de réception s’applique à toutes les entreprises assujetties depuis le 1^er septembre 2026, celle d’émission aux PME et TPE au 1^er septembre 2027. Le portail public n’offrant plus de service gratuit, le passage par une plateforme agréée est obligatoire.

L’eFTI : à compter du 9 juillet 2027, les autorités des États membres devront accepter les informations transmises via des plateformes certifiées. Attention à ne pas lire cette date comme une obligation pesant sur les transporteurs — l’usage reste volontaire. En revanche, disposer d’un module e-CMR ne vaut pas conformité eFTI.

Demandez à votre éditeur sa feuille de route datée, ses spécifications d’intégrité des données, son mécanisme d’authentification et ses procédures d’export en contrôle. Une réponse vague est une réponse.

Où l’arbre mène le plus souvent

Rarement au remplacement complet. Le montage hybride — progiciel conservé pour l’exécution, développement pour le pilotage et les flux non standard — gagne dans la majorité des cas pour trois raisons : il évite une migration de données, il n’immobilise pas les équipes, et il rend le remplacement futur du progiciel plus simple, puisque l’intelligence métier ne vit plus uniquement dans le paramétrage d’un produit tiers.

Un repère utile pour calibrer ses attentes : chez Manitou, sur 45 demandes de développement spécifique passées au crible, 60 % ont été abandonnées, 26,4 % ramenées au standard et 23,6 % conservées. Près d’un besoin sur quatre résiste, dans une démarche pourtant conçue pour éliminer le spécifique.

Pour le détail par métier, voir notre page WMS et TMS sur mesure.

La question « faut-il développer ou acheter » se tranche mal en discutant de fonctionnalités. Elle se tranche bien en passant sept critères, dont plusieurs ont un seuil chiffrable.

Voici la grille que nous utilisons en atelier de cadrage. Elle est faite pour donner tort au développement sur mesure la plupart du temps — c’est ce qui la rend utile.

Comment lire cette grille

Un seul critère à droite ne justifie pas un développement. Trois, dont au moins un parmi les critères 1, 3 et 7, justifient une étude sérieuse.

La raison est économique : les trois critères en question sont ceux qui produisent une dépense mesurable et croissante. Les autres produisent de l’inconfort, ce qui n’est pas la même chose.

Critère 1 : le seuil d’utilisateurs

Les grilles publiques du marché donnent l’ordre de grandeur. Comptez 29,99 € HT par mois et par utilisateur supplémentaire chez Axonaut, 19 € HT chez Batappli. ProGBat annonce des utilisateurs illimités mais plafonne à cinq connexions simultanées ses offres à 29 € et 42 € HT par mois, l’illimité passant par une offre à 138 € HT. Chez Praxedo, un collaborateur ayant besoin de l’accès web et de l’application mobile est facturé deux fois.

Le calcul à faire n’est pas le coût d’aujourd’hui mais celui à trois ans, avec l’effectif prévu. C’est souvent à ce moment que la discussion change de nature.

Critère 3 : le spécifique déjà facturé

C’est le critère le plus discriminant, et le plus facile à vérifier : ouvrez les factures de votre éditeur des deux dernières années et cherchez les lignes de prestation.

Chez Mecalux, sur Easy WMS, le constat des utilisateurs est sans détour : des ajustements de faible ampleur « nécessitent des développements spécifiques avec les coûts correspondants ». À partir de là, la question n’est plus « développer ou acheter » mais « développer chez qui, et qui détient le résultat ».

Critère 7 : la dépendance au calendrier de l’éditeur

Deux échéances rendent ce critère actuel. La facturation électronique, dont l’obligation de réception s’applique à toutes les entreprises assujetties depuis le 1^er septembre 2026 et l’obligation d’émission aux PME et TPE au 1^er septembre 2027. Et, côté transport, l’échéance eFTI du 9 juillet 2027 — qui oblige les autorités et non les transporteurs, mais qui suppose que l’outil sache produire des données conformes.

La bonne question à poser à un éditeur n’est pas « serez-vous prêts » mais « montrez-moi votre feuille de route datée et vos spécifications ». L’absence de réponse est une réponse.

Le chiffre qui remet les choses à l’échelle

Hardis, éditeur du WMS Reflex, documente la démarche de Manitou : sur 45 demandes de développement spécifique analysées par un « tribunal des spécifiques », 60 % ont été abandonnées, 26,4 % ramenées au standard, et 23,6 % conservées.

Autrement dit, dans une démarche conçue pour éliminer le spécifique, près d’un besoin sur quatre survit. C’est l’ordre de grandeur raisonnable : le développement sur mesure ne remplace pas le standard, il traite la fraction que le standard ne prend pas.

Ce que la grille ne dit pas

Elle ne dit rien du coût de la maintenance, qui se budgète dès le départ et non au moment où le besoin apparaît. Elle ne dit rien non plus de la capacité de l’entreprise à porter un projet : un développement réussi suppose quelqu’un en interne capable de trancher les arbitrages fonctionnels, ce qui n’est pas toujours disponible.

Sur ces deux points, une entreprise honnête avec elle-même s’épargne parfois un projet.

Pour aller plus loin sur les situations concrètes où le standard atteint sa limite, voir notre page logiciel sur mesure pour le BTP.