InfraDZ Software
Suite ERP et point de vente pour les PME : stock, ventes, achats, devis et factures, sur le web et en application de bureau, avec des droits d'accès par module et par rôle.
- Mon rôle
- Ingénieur Full Stack
- Période
- avr. 2026 — mai 2026
- Statut
- Livré
InfraDZ est une suite de gestion pour les PME qui réunit stock, ventes, achats, facturation et caisse au sein d'une même plateforme. Chaque entreprise fonctionne comme un tenant, l'entité de premier niveau présente dans les 74 tables du schéma PostgreSQL, et les droits d'accès s'accordent module par module.
Le produit est livré sur deux surfaces à partir d'un seul code source : un client web React et une application de bureau Tauri v2 qui référence exactement les mêmes sources React. La connexion prend en charge email/mot de passe, OTP et Google OAuth via un schéma hybride cookie + Bearer, et l'interface s'adapte aux permissions de chaque utilisateur, jusqu'à une barre latérale qui ne liste que ce que le rôle est autorisé à ouvrir.
Le problème à résoudre
La difficulté consistait à servir de nombreuses entreprises indépendantes depuis un même système sans que leurs données ne se mélangent. Un tenant qui n'exploite qu'une caisse ne doit pas voir les autres modules ; un caissier ne doit pas voir les écrans d'achats ; et un commerce qui supprime un produit vendu le mois précédent ne doit pas corrompre son propre historique. À cela s'ajoutait le fait que le produit devait exister à la fois en application web et en application de bureau installable — ce qui impose habituellement de maintenir deux frontends.
Comment cela a été construit
La multi-location est structurelle, pas ajoutée après coup : « tenant » est l'entité de premier niveau dans les 74 tables du schéma comme dans le code, et les droits d'accès se définissent module par module pour chaque tenant. Les permissions voyagent avec la session — /auth/me les renvoie — et le client verrouille tout via un hook useCan, un composant <Can> et une barre latérale filtrée par permission : les écrans qu'un rôle ne peut pas utiliser ne sont tout simplement jamais rendus.
La question du bureau a été résolue avec Tauri v2 : l'application de bureau référence les sources React du client web, un seul code produisant les deux builds. La sécurité des données repose sur une convention stricte de suppression douce — les données de référence passent à isActive=false et restent restaurables, jamais supprimées définitivement — ce qui garantit que les documents historiques pointent toujours vers des enregistrements existants. Le module caisse partage un type Article maître unique avec le reste de la suite : un produit est défini une fois et se comporte de la même façon en caisse et en stock.
Ce que ça fait
Cœur multi-tenant
Chaque table et chaque chemin de code est rattaché à une entité tenant de premier niveau, isolant les données de chaque entreprise dans les 74 tables du schéma.
Droits d'accès par module
Stock, ventes, achats, facturation et caisse sont des modules distincts : chaque entreprise n'accède qu'à ceux qu'elle utilise.
Authentification hybride
Sessions cookie + Bearer avec connexion par email/mot de passe, OTP et Google OAuth.
Interface filtrée par permissions
Un hook useCan, un composant <Can> et une barre latérale filtrée masquent tout ce que le rôle ne peut pas manipuler, à partir des permissions renvoyées par /auth/me.
Bureau à source unique
Le build de bureau Tauri v2 référence les mêmes sources React que le client web : un seul code, deux plateformes.
Suppression douce systématique
Les données de référence ne sont jamais supprimées définitivement : les enregistrements passent à isActive=false et peuvent être restaurés, préservant l'historique référentiel.
Construit avec
Frontend
Un seul code React alimente à la fois le client web et l'application de bureau Tauri v2 : chaque écran ERP et caisse est écrit une fois et livré sur les deux plateformes.
Le typage statique rend le type Article partagé et les contrats de permissions vérifiables à la compilation — condition pour livrer sereinement un même code en builds web et bureau.
Backend
Faire tourner l'API sous Node garde serveur et client dans le même langage : des contrats comme les permissions renvoyées par /auth/me ou le type Article partagé restent alignés sur toute la pile.
Données
Un schéma relationnel de 74 tables exige de vraies clés étrangères : PostgreSQL rattache chaque ligne à son tenant et permet à la suppression douce de préserver des références qu'un DELETE définitif casserait.
Infrastructure
Les conteneurs figent l'API et PostgreSQL dans des versions identiques d'un environnement à l'autre — indispensable pour un déploiement multi-tenant qui sert de nombreuses entreprises depuis une même pile.