Un client ouvre son extranet et voit un contrat « actif ». Il appelle pourtant le support parce que l’ERP le considère suspendu. Le problème devient visible : le portail a copié le statut lors de la dernière synchronisation, puis permis d’ajouter une adresse que le CRM ne connaît pas. Ce qui devait réduire les tickets a créé un quatrième endroit où l’entreprise doit décider quelle information croire.
Un extranet dérive facilement vers une reconstruction du système d’information : catalogue, documents, utilisateurs, tickets, commandes, reporting et règles sont redéveloppés derrière une nouvelle interface. Chaque copie accélère une première page, puis multiplie les synchronisations, les droits et les modes dégradés. Le portail devient coûteux précisément lorsqu’il commence à être utilisé.
Le vrai enjeu est d’exposer une promesse client cohérente sans déplacer l’autorité des domaines. L’extranet doit orchestrer des cas d’usage, présenter des projections datées et renvoyer les décisions aux systèmes propriétaires. Contre-intuitivement, une expérience unifiée peut reposer sur plusieurs sources si leurs responsabilités, identifiants et comportements en panne sont explicites.
Dans une stratégie de développement web sur mesure, le portail devient une frontière produit et de sécurité. Ce guide aide à cadrer son périmètre, ses contrats et son exploitation afin que l’autonomie client augmente sans dupliquer l’ensemble du SI.
Définir la promesse de l’extranet
Choisir des issues client mesurables
Le projet commence par des résultats : retrouver un document, suivre une intervention, demander une modification, gérer un utilisateur ou télécharger un relevé. « Digitaliser la relation » ne permet pas d’arbitrer. Chaque promesse possède audience, données, délai, autorité et sortie vers le support si elle ne peut être tenue.
L’équipe observe les demandes actuelles et le coût complet. Un volume élevé ne suffit pas : une demande peut être fréquente mais nécessiter un jugement. Le premier périmètre privilégie les actions à valeur claire, données disponibles et risque borné. Il accepte de ne pas couvrir tout le catalogue de services.
Écrire le contrat de confiance
Le client sait quelles informations sont actuelles, lesquelles sont en attente et ce que son action engage. Un statut, une date et une prochaine étape valent mieux qu’une promesse générale de temps réel. Les limites et voies d’escalade font partie de l’expérience.
Choisir ce qui reste hors du portail
Les fonctions internes de correction, les données techniques et les exceptions rares ne doivent pas toutes être exposées. Le portail propose des intentions client ; le back-office conserve administration, diagnostic et réparation. Une demande complexe peut être déposée et suivie sans rendre le client opérateur du processus interne.
Le périmètre exclut les actions sans source fiable ou sans propriétaire. Il exclut aussi les agrégats qui risquent de révéler une autre entité. Une fonction reportée reçoit une alternative claire : contact, formulaire cadré ou lecture seule. Le vide ne doit pas pousser à l’email privé.
Prévenir le glissement par opportunité
Chaque nouvelle fonction passe par la même fiche : promesse, décision, source, droit, mode dégradé et support. Le fait qu’une donnée soit déjà disponible dans l’API ne suffit pas. Une vue sans usage et sans run augmente le périmètre d’incident.
Attribuer sources et responsabilités
Pour chaque attribut, l’équipe nomme système propriétaire, possibilité de contribution, validation et délai de propagation. Le CRM peut posséder le contact, l’ERP le contrat, le service d’intervention le planning. Le portail ne devient pas maître par défaut parce qu’il reçoit la saisie.
Une modification client est une proposition ou une commande. Elle porte version et preuve. Le système propriétaire accepte, refuse ou demande une revue, puis renvoie un verdict. Le portail n’affiche pas « enregistré » lorsqu’il a seulement mis la demande en file.
Conserver provenance et date
Les valeurs projetées indiquent source et fraîcheur lorsque la décision en dépend. Une donnée ancienne peut rester consultable avec limite. Une donnée opposable peut bloquer l’action si la source n’est plus joignable. Le mode dégradé est choisi par cas d’usage.
Projeter sans créer une vérité parallèle
Le portail maintient des lectures adaptées pour répondre vite : contrats actifs, dernières interventions, documents autorisés. Chaque projection porte version source, date et état de synchronisation. Elle peut être reconstruite. Les corrections se font dans le domaine propriétaire, pas directement dans la table de lecture.
Une commande critique revalide les éléments nécessaires. Une projection ancienne peut suffire à afficher l’historique, pas à autoriser un changement de bénéficiaire. Le cache conserve le périmètre et ne mélange pas deux comptes. La révocation invalide les lectures concernées.
Réconcilier plutôt que promettre la simultanéité
Une balance compare identifiants, versions, droits et objets visibles. Les écarts sont classés entre retard connu, mapping absent, objet orphelin et conflit. Une divergence inconnue ferme l’extension. Le support dispose d’une vue qui explique pourquoi une donnée apparaît.
Relier comptes, organisations et invitations
Le compte utilisateur n’est pas le client. Une personne peut représenter plusieurs organisations, avec des capacités différentes. Le modèle sépare identité, appartenance, rôle délégué et périmètre. Une invitation cible une organisation, une capacité, une durée et un email vérifié.
Le départ d’un contact ferme ses sessions et délégations sans supprimer l’histoire. Un administrateur client gère des utilisateurs dans les limites prévues ; il ne s’accorde pas de nouvelles capacités globales. Les invitations expirent et sont à usage unique. Les comptes partagés sont refusés.
Prévoir rapprochement et récupération
Un changement d’email ou une fusion d’organisation ne recrée pas une identité. Les anciens identifiants restent résolvables. La récupération de compte vérifie la personne sans contourner l’autorité de l’organisation. Les actions sensibles peuvent exiger une authentification renforcée.
Publier documents et notifications avec preuve
Un document possède type, propriétaire, version, période, organisation et règle d’accès. Le portail ne publie pas un répertoire brut. Une facture corrigée conserve l’ancienne version selon la politique, mais indique laquelle est opposable. Un lien signé expire et ne remplace pas l’autorisation.
Les notifications signalent un événement ; elles ne deviennent pas la seule preuve. Le centre de notifications reprend le même état que le dossier. Une réponse perdue est rejouée sans envoyer deux invitations ou deux demandes. Les préférences ne désactivent pas une notification obligatoire sans décision.
Fermer l’accès après révocation
La révocation touche interface, API, liens, cache, recherche et exports. Elle est testée avec un document déjà ouvert et une tâche asynchrone. Le journal conserve acteur, motif et ressources affectées. Une copie téléchargée suit la politique contractuelle ; le portail ne peut pas la rappeler magiquement.
Cas concret : suivre interventions et contrats
Cas hypothétique : une entreprise de maintenance ouvre un extranet à ses clients. Ils veulent voir contrats, sites, interventions et rapports. L’ancien projet prévoit de recopier CRM, ERP et outil terrain chaque nuit dans une base unique, puis d’autoriser les corrections directement.
La cible garde le CRM propriétaire des organisations, l’ERP des contrats et l’outil terrain des interventions. Le portail construit des projections par compte. Une demande de changement d’adresse devient une commande au domaine approprié. Les rapports sont publiés avec site, version et droit.
Le pilote porte trois clients, cinquante sites et deux cents documents. Les seuils locaux exigent aucune donnée inter-client, une révocation effective sur tous les chemins et une explication de chaque retard de projection. Le support doit retrouver le verdict depuis le compte et le document sans accès global.
Éprouver sources, versions et isolement
Par exemple, si l’outil terrain est indisponible, les interventions passées restent visibles avec leur date mais une nouvelle planification attend. Si un rapport est corrigé, alors le portail publie la nouvelle version et conserve la chronologie. Il ne remplace pas silencieusement un document déjà utilisé.
La recette tire vingt documents, dix interventions et cinq changements d’adresse par client. Elle compare le propriétaire, la version, le périmètre et le verdict avec les systèmes d’autorité. Toute ressource visible sous une autre organisation bloque immédiatement l’ouverture ; un retard explicite peut être accepté pendant le budget défini avec le métier. Ce seuil distingue sécurité et fraîcheur au lieu de les confondre. Il vaut pour ce pilote de maintenance et devra être requalifié si les contrats ou la criticité des interventions changent.
Appliquer droits et isolation partout
L’autorisation vérifie action, ressource, organisation et relation. Elle s’applique à chaque requête, conformément aux principes de l’OWASP Authorization Cheat Sheet. Masquer un menu n’est pas une protection. Les identifiants difficiles à deviner ne remplacent pas le contrôle.
La recette couvre recherches, exports, URLs, caches, fichiers, notifications et workers. Elle change une appartenance pendant la session et révoque une invitation. Les refus ne révèlent pas l’existence d’une autre organisation. Les accès sensibles sont journalisés et revus.
Minimiser les données exposées
Chaque projection contient seulement ce que le cas d’usage exige. Les environnements non productifs utilisent des données adaptées. Les secrets et journaux ne sont pas visibles par le support client. Une vue de diagnostic traduit les causes sans exposer les détails techniques.
Mettre en œuvre des contrats reprenables
Contractualiser entrées et sorties
Les entrées sont compte, organisation, capacité, objet et version ; les sorties sont projection, commande et verdict. Les dépendances sont identifiées. La journalisation conserve corrélation et source. L’instrumentation relie l’action client aux systèmes propriétaires.
Le monitoring suit latence, retard, refus, invitations, retries et écarts de balance. Le runbook attribue les responsabilités. Un rollback ferme une nouvelle action sans retirer la lecture sûre. Le retry idempotent retrouve la demande existante.
Déployer par capacité
Chaque capacité possède drapeau, périmètre pilote et critères de sortie. Les contrats sont compatibles pendant la coexistence. La CI teste droits et schémas. Le mode dégradé est exercé avant l’ouverture. Une évolution du SI ne doit pas casser toutes les pages du portail.
Dans le backend PHP et Symfony, l’API du portail demande une lecture ou transmet une commande portant compte, organisation, version et clé d’idempotence. Doctrine persiste demande et boîte de sortie ; un worker contacte le domaine propriétaire puis enregistre le verdict. Le cache contient une projection partitionnée et datée, jamais une autorité implicite. Les tests d’intégration couvrent révocation, changement de rattachement, retry et réponse hors ordre. Logging, instrumentation et monitoring relient l’écran à la source sans copier les secrets. Le déploiement ouvre une capacité par client et le rollback la ferme en conservant une lecture sûre et le runbook de reprise.
Exploiter dépendances et autonomie
Le tableau suit demandes autonomes terminées, abandons, tickets après usage, erreurs d’accès, retard de projections et corrections manuelles. Le nombre de connexions ne prouve pas la valeur. Une action autonome qui crée une reprise interne n’a pas réduit le coût complet.
Chaque dépendance possède budget et propriétaire. Le support sait ce qui reste lisible, ce qui attend et ce qui est bloqué. Les incidents sont reliés au compte et au parcours. Les fonctions sans usage ou avec un run disproportionné sont retirées.
Le comité arbitre explicitement cohérence, vitesse et autonomie. Une lecture directe offre la valeur la plus récente, mais rend le portail dépendant de la disponibilité de la source. Une projection améliore la continuité, mais exige fraîcheur affichée et réconciliation. Une copie modifiable semble autonome, mais crée une seconde autorité : elle est écartée. Pour chaque capacité, le tableau consigne l’option retenue, sa contrepartie, le budget de panne et la personne qui décide du mode dégradé.
Les signaux faibles sont les tickets qui demandent quelle version croire, les corrections réalisées dans deux outils et les invitations conservées « au cas où ». Chacun ouvre une revue de contrat avant de devenir un incident d’isolation ou de qualité. Le produit suit aussi la part des demandes que le client termine sans reprise interne. Une connexion fréquente ne compense pas une autonomie factice si les équipes ressaisissent ensuite les mêmes informations dans le SI.
Pour qui un extranet devient-il pertinent ?
Il convient aux relations récurrentes avec organisations, contrats, documents et demandes structurées. Produit, relation client, sécurité, intégration, support et métiers propriétaires participent. Les clients administrateurs apportent les réalités de délégation.
Un simple espace documentaire peut suffire si aucune action n’est attendue. Un site public et un formulaire peuvent couvrir un faible volume. L’extranet devient pertinent lorsque l’identité, les droits et la continuité des dossiers créent une valeur durable.
Erreurs fréquentes des extranets
La première erreur copie toutes les tables. La deuxième fait du portail une nouvelle source. La troisième modélise un utilisateur égal à un client. La quatrième partage des comptes. La cinquième protège l’écran mais pas les fichiers. La sixième promet du temps réel partout.
Autres pièges : fonction sans propriétaire, correction directe, invitation sans fin, cache non partitionné, support avec accès global ou notification contradictoire. Enfin, un beau portail ne compense pas une identité ou un contrat mal défini.
Décider ce que l’extranet doit porter
Bloc de décision. Portez dans l’extranet les lectures et commandes qui servent une promesse client stable. Gardez la décision dans le domaine propriétaire. Utilisez une projection pour la vitesse, une revalidation pour les effets sensibles et une voie support pour les exceptions. Refusez une fonction sans source, droit ou mode dégradé.
- Commencer par trois issues client.
- Attribuer source, version et responsabilité.
- Tester isolation, révocation et panne.
- Étendre par capacité, jamais par copie de module.
Le coût complet inclut intégration, identité, sécurité, support et évolution. Une fonction apparemment simple peut être chère si elle traverse plusieurs autorités. Le périmètre juste maximise la confiance plutôt que le nombre de menus.
Plan d’action sur huit semaines
Semaines 1 et 2 : cadrer
Sélectionnez demandes, audiences et trois promesses. Cartographiez sources, droits, identités et dépendances. Écrivez comportements nominaux et dégradés. Excluez les fonctions sans autorité claire.
Semaines 3 à 5 : construire
Implémentez identité organisationnelle, une projection documentaire et une commande. Branchez journalisation, monitoring et balance. Testez invitations, délégations et liens. Le support participe aux messages et aux outils de diagnostic.
Semaines 6 à 8 : éprouver
Ouvrez à trois clients. Provoquez source lente, révocation, document corrigé et réponse perdue. Mesurez issue, tickets et récupération. Exécutez le rollback d’une action sans retirer l’historique.
Décider l’extension capacité par capacité
Le bilan classe chaque capacité selon valeur, confiance et coût de run. D’abord, stabiliser identité et lecture ; ensuite, ouvrir une commande ; puis élargir. Si une divergence exige une correction directe, la capacité revient en cadrage.
La revue de passage commence par une démonstration menée avec les droits réels de chaque client, jamais avec un compte global. Un client retrouve un contrat, révoque un contact et suit une demande ; le support diagnostique la même histoire depuis un identifiant corrélé. L’exploitation coupe successivement CRM, ERP et outil terrain afin de vérifier les messages, les budgets de fraîcheur et la reprise. Pour chaque scénario, elle note l’entrée, la sortie, la dépendance, la responsabilité et la preuve attendue.
Avant l’extension, une balance rapproche projections, commandes, verdicts et documents publiés. Les écarts expliqués sont datés et propriétaires ; tout écart sans cause suspend la capacité concernée sans fermer les autres. Le compte rendu consigne les seuils locaux, la procédure de rollback, les alertes et l’astreinte. La semaine suivant l’ouverture, la revue reste quotidienne ; elle devient ensuite hebdomadaire seulement si les incidents et tickets restent dans le budget accepté avec les clients pilotes.
Enfin, le produit tient une liste assumée de ce qu’il ne fera pas : administration des référentiels, correction comptable, diagnostic technique profond ou décision sans autorité claire. Cette frontière est relue à chaque demande de menu supplémentaire. Une nouvelle capacité entre lorsqu’elle réutilise l’identité, les contrats et le run existants ; si elle impose une nouvelle source de vérité, elle déclenche un cadrage séparé. Cette discipline protège la promesse initiale contre la reconstruction progressive du SI.
- Nommer la promesse et les objets.
- Fermer sources, droits et modes dégradés.
- Tester isolation, reprise et support.
- Étendre depuis les usages réellement autonomes.
Guides complémentaires pour le portail
Choisir les actions autonomes
Le guide du self-service client aide à qualifier risque, données et sortie support.
Séparer opérations et administration
La séparation opérations et administration protège les fonctions sensibles.
- Une promesse bornée.
- Des projections sourcées.
- Une isolation testée.
Conclusion : exposer une promesse cohérente
Un extranet utile n’est pas une copie du SI. Il orchestre quelques cas d’usage, présente des lectures adaptées et renvoie les décisions aux domaines propriétaires. L’identité et les droits traversent chaque fonction.
Les projections, versions et balances rendent la distribution exploitable. Le mode dégradé reste visible. Le support retrouve le verdict sans compte global. Le périmètre évolue par capacités prouvées.
Dawap peut accompagner cette conception et son intégration dans une démarche de développement web sur mesure. Le résultat attendu est une autonomie client réelle, sans créer une nouvelle vérité ni un second système d’information.
