Une étude d’implantation commerciale est un travail méthodique : délimiter une zone de chalandise, mesurer la population et son pouvoir d’achat, recenser la concurrence, estimer un chiffre d’affaires potentiel, et rendre le tout sous une forme lisible par un dirigeant qui doit décider d’ouvrir ou non un point de vente.
Ce travail est le cœur de métier du cabinet. Il vivait pourtant, comme dans beaucoup d’entreprises, dans une accumulation de classeurs, de modèles de documents et de gestes appris par imitation. Chaque chargé d’études avait sa version, et la méthode complète n’existait nulle part sous une forme exécutable.
Pourquoi le marché ne vendait pas cet outil
C’est la situation typique qui justifie un outil interne. Il existe des logiciels de géomarketing, et ils sont bons pour ce qu’ils font. Aucun ne fait ce que fait ce cabinet, parce que ce que fait ce cabinet est précisément sa façon à lui de travailler, c’est-à-dire son avantage concurrentiel.
Un éditeur ne modélise pas la méthode d’un cabinet de vingt personnes. Payer un abonnement pour un outil générique, puis recoller le reste à la main dans un tableur, revient à payer pour la moitié du problème.
Jusqu’à récemment, la réponse était qu’un développement sur mesure coûtait trop cher pour se justifier. Le coût de construction s’étant effondré, l’arbitrage a changé.
Construire à partir du geste, pas du cahier des charges
Le chantier n’a pas commencé par une spécification. Il a commencé en regardant des chargés d’études produire une étude réelle, étape par étape, en notant où ils perdaient du temps, où ils recopiaient, et où ils hésitaient parce que la méthode était ambiguë.
L’application a ensuite été construite par itérations courtes, avec l’assistance de l’intelligence artificielle générative pour écrire le code. Une version utilisable est arrivée en quelques semaines, et les évolutions se sont faites au rythme des retours d’usage, en jours plutôt qu’en versions trimestrielles.
Cette vitesse change la nature de la relation à l’outil. Quand une modification demande un trimestre, les utilisateurs cessent de demander et contournent. Quand elle arrive dans la semaine, ils signalent tout, et l’outil converge vers le métier réel.
Ce que l’outil a produit au-delà de l’outil
L’effet le plus durable n’était pas prévu. Pour écrire l’application, il a fallu rendre la méthode explicite : quelles données entrent, dans quel ordre, avec quelles règles d’arbitrage, et quelles conclusions sont défendables.
Ce travail de mise au clair a une valeur propre. Le savoir-faire cesse d’être une compétence individuelle transmise par compagnonnage pour devenir un actif de l’entreprise, qui se transmet, se discute et s’améliore. Une nouvelle recrue devient productive nettement plus vite, parce que la méthode est dans l’outil.
Ce qui fait mourir un outil interne, et comment on l’évite
Il faut être franc sur le risque. Un outil interne meurt rarement parce qu’il est mal conçu. Il meurt parce que personne ne le maintient, parce qu’il n’a pas de tests, parce qu’il n’est pas surveillé, et parce qu’une seule personne sait comment il fonctionne.
Ces quatre points font partie du chantier, sinon il ne vaut pas la peine d’être lancé. Le code est déposé dans un dépôt dont le client est propriétaire, l’hébergement est le sien, les traitements qui alimentent l’application sont surveillés, et la documentation d’exploitation est livrée avec.
Ce qui est transposable
La question à se poser n’est pas « pourrait-on développer cet outil », puisque la réponse est presque toujours oui. Elle est « notre façon de faire est-elle notre avantage ».
Quand la réponse est oui, construire se défend, parce qu’aucun éditeur ne modélisera un avantage qui n’appartient qu’à vous. Quand le besoin est standard et réglementé, comme la paie ou la comptabilité, acheter reste le bon choix et il n’y a aucune raison d’en discuter.
Le client final n’est pas nommé. Les chiffres cités sont ceux du chantier.