La vraie question n'est pas « lequel », mais « pour quoi »
La plupart des projets qui échouent ont commencé par le choix d'un outil, pas par la description d'un problème. On achète un progiciel réputé, on découvre six mois plus tard qu'il ne gère pas le cas particulier qui représente 40 % de l'activité, et l'on retourne au tableur en parallèle.
Avant de comparer des solutions, écrivez ce qui vous coûte du temps aujourd'hui. Une page suffit. Cette page est votre cahier des charges, et elle vaut plus que toutes les démonstrations.
Progiciel du marché : quand c'est le bon choix
Un progiciel convient quand votre métier ressemble à celui de milliers d'autres entreprises et que vous acceptez de vous adapter à sa logique. Vous gagnez la mise en route rapide, un outil éprouvé et une communauté.
Vous perdez la souplesse. Ce qu'il ne fait pas, il ne le fera pas pour vous, et les contournements finissent en tableurs parallèles — c'est-à-dire exactement ce que vous vouliez supprimer.
Comptez aussi la licence par utilisateur. Elle paraît modeste au départ, puis grandit avec votre effectif, chaque année, sans fin.
Sur mesure : quand c'est justifié
Le sur mesure se justifie quand votre façon de travailler est un avantage concurrentiel, quand aucun outil du marché ne couvre votre cas, ou quand la somme des licences dépasse à terme le coût d'un développement.
L'investissement de départ est plus élevé. Il n'y a ensuite ni licence par poste, ni dépendance au calendrier d'un éditeur, et l'outil évolue quand vous en avez besoin.
La contrepartie est réelle : vous dépendez de la disponibilité de celui qui l'a écrit. D'où l'importance du code source et de la documentation, abordés plus bas.
Les trois facteurs qui tranchent
- La singularité de vos circuits — si votre façon de gérer les commandes, les tournées ou les acomptes est le cœur de votre valeur, aucun progiciel ne la reproduira.
- Le coût sur cinq ans, pas à l'achat — additionnez licences, paramétrage, formation, contournements et migration éventuelle. La comparaison change souvent de camp.
- Votre capacité à changer vos habitudes — un progiciel impose ses processus. Si vos équipes ne les adopteront pas, l'outil restera vide, quelle que soit sa qualité.
Cinq erreurs fréquentes
Choisir sur la démonstration
Une démonstration montre le chemin heureux. Demandez à voir vos propres cas difficiles : le client qui paie en trois fois, l'avoir partiel, la commande annulée après livraison.
Oublier la reprise de l'historique
Des années de données dorment dans votre ancien système ou dans des tableurs. Les récupérer représente parfois autant de travail que le développement lui-même. Ce poste doit figurer au devis dès le départ.
Négliger le mode dégradé
Le réseau tombe, l'électricité saute. Un outil qui exige une connexion permanente immobilise votre caisse et vos équipes terrain. Demandez ce qui se passe hors connexion — et faites-le démontrer.
Sous-estimer la formation
Un outil que personne ne sait utiliser reste un coût. Prévoyez la formation, sur vos vraies données et non sur un jeu d'exemple, et un support écrit qui reste après le départ du formateur.
Ne pas exiger le code source
Pour un développement sur mesure, faites écrire au contrat que le code source et les données vous appartiennent, et qu'ils vous sont restitués dans un format exploitable. Sans cette clause, un prestataire injoignable vous laisse sans recours.
Commencer petit, mais commencer
Les projets qui aboutissent couvrent d'abord le besoin qui fait le plus mal — la facturation, la caisse, le stock — puis s'étendent. Ceux qui veulent tout couvrir dès le premier jour s'enlisent en cadrage et ne livrent jamais.
Un premier module utilisé vaut mieux qu'un système complet en discussion depuis un an.