Quand l’outil n’existe pas, ou coûte plus cher que de l’écrire.

Le problème que cela résout

Il arrive un moment où le logiciel en place ne fait pas tout à fait ce qu’il faudrait. Trois issues se présentent alors : changer d’outil, ce qui coûte cher et emporte les habitudes de travail ; acheter un module du marché, quand il existe et que son prix reste raisonnable ; ou faire écrire ce qui manque.

La troisième voie est souvent écartée par réflexe, jugée réservée aux grandes structures. Elle est pourtant la moins chère dès que le besoin est précis et le périmètre réduit. J’ai écrit un module de mesure d’audience pour PrestaShop parce que les modules équivalents du marché se vendaient à un prix sans rapport avec ce qu’ils font.

La méthode

Écoute du besoin

Le besoin se recueille auprès de ceux qui feront le travail avec l’outil, pas seulement auprès de celui qui signe. C’est là que se trouvent les contraintes réelles : le geste répété quarante fois par jour, le cas particulier qui revient chaque fin de mois, la donnée qu’il faut ressaisir parce que deux logiciels ne se parlent pas.

Cette étape produit une description en français, pas un cahier des charges technique. Si nous ne sommes pas d’accord sur le problème, le reste ne sert à rien.

Étude technique et faisabilité

Avant d’engager la dépense, je regarde ce que permet réellement le logiciel à étendre : ses points d’extension, ses interfaces de programmation, ce qu’une mise à jour risque d’emporter.

Cette étude débouche parfois sur un avis négatif, et c’est un résultat utile. Mieux vaut apprendre en quelques heures qu’un développement serait fragile ou vite obsolète, plutôt qu’en quelques semaines.

Développement

Le code se greffe sur l’existant plutôt qu’il ne le remplace. Un module s’installe et se désinstalle, il ne modifie pas le cœur du logiciel : c’est ce qui permet aux mises à jour de continuer à s’appliquer.

Le travail est versionné du premier jour. Vous savez ce qui a changé, quand, et vous pouvez revenir en arrière.

Test et correction

L’outil est essayé en conditions réelles, avec vos données et vos cas particuliers, pas seulement avec un exemple qui fonctionne. Les corrections de cette phase sont comprises dans le développement : un module qui marche sur le jeu d’essai et pas chez vous n’est pas terminé.

Adaptation à l’utilisateur

Quelques semaines d’usage révèlent ce qu’aucune réunion n’avait vu. Un champ mal placé, une étape en trop, un libellé que personne ne comprend. Cette phase d’ajustement est prévue dès le départ, parce qu’elle est la règle et non l’exception.

Ce que j’ai déjà écrit

Ces travaux sont publics, sous licence libre, et leur code est lisible par n’importe qui :

• Module Matomo pour PrestaShop 9 : mesure d’audience et suivi e-commerce avec trois modes de collecte, dont un mode serveur qui ne dépose rien dans la page livrée au visiteur. Multiboutique, licence MIT.
• Synchronisation PrestaShop et Odoo : rapprochement entre la boutique et la gestion, pour cesser de ressaisir.
• Code-barres sur les bons de livraison Odoo : un module Python de quelques centaines de lignes qui règle un geste quotidien en préparation de commande.
• Passerelle clavier d’alarme et domotique : synchronisation bidirectionnelle entre un panneau d’alarme et un clavier Zigbee.

Publier le code n’est pas une coquetterie. C’est ce qui vous garantit de pouvoir reprendre l’outil ailleurs, avec quelqu’un d’autre, le jour où vous le souhaitez.

Quand on m’appelle

Quand un devis d’éditeur paraît disproportionné au regard du besoin. Quand deux logiciels doivent échanger et que personne ne propose la passerelle. Quand une manipulation répétitive coûte plus cher en temps qu’elle ne coûterait à automatiser.

Décrivez ce que vous n’arrivez pas à faire aujourd’hui sur la page contact. L’étude de faisabilité vient avant le devis.