Architecture d'application web

Quand tu parle une base par entreprise cela veut dire 1 base par incription ?

C´est exactement ça ☺

Pour mon avis j'obterais sur la solution 1. Je trouve que faire une base pour chaque entreprise rique de faire beaucoup. Imagine que ta 1000 entreprises. Aprés niveaux requéte cela est plus simple.

Sa reste mon avis

Le soucis c'est que j'ai peur d'avoir des fails de sécurité, une entreprise puisse modifier des données qu'ils ne sont pas à elles même si j'ai des conditions

C'est là où tu peux faire plusieurs restriction.. en checkant le nom de l'entreprise, (une clé que tu pourrais attribuer à chaque entreprise.. comme une sorte de token) etc.... après tu n'est pas à l'abri de failles.. mais c'est en rendant public ton app que tu pourras lui faire subir un stress test..
et +1 pour la solution 1, ça me semble énorme une base par entreprise.

Très bien, je pars sur cette idée, je vais tout relié avec l'id de l'entreprise :p

Parce qu'a pars ces 2 solutions, il y en aurais d'autre ?

Je ne vois pas de solution qui correspondrait réellement à ton cas.

Bonjour Mika, si ton but est de vraiment mettre en production dans un environnement réel. Tu dois prendre une contrainte sous-jacente assez courante dans le monde du B2B. Bon nombre de société souhaite assurer elle même le hosting. Elle souhaite très souvent que ça soit héberger soit sur son intranet soit sur son serveur. Il est donc préférable, pour anticiper ce besoin, d'avoir un DB par Société. Qui plus, pour ce que ça vaut, garder une DB collant plus à la logique métier et éviter des jointures lié à ta méchanique de "multi-société" inutilement.

Attention cette réflexion peut aussi avoir un mauvais coté, si tu comptes avoir des sociétés partageant certaines information (comme un groupe de société tel que Google aillant plusieurs filliale ?) alors tu devrais prévoir un système découpler par Groupe, ou Holding.

Dans l'espoir de t'avoir aidé.

@Yanis-git Merci pour ta réponse,celle-ci m'amène à la réflexion, du est-ce mieux d'héberger les app ou alors de laisser le choix le l'héberger eux même et de fonctionner sous forme de licence. Cet aspect est nettement plus commercial que technique !

Tout dépend le secteur que tu attaques. Il est résonnable de penser que de petites sociétés souhaiteront se soulager de cette charge qui est la gestion d'un serveur, en revanche l'argument technico-commercial d'un cloisonnement complet de leurs informations par rapport aux autres sociétés utilisant le service aura de l'importance (cf: ta réflexion sur la sécurité ci-dessus).

Une fois un certain pallier passé, les sociétés préfèrerons l'indépendances et l'autonomie sur l'hébergement, ça permettra une gestion des risques plus efficasse pour elle. Nous parlons ici de manipulation de donnée à haute valeur pour une société.

Je te recommande donc d'évaluer le surcoût en terme de developpement pour toi d'inclure les deux solutions dès la version 1 de ta solution.

N'oublie pas qu'une solution "sous licence" et hébergé chez un client créé des contraintes techniques quant au déployement (initial et mis à jour). Cela doit être une partie intégrante de ton processus de développement.

Tu créer ton projet comme si c'était pour une entreprise, puis tu lunch un VM par entreprise et sur une page de connection unique lors de la connection tu vérifie l'identifiant/mot de passe/certificat/ip bref ce que tu veux et tu redirige vers un truc du genre https://ff45f54.tondomaine.fr/ avec ff45f54 un identifiant unique d'une entreprise qui envoi sur sa VM.

Merci pour vos réponses ! Je vais partir sur le fait que ce sont des petits organismes, donc le mode SaaS serait plus adéquat.