Refonte d'outil métier

Votre outil interne a rendu service pendant des années. Aujourd'hui il freine plus qu'il n'aide. Voici comment on le remplace, sans perdre vos données ni arrêter votre activité.

Échange découverte

Prix fixe, premier livrable en quelques semaines, maintenance incluse.

Un outil métier ne meurt pas d'un coup

Il se dégrade lentement. Le tableur créé pour dépanner devient l'outil de référence de tout un service. La base Access qui tournait bien à trois utilisateurs en accueille douze. L'application développée il y a quinze ans fonctionne encore, mais celui qui l'a écrite est parti et personne n'ose y toucher.

Pendant longtemps, tout le monde s'arrange. On contourne, on ressaisit, on garde une copie de secours au cas où. Le coût de ces contournements ne se voit nulle part dans les comptes, alors la refonte n'est jamais prioritaire.

Ce qui déclenche la décision, c'est presque toujours un événement précis : un départ, une panne, un audit, une croissance qui rend le bricolage intenable, ou un éditeur qui annonce la fin du support. Si vous lisez cette page, il y a des chances que quelque chose de ce genre vienne de se produire.

Les signes qui reviennent le plus souvent

Un seul de ces points ne justifie pas forcément une refonte. Trois ou quatre, si.

  • Une seule personne sait faire fonctionner l'outil, et son départ serait un problème.
  • Les données sont ressaisies plusieurs fois, d'un outil à l'autre.
  • Impossible d'y accéder en déplacement ou depuis un mobile.
  • Chaque évolution coûte cher, prend des mois, ou se heurte à un refus.
  • L'outil impose sa logique au métier, alors que ce devrait être l'inverse.
  • Personne ne sait ce qui se passerait si le fichier ou le serveur était perdu.

Refondre, ce n'est pas tout reconstruire à l'identique

Un outil qui a vécu quinze ans a accumulé des fonctions que plus personne n'utilise, des écrans créés pour un client parti depuis longtemps, des règles dont l'origine s'est perdue. Reproduire tout cela à l'identique coûterait cher pour reconduire les mêmes problèmes.

Le cadrage sert précisément à faire ce tri : ce qui est utilisé tous les jours, ce qui sert une fois par an, ce qui ne sert plus. C'est aussi le moment où remontent les règles métier que personne n'avait jamais écrites, celles qui vivaient dans la tête de deux personnes. Elles sont souvent le vrai contenu de l'ancien outil.

On en sort avec un périmètre écrit, court, qui dit ce qui sera fait et ce qui ne le sera pas. C'est ce périmètre qui permet de s'engager sur un prix fixe. Le détail des étapes est ici.

Et si l'outil n'existe pas encore

Toutes les demandes ne partent pas d'un existant à remplacer. Il arrive que le besoin soit réel mais qu'aucun logiciel du marché ne le couvre, alors les équipes s'arrangent avec des tableurs et des emails en attendant. Le point de départ est différent, la démarche est la même : cadrage, périmètre écrit, prix fixe, livraison par itérations.

C'est le sujet de la page application métier sur-mesure.

Questions fréquentes

Refonte ou remplacement par un logiciel du marché : comment choisir ?
La question à se poser est celle du taux de couverture. Si un logiciel du marché couvre 90 % de votre besoin, prenez-le : ce sera moins cher et mieux maintenu, et on vous le dira franchement pendant l'échange découverte. La refonte sur-mesure se justifie quand aucun produit ne dépasse 70 %, quand votre façon de travailler est un avantage concurrentiel qu'il ne faut pas aligner sur celle de tout le monde, ou quand les licences d'un outil surdimensionné coûtent plus cher que l'outil que vous auriez pu faire faire.
On va perdre nos données historiques ?
Non, la reprise des données fait partie du projet et figure dans le devis. Un fichier Excel, une base Access ou une base PostgreSQL se lisent directement. Pour un format propriétaire, on passe par les exports du logiciel, et si l'éditeur a disparu, par une lecture directe des fichiers. C'est un point qu'on regarde pendant le cadrage, avant de s'engager sur un prix.
Combien de temps avant d'avoir quelque chose d'utilisable ?
Le premier livrable testable arrive en quelques semaines après la signature. Le développement avance par itérations courtes : vous voyez l'outil se construire et vous le testez au fur et à mesure, plutôt que d'attendre six mois une grande livraison. La mise en production complète se situe généralement entre 6 et 12 semaines selon le périmètre.
Faut-il tout refaire d'un coup ?
Rarement, et c'est même déconseillé. On commence par la partie qui fait le plus mal au quotidien, on la met en service, et le reste suit. L'ancien et le nouvel outil peuvent cohabiter le temps de la transition. Ça réduit le risque et ça permet de mesurer le bénéfice avant d'aller plus loin.
Qu'est-ce qui garantit qu'on ne sera pas dépendant de vous ?
Le code source est versionné dans un dépôt Git qui vous appartient, la base de données est ouverte (PostgreSQL), la documentation et les scripts de déploiement vous sont remis. La maintenance mensuelle est sans engagement de durée. Si vous voulez internaliser ou changer de prestataire, vous partez avec tout.
Que couvre la maintenance mensuelle ?
Hébergement, sauvegardes, mises à jour de sécurité, support et petites évolutions. Ce n'est pas seulement de la correction de bugs : l'outil continue d'évoluer avec votre activité. C'est ce qui fait qu'un outil métier reste utile cinq ans plus tard au lieu de devenir à son tour le vieux logiciel qu'il faudra refaire.

Vous vous reconnaissez dans une de ces situations ?

30 minutes pour regarder votre outil actuel et vous dire ce qui est réaliste. Si une solution du marché fait l'affaire, on vous le dira aussi.

Échange découverte