Le modèle SaaSS : libre, accessible et sans dépendance

SaaSS : le meilleur du SaaS, sans les contraintes

Nous avons choisi l’acronyme SaaSS (Software as a Self Service) pour définir notre modèle de diffusion et d’exploitation de notre plateforme.

Avec notre écosystème, c’est un peu comme chez Flunch : en fonction de vos besoins, de vos compétences et de vos envies, vous choisissez les services que vous souhaitez utiliser et la manière dont vous souhaitez les exploiter. Vous pouvez ainsi utiliser l’intégralité de notre plateforme en mode SaaS, ou décider d’en exploiter vous-même une partie, voire la totalité, en hébergeant nos microservices sur votre propre infrastructure.

Mais derrière ce modèle se cache une conviction plus profonde : la simplicité d’utilisation ne doit jamais se faire au détriment de la liberté de nos utilisateurs.

Un néophyte pourra exploiter l’intégralité de la plateforme en mode SaaS pour créer un site statique ou publier des pages promotionnelles, sans avoir à se soucier des considérations techniques. Il bénéficie ainsi d’une solution clé en main, sans administration de serveur ni maintenance des différents composants.

Pour les profils plus techniques, les besoins peuvent être différents. Ils peuvent souhaiter conserver une partie de notre infrastructure en mode SaaS, tout en hébergeant eux-mêmes certains microservices pour répondre à des contraintes particulières.

Et si un projet nécessite des fonctionnalités ou des capacités qui ne sont pas adaptées à nos offres commerciales, il reste possible de déployer un ou plusieurs de nos microservices, distribués sous licence libre, sur sa propre infrastructure.

Ce n’est pas une possibilité théorique : nos microservices sont diffusés sous licence libre, afin que chacun puisse les utiliser et les adapter à ses besoins, dans le respect des conditions de leur licence.

Nous ne souhaitons pas imposer une manière unique d’utiliser notre écosystème. Vous êtes libre de choisir le niveau d’autonomie qui vous convient.

Imaginons un projet qui nécessite l’envoi d’un très grand nombre de courriels. Plutôt que d’utiliser une offre mutualisée qui ne serait pas adaptée à ses besoins, le porteur du projet pourrait choisir d’administrer sa propre instance de Yama Database et de la connecter au fournisseur de son choix (Brevo, Mailjet, etc.). Il conserve ainsi la maîtrise de son infrastructure et peut choisir librement son prestataire, ses tarifs et ses modalités d’envoi.

Autre exemple : une agence web souhaite proposer à ses clients une offre complète comprenant l’hébergement, le support technique et la gestion des contenus. Elle souhaite également maîtriser précisément ses coûts et sa marge. Elle peut alors choisir d’héberger l’ensemble des microservices nécessaires au fonctionnement de notre écosystème. Elle bénéficie ainsi de nos outils sans avoir à souscrire à nos offres d’hébergement et sans nous reverser de redevance pour leur utilisation.

Bien entendu, cela implique de prendre en charge l’infrastructure, son administration, sa maintenance et son évolution. Mais pour une agence qui dispose déjà des compétences et des ressources nécessaires, cette approche peut être particulièrement intéressante.

Pourquoi nous faisons le choix de l’ouverture ?

La question est légitime. Pourquoi permettre à des entreprises d’exploiter notre solution sans nécessairement générer de revenus directs pour Yama ? Nous y voyons plusieurs avantages.

Premièrement, favoriser l’adoption de notre écosystème.

Plus nos microservices sont utilisés, plus notre écosystème gagne en visibilité. Nous préférons voir nos outils adoptés par le plus grand nombre, y compris par des structures qui choisissent de les héberger elles-mêmes, plutôt que de réserver leur utilisation à nos seuls clients.

Deuxièmement, encourager les contributions.

Nous pouvons imaginer que certaines agences rencontrent des besoins auxquels nos logiciels ne répondent pas encore. Elles peuvent alors proposer des évolutions, corriger des problèmes ou développer de nouvelles fonctionnalités, puis en faire bénéficier l’ensemble de la communauté.

C’est aussi l’un des intérêts du logiciel libre : permettre à chacun de participer à l’amélioration des outils qu’il utilise.

Enfin, promouvoir une autre manière de concevoir le web.

Notre ambition dépasse la simple diffusion de nos logiciels. Nous souhaitons avant tout favoriser l’adoption des sites statiques, qui constituent selon nous une approche particulièrement pertinente pour construire une vision moderne du web.

Et concrètement, combien cela nous coûte ?

Nous n’allons pas vous mentir : héberger quelques projets supplémentaires qui ne génèrent pas de revenus directs représente un coût marginal lorsque l’essentiel de la charge d’exploitation est pris en charge par l’infrastructure de nos partenaires.

Dans le cas d’une agence qui héberge elle-même les microservices, nous conservons uniquement les éventuelles opérations qui restent nécessaires au fonctionnement du cœur de l’écosystème. Et celles-ci sont relativement légères : quelques fichiers de configuration et de contenu à gérer, des dépôts Git à consulter et des échanges avec les différents services.

Ce n’est évidemment pas totalement gratuit pour nous, mais le coût reste très limité au regard des bénéfices potentiels en matière d’adoption, de visibilité et de contributions.

Et pour les partenaires qui préfèrent le SaaS ?

L’auto-hébergement n’est évidemment pas une obligation. Nous proposons également une offre partenaire spécialement conçue pour les agences et les professionnels qui souhaitent commercialiser nos solutions auprès de leurs propres clients.

Cette offre bénéficie de tarifs préférentiels afin de leur permettre de conserver une marge sur les prestations qu’ils proposent. Les tarifs sont également dégressifs en fonction du nombre de sites souscrits.

Chacun peut donc choisir le modèle qui lui convient : gérer lui-même son infrastructure ou s’appuyer sur la nôtre.

Pas de dépendance artificielle : vos contenus vous appartiennent

Au-delà de la possibilité d’auto-héberger nos microservices, nous avons fait un autre choix important : ne pas enfermer nos utilisateurs dans Yama CMS.

Nous ne voulons pas que la pérennité de votre site internet dépende de notre existence, de nos tarifs ou de nos décisions commerciales. C’est pourquoi nous avons conçu Yama CMS comme une solution agnostique, indépendante du générateur de sites statiques utilisé. Vous pouvez travailler avec Astro, Hugo, Next.js, Nuxt, 11ty ou tout autre générateur.

Nous nous appuyons également sur des formats et des standards ouverts pour stocker les contenus :

• Markdown pour les pages et les contenus éditoriaux.
• JSON Schema pour décrire et valider les structures de données.

Ces choix ne sont pas anodins. Ils permettent de ne pas enfermer vos contenus dans un format propriétaire ou dans une technologie que nous serions les seuls à comprendre. Concrètement, si vous décidez un jour de quitter Yama CMS, vous pouvez récupérer vos contenus, reconstruire votre site et l’héberger chez le prestataire de votre choix. Vous n’avez pas besoin de notre autorisation. Vous n’avez pas besoin de négocier une migration. Et surtout, vous ne perdez pas le travail réalisé pendant toutes ces années.

Nous voulons que vous choisissiez de rester chez nous parce que notre solution vous convient, et non parce que vous n’avez pas d’autre possibilité.

Une question de souveraineté numérique

La liberté ne se limite pas au choix des logiciels. Elle concerne également la maîtrise de l’infrastructure qui les héberge et des acteurs qui interviennent dans leur fonctionnement.

Nous avons fait le choix de développer et d’héberger nos solutions en France. Ce choix participe à notre volonté de contribuer à une plus grande souveraineté numérique. Nous souhaitons proposer une alternative française aux plateformes étrangères, en gardant la maîtrise de nos développements et de notre infrastructure.

Cela ne signifie pas que tous les composants logiciels utilisés sont nécessairement français, ni que l’ensemble des dépendances techniques disparaît. Mais cela signifie que le développement de notre écosystème et l’exploitation de nos services sont réalisés depuis la France, avec une volonté de limiter autant que possible les dépendances inutiles.

Nous pensons qu’il est important de pouvoir disposer d’outils numériques conçus, développés et hébergés localement, sans pour autant renoncer à la qualité, à la modernité ou à la simplicité d’utilisation.

La souveraineté numérique ne devrait pas être réservée aux grandes organisations disposant de leurs propres équipes informatiques. Les petites entreprises, les associations, les indépendants et les agences web doivent également pouvoir en bénéficier.

Un clin d’œil à Richard Stallman

Enfin, si nous avons choisi cet acronyme, ce n’est pas tout à fait un hasard. Il fait également écho au concept de SaaSS (Service as a Software Substitute), développé par Richard Stallman, fondateur du projet GNU.

Ce concept désigne une situation dans laquelle un utilisateur confie à un serveur distant des opérations informatiques qu’il pourrait effectuer lui-même à l’aide d’un logiciel exécuté sur sa propre machine. Pour Richard Stallman, cette dépendance à un service distant pose un véritable problème de liberté informatique : même lorsque le logiciel utilisé est libre, l’utilisateur ne contrôle pas nécessairement l’instance qui réalise effectivement ses opérations.

Notre utilisation du même acronyme repose sur une idée différente, mais qui nous semble faire écho à cette réflexion : laisser chacun libre de choisir où et comment ses outils numériques sont exploités.

Nous ne prétendons pas supprimer toutes les formes de dépendance liées aux services en ligne. Proposer une plateforme hébergée implique nécessairement de prendre en charge une partie de l’exploitation technique à la place de nos utilisateurs. En revanche, nous souhaitons leur laisser le choix. Utiliser nos services sans se soucier de la technique, n’en exploiter qu’une partie ou reprendre complètement la main sur leur infrastructure : toutes ces possibilités doivent coexister.

Notre vision du numérique

Nous ne cherchons pas à construire une plateforme dont il serait difficile de sortir. Nous voulons construire un écosystème dont il est agréable de faire partie. Un écosystème dans lequel les logiciels peuvent être étudiés, réutilisés et améliorés. Dans lequel les données restent accessibles et portables. Dans lequel les utilisateurs peuvent choisir leur niveau d’autonomie et ne sont pas contraints de dépendre d’un fournisseur unique. Nous croyons à un web plus ouvert, plus durable et plus souverain. Un web dans lequel la technologie reste au service de ceux qui l’utilisent, et non l’inverse.

C’est notre vision d’un numérique libre et accessible. Et c’est ce que nous souhaitons construire avec Yama !

JSON Schema

JSON Schema est un vocabulaire permettant de décrire, structurer et valider des données au format JSON. Il définit les propriétés attendues, leurs types (texte, nombre, booléen, tableau, objet, etc.), ainsi que les règles et contraintes auxquelles elles doivent répondre. Son principal avantage : garantir la cohérence et la validité des données tout en facilitant leur compréhension et leur exploitation par différentes applications.

Markdown

Markdown est un langage de balisage léger qui permet de mettre en forme du texte à l’aide d’une syntaxe simple et lisible, sans utiliser de balises HTML complexes. Il permet notamment de structurer des documents avec des titres, des paragraphes, des listes, des liens, des images ou encore du code. Son principal avantage : le contenu reste lisible même sans logiciel spécifique et peut facilement être converti vers d’autres formats, comme HTML ou PDF.