*Ce guide a été écrit notamment grâce à la lecture du livre [Working in Public: The Making and Maintenance of Open Source Software](https://amzn.to/45iaEIx)*. L'objectif de cet article est de comprendre ce modèle de développement, de comprendre qui sont les gens qui le font fonctionner et quels sont les modèles économiques viables. ## Comment les logiciels open source sont ils produits ? Désormais, la norme pour un projet Open Source, c'est peu de développeurs qui font l'essentiel du travail et beaucoup de petits contributeurs qui vont et viennent. Sur Github, moins de 5% des développeurs sont responsables de 95% du code et des interactions sociales. L'idée rependue que "l'open source est une communauté de personnes qui collaborent" fait penser à beaucoup de mainteneurs solos que, s'ils sont seuls, c'est qu'un truc cloche... C'est faux. La plupart des développeurs open source interagissent faiblement avec des tiers qui n'ont de toutes façons que peu d’intérêt sur le long terme. De la même façon qu'il y a des influenceurs Instagram, des streamers sur Twitch, il y a désormais des développeurs sur Github. Et comme sur les autres plateformes, **la réputation d'un créateur est comme une batterie**, on suit un créateur, car on s'attend à du contenu. Si le créateur arrête de créer, ses fans vont s'ennuyer et partir. **Une réputation, comme un logiciel, nécessite de la maintenance**. Dans un projet, il y a trois grandes étapes: - **Création** : Tous les projets Open Source démarrent avec peu de développeurs, souvent une seule personne. La plupart du temps, avant la première version, le code est privé (et donc non partagé) ce qui permet de travailler sereinement avant de demander des retours. - **Évangélisation** : Une fois le projet "sorti", les développeurs ont généralement très envie d'avoir des retours, des demandes, des ajouts de code... le projet va être promu de la même façon que l'on fait la promotion d'une startup (Twitter, Reddit, Producthunt...). L'objectif à ce moment est d'avoir un maximum de développeurs qui utilisent le code produit. On va aussi souhaiter des contributions de code tout en gardant le contrôle de la direction du projet. - **Croissance** : Quand le projet grossit, les créateurs se retrouvent à faire moins de code et vont passer plus de temps à répondre aux questions, corriger des bugs, relire des contributions... Le problème : cela ne signifie absolument pas que le créateur du projet aura plus de contributions intéressantes au code ou que plus de gens vont l'aider à corriger les bugs. ## La vie d'un mainteneur **La création a une motivation intrinsèque, la maintenance a besoin d’une motivation extrinsèque.** [Harlan Mills](https://en.wikipedia.org/wiki/Harlan_Mills) suggérait d’organiser les développeurs comme une équipe de chirurgiens avec un “*chef programmeur*” qui se charge des spécifications et du design. Des “*copilotes*” qui seraient ses bras droits puis un nombre de personnes qui se chargent du reste (documentation, support, relecture…). Les projets centralisés sont centrés sur un petit groupe de mainteneurs qui jouent le rôle de chirurgiens avec des utilisateurs & contributeurs qui l’aident dans son travail. Bien qu’ils soient peu nombreux, ces mainteneurs sont aussi un goulot d’étranglement des contributions tierces, car ils doivent prendre des décisions, passer du temps à relire et constamment faire des arbitrages entre les demandes, besoins, souhaites et merge requests. Pour le mainteneur, le plus difficile à gérer aujourd’hui est le contributeur occasionnel. En effet, avec la standardisation provoquée par Github et l’accroissement exponentielle d’utilisateurs de composants open source, beaucoup de gens se sont mis à contribuer. Pour les mainteneurs de projets Open Source, cela se transforme en un flux qui peut les déborder, un peu comme des touristes débarquant dans une ville balnéaire. De plus, ces nombreuses contributions peuvent avoir des niveaux de qualité très différents ce qui peut complètement noyer le groupe de mainteneurs. Pour l’aider dans sa tâche, on trouve aussi ceux que l’on appelle les “*utilisateurs actifs*”, ce sont ces utilisateurs qui testent les nouvelles versions, répondent aux questions sur Discord, font des rapports de bugs et font un barrage efficace face avec utilisateurs actifs qui ne vont que consommer. Ils peuvent clairement réduire la charge de travail des mainteneurs. **Le problème des mainteneurs aujourd’hui est de gérer un volume important de petites interactions. Cela ressemble moins à la gestion d’une communauté qu’à la gestion d’un trafic aérien.** ## Est-ce que les logiciels sont des biens communs ? ### Qu'est-ce qu'un “bien commun” ? [Elinor Ostrom](https://fr.wikipedia.org/wiki/Elinor_Ostrom) a étudié longuement les conditions qui ont permis la gestion des “biens *communs*” comme les forêts, les systèmes d’irrigations, pêcheries… Elle a essayé d’expliquer comment éviter la “tragédie des communs” (Le cas où des ressources sont perdues parce que certaines personnes agissent par égoïsme au lieu de penser à la communauté). Elle en a déduit [8 principes](https://www.gillesenvrac.ca/carnet/2017/03/gestion-communs/) qui montrent le besoin d’un sentiment d’identité du groupe qui rend les processus de gouvernance (élaboration de règles, résolution de problèmes et sanctions) acceptable. On le voit par exemple dans les communautés en ligne, très rapidement, une norme culturelle se développe et permet de gérer les interactions dans ces groupes. ### Pourquoi nous participons aux biens communs ? [Yochai Benkler](https://fr.wikipedia.org/wiki/Yochai_Benkler) a utilisé le travail d’Elinor Ostrom pour l’appliquer au monde de l’open source. Il a notamment montré que le fait que des développeurs soient personnellement motivés par un projet réduit grandement les coûts de coordination du projet. Or dans les entreprises, ces coûts (rechercher, évaluer, recruter et manager des employés) représentent une part énorme des dépenses et concentrent souvent les difficultés. Pour que cela fonctionne, Benkler identifie trois éléments clés : - **Une motivation intrinsèque** : les membres d’un projet font le projet parce qu’ils ont envie de le faire. Dans le cadre de l’open source, les gens codent, car ils aiment coder. - **Des tâches modulaires et granulaires** : cela signifie que les tâches doivent être décomposables en petits morceaux. Comme le disait McIlroy : “*écrivez un programme qui ne fait qu’une seule tâche et la fait bien et écrivez des programmes qui travaillent ensemble*”. - **De faibles coûts de coordination** : il ne faut pas que les contributeurs passent trop de temps à former, relire du code ou faire des merge requests. Quand ces coûts dépassent les bénéfices, le projet s’effondre. La production de logiciels open source reposant sur la motivation intrinsèque, l’argent est souvent vu comme une motivation extrinsèque qui peut interférer avec un système de production déjà très opérationnel. ### Comment les plateformes ont brisé les communs ? Quand on pense aux biens communs, on imagine que chaque membre va se sentir une responsabilité de corriger ou d'améliorer les choses. Avec l’arrivée de Github, les projets Open Source se sont “standardisés” (git, issues, users, readme…) et Il est devenu beaucoup plus facile à n’importe qui de contribuer à un projet qu’il ne connaît pas. Et pourtant, aujourd’hui, la plupart des développeurs ont des interactions limitées entre eux, avec un contexte commun faible et peu d’investissement sur le long terme. Ceci va à l’encontre de la vision d’Ostrom mais c'est la réalité. ## Les types de projets Open Source On peut classer un projet open source selon quatre critères : - **La portée technique** : un projet qui semble avoir toutes les fonctionnalités requises attirera peu de nouveaux contributeurs. Il peut être très utilisé, mais il peut y avoir peu de choses à faire. *Par exemple : Webpack.* - **Le besoin de support** : le support consiste à répondre aux gens, traiter les demandes, relire le code des autres… Les contributeurs ont surtout envie d’écrire du code intéressant, pas de faire du triage de bugs. *Par exemple, Youtube-dl est un projet assez simple avec peu de code, mais il y a énormément de demande de support.* - **La facilité de participation** : quelle est la difficulté de contribuer à un projet pour un nouveau venu ? Est-ce un langage connu ? Est-ce bien documenté ? La communauté est-elle sympa ? les mainteneurs du projet sont ils disponibles ? - **Le nombre d’utilisateurs** : le potentiel de personnes qui pourraient être contributeurs ? Ceci est généralement une fonction du nombre de personnes qui pourraient utiliser l’application. À partir de là, on se retrouve avec quatre grands types de projets : - **Fédérations** : Ce sont des projets avec une croissance forte des utilisateurs et des contributeurs. On y trouve des projets comme Linux ou Rust. Ces projets ressemblent à des entreprises et sont complexes à gérer ce qui les pousse à mettre en place des votes, des groupes de travail, des fondations… - **Clubs** : Ce sont des projets avec une croissance forte des contributeurs, mais une croissance faible des utilisateurs. Astropy qui fournit des outils Python aux astronomes est un exemple. Ce projet va avoir peu d’utilisateurs, mais ceux-ci ont de bonnes chances de pouvoir être des contributeurs actifs. Ce sont un peu comme des associations. - **Jouets** : Ce sont des projets, souvent personnels, avec peu de croissances des contributeurs et des utilisateurs. On a par exemple SSH-Chat qui permet à des utilisateurs de discuter via SSH. - **Stades** : Ce sont des projets avec peu de croissance des contributeurs, mais une forte croissance des utilisateurs. Ils reçoivent bien quelques contributions, mais ce n’est rien comparé à la croissance des usages. On y trouve des projets comme Babel ou Webpack… Contrairement aux fédérations & clubs, le management est centralisé. Le futur des projets organisés autour communautés décentralisées (clubs & fédérations) réside dans le recrutement de nouveaux contributeurs et la réduction de la friction sur leur recrutement. Les projets centralisés, eux, doivent survivre avec moins de temps de contribution, les créateurs de ses projets essayent au maximum d’automatiser, de faire faire le support de base par la communauté et d’éliminer toute “distraction”. ## Les coûts d'un projet Open Source Les deux premières choses dont il faut se rappeler : - Un logiciel, une fois écrit, n'est jamais vraiment fini. Même si l'on vient à bout des fonctionnalités, il y a toujours une maintenance à faire. Fergus Henderson explique que chez Google, la plupart des logiciels sont régulièrement réécrits afin de les rendre plus simple et mieux réfléchi. Cela permet aussi de transférer les compétences. - Un logiciel, une fois qu'il a un certain nombre d'utilisateurs, ne disparaît jamais vraiment. Il peut continue de vivre très longtemps. Nous avons les exemples de Fortran, Cobol, NTP... Malgré ces deux points, nous avons tendance à croire que les logiciels ont un coût marginal très faible, que produire le logiciel coûte cher, mais que sa distribution ne coûte quasiment rien. C'est faux, nous allons voir ces coûts qui sont un peu invisibles ! ### Coûts marginaux Le logiciel a deux propriétés qui nous font croire à un coût marginal nul : - **Pas de rivalité** : si j'utilise un code téléchargé sur Github, je ne diminue pas la capacité d'une autre personne à utiliser ce même code pour ses propres besoins. - **Pas d'excluabilité** : si quelqu'un a une copie, elle peut la distribuer à qui elle veut. Ces deux propriétés ont tendance à faire penser que l'open source est un bien public, mais ce n'est pas tout à fait le cas. **De la même façon qu'ajouter des voitures sur une autoroute ne pose pas de problème jusqu'à ce qu'un embouteillage se crée, plus on a d'utilisateurs sur un logiciel, plus on va avoir de travail "divers" à réaliser qui vont finir par prendre beaucoup de temps.** ### Support utilisateur Quand un logiciel est peu utilisé, le coût du support est faible, mais cela peut vite changer. Dewitt Clinton de Google présentait le problème de la façon suivante : “*Si vous avez un milliard d’utilisateur que seul 0,1% ont besoin de contacter le support une fois tous les trois ans pendant 10 minutes, cela vous coûtera 19 années hommes chaque jour, soit à peu près 21 000 personnes*”. Le support des projets open source, ce ne sont pas que le traitement des tickets, mais aussi répondre aux questions “comment ?” et “pourquoi ?”. Ceci implique aussi de passer du temps à faire de la modération comme on peut avoir à le faire sur Discord. ### Maintenance Une étude de Stripe indique que les développeurs passent 48% de leur temps à maintenir du code. ### Refactoring Plus le temps passe, plus vous ajouter de code, plus la dette technique augmente. Et en acceptant des contributions qui peuvent avoir divers niveaux de qualité, on arrive parfois à un projet dont le code n’est pas uniforme. Le refactoring est justement ce processus qui permet de rembourser la dette technique mais il coûté très cher (notamment en revalidation). ### L’adaptation aux besoins utilisateurs Les besoins des utilisateurs vont aussi changer avec le temps, les mainteneurs vont devoir fournir un effort pour y coller sous peine de voir la réputation du projet baisser ou éventuellement voir le projet mourir. ## Création de valeur Il y a quelques années, pour installer Linux, il fallait que des gens investissent pour imprimer des CD et les distribuer puis il fallait que des utilisateurs payent pour y avoir accès. Désormais, avec Github, des millions de projets sont disponibles immédiatement et sans coût. Aujourd’hui, si vous voulez bâtir quelque chose, vous n’avez plus à refaire les éléments principaux (OS, base de données, serveur web, gestion des logs…), vous pouvez faire plus en écrivant moins de code. Cela a permis aussi aux utilisateurs d’accéder à des solutions moins chères. À une époque pas si lointaine, on devait même payer pour avoir un navigateur Internet. Ce coût marginal a donc énormément profité aux utilisateurs, mais les producteurs, eux, ont très peu gagné en valeur, tout au plus ont ils pu se bâtir une réputation. Pour gagner de l’argent, les producteurs de logiciels propriétaires, eux, font en sorte de supprimer les propriétés de non-rivalité et non-excluabilité de leur code en vendant, par exemple, des licences. On peut désormais de moins en moins vivre sans logiciel et pourtant personne ne veut payer pour une bonne partie des logiciels qui font fonctionner l’économie. Jane Jacobs fait un parallèle intéressant avec la façon dont on conçoit parfois les villes en pensant les parcs, routes, immeubles comme des objets statiques plutôt que des objets devant être maintenus et adaptés au fil du temps. Comme pour un logiciel, Jacob explique qu’une ville ne peut pas être parfaitement conçue en une fois, car la façon dont les gens utilisent leur environnement change en permanence. **On doit donc voir le code comme quelque chose de vivant, un artefact et un organisme**. Nous sommes face à une dualité : **le contenu digital ne vaut rien et il est pourtant indispensable à la société**. ### Dépendance  La valeur est aussi dépendante de qui utilise le code. Si mon code n’est utilisé par personne, il vaut moins qu’un code qui serait utilisé par des millions de serveurs. Dans un sens, le logiciel est comparable à une infrastructure publique. Comme le code, la valeur d’une infrastructure dépend de son utilisation et pas forcément de son coût ou de sa maintenance. C’est le cas par exemple d’une route qui peut être très utile, car très utilisé, même si c’est la route qui a coûté le moins cher à construire. En fait, on se trouve dans une situation connue comme la “*tragédie des communs*”. **Si un parc est libre d’accès, les gens l’utiliseront sans payer la maintenance qu’il nécessite. Plus il y a de gens qui vont utiliser ce parc, plus sa qualité va diminuer.** Pour résoudre ce problème, soit on fait payer l’entrée, soit ces biens sont fournis par l’état grâce aux impôts. L’état finance des parcs, car s’il ne le faisait pas, on peut se dire que personne ne le ferait. Imaginons que je tire un feu d’artifice depuis ma maison, mes voisins peuvent en profiter gratuitement et je ne peux pas les en empêcher. Par contre, à un moment, je pourrai en avoir marre de financer le feu d’artifice, organiser le show, etc… Imaginez en plus que les voisins comment à frapper à ma porte pour faire des demandes particulières, cela pourrait rapidement devenir une corvée. Il parait compliqué d’arriver à financer tout cela. Les gens aiment faire des choses et les partager. De plus, étant donné le nombre d’humains et cette facilité à produire des choses d’assez bonne qualité, on ne risque pas de manquer de contenus. Il y aura toujours quelqu’un pour produire gratuitement quelque chose que l’on apprécie. Mais il est très important de comprendre que le sentiment de fatigue et de lassitude des développeurs open source ne vient pas du fait que le code soit public, mais du fait que des gens essayent de participer à la production de celui-ci. Le code open source dans sa forme “statique” ressemble à un bien public, mais sa production ressemble surtout à un bien commun dont l’une des ressources, l’attention du mainteneur, est limitée. Si 20 personnes font la queue chez vous tous les jours pour vous parler de votre feu d’artifice, vous allez certainement arrêter de le tirer. Jonathan Zdziarski propose une vision intéressante : “*Il y a bien sûr une place pour les utilisateurs et leurs demandes, mais ce n’est pas dans la communauté à moins qu’ils contribuent au code. Les utilisateurs doivent être en dehors de cette communauté. Les amateurs de peinture ne sont pas assis à côté des peintres quand ils peignent, ils vont voir les œuvres au musée*”. On peut imaginer que tout le monde puisse consulter les listes de diffusion, les tickets, les forums… , mais pour aller plus loin, il faut être un des développeurs du projet : les utilisateurs peuvent consommer du code open source, mais ils ne doivent pas consommer l’attention des mainteneurs. ### Comment en tirer parti ? La récompense classique pour des créateurs de contenus est la réputation qui peut être convertie en audience. Tout l’intérêt étant de trouver des moyens de transformer cette attention en argent. Cependant, les développeurs les plus connus ne sont pas nécessairement les meilleurs contributeurs des meilleurs projets Open Source, mais plutôt les conférenciers, les Youtubeurs, les streamers, les “professeurs”… Twitch a rendu économiquement viable le fait de jouer au jeu vidéo. Github n’a pas réussi à faire la même chose pour les développeurs open source. ## Commercialisation Traditionnellement, l'Open Source était principalement développée autour de l'infrastructure d'entreprise, comme les bases de données et les systèmes d'exploitation. Aujourd'hui, le développement de l'open source se produit dans presque tous les secteurs - Fintech, commerce électronique, éducation, cybersécurité... Pendant des années, les entreprises qui proposaient de l'open source ont vécu grâce à la vente de service et de support. L'absence de revenu de "licence" en faisait des entreprises moins intéressantes que leur concurrent "propriétaire" et cela se ressentait dans les valorisations. L'arrivée du SaaS a permis aux entreprises d'utiliser (et de payer) des solutions open source exécutées dans le cloud sans se poser de questions sur la licence. Grâce à cette nouvelle façon de faire, la valeur des entreprises open source s'est rapprochée de celle des entreprises propriétaires, les clients sont prêts à payer les deux. ## Le cercle vertueux de l'open source L'open source permet : - De développer rapidement des solutions avec des développeurs motivés ayant peu de besoin de coordination. - D'avoir une adoption rapide et facilitée par la mise à disposition gratuite de la solution. - D'avoir une communauté de développeurs qui vont tester et corriger les bugs et lui permettre d'atteindre un certain niveau de qualité. Une fois ces étapes atteintes, il faut aller vers la commercialisation et les trois principales sources de revenus : - La vente de services et de support. - La vente de licences particulière (Open Source). - Le mode SaaS. ## Les trois piliers du succès Pour être un succès, votre projet open source doit passer par trois étapes : - **Project-community fit** : votre projet open source doit créer une communauté de développeurs qui contribuent activement à la base de code open source. Cela peut être mesuré par les étoiles GitHub, les commits ou la croissance des contributeurs. - **Product-market fit** : votre projet open source doit être utilisé par des clients. Cela peut être mesuré par le nombre de téléchargements, le nombre d'installations, le nombre d'utilisateurs actifs ou le nombre de clients. - **Value-market fit** : votre projet open source doit offrir quelque chose pour lesquels les clients sont prêts à payer. Cela peut être mesuré par le nombre de clients payants, le nombre de licences vendues ou le chiffre d'affaires. ### Project-community fit Les indicateurs principaux sont les étoiles GitHub, le nombre de collaborateurs et le nombre de pull requests. Ceci nécessite un engagement élevé (et sur la durée) du contributeur et une reconnaissance continue de la communauté des développeurs. Il faut combiner inclusion et affirmation, en somme, il faut pouvoir accepter les utilisateurs, les intégrer, mais il faut aussi très souvent savoir dire NON. ### Product-market fit Une fois que vous avez un leader et un groupe actif de collaborateurs, il faut passer au stade suivant : le product-market fit. Il faut répondre aux questions : - Quel est le problème que le logiciel open source aide à résoudre ? - Pour qui résout-il ce problème ? - Quelles sont les alternatives sur le marché ? Cette étape est nécessaire pour préparer l'engagement commercial ultérieur. Idéalement, les utilisateurs des solutions open source vont devenir des prospects pour les produits ou services à valeur ajoutée que vous allez vendre. ### Value-market fit La dernière étape, et souvent la plus difficile, consiste à trouver l'adéquation entre la valeur et le marché et à générer des revenus. Alors que l'adéquation entre le produit et le marché concerne fréquemment les utilisateurs individuels, l'adéquation entre la valeur et le marché se concentre généralement sur les acheteurs au niveau de l'entreprise. Le secret de l'adéquation entre la valeur et le marché est de se concentrer sur ce que les clients apprécient et sont prêts à payer, et non sur ce que vous pouvez monétiser. Souvent, l'adéquation entre la valeur et le marché est moins liée à ce que le produit fait qu'à la manière dont il est adopté et au type de valeur qu'il génère. La valeur fournie par les logiciels libres et open source ne se limite pas à sa fonctionnalité, mais également à ses avantages opérationnels et à ses fonctionnalités. Ainsi, lors de la réflexion sur une offre commerciale, certaines questions à prendre en compte sont les suivantes : - Votre produit résout-il un problème commercial central ou fournit-il des avantages opérationnels clairs ? - Est-il difficile à reproduire ou à trouver des alternatives ? - Y a-t-il des capacités à grande échelle requises pour les équipes ou les organisations qui ne sont pas réalisées dans les logiciels libres et open source ? Voici quelques exemples de valeur commerciale : - Fiabilité, disponibilité, sécurité. - Outillage, aide au développement. - Performance. - Audit. - Prestations de service. ## Les modèles de commercialisation ### Le modèle de support Le modèle de support est le modèle de commercialisation le plus ancien et le plus courant pour les entreprises de l'open source. Redhat est le plus ancien et le spécialiste de ce modèle. ### Le modèle Open core Le modèle open core consiste à proposer une version open source de base et une version payante avec des fonctionnalités supplémentaires. Certains composants (pour la sécurité par exemple) peuvent être gardés en version payante sans faire de mal au produit Open source. Le principal problème avec ce modèle est que votre base d'utilisateurs peut être insatisfaite de vos choix (et forker votre projet). ### Le modèle SaaS Vous proposez une version hébergée de votre solution. Cependant, les géants du cloud risquent de vous concurrencer en prenant votre code et en offrant une version hébergée. Rappelez-vous que vous avez trois avantages : - Les entreprises n'aiment pas le "vendor lock-in". - Les entreprises préfèrent acheter à ceux qui ont fait le code. - Vos concurrents n'ont pas votre expertise. ## L'open source comme en tête de l'entonnoir. Votre travail va consister à connecter les personnes qui utilisent votre logiciel open source (votre communauté) avec la valeur ajoutée de ce que vous vendez. ### Sensibilisation et intérêt - Gestion de la communauté des développeurs La première étape consiste à sensibiliser les développeurs à votre projet. Le fondateur doit agir comme un évangéliste. Quand l'entreprise va grossir, avoir une équipe qui soit à la fois douée en technique et en communication, est nécessaire. Quand vous aurez repéré ces développeurs à la fois techniques et communicants, envoyez les aux conférences, faites les participer sur les réseaux sociaux afin qu'ils expliquent votre projet et sa valeur. Ils ne doivent pas "vendre" au risque de perdre leur crédibilité, ils doivent générer de l'intérêt. ### Considération - Gestion du produit L'étape suivante est la considération. Vous devez maintenant maximiser le nombre de développeurs et d'utilisateurs qui utilisent et aiment votre produit. Une gestion de produit efficace s'occupera de : - Gérer les feuilles de route du projet open source et de sa version closed source. - De communiquer les décisions à vos développeurs et utilisateurs. - D'intégrer des outils d'analyses dans le produit pour collecter davantage d'informations sur les modèles d'utilisation et ainsi prévoir les opportunités de vente. Les entreprises et les fondateurs les plus prospères disposent de lignes directrices claires qui les aident à délimiter et à communiquer ce qui sera payé et ce qui sera gratuit. ### Évaluation et intention - Génération de prospects et développement commercial La prochaine étape consiste à convertir les utilisateurs en clients. Votre marketing sortant doit donner la priorité aux campagnes axées sur des segments de marché spécifiques, sur la base de modèles que vous aurez compris grâce à l'évangélisation des développeurs. En prêtant attention à vos utilisateurs open source, vous apprendrez quels rôles et départements utilisent le produit et quels sont leurs intérêts. Vient ensuite un effort de développement des ventes. Les vendeurs doivent adopter une approche axée sur le succès client plutôt qu'une approche trop commerciale et être insatiablement curieux des besoins de vos utilisateurs et de ce qu'ils font avec le produit. ### Achat et expansion - Ventes internes et sur le terrain Une fois que vous avez des prospects qualifiés, vous pouvez avoir deux façons de vente à l'entreprise : - En **libre-service** : les utilisateurs au sein de l'entreprise adoptent et paient un produit de manière organique. Généralement, ce produit sera destiné aux particuliers. - En **vente-service** (top down) : on conclut des affaires au niveau du service de l'entreprise ou étendre l'utilisation dans toute l'entreprise.