Un client retrouve son devis, dépose une pièce manquante et suit sa demande depuis un seul espace. Votre équipe sait ce qui a été transmis, par qui et pour quelle entreprise. Un extranet client WordPress bien conçu peut simplifier ces échanges, à condition de protéger chaque document et chaque opération, pas seulement la page de connexion.
WordPress peut fournir le socle du portail et GreenShift son interface. Il faut cependant concevoir les relations entre comptes, entreprises et ressources, le stockage des fichiers, les accès aux API et les procédures de maintenance. Installer un thème et masquer quelques blocs ne suffit pas à obtenir un extranet confidentiel.
Ce guide détaille une architecture possible, ses limites et les vérifications à effectuer avant ouverture. Les modèles de données, noms de routes et règles proposés sont des exemples de conception à adapter ; ils ne décrivent pas un module prêt à installer ni une certification de sécurité.
Les étapes de conception
- Définir le besoin et les limites de WordPress
- Séparer identité, données et interface
- Modéliser les entreprises clientes et leurs droits
- Contrôler chaque accès côté serveur
- Protéger les dépôts et téléchargements
- Construire le tableau de bord avec GreenShift
- Connecter Dolibarr et n8n
- Organiser les données personnelles
- Tester l’étanchéité et préparer la mise en production
Extranet, espace membre et page privée : des besoins différents
Un espace membre distribue souvent des contenus selon une inscription ou un abonnement. Un extranet organise aussi des échanges métier : dossiers, demandes, pièces jointes, validations et informations provenant d’un ERP. Ces catégories peuvent se recouvrir, mais elles n’impliquent pas les mêmes règles d’accès.
| Besoin | Question à résoudre | Conséquence technique |
|---|---|---|
| Ressources communes | Tous les utilisateurs habilités voient-ils les mêmes documents ? | Droits par groupe et protection des fichiers |
| Dossiers clients | Quels collaborateurs peuvent consulter quel dossier ? | Relation entre utilisateur, organisation et dossier |
| Demandes et pièces jointes | Qui peut créer, répondre ou clôturer ? | Permissions distinctes et transitions contrôlées |
| Devis ou factures | Quel système fait foi et quelle donnée afficher ? | Intégration ERP limitée au périmètre autorisé |
| Espace partenaire | Un partenaire travaille-t-il pour plusieurs entreprises ? | Adhésions multiples et séparation des contextes |
Le statut « privé » d’une page WordPress suit les capacités du compte. Il ne crée pas à lui seul une autorisation par entreprise cliente, et un simple abonné ne reçoit pas automatiquement le droit de lire toutes les pages privées. Une protection par mot de passe partagé ne donne pas non plus une identité individuelle fiable. Les rôles et capacités WordPress constituent une base, à compléter par les règles métier.
Quand WordPress est-il un choix pertinent ?
Il peut convenir à un portail documentaire, un suivi de demandes ou une interface client reliée à des services existants, si l’équipe sait maintenir cet ensemble. Il permet de réutiliser les contenus éditoriaux et une interface de publication connue. Le choix doit toutefois être validé sur les accès, les volumes de données et les intégrations réelles.
Des exigences d’isolation fortes, des processus transactionnels complexes ou un cadre sectoriel particulier peuvent orienter vers une application dédiée ou un service spécialisé. Le nombre de comptes seul ne permet pas de trancher : cent utilisateurs réalisant de gros exports simultanés peuvent solliciter davantage le système que plusieurs milliers de comptes rarement actifs.
Auto-héberger donne davantage de maîtrise, mais transfère aussi la responsabilité de l’exploitation. Les emails, sauvegardes, outils d’analyse et connecteurs restent des dépendances à inventorier. La maîtrise des données ne se déduit pas du seul lieu où tourne WordPress.
Une architecture qui sépare les responsabilités
| Composant | Responsabilité proposée | Limite à respecter |
|---|---|---|
| WordPress | Comptes, contenu et point d’entrée applicatif | Ne connaît pas spontanément les droits propres à chaque entreprise |
| Plugin métier ou service dédié | Organisations, dossiers, autorisations et états | Les règles doivent être centralisées et testées |
| GreenShift | Présentation des données autorisées et interactions | L’interface ne décide pas seule de l’accès |
| Blocksy ou autre thème adapté | Structure et cohérence visuelle | Ne doit pas contenir toute la logique métier |
| Stockage privé | Conservation des fichiers et distribution contrôlée | Pas de contournement par une URL publique |
| Dolibarr | Référentiel des informations commerciales retenues | L’API ne doit pas être exposée avec un compte trop puissant |
| n8n | Notifications, synchronisations et reprises | Ne remplace pas l’autorisation lors de la consultation |
Le parcours proposé est simple : le navigateur contacte le portail, le serveur identifie l’utilisateur, détermine ses droits puis retourne uniquement les informations admises. Le service métier interroge le stockage ou l’ERP si nécessaire. Un appel refusé s’arrête avant la transmission des données confidentielles au navigateur.
Je recommande de placer les règles métier dans un composant indépendant du thème. Changer une mise en page ne doit pas changer les autorisations. Un plugin spécialisé peut remplir ce rôle si ses fonctions correspondent au besoin ; un développement sur mesure devient pertinent lorsque les relations et processus sortent de son modèle.
La combinaison Blocksy et GreenShift peut fournir la présentation. Mon approche WordPress Native-First vise à limiter les dépendances inutiles, sans prétendre supprimer les composants nécessaires à une application métier.
Exemple suivi : un portail utilisé par plusieurs entreprises
Prenons un scénario fictif. Une société de services accompagne les entreprises Alpha et Bêta. Alpha possède deux collaborateurs : Alice suit les dossiers, Bruno consulte uniquement les documents comptables. Claire, chargée de projet chez le prestataire, suit certains dossiers des deux entreprises. Une quatrième personne intervient pour deux clients et doit pouvoir changer de contexte sans mélanger leurs informations.
Un unique rôle WordPress « client » ne décrit pas ces relations. Il indique éventuellement une catégorie de fonctions, mais ne dit pas à quels dossiers une personne appartient. L’entreprise cliente doit être un objet distinct du compte utilisateur.
Un modèle de données minimal
| Objet | Champs ou relations proposés | Règle à prévoir |
|---|---|---|
| Organisation | Identifiant, nom, état, référence ERP | Une organisation désactivée ne donne plus d’accès actif |
| Adhésion | Utilisateur, organisation, profil, état, échéance éventuelle | Un utilisateur peut avoir plusieurs adhésions contrôlées |
| Dossier | Organisation, responsable, statut | Le propriétaire métier n’est pas fourni librement par le navigateur |
| Document | Dossier, version, clé de stockage, état de publication | Chaque version conserve son rattachement et son niveau d’accès |
| Demande | Dossier, auteur, état, historique | L’auteur ne détermine pas à lui seul tous les droits |
| Événement | Acteur, action, ressource, résultat, date | Le journal doit rester exploitable sans recopier tous les contenus |
Ce modèle est un choix de conception, pas le schéma standard de WordPress. Les objets peuvent être stockés dans des types de contenus personnalisés, des tables dédiées ou un service externe. Le choix dépend notamment des relations, recherches et volumes attendus. Une table dédiée demande ses propres migrations, index, sauvegardes et outils d’administration.
Avec des types de contenus personnalisés, examinez les paramètres d’exposition, les archives, la recherche, les capacités et l’API REST. La documentation de register_post_type() décrit ces réglages. Déclarer un type non public aide à limiter son exposition, mais ne sécurise pas un endpoint personnalisé qui lirait directement ses données.
Écrire la matrice des droits avant le design
| Profil illustratif | Consulter un dossier | Déposer une pièce | Voir les factures | Inviter un membre |
|---|---|---|---|---|
| Collaborateur client | Dossiers autorisés de son entreprise | Si le dossier accepte les dépôts | Seulement avec droit financier | Non |
| Responsable client | Selon son mandat dans l’entreprise | Selon le dossier | Seulement avec droit financier | Si une délégation explicite le permet |
| Chargé de projet interne | Dossiers qui lui sont attribués | Selon ses fonctions | Si nécessaire à sa mission | Selon procédure interne |
| Administrateur technique | Accès technique privilégié | Fonction d’administration | Accès à encadrer et journaliser | Gestion contrôlée |
Cette matrice doit être validée par le responsable métier. Le responsable d’une entreprise cliente ne devient jamais administrateur WordPress pour pouvoir inviter un collègue. Une fonction spécifique gère l’invitation dans son périmètre, avec des profils attribuables limités.
L’isolation entre clients ne protège pas automatiquement contre l’administrateur de l’application ou du serveur. Si certains opérateurs ne doivent pas pouvoir lire les documents, il faut un modèle de confiance et de chiffrement adapté. Le chiffrement du disque seul ne garantit pas cette séparation lorsque l’application peut déchiffrer les fichiers.
Authentification et autorisation : deux contrôles distincts
L’authentification établit qui agit. L’autorisation décide si cette personne peut accomplir cette action sur cette ressource. Un utilisateur correctement connecté peut être parfaitement légitime pour Alpha et interdit d’accès aux documents de Bêta.
Le contrôle doit s’appliquer aux listes, fiches, pièces jointes, exports et modifications. Les principes de contrôle d’accès de l’OWASP recommandent notamment le refus par défaut et la vérification des permissions à chaque requête. Une règle doit être explicite lorsqu’un utilisateur interne bénéficie d’un périmètre différent.
Règle illustrative pour télécharger un document :
1. Identifier une session valide et un compte autorisé.
2. Charger les métadonnées du document demandé.
3. Déterminer son dossier et son organisation côté serveur.
4. Vérifier l’adhésion active et la capacité de téléchargement.
5. Vérifier le droit sur ce dossier et l’état du document.
6. Contrôler les éventuelles restrictions supplémentaires.
7. Distribuer le fichier et journaliser le résultat.
En l’absence de règle qui autorise l’action : refuser.Ce pseudo-code expose une politique, pas un code PHP de production. Le traitement réel doit aussi valider les entrées, gérer les erreurs et maintenir une cohérence si les droits changent pendant une opération. Une fonction centrale d’autorisation réduit le risque d’avoir des règles différentes selon l’écran.
Changer un identifiant ne doit jamais changer les droits
Le problème classique consiste à consulter une ressource d’un autre client en modifiant un identifiant dans l’adresse ou dans une requête. L’OWASP décrit cette famille de défauts sous le terme IDOR. Un identifiant aléatoire rend la découverte moins facile, mais ne remplace pas le contrôle de propriété.
Dans notre exemple, Alice ne doit obtenir ni le fichier de Bêta, ni son titre, ni son montant dans une réponse d’erreur. Le compte des résultats, les suggestions de recherche et les exports doivent également rester dans le périmètre autorisé. Filtrer seulement l’affichage après avoir envoyé toutes les données au navigateur divulgue déjà l’information.
Sécuriser les routes REST et les actions
Une route telle que /wp-json/extranet/v1/documents/456 serait une route à développer, pas une fonction native de WordPress. Sa permission_callback doit vérifier les droits pertinents. Pour les listes, la requête doit se limiter aux ressources autorisées ; pour une fiche, le contrôle porte sur l’objet demandé. La documentation des endpoints personnalisés décrit cette séparation.
Pour une interface utilisant la session WordPress dans le navigateur, l’authentification REST par cookies s’accompagne du nonce prévu pour l’API, généralement transmis dans X-WP-Nonce. Il faut gérer son expiration et les retours de session expirée. Pour les intégrations serveur, utilisez un mécanisme adapté et des identifiants dédiés.
Un nonce WordPress contribue à prévenir les requêtes intersites non souhaitées. Il ne remplace ni l’identité ni l’autorisation et n’est pas un jeton à usage unique garanti. Il ne faut pas non plus utiliser un lien GET pour une suppression ou une validation métier ayant un effet durable.
Validez les champs acceptés : le navigateur ne doit pas pouvoir modifier arbitrairement l’organisation propriétaire, les droits ou un statut réservé à l’équipe. Chaque transition mérite sa propre règle. Passer une demande de « brouillon » à « envoyée » n’accorde pas le droit de la marquer « traitée ».
Documents confidentiels : protéger le fichier lui-même
Dans une installation WordPress classique, un fichier placé dans le dossier public des médias peut être servi directement par le serveur web. Protéger la page qui contient son lien, ou son éventuelle page de pièce jointe, ne protège donc pas nécessairement les octets du fichier. Cette propriété doit être testée avec un navigateur déconnecté.
Pour Alpha, le bouton « Télécharger la facture » doit appeler un mécanisme qui vérifie les droits. Le document ne doit pas rester disponible par une seconde adresse publique, une miniature, une ancienne version ou une copie créée pour la prévisualisation. Le périmètre couvre tous les dérivés du fichier.
| Approche | Principe | Limite à examiner |
|---|---|---|
| Stockage hors racine publique | Un contrôleur autorisé distribue le fichier | Débit, mémoire et durée des transferts |
| Distribution déléguée au serveur web | L’application autorise, puis le serveur transmet | Configuration interne et absence d’URL directe |
| Stockage objet privé | Accès via une passerelle ou un lien signé temporaire | Partage du lien et révocation avant expiration |
| Solution documentaire dédiée | Le portail délègue la gestion documentaire | Identités, droits, contrats et exports à intégrer |
Avec nginx, un emplacement déclaré internal et une distribution via X-Accel-Redirect peuvent séparer autorisation applicative et transfert du fichier. La documentation nginx décrit ce mécanisme. Sur Plesk, son intégration dépend de la configuration effective nginx/Apache : une règle destinée à Apache seule peut ne pas couvrir un fichier servi directement par nginx.
Le chemin de stockage doit être résolu à partir d’un identifiant connu côté serveur. Il ne doit pas être assemblé librement depuis un chemin envoyé par l’utilisateur. Protégez aussi les noms de fichiers et les en-têtes de téléchargement ; une erreur ne doit pas révéler un chemin interne ou une configuration.
Ce qu’un lien temporaire garantit — et ce qu’il ne garantit pas
Un lien signé limite généralement l’accès à une ressource pendant une durée donnée. Selon le mécanisme, toute personne possédant ce lien peut l’utiliser jusqu’à son expiration. Une révocation du compte ne l’invalide pas forcément immédiatement. Si la révocation à chaque lecture est exigée, préférez un passage systématique par un service qui réévalue l’autorisation.
Une fois téléchargé légitimement, un fichier peut être conservé, photographié ou transmis. Un portail classique ne peut pas le retirer du disque d’un client. Le cahier des charges doit distinguer le contrôle des accès futurs de la maîtrise des copies déjà remises.
Sécuriser le dépôt de fichiers et leurs traitements
Définissez les formats réellement nécessaires, la taille maximale, les quotas et les comptes autorisés à déposer. Contrôlez le type détecté et le contenu lorsque c’est possible : l’extension et le type MIME déclarés par le navigateur ne suffisent pas. Stockez les fichiers sous un identifiant interne et empêchez leur exécution.
La fiche OWASP sur les téléversements recommande une défense combinant plusieurs contrôles. Selon le risque, prévoyez une analyse antivirus ou un traitement de neutralisation approprié. Aucun scanner ne prouve à lui seul qu’un fichier est inoffensif ; les outils d’extraction et de prévisualisation doivent aussi être maintenus et isolés.
Dans notre portail, une pièce suit par exemple les états « reçue », « en contrôle », « disponible » ou « rejetée ». Elle ne devient pas téléchargeable avant la validation attendue. Si l’analyse est indisponible, le système conserve l’état en attente au lieu de déclarer le fichier sûr.
Les archives compressées et les fichiers chiffrés demandent un traitement particulier : leur contenu peut être impossible à inspecter ou provoquer une consommation excessive de ressources. Pour un premier portail documentaire, refuser les formats sans besoin métier identifié simplifie l’exploitation et les tests.
Invitations, MFA, sessions et départs des utilisateurs
Le cycle de vie des comptes doit être conçu dès le départ. Qui crée une entreprise ? Qui valide son premier responsable ? Qui peut inviter un collègue ? Que devient l’accès lorsque le contrat se termine ou qu’un salarié quitte l’organisation ? Un portail reste vulnérable si ces décisions reposent sur des manipulations informelles.
Inviter sans permettre l’auto-attribution de droits
Une invitation doit viser une identité et une organisation déterminées, avec un profil prédéfini, une expiration et un traitement qui empêche sa réutilisation après acceptation. Vérifiez que l’invitant possède encore les droits requis au moment de l’acceptation. Le domaine de l’adresse email, à lui seul, ne prouve pas qu’une personne représente une entreprise.
Pour les comptes partagés, il devient difficile de distinguer les auteurs d’une action et de retirer l’accès à une seule personne. Privilégiez les comptes nominatifs. Un utilisateur travaillant pour Alpha et Bêta reçoit deux adhésions, pas un pouvoir global sur tous les clients.
Prévoir la récupération avec autant de soin que la connexion
Je recommande une authentification multifacteur pour l’administration et les comptes exposés à des données sensibles, avec une politique adaptée aux autres profils. La recommandation de la CNIL sur la MFA traite aussi les données personnelles associées à ce dispositif. Le choix dépend du risque et des conditions d’utilisation ; il n’existe pas une obligation universelle identique pour tous les extranets.
La réinitialisation d’un mot de passe, la perte du second facteur et le changement d’email doivent avoir une procédure vérifiable. Une demande informelle au support ne doit pas permettre de contourner l’authentification. Testez ces opérations avec de vrais profils de test, y compris les cas d’adresse devenue inaccessible.
Révoquer effectivement les accès
La gestion des sessions décrite par l’OWASP distingue notamment les limites d’inactivité, les durées maximales et la fermeture des sessions. Leur choix doit correspondre aux usages. Une session interrompue brutalement au milieu d’un long formulaire peut aussi provoquer des pertes de travail ; avertissement et reprise contrôlée améliorent l’expérience.
Dans l’application proposée, retirer une adhésion doit bloquer les nouvelles requêtes concernées, même si la session du compte existe encore. Il faut également traiter les jetons d’intégration, les liens temporaires et les caches. Une extension de désactivation de compte doit être évaluée sur ces effets réels : cacher le bouton de connexion ne suffit pas.
Construire une interface GreenShift utile et accessible
Le tableau de bord doit aider le client à comprendre ce qu’il peut faire : voir les demandes en attente, retrouver les documents et identifier les prochaines actions. Pour Alpha, je proposerais un résumé des dossiers actifs, une liste des pièces attendues et un accès aux documents financiers seulement pour les personnes habilitées.
La documentation de l’API Connector de GreenShift distingue des appels côté serveur et côté navigateur, avec possibilités d’affichage dynamique. Les options disponibles doivent être vérifiées dans la version et les extensions utilisées. Le mode navigateur expose les appels et les données qu’il reçoit : aucun secret d’ERP ne doit y être placé.
Le rendu conditionnel aide à présenter les bonnes actions. Sa portée dépend toutefois du mécanisme employé : ne pas rendre un bloc côté serveur est différent de le cacher après réception. Dans les deux cas, le fichier et l’API sous-jacents doivent avoir leurs propres contrôles. Le nom d’une option de visibilité n’est pas une preuve de sécurité.
Une méthode de réalisation en cinq étapes
| Étape | Réalisation | Vérification |
|---|---|---|
| 1. Maquette | Dessiner un dossier avec des données fictives | Actions et états compris par un client |
| 2. Contrat de données | Définir les champs utiles à chaque écran | Aucune donnée interne inutile |
| 3. Autorisation | Implémenter l’accès au dossier et aux documents | Refus avec un compte d’une autre entreprise |
| 4. Liaison dynamique | Relier l’interface aux réponses filtrées | Gestion du chargement, du vide et des erreurs |
| 5. Recette | Tester les parcours complets sur mobile et ordinateur | Navigation au clavier et messages explicites |
N’utilisez pas de données réelles confidentielles pour alimenter des démonstrations, captures ou contenus de secours dans les blocs. Un résultat d’API enregistré dans un modèle, une révision ou une page peut rester présent même si l’affichage dynamique a changé. Contrôlez ce qui est enregistré et ce qui est envoyé au navigateur.
Les formulaires doivent avoir des libellés, des messages d’erreur associés et une confirmation après enregistrement effectif. Un statut ne doit pas être indiqué uniquement par une couleur. Les boutons de téléchargement doivent nommer le document et, si utile, son format et sa taille.
Si une personne appartient à plusieurs entreprises, affichez clairement le contexte actif. Lorsqu’elle change d’entreprise, réinitialisez les sélections et vérifiez les données rechargées. Un identifiant conservé dans un onglet ou dans le stockage du navigateur ne doit pas imposer le périmètre accepté par le serveur.
Connecter Dolibarr sans exposer toute la base commerciale
Commencez par désigner le système qui fait foi pour chaque donnée. Dolibarr peut rester la source des tiers, devis et factures ; le portail peut conserver les demandes et préférences d’interface. Cette séparation évite deux copies modifiables d’une même information dont personne ne sait résoudre les écarts.
Le module API REST de Dolibarr expose des services après activation. La clé est transmise dans l’en-tête DOLAPIKEY. Les opérations disponibles se vérifient dans l’explorateur de l’installation, selon les modules, versions et droits. La clé reste sur le serveur et les appels passent par HTTPS.
Exemple : afficher une facture à Bruno
Le portail identifie Bruno, vérifie son adhésion à Alpha et son droit de consultation financière. Il retrouve ensuite la référence du tiers ERP à partir d’une association administrée côté serveur. Il demande les données autorisées, vérifie leur rattachement puis construit une réponse réduite aux champs nécessaires : référence, date, montant, statut et action de téléchargement.
Un paramètre client_id fourni par le navigateur ne doit jamais suffire à choisir le tiers Dolibarr. Si le compte technique dispose d’une visibilité large dans l’ERP, le portail doit empêcher qu’elle soit transmise à l’utilisateur final. Les droits natifs du compte d’API et les contrôles du portail sont complémentaires ; leur efficacité se teste sur les routes réellement utilisées.
Ne retournez pas directement tout le JSON reçu de l’ERP. Il peut contenir des notes internes ou des champs inutiles au client. Fixez aussi des limites de taille, un délai d’attente et des messages d’erreur qui ne révèlent pas les détails de l’infrastructure.
Pour une première version, privilégiez la consultation et une demande de modification plutôt qu’une édition directe des données commerciales. Ajouter une validation de devis, un paiement ou une signature impose un workflow spécifique et la vérification des conditions applicables ; un bouton « accepter » ne constitue pas, à lui seul, un dispositif complet.
n8n : automatiser après un enregistrement fiable
Un scénario possible consiste à notifier Claire lorsqu’Alpha dépose une nouvelle pièce. Le portail enregistre d’abord le document, son état et un événement à traiter. Le workflow récupère cet événement, envoie une notification adaptée puis indique le résultat. L’utilisateur voit « document reçu » dès que la réception est confirmée, sans attendre une promesse de livraison email.
Attribuez un identifiant unique à l’événement et empêchez son traitement métier en double. Une relance automatique après timeout peut sinon créer deux demandes ou deux notifications. Les erreurs temporaires peuvent être réessayées avec une limite ; les échecs persistants doivent devenir visibles pour l’équipe. L’historique des exécutions n8n aide au suivi, mais sa conservation doit être maîtrisée.
Protégez l’entrée du workflow et vérifiez l’origine des événements. Préférez transmettre des références de dossiers plutôt que les documents complets lorsqu’ils ne sont pas nécessaires. Une notification peut inviter à ouvrir le portail sans inclure une facture ou un détail confidentiel dans l’email.
Les appels vers des services externes doivent cibler des destinations prévues. Un connecteur serveur qui accepte librement une URL du navigateur peut être détourné pour atteindre des ressources internes : c’est le risque de SSRF. Les domaines, protocoles et redirections autorisés doivent donc être maîtrisés.
Mon guide du back-office unifié avec Dolibarr et n8n complète cette organisation des échanges.
Cache privé et performance : éviter les fuites entre clients
Un cache de page partagé peut servir à Bêta une réponse préparée pour Alpha si sa clé et ses règles ne tiennent pas compte du contexte. Le contrôle d’accès dans WordPress ne suffit plus si un CDN ou un proxy répond avant que WordPress soit interrogé.
Pour démarrer, excluez les écrans et routes confidentiels du cache partagé, puis vérifiez le résultat réel sur chaque couche. La documentation Cache-Control distingue private, qui exclut les caches partagés mais permet le cache privé, et no-store, qui interdit le stockage de la réponse par les caches. Ces en-têtes ne remplacent pas l’authentification et ne suppriment pas magiquement des copies déjà conservées.
Un cache applicatif de données doit inclure les dimensions utiles : organisation, droits, ressource et version. Il doit être invalidé lorsqu’une permission ou un document change. Les fichiers publics de style et de script peuvent rester mutualisés ; une réponse contenant une facture ne suit pas les mêmes règles.
Mesurer une charge réaliste
Le dimensionnement part des utilisateurs simultanés, de la taille des documents, des recherches et des opérations longues. Paginez les listes, indexez les relations fréquemment utilisées et évitez de charger un dossier complet pour afficher son résumé. Un export volumineux doit être borné ou préparé en arrière-plan avec téléchargement contrôlé.
Sur Ubuntu/Plesk, surveillez les workers PHP-FPM, la mémoire, les requêtes MariaDB, les files de traitement et l’espace disque. Transférer chaque gros document à travers PHP peut monopoliser les workers ; une distribution contrôlée par le serveur web peut être plus adaptée. La décision se prend après mesure, pas à partir d’un nombre arbitraire de visiteurs.
Prévoyez un mode dégradé lorsque Dolibarr est indisponible : message explicite, dernière synchronisation visible si une copie autorisée est utilisée, et désactivation des actions exigeant une donnée à jour. Un état ancien ne doit pas être présenté comme une confirmation actuelle de paiement.
Données personnelles : documenter les usages et les responsabilités
Un extranet peut traiter des coordonnées, échanges, documents et traces de connexion. Pour chaque usage, précisez sa finalité, les destinataires, la base juridique appropriée et les informations données aux personnes. L’auto-hébergement et HTTPS ne rendent pas un traitement conforme à eux seuls.
Les recommandations de la CNIL sur la sous-traitance rappellent la nécessité d’encadrer les prestations. Examinez l’hébergement, l’email, les sauvegardes et les outils de support : lieux de traitement, accès possibles, garanties contractuelles et modalités de restitution. Un hébergement en France ne décrit pas tous les flux de la chaîne.
Définissez les durées de conservation par catégorie, selon les finalités et obligations applicables. Une pièce de dossier, un compte inactif et une facture n’ont pas nécessairement la même durée. La fermeture de l’accès client ne signifie pas que toutes les données doivent disparaître immédiatement.
Séparez l’accès courant, l’archivage justifié et la suppression. Les demandes relatives aux données doivent couvrir aussi les champs personnalisés, tables métier et systèmes connectés ; les outils natifs de WordPress ne connaissent pas automatiquement tous ces emplacements. Les modalités doivent être validées avec le responsable du traitement et, selon le projet, son DPO ou conseil compétent.
Évitez les outils de rejeu de session, pixels publicitaires ou scripts tiers sans besoin établi dans la zone privée. Ils peuvent recevoir des informations sur les écrans consultés. Les traitements de données particulièrement sensibles et les exigences sectorielles nécessitent une analyse spécifique ; ce guide général n’atteste pas leur conformité.
Mon article sur la gestion des données personnelles dans WordPress permet de prolonger ce travail.
Journaliser les événements utiles, sans recopier les dossiers
Prévoyez les accès sensibles, changements de droits, invitations, dépôts, téléchargements et opérations d’administration. La fiche CNIL sur la journalisation recommande notamment de conserver l’acteur, la date, l’action et la référence concernée, en évitant de dupliquer inutilement les données. Les journaux doivent être protégés et effectivement consultables en cas d’incident.
Un événement peut indiquer qu’un téléchargement a été autorisé ou qu’un transfert a démarré. Il ne prouve pas nécessairement que le destinataire a lu le document ni que chaque octet a été reçu. N’attribuez pas aux traces techniques une valeur qu’elles ne démontrent pas.
Configurez des alertes exploitables : refus d’accès répétés, export inhabituel, nouvelle attribution de privilèges ou échec prolongé d’une synchronisation. Ne journalisez ni mots de passe, ni clés d’API, ni liens signés complets. La durée et le périmètre des traces doivent être justifiés.
La recette : prouver l’étanchéité entre les comptes
Les tests doivent utiliser au minimum deux entreprises, plusieurs profils, un compte révoqué et un visiteur non connecté. Préparez des données fictives reconnaissables pour détecter immédiatement un mélange. Tester uniquement avec un administrateur masque de nombreux défauts.
| Test | Résultat attendu |
|---|---|
| Alpha demande un document de Bêta par son identifiant | Refus sans contenu ni métadonnée confidentielle |
| Visiteur ouvre directement l’adresse d’un fichier | Aucun fichier privé accessible |
| Utilisateur cherche un dossier d’une autre entreprise | Aucun résultat, suggestion ou total révélateur |
| Compte sans droit financier ouvre une facture | Refus même si le lien a été copié |
| Compte révoqué réutilise un onglet et une session ouverts | Les nouvelles requêtes sont refusées |
| Client modifie un champ propriétaire ou un statut réservé | Modification refusée côté serveur |
| Lien temporaire expiré ou invitation déjà utilisée | Accès refusé selon la politique définie |
| Dépôt non autorisé ou fichier hors limites | Rejet sans publication du contenu |
| Deux clients ouvrent la même route derrière le cache | Aucune réponse croisée |
| Événement transmis deux fois à n8n | Pas de doublon métier |
| ERP ou antivirus indisponible | État d’attente ou erreur contrôlée |
| Export ou aperçu d’un document restreint | Même politique que pour la ressource d’origine |
Contrôlez les réponses HTML et JSON, les routes de médias, les en-têtes de cache et les journaux. Les tests incluent aussi une action légitime de bout en bout : une protection qui refuse tout n’est pas un service utilisable.
Automatisez les contrôles d’autorisation essentiels pour les rejouer après une mise à jour. Complétez par une revue de configuration et de code ; selon l’exposition et la sensibilité, un audit indépendant ou un test d’intrusion apporte une vérification supplémentaire. Un scanner sans alerte ne garantit pas l’absence de défaut métier.
Sauvegardes, reprise et maintenance
Sauvegardez ensemble les données, fichiers privés, configurations et éléments nécessaires à la remise en service. La CNIL recommande de tester la restauration et de protéger les sauvegardes au niveau approprié. Un export de base sans les documents associés ne reconstitue pas le portail.
Définissez deux objectifs avec le métier : la quantité de données que l’on accepte éventuellement de perdre, ou RPO, et le délai de reprise visé, ou RTO. Ce sont des objectifs à démontrer par des essais ; annoncer une sauvegarde quotidienne ne prouve pas un redémarrage en une heure.
Une restauration ancienne peut rétablir des droits depuis retirés. La procédure de reprise doit donc réconcilier les révocations, invitations et opérations en attente avant de rouvrir le service. Les copies de préproduction doivent rester protégées, avec emails et intégrations de production neutralisés.
Conservez l’inventaire des composants et testez les mises à jour sur les parcours critiques. Documentez qui surveille les alertes, renouvelle les certificats, traite les départs et intervient en cas d’incident. Le diagnostic de dette technique WordPress aide à anticiper les dépendances qui deviennent difficiles à maintenir.
Organiser le projet et son budget
Un premier périmètre raisonnable peut réunir les invitations, une bibliothèque documentaire privée et le suivi d’une demande. L’affichage ERP et les automatisations viennent ensuite, lorsque les autorisations et la restauration sont validées. Cette progression limite le nombre de problèmes à résoudre simultanément.
| Jalon | Livrable à valider |
|---|---|
| Cadrage | Parcours, matrice des droits, données, acteurs et contraintes |
| Prototype | Un dossier complet avec plusieurs profils de test |
| Implémentation | Stockage privé, API, journalisation et gestion des erreurs |
| Recette | Tests de séparation, parcours métier et restauration |
| Ouverture pilote | Petit groupe identifié et support disponible |
| Exploitation | Responsabilités, supervision, documentation et réversibilité |
Le coût dépend surtout des règles d’accès, de la reprise des données, des intégrations, des volumes et des exigences de disponibilité. Le devis doit distinguer conception, développement, recette, hébergement, licences, support et maintenance. Un prix de thème ne représente pas le coût d’un extranet.
Pour estimer l’intérêt, mesurez les échanges évités et le temps réellement gagné. Exemple purement illustratif : 100 recherches manuelles de documents de six minutes représentent dix heures par mois. Le gain net sera inférieur si le portail nécessite de l’assistance ou une double saisie. Il faut comparer cette économie aux charges d’exploitation sans promettre un retour automatique.
La réversibilité fait partie du projet : comptes, organisations, relations, fichiers et historique utile doivent pouvoir être exportés dans un format documenté. Un changement de prestataire ne doit pas rendre illisible le rattachement des documents à leurs clients.
Questions fréquentes sur les extranets WordPress
WordPress est-il adapté à un extranet professionnel ?
Il peut l’être pour un portail documentaire ou métier dont les droits, données et intégrations sont correctement conçus. Il faut valider les usages et la charge réelle. Des exigences fortes d’isolation, de complexité transactionnelle ou de conformité sectorielle peuvent conduire à une autre architecture.
GreenShift suffit-il à sécuriser un espace client ?
Non. GreenShift peut construire l’interface et afficher les réponses d’un service. L’autorisation doit rester vérifiée sur chaque route et chaque ressource, côté serveur. Les fonctions disponibles et leur comportement dépendent également de la version et des extensions utilisées.
Une page privée WordPress protège-t-elle ses documents ?
Pas nécessairement. Le droit de voir une page ne protège pas automatiquement l’URL directe d’un fichier de la médiathèque. Les documents confidentiels nécessitent un stockage et une distribution contrôlés, y compris pour leurs aperçus et anciennes versions.
Comment séparer plusieurs entreprises clientes ?
Modélisez explicitement les organisations et les adhésions des utilisateurs. Reliez chaque dossier et document à son périmètre, puis vérifiez les droits à chaque accès. Les recherches, exports, caches et téléchargements doivent respecter les mêmes règles.
Un utilisateur peut-il accéder à plusieurs entreprises ?
Oui, si ses adhésions sont gérées séparément. Le contexte actif doit être visible et validé par le serveur. Un changement d’entreprise dans l’interface ne doit jamais suffire à ouvrir les dossiers d’une organisation à laquelle la personne n’appartient pas.
Peut-on connecter le portail à Dolibarr ?
Oui, via les services API disponibles sur l’installation. La clé reste côté serveur et le portail limite les données retournées selon les droits du client. Il faut tester les permissions réelles du compte technique et le rattachement des documents au bon tiers.
L’authentification multifacteur est-elle obligatoire ?
Il n’existe pas une règle universelle identique pour tous les extranets. Le niveau requis dépend des risques et des obligations applicables. Elle est particulièrement pertinente pour l’administration et les données sensibles, avec une procédure de récupération qui ne contourne pas la protection.
Peut-on annuler un téléchargement déjà effectué ?
On peut retirer un accès futur, mais pas supprimer une copie déjà conservée par le destinataire. Un lien signé peut aussi rester utilisable jusqu’à expiration selon le dispositif. Une exigence de révocation immédiate impose une conception adaptée.
Un hébergement français suffit-il pour être conforme au RGPD ?
Non. Il faut également examiner les finalités, les bases juridiques, les accès, les durées, les prestataires et l’exercice des droits. Les sauvegardes et outils connectés font partie du périmètre. Les traitements particuliers nécessitent une analyse adaptée.
Comment vérifier la sécurité avant ouverture ?
Testez plusieurs clients et profils, les accès directs, les changements d’identifiant, les comptes révoqués, les fichiers et les caches. Validez aussi la restauration et les parcours autorisés. Les contrôles doivent être rejoués après les changements importants.
Faut-il mettre l’extranet sur un sous-domaine ?
Un sous-domaine peut faciliter l’organisation, mais ne crée pas à lui seul une isolation. Il faut examiner les comptes système, bases, cookies, secrets, règles réseau et droits de fichiers. Une installation séparée augmente aussi les tâches d’exploitation ; le choix dépend du niveau de séparation recherché.
Peut-on ajouter ensuite un assistant IA ?
Oui, mais l’index documentaire et chaque recherche doivent respecter les mêmes permissions que le portail. Un document privé ne doit pas être transmis au modèle pour un utilisateur non autorisé. Cette extension demande ses propres tests de confidentialité et de qualité des réponses.
Pour l’extension documentaire par IA, mon guide sur le moteur de réponse RAG connecté à WordPress détaille la recherche dans des sources autorisées.
Construire un portail que vos clients peuvent utiliser avec confiance
Un extranet utile rend les documents accessibles aux bonnes personnes et les échanges plus simples à suivre. Sa fiabilité dépend de l’ensemble : identité, relations métier, stockage, API, interface, maintenance et capacité de reprise. WordPress et GreenShift peuvent servir ce projet lorsque ces responsabilités sont clairement définies.
En tant que développeur indépendant spécialisé dans WordPress et l’administration serveur, je peux étudier vos parcours, vos documents et vos connexions à Dolibarr pour définir une architecture adaptée. Le cadrage doit permettre de distinguer les fonctions disponibles, celles à développer et les contraintes d’exploitation.
Pour préparer un premier échange, indiquez les profils d’utilisateurs, les documents à partager, les outils à connecter et vos contraintes de confidentialité. Inutile de transmettre des données clients ou des identifiants dans le formulaire : ces éléments se partagent ensuite par un canal adapté.
