L’Open Source est encore trop souvent perçu comme un moyen de faire des économies en s’émancipant des éditeurs propriétaires et de leurs pratiques de lock-in. En réponse, certaines entreprises et organismes publics ont fait le choix d’essayer de redévelopper en interne une solution libre pourtant déjà existante, en se passant de son éditeur, avec l’objectif d’avoir un maximum de contrôle et d’autonomie. Sans surprise, cela ne fonctionne pas et les échecs s’accumulent autant que les promesses non tenues.
Pourquoi ? Parce que le métier d’éditeur de logiciel, fut-il Open Source, ne s’improvise pas et est grandement sous-estimé par ces organisations. Découvrez dans cet article ce métier encore mal (re)connu, à l’origine pourtant de 90% des logiciels libres.
Posons les bases
Il est important de distinguer dans cet article et de façon générale pour l’open source :
- Les composants techniques, souvent gérés de façon communautaires, qui ne sont pas destinés à l’utilisateur final mais à des techniciens ou développeurs pour construire des solutions. Exemple : des middleware, bases de données, composants d’infrastructure comme Nginx, Cyrus, etc. dont les principaux contributeurs sont, en général, des éditeurs !
- Les solutions à destination des utilisateurs finaux, comme les suites bureautiques, les applications de gestion, de messagerie, etc. pour qui l’acceptabilité par l’utilisateur, l’écosystème et l’environnement global sont aussi importants que leur fonctionnement.
C’est à cette 2ème catégorie que nous faisons allusion dans cet article.
Une crainte héritée des ogres hégémoniques
Comportements de « chasseur de prime », « vendre plus » plutôt que « vendre mieux », déséquilibre des relations commerciales, lock-in technologique et contractuel, non-respect du RGPD, extraterritorialité du droit… les arguments ne manquent pas pour pousser les organisations publiques et privées à chercher des alternatives aux solutions hégémoniques notamment américaines.
Cependant certaines directions des SI qui se tournent vers l’Open Source ont tendance à transformer l’aversion légitime envers certains grands éditeurs et leur comportement outrancier en une aversion envers l’éditeur au sens large qui est vu comme un parasite commercial.
On retrouve aussi encore parfois (de plus en plus rarement car le logiciel libre a muri), cette aversion chez des personnes qui simplement ne conçoivent pas qu’il faille payer pour du logiciel libre et déclinent ceci en « le logiciel libre ce ne doit être que du service » ou « c’est l’utilisateur qui décide ce qu’il doit payer » !
Mon projet, c’est un produit ?!
Ces organisations choisissent de « construire » leur solution en interne en faisant appel à des prestataires de service Open Source pour le développement ou le support. Ceci est pertinent quand il n’y a pas de solution « sur étagère » correspondant à la problématique ou qu’il faut couvrir un besoin métier spécifique. Mais cela n’a plus aucun intérêt et est toujours contre-productif quand une solution standard industrialisée couvrant le besoin existe déjà. En effet, on ne développe pas une solution standard à coup de prestations de service ou de support.
En effet, pendant qu’on réalise un projet, on n’écrit pas un logiciel ! Les coûts et les tâches réelles pour développer et maintenir un logiciel standard sont sans commune mesure avec ce qui est nécessaire pour un projet ! Plus le temps passe, plus le logiciel s’enrichit et le nombre de versions augmente, plus la différence s’amplifie encore. La maintenance de l’existant, l’effort continu et croissant sur les tests et la qualité, les évolutions nécessaires du socle technologique et la dette technique devenant rapidement les tâches les plus consommatrices de temps (et d’argent).
Le client qui voudrait un logiciel en mode service
De l’autre côté du spectre, la vision de ce qu’est prêt à acheter un client en mode service (développement de nouvelles fonctionnalités, support) n’a strictement rien à voir avec tout le travail qui est nécessaire à un éditeur pour fournir une solution de qualité, pérenne dans le temps !
Lors du développement initial pour le premier demandeur, c’est simple, il n’y a qu’une tâche : développer les fonctionnalités. Mais ce n’est valable que pour la première version et pour un seul client : le premier !
[En complément : retrouvez ici en vidéo une conférence de Pierre Baudracco, Président de BlueMind et auteur de cet article sur le thème « Open Source : passer d’un modèle de service à un modèle éditeur », donné le 1 octobre 2020 dans le cadre des ateliers du Hub Open Source Systematic Paris Région.]
La machine qui construit la machine !
Souvent le point de départ d’un projet est le développement d’un programme, ou l’assemblage de quelques composants, pour résoudre une tâche particulière pour un utilisateur. L’utilisateur demandeur est content, logique : on apporte une solution à sa demande spécifique !
Le développeur ou commanditaire se dit alors « voilà qui pourrait servir à d’autres, et j’ai des idées de fonctionnalités à ajouter ; je vais en faire un produit ! Je vais rassembler quelques confrères pour mutualiser/aider à financer. »
C’est là qu’est l’erreur : l’écart entre le projet spécifique et le logiciel est en général 100 fois plus important qu’imaginé ! Passer d’un prototype à une solution industrialisée est beaucoup plus complexe que faire le prototype lui-même. C’est aussi vrai dans le logiciel que dans l’industrie.
Ce n’est pas parce que l’on est arrivé à construire une voiture dans son garage, en redressant à coups de marteau les erreurs, qu’il est simple de devenir Renault en production industrialisée et avec ses engagements/garanties et son réseau de maintenance/réparateurs !
La gouvernance, au-delà du premier client
Outre les tâches autres que le développement de nouvelles fonctionnalités, et la complexité de passer à l’échelle dans le développement d’un logiciel, l’augmentation du nombre de clients a beaucoup de conséquences pour un projet :
- Comment maitriser la roadmap quand les fonctionnalités que vous développez sont dictées par un client financeur et pas celles que vous jugez prioritaires pour le produit ?
- Quelle gouvernance et qui définit et est garant de la vision long terme de la solution ?
- Qui est responsable des implémentations sous forme de projet ?
- Qui garantit la compatibilité et le fonctionnement dans les différents contextes des utilisateurs ?
- Qui maintient et fait évoluer le socle technologique, nécessitant régulièrement des chantiers très importants et des chemins/outils de mise à jour
- Comment évaluer le détail des fonctionnalités et leur impact selon les implémentations ?
- Qui garantit les anciennes versions ?
- Qui décide et assure les API, les interactions avec d’autres outils ou partenaires ?
- Comment acquérir et développer du savoir-faire, de la compétence, quand les équipes et les projets mutent en permanence ?
Ces questions – ou plutôt l’absence de réponse satisfaisante – posent également d’autres limites du modèle de service pour développer un logiciel Open Source et expliquent la plupart des échecs dans les organisations qui pensent pouvoir se libérer des éditeurs pour un besoin standard.
Un éditeur Open Source, pourquoi faire ?
Une solution ce n’est pas un code source. C’est un produit fiable, supporté, de qualité, qui plait aux utilisateurs pour un coût raisonnable et lisible.
Le rôle d’un éditeur consiste à concevoir, à maintenir et à faire évoluer un produit pérenne et adapté aux besoins des utilisateurs, en matière de fonctionnalités, d’ergonomie, de sécurité et de performance.
Le métier d’éditeur ne s’improvise pas et nécessite des engagements long terme, une gouvernance efficace, des capacités de vision, d’anticipation, de développement, de qualité et de maintenance importants, ainsi que toute l’organisation pour répondre aux demandes et besoins des clients et partenaires qui veulent une solution !
Les éditeurs Open Source commercialisent typiquement des offres qui viennent compléter ou faciliter l’utilisation et l’exploitation de la solution, comprenant par exemple des outils complémentaires, des fonctionnalités en plus, un support assuré par des « experts ultimes » du logiciel, avec des garanties de réactivité. Ces offres peuvent prendre la forme d’abonnements ou souscriptions, de services Saas (fourniture de la solution sous forme de service hébergé), d’achat de modules ou fonctionnalités complémentaires de type freemium/open core ou d’autres prestations.
Ces offres ont en général été bien réfléchies pour un équilibre revenu/valeur apportée. On trouve, spécifiquement en France des utilisateurs qui veulent d’une solution mais pas de son offre éditeur. Qui veulent même payer (un peu) mais en définissant eux même l’offre qu’ils souhaiteraient ! Un des exemples classiques résultat de l’aversion aux éditeurs est : « je veux bien payer du support mais je ne veux pas payer par utilisateur, » y compris quand c’est la métrique la plus juste, pertinente et simple.
Comme avec l’équipe de France de football, le soir d’un match, on s’imagine facilement sélectionneur à la place du sélectionneur ! L’offre d’un éditeur fait partie de son modèle, de sa lisibilité de son équation générale ; il est inutile d’essayer de la redéfinir à sa place (notamment avec des principes qui ne marchent pas comme « financer le logiciel par du support »), il faut la respecter !
Travailler avec un éditeur open source plutôt que d’essayer de le contourner permet de maximiser les chances de succès, d’avoir une meilleure solution, de garantir la continuité du logiciel, de bénéficier des meilleures compétences tout en faisant des économies et en privilégiant une philosophie ouverte qui bénéficiera à tout le monde.
Qu’ils soient une entreprise, une association ou une fondation, que leur but soit lucratif ou non, les éditeurs sont les garants de l’avenir des solutions Open Source. Ils ont une organisation, des salariés, une roadmap et des enjeux économiques. Le logiciel libre ne vit pas que d’amour et d’eau fraîche !
Editeur Open Source : la vision de BlueMind
Il est important de réaliser que se plaindre du trop petit nombre de solutions Open Source de qualité pour l’utilisateur final est paradoxal avec l’aversion pour les éditeurs Open Source !
Pour BlueMind le chemin est clair : pour être une réelle alternative souveraine aux solutions hégémoniques américaines, il faut d’abord et avant tout proposer un bon produit ! Et au niveau messagerie avoir un bon produit nécessite de répondre sérieusement aux 4 axes principaux de demande du marché :
- Fonctionnalités : proposer des fonctionnalités avancées pour le cœur de messagerie. Il ne s’agit pas simplement de cocher les fonctionnalités mail, agenda, contacts, etc, mais de proposer les scénarios évolués d’usage et un périmètre fonctionnel étendu en intégrant de façon fluide les autres composantes du collaboratif (visioconférence, documents, communication live, connaissance, etc.)
- Habitudes : la messagerie est l’outil le plus utilisé en entreprise. Plus encore que pour n’importe quel outil, en matière de messagerie, c’est l’utilisateur qui guide les choix. Souvent, ce choix se porte sur Outlook. BlueMind s’est emparé de ce problème en mettant l’utilisateur au cœur de tous ses développement pour devenir la seule messagerie « compatible avec tous les usages », soit Outlook en mode natif (BlueMind est la seule alternative à Microsoft à avoir réussi l’exploit de supporter Outlook sans connecteur) mais également les autres moyens d’accès.
- Résilience et sécurité : la messagerie ça doit marcher, et même ne jamais s’arrêter !
- Scalabilité : pour répondre à toutes les problématiques, aux évolutions et à la croissance des populations et de l’usage du collaboratif.
C’est le modèle d’éditeur Open Source qui permet à BlueMind de répondre à ces 4 axes ! Développer un logiciel de qualité, pérenne, à destination de l’utilisateur, est un métier : éditeur. Et ce métier, y compris dans l’Open Source, ne fonctionne pas avec un modèle basé sur le service.
Être éditeur signifie que nous sommes concentrés à 100% sur la solution : le produit et tous les outils et ressources qui l’enrichissent, comme les outils de migration, les différentes documentations (techniques, fonctionnelles ou commerciales), ainsi que l’écosystème (partenaires intégrateurs et technologiques notamment). Nous apportons une vision et une gouvernance globales et pérennes pour garantir la cohérence de la solution.
Et c’est ce niveau de qualité qu’attendent les utilisateurs et qui permet à BlueMind de proposer une alternative souveraine, crédible et surtout acceptée par les utilisateurs et les clients !
#NousAvonsLeChoix
