Quand passer à un logiciel sur-mesure

Eurostat a mesuré qu’en 2025, parmi les entreprises de l’Union européenne comptant dix salariés ou plus, plus de la moitié, 53,47 %, utilisaient au moins un logiciel de gestion intégrée, de relation client ou de pilotage par les données. Pour celles-là, la question n’est plus de savoir s’il faut un outil, mais de savoir quand passer à un logiciel sur-mesure, à quel moment celui qui tourne cesse de convenir. Ce moment ne se lit ni dans un effectif ni dans un chiffre d’affaires. Il se lit dans le travail que vos équipes font à côté du logiciel, dans les règles qu’aucun écran n’applique, et dans les dates que d’autres ont fixées à votre place. Vous trouverez ici les trois signaux qui datent cette décision, les deux constats qui y ressemblent sans rien prouver, les échéances qui commandent un calendrier de projet, le cas de l’outil sur-mesure que vous avez déjà, et le calcul à mener avec vos propres chiffres avant d’appeler un prestataire.

Les signaux qui datent la décision

Un logiciel cesse de convenir bien avant que quelqu’un le dise à voix haute. Trois signaux se relèvent sans compétence technique, dans le travail quotidien de vos équipes, et chacun appelle une décision différente. Un seul des trois conduit directement à faire développer un outil.

Le travail qui se fait à côté du logiciel

Un contournement est tout ce que vos équipes font en dehors de l’outil officiel pour arriver au résultat attendu. Elles tiennent un tableur en parallèle pour suivre ce que le logiciel ignore, reprennent un export à la main avant de l’envoyer au client, consignent une information dans un message parce qu’aucun champ ne l’accueille, ou entretiennent un fichier partagé qui sert de mémoire commune sur les dossiers en cours.

Demandez à chaque personne concernée ce qu’elle fait en dehors du logiciel dans une journée ordinaire, et notez-le sans commenter. Vous obtenez une liste qui se compte, et c’est sa forme qui vous intéresse plus que sa longueur. Un contournement isolé sur une tâche secondaire ne pèse rien. Dix contournements concentrés sur un même processus métier, votre façon de traiter une affaire par exemple, désignent un endroit précis où l’outil ne suit plus votre organisation. La bascule se joue sur cette concentration bien plus que sur le nombre total. Quand le contournement principal est un classeur qui porte à lui seul un processus entier, ce qu’un tableur partagé cesse de tenir passé un certain point vaut d’être lu avant toute conclusion.

À ce stade, la seule décision utile consiste à relever et à compter. Le chiffrage attend d’avoir la liste complète.

La même information saisie à deux endroits

Une information saisie dans deux logiciels par deux personnes différentes finit par exister en deux versions qui ne disent pas la même chose. Le devis validé dans un outil est retapé en commande dans un autre, puis ressaisi en facture dans un troisième. Cette double saisie coûte des heures et produit des écarts que personne n’arbitre.

Une double saisie fait conclure trop vite au remplacement des deux logiciels, alors que deux outils qui ne s’échangent rien peuvent être reliés. Une interface de programmation, appelée API, laisse un logiciel lire et écrire les données d’un autre sans intervention humaine. Avant d’envisager un développement complet, posez trois questions écrites à vos deux éditeurs : une interface de programmation permettant l’échange automatique existe-t-elle et en version documentée, votre contrat en vigueur couvre-t-il son usage, et quelles données précises peuvent en sortir. Trois réponses positives suffisent à envisager de relier vos deux outils l’un à l’autre, un chantier qui porte sur le transfert des données, pas sur la réécriture de votre outil.

Vous tranchez ce signal sur ces trois réponses. Un refus, ou une interface qui ne donne pas une donnée qui circule tous les jours, fait basculer ce signal du côté du développement. Un accord vous laisse traiter le problème par une connexion entre les deux outils, sans écrire un logiciel de plus.

Une règle de gestion que seule une personne sait appliquer

Une règle de gestion est une décision que votre entreprise applique de façon constante : la remise accordée selon le volume et l’ancienneté du client, le circuit de validation qui change au-dessus d’un certain montant, l’échéance calculée autrement pour un donneur d’ordre public, la pièce à réclamer avant d’ouvrir un dossier.

Quand cette règle n’existe dans aucun écran, elle vit dans la tête d’une personne, ou dans un fichier qu’elle est seule à savoir lire. Cette dépendance à une personne clé se vérifie par une question posée à voix haute en réunion : si cette personne s’absente, qui applique la règle, et sur quelle base. Quand personne ne répond, vous tenez celui des trois signaux qui conduit directement à faire développer un outil.

Un paramétrage ne corrige pas ce cas, puisque l’éditeur n’a jamais prévu la règle, et une formation non plus, puisque la règle n’est écrite nulle part. Voilà ce qui date une décision : le jour où une règle qui engage votre argent ou votre responsabilité dépend encore de la présence de son auteur, elle doit entrer dans un outil. La première chose à produire est la règle elle-même, écrite en une phrase, dans les mots de la personne qui l’applique. Cette phrase ouvre le cahier des charges. Le cahier des charges doit aussi répondre à la question symétrique, côté prestataire cette fois : qui héberge les données une fois entrées dans l’outil, sous quelles conditions vous les récupérez si vous changez de prestataire, et à qui appartient le code livré. Cette dépendance à un fournisseur remplace la dépendance à une personne clé décrite plus haut, et elle se vérifie de la même façon, par une question posée par écrit avant de signer.

Les deux constats qui ressemblent à un déclencheur

Les deux constats qui suivent servent d’argument et ne prouvent rien tant qu’un des trois signaux ne les accompagne pas.

La croissance seule ne décide de rien

En 2025, parmi les entreprises de dix salariés ou plus, 41 % des petites entreprises de l’Union utilisaient un logiciel de gestion intégré, contre 89 % des grandes. Pour la gestion de la relation client, sur ce même périmètre, l’écart va de 25 % à 65 %. Ces écarts disent que les grandes entreprises sont mieux équipées que les petites. Ils ne disent rien de la nature de l’outil, ni de qui l’a écrit.

Un produit du marché convient tant que votre activité rentre dans ses cases, quelle que soit votre taille. Le nombre de personnes à équiper d’un compte pèse sur la facture des licences, et il entre à ce titre dans la comparaison des coûts sur la durée. Il ne date aucune décision par lui-même.

L’agacement des équipes contre l’outil en place

Un logiciel détesté reste parfois un logiciel adapté. Trois causes se confondent derrière la même plainte. Personne n’a repris le paramétrage d’origine depuis l’installation, et l’outil est resté réglé pour une organisation que vous n’avez plus. La formation s’est arrêtée à la mise en service, et chacun a appris depuis le chemin le plus court plutôt que le bon. Vous payez un module acheté et jamais ouvert, une fonction que personne ne sait utiliser.

Ces trois causes se traitent chez votre éditeur actuel, sur le produit que vous avez déjà. La vérification tient en une consigne : reprenez les règles que l’outil n’applique pas, et faites répondre votre éditeur par écrit sur chacune, réglable dans le produit, faisable en ajoutant du développement, ou hors de portée. Les quatre endroits précis où un produit du marché s’arrête donnent le détail de ce test. Tant qu’il n’a pas été mené, l’agacement des équipes reste une opinion.

Le calendrier que vous ne fixez pas

Les signaux précédents viennent de chez vous, et vous décidez du moment où vous les traitez. Les deux dates qui suivent viennent d’ailleurs, et elles commandent un calendrier de projet que vous n’avez pas choisi.

Une échéance réglementaire déjà datée

La facturation électronique entre entreprises en donne l’exemple le plus net en France. Toutes les entreprises doivent être en mesure de recevoir leurs factures fournisseurs au format électronique depuis le 1er septembre 2026. L’obligation d’émettre s’applique à la même date aux grandes entreprises et aux entreprises de taille intermédiaire, puis aux PME et aux micro-entreprises à partir du 1er septembre 2027. La facture transite par une plateforme que l’administration fiscale a agréée.

Une échéance réglementaire de ce type déplace deux décisions. La première porte sur la date de mise en service : deux changements simultanés sur le même flux de facturation se contrôlent mal, et viser exactement ce mois-là revient à cumuler les deux risques. La seconde porte sur le périmètre. Votre façon de calculer un prix vous appartient, et c’est elle qui justifie un outil écrit pour vous. Le format d’une facture électronique s’impose de la même manière à toutes les entreprises, et votre logiciel de facturation le suit déjà.

Une fin de maintenance annoncée par votre éditeur

La seconde date vient de l’entreprise qui édite votre logiciel actuel. SAP a publié la sienne pour la suite de gestion Business Suite 7 : la maintenance standard s’arrête fin 2027, une maintenance étendue reste disponible en option jusqu’à fin 2030, moyennant un supplément de deux points sur la base de calcul du support. Aucun client ne choisit cette date, et chacun doit pourtant décider de la suite avant qu’elle arrive.

Une fin de maintenance annoncée change les conditions de la décision. Le budget est arbitré, la reprise de données est de toute façon à faire, et le changement se discute déjà en interne. Le bon réflexe consiste à traiter la migration imposée et la question du sur-mesure comme une seule décision. Refaire à l’identique chez le même éditeur, puis rouvrir le sujet quelques années plus tard, revient à payer deux reprises de données au lieu d’une.

L’outil sur-mesure que vous avez déjà

Reste le cas de l’entreprise qui a déjà fait développer, il y a plusieurs années. La question porte alors sur l’existant plutôt que sur la bascule, et elle ne dépend d’aucune date extérieure. Un outil dédié qui rend encore le service attendu se garde : il se reprend, se met à jour et se documente, et remettre l’outil existant sur une base entretenue conserve les règles déjà écrites au lieu de les réécrire.

La réécriture se justifie sur deux conditions : les règles portées par l’outil ne correspondent plus à votre activité, ou plus personne ne sait comment il fonctionne. Faites établir l’état réel du code et des données avant d’arbitrer, parce qu’une reprise de données depuis un outil sans documentation se chiffre mal tant que personne ne l’a ouvert.

Ce que la situation actuelle vous coûte déjà

Les trois signaux situent le problème. Reste à savoir ce qu’il vous coûte, et vous pouvez l’établir seul, avant d’appeler qui que ce soit.

Reprenez la liste des contournements du premier signal. Sur un cycle de sept jours consécutifs, chronométrez le temps que prend chacun, personne par personne. Ce relevé porte sur la semaine entière plutôt que sur une seule journée, parce qu’une relance, un état à produire ou un contrôle ne tombent pas tous les jours. Comptez à part les tâches mensuelles, une clôture par exemple, que vous reporterez sur douze mois. Multipliez ces heures par le coût horaire chargé des personnes concernées, puis par le nombre de semaines travaillées dans l’année. Vous obtenez le coût des heures perdues, un montant annuel qui se compare directement à un devis.

Ce montant se lit avec la liste en main. Réparti sur beaucoup de personnes et de tâches différentes, il désigne du paramétrage et de la formation à reprendre. Concentré sur un ou deux processus, il donne le prix du manque que le premier signal avait seulement localisé.

Ajoutez ensuite ce qui ne se compte pas en heures : la règle de gestion qui repose sur une seule personne, l’erreur de facturation qu’un contrôle automatique aurait arrêtée, le dossier resté sans nouvelles. Ces éléments ne se convertissent pas en euros. Écrivez-les à côté du montant, ils pèsent dans l’arbitrage.

Le retour sur investissement se lit alors en divisant le prix du développement par ce coût annuel, une fois l’entretien annuel de l’outil retranché de ce coût. Vous obtenez le nombre d’années au bout desquelles l’outil est remboursé, à mettre en face du nombre d’années que vous comptez passer avec lui. La médiane des budgets réellement engagés donne l’ordre de grandeur à porter dans ce calcul.

Ce qui se décide quand la date est la bonne

Un projet ne commence pas par la liste de tout ce que l’outil devra faire un jour. Il commence par un seul processus, le plus coûteux de votre relevé, mis en service pendant que le reste s’écrit. Ce processus unique forme le périmètre de la première version, celle qui se corrige pendant que les habitudes se prennent et qui donne une base réelle pour décider de la suite.

Deux dates encadrent ensuite le projet. La première est celle du départ : une obligation légale ou une fin de maintenance vous l’impose, ou bien vous la fixez vous-même quand rien ne vous l’impose. La seconde est celle à laquelle vous voulez que l’outil tourne. Entre les deux se placent la reprise de données, les droits d’accès par profil et les tests de vos équipes. Votre relevé de contournements et les réponses écrites de votre éditeur déterminent ce qui entre dans cette première version et ce qui attend la suivante.

La façon dont un projet de ce type se déroule se lit étape par étape, et le périmètre couvert par un outil de gestion dessiné sur votre organisation se lit à part. Écrivez à Naratys avec vos deux dates, celle du départ et celle où l’outil doit tourner. Nous vous dirons si le délai tient, et ce qui doit entrer dans la première version pour qu’il tienne.

Sources

E-business integration, Statistics Explained, Eurostat, données 2025, consulté le 8 septembre 2026, https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-business_integration

Larger enterprises used more e-business apps in 2025, Eurostat, 20 mai 2026, https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260520-1

Comment se mettre en conformité avec l’obligation de facturation électronique, Entreprendre.Service-Public.fr, consulté le 8 septembre 2026, https://entreprendre.service-public.gouv.fr/vosdroits/F39785

Innovation Commitment for SAP S/4HANA until 2040, maintenance strategy, SAP Support Portal, consulté le 8 septembre 2026, https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html