Logiciel standard ou développement sur mesure : comment choisir ?

Qu’est-ce qu’un logiciel standard ?

Un logiciel standard est conçu pour répondre à des besoins partagés par plusieurs entreprises ou organisations.

Il peut s’agir par exemple d’un CRM, d’un ERP, d’un outil de gestion, d’une solution collaborative ou d’une application spécialisée dans une fonction précise.

Un fonctionnement déjà défini

Le logiciel propose généralement :

• une architecture existante ;
• des fonctionnalités déjà développées ;
• une interface prête à être utilisée ;
• des paramètres de configuration ;
• des mises à jour gérées par l’éditeur ;
• une documentation ou un support selon l’offre choisie.

L’entreprise adapte alors une partie de son organisation au fonctionnement prévu par la solution.

Un logiciel standard peut être largement configurable

« Standard » ne signifie pas nécessairement rigide.

Certaines solutions permettent de personnaliser des champs, des workflows, des droits, des tableaux de bord ou d’ajouter des extensions.

Il est donc important d’étudier les possibilités réelles du logiciel avant de conclure qu’un développement spécifique est nécessaire.

Qu’est-ce qu’un logiciel sur mesure ?

Un logiciel sur mesure est conçu à partir des besoins spécifiques d’une entreprise ou d’une organisation.

Son fonctionnement peut être défini autour :

• des utilisateurs ;
• des processus métier ;
• des règles de gestion ;
• des données ;
• des logiciels déjà utilisés ;
• des intégrations nécessaires.

L’objectif n’est pas de reproduire toutes les fonctions d’un logiciel standard, mais de construire les fonctions réellement nécessaires au projet.

Le développement spécifique peut prendre plusieurs formes

Il peut s’agir :

• d’un outil métier ;
• d’une application Web ;
• d’une interface complémentaire à un ERP ou un CRM ;
• d’un connecteur ;
• d’une automatisation ;
• d’un module spécifique autour d’une solution existante.

Notre article Logiciel métier sur mesure : quand devient-il pertinent ? détaille plus précisément les situations pouvant justifier cette approche.

Commencer par analyser le besoin métier

Choisir un logiciel avant d’avoir défini précisément le problème à résoudre conduit souvent à comparer des listes de fonctionnalités sans savoir lesquelles sont réellement importantes.

Décrire le fonctionnement actuel

Commencez par identifier :

• les différentes étapes du processus ;
• les personnes qui interviennent ;
• les logiciels actuellement utilisés ;
• les données manipulées ;
• les tâches répétitives ;
• les doubles saisies ;
• les principales difficultés rencontrées.

Définir le résultat attendu

Le besoin peut par exemple être de :

• centraliser des informations ;
• réduire certaines saisies ;
• mieux suivre des dossiers ;
• automatiser des étapes ;
• faire communiquer plusieurs logiciels ;
• proposer une interface différente selon les utilisateurs ;
• disposer d’indicateurs spécifiques.

Cette analyse permet ensuite de rechercher une solution plutôt que d’adapter le besoin au premier outil étudié.

Comparer les fonctionnalités réellement nécessaires

Un logiciel standard peut proposer beaucoup plus de fonctions qu’un développement spécifique.

Ce n’est pas nécessairement un avantage si une grande partie de ces fonctions n’est jamais utilisée.

Distinguer trois niveaux de besoin

Pour chaque fonctionnalité envisagée, il peut être utile de la classer comme :

• indispensable : le processus ne peut pas fonctionner correctement sans elle ;
• utile : elle améliore le fonctionnement mais n’est pas indispensable au lancement ;
• optionnelle : elle peut être envisagée ultérieurement.

Comparer le fonctionnement, pas seulement la présence d’une fonction

Deux logiciels peuvent annoncer la même fonctionnalité tout en la mettant en œuvre de manière très différente.

Par exemple, la présence d’un système de validation ne signifie pas nécessairement que celui-ci peut reproduire les règles précises utilisées par votre organisation.

Il est donc préférable de tester les scénarios métier importants plutôt que de comparer uniquement des tableaux de fonctionnalités.

Le logiciel doit-il s’adapter au processus ou l’inverse ?

Un logiciel standard apporte généralement son propre modèle de fonctionnement.

Cette contrainte peut être positive lorsqu’elle permet de simplifier un processus inutilement complexe.

Ne pas reproduire toutes les habitudes existantes

Le fait qu’une opération ait toujours été réalisée d’une certaine manière ne signifie pas qu’elle doit être reproduite à l’identique dans un nouvel outil.

Avant de demander un développement spécifique, il est utile d’identifier les étapes qui peuvent être simplifiées ou supprimées.

Mais certaines règles sont réellement spécifiques

Une entreprise peut avoir des contraintes métier que les logiciels standards ne couvrent pas correctement :

• plusieurs niveaux particuliers de validation ;
• des calculs spécifiques ;
• des statuts propres à son activité ;
• des workflows différents selon le contexte ;
• des relations particulières entre plusieurs données.

Lorsque les contournements deviennent plus importants que le fonctionnement normal du logiciel, un développement spécifique peut être pertinent.

Cette logique est également au cœur de notre article consacré à l’automatisation des processus métier.

Vérifier les intégrations avec les outils existants

Un logiciel ne fonctionne généralement pas seul dans l’environnement d’une entreprise.

Il peut devoir échanger avec :

• un ERP ;
• un CRM ;
• un site Web ;
• une plateforme de formation ;
• un outil comptable ;
• un logiciel métier ;
• d’autres applications internes ou externes.

Un logiciel standard peut proposer des connecteurs existants

C’est l’un de ses avantages possibles : certaines intégrations peuvent déjà être proposées ou disponibles via son écosystème.

Mais il faut vérifier leur périmètre réel

Le fait qu’un logiciel annonce une connexion avec une autre solution ne garantit pas que les données ou actions dont votre processus a besoin soient disponibles.

Il faut notamment vérifier :

• les données échangées ;
• le sens des échanges ;
• leur fréquence ;
• les éventuelles limitations ;
• les conditions commerciales ;
• la gestion des erreurs.

Le sur-mesure peut compléter les outils existants

Lorsque les logiciels disposent d’API adaptées, un développement spécifique peut servir d’interface ou de connecteur entre plusieurs systèmes.

Notre guide sur l’intégration API explique comment cadrer ces échanges.

Comparer la gestion des utilisateurs et des droits

Les besoins peuvent fortement varier selon les profils qui utiliseront le logiciel.

Un collaborateur, un responsable, un administrateur, un client ou un partenaire n’ont pas nécessairement accès aux mêmes informations.

Avec une solution standard

Les rôles et permissions sont généralement définis à l’intérieur du modèle proposé par l’éditeur.

Ils peuvent être suffisamment flexibles ou au contraire devenir contraignants selon le processus.

Avec un développement sur mesure

Les règles peuvent être définies autour des besoins du projet, mais elles doivent alors être conçues, développées, testées et maintenues.

Il faut notamment prévoir :

• la création des comptes ;
• les rôles ;
• les habilitations ;
• les modifications de droits ;
• la désactivation des comptes ;
• les éventuelles règles d’administration.

La flexibilité supplémentaire implique donc également davantage de responsabilités dans la conception de l’outil.

Anticiper les évolutions futures

Le besoin actuel ne doit pas être le seul critère de choix.

Il faut également envisager les évolutions raisonnablement prévisibles.

Un logiciel standard évolue selon la stratégie de son éditeur

L’entreprise bénéficie des nouvelles versions proposées, mais ne maîtrise pas nécessairement les priorités de développement.

Une fonction peut apparaître, évoluer ou disparaître selon les décisions de l’éditeur.

Un logiciel sur mesure évolue selon vos besoins

Cette liberté peut être intéressante lorsque les processus changent régulièrement.

Elle signifie cependant que les évolutions doivent être conçues, développées et maintenues.

Éviter d’anticiper toutes les possibilités

Un développement sur mesure ne doit pas essayer de prévoir toutes les évolutions imaginables dès sa première version.

Il est souvent plus pertinent de construire une architecture suffisamment évolutive puis d’ajouter les nouvelles fonctions lorsqu’un besoin concret apparaît.

Comparer les coûts au-delà du prix initial

Comparer uniquement le prix d’achat ou de développement donne une vision incomplète.

Les deux approches peuvent générer différents coûts dans le temps.

Pour un logiciel standard

Selon le modèle choisi, il faut notamment examiner :

• les licences ou abonnements ;
• le nombre d’utilisateurs ;
• les modules complémentaires ;
• les options nécessaires ;
• les intégrations ;
• la configuration ;
• la migration des données ;
• la formation ou l’accompagnement.

Pour un développement spécifique

Le projet peut notamment comprendre :

• le cadrage ;
• la conception ;
• le développement ;
• les tests ;
• l’hébergement lorsque cela est nécessaire ;
• la maintenance ;
• les futures évolutions ;
• les services tiers éventuellement utilisés.

Prendre aussi en compte les coûts liés aux contournements

Un logiciel moins coûteux peut devenir moins intéressant si les équipes doivent continuellement effectuer des doubles saisies, exporter des fichiers ou appliquer des procédures manuelles pour compenser ses limites.

Inversement, développer une solution spécifique pour un besoin simple peut ajouter une complexité inutile.

Maintenance, support et dépendances

Le choix influence également la manière dont la solution sera maintenue.

Avec un logiciel standard

L’éditeur prend généralement en charge une partie importante de la maintenance de son produit.

En contrepartie, l’entreprise dépend de :

• la disponibilité du service ;
• la politique tarifaire ;
• la feuille de route du produit ;
• les formats d’export proposés ;
• les conditions d’accès aux API ;
• la continuité du service.

Avec un logiciel sur mesure

Le fonctionnement est davantage maîtrisé mais la maintenance doit être organisée.

Il faut notamment prévoir :

• les mises à jour techniques ;
• les correctifs ;
• le suivi des dépendances ;
• les sauvegardes ;
• la sécurité ;
• les évolutions des API connectées ;
• la documentation.

Ce sujet doit être étudié avant la mise en production plutôt qu’après le premier incident.

Peut-on combiner logiciel standard et développement spécifique ?

Oui, et cette approche peut être particulièrement pertinente.

Le choix ne doit pas nécessairement être entièrement standard ou entièrement spécifique.

Conserver un logiciel pour ce qu’il fait bien

Un CRM peut continuer à gérer les données commerciales tandis qu’un outil spécifique prend en charge un processus particulier.

Un ERP peut rester responsable des données de gestion tandis qu’une application Web propose une interface adaptée à certains utilisateurs.

Ajouter une couche métier

Une application complémentaire peut récupérer certaines informations, appliquer des règles puis renvoyer les résultats vers les outils existants.

Cette approche évite de reconstruire des fonctions déjà correctement assurées ailleurs.

Créer des automatisations ciblées

Parfois, aucun nouveau logiciel complet n’est nécessaire.

Une automatisation ou un connecteur peut suffire à résoudre le problème.

Pour comprendre cette logique, consultez également notre article Application Web sur mesure : dans quels cas la choisir ?.

Une grille simple pour orienter la décision

Avant de choisir une approche, plusieurs questions permettent de structurer la réflexion.

Le besoin existe-t-il déjà dans une solution standard ?

Si oui, vérifiez si elle répond réellement aux usages importants avant d’envisager un développement.

Combien de contournements seront nécessaires ?

Quelques adaptations peuvent être acceptables. Une multiplication des procédures parallèles peut en revanche signaler que le modèle est mal adapté.

Les règles métier sont-elles réellement spécifiques ?

Si le fonctionnement est commun à de nombreuses entreprises, une solution standard peut probablement le couvrir.

Quels logiciels doivent être connectés ?

Les intégrations disponibles peuvent fortement influencer le choix.

Qui doit utiliser l’outil ?

Nombre d’utilisateurs, profils, accès externes et niveaux de droits doivent être définis.

Quelle maîtrise souhaitez-vous conserver ?

Évolutions, données, hébergement, maintenance et dépendance à un éditeur doivent être examinés selon le contexte.

Le besoin est-il suffisamment stable ?

Développer un outil autour d’un processus encore très incertain peut entraîner de nombreuses modifications.

Peut-on commencer plus simplement ?

Une automatisation, un connecteur ou une évolution de l’existant peut parfois apporter une réponse suffisante sans créer immédiatement un nouveau logiciel.

Pour approfondir votre choix

Plusieurs ressources AMEGANET permettent de poursuivre cette réflexion :

• Logiciel métier sur mesure : identifiez les situations dans lesquelles un outil spécifique devient pertinent.
• Application Web sur mesure : découvrez quand une interface métier accessible depuis le Web peut être adaptée.
• Remplacer Excel par un outil métier : repérez les limites d’un fonctionnement devenu dépendant des tableurs.
• Automatisation des processus métier : analysez les processus avant d’automatiser.
• Intégration API : étudiez les échanges nécessaires entre plusieurs logiciels.
• Développement sur mesure & API : découvrez l’accompagnement AMEGANET pour les outils métier, applications, API et connecteurs.

Choisir la solution la plus simple qui répond réellement au besoin

Un logiciel standard est pertinent lorsqu’il couvre correctement les besoins sans imposer de contournements importants. Il permet alors de bénéficier d’un produit existant sans reconstruire des fonctionnalités déjà disponibles.

Le développement sur mesure devient intéressant lorsque les processus, règles ou intégrations sont suffisamment spécifiques pour que les solutions existantes atteignent leurs limites.

Entre les deux, une troisième voie existe souvent : conserver les logiciels standards qui fonctionnent et développer uniquement les fonctions, interfaces ou connecteurs manquants.

La décision doit donc partir de l’analyse du besoin, de l’environnement existant et des évolutions attendues plutôt que d’une préférence systématique pour le standard ou le sur-mesure.