Tous les services

Applications SaaS

Une application SaaS, c’est le produit que vous facturez, celui auquel les clients se connectent, pour lequel ils paient et vers lequel ils reviennent. Nous concevons le produit, mettons en place la facturation et la gestion des licences, et développons le tableau de bord sur lequel ils travaillent réellement, afin que vous puissiez proposer une véritable activité et non pas simplement une brochure dotée d’un identifiant de connexion. Après le lancement, nous maintenons un dialogue permanent : l’utilisation du produit nous indique les modifications à apporter ensuite.

  • Architecture du produit
  • Applications multi-locataires
  • Facturation des abonnements
  • Tableaux de bord d'administration
  • Authentification et rôles
  • Conception d'API
  • Intégrations
  • Lancement et itération

L'essentiel

Qu'est-ce qu'une application SaaS ?

Un logiciel pour lequel un utilisateur paie un abonnement et auquel il se connecte pour effectuer une tâche. C'est là toute la définition, et toutes les difficultés liées à sa conception découlent de ces deux aspects : il doit continuer à justifier le prochain paiement, et il doit stocker les données de plusieurs clients sans jamais les mélanger.

C'est pourquoi un produit SaaS n'est pas simplement un site web auquel on aurait ajouté une fonctionnalité de connexion. Comptes, rôles, environnements, facturation, licences, périodes d'essai, mises à niveau, paiements refusés, audit… Aucun de ces éléments n'est la fonctionnalité que vous vendez, mais tous doivent fonctionner avant que quiconque puisse acheter le produit, et chacun d'entre eux représente un domaine où un raccourci peut se transformer en refonte complète.

Nous développons le produit et les mécanismes commerciaux qui l'entourent d'un seul tenant, puis nous restons suffisamment longtemps pour analyser les données d'utilisation. La première version n'est qu'une hypothèse. Le plus intéressant, ce sont les six mois qui suivent le lancement, lorsque l'on peut enfin voir quelles fonctionnalités les utilisateurs consultent.

  • SaaS
  • Multi-locataires
  • Facturation des abonnements
  • Architecture du produit
  • Tableaux de bord
  • API

Capabilities

Ce que nous faisons pour vous

Le produit, et les aspects d'une entreprise de logiciels qui ne relèvent pas du produit.

Architecture du produit

Le modèle de données, les limites entre les locataires et les décisions dont la révision s'avère coûteuse. Se tromper sur la délimitation entre les locataires est la seule erreur qui se traduit par une réécriture plutôt que par une refactorisation.

Authentification, rôles et équipes

Inscription, authentification unique (SSO), invitations, autorisations par poste, et l'administrateur qui doit résoudre les problèmes sans l'aide d'un développeur. Les modèles d'autorisation sont faciles à mettre en place, mais très difficiles à modifier une fois que les clients en dépendent.

Facturation des abonnements

Abonnements, périodes d'essai, calcul au prorata, mises à niveau, paiements échoués et factures que votre comptable vous demandera. C'est au niveau de la facturation que la plupart des SaaS développés en interne perdent discrètement de l'argent — non pas à cause de la fraude, mais à cause de cas particuliers que personne n'a pris en compte.

Le tableau de bord sur lequel travaillent les collaborateurs

Les écrans que les clients consultent chaque jour sont conçus pour une utilisation quotidienne et non pour une simple démonstration. Un tableau de bord optimisé pour les cinq premières minutes devient lassant dès la deuxième semaine.

API et intégrations

Une API documentée, des webhooks et des connexions aux outils que vos clients utilisent déjà. L'intégration est souvent le facteur déterminant dans la décision d'achat.

L'IA là où elle trouve toute sa place

Recherche, synthèse, extraction, assistance — ces fonctionnalités sont ajoutées lorsqu'elles permettent d'alléger la charge de travail d'une personne, et non parce que la catégorie s'attend à ce qu'une icône en forme d'étincelle y figure.

Processus

Déroulement d'une compilation

Il faut compter entre douze et vingt semaines pour obtenir une première version commercialisable, selon le domaine. Ensuite, on parle davantage d’un rythme de publication que d’une ligne d’arrivée.

  1. Préciser ce qui est vendu

    Qui paie, pour quoi, et qu'est-ce qui change lorsqu'on cesse de payer ? La tarification relève d'une décision relative au produit et elle impose des contraintes au modèle de données ; elle doit donc être prise en compte en premier lieu, et non en dernier.

  2. Concevoir le contrat de location

    Comment les clients sont séparés, où cette limite est appliquée et ce qu'un administrateur peut voir de part et d'autre de celle-ci. Ces éléments doivent être consignés par écrit et validés avant même que la première table n'existe.

  3. Construire la colonne vertébrale

    Comptes, rôles, facturation, l'interface de ligne de commande. Des aspects peu glamour mais indispensables : rien ne peut être vendu tant que tout cela ne fonctionne pas, ce qui évite que ces problèmes ne se posent plus tard.

  4. Réaliser le produit

    Ce que vous vendez réellement, c'est une série de tranches verticales dont chacune correspond à un élément utilisable. Une tranche qui ne peut pas faire l'objet d'une démonstration est une tranche qui ne peut pas être corrigée.

  5. Instrument et lancement

    Analyses, suivi des erreurs et événements d'utilisation sur les parcours clés, mis en place avant le lancement plutôt que pendant la première semaine, souvent source de confusion, qui suit celui-ci.

  6. Lisez le mode d'emploi et procédez par itérations

    Ce que les utilisateurs ouvrent, ce qu'ils laissent de côté, où ils invitent un collègue. La feuille de route après le lancement devrait principalement apporter des réponses à ces questions, et non pas se baser sur le backlog rédigé avant même que quiconque n'ait utilisé l'application.

Impact

Pourquoi est-ce important ?

La différence entre la mise sur le marché d'un logiciel et la gestion d'une entreprise de logiciels réside principalement dans les éléments qui ne sont pas des fonctionnalités.

Revenus récurrents

Un abonnement est un modèle économique, pas un moyen de paiement. S'il est bien conçu, il génère des retombées positives ; s'il est mis en place à la va-vite, il entraîne un taux de désabonnement difficile à analyser.

Un bail que vous pouvez faire valoir

Le fait qu'un client puisse consulter les données d'un autre client constitue l'échec irrémédiable pour un service SaaS. Assurer le respect de cette règle au niveau de la frontière plutôt qu'au sein de chaque requête, c'est là toute la différence entre une politique et un simple espoir.

Une croissance qui n'a pas besoin de vous

L'inscription en libre-service, les invitations et les mises à niveau intégrées au produit font que les clients arrivent pendant que tout le monde dort. Chaque étape manuelle de ce parcours constitue un frein.

Cela s'intègre parfaitement à l'environnement qu'ils utilisent déjà

La plupart des acheteurs ne remplacent rien : ils viennent compléter une infrastructure existante. Une API et deux bonnes intégrations permettent de lever la principale objection.

Il reste rapide même lorsqu'il se remplit

Les modèles de requêtes qui conviennent pour dix comptes ne conviennent pas pour dix mille. Concevoir un système adapté à ce dernier cas ne coûte pratiquement rien au départ, mais ne peut pas être mis en place à moindre coût par la suite.

Un code source que votre équipe pourra reprendre à son compte

Codé, testé, documenté et déployé via un pipeline plutôt que par une personne. Nous développons en partant du principe que nous ne serons pas les derniers à travailler sur ce projet.

Questions

Entre douze et vingt semaines pour la plupart des produits. C'est la complexité du domaine qui détermine la durée, plutôt que le nombre de fonctionnalités : tout projet impliquant des données réglementées, des autorisations complexes ou une intégration difficile se situe dans la partie haute de cette fourchette.

Projets sélectionnés

Là où c'est déjà en production.

Tous les projets

Prochaine étape

Dites-nous quelles tâches on vous paie pour effectuer manuellement.

C'est généralement là que se trouve le produit. Envoyez-nous ses dimensions et nous vous proposerons un périmètre d'intervention, une fourchette de prix et les éléments qui pourraient faire l'objet d'une discussion.