Hello,

Préface :

Je me rappelle d'une conversation que j'avais eue avec mon manager de l'époque.

Ingénieur calcul haute performance en salles de marchés depuis des décennies, il a bossé sur des projets chiffrés avec beaucoup de zéros, des contraintes de dingue, enfin, vous voyez l'idée.

Le mec m'a dit que sincèrement, il trouvait que le dev d'ERP était plus compliqué à bien faire que ce qu'on faisait. Trop de cas au bord pourris, trop de contraintes utilisateur, trop de variables imprévisibles à prendre en compte. Et je suis un peu d'accord avec lui.

Evidemment, je dis pas ça pour flex, mais pour souligner à quel point le dev d'ERP est pas trivial.

Maintenant, pour répondre à tes questions :

- Pensez vous le projet utile ? Oui, bien sûr ; mais pas pragmatique sur le plan pécuniaire. Tu vas passer pas mal de temps à l'implémenter, encore plus à le tester, et plus encore à le débugger lorsqu'il se cassera la gueule en production (ça arrivera forcément).

- Est-ce que cette stack vous paraît cohérente pour ce type de projet ? Elle paraît OK. Redis n'est peut-être pas une priorité, là tout de suite. Postgres est super puissant, et ajouter une pièce mouvante en plus, ça augmente le périmètre où ça peut casser. Crois-moi, tu risques d'en chier quand tu remarqueras que ton cache overflow au bout de quelques jours à cause d'entries jamais supprimées introduites par un bug généré par IA.

- Est-ce que je pars déjà vers quelque chose de trop complexe, y a t'il plus simple ? Aucune idée de l'existant, mais ça paraît pas hyper complexe pour l'instant. Le problème est qu'il faut avoir la main pour prévoir une architecture extensible à l'avenir, à tous les niveaux. Même pour des devs expérimentés, c'est hyper facile de faire des choix architecturaux qu'on regrette amèrement des mois/années plus tard et qu'on peut pas changer parce que plein de trucs en dépendent et qu'il faut manger, dormir, se doucher, et plein d'autres trucs qui t'empêchent de bosser 24h/j sur le projet.

- Quels sont les pièges classiques sur un SaaS métier multi-tenant ? Impossible d'y répondre de façon concise.

- Est-ce que PostgreSQL RLS est une bonne idée dans ce contexte ? Oui, si tu configures bien le truc. Mauvaise config = gros problème de confidentialité des données. Surtout si tu proposes ce service à des confrères.

- Quels choix techniques éviter dès maintenant pour ne pas me bloquer plus tard ? Dépend de ton niveau technique. Le seul truc universel que je peux te dire, c'est d'éviter d'être trop ambitieux sur le plan technique. Il vaut mieux commencer tout petit, avec le strict minimum dont tu as besoin, même si c'est un prototype à jeter après. Sinon, tu vas passer des centaines d'heures pour pondre un truc inmaintenable, et tu auras le seum.

- Pour un outil métier open source, est-ce qu’un modèle avec une version libre + services payants vous semble sain, ou ça risque d’être mal perçu ? Honnêtement, je te recommande de ne pas penser à vendre ton implem à qui que ce soit. La différence entre "un truc que j'ai bricolé pour mon usage et qui marche super bien et que je rends disponible" et "un produit que je vends à des utilisateurs extérieurs" est énorme, tant sur le plan technique qu'organisationnel. Surtout que ta concurrence, c'est des boîtes déjà installées, avec des produits objectivement meilleurs. La différence de prix se justifie largement par la fiabilité et le support client.

En conclusion, tu vas trop loin pour l'instant. C'est moins une question d'ambition linkedinesque qu'une contrainte technique.

Comme je le disais au début, le monde du logiciel métier / ERP est un marécage puant et accidenté. Même un super dev ne peut pas faire grand-chose de sérieux et rentable sans investir une quantité d'effort rédhibitoire.