Que faut-il prendre en compte lorsqu’on crée une application pour le business / l’entreprise ?

(news.ycombinator.com)

49 points par xguru 2023-01-09 | 3 commentaires | Partager sur WhatsApp

Question publiée sur HN, avec les réponses les plus recommandées

Réponse 1

Qui est l’acheteur ? En général, il est différent de l’utilisateur du produit, et il faut comprendre ce qu’il veut
SSO, basé sur SAML
Côté sécurité, couvrir l’OWASP top-10, ainsi que l’app-sec (sécurité applicative)
Mettre en œuvre le RBAC. Faire en sorte qu’un administrateur puisse ajouter/gérer facilement les utilisateurs
Implémenter un compte de démo en sandbox et le remplir avec des données proches du réel. Le rendre très simple à utiliser lors du pitch commercial. Faire en sorte que le produit parle de lui-même à votre place
Penser au multi-tenant dès le départ. C’est difficile à ajouter plus tard
Intégrer dès le début les exigences de conformité propres au domaine. Des éléments comme SOC 2 ne sont pas si difficiles. Pendant ce temps, trouver un bon prestataire de sécurité pour faire des tests, corriger les problèmes de priorité haute ou moyenne, puis obtenir les certificats. Cela aide à construire la confiance avec les clients
Les rapports. En général, les administrateurs ont besoin de divers rapports. Il est utile de leur fournir des exports CSV/Excel afin qu’ils puissent les réutiliser dans leur logiciel de tableur
Les utilisateurs peuvent faire des erreurs, donc toujours utiliser le soft-delete. Ensuite, faire un hard-delete quelques mois plus tard si nécessaire

En tant que premier ingénieur de l’entreprise, j’ai construit 2 applications enterprise à succès (l’une a été vendue, l’autre vaut actuellement plus de 100M)
La seule chose dont il faut vraiment se soucier est de savoir si « les clients veulent et ont réellement besoin de votre application ». 99 % des produits SaaS enterprise échouent non pas à cause de fonctionnalités manquantes, mais à cause de ça
Des fonctionnalités enterprise comme le SSO, les intégrations ou l’audit trail peuvent être construites lorsque les clients les demandent
La plupart de ces sujets sont déjà résolus, mais comme vous êtes ingénieur, ils paraissent attrayants
Ignorez cela et concentrez-vous uniquement sur le problème business : « Mon application résout-elle un besoin pressant de mon client ? »
Pour adopter l’état d’esprit qui permet de répondre à cette question, lisez "The Mom Test". C’est la chose la plus importante à ce stade

À votre place, je laisserais pour plus tard les aspects techniques d’un produit B2B / enterprise
Le vrai sujet est de comprendre le processus de vente / la stratégie GTM (Go To Market). Comme d’autres l’ont dit, il est utile de s’associer avec quelqu’un qui connaît le problème / le secteur et qui a déjà vendu à des entreprises. Gardez à l’esprit que cela deviendra la compétence clé de l’entreprise (si vous voulez gagner beaucoup d’argent). En tant que leader technique, votre travail se rapproche davantage du conseil que du simple fait de construire et livrer un produit
Si vous avancez seul, parlez à beaucoup de personnes impliquées dans les processus métier et vérifiez pourquoi elles fonctionnent aujourd’hui de cette manière sur le problème que vous cherchez à résoudre. Souvent, en tant que développeurs, nous voyons un problème technique alors qu’il s’agit en réalité d’un problème organisationnel / politique / social. Ne construisez pas trop de choses au départ : créez d’abord un prototype visuel que vous pouvez montrer et pitcher, puis laissez les utilisateurs le tester eux-mêmes

Beaucoup de choses dépendent du type de business que vous visez. Si vous ciblez des organismes publics ou des institutions financières, les exigences seront bien plus nombreuses que pour une entreprise logicielle classique
Pour les grandes entreprises, le cycle de vente peut être assez long, mais en contrepartie la taille des contrats peut être très importante
Après plusieurs années à vendre à des clients enterprise, le meilleur conseil que je puisse donner est : « comprenez votre client cible ». Non seulement l’entreprise elle-même, mais aussi les personnes réelles auxquelles vous allez vendre le logiciel. Avant de commencer à construire, parlez à vos clients cibles pour vérifier exactement ce dont ils ont besoin (et si cela correspond bien à ce que vous imaginez), ainsi que les obstacles qu’ils pourraient avoir à l’achat de votre logiciel. Si vous connaissez les exigences à l’avance, vous n’aurez pas de mauvaises surprises pendant le processus de vente
Le livre que je recommande est The Mom Test. Il vous apprendra à poser les bonnes questions pour obtenir du feedback de vos clients cibles

Concevez l’application de façon à exposer une API, et faites en sorte que le client web s’appuie sur cette API pour le rendu. Dans l’espace enterprise, il n’est pas nécessaire de faire du rendu côté serveur pour le SEO
Souvent, dans les entreprises, après avoir utilisé votre application, les gens veulent automatiser eux-mêmes certaines tâches ou intégrer l’application à d’autres systèmes. Si vous avez une API, cela signifie que vous n’avez pas besoin de travail supplémentaire. Tout ce qu’ils peuvent faire dans l’application peut alors être automatisé
S’il y a une base de données, disposer d’une réplique en lecture seule accessible à vos utilisateurs permet de répondre rapidement à presque toutes les questions business. Beaucoup de responsables métier, de personnes qui produisent des rapports et d’ingénieurs maîtrisent très bien SQL

Le plus important est de « trouver un problème pour lequel les entreprises sont réellement prêtes à payer afin qu’il soit résolu ». Mettez en place un MVP simple et développez à partir de là

Construire et concevoir pour le multi-tenant dès l’étape du schéma
Découpler l’ID et le mécanisme de connexion — prévoir plusieurs mécanismes de connexion par utilisateur (e-mail / mot de passe, SAML, OpenID Connect, Google) et envisager aussi plusieurs facteurs d’authentification (TOTP, Duo, …). Faire attention à la manière de distinguer les utilisateurs authentifiés et de vérifier les adresses e-mail
Utiliser aussi TLS pour les connexions à la base de données. Utiliser le chiffrement. Automatiser les sauvegardes et permettre de restaurer / exporter les données par client, et pas seulement l’application entière
Utiliser une base de données de séries temporelles ou un système de journalisation d’événements, et générer un audit trail pour toutes les actions effectuées dans le système par des utilisateurs autorisés, ainsi que pour les changements de compte ou de permissions et les actions destructrices

bus710 2023-01-09

On sent une vraie perspicacité.

wicksome 2023-01-09

Lors de la création d’applications pour le business ou l’entreprise, à quoi faut-il penser ?

xguru 2023-01-09