Vous avez décidé d’équiper votre entreprise d’un outil interne : suivi des commandes, gestion des interventions, pilotage de la production. Le budget est réservé, le prestataire est presque choisi, et tout le monde attend la première version avec impatience.
C’est exactement le moment où se jouent les trois décisions qui détermineront si cet outil sera encore utilisé dans cinq ans — ou abandonné dans six mois. Aucune des trois n’est technique, et toutes se prennent avant que le travail commence.
Un outil abandonné est rarement un outil mal fabriqué
L’idée reçue veut qu’un projet informatique rate pour des raisons informatiques. Dans les faits, les outils internes qui finissent au placard fonctionnent presque toujours : ils font ce qui a été demandé, sans erreur, et personne ne s’en sert.
Le point commun de ces projets n’est pas la qualité de fabrication. C’est qu’on a commencé à décrire la solution avant d’avoir fini de décrire le problème. Une fois cette bascule faite, tout le reste est contaminé : le devis chiffre la mauvaise chose, les réunions arbitrent des détails d’écran au lieu d’arbitrer des priorités, et la mise en service révèle que l’outil résout un problème que personne n’avait vraiment.
Un chiffre souvent cité, issu d’un relevé présenté par le Standish Group au début des années 2000, illustre l’ampleur du gâchis : sur les logiciels observés, environ 45 % des fonctionnalités livrées n’étaient jamais utilisées, et 64 % l’étaient rarement ou jamais. La méthode de l’étude a été discutée depuis, et le chiffre exact importe peu. L’ordre de grandeur, lui, correspond à ce que l’on observe sur le terrain : la majorité de ce qui est payé dans un projet ne sert à personne.
J’ai conçu pour un groupement professionnel national une plateforme qui gère ses adhérents, ses cotisations, ses communications et un espace documentaire réservé aux membres. Elle est restée en service une dizaine d’années, conception et hébergement compris. Ce n’est pas une prouesse de fabrication : c’est le résultat d’un périmètre initial étroit — la gestion des adhérents, rien d’autre — auquel on a ajouté une brique par an, en fonction de ce que les membres utilisaient réellement. Le détail de la mission est sur la fiche extranet et gestion d’un groupement national.
Trois erreurs, trois moments précis
Erreur 1 : partir de l’outil plutôt que du problème
Elle se reconnaît à une phrase : « il nous faudrait un CRM ». Ou un ERP, ou un portail, ou une application mobile. Le nom de la catégorie arrive avant la description de ce qui coince, et il emporte avec lui des dizaines de décisions implicites que personne n’a prises consciemment.
Le correctif est simple, et inconfortable : interdisez-vous de nommer l’outil pendant les deux premières réunions. Décrivez uniquement ce qui se passe aujourd’hui — qui fait quoi, dans quel ordre, avec quelles informations, où ça bloque, combien de temps ça prend, ce que ça coûte quand ça rate. Si vous n’arrivez pas à chiffrer grossièrement le coût annuel du problème, vous n’êtes pas prêt à acheter la solution.
Cette étape sert aussi à trancher une question que beaucoup sautent : faut-il vraiment développer quelque chose ? Pour une bonne partie des besoins, un logiciel existant fera l’affaire pour moins cher, et le sujet mérite d’être réglé en amont — j’ai détaillé la grille de décision dans outil sur mesure ou SaaS : comment savoir.
Erreur 2 : viser le périmètre complet dès la première version
C’est l’erreur la plus coûteuse, et la plus naturelle. Puisqu’on lance un projet, autant le lancer en grand : tant qu’à équiper le service commercial, équipons aussi la production, l’après-vente et la direction. Chaque ajout paraît marginal au moment où on le décide.
Le problème n’est pas le montant. C’est que le périmètre large repousse la date à laquelle quelqu’un utilise l’outil pour de vrai — et donc la date à laquelle vous apprenez si vous avez visé juste. Un projet qui met dix-huit mois avant sa première utilisation réelle a dix-huit mois de décisions non vérifiées empilées les unes sur les autres.
La règle inverse est plus sûre : choisissez le processus le plus douloureux, couvrez-le entièrement, mettez-le en service, et n’ajoutez la suite qu’ensuite. Vous découvrirez presque toujours que deux ou trois des fonctions prévues pour plus tard n’ont plus lieu d’être, et qu’une fonction à laquelle personne n’avait pensé est devenue prioritaire.
Erreur 3 : oublier les personnes qui s’en serviront tous les jours
Un outil interne est commandé par la direction, payé par la direction, validé par la direction — et utilisé par quelqu’un d’autre. Quand les futurs utilisateurs découvrent l’outil à la mise en service, deux réactions se produisent, souvent ensemble : ils trouvent des cas courants que personne n’avait mentionnés, et ils continuent à utiliser leurs anciennes méthodes en parallèle « le temps de voir ».
Cette double saisie est le symptôme le plus fiable d’un projet en train d’échouer. Elle ne se corrige pas par la formation ni par une note de service : elle signale que l’outil ne couvre pas la réalité du travail.
L’antidote coûte une demi-journée. Faites décrire le processus par la personne qui l’exécute, pas par son responsable, et faites-lui valider les écrans avant qu’ils existent, sur papier s’il le faut. Désignez ensuite un référent interne qui aura le dernier mot sur les arbitrages du quotidien — et donnez-lui du temps pour ça, pas seulement le titre.
| L’erreur | Le signal d’alerte | Le correctif |
|---|---|---|
| Partir de l’outil | La catégorie d’outil est nommée avant que le problème soit chiffré | Deux réunions de description du travail réel, sans nommer d’outil |
| Viser trop large | Plus de trois services concernés par la première version | Un seul processus, couvert entièrement, mis en service avant le reste |
| Oublier les utilisateurs | Aucun utilisateur final présent aux réunions de cadrage | Un référent interne désigné, disponible, avec pouvoir d’arbitrage |
Un devis qui liste cent lignes de fonctionnalités donne une impression de maîtrise, mais il chiffre surtout la capacité du prestataire à retranscrire ce que vous avez dit. Plus la liste est longue, plus la probabilité est forte que vous payiez des fonctions dont personne n’aura l’usage. Demandez plutôt un chiffrage en deux temps : une première version restreinte avec une date de mise en service, puis une enveloppe indicative pour la suite. Un prestataire qui refuse de découper est un prestataire qui a intérêt à ce que vous ne testiez rien avant la fin.
Cadrer en trois séances avant de demander un devis
Ces trois erreurs se neutralisent avec trois réunions internes, avant tout contact commercial.
La première séance décrit le travail tel qu’il se fait. Les personnes qui exécutent le processus racontent leur journée, étape par étape. Vous notez les points de friction et les reprises manuelles, sans proposer de solution.
La deuxième séance chiffre. Combien d’heures par mois, combien d’erreurs, combien de commandes perdues, combien de facturation en retard. Une estimation grossière suffit : l’objectif est d’obtenir un ordre de grandeur annuel, qui servira de plafond raisonnable à votre investissement. C’est le calcul que détaille l’article sur le coût réel d’un logiciel métier sur mesure.
La troisième séance découpe. Parmi tout ce qui a été listé, vous choisissez le segment qui, réglé seul, produirait déjà un gain mesurable. C’est le périmètre que vous ferez chiffrer. Le reste part dans une liste d’attente, datée, que vous ressortirez après la mise en service.
À l’issue de ces trois séances, vous pouvez consulter des prestataires avec un document de deux pages qui vaut mieux qu’un cahier des charges de quarante. Et vous saurez reconnaître celui qui vous propose d’en couvrir la moitié pour commencer : c’est généralement le bon. Si vous voulez voir à quoi ressemble ce type de démarche appliquée à une PME, la page applications métier sur mesure en décrit le déroulé.
Pour aller plus loin
7 questions à poser avant de lancer un projet digital pour votre PME
Le guide complète ce cadrage par les questions à poser au prestataire avant de signer : propriété de l'outil, conditions de reprise, budget de fonctionnement annuel — celles qui coûtent le plus cher quand on les découvre après coup.
Télécharger le guide gratuitementLa règle à retenir
Un projet d’application de gestion interne se joue presque entièrement avant le premier devis. Nommez le problème avant l’outil, réduisez le périmètre de la première version jusqu’à ce qu’elle paraisse modeste, et mettez un utilisateur quotidien dans la pièce dès le cadrage.
Ces trois décisions ne coûtent rien et prennent trois demi-journées. Elles déterminent pourtant l’essentiel de ce que vous obtiendrez — et l’essentiel de ce que vous ne paierez pas pour rien.
Questions fréquentes
Combien coûte une application de gestion interne pour une PME ?
Tout dépend du périmètre, et c'est précisément pour ça que les fourchettes générales ne servent à rien. Un outil qui couvre un seul processus bien délimité — le suivi des interventions, la qualification des demandes entrantes — représente un investissement très différent d'une plateforme qui reprend l'ensemble du cycle commercial. Le bon réflexe n'est pas de chercher un prix moyen, mais de faire chiffrer deux périmètres : le strict nécessaire, et le souhaitable. L'écart entre les deux vous dira beaucoup plus que n'importe quelle fourchette.
Faut-il développer sur mesure ou prendre un logiciel du marché ?
La question se tranche sur un seul critère : votre processus vous distingue-t-il de vos concurrents ? Pour la comptabilité, les congés ou la signature électronique, la réponse est non, et un logiciel du marché fera mieux et moins cher. Pour votre façon de qualifier une demande, de planifier une production ou de gérer un litige, la réponse est souvent oui — et c'est là que le sur mesure se justifie. Beaucoup de PME finissent avec les deux, et c'est généralement la combinaison la plus économique.
Combien de temps faut-il pour mettre en place un outil de gestion interne ?
Une première version utile sur un périmètre restreint se met en service en quelques mois, pas en quelques semaines ni en deux ans. Ce qui allonge réellement les délais n'est pas la fabrication, c'est l'indécision en amont : un périmètre qui bouge, des interlocuteurs qui changent d'avis, des validations qui traînent. Un cadrage sérieux avant de commencer raccourcit le projet bien plus sûrement qu'une équipe plus nombreuse.
Comment savoir si mon entreprise est prête pour une application métier ?
Trois indices simples. Vous savez nommer précisément le processus qui coince, et le chiffrer en temps ou en argent. Vous pouvez désigner une personne en interne qui aura le dernier mot sur les arbitrages et qui sera disponible. Et vous acceptez de démarrer sur un périmètre réduit plutôt que sur l'outil complet. Si l'un des trois manque, il vaut mieux régler ça d'abord : un projet lancé sans ces éléments dérive dans presque tous les cas.