Le projet en un coup d’œil
Le navigateur attend une session confortable et protégée ; une API attend des appels sans état, des erreurs JSON stables et des jetons dont le cycle de vie reste borné.
Ciama associe chaque utilisateur à un compte, conserve ses rôles, protège le web par session et CSRF, puis authentifie l’API par jeton Bearer vérifié à chaque requête.
Trois niveaux hiérarchiques, un accès API d’une heure, un renouvellement de sept jours à usage unique et une fenêtre d’invitation de trente jours cadrent désormais les accès.
Quand un cockpit marketplace commence à réunir commandes, produits, stocks, offres, achats et connecteurs, son accès devient une fonction produit à part entière. Il ne suffit plus d’afficher une page de connexion : l’application doit savoir quelle identité agit, à quel compte elle appartient, si ce compte peut encore travailler et comment cette identité prouve sa session selon le canal utilisé.
Dawap a structuré cette fondation dans Ciama en séparant quatre notions souvent mélangées. L’utilisateur porte son identité et ses rôles. Le compte délimite le contexte de travail et possède un état actif. La session web sert la navigation humaine avec une protection CSRF. L’API reste sans état et exige un jeton Bearer signé dont l’identité est rechargée avant de laisser passer la requête.
Le résultat n’est pas présenté comme un système de permissions métier plus fin qu’il ne l’est. Ciama possède trois niveaux hiérarchiques — utilisateur, administrateur et super-administrateur — ainsi qu’un rôle fournisseur séparé. Le projet raconte précisément ce que cette base sécurise déjà, les contrôles qui l’accompagnent et les frontières qui restent à durcir dans le cadre de l’accompagnement marketplace vendeurs.
1. Ciama, un cockpit utilisé dans le navigateur et par des intégrations
Faire vivre la même identité sans confondre session humaine et contrat machine
Ciama ne se limite pas à une interface. Le back-office accompagne les opérations quotidiennes, tandis que l’API expose des ressources à des consommateurs techniques. Ces deux portes partagent les mêmes utilisateurs et les mêmes données, mais elles ne peuvent pas gérer leur session de la même manière.
Dans le navigateur, une personne se connecte par e-mail et mot de passe, puis navigue avec une session maintenue par le pare-feu web. Les formulaires sensibles ont besoin d’un jeton CSRF pour empêcher qu’un autre site déclenche une action à sa place. La déconnexion doit terminer ce contexte de navigation.
Dans l’API, conserver une session serveur pour chaque client compliquerait la montée en charge et le diagnostic. Chaque appel protégé apporte donc son propre jeton Bearer. Un jeton court réduit la durée d’exposition ; un mécanisme de renouvellement évite de redemander le mot de passe toutes les heures.
L’enjeu consistait à rendre ces parcours cohérents sans créer une illusion de sécurité. Un rôle global ne remplace pas une règle d’appartenance au compte. Une page intitulée « sécurité » ne prouve pas que toutes ses informations sont alimentées. Une invitation envoyée ne prouve pas que tout le rattachement d’équipe est terminé. Le projet sépare ces niveaux de maturité.
2. Faire évoluer l’accès avec le produit, puis vérifier chaque contrat
Du premier OMS d’octobre 2025 au durcissement API et compte de mars 2026
Le premier socle d’authentification accompagne le MVP OMS du 26 octobre 2025. Il fournit les entités utilisateur et compte, la connexion web, les rôles globaux et les premiers écrans d’administration. L’ajout de l’API le 11 novembre oblige ensuite à distinguer le contrat HTTP destiné aux intégrations de la session du navigateur.
Le 15 mars 2026 marque le principal durcissement. La connexion et le renouvellement API deviennent des cas d’usage distincts. Le jeton d’accès adopte une durée d’une heure. Le renouvellement passe dans Redis avec une durée de sept jours, une valeur aléatoire longue, un stockage sous empreinte et une rotation qui invalide l’ancienne valeur.
Le 18 mars, l’espace compte rassemble les utilisateurs rattachés au même compte et rend visibles leur rôle global ainsi que leur dernière activité connue. Cette vue apporte une lecture d’équipe utile, mais les indicateurs de plan, de facturation, de canaux et de double authentification affichés autour ne sont pas tous issus de données opérationnelles ; ils ne servent donc pas de preuve dans cette étude.
La méthode de validation repose sur les comportements réellement couverts : refus d’une API sans Bearer, contrat de connexion, erreurs de validation, refus des mauvais identifiants, renouvellement invalide, politique de mot de passe et cycle d’invitation. Les limites observées sont conservées dans la conclusion afin de guider le prochain lot plutôt que d’être masquées par un vocabulaire de gouvernance.
3. Avant la séparation : une connexion ne décrivait pas toute la frontière
Authentifier une personne ne suffit pas à cadrer son contexte de travail
Au début du cockpit, l’accès répondait au besoin immédiat : reconnaître un utilisateur avant d’ouvrir le back-office. Cette étape est nécessaire, mais elle laisse plusieurs questions sans réponse. Le compte est-il actif ? Quel rôle global possède la personne ? La ressource demandée appartient-elle à son compte ? La requête vient-elle du navigateur ou d’une intégration ?
Ces questions prennent de l’importance lorsque les modules se multiplient. Une offre, un stock, une commande ou une connexion fournisseur ne doit pas devenir visible simplement parce que l’identité possède le rôle minimal. L’autorisation combine au moins le droit d’entrer dans la zone et le droit de manipuler l’objet demandé.
L’API crée une difficulté supplémentaire. Une session web ne convient pas à un consommateur qui enchaîne des requêtes JSON. À l’inverse, demander au navigateur de gérer manuellement un renouvellement Bearer dégraderait un parcours humain qui sait déjà s’appuyer sur les mécanismes de session de Symfony.
Le projet a donc cessé de traiter « l’accès » comme une fonctionnalité unique. Il distingue l’authentification, le niveau de rôle, l’appartenance au compte, le cycle de session et la traçabilité de connexion. Cette décomposition rend chaque promesse vérifiable et chaque manque localisable.
4. Fixer quatre objectifs sans inventer une matrice de permissions
Une fondation sobre qui puisse être durcie progressivement
Le premier objectif était de protéger toutes les grandes zones privées. Les chemins du back-office et de l’API doivent refuser une identité absente. Seules la connexion, la documentation publique prévue et les deux adresses de renouvellement nécessaires restent accessibles sans rôle utilisateur.
Le deuxième objectif consistait à garder une seule identité de référence. L’e-mail charge l’utilisateur au moment de la connexion. Pour l’API, le jeton contient un identifiant, mais chaque requête recharge ensuite l’utilisateur existant. La suppression d’une identité ne doit pas laisser un simple contenu signé agir jusqu’à son expiration.
Le troisième objectif portait sur la durée. Le jeton d’accès devait rester court, tandis que le renouvellement devait être assez long pour préserver l’usage et assez strict pour ne pas être rejoué après rotation. Les durées d’une heure et de sept jours matérialisent cet équilibre.
Le quatrième objectif était éditorial autant que technique : ne pas confondre trois rôles globaux avec des permissions métier. Aucun profil commerce, stock, direction ou lecture seule n’est livré dans cette version. Cette honnêteté protège la roadmap, car le futur modèle pourra partir des actions réelles au lieu de s’aligner sur des profils fictifs.
5. Relier chaque utilisateur à une identité durable et à un compte
L’e-mail ouvre la session ; le compte fournit le contexte métier
L’utilisateur conserve son e-mail, son mot de passe chiffré, son prénom, son nom, son téléphone éventuel et sa liste de rôles. Ses dates de création, de mise à jour et de dernière connexion permettent de distinguer une identité existante d’une identité récemment active.
Le compte possède son propre identifiant, son nom et un état actif. Il devient la racine de nombreuses recherches métier : utilisateurs, produits, offres, commandes et connexions fournisseur peuvent être filtrés selon ce contexte. La personne connectée n’est donc pas seulement un e-mail ; elle entre dans un espace de travail déterminé.
Cette relation permet à la page de paramètres de chercher les membres avec l’identifiant du compte courant. Elle permet aussi aux contrôleurs métier les plus sensibles de vérifier que l’objet demandé appartient bien à ce compte avant de l’afficher ou de le modifier.
La relation ne dispense pas de contrôles explicites. Une entité reliée au compte ne bloque rien par magie : chaque route qui reçoit un identifiant doit appliquer la règle d’appartenance. Le projet assume cette distinction, car elle conditionne la solidité réelle d’une application multi-compte.
6. Organiser trois niveaux de rôle globaux
Utilisateur, administrateur et super-administrateur forment une hiérarchie simple
Le niveau utilisateur donne accès aux zones privées du back-office et de l’API. Le niveau administrateur hérite de cet accès. Le niveau super-administrateur hérite à son tour du niveau administrateur et porte une capacité technique supplémentaire prévue par Symfony.
Cette hiérarchie évite de répéter le rôle utilisateur sur un administrateur pour chaque contrôle de zone. Elle reste volontairement courte : un niveau supérieur reprend les capacités globales du niveau inférieur, puis les écrans peuvent ajouter une décision plus précise lorsqu’elle existe.
Un rôle fournisseur apparaît séparément dans le point d’entrée applicatif. Il oriente vers un espace fournisseur, mais ne fait pas partie de la chaîne utilisateur-administrateur-super-administrateur. Il ne faut donc ni le compter comme un quatrième niveau ni lui attribuer les droits d’administration par héritage.
La configuration prévoit aussi la capacité Symfony utilisée pour changer d’identité au niveau supérieur, mais la fonction de bascule elle-même n’est pas activée. La fiche ne la présente donc pas comme une fonctionnalité disponible. Déclarer une capacité héritée n’équivaut pas à livrer son parcours.
7. Conserver une session web adaptée à la navigation humaine
Formulaire, CSRF, destination et déconnexion restent dans le même pare-feu
Le navigateur utilise une connexion par formulaire. L’adresse e-mail sert d’identifiant et le composant de sécurité vérifie le mot de passe avec l’algorithme configuré automatiquement. Une fois la connexion acceptée, la session permet d’enchaîner les écrans sans renvoyer les identifiants à chaque page.
La protection CSRF est activée sur la connexion. Elle complète la vérification des identifiants en s’assurant que la soumission vient du formulaire attendu. Les mises à jour sensibles, comme le changement de mot de passe du profil, appliquent également leur propre jeton CSRF.
Après authentification, le parcours revient vers le point d’accès de l’application, qui choisit la destination selon le rôle reconnu. La déconnexion possède sa route dédiée. Ces mécanismes sont classiques ; leur valeur tient précisément au fait de ne pas réinventer une session propriétaire autour du cockpit.
Le pare-feu web reste chargé à la demande. La session n’est donc pas sollicitée pour les ressources publiques qui n’en ont pas besoin. Cette frontière est indépendante de l’API, dont le pare-feu est sans état et dont l’authentificateur attend un en-tête Bearer.
8. Donner à la connexion API un contrat JSON stable
Valider l’entrée, contrôler l’identité puis retourner une paire de jetons
La connexion API accepte un nom d’utilisateur ou un e-mail et un mot de passe dans un corps JSON. Un document vide, mal formé ou incomplet produit une erreur de validation structurée. De mauvais identifiants produisent une réponse non autorisée distincte, sans exposer la raison détaillée du refus.
Le cas d’usage charge l’identité, vérifie que son compte est actif, puis contrôle le mot de passe chiffré. Ce n’est qu’après ces étapes qu’il demande un jeton d’accès et crée un jeton de renouvellement. L’ordre évite d’émettre des valeurs de session pour une identité désactivée.
La réponse contient le jeton d’accès, son type Bearer, sa durée, sa date d’expiration et la valeur de renouvellement. Le consommateur dispose ainsi des informations nécessaires pour planifier son prochain renouvellement sans interpréter le contenu interne du jeton.
Deux adresses de renouvellement sont maintenues : l’adresse courante et une adresse historique. Leur présence évite de casser immédiatement les consommateurs existants pendant la transition. Elles appellent le même cas d’usage et produisent le même contrat de nouvelle paire.
9. Limiter le jeton d’accès à une heure
Un JWT signé transporte le minimum utile et reste vérifié côté application
Le jeton d’accès est signé en HS256 avec un secret exigé par l’environnement. Sa charge contient l’identifiant utilisateur, l’e-mail, les rôles, la date d’émission et l’expiration. La durée fixe de 3 600 secondes correspond à une heure.
À chaque requête API protégée, l’authentificateur exige l’en-tête Authorization au format Bearer. Il décode la signature et l’expiration, récupère l’identifiant de la charge, puis recharge l’utilisateur dans la base. Un jeton valide pour une identité qui n’existe plus est donc refusé.
Le niveau ROLE_USER reste nécessaire après l’authentification. Le contenu signé ne court-circuite pas le modèle de sécurité Symfony : il crée un passeport à partir de l’utilisateur courant et laisse le contrôle d’accès de la zone appliquer son exigence.
Un JWT d’une heure ne permet pas une révocation instantanée de toutes ses copies. Le rechargement de l’utilisateur réduit toutefois le risque lié à une suppression. Une révocation par session ou par appareil demanderait une liste d’état supplémentaire, qui ne fait pas partie de ce lot.
10. Faire du renouvellement un secret rotatif à usage unique
Sept jours de continuité sans conserver la valeur brute dans Redis
Le jeton de renouvellement est produit avec soixante-quatre octets aléatoires, puis encodé en 128 caractères hexadécimaux. Sa durée de vie est de 604 800 secondes, soit sept jours. Il n’est pas un JWT autonome : son état est conservé dans Redis.
La clé de stockage utilise une empreinte SHA-256 de la valeur remise au consommateur. Redis ne conserve donc pas le secret brut comme clé lisible. La charge associe l’utilisateur, l’expiration et un statut actif pendant la durée restante.
Lors d’un renouvellement, le stockage crée une nouvelle valeur et fait passer l’ancienne à l’état « rotated » avec sa durée restante. Le cas d’usage retrouve ensuite l’identité actuelle, vérifie que le compte reste actif, émet un nouveau jeton d’accès et retourne la nouvelle paire.
Après l’enregistrement du statut, une seconde utilisation séquentielle de l’ancien secret est refusée. La lecture, la création et le marquage ne forment toutefois pas encore une opération Redis atomique : deux demandes strictement concurrentes pourraient franchir la lecture active. Une transaction ou un script serveur reste nécessaire pour garantir l’usage unique sous concurrence.
11. Bloquer la création et le renouvellement de session API pour un compte inactif
L’état du compte reste relu au lieu d’être figé dans le jeton long
L’identité d’authentification ne porte pas un simple booléen indépendant. Lorsqu’un utilisateur possède un compte, l’état actif de ce compte détermine si l’identité est considérée active. Cette décision relie l’accès technique à la capacité opérationnelle de l’organisation.
La connexion API refuse donc un mot de passe pourtant correct si le compte est inactif. Le renouvellement applique la même règle lorsqu’il recharge l’identité. Un jeton de sept jours ne prolonge pas artificiellement l’accès d’un compte désactivé au moment où il demande une nouvelle paire.
Le jeton d’accès déjà émis reste borné par son heure de validité. Le contrôle actuel recharge l’utilisateur, mais ne démontre pas une révocation centrale de chaque JWT au changement d’état du compte. La durée courte reste ici le principal plafond temporel.
Cette règle constitue une base de suspension exploitable. Pour aller plus loin, le cockpit pourrait ajouter un numéro de version de session, une liste de révocation ou une vérification explicite de l’état du compte sur chaque requête. Ces mécanismes ne sont pas revendiqués dans la version présente.
12. Encadrer le changement de mot de passe du profil
Prouver l’ancien secret, confirmer le nouveau et exiger sa diversité
Depuis son profil, l’utilisateur doit fournir son mot de passe actuel avant toute modification. La requête POST exige également un jeton CSRF. Un secret actuel erroné ou un jeton de formulaire invalide interrompt le parcours sans modifier l’identité.
Le nouveau mot de passe et sa confirmation doivent être identiques. Sa longueur minimale est de douze caractères. Parmi majuscules, minuscules, chiffres et caractères spéciaux, au moins trois familles doivent être présentes.
Lorsque ces règles sont satisfaites, le composant de hachage Symfony produit la nouvelle valeur enregistrée. Le contrôleur n’écrit jamais le mot de passe en clair. La stratégie « auto » laisse le framework sélectionner l’algorithme adapté au type d’utilisateur et à l’environnement.
La même politique de douze caractères et trois familles est appliquée lors de la confirmation d’une invitation. Cette cohérence évite qu’un compte créé par invitation commence avec une exigence plus faible que celle demandée ensuite dans le profil.
13. Préparer l’invitation avec une fenêtre de trente jours
E-mail unique, jeton aléatoire, expiration et possibilité de renvoi
Le parcours d’invitation reçoit un e-mail, un rôle et l’identité de la personne qui invite. Il refuse un e-mail déjà utilisé par un utilisateur ou une invitation existante. Il crée ensuite un identifiant, un jeton d’inscription aléatoire et une expiration à trente jours.
L’envoi du message est confié à la file asynchrone. Le statut passe de « created » à « send » autour de cette transmission. Un renvoi refuse une invitation introuvable ou déjà confirmée, renouvelle le jeton et repousse son expiration de trente jours.
La confirmation vérifie l’existence, l’état et la date de l’invitation, puis exige prénom, nom et mot de passe conforme. Après création de l’utilisateur, l’invitation passe à l’état confirmé et son jeton d’inscription est supprimé.
Cette mécanique ne suffit pas encore à promettre un onboarding d’équipe autonome. Le parcours de confirmation transmet correctement l’e-mail et le rôle, mais le rattachement au compte invitant n’est pas achevé dans cette version. La fondation est donc décrite comme un cycle d’invitation à compléter, pas comme une délégation prête à déployer.
14. Historiser les authentifications réussies
Dernière activité, adresse réseau et contexte de navigation deviennent relisibles
Un succès d’authentification met à jour la date de dernière connexion de l’utilisateur. Il crée aussi un événement distinct associé à cette identité. L’abonné n’étant pas limité au pare-feu web, cette trace peut également accompagner l’authentification Bearer des requêtes API.
Le User-Agent est interprété pour distinguer plusieurs navigateurs, leur version, le système d’exploitation et un type d’appareil desktop, mobile ou tablette. Les valeurs inconnues restent explicitement inconnues plutôt que d’empêcher l’enregistrement de l’événement.
La vue d’un utilisateur peut charger ses dix derniers événements par défaut avec pagination. Cette trace permet d’examiner des authentifications réussies et de rapprocher une activité récente d’un navigateur ou d’un appareil déclaré.
Il ne s’agit pas d’un journal exhaustif de toutes les décisions métier. Les consultations, exports, validations, changements de marge ou corrections de stock ne sont pas automatiquement couverts par cet événement. Le projet parle donc d’historique de connexion, jamais de traçabilité complète des actions.
15. Afficher les membres du compte sans transformer la maquette en donnée
Huit identités au maximum, un rôle lisible et une dernière activité réelle
La page de paramètres récupère le compte de la personne connectée, puis recherche jusqu’à huit utilisateurs portant cet identifiant de compte. Elle compose pour chacun un nom, un e-mail, un rôle lisible et une date de dernière activité.
Le libellé « Owner » correspond au super-administrateur, « Admin » à l’administrateur, et « User » aux autres rôles dans cette vue. La dernière activité reprend la dernière connexion lorsqu’elle existe, ou la date de création comme point de repli.
Cette liste donne un aperçu concret de l’équipe rattachée au compte. Elle ne prouve toutefois ni un nombre de sièges souscrits, ni un niveau de forfait, ni un état de double authentification. Ces éléments présents dans l’interface restent aujourd’hui des données de présentation.
L’étude de cas limite donc son résultat public à ce qui est réellement alimenté : les membres filtrés par compte, leur identité, leur niveau global et leur activité connue. Cette discipline évite qu’une belle page d’administration devienne une fausse preuve de gouvernance.
16. Appliquer l’appartenance au compte là où la donnée métier l’exige
Le rôle ouvre une zone ; le compte doit encore protéger chaque ressource
De nombreux écrans métier récupèrent le compte courant et l’utilisent pour filtrer leurs recherches ou vérifier l’objet demandé. Cette méthode est essentielle pour les produits, offres, commandes, fournisseurs et connexions dont l’identifiant seul ne doit jamais suffire.
La recherche d’utilisateurs applique elle aussi le compte courant. Elle limite les résultats, pagine et peut ajouter une recherche textuelle. La page équipe des paramètres suit la même logique pour sa liste de membres.
En revanche, l’autorisation centralisée ne couvre pas encore toute l’administration utilisateur historique. La généralisation des contrôles d’appartenance fait donc partie des suites nécessaires avant de parler d’administration multi-compte complète.
Cette limite explique pourquoi la hiérarchie globale reste une fondation. Le prochain niveau de maturité doit centraliser les décisions d’autorisation, vérifier systématiquement le contexte cible et réserver les opérations d’administration aux rôles attendus, avec des scénarios de refus entre comptes.
17. Tester les contrats d’accès plutôt que la seule page de connexion
Les refus font partie du comportement attendu
La campagne API vérifie qu’une route protégée refuse l’absence de Bearer avec un statut 401 et une erreur JSON standard. Elle vérifie aussi que les deux adresses de renouvellement restent résolues, afin de préserver la compatibilité du contrat historique.
La connexion est testée avec une paire valide, un contenu incomplet et de mauvais identifiants. Les assertions portent sur la présence des deux jetons, du type, de la durée et de l’expiration, puis sur les codes d’erreur distincts pour la validation et l’authentification.
Le renouvellement couvre l’absence de valeur et une valeur invalide. Les cas d’usage unitaires et d’intégration complètent ces parcours autour de l’identité active, de la rotation et de l’émission de la nouvelle paire.
Côté web, les contrôles couvrent l’ancien mot de passe incorrect, la confirmation différente, un secret trop faible et une mise à jour valide. L’invitation couvre notamment le cas valide, l’absence, la double confirmation, l’expiration et la politique de mot de passe. Les frontières entre comptes restent le principal lot de refus à généraliser.
18. Choisir des mécanismes standards et des durées explicites
La simplicité réduit les zones de sécurité invisibles
Le web s’appuie sur le formulaire, la session et le CSRF de Symfony. L’API utilise un pare-feu sans état et un authentificateur Bearer dédié. Ce partage des responsabilités évite de faire transiter un jeton API dans tous les formulaires ou de créer une session serveur pour chaque intégration.
Le JWT d’accès reste autonome pendant une heure, mais l’utilisateur est rechargé à chaque requête. Le renouvellement garde au contraire un état dans Redis pendant sept jours. Cette combinaison réserve l’état serveur au secret qui doit être rotatif et utilisé une seule fois.
Le stockage par empreinte limite l’exposition du jeton long en cache. La conservation de l’ancienne empreinte avec le statut « rotated » bloque sa réutilisation séquentielle pendant sa durée résiduelle. La valeur longue reste uniquement entre les mains du consommateur qui vient de la recevoir.
Enfin, trois niveaux globaux ont été préférés à une multitude de rôles non reliés à des règles effectives. Une future matrice métier devra nommer les ressources, les actions et les conditions. Ajouter des libellés avant ces décisions aurait produit de la complexité sans autorisation vérifiable.
19. Passer d’une porte d’entrée unique à un modèle d’accès explicable
Chaque refus peut être rattaché à une étape précise
Avant ce durcissement, parler de « gestion des accès » risquait de mélanger connexion, rôle, compte et session. Après la livraison, chaque responsabilité possède son mécanisme : le fournisseur d’utilisateurs charge l’identité, le compte porte son état, la hiérarchie ouvre les zones et le canal choisit son cycle de session.
Pour une intégration, le contrat devient prévisible. Elle obtient une paire, utilise le Bearer pendant une heure, renouvelle avec une valeur valable sept jours puis remplace immédiatement cette valeur. Une erreur indique si l’entrée est incomplète, les identifiants invalides ou le renouvellement expiré.
Pour un utilisateur web, la connexion reste simple. La protection CSRF, la session, la déconnexion et le changement de mot de passe s’insèrent dans le parcours attendu. La dernière connexion et ses événements offrent un premier niveau de relecture sans prétendre auditer toute l’activité métier.
Pour l’équipe produit, le gain le plus important est la lucidité. Les rôles disponibles, les limites multi-compte, la portée de l’invitation et les données réellement alimentées sont identifiés. La prochaine décision peut donc viser le bon manque au lieu de refaire une couche d’interface.
20. Nommer les limites avant d’étendre la gouvernance
La prochaine étape porte sur l’autorisation métier, pas sur de nouveaux intitulés
La version actuelle ne fournit pas de profils commerce, opérations, stock, direction ou lecture seule. Elle ne sépare pas systématiquement consultation, modification, export et validation. Toute présentation d’une gestion fine des droits serait donc prématurée.
L’appartenance au compte est bien utilisée dans plusieurs recherches et contrôles métier, mais elle doit être généralisée aux routes historiques d’administration utilisateur. La même campagne devra vérifier qu’une identité d’un compte ne peut ni voir ni modifier celle d’un autre compte.
Le cycle d’invitation possède son e-mail, son jeton, son expiration, son renvoi et sa confirmation. Son rattachement final au compte invitant reste à compléter. Les rôles acceptés à l’entrée devront aussi être limités selon le rôle de la personne qui invite.
Aucune double authentification active n’est revendiquée, aucune bascule d’identité n’est annoncée et l’historique d’authentification ne remplace pas un journal métier. La rotation Redis doit en outre devenir atomique pour garantir l’usage unique en concurrence. Ces limites définissent précisément le travail nécessaire pour transformer la fondation en gouvernance complète.
21. Relier les accès aux fonctions qu’ils doivent réellement protéger
Le compte et la session prennent leur sens dans les parcours marketplace
Le centre de contrôle produit de Ciama réunit huit vues autour d’une même référence. Sa richesse montre pourquoi un simple droit d’entrée doit évoluer vers des décisions par ressource et par action.
Le centre de contrôle des connecteurs applique déjà le compte et la fonction pour déterminer les fournisseurs visibles et activables. Il donne un exemple concret de frontière métier à généraliser au-delà des rôles globaux.
Le socle on-premise en images Docker testées porte enfin Redis, le web et les processus nécessaires au cycle d’authentification. L’accès applicatif dépend aussi d’un runtime correctement configuré et d’un secret déployé hors du contenu public.
Ces chantiers prolongent l’accompagnement marketplace vendeurs : construire les fonctions utiles, définir leurs frontières, éprouver les refus et faire évoluer la gouvernance au même rythme que le cockpit.
22. Conclusion
La meilleure preuve d’accès est celle qui distingue déjà le livré du prochain durcissement
Ciama dispose désormais d’une architecture d’accès compréhensible : une identité reliée à un compte, trois niveaux de rôle, une session web protégée, une API Bearer sans état, un jeton court d’une heure et un renouvellement rotatif de sept jours. Les invitations et les événements de connexion complètent cette fondation.
La force du projet ne vient pas d’une longue liste de profils fictifs. Elle vient des contrats mesurables, des refus testés et des limites explicites. L’invitation doit encore achever son rattachement au compte ; certaines routes utilisateur doivent généraliser la frontière multi-compte ; les permissions métier restent à concevoir par ressource et par action.
C’est ainsi que Dawap aborde l’accompagnement marketplace vendeurs : sécuriser ce qui existe, ne pas masquer la maturité, puis transformer les usages réels en règles d’autorisation testables et durables.
