Bati : sécuriser l’accès (SSO, 2FA, rôles) + bonnes pratiques (2026)

Bati : sécuriser l’accès (SSO, 2FA, rôles) + bonnes pratiques (2026)

Quand Bati commence à être utilisé au quotidien (conducteurs de travaux, administratif, direction, sous-traitants), la sécurité des accès devient un sujet d’exploitation : comptes partagés, départs non gérés, sessions trop longues, et droits trop larges finissent toujours par créer un incident.

Dans ce guide, on déroule une approche simple et robuste pour sécuriser l’accès à Bati : SSO, 2FA/MFA, rôles (RBAC), et politiques de session.

Si vous n’avez pas encore une base “prod” propre (HTTPS + données persistantes + sauvegardes), commencez par : Bati : déployer sur adgents.cloud (HTTPS, sauvegardes, perf).

1) Le vrai objectif : donner le bon accès, au bon moment

Une sécurité efficace, ce n’est pas “mettre plus de friction”. C’est :

• éviter les comptes partagés (sinon impossible d’auditer)
• limiter les droits (principe du moindre privilège)
• maîtriser le cycle de vie (arrivées/départs, prestataires, intérim)
• tracer les actions sensibles (exports, suppression, changements de paramètres)

Dans une application B2B, le point clé est d’avoir un modèle d’identité clair : un utilisateur → une organisation → un rôle → des permissions.

Sur adgents.cloud, vous pouvez isoler les environnements (staging/prod), gérer des domaines, et activer des sauvegardes automatiques. Voir : Bati sur adgents.cloud.

2) SSO : la base dès que vous avez une équipe (ou plusieurs entités)

Le SSO (authentification unique) permet aux utilisateurs de se connecter via votre fournisseur d’identité (ex : Microsoft Entra ID/Azure AD, Google Workspace, Keycloak).

Deux bénéfices immédiats :

• onboarding/offboarding plus fiable (vous coupez l’accès à la source)
• politiques homogènes (mots de passe, restrictions, règles conditionnelles)

En pratique, vous rencontrerez surtout :

• SAML (très utilisé en entreprise)
• OpenID Connect (OIDC) (moderne, très courant pour web/mobile)

Bon réflexe : si vous activez le SSO, durcissez le compte IdP (MFA obligatoire, règles conditionnelles) car l’IdP devient un point critique.

3) 2FA/MFA : réduire drastiquement le risque de compromission

Le mot de passe seul ne suffit plus. Le minimum “serein” en 2026 : MFA au moins pour :

• les comptes admin
• l’accès depuis un nouvel appareil
• les actions sensibles (exports, changements de droits, suppression)

Côté méthode, l’ordre de préférence est généralement :

1. application d’authentification (TOTP)
2. notifications push
3. SMS / email (souvent plus simple, mais moins robuste)

Objectif : que la sécurité ne devienne pas un frein. Une MFA bien placée (contextuelle) protège sans “punir” l’utilisateur à chaque connexion.

4) Rôles (RBAC) : la différence entre “ça marche” et “c’est opérable”

RBAC (Role-Based Access Control) veut dire : vous attribuez des permissions via des rôles au lieu de bricoler des droits utilisateur par utilisateur.

Un découpage efficace pour Bati ressemble souvent à :

• Administrateur : configuration globale, gestion des utilisateurs
• Direction / contrôle : visibilité étendue, exports
• Chef de projet / conducteur : création/édition selon périmètre
• Compta / administratif : factures, documents
• Sous-traitant / externe : accès restreint à un projet, lecture limitée

Deux règles qui évitent 80% des problèmes :

• ne donnez jamais “admin” par défaut
• évitez les rôles “fourre-tout” : mieux vaut 5 rôles clairs que 2 rôles flous

5) Sessions : la partie souvent oubliée (et pourtant critique)

Même avec SSO + MFA, une session trop permissive peut ruiner l’effort. Pensez à :

• durée de session (adapter selon risque)
• expiration à l’inactivité
• déconnexion forcée en cas de changement de mot de passe ou retrait d’accès
• ré-authentification pour certaines actions sensibles

Et si des postes partagés existent sur chantier : prévoyez des sessions courtes et une déconnexion automatique stricte.

6) Onboarding / offboarding : process simple, auditable

C’est souvent là que ça casse :

• un prestataire garde un accès après la fin de mission
• un salarié part, mais son compte reste actif
• un compte “générique” circule

Checklist opérationnelle :

• création de compte nominatif
• attribution d’un rôle minimal
• MFA activée (au moins pour les comptes sensibles)
• revue des accès (mensuelle/trimestrielle)
• suppression / désactivation immédiate à la sortie

Si vous avez un staging, testez vos changements d’authentification (SSO, sessions) avant la production. Sur adgents.cloud, vous pouvez cloner une instance et ajuster CPU/RAM au besoin : héberger Bati sur adgents.cloud.

7) Journalisation et audit : pouvoir répondre vite en cas d’incident

Le but n’est pas d’empiler des logs “pour faire bien”, mais de pouvoir répondre à :

• qui s’est connecté ? quand ? d’où ?
• quels échecs d’authentification ?
• qui a changé des droits ?
• qui a exporté des données ?

Minimum recommandé :

• événements d’authentification (succès/échec)
• changements de rôles/permissions
• actions sensibles (exports, suppression)

Vidéo (YouTube, FR) : comprendre OpenID Connect

Pour une explication claire en français (OIDC, jetons, ce que ça change), vous pouvez regarder : .

Conclusion

Sécuriser l’accès à Bati sans perdre en fluidité, c’est surtout :

• SSO (SAML/OIDC) pour centraliser et maîtriser l’onboarding/offboarding
• MFA pour éviter qu’un mot de passe compromis ouvre toutes les portes
• RBAC pour limiter les dégâts et simplifier l’exploitation
• des sessions correctement configurées

Si vous voulez une base simple à opérer (déploiement rapide, backups automatiques, scaling, stop/start), vous pouvez lancer Bati ici : adgents.cloud — Bati.