Proposition d'une API Gratuite et/ou d'un modèle utilisateur payeur

#1 BOBG

Bonjour, En tant qu'éditeur d'un logiciel immobilier, nous souhaitons permettre à nos utilisateurs de signer des documents. À ce jour, il existe de nombreux concurrents offrant des solutions gratuites, mais aucun ne propose d'API gratuit, et tous exigent que l'éditeur du logiciel paie le service de l'API et refacture ensuite ses clients (modèle partenaire payeur). L'avantage de ce modèle est qu'il est plus simple pour le service de certification, mais pas pour l'éditeur, surtout si celui-ci propose ses applications en Freeware, Freemium, ou Open Source. Cela revient à passer à côté d'un marché non négligeable. À l'inverse, dans le modèle où c'est l'utilisateur qui paie directement son service auprès du prestataire, l'éditeur du logiciel peut proposer cette fonctionnalité gratuitement. Il revient ensuite au prestataire de certification de faire ses offres (par exemple, en limitant le nombre de certifications). Ce modèle permet aux éditeurs d'intégrer une API sans coût supplémentaire, rendant ainsi l'intégration possible dans tous les logiciels gratuits, payants ou Open Source. C'est d'ailleurs le modèle choisi par un fournisseur de synchronisation bancaire belge : Ponto. Ce choix lui a permis d'être intégré, par exemple, à Odoo (5 millions d'utilisateurs) !!. Nous allons aussi intégrer Ponto pour la synchronisation bancaire en 2024 et pas leurs concurrents (:. Pour en revenir à Lex, intégrer une API minimale pour automatiser certaines tâches (éviter la saisie répétitive d'informations) en version gratuite ou payante (modèle client payeur) permettrait de se démarquer de la concurrence. Parvenir à attirer les développeurs et les éditeurs est, à mon avis, indispensable pour être intégré dans les applications de gestion. Bien cordialement,

#2 Administrateur

Bonjour,

Tout d’abord merci pour votre intérêt concernant Lex Community et vos réflexions quant au modèle d’une API gratuite et/ou d’un modèle utilisateur payeur.

Avant d’aborder le modèle économique, nous souhaitons d’abord rectifier votre information relative au fait qu’il existe de nombreux concurrents offrant des solutions gratuites. En effet, Lex Community est à notre connaissance la seule plateforme au monde qui offre la possibilité d’effectuer des signatures simples, avancées et qualifiées gratuitement.

Il est important pour nous d’effectuer cette rectification car la fourniture d’une API gratuite ou payante pour des signatures uniquement simples et qui ne concernent que des transactions de faible valeur n’a pas grand intérêt et donc la notion de business model ne peut se concevoir de manière identique.

Ensuite avec Lex Enterprise, notre solution payante, sans coût de mise en service et avec un modèle économique qui s’appuie uniquement sur un coût à la signature, le portail et l’API sont totalement gratuites et disponibles en marque blanche. Le client final, comme un éditeur ou un opérateur à grande échelle de la solution, peut créer autant de jetons d’API qu’il le souhaite. Dès l’acquisition d’un espace de signature (qu’on appelle tenant), y compris pour notre prix d’entrée (voir notre page tarifs), l’API est disponible.

Si vous êtes un éditeur et que vous souhaitez proposer votre logiciel métier à un client final, vous pouvez vendre votre connecteur gratuitement, si vous le souhaitez, et le client final ne paiera que ses consommations de signature. Votre seul investissement sera de vous équiper d’un tenant (que vous pourrez utiliser pour, entre autres choses, faire signer vos contrats de licence à vos clients 😉) et qui vous permettra d’acquérir très rapidement les compétences pour développer un connecteur performant. C’est ce qu’ont déjà expérimenté de nombreux partenaires éditeurs. Certains partenaires préfèrent vendre des packs de crédits de signature avec leur solution métier, mais rien ne les y oblige.

Merci encore pour votre contribution à laquelle nous espérons avoir répondu positivement. N’hésitez pas à nous contacter pour toute question.

Bien cordialement,
L’équipe Lex Community.

#3 BOBG

Bonjour, Merci pour votre réponse. J'avoue ne pas avoir tout compris. Il est clair que votre solution se démarque des autres (mais je l'ai trouvée par hasard). Il manque juste un minimum d'automatisation pour inciter les éditeurs et les développeurs à vous choisir plutôt que les concurrents. Pour nous, l'automatisation est indispensable. Je reformule ce que nous recherchons : 1 - Un service de signature un minimum automatisable afin que l'utilisateur ait le moins de ressaisies à faire. Par exemple, un envoi via un formulaire POST depuis notre site/application qui permet de tout pré-remplir. L'idéal serait d'avoir une API minimale pour communiquer avec vos services. 2 - Des tarifs attractifs : gratuit pour les petits utilisateurs (permet de tester) et payant pour les autres. 3 - Un modèle économique où l'utilisateur final paie votre service. Nous ne faisons qu'implémenter un protocole (comme l'envoi des emails en SMTP). Nous ne voulons pas nous compliquer la tâche avec la gestion d'un compte développeur spécifique ou autre. Nous avons plusieurs développeurs venant du monde Open Source et certains développent encore bénévolement (devinez pourquoi j'ai cité Odoo !). Un service sur ce modèle, sans tracas et avec une implémentation libre, est largement préféré dans le monde de l'Open Source. La version community répond à nos critères, sauf pour l'automatisation. Dommage. Nos clients vont du simple particulier avec quelques locations (qui fera peut-être 2/3 signatures de documents par an) jusqu'aux clients ayant plusieurs centaines de locations. Les tarifs de la version payante de Lex sont adaptés pour nos plus gros clients, mais pas pour les plus petits. N'oublions pas que les petits peuvent devenir moyens, voire très grands. Il ne faut pas les oublier. Merci.

#4 Administrateur

Bonsoir et merci pour votre message.
Voici quelques explications complémentaires en réponses à vos dernières questions.
1. Notre API est publique et documentée ici : https://sgs-demo-test01.sunnystamp.com/wm-docs/
2. Dans notre architecture, la segmentation des clients repose sur la notion de tenant. Il n'est pas possible de brider le nombre de signatures par utilisateurs, mais seulement par tenant. Par conséquent Lex Community est un tenant de Lex Enterprise, dont le client est "la communauté" qui n'est pas facturée des signatures qu'elle consomme. La seule manière de brider cette plateforme est justement d'interdire l'utilisation de l'API. A noter également que chaque utilisateur est cloisonné et ne voit pas les autres utilisateurs (seulement ses contacts qui lui sont propres), ce qui constitue un modèle de sécurité simple et robuste.
3. Le modèle économique que vous souhaitez mettre en place est tout à fait réalisable mais conditionné au fait que vous fassiez l'acquisition vous-mêmes d'un tenant. Ainsi vous gérez vos groupes, vos utilisateurs et vous pouvez ainsi décider d'en facturer certains (vos plus gros clients) et pas d'autres (vos plus petits clients). Lex Community est gratuite parce qu'il s'agit d'une contribution sociale de Lex Persona. Mais son coût d'exploitation est loin d'être négligeable. Vous pouvez faire de même si vous le souhaitez dans la proportion qui vous convient et qui serait compatible avec votre propre modèle économique. L'un de nos partenaires a commencé le développement d'un connecteur Lex Enterprise - Odoo sur cette base.
En espérant avoir répondu à vos attentes,
Bien cordialement,
L'équipe Lex Community.

   

#5 BOBG

Merci de votre réponse. Nous avons trouvé un autre prestataire mieux adapté à notre modèle économique. Nous intégrons leur API, et l'éditeur devient apporteur d'affaires, ce qui nous permet de toucher une rétrocommission. Cependant, nous avons négocié pour renoncer à cette rétrocommission afin d'offrir plusieurs signatures gratuites à nos utilisateurs ayant très peu de locations. Cela crée une situation gagnant-gagnant. Cette opération est neutre financièrement pour nous, ce qui correspond à un modèle commercial que nous apprécions. Je continue néanmoins à suivre votre évolution, car nous souhaitons implémenter deux prestataires pour pallier une éventuelle défaillance de l'un d'entre eux.