Ce que nous refusons de construire, et pourquoi

Un négociant en matériaux nous demande d'intégrer la facturation dans sa nouvelle application, pile sur le logiciel que son expert-comptable connaît par cœur ; un restaurateur demande un écran de gestion de la paie, alors que son cabinet s'en occupe très bien depuis des années. Dans les deux cas, nous répondons non. Ce que nous refusons de construire dit autant sur notre façon de travailler que ce que nous construisons.

Refuser de reconstruire un outil qui fait déjà le travail#

La première chose que nous refusons est la plus simple à expliquer : reconstruire ce qu'un outil du commerce fait déjà correctement. Un logiciel de comptabilité suivi par un expert-comptable, un logiciel de caisse à jour de ses obligations, un outil de paie qui sort les bulletins chaque mois sans erreur : nous ne proposons jamais de les remplacer par un écran maison.

Si un logiciel du commerce fait le travail, prenez-le. Nous vous le dirons, et ça nous arrive.

Ce que nous construisons se branche à côté : une donnée saisie une fois dans l'application ressort vers le logiciel de comptabilité au bon format, sans ressaisie. L'application prend en charge ce qui n'existe nulle part ailleurs pour ce métier précis, et laisse le reste à qui le fait déjà bien. Le choix entre un logiciel du commerce et une application sur mesure se pose écran par écran, pas pour l'entreprise entière.

Refuser une fonctionnalité sans personne pour dire qui l'ouvrira#

La deuxième chose que nous refusons revient presque à chaque audit : une fonctionnalité demandée « au cas où », sans qu'on puisse dire qui l'ouvrira, ni quel jour du mois. Un export comptable avancé que personne n'a encore réclamé, un tableau de statistiques pensé pour une direction qui n'a jamais posé la question, une case ajoutée « pour plus tard » : ce sont les premiers écrans qui dorment, six mois après la mise en service, comme les fonctionnalités payées et jamais ouvertes d'un logiciel du marché.

Avant d'ajouter un écran à une première version, nous posons une seule question : qui l'ouvrira, et à quel moment de son mois ? Si personne ne répond avec précision, l'écran attend. Il revient dès qu'une personne précise en a besoin pour une tâche précise, jamais avant.

Prenons l'hypothèse d'un négociant en matériaux qui demande vingt écrans pour sa première version. En posant cette question à chacun, cinq n'ont pas de réponse claire et sortent du périmètre de départ. Dans cet exemple, c'est cinq écrans de moins à construire, et une première version qui arrive plus tôt pour tout le reste.

Refuser de porter la mise à jour d'un sujet réglementé#

La troisième chose que nous refusons est de porter, à notre compte, la mise à jour d'un sujet réglementé : la paie, la facturation électronique obligatoire, la caisse enregistreuse. Ces sujets changent par la loi, pas par nous, et un éditeur spécialisé les suit à plein temps, souvent avec une certification à la clé.

Construire notre propre écran de paie demanderait de suivre chaque barème, chaque taux, chaque exception : un travail qui relève d'un métier différent du nôtre, et qui exposerait l'entreprise à un retard de conformité si nous prenions du retard. Nous préférons connecter l'application à l'outil spécialisé déjà en place, dans les deux sens : les heures saisies sur le terrain partent vers le logiciel de paie, les documents produits par la caisse remontent dans l'application pour le suivi du jour.

Le gain pour vous : une seule mise à jour légale à surveiller, portée par qui en a fait son métier, pendant que l'application s'occupe de ce qu'aucun éditeur généraliste ne couvre pour votre métier précis.

La grille que nous appliquons avant de dire oui#

Ce qui change avec une application construite pour l'entreprise#

Cette grille se pose avant d'écrire la première ligne, pendant l'audit qui ouvre le projet. Elle continue de se poser à chaque demande d'évolution, des mois après la mise en service : une nouvelle fonctionnalité suit la même question, qui l'ouvrira et quand, avant d'entrer dans le périmètre.

Pour vous, le résultat est une application plus légère à utiliser, qui ne demande pas de naviguer entre des écrans que personne n'ouvre pour atteindre ceux qui servent tous les jours. Voir ce que couvre une application construite pour une entreprise.

Ce qu'il ne faut pas en conclure#

Refuser une demande n'est pas la clore définitivement. Un écran reporté parce que personne ne pouvait dire qui l'ouvrirait revient dès qu'une personne précise en a besoin : le refus porte sur le moment, pas sur le principe. De même, se connecter à un outil existant ne veut pas dire s'en contenter partout : si cet outil devient lui aussi un frein, la question se repose à ce moment-là, pas avant.

Ce que nous refusons de construire : ce qu'il faut retenir#

Trois refus reviennent à chaque projet : reconstruire un outil qui fait déjà le travail, ajouter un écran sans personne pour dire qui l'ouvrira, porter la mise à jour d'un sujet réglementé qui n'est pas notre métier. Une seule question tranche la plupart des cas : qui s'en servira, et à quel moment précis ?

Un prestataire qui dit oui à toute demande construit, au bout du compte, une application plus lourde que celle dont vous avez besoin. Dire non au bon moment fait partie du travail, autant que dire oui au reste.