Récapitulatif du mois de mars 2024

Publié le 3 avril 2024

Nous avons progressé dans la création de notre écosystème de micro-SaaS, en axant le développement sur notre premier produit dédié à la communication par email. Six segments de marché ont été identifiés, avec des interviews en cours pour affiner les fonctionnalités. Un site et une newsletter ont été lancés pour renforcer la présence en ligne. Le développement technique s'est concentré sur Heimdall, notre plateforme pour la gestion des utilisateurs et des paiements.

Récapitulatif du travail effectué lié aux choix stratégiques, au marketing et à la communication

Déterminer les segments de marché potentiels et les utilisateurs finaux

Ce mois-ci nous avons commencé par établir une liste de segments de marché pour déterminer quelles personnes nous pourrions aider concernant la rédaction de contenu éditorial envoyé par email (le projet RMS).

Nous avons listé les 6 segments suivants :

Entreprises en croissance : Pour les entreprises en croissance, l'attrait réside dans la découverte d'outils de marketing par email qui allient simplicité, accessibilité économique, et une valeur ajoutée claire par rapport aux solutions existantes souvent jugées complexes et coûteuses. Cette recherche est guidée par la nécessité de se distinguer dans un environnement concurrentiel tout en gérant prudemment les ressources limitées. Nous estimons les clients finaux être les fondateurs, les directeurs produit et les pôles marketing et communication.

Les agences immobilières : avec leurs agents et directeurs d'agence, elles recherchent spécifiquement des outils qui leur permettent de segmenter et personnaliser leurs newsletters de manière efficace. Cette exigence découle du désir d'optimiser la communication avec leurs clients pour se différencier des agences concurrentes. Les services disponibles sont souvent peu spécialisés, suggérant une opportunité pour une solution plus adaptée.

Les créateurs de contenu : incluant les indépendants, blogueurs, et YouTubers, sont motivés par l'utilisation d'outils qui soutiennent et renforcent leurs communautés sans compromettre la qualité de la relation établie. Leur principal critère de sélection repose sur la facilité d'utilisation, l'efficacité et la capacité à offrir une valeur ajoutée sans générer d'impact négatif sur la dynamique avec leur audience.

Le secteur de l'événementiel : les organisateurs d'événements cherchent des solutions qui leur offrent une grande flexibilité et la possibilité de personnaliser leurs communications. Cette demande est dictée par le besoin de refléter l'unicité et la spécificité de chaque événement, soulignant l'importance d'outils capables de s'adapter à une variété de contextes et d'exigences.

Agences de marketing et communication : les spécialistes du marketing numérique et les gestionnaires de compte client visent à trouver des solutions qui promettent une transition aisée de leurs outils actuels. Leur réticence à changer est surmontée uniquement lorsque la nouvelle solution démontre un avantage substantiel en termes de simplicité d'utilisation, de coût et de performances par rapport aux options existantes.

Les secteurs réglementés : tels que la santé et le droit, les cadres légaux et responsables de la conformité privilégient les solutions qui garantissent la sécurité et la conformité réglementaire. Leur ouverture à l'adoption de nouvelles technologies est conditionnée par la capacité de ces outils à répondre à des critères stricts de conformité, d'autant que nous pensons avoir à faire un travail d'éducation sur l'intérêt pour de tels secteurs de développer une communication éditorial par email.

L'intérêt pour nous était de définir des profils d'utilisateurs finaux avec lesquels nous souhaitons échanger pour cerner et lister des fonctionnalités clés, moteurs potentiels de notre différenciation.

Nous avons poursuivis cette analyse avec 3 interviews de profils différents en rapport au segment des entreprises en croissances.

Voici un court résumé des échanges :

• Nous avons eu, pour le moment, validations concernant nos hypothèses de coûts et de complexités des solutions existantes,
• Nous avons découvert des problématiques intéressantes ainsi que quelques idées de fonctionnalités pertinentes auxquelles nous n'avions pas pensé,
• Nous avons bénéficié de retours d'expériences liés à la création d'un produit et sur la communication, ce qui nous a permis d'enrichir nos connaissances en la matière.

Nous prévoyons de réaliser plusieurs dizaines d'interviews d'ici les prochaines semaines pour enrichir nos listes d'hypothèses et cerner les problématiques récurrentes pour définir un marché tête de pont et un persona d'utilisateur final.

Préparation de la communication de Bireme Lab

Au cours du mois de mars, nous avons discrètement sortie le site https://bireme.io pour rédiger du contenu de blog et créer de l'antériorité dans notre présence en ligne, avec quelques idées d'articles sur lesquels nous travaillons. Nous souhaitons y partager notre avancée tous les mois, nos découvertes ainsi que des billets d'humeurs.

Nous avons également créé notre newsletter pour commencer à récupérer des contacts à activer par email. Nous prévoyons de transformer cette newsletter en liste d'attente une fois notre premier produit disponible en accès bêta.

Travail lié à la conception et au développement produit

Création de la plateforme de gestion des paiements et de nos utilisateurs

Comme nous avons l'ambitions de créer un écosysteme de micro-SaaS, nous avons décidé de commencer par créer un socle commun sur lequel se basera l'ensemble des services Bireme Lab. Son rôle consiste à centraliser la gestion de la facturation, les configurations des organisations, des équipes et des profils utilisateurs. Autant d'informations importantes que nous utiliserons dans chacun de nos produits.

Nous avons nommé cette application Heimdall, en référence au gardien du Bifröst dans la mythologie nordique.

Nous avons décidé de développer Heimdall maintenant pour assurer que toutes nos applications bénéficient de la même plateforme, favorisant les interconnexions entre services et nous offrant la possibilité de nous concentrer pleinement sur le développement des fonctionnalités métier par la suite. Travailler sur cette partie du produit en parallèle de la conduite des interviews nous permet de prendre le temps de lister, objectivement, les fonctionnalité clés à concevoir pour notre premier produit RMS tout en avançant sur un pré-requis technique nécessaire.

Les tâches produits accomplies durant le mois

Focus produit du mois : Heimdall

Spécifications : nous avons pris le temps de spécifier entièrement les modèles de données ainsi que les fonctionnalités qui seront présentes au lancement du premier produit :

• Possibilité de créer et de gérer une ou plusieurs organisations,
• Gestion des invitations d'utilisateurs,
• Possibilité de créer des équipes liées à une organisation et d'y inviter des utilisateurs,
• Gestion des permissions à la fois au niveau des équipes mais aussi au niveau des utilisateurs,
• Centralisation des informations de paiement, et de la gestion de la facturation, tout produit Bireme Lab confondu,
• Onboarding interactif à la création de compte.

UX/UI : nous avons commencé à mettre en forme les maquettes de toutes les fonctionnalités présente dans la V1 d'Heimdall.

À ce jour nous avons terminé le travail de webdesign sur les sections suivantes :

Connexion des utilisateurs : page de connexion, de validation de code OTP,

Onboarding d'un utilisateur : formulaire par étapes pour qu'un utilisateur renseigne les informations nécessaires à la configuration de son espace de travail,

Création d'une organisation : formulaire par étapes pour qu'un utilisateur renseigne les informations nécessaires à la création d'une organisation,

Page d'invitation : page pour accepter une invitation à rejoindre une organisation.

Focus sur : la gestion des permissions

En établissant la liste des fonctionnalités essentielles au bon fonctionnement, à la maintenance et pour simplifier l'évolution de nos produits dans le futur, nous avons émis l'hypothèse que de retravailler la gestion des utilisateurs pour permettre de créer des organisations, des équipes et de gérer des permissions serait un cauchemar une fois RMS disponible à l'usage.

Nous avons donc décidé de travailler activement, pour la V1 d'Heimdall, sur la création d'une gestion d'organisations permettant aux utilisateurs de créer des équipes, d'inviter des utilisateurs et de configurer différents niveaux de permissions.

Nous avons établis les permissions à deux niveaux :

• au niveau des équipes : l'administrateur d'une organisation pourra créer une équipe, et y déterminer les permissions que les membres de cette équipe auront "par défaut" au sein de l'organisation,
• au niveau des utilisateurs : l'administrateur d'une organisation aura la possibilité d'ajouter des permissions en plus de celles héritées par la configuration de l'équipe dont l'utilisateur sera membre.

De cette manière, un administrateur qui configure correctement ses équipes pourra segmenter efficacement les droits d'accès et les usages des produits Bireme Lab au sein de son organisation. Assurant un gain de rapidité puisque le collaborateur invité aura, par défaut, les permissions configurées au niveau de l'équipe, et un gain de sécurité sur qui aura le droit de faire quoi avec les outils de l'entreprise.

À noter, également, que nous avons déterminé les règles suivantes :

• Un utilisateur ne peut pas avoir moins de permissions que celles de l'équipe dont il est membre,
• Par défaut chaque organisation possèdera une équipe "Admin" qui ne pourra pas être supprimée : chacun de ses membres sera considéré administrateur de l'organisation et bénéficiera de toutes les permissions.

Focus sur : la rédaction des spécifications chez Bireme Lab

Avec un historique de profils plutôt tech, nous avons décidé de centraliser nos documentations et nos spécifications produits sur GitHub.

Nous trouvons cette manière de travailler très naturel grâce aux fonctionnalités natif à l'outil pour collaborer sur la rédaction et sur les révisions.

Pour chaque ajout ou modification nous créons une nouvelle branche, une pull request ¹ avec les informations suivantes dans la description :

• Nom du produit impacté,
• Liste des fonctionnalités impactées,
• Motivations :
  • pour la nouvelle fonctionnalité, ce qu'elle apporte
  • pour la refonte, ce qui ne va pas dans la version actuelle et ce que la nouvelle version apporte
  • Pour les changements mineurs, pourquoi devons-nous mettre à jour la spécification ?
• Brève description des changements,
• Liste des doutes que vous avez sur des points spécifiques liés au produit/UX/design.
• Liste des doutes que vous avez sur la faisabilité technique

De cette manière chaque modification des spécification est soumise à révision, nous conservons également un versionnement efficace de notre travail, accessible à tout moment.

Autre avantage important, Github intègre nativement Mermaid et permet de visualiser rapidement les diagrammes et les schémas que nous ajoutons dans les spécifications produits de cette manière.

Travail de développement

Focus tech du mois : Heimdall

Les tâches tech accomplies durant le mois

Création de l'environnement de développement : mise en place de l'architecture technique des produits

Création de l'API GraphQL : création d'un serveur web en Rust avec des fonctions permettant de lire, traiter et sauvegarder les données dans nos bases de données.

Développement de l'authentification des utilisateurs : intégration du service externe Clerk pour gérer l'authentification des utilisateurs, développement des pages pour se connecter aux produits

Développement de l'onboarding utilisateur : création des pages permettant aux utilisateurs de renseigner leurs informations lors de la première connexion

Gestion et centralisation des journaux d'erreurs : mise en place du système d'alertes pour simplifier l'identification et le traitement des problèmes techniques que les utilisateurs pourraient rencontrer en utilisant nos produits

Focus sur : notre environnement de développement

Pour nos applications, nous avons décider de choisir les technologies suivantes:

• Rust pour le back-end avec les librairies:
  • Rocket qui permet de créer un serveur web
  • Juniper qui permet de créer une API GraphQL
  • SQLx pour communiquer avec notre base de données
• TypeScript pour le front-end avec les librairies:
  • Vite pour compiler et minifier notre application
  • React pour le développement de l'interface utilisateur
  • @swan-io/use-form pour la gestion des formulaires
  • @swan-io/chicane pour la gestion des routes
  • Clerk pour l'authentification des utilisateurs
  • gql.tada pour la communication avec notre API GraphQL

Lorsque nous développons notre application, nous avons 2 serveurs en parallèle:

• le serveur back-end qui s'occupe de servir l'API GraphQL
• un serveur créé par Vite qui s'occupe de transpiller notre code front-end à chaque modification.

Afin d'éviter les problèmes de CORS, nous avons configuré Vite pour qu'il créé un proxy vers notre serveur back-end.

Et lorsque nous préparons notre application à la mise en production, le serveur back-end contient les fichiers statiques de notre application front-end et s'occupe de les servir.

Cela nous apporte ces avantages:

• nous n'avons pas besoin de spécifier l'URL du serveur back-end dans notre application front-end
• nous n'avons pas besoin de gérer les CORS côté back-end
• nous n'avons qu'un seul serveur à gérer en production (donc pas besoin de synchroniser le déploiement de 2 serveurs lors de la mise en production)

Focus sur : création de l'API GraphQL

Comme précisé dans la partie précédente, nous avons décidé de créer une API avec le langage de requête GraphQL pour notre application. Cela nous apporte des avantages techniques et organisationnels :

• la communication entre le front-end et le back-end est type-safe ², ce qui rend le développement plus fluide et tout en évitant des oublies involontaires en cas de modification de l'API,
• permet de créer une API générique et flexible côté produit. Nous permettant d'afficher davantage d'informations sans avoir à modifier le back-end.

Pour le développement de cette API, nous nous sommes tourné vers Rust. Nous avons conscience que c'est un choix particulier car Rust est un langage qui demande de l'expérience et qui n'a pas une communauté aussi grande que JavaScript, notamment pour le développement web.

Mais Rust a un ecosystème suffisamment important pour créer des applications robustes et performantes :

• Rocket permet de créer facilemenent un serveur web qui combine à la fois le multi-threading ³ et le code asynchrone pour créer des applications performantes,
• l'utilisation de SQLx nous permet d'écrire des requêtes SQL qui sont validées à la compilation et donc rends le développement plus rapide en nous indiquant les erreurs de syntaxe avant l'exécution. Cela nous permet aussi de nous indiqué toutes les requêtes SQL à modifier en cas de modification du modèle de données,
• Et avec Juniper nous pouvons créer une API GraphQL qui se base sur le système de typage de Rust. Donc toute modification dans le code est automatiquement répercuté sur le schéma GraphQL, schéma qui est ensuite utilisé par notre application front-end pour inférer le typage des requêtes.

Au final nous avons réussi à créer du code type-safe de notre base de données, jusqu'à l'interface utilisateur en passant par notre serveur back-end. Ce qui nous rend confiant pour déployer des mises à jour rapidement et sans régressions.

¹ : abréviation de "Pull Request" en anglais. C'est une fonctionnalité pour proposer et discuter des modifications de code avant de les fusionner avec le reste du projet
² : Le terme type-safe fait référence à un code écrit dans un langage de programmation typé statiquement, où les types de données sont vérifiés au moment de la compilation, ce qui garantit une exécution plus sûre du code en prévenant les erreurs de type potentielles.
³ : Le multi-threading est une technique de programmation qui permet à un programme d'exécuter plusieurs tâches ou portions de code en parallèle sur plusieurs cœurs du processeur, comme si elles se déroulaient en même temps. JavaScript est un langage single-thread et n'utilise qu'un seul cœur de processeur, à la différence de Rust.