Camille , Un peu de provoque ;). Comme on fait du SaaS, Ben on fabrique ses services internes soit même
Avec Météor et 2 fichiers javascript tu te fais un chat.
Idem pour un éditeur collaboratif basic et du partage de fichier et tout le toutim
En fait tout les services payant cités vivent royalement sur le dos de petits gars paresseux, ou pressés.
Plus sérieusement vous croyez que google utilise un service externe pour faire tourner ses algorithmes, ou qu’un site de data mining se contenterai d’utiliser les données de google trend et l’api tweeter.
Il me semble que quand on veut quelque chose on s’en donne les moyens, avec tous le code libre existant on est parfois surpris de ce que l’on peux faire en peu de temps .
mon avis sur la question, pour faire simple : externalise ce qui n’est pas le coeur de ton activité.
Il s’agit pas de gars paresseux, mais qui ont compris que plus tu passes de temps à faire des choses non critiques moins t’as de temps à passer vraiment sur ton business
pour google, son algorithme est le coeur de son activité donc en effet ils n’ont pas intérêt à externaliser ça.
Moui, tu provoques mais tu convaincs pas vraiment.
Il est toujours possible de tout développer soi-même, de réinventer la roue, d’aller chercher des terres rares en Chine et de construire des ordinateurs dans son garage pour sa startup, etc. etc. parce que pourquoi s’arrêter en si bon chemin ?
La question est purement économique : qu’est-ce qui coûte le plus cher ? Utiliser la version gratos de Slack, ou développer un truc de chat qui aura 1/10ème des fonctions, qui va prendre 1 heure… puis 1 heure, puis 2, puis 3 quand je dois ajouter des fonctions, corriger des bugs, ah tiens il faut mettre en place un serveur, etc., tout ça fait par un développeur que je paie pour faire autre chose ?
Il y a des situations où développer une tech au lieu de l’acheter est envisageable (principalement lorsque le besoin n’est pas satisfait par les offres du marché), mais pour la plupart des outils, si vous en êtes à vous poser la question de l’impact sur vos bénéfices, vous avez de plus sérieux problèmes avec votre startup.
La comparaison avec les agriculteurs est pas très réaliste, compte tenu des marges énormes des entreprises tech vs. l’agriculture.
Yep Tommy on est d’accord sur le cœur de l’activité, mais Camille demande je cite « les services utilisés en interne par l’équipe ;) » et là il me semble on est en plein au cœur de l’activité.
Une image demande à un artisan si il loue ses outils, non dans certain cas il vont même jusqu’à les fabriquer à leur main. Avec les technos dont on dispose faire un chat interne prend aller, une heure.
A choisir entre paypal ou stripe et un simple module de paiement CB tu conseilles quoi. On observe le même biais que dans la grande distribution, on multiplie les intermédiaires et à la fin on gagne plus rien ;), parce que le client n’est plus prés à payer tes services externalisés. voir les agriculteurs (engrais semences pesticides abattoir).
Je sais ça fait pas très startup mais j’aime bien les comparaisons pour anticiper ce qui risque d’arriver.
Pour revenir au petit monde des startups, les métrics par exemple sont le cœur de toute activité et se contenter de google analytics et d’un tunnel de conversion, revient à travailler avec dix ans de retard il me semble.
Pour moi, ça fait aucun sens de les développer, sauf s’il y a un besoin spécifique au business et que ça n’existe pas sur le marché (et c’est très rarement le cas).
Par contre héberger un service open source, oui pourquoi pas, mais attention aux coûts cachés liés aux mises à jour, aux sauvegardes, etc.
Une bonne liste de services libres a héberger soit même :
On s’est pas compris sur le “coeur de l’activité”, j’ai du mal m’exprimer.
Il s’agit de ce qui est directement aligné avec ta proposition de valeur (ex. l’algorithme de google fait qu’ils ont des meilleurs résultats que tout le monde et donc bien sûr ils doivent bosser dessus et pas l’externaliser).
Le chat dans une équipe, oui on y passe du temps dedans (ce que tu as compris par “coeur de l’activité”) mais ce n’est pas ce qui fait que tes clients achètent ton produit. Si l’outil remplit 90% de tes besoins sans plomber tes finances (et sinon, c’est que tu as d’autres soucis plus importants dans ta startup) pas besoin de réinventer la roue, comme le dit très bien @davidoudiette .
Sinon, pour ce qui est des metrics, là aussi, réutilise ce qui existe déjà. Je rencontre pas mal de boites qui ont commencé par faire leur propre système d’analytics maison et se rendent compte qu’ils arrivent pas à en tirer suffisamment d’insights et veulent finalement migrer vers un produit commercial analytics. Au final, beaucoup de temps et d’argent dépensé à faire qqch qui aurait pu se faire plus simplement.
Personnellement, je pense qu’il n’est pas intéressant de créer quelque chose si il existe déjà et propose une solution intéressante.
Ne pas réinventer la roue est important, car le faire fait parfois perdre du temps. Il existe beaucoup de solutions digne d’intérêt.
Certes il existe beaucoup d’outils entre autres sous licence Open Source, de librairies et autres exemples ou tutoriels.
Donc c’est vrai qu’il est facile de développer quelque chose d’utile en très peu de temps, avec les bons outils aussi…
Beaucoup de gens pensent que développer (écrire) du logiciel est finalement quelque chose de simple mais, en fait ça ne l’est pas surtout pour en faire quelque chose de productif dans le cadre d’une utilisation industriel.
A cela plusieurs raisons :
Concevoir une solution nécessite de multiples compétences aujourd’hui : fonctionnelle, codage, intégration, ergonomie, tests, marketing, … ;
L’application/le logiciel doivent être testé, car les utilisateurs sont de plus en plus exigeants et connaisseurs. Une anomalie peu vite faire beaucoup de mal a une solution. Prenons ainsi l’exemple de McAffee qui à perdu beaucoup de client il y a quelques années après les avoirs dédommagés au passage. Sont antivirus considérant une librairie système comme un faux-positif après une mise à jour ;
La métier d’éditeur deviens de plus en plus un métier industriel mais, il reste encore beaucoup à faire, pour industrialiser l’ensemble du processus de production. Toutefois, petit à petit on y viens ;
…
Alors développer des outils, utilitaires… pourquoi pas beaucoup savent le faire mais gare aux erreurs.
Prenons l’exemple de Numéricable qui viens d’être pointé du doigt parque ce que leur outil interne faisant le lien entre l’adresse IP attribué et l’abonné, avait un « bug ». C’est à méditer.
Par rapport à l’image de l’artisan, ça met en évidence une chose également : la qualité des outils. Exemple : ton artisan qui fabrique ou achète ses outils, il a un certain temps et un certain budget à affecter à ses outils (et en général cet investissement n’est pas négligeable lorsque l’on parle d’outils professionnels !). Maintenant, imagine qu’on propose à ton artisan, une version « premium » de ses outils : plus agréables à utiliser, plus efficaces, ils lui font gagner du temps, et en plus lui apportent une qualité de fabrication plus élevée, seulement on lui propose contre un loyer de 20 euros par mois. Tu es cet artisan : tu fais quoi ?
Et par expérience, ce qui fail le coût d’un SaaS (maison ou pro) c’est la production, le support et la maintenance (corrective et évolutive), pas le développement initial.
Meteor te fait un chat en 2 fichiers, certes. Mais ensuite déployer l’appli va prendre du temps (quel serveur? comment?). Puis surveiller qu’elle tourne bien, la relancer quand elle crashe. Lire des blogs sur internet puis affiner tes fichiers de configuration pour qu’elle se plante moins souvent. Ajouter une fonction de partage de fichiers (par exemple). Gérer les versions, le stockage. Expliquer le fonctionnement aux autres utilisateurs. Et… bref, la vie d’une app.
Moi, c’est ça que je paye quand je paye un SaaS, pas l’écriture du code du prototype
Je pars du principe qu’il faut externaliser tout ce qui n’est pas notre coeur de métier. Faire un tchat d’équipe avec Meteor est effectivement simple mais pourquoi s’embêter alors que Slack et gratuit et que tout un tas de développeurs crées des outils que nous n’avons qu’à utiliser ? En plus ces outils sont beaucoup plus évolués que ceux que nous pourrions développer nous-même, ils sont documentés, maintenus etc.
Avant je voulais maitriser toute la chaine et développer mes petites applications (CRM, outil de gestion de projet etc.) mais ceci prend du temps, du temps sur mon activité principale, je préfère donc utiliser un service externe. De plus, comme l’a souligné @xavierpriour, une fois l’application développée ce n’est pas terminé : il faut la déployer sur un serveur, la maintenir, la faire évoluer, maintenir le serveur etc.
