Logiciel standard ou sur mesure : comparer sur un vrai processus

Commencer par les situations à résoudre

Décrivez le début et la fin du travail : qui reçoit la demande, quelles informations manquent, qui décide et quel document clôt le dossier. Ajoutez un cas habituel, une correction et une exception. Cette description fournit une base commune aux éditeurs et au développeur ; chacun devra montrer comment il traite le même besoin.

Séparez ensuite les exigences indispensables des habitudes modifiables. Une validation obligatoire avant envoi peut être essentielle. L'ordre actuel des colonnes d'un tableau ne l'est pas forcément. Si chaque particularité est déclarée impérative, la comparaison favorisera artificiellement une reconstruction complète.

Distinguer réglage, extension et développement

Un produit existant peut offrir les champs, permissions et modèles nécessaires par simple configuration. Une extension ajoute une fonction à ce produit. Un outil spécifique peut aussi ne couvrir qu'une étape et échanger avec le logiciel principal. Le choix n'est donc pas limité à acheter un abonnement ou tout reconstruire.

Le Government Digital Service britannique invite à partir des besoins utilisateurs, à distinguer configuration et personnalisation, et à considérer une combinaison de composants. Il souligne aussi que des adaptations profondes peuvent compliquer les mises à jour. Ce cadre aide à poser les questions ; il ne donne pas une réponse automatique pour une PME suisse.

Faire une démonstration sur un cas commun

Exemple hypothétique : une entreprise reçoit une demande d'intervention, affecte un technicien, prépare un rapport et transmet les éléments validés à la facturation. Préparez un dossier fictif avec une adresse corrigée après planification et une pièce indisponible. Demandez à chaque prestataire de dérouler ce scénario, y compris le retour au bureau.

Dans le compte rendu, attribuez un état à chaque étape : disponible et montré, configurable et montré, développement à chiffrer, ou absent. Une promesse inscrite dans une feuille de route reste distincte d'une fonction disponible. Faites préciser les éditions, licences et droits utilisés pendant la démonstration.

• Créer et retrouver le dossier sans ressaisir les mêmes coordonnées.
• Réaffecter l'intervention en conservant l'historique.
• Bloquer l'envoi d'un rapport incomplet avec une explication utile.
• Exporter le dossier, ses fichiers et les identifiants nécessaires à sa reprise.

Comparer le coût d'exploitation et la possibilité de sortie

Demandez un chiffrage portant sur le même périmètre : installation, reprise des données, configuration, formation, intégrations, licences et maintenance. Indiquez les utilisateurs et usages réellement envisagés. Ajoutez le temps interne nécessaire pour préparer les données et administrer l'outil. Une solution qui couvre mal une étape peut déplacer la dépense vers de la ressaisie.

Pour chaque option, demandez comment récupérer les données et poursuivre le travail avec un autre prestataire. Un export doit être accompagné de ses relations, de ses pièces jointes et d'une description lisible. Pour le sur mesure, précisez la remise du code, de la documentation et des accès. Aucun de ces éléments ne découle automatiquement du mot « sur mesure ».

Écrire une décision compréhensible et révisable

Une fiche de décision peut tenir sur une page : problème traité, options examinées, exigences bloquantes, preuves de démonstration, coût retenu et points restant incertains. Choisissez la solution qui répond aux besoins prioritaires avec des limites acceptables. Une note moyenne ne doit pas masquer un blocage, par exemple l'impossibilité d'exporter une donnée essentielle.

Le sur mesure mérite d'être étudié lorsque des règles centrales restent impossibles à représenter ou que les contournements compromettent le travail. Un produit existant convient si son fonctionnement couvre le besoin et si son administration reste soutenable. Conserver le système actuel est aussi une décision possible lorsque les bénéfices attendus ne justifient pas la transition.

Définir un premier périmètre avant de s'engager

Le premier périmètre doit produire un résultat exploitable : une catégorie de demandes, un type de document ou une équipe pilote. Définissez qui valide ce résultat et quelles fonctions restent dans l'outil actuel. Évitez de construire une plateforme complète avant d'avoir observé l'utilisation de ce premier parcours.

Notez enfin les événements qui imposeraient de revoir la décision : nouvelle contrainte d'intégration, changement de volume, arrêt d'un produit ou évolution majeure du processus. Le choix initial reste valable dans un contexte donné. Cette trace permet de faire évoluer le système sans prétendre qu'une option sera toujours la meilleure.