Le premier grand client révèle les limites du produit SaaS
Un exemple fictif d’approbation de commande supplémentaire relie variantes clientes, maintenance commune et périmètre du produit.
Un client professionnel demande une approbation supplémentaire, tandis que les autres utilisent le parcours existant. Pour l’équipe SaaS, une décision produit apparaît : cette variante fait-elle partie de l’offre commune et comment peut-elle y rester maintenable ?
L’exemple suivant est entièrement hypothétique. Il ne décrit ni fonctionnalité réellement commandée ni résultat de projet mesuré.
Décrire une variante par une règle traçable
Supposons que le produit traite les commandes des entreprises C10 et C20. Le nouveau client exige l’approbation d’une autre personne autorisée. La personne qui commande ne peut pas approuver sa propre commande. L’autre client doit conserver le parcours actuel.
Entreprise | Parcours souhaité | Vérification attendue lors d’une mise à jour commune |
|---|---|---|
| Attendre une approbation indépendante après envoi | L’auto-approbation est refusée ; seule l’autre personne autorisée peut approuver |
| Traiter la commande sans étape d’approbation supplémentaire | Le parcours actuel reste fonctionnel, sans obligation d’approbation propre à l’autre client |
La pertinence d’un paramètre client géré dépend du modèle produit. Dans cet exemple, la variante serait testable : règle, périmètre et comportement attendu pour chaque client sont définis.
Une solution particulière a aussi un avenir
Une copie du code conçue uniquement pour un client devra également être corrigée, testée et mise à jour. Nous examinerions donc d’abord si le besoin peut être maintenu comme variante clairement délimitée du produit commun. Cette recommandation est conditionnelle ; elle n’oblige pas à transformer toute exception en paramètre.
Si le client exige un processus fondamentalement différent avec maintenance et assistance propres, une solution séparée peut être un choix conscient. Périmètre et responsabilités doivent alors être explicitement convenus. Des ressources dédiées ou des déploiements séparés n’exigent pas automatiquement une autre base de code produit.
Distinguer fonction, droit au service et accès aux données
Un indicateur de fonctionnalité peut aider lors d’une introduction limitée dans le temps. Un droit au service convenu durablement exige toutefois une gestion et une application adaptées. Activer une fonction ne remplace pas non plus la vérification de qui peut approuver pour quelle entreprise.
Dans cet exemple, une mise à jour devrait tester la variante d’approbation et le parcours inchangé. La règle produit traçable et l’effort de maintenance comptent ; la première demande cliente ne décide pas seule de l’architecture.
Sources
Écrit par
- Katharina WeberRédactrice logiciels et technologieKatharina Weber s’occupe chez ASES des articles consacrés au développement logiciel. Elle traite des questions que se posent les entreprises lorsqu’elles choisissent un logiciel, développent de nouvelles applications ou modernisent leurs systèmes existants.
À lire aussi
Tous les articles
Développement logiciel avec ASES
Logiciels sur mesure, applications web et mobiles