Anatomie d'une suite logicielle née dans un cabinet de courtage

On imagine souvent qu'un logiciel métier naît dans une entreprise de logiciel. Le nôtre est né ailleurs : dans les bureaux d'un groupe de courtage en assurance, au milieu des contrats, des sinistres et des appels clients. Ce détail d'origine change presque tout, et c'est l'histoire que je veux raconter ici.

Au départ, il n'y avait pas de produit. Il y avait un problème. Nos équipes passaient un temps considérable à des tâches que personne n'aime : retrouver le bon document, ressaisir une information déjà connue, trier une boîte mail qui déborde, reconstituer l'historique d'un client éparpillé entre plusieurs outils. Aucun éditeur du marché ne répondait précisément à notre manière de travailler. Les solutions généralistes traitaient le courtage comme un cas particulier de la relation client, alors que le métier est fait de détails réglementaires et opérationnels qui n'entrent dans aucune case standard.

Nous avons donc construit. D'abord un CRM pensé pour le courtage — ce qui deviendra BrokerCRM. Pas un CRM générique qu'on adapte, mais un outil qui parle nativement de contrats, de garanties, d'échéances, de devoir de conseil. Vingt-neuf versions plus tard, je mesure le chemin : chaque release a été dictée par un usage réel, remontée par des gens qui s'en servaient le jour même. C'est un luxe rare en édition logicielle, et c'est aussi une exigence permanente.

Autour du CRM, d'autres briques sont apparues, chacune pour résoudre une douleur précise. BrokerAI, pour assister le courtier dans ses tâches d'analyse et de rédaction. Le Classifier, pour trier automatiquement le flux entrant d'emails, qui est sans doute la charge invisible la plus lourde d'un cabinet. AudioPlateforme, pour transformer un patrimoine de plus de cent mille documents en mémoire réellement exploitable. Aucune de ces briques n'a été décidée dans un comité produit hors-sol : toutes répondent à un irritant que nous vivions nous-mêmes.

Cette position d'utilisateur-éditeur a un revers, qu'il serait malhonnête de taire. On a tendance à construire pour soi, à confondre son propre cas avec une généralité, à empiler des fonctions parce qu'un collègue les a réclamées un mardi matin. Le risque permanent, c'est le logiciel qui colle si bien à une organisation qu'il devient intransmissible. Une grande partie de notre travail des derniers mois a justement consisté à distinguer ce qui relève du métier du courtage — donc transposable — de ce qui relève de nos habitudes — donc à laisser de côté.

Mais l'avantage est considérable, et je l'assume pleinement : nous ne supposons pas les besoins, nous les vivons. Quand une obligation réglementaire évolue, nous la subissons en même temps que nos clients potentiels, pas six mois plus tard à travers un cahier des charges. Quand une fonction est mal pensée, c'est nous qui perdons du temps en premier. Ce raccourci entre le problème et la correction est, je crois, ce qui donne à la suite sa cohérence.

Aujourd'hui, ces briques forment un ensemble : BrokerCRM, BrokerAI, le Classifier, AudioPlateforme, et une capacité de développement et d'intégration sur mesure. C'est cet ensemble que nous structurons sous le nom de Lapi Tech. Pas pour faire de la technologie un argument marketing, mais parce que ce patrimoine a une valeur propre, distincte de l'activité de courtage qui l'a fait naître.

Je continuerai à raconter cette trajectoire ici, sans la lisser. Les bonnes décisions comme les détours. Parce que je crois qu'on apprend davantage d'une histoire vraie que d'une démonstration parfaite.