Développement SaaS : la moitié du travail ne se voit pas

Réponse courte

Un SaaS est un logiciel vendu par abonnement et utilisé depuis un navigateur, sans installation chez le client. Le développement porte autant sur le produit que sur la plomberie : comptes, rôles, facturation, relances, journaux d'activité. Watizi construit cette base, puis le poste de commande qui sert à piloter.

Sur cette page

01 La plomberie représente la moitié du travail
02 Délimiter la première version pour de bon
03 Voir ce que le produit fait quand vous regardez ailleurs
04 Les repères en un tableau

La plomberie représente la moitié du travail

Comptes, invitations, rôles et permissions, facturation récurrente, gestion des impayés, export des données, journaux d'activité. Rien de tout cela n'apparaît sur les maquettes, et tout doit exister le jour où le premier client paie.

Cette part du produit est systématiquement sous-estimée dans les devis, parce qu'elle ne se montre pas. Elle se voit seulement quand elle manque, et le jour où un client ne peut pas inviter son collègue, personne ne trouve la démonstration élégante.

Le bon réflexe consiste à la traiter en premier. Une base d'authentification et de facturation posée dès le début supporte ensuite n'importe quelle fonctionnalité ; l'ordre inverse oblige à réécrire le produit une fois qu'il a des utilisateurs, donc des données à ne pas perdre.

Il existe des briques éprouvées pour la plupart de ces sujets. Les assembler correctement demande du métier ; les réécrire depuis zéro relève rarement du bon usage du budget.

Délimiter la première version pour de bon

Une première version utile porte un seul parcours complet, de l'inscription au résultat que le client attend. Le reste attend le retour des premiers utilisateurs, qui contredira une partie des hypothèses de départ.

Le piège classique consiste à construire six mois avant de montrer quoi que ce soit. À la sortie, le produit répond à la vision de son commanditaire et non aux usages constatés, et les corrections coûtent alors le prix d'une refonte.

Délimiter suppose d'écrire ce qui n'est pas construit avec la même précision que ce qui l'est. Un périmètre qui ne liste que des inclusions n'est pas un périmètre, c'est une liste de souhaits.

Watizi écrit ce document pendant le cadrage, en deux colonnes : ce qui entre dans la première version, ce qui attend la suivante, et pour quelle raison.

Voir ce que le produit fait quand vous regardez ailleurs

Un SaaS en service émet des signaux en permanence : inscriptions, comptes dormants, paiements refusés, actions des agents. Sans un endroit unique pour les regarder, ces signaux existent sans que personne ne les lise.

Le studio a construit son propre poste de commande pour cet usage : un écran d'où l'on voit ce que chaque agent a traité, ce qu'il a escaladé et ce qui attend une validation humaine. Un agent qu'on ne peut pas regarder travailler finit par être débranché.

Le même raisonnement vaut pour les indicateurs commerciaux. Un tableau de bord qui affiche un chiffre sans dire d'où il sort ne sert qu'à rassurer, et il rassure surtout quand il faudrait s'inquiéter.

Ce poste de commande fait partie du produit livré. Il n'est pas un supplément vendu ensuite, parce qu'un logiciel qu'on ne peut pas piloter n'est pas terminé.

Quels repères vérifier, et comment ?

Cinq critères se vérifient sans outil particulier. Le tableau les met en regard de ce qu'ils changent pour un visiteur, pour un moteur, et de la façon de les contrôler.

Critères de qualité applicables au sujet « developpement saas », effet côté visiteur, effet côté moteur et méthode de vérification.
Critère	Pour le visiteur	Pour un moteur	Comment le vérifier
Exactitude	Il trouve la bonne information du premier coup	Aucune contradiction à arbitrer	Relire chaque champ publié, source par source
Fraîcheur	Il sait que la page est tenue	Signal de mise à jour daté	Noter la date de dernière modification
Cohérence	Le même message partout où il vous croise	Recoupement possible entre les sources	Comparer les sources deux à deux
Preuve	Il peut vérifier ce qui est affirmé	Contenu citable, attribué à un émetteur	Chercher qui signe et ce qui est sourcé
Régularité	Une activité visiblement suivie	Historique lisible dans la durée	Tenir un relevé à intervalle fixe

Questions fréquentes

Faut-il partir d'un outil existant plutôt que de développer ?

Oui, tant qu'un outil du marché couvre le besoin sans contorsion. Le développement se justifie quand le produit est ce que l'entreprise vend, quand les règles métier n'existent nulle part ailleurs, ou quand la dépendance à un éditeur devient un risque assumé.

Où sont hébergées les données d'un SaaS construit par Watizi ?

En France, chez un hébergeur choisi avec vous. L'entreprise reste propriétaire de sa base et peut l'exporter quand elle veut, ce qui se vérifie en lisant le contrat plutôt qu'en écoutant une promesse.

Combien de temps avant la première version en ligne ?

Le délai découle du périmètre retenu au cadrage. Un parcours unique, complet et facturable sort bien plus vite qu'un produit qui tente de couvrir trois métiers à la fois : c'est l'arbitrage principal de cette phase.

Sources

Arrêter le périmètre du produit avant de le construire

Le cadrage projet demande ce que le produit doit faire, pour quels comptes, et dans quel ordre. Watizi revient avec un périmètre écrit et un chiffrage sous 48 h.

Cadrer mon projet SaaS

Le logiciel est l'instrument, l'orchestre le fait jouer : les agents IA travaillent dedans, la visibilité dans les moteurs IA se prépare dès le code, et la Part de Voix IA mesure ce que ça donne.