Développement de logiciels sur mesure pour PME

Un logiciel sur mesure se justifie quand le processus est vraiment le vôtre, quand aucun produit ne supporte une règle que vous n’avez pas le droit d’abandonner, ou quand les contournements sont devenus plus coûteux que posséder l’outil. Ces cas existent et sont plus fréquents que les éditeurs ne l’admettent. Ce ne sont pas tous les cas.

Alors avant de chiffrer un développement, nous le comparons aux réponses moins chères : configurer ce qui existe déjà, relier deux outils que vous payez de toute façon, ou changer le processus lui-même. Si l’une de ces pistes l’emporte, nous le dirons. Un projet dont aucun de nous ne serait fier nous coûte plus cher qu’une facture plus petite.

Quand le développement l’emporte, la première version couvre une seule tâche du début à la fin : les écrans, les droits, et ce qui se passe quand quelqu’un fait une bêtise. Pas une plateforme pour l’entreprise que vous pourriez devenir.

Les besoins sont rarement dans un document. Ils sont dans un tableur à trois onglets que personne d’autre n’ouvre, dans un modèle d’e-mail, dans une vérification que quelqu’un fait de mémoire chaque vendredi, et dans la raison pour laquelle un collègue trie toujours la liste d’une certaine manière. Nous travaillons à partir de cas réels, surtout les plus tordus, parce que c’est là que vivent les règles.

Tout ce qui est incertain est prototypé tant que le modifier coûte encore peu. Le périmètre, ce qui a été reporté et la manière dont nous saurons que cela a marché restent écrits là où chacun les voit. Les gens réagissent bien mieux à un écran qui ressemble à leur travail qu’à un schéma qui le décrit, et cette réaction arrive tant qu’on peut encore en tenir compte. Ce que nous demandons au départ, ce sont surtout des preuves :

L’application s’organise autour de données que vous reconnaîtriez et de règles que vous pourriez expliquer à voix haute. Authentification, autorisations, validation et journal d’audit vont là où est le risque. Les mettre partout par réflexe n’apporte rien. Les intégrations partent du principe que le réseau tombe et que l’autre côté changera sans prévenir. Sauvegardes et restaurations se conçoivent avec le déploiement, pas une fois que le système contient ce que vous ne pouvez pas vous permettre de perdre.

Nous utilisons des technologies ennuyeuses à dessein (TypeScript, Node.js, React, PostgreSQL) et laissons de côté l’infrastructure dont le projet n’a pas l’usage. Une petite architecture est plus facile à tester, sécuriser, exploiter et transmettre. Le travail de performance va vers les actions répétées toute la journée et les volumes que vous pouvez réellement atteindre, pas ceux d’une présentation. Le vrai test du résultat : un développeur compétent qui ne nous a jamais rencontrés peut-il le reprendre ?

Une estimation est une probabilité, pas une promesse, et sa version honnête vient avec ses hypothèses. Ce qui met un logiciel en retard, c’est rarement le code. C’est une reprise de données bien pire que décrite, une intégration dont la documentation relève de la fiction, ou une décision qui demande trois personnes jamais disponibles la même semaine.

Les parties risquées sont donc examinées en premier, tant qu’il reste de la marge pour changer le plan, et le périmètre est réduit avant la qualité. Si quelque chose doit glisser, vous l’apprenez quand nous le savons, pas à l’échéance. Une première livraison plus petite qui sort vraiment vaut mieux qu’une complète qui recule sans cesse.

Un nouveau logiciel remplace généralement quelque chose qui ne peut pas s’arrêter le jour du lancement. Migration, accès, formation et déploiement se planifient d’un seul tenant. Les données historiques sont nettoyées et importées d’abord dans une répétition, puis rapprochées de la source d’origine : totaux, comptages et un échantillon de dossiers que les gens reconnaîtront. Quand le risque est plus élevé, un groupe pilote tourne sur les deux systèmes pendant un temps.

Les déploiements sont reproductibles et portent leur propre configuration pour chaque environnement. Des contrôles automatisés couvrent les comportements qui comptent, et la journalisation rend un problème de production diagnosticable plutôt que reproductible avec un peu de chance. Les gens reçoivent des instructions courtes pour les tâches qu’ils font vraiment, pas un manuel. Pour tout ce qui est critique, un chemin de retour est convenu, afin qu’une mise en production ordinaire le reste.

Une fois en service, les usages disent quelles hypothèses étaient justes. Là où les gens abandonnent un formulaire, ce sur quoi ils posent des questions, l’étape qui traîne, l’endroit où ils sont retournés au tableur malgré tout. Cela fait une meilleure feuille de route qu’une liste de souhaits. Une option que personne n’ouvre peut disparaître. Un raccourci sur une tâche faite quarante fois par jour vaut plus qu’une fonctionnalité.

Le travail qui maintient le logiciel en vie se planifie : dépendances, mises à jour de sécurité, sauvegardes, et les intégrations qui changent sous vos pieds. La documentation couvre le fonctionnement du système et les décisions qu’on ne peut pas deviner à partir du code.

Le code source, les données et les comptes d’infrastructure sont à vous, organisés ainsi dès le départ, pour qu’il n’y ait rien à négocier à la fin. Tout ce qui est spécifique à un fournisseur est nommé tant que c’est encore un choix, pour que le coût d’un déménagement soit un chiffre que vous connaissez et non que vous découvrez.

Si une autre équipe reprend un jour, ce dont elle a besoin, c’est du dépôt, du processus de déploiement et d’une documentation qui explique les décisions. Ils existent. Un logiciel sur mesure doit vous donner plus de contrôle sur un processus important, pas échanger une dépendance contre une autre.