On bâtit votre logiciel
sur mesure.

Sur mesure ou logiciel du marché : comment on tranche

La question se règle sur un seul critère : est-ce que ce process est ce qui vous différencie de vos concurrents ? Pour la paie, la comptabilité, la messagerie, la réponse est non, et un progiciel du marché fera mieux et moins cher que n'importe quel développement. Pour la façon dont vous configurez un produit, planifiez une tournée ou suivez une affaire, la réponse est souvent oui, et c'est là que le sur mesure se justifie.

Le piège classique est l'entre-deux : prendre un progiciel standard pour un process différenciant, puis le tordre à coups de développements spécifiques jusqu'à en faire un logiciel sur mesure hors de prix, qu'on ne peut plus mettre à jour. Quand ce diagnostic apparaît, on le dit, quitte à ce que le projet n'ait pas lieu. C'est le rôle du cadrage de trancher cela avant d'écrire une ligne de code.

Ce qui fait le coût d'un logiciel sur mesure

Ce n'est presque jamais le nombre d'écrans. Les quatre postes qui font vraiment varier l'effort :

• Le nombre d'intégrations avec des systèmes existants, ERP, CRM, outil comptable. Chaque connexion apporte ses formats, ses pannes et ses cas particuliers.
• La reprise de données de l'ancien système, dont la qualité réelle est presque toujours inférieure à ce que l'on croit.
• Le niveau d'exigence sur la disponibilité et la sécurité, qui n'est pas le même pour un outil interne utilisé par dix personnes et pour un portail ouvert à vos clients.
• Les contraintes réglementaires ou de conformité, quand il y en a.

C'est pour cela qu'on cadre le périmètre avant de s'engager : un chiffrage donné sans avoir regardé ces quatre points n'est pas un chiffrage, c'est un pari.

Les deux étapes qu'on sous-estime toujours

La reprise de données d'abord. Vingt ans de saisie dans un ancien outil, cela veut dire des doublons, des champs détournés de leur usage, des conventions qui ont changé trois fois. Le travail n'est pas technique, il est décisionnel : quelqu'un chez vous doit trancher ce qu'on garde, ce qu'on corrige et ce qu'on abandonne. C'est le poste qui déborde le plus souvent, et c'est rarement de la faute du prestataire.

La recette ensuite, c'est-à-dire la vérification par vos équipes que le logiciel fait bien ce qu'il doit faire, sur de vrais cas. Elle demande du temps aux personnes les plus occupées de l'entreprise, celles qui connaissent le métier. Une recette bâclée se paie en production, au moment le plus coûteux.

Commencer petit : le MVP

Quand le périmètre est large ou que l'usage reste incertain, on livre d'abord un MVP, une première version réduite au strict nécessaire mais réellement utilisable en production par une équipe. L'objectif n'est pas de faire une démonstration, il est de confronter l'outil au terrain pendant que le budget engagé reste faible.

Ce que le terrain renvoie en trois semaines d'usage réel vaut mieux que six mois de spécifications. Les priorités de la suite se décident sur cette base, pas sur un cahier des charges écrit avant que quiconque ait vu le produit.

Ce que recouvre la maintenance, une fois livré

Ce qu'on appelle la TMA, ou tierce maintenance applicative, couvre trois choses qu'on confond souvent :

• Le correctif : les anomalies découvertes après la mise en production.
• L'adaptatif : ce qu'il faut ajuster quand l'environnement bouge, montée de version, changement d'API chez un partenaire, évolution réglementaire. C'est le poste qu'on oublie de budgéter, et il ne dépend pas de vous.
• L'évolutif : les nouvelles fonctions demandées par les utilisateurs une fois qu'ils se sont approprié l'outil.

La propriété du code est ce qui rend ce sujet non captif : sources sur votre dépôt, documentation livrée, comptes d'hébergement à votre nom. Vous pouvez nous confier la maintenance, la reprendre en interne, ou la confier à un tiers, sans rien redévelopper.