Pourquoi votre stack logiciel empire en grandissant
Vous avez commencé avec un CRM, un Slack et Google Drive. Puis sont venus un ERP, un outil de ticketing, un logiciel de paie, un ATS, un BI tool, un WMS... et soudain, vous gérez 47 applications qui ne se parlent pas.
C'est ce qu'on appelle l'entropy logicielle — et plus une entreprise grandit, plus elle accélère.
Chez KODY, on voit ce pattern chez presque tous nos clients : des boîtes qui ont commencé avec des solutions SaaS simples, et qui se retrouvent 5 ans plus tard avec un monstre technique dont personne ne maîtrise la cartographie complète.
L'illusion du "on prend un outil et c'est réglé"
Quand une startup démarre, elle choisit des outils prêts à l'emploi. C'est logique : il faut avancer vite, valider un marché, ne pas réinventer la roue.
Le problème, c'est que chaque nouvel outil résout un problème immédiat — et en crée deux à moyen terme :
| Étape | Action | Conséquence cachée |
|---|---|---|
| 10 employés | Slack + Gmail + Notion | ✅ Tout le monde communique |
| 30 employés | HubSpot CRM | ❌ Les ventes sont dans HubSpot, le support dans Intercom, les données ne matchent pas |
| 50 employés | QuickBooks | ❌ La compta ne parle pas au CRM qui ne parle pas au support |
| 80 employés | ERP Sage / Odoo | ❌ 6 mois de migration, des processus tordu pour coller au logiciel |
| 120 employés | Outil BI + Data warehouse | ❌ Le data warehouse doit nettoyer les incohérences entre tous les outils |
À chaque étape, on ajoute une couche. Et à chaque couche, on ajoute des intégrations, des scripts de synchronisation, des exports CSV à la main, et des process de contournement parce que le logiciel ne fait pas exactement ce dont l'équipe a besoin.
3 symptômes qui doivent vous alerter
1. La multiplication des "passe-plats"
Un commercial qui copie-colle des infos du CRM vers un Google Sheet pour que l'équipe compta puisse les traiter. Un responsable logistique qui exporte des données de l'ERP vers Excel pour faire son calcul de stock. Un CTO qui maintient 12 scripts Python qui sync des bases de données qui ne se parlent pas.
Chacun de ces "passe-plats" est :
- Un point de fragilité (si le collègue est en vacances, le process s'arrête)
- Une source d'erreur (fatigue, mauvaise manip)
- Un coût caché (X heures/semaine × Y personnes = poste plein temps)
2. Le shadow IT explose
Quand le logiciel officiel ne répond pas au besoin réel, les équipes contournent. Elles souscrivent à des outils SaaS avec leur carte bleue, créent des bases Airtable, utilisent des versions gratuites d'outils non approuvés.
Le shadow IT représenterait en moyenne 30 à 40% des dépenses logicielles dans les entreprises de plus de 100 employés.
Chaque outil non référencé est une porte ouverte sur un risque sécurité, une fuite de données, et une dette technique supplémentaire.
3. Le coût d'intégration dépasse le coût de la solution
C'est le piège classique : un logiciel coûte 200€/mois par utilisateur, mais son intégration avec le reste du SI coûte 50 000€ et prend 6 mois. Et après ? Il faut le maintenir.
Entre les API qui changent, les versions qui ne sont plus supportées, et les mises à jour qui cassent les connecteurs maison — maintenir ces intégrations devient un métier à plein temps.
Ce que le sur-mesure change
On ne va pas se mentir : le sur-mesure n'est pas la réponse à tout. Pour un besoin générique (email, visio, chat), un SaaS standard est parfait.
Mais pour les processus métier qui font votre avantage concurrentiel, le sur-mesure change la donne.
# Comparaison : ERP standard vs sur-mesure KODY
ERP standard:
- Avantages: Communauté, mises à jour automatiques, prix d'entrée bas
- Inconvénients: Processus imposés, intégrations complexes, rigidité
- TCO 3 ans: Souvent 2-3x le coût de licence en intégrations et contournements
Application sur-mesure:
- Avantages: Processus = votre métier, pas d'intégrations superflues, évolutif
- Inconvénients: Développement initial, maintenance internalisée ou confiée
- TCO 3 ans: Investissement initial plus élevé, mais coûts d'exploitation maîtrisés
L'architecture API-first
Chez KODY, quand on conçoit un logiciel sur-mesure pour un client, on suit un principe simple : l'API est le produit.
Concrètement :
- Brique métier : le cœur de l'application qui gère vos règles métier (devis, facturation, workflow)
- APIs REST/GraphQL : des endpoints propres que tous vos outils peuvent consommer
- UI headless : une interface React/Next.js qui n'est qu'un client parmi d'autres
// Exemple : une API métier qui centralise la logique
// au lieu d'avoir 3 outils qui gèrent la facturation chacun de leur côté
interface InvoiceService {
createInvoice(order: Order): Promise<Invoice>;
syncWithAccounting(invoice: Invoice): Promise<void>;
sendToCustomer(invoice: Invoice): Promise<void>;
archiveToStorage(invoice: Invoice): Promise<void>;
}
// Un seul endpoint. Tous les canaux (web, mobile, API tierce) l'appellent.
// Plus de duplication, plus de désynchro.
Cette approche permet :
- Un point de vérité unique — la donnée vit et est traitée à un seul endroit
- Des intégrations propres — chaque outil externe se branche sur l'API, pas sur un CSV
- Une évolutivité réelle — vous ajoutez un canal (mobile, portail client, partenaire) sans toucher au métier
Le piège du "on va tout mettre dans un seul ERP"
Certaines entreprises tentent de résoudre la complexité en faisant le chemin inverse : tout centraliser dans un ERP unique (SAP, Oracle, Odoo, Microsoft Dynamics).
C'est une solution — mais elle a son propre coût :
- Adaptation forcée : vous devez plier vos processus au moule de l'ERP
- Lock-in : changer d'ERP est un projet de 12 à 24 mois
- Suralimentation : vous payez pour des fonctionnalités que vous n'utiliserez jamais
- Lourdeur : les mises à jour et customisations deviennent des projets en soi
L'alternative hybride, qu'on voit de plus en plus chez nos clients : un socle sur-mesure pour le cœur métier, des SaaS spécialisés pour le reste, une API qui fait le lien.
Conclusion : la simplicité se construit
La complexité IT n'est pas une fatalité. C'est le résultat de décisions prises sous pression, une urgence après l'autre, sans vision d'ensemble.
La solution n'est pas d'acheter "le bon" logiciel — aucun ERP, aucun SaaS, aucun outil miracle ne supprimera la complexité de vos processus métier.
La solution, c'est :
- Identifier ce qui fait votre coeur métier (ce qui vous rend unique)
- Construire sur-mesure cette partie-là (API-first, headless)
- Connecter proprement des SaaS standards pour le reste
- Éliminer les doublons et les outils fantômes (shadow IT)
Chez KODY, on appelle ça l'architecture sobre — un SI où chaque brique a une raison d'être, où chaque intégration est utile, et où la complexité ne croît pas plus vite que l'entreprise.
Vous voulez auditer votre stack logiciel ? On le fait en 2 jours : cartographie de votre SI, identification des doublons, plan de réduction de la complexité. Parlons-en.

