Le logiciel d'entreprise a un problème de coût qui frappe le plus durement les entreprises moyennes : chaque secteur se croit unique, donc chaque secteur paie pour reconstruire les mêmes modules avec des étiquettes différentes. Un moteur de facturation, un référentiel documentaire, un système d'agenda et un flux d'approbation sont identiques à 80 %, qu'ils servent un cabinet d'avocats, une agence maritime ou un entrepôt de distribution. Les 20 % restants — la logique métier — sont là où vit vraiment le secteur. Tout notre portefeuille est construit en prenant ce ratio au sérieux.
Le châssis partagé
Nous maintenons un châssis modulaire — authentification, gestion documentaire, agenda, notifications, reporting, facturation — et le déployons sur quatre verticales : opérations maritimes, pratique juridique, logistique et back-office commercial. Chaque verticale reçoit les 20 % qui la rendent unique : catalogues de conformité pour le maritime, flux de dossiers pour le juridique, tournées pour la logistique. Notre Enterprise Portal public et la galerie de démos sont la surface visible de cela : des produits distincts, une architecture en dessous.
Ce que le client gagne réellement
- Compression des coûts. Un module amorti sur quatre secteurs coûte à chaque client une fraction du développement sur mesure. C'est la différence entre un « logiciel d'entreprise » accessible à une société de 50 personnes ou réservé à une multinationale.
- Maturité par héritage. Quand le module documentaire gagne une piste d'audit parce qu'un client maritime en avait besoin pour ses inspections, la verticale juridique en hérite au cycle suivant. L'exigence la plus dure de chaque secteur élève le plancher des autres.
- Un correctif, tous les déploiements. Une vulnérabilité corrigée dans le châssis est corrigée partout. Comparez avec le modèle d'agence, où chaque build sur mesure dérive vers son propre dialecte non corrigé.
La discipline que cela exige
La modularité échoue quand elle n'est qu'un slogan. Trois règles la gardent réelle chez nous :
1. Le châssis ne contient jamais de logique métier
Dès qu'un « si maritime, alors… » apparaît dans un module partagé, vous n'avez plus une plateforme ; vous avez quatre codebases dans un trench-coat. Les règles métier vivent dans des couches par verticale et des catalogues de configuration.
2. Des niveaux, pas des builds sur mesure
Nous structurons l'offre en niveaux — outils personnels, espace de travail numérique, ERP industriel — pour qu'un client grandisse en activant des modules, pas en commandant des réécritures. Le chemin de montée en gamme, c'est la configuration.
3. Diverger est une décision, pas un accident
Parfois une verticale a réellement besoin de bifurquer un module. C'est permis — comme décision d'architecture consignée et avec un responsable, pas comme une dérive de mardi après-midi. La divergence non gérée est la mort silencieuse des plateformes.
Pourquoi cela compte spécifiquement en Amérique latine
Le marché intermédiaire latino-américain est chroniquement mal servi : trop complexe pour fonctionner au tableur et à WhatsApp, hors de portée des suites ERP mondiales et de leurs armées d'intégrateurs. L'architecture modulaire est ce qui rend viable la voie médiane — un logiciel de niveau industriel à une structure de coûts régionale, dans la langue du client et construit autour de la réglementation régionale.
À retenir
- La plupart des logiciels « sectoriels » sont à 80 % des modules génériques et à 20 % de la logique métier.
- Amortir les 80 % entre secteurs rend le logiciel d'entreprise accessible au marché intermédiaire.
- Le châssis doit rester sans logique métier ; la divergence doit être une décision consignée.
- Chaque verticale hérite des exigences les plus dures de ses sœurs.
Vous travaillez dans un secteur réglementé et vous vous débattez avec les problèmes décrits ici ? Nous construisons des logiciels exactement pour cela.
Parler à PBS