Construire une base commune
Commencez par un même document de contexte pour chaque éditeur : sites concernés, flux, volumes observés, calendrier envisagé, systèmes connectés et contraintes d’exploitation. Ajoutez les exceptions importantes, comme les retours, les lots, les supports logistiques ou les zones de quarantaine si elles existent chez vous. Une démonstration ou une offre basée sur un autre scénario ne permet pas une comparaison directe.
Définissez un périmètre versionné avant de demander les prix. Distinguez les fonctions obligatoires, les préférences et les évolutions possibles. Pour chaque flux, nommez l’événement de départ, le résultat attendu, les acteurs et les informations nécessaires. Évitez les formulations générales telles que « gestion complète des encours » sans décrire les opérations réelles qui doivent être couvertes.
Ajoutez une colonne d’hypothèses et une colonne de preuve. Une réponse « standard » devrait être reliée à une documentation ou démonstration. Une réponse « spécifique » doit préciser la configuration ou le développement. Une réponse « hors périmètre » doit être chiffrée séparément ou marquée comme risque. Cette convention rend les inconnues visibles sans les transformer en coût supposé.
Normaliser les lignes tarifaires
Recopiez les lignes dans une matrice : abonnement, utilisateurs, sites, intégration, migration, connecteurs, environnement de test, formation, matériel, support, maintenance et assistance au démarrage. Les intitulés peuvent différer; ne les fusionnez que si leur contenu correspond. Mentionnez la période couverte, l’unité, les quantités et le caractère fixe ou estimatif. Ne comparez pas un montant ponctuel à un montant annuel comme s’ils étaient équivalents.
Calculez un total sur une période explicitée avec les mêmes hypothèses pour chaque offre. Séparez le récurrent des coûts initiaux et des coûts internes. Les hausses futures, l’indexation ou la modification des effectifs doivent rester des scénarios, à moins qu’une clause ne fixe déjà leur calcul. Incluez les taxes de manière cohérente et signalez toute ligne dont le traitement fiscal reste à confirmer.
Les frais de projet sont particulièrement sensibles au périmètre. Demandez combien d’ateliers, d’interfaces, de cycles d’essai et de jours de formation sont inclus. Vérifiez si un changement après validation entraîne un avenant. Faites distinguer correction d’un écart, demande d’évolution et défaut; les conséquences peuvent différer. Le contrat doit décrire les critères de réception et les documents remis.
Comparer les scénarios de fabrication
Utilisez un même ordre de fabrication fictif, une opération terminée, un arrêt déclaré, une non-conformité et une correction autorisée. Demandez à chaque candidat d’indiquer les données capturées, l’acteur, l’horodatage, l’état renvoyé à l’ERP et les actions manuelles. Faites distinguer démonstration, paramétrage inclus et développement. La même séquence révèle mieux les écarts qu’une comparaison de brochures fonctionnelles.
Comparer la capacité opérationnelle
Préparez un petit ensemble de scénarios identiques à faire exécuter : une réception partielle, un poste de travail indisponible, une commande urgente, une correction autorisée et un inventaire qui révèle un écart. Ne notez pas seulement si l’écran permet une action; observez les informations visibles, la trace conservée, les droits requis et le traitement d’une erreur.
Évaluez la compatibilité avec vos appareils, étiquettes, réseau et systèmes existants. Demandez la version et l’environnement utilisés, les limites connues et les prérequis. Quand une fonction repose sur un connecteur, demandez qui l’exploite, surveille les erreurs, maintient la compatibilité et répond lors d’un incident. Un logo de partenaire sur une page ne décrit pas la responsabilité contractuelle.
Comparez aussi les modalités de transfert de données et de sortie. Demandez les formats disponibles, le coût, le délai, l’assistance incluse et les restrictions éventuelles. La facilité d’export doit être démontrée sur un échantillon représentatif. Faites examiner la réponse par votre équipe informatique et juridique avant de traiter le sujet comme acquis.
Rendre la décision vérifiable
Attribuez un poids aux critères seulement après que les responsables ont convenu de leur importance. Conservez les réponses brutes et les notes individuelles; ne remplacez pas un désaccord par une moyenne qui le masque. Indiquez les conditions qui changeraient la décision, par exemple une interface indispensable non incluse ou une limite de continuité incompatible avec l’activité.
Rédigez une synthèse d’une page : périmètre, coût par période, exclusions, preuves, risques, décisions à obtenir et prochaine étape. Les personnes qui valident doivent pouvoir remonter de chaque conclusion à un devis, une clause ou un essai. Cela limite les biais de présentation et aide à réexaminer l’offre si le périmètre évolue.
Ce carnet ne classe aucun éditeur et ne fournit pas de prix moyens. Il vous aide à comparer deux réponses produites avec la même base. Les montants fictifs du calculateur illustrent des opérations arithmétiques; seuls vos devis datés et vos hypothèses sont adaptés à votre projet.
Sources et limites
Les sources éclairent des questions de cadrage; elles ne valident pas votre architecture ni un fournisseur. Les standards et documentations cités restent la propriété de leurs éditeurs et ne remplacent pas l’analyse de votre site.