Comments on: Saas et B2B: rien ne sert d’innover sans compatibilité http://www.imctobitch.com/saas-et-b2b-rien-ne-sert-dinnover-sans-compatibilte/?utm_source=rss&utm_medium=rss&utm_campaign=saas-et-b2b-rien-ne-sert-dinnover-sans-compatibilte Random thoughts about my young CTO startup experience Thu, 17 Sep 2020 11:32:20 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: Thibaut Camberlin http://www.imctobitch.com/saas-et-b2b-rien-ne-sert-dinnover-sans-compatibilte/comment-page-1/#comment-197 Thibaut Camberlin Fri, 03 Aug 2012 09:06:34 +0000 http://www.imctobitch.com/?p=313#comment-197 Dans ma situation, le logiciel est Open Source, donc pour ce qui est du code standard la question ne se pose pas. Et comme la valeur est dans cette partie du logiciel, on ne met pas de protection particulière sur le code spécifique, voir même il est contribué. Dans ma situation, le logiciel est Open Source, donc pour ce qui est du code standard la question ne se pose pas. Et comme la valeur est dans cette partie du logiciel, on ne met pas de protection particulière sur le code spécifique, voir même il est contribué.

]]> By: Pierre Chapuis http://www.imctobitch.com/saas-et-b2b-rien-ne-sert-dinnover-sans-compatibilte/comment-page-1/#comment-188 Pierre Chapuis Thu, 26 Jul 2012 16:59:24 +0000 http://www.imctobitch.com/?p=313#comment-188 > Les modèles “on premise” compliquent encore plus la donne car il s’agit de rendre le produit également compatible avec les serveurs, OS et plus globalement l’IT du client. J'aimerais bien (plus par curiosité personnelle) des retours de gens qui ont fait ça (vendre une version "on premise" de soft SaaS). Entre autres, en général le soft est écrit dans un langage dynamique, comment protégez-vous le code source ? Je sais que GitHub par exemple se débrouille (débrouillait ?) pour le compiler en utilisant JRuby (https://speakerdeck.com/u/atmos/p/breaking-into-the-enterprise)... Idem si quelqu'un utilise le modèle intermédiaire qui consiste à vendre soit des "appliances" (ie. des machines physiques avec le soft pré-chargé) soit des "appliances virtuelles" dans le store d'Amazon AWS. > Les modèles “on premise” compliquent encore plus la donne car il s’agit de rendre le produit également compatible avec les serveurs, OS et plus globalement l’IT du client.

J’aimerais bien (plus par curiosité personnelle) des retours de gens qui ont fait ça (vendre une version “on premise” de soft SaaS). Entre autres, en général le soft est écrit dans un langage dynamique, comment protégez-vous le code source ? Je sais que GitHub par exemple se débrouille (débrouillait ?) pour le compiler en utilisant JRuby (https://speakerdeck.com/u/atmos/p/breaking-into-the-enterprise)…

Idem si quelqu’un utilise le modèle intermédiaire qui consiste à vendre soit des “appliances” (ie. des machines physiques avec le soft pré-chargé) soit des “appliances virtuelles” dans le store d’Amazon AWS.

]]> By: Thibaut Camberlin http://www.imctobitch.com/saas-et-b2b-rien-ne-sert-dinnover-sans-compatibilte/comment-page-1/#comment-187 Thibaut Camberlin Thu, 26 Jul 2012 12:45:52 +0000 http://www.imctobitch.com/?p=313#comment-187 Tout à fait d'accord, l'environnement BtoB est en ce sens beaucoup plus contraignant que le BtoC. Les application tiers, comme Ballon, par opposition aux applications métier pour lesquelles des MAJ du parc peuvent être exigées, doivent s'adapter. Sur cette même problématique, on peut également parler des comptes trop frileux pour aller en version Saas et qui exigent une solution hébergée sur leur infrastructure. Les modèles "on premise" compliquent encore plus la donne car il s'agit de rendre le produit également compatible avec les serveurs, OS et plus globalement l'IT du client. Pour l'éditeur, a fortiori une start-up aux moyens limités, il faut faire des choix et évaluer le bénéfice (gain en temps de développement) versus les pertes éventuelles (ventes non conclues pour cause de non compatibilité / compliance avec la policy du client). Cette logique sera valable jusqu'à ce que le gap technologique entre le monde de l'entreprise en celui du particulier soit comblé, c'est à dire pas tout se suite ! Tout à fait d’accord, l’environnement BtoB est en ce sens beaucoup plus contraignant que le BtoC. Les application tiers, comme Ballon, par opposition aux applications métier pour lesquelles des MAJ du parc peuvent être exigées, doivent s’adapter. Sur cette même problématique, on peut également parler des comptes trop frileux pour aller en version Saas et qui exigent une solution hébergée sur leur infrastructure. Les modèles “on premise” compliquent encore plus la donne car il s’agit de rendre le produit également compatible avec les serveurs, OS et plus globalement l’IT du client.
Pour l’éditeur, a fortiori une start-up aux moyens limités, il faut faire des choix et évaluer le bénéfice (gain en temps de développement) versus les pertes éventuelles (ventes non conclues pour cause de non compatibilité / compliance avec la policy du client). Cette logique sera valable jusqu’à ce que le gap technologique entre le monde de l’entreprise en celui du particulier soit comblé, c’est à dire pas tout se suite !

]]>