Lecture 5 min

Développement logiciel sur mesure : faire construire ou acheter

On fait construire un logiciel métier seulement si celui du marché force à changer la façon de travailler, ou s’il ne couvre pas le cas.

Une boîte fermée et un cahier ouvert, chacun au bout d’un chemin qui se sépare

Choisir entre un produit du marché et un développement logiciel sur mesure n’est pas d’abord une décision technique. C’est une décision d’organisation.

La vraie question est simple : est-ce que le travail important de votre équipe tient dans un outil existant sans être déformé ?

On fait construire un logiciel métier seulement si celui du marché force à changer la façon de travailler, ou s’il ne couvre pas le cas. Sinon, il vaut souvent mieux acheter, configurer correctement, former l’équipe et avancer.

Quand le travail est déjà couvert

Un produit du marché convient quand beaucoup d’entreprises font le même geste de manière assez proche.

La comptabilité, la messagerie, l’agenda, la signature électronique, la prise de rendez-vous simple ou une gestion commerciale standard sont de bons exemples. Dans ces cas, l’entreprise n’a pas intérêt à réinventer une base déjà solide. Elle doit plutôt choisir un produit fiable, accepter son modèle, paramétrer ce qui doit l’être, puis concentrer son énergie ailleurs.

Cela ne veut pas dire que l’équipe n’aura aucun effort à faire. Un produit impose toujours une façon de nommer les choses, de ranger les informations, de définir les rôles. Une adaptation raisonnable est normale.

Le signal d’alerte apparaît quand l’équipe doit contourner l’outil tous les jours : fichier Excel à côté, double saisie, validation faite par message parce que l’outil ne sait pas la porter, information critique cachée dans une note, exception suivie dans la tête d’une personne.

À ce moment-là, le problème n’est plus l’ergonomie. C’est l’ajustement entre le logiciel et le travail réel.

La bonne question n’est donc pas “pouvons-nous faire mieux nous-mêmes ?”. La bonne question est : “ce travail est-il déjà pris en charge sans forcer notre équipe à bricoler autour de l’outil ?”.

Si oui, achetez. C’est souvent la décision la plus saine.

Quand le produit force à changer le travail

Le développement logiciel sur mesure devient pertinent quand le produit du marché demande à l’équipe d’abandonner une étape qui compte, ou quand il ne sait pas représenter le cas.

Cela arrive souvent dans les activités où la valeur vient d’une manière précise de traiter les dossiers : séquence de validation particulière, règles dépendantes du terrain, suivi d’exceptions, combinaison de contraintes métier, passage entre plusieurs systèmes, responsabilité qui change selon le contexte.

Dans ces situations, l’application métier sur mesure ne sert pas à “avoir son propre outil” par préférence. Elle sert à préserver une méthode de travail qui a de la valeur.

Le besoin peut être plus petit qu’on l’imagine. Il ne s’agit pas forcément de refaire tout le système d’information. Un logiciel métier sur mesure peut être un portail, un outil interne, une couche entre deux systèmes, une interface de validation, un suivi de dossiers, ou une automatisation encadrée.

Le point commun est le même : le travail existe déjà, il est important, et les solutions disponibles le tordent ou l’ignorent.

Un bon projet sur mesure protège le cœur spécifique du métier. Il ne reconstruit pas ce que le marché fait déjà bien.

La question avant de choisir

Avant de comparer des fournisseurs ou de demander des devis, prenez un seul flux de travail.

Pas “l’organisation”. Pas “le suivi client”. Pas “la production”. Un flux précis : une demande arrive, quelqu’un vérifie, une décision est prise, une information est transmise, un dossier avance.

Observez ce flux tel qu’il se passe vraiment. Pas la version idéale. La vraie version : les copier-coller, les relances, les vérifications implicites, les décisions prises dans un message, les fichiers temporaires qui deviennent permanents, les exceptions que l’outil ne montre pas.

Ensuite, écrivez ce qui doit rester vrai :

  • quelles étapes ne peuvent pas disparaître.
  • quelles informations doivent être visibles au bon moment.
  • qui doit valider quoi.
  • quelles exceptions doivent être suivies.
  • ce qui ne doit pas être perdu entre deux personnes ou deux outils.

Si un produit du marché respecte ces points avec une adaptation raisonnable, il faut l’acheter.

Si l’équipe contourne le produit chaque jour pour préserver ces points, le produit ne convient pas.

C’est cela, le vrai test du développement d’application sur mesure. Pas une liste de fonctions. Pas une préférence pour une interface. Un contrôle sur le travail qui doit rester fiable.

Ce que ce n’est pas

Un projet sur mesure n’est pas une version plus jolie d’un outil qui fonctionne déjà. Une interface plus agréable peut compter, mais elle ne suffit pas à justifier un chantier de fond.

Ce n’est pas une manière d’éviter d’apprendre un produit existant. Si le travail est standard et bien couvert, le sujet est probablement l’adoption, la formation ou le paramétrage.

Ce n’est pas un second projet pour un logiciel utilisé rarement. Si le flux est peu fréquent, non critique et supportable avec un outil existant, la création de logiciel métier risque de coûter plus qu’elle ne rapporte.

Ce n’est pas non plus une volonté de tout centraliser par principe. Centraliser peut aider quand cela réduit une friction réelle. Centraliser pour “tout avoir au même endroit” crée souvent un outil trop large, difficile à maintenir, et moins bon que les produits spécialisés qu’il remplace.

Construire se justifie quand l’outil générique oblige l’équipe à renoncer à son vrai travail ou à le cacher dans des contournements permanents.

Trancher cette semaine

Vous pouvez prendre une première décision sans lancer une grande étude.

  1. Nommez le travail en une phrase.
  2. Listez ce qu’un produit du marché forcerait l’équipe à arrêter de faire.
  3. Enlevez de cette liste les préférences de confort.
  4. Gardez seulement les éléments qui touchent à la qualité, au délai, au contrôle, à la responsabilité ou à la valeur métier.
  5. Si la liste est vide, achetez.
  6. Si la liste décrit le travail lui-même, faites construire.
  7. Ne partez pas d’une liste de fournisseurs avant d’avoir fait ce test.

Cette séquence ramène la décision à l’essentiel : qu’est-ce que l’équipe doit continuer à faire pour bien travailler, et qu’est-ce qu’un produit l’obligerait à abandonner ou à bricoler ?

La suite

Si le test dit de faire construire, la conversation suivante ne doit pas commencer par les écrans. Elle doit commencer par le travail, les personnes qui le font, les exceptions à préserver, et ce que la première version laisse volontairement de côté.

C’est souvent le meilleur point de départ avec Perfusion.

Prendre rendez-vous

Parlons de votre projet

Faites le point en 15 minutes sur votre projet et les pistes de financement.

Prendre rendez-vous avec Perfusion.dev
Retour au blog