La défendabilité mesure à quel point il est difficile pour un concurrent de te prendre tes clients une fois qu'ils décident d'essayer. Tu la mesures par ce que l'attaquant doit dépenser : argent, temps, ou accès qu'il ne peut pas acheter. Un produit que n'importe quel développeur peut reconstruire en trois semaines a une faible défendabilité, aussi bon soit-il en apparence.
Défendabilité et moat décrivent une même idée sous deux angles. Un moat est la structure. La défendabilité est la difficulté pratique que rencontre un concurrent lorsqu'il tente d'arracher un client précis. Tu la testes client par client, pas marché par marché.
Un exemple. Tu vends un logiciel de comptabilité à 900 petites entreprises, et chaque compte contient trois années de transactions catégorisées. Changer de fournisseur signifie exporter, réimporter et revérifier cet historique. Prévois huit heures de travail d'un comptable à 65 euros de l'heure, et le changement coûte à ce client 520 euros. Un concurrent facturant 29 euros par mois devrait offrir environ 18 mois gratuits rien que pour couvrir ce coût, parce que 18 fois 29 font 522 euros. Voilà une défendabilité que tu peux chiffrer.
Les sources incluent des données qui n'existent que parce que le client a utilisé ton produit, des intégrations dans des systèmes dont il dépend, des contrats, des agréments réglementaires, et une distribution à laquelle un concurrent ne peut pas acheter l'accès.
Le malentendu consiste à assimiler défendabilité et secret. Cacher ton code protège peu, parce que les concurrents copient le produit visible, pas l'implémentation. Un second malentendu porte sur le moment : de nombreux fondateurs écrivent sur la défendabilité comme si elle existait déjà au lancement. Le jour un, presque rien n'est défendable.
Le plan généré par Foundor aborde la défendabilité dans la section concurrence. La réponse qui tient la route est précise : nomme ce qui s'accumule dans ton entreprise avec le temps, et ce qu'un concurrent devrait dépenser pour te rattraper.
