Le client ouvre une demande pour une commande endommagée. Le support crée un ticket, la logistique ajoute une note dans l’ERP et les photos restent dans un email. Lorsque le dossier change d’équipe, chacun retrouve un fragment différent. Le client répète son histoire et une seconde expédition part sans connaître la première décision.
Le problème augmente la charge support et le coût logistique : une preuve introuvable retarde l’avoir, tandis qu’un lien vers le mauvais compte expose une donnée client. Les équipes compensent par des captures et exports, ce qui multiplie encore les versions sans propriétaire.
Réunir toutes les données dans une grande fiche paraît simple, mais confond des objets aux cycles distincts. Une demande exprime un besoin, un ticket organise le travail, une commande porte un engagement et une pièce apporte une preuve. Les dupliquer fait diverger statuts, droits et dates.
Le vrai enjeu est de relier ces objets par une identité et une relation explicites, puis de présenter une chronologie adaptée à chaque rôle. Le portail n’a pas besoin de devenir maître de l’ERP ou du support ; il doit pouvoir retrouver les faits et appliquer les bonnes actions.
Une architecture de développement web sur mesure construit ce dossier traversant, avec sécurité, version et reprise. La méthode commence par le sens des liens.
Choisir le dossier métier racine
Le dossier racine correspond à la question que l’utilisateur suit : incident de livraison, demande de retour, intervention ou réclamation. Il possède identifiant stable, demandeur, compte, objet concerné, statut de synthèse et droits. Il ne remplace pas les objets sources ; il les relie.
Une même commande peut participer à plusieurs dossiers, et un dossier à plusieurs commandes. Évitez de prendre le premier numéro comme clé unique. Le dossier conserve son propre cycle et ses liens typés. La synthèse est calculée depuis les faits autoritatifs.
Fermer création et déduplication
La création recherche un dossier ouvert par compte, motif et objet, puis propose un rattachement. Une clé d’idempotence protège les doubles soumissions. Un cas réellement distinct reçoit un nouveau dossier, même s’il concerne la même commande. La fusion reste une décision tracée et réversible.
Distinguer demande, ticket et commande
La demande décrit le besoin du client et les informations fournies. Le ticket porte affectation, priorité, file et actions internes. La commande conserve lignes, prix et livraison. Une pièce jointe a identité, contenu, classification et droits. Chaque objet garde son propriétaire et sa version.
Le statut de l’un ne commande pas implicitement les autres. Fermer un ticket ne clôt pas la réclamation si un remboursement reste attendu. Annuler une commande ne supprime pas les échanges. Le dossier de synthèse expose les sous-processus et la prochaine action.
Séparer faits et conversations
Un message peut annoncer un fait, mais il n’est pas ce fait. « Le colis est reparti » doit référencer l’expédition ou rester une déclaration. Cette séparation permet de corriger une erreur de communication sans réécrire l’événement logistique.
Créer des relations typées
Les liens portent type, source, auteur, date d’effet et éventuellement rôle : concerne, déclenche, remplace, justifie ou résout. Une pièce « justifie » un dommage ; un avoir « résout financièrement » une demande. Un lien générique related_to ne permet ni règles ni lecture claire.
Les invariants protègent les combinaisons impossibles. Une facture liée doit appartenir au compte du dossier ou passer une règle de partage. Une relation supprimée garde un historique lorsqu’elle a guidé une décision. Les liens externes conservent système et identifiant canonique.
Porter plusieurs niveaux de visibilité
Le client voit sa demande, les réponses publiées et les objets auxquels il a droit. Les notes internes, alertes fraude ou commentaires de diagnostic restent séparés. Une relation visible n’ouvre pas automatiquement la ressource cible : l’autorisation est recalculée à chaque accès.
Versionner le graphe de dossier
Une relation importante reçoit une version et une commande d’origine. Deux agents qui rattachent simultanément une commande ne doivent pas créer des branches contradictoires. Le second voit la version courante, puis confirme ou annule son geste. Une fusion de dossiers déplace les liens avec un manifeste et garde un alias depuis l’ancien numéro. La défusion reste possible tant qu’aucune décision irréversible n’a mélangé les preuves.
Les invariants sont testés sur le graphe complet : un remboursement concerne une ligne du compte, une intervention vise un équipement du site, un document émis correspond à l’entité. Une violation ne supprime pas le lien reçu ; elle le place en quarantaine avec la cause et le système source. Cette trace aide à corriger l’intégration sans présenter une relation dangereuse au client.
Construire une chronologie fidèle
La chronologie combine événements de domaine avec source, date d’effet, date de réception et corrélation. Elle trie selon le temps métier lorsque possible et signale un événement reçu tardivement. Les mises à jour techniques sans valeur utilisateur n’encombrent pas le fil.
Regroupez les événements d’une même commande : retour autorisé, étiquette émise, colis reçu. L’interface distingue statut, message et action. Elle ne donne pas l’impression qu’une projection en retard annule un fait plus récent. Une fraîcheur est affichée sur les sources asynchrones.
Préserver les corrections
Une correction ajoute un nouvel événement lié au précédent, avec motif. Elle ne modifie pas silencieusement la chronologie. Le support peut reconstruire ce qui était connu lors de la décision et ce qui a changé ensuite.
Sécuriser les pièces jointes
La pièce possède identifiant, propriétaire, dossier, type déclaré, type détecté, taille, empreinte, statut d’analyse et durée. Stockez-la hors racine publique avec un nom généré. Le téléchargement vérifie compte, relation, classification et droit au moment de la requête.
L’OWASP File Upload Cheat Sheet recommande notamment liste d’extensions autorisées, validation du type et du nom, limites de taille, stockage sûr et analyse adaptée. Aucun contrôle isolé ne suffit.
Traiter l’analyse asynchrone
Le fichier reste en quarantaine jusqu’au verdict. L’interface montre « analyse en cours » sans lien direct. Un échec produit une action de remplacement. L’empreinte aide à détecter un doublon, mais deux usages d’un même contenu gardent leurs relations et durées propres.
Fermer conservation et suppression
La durée dépend du type de dossier, de la pièce et de la finalité, pas du seul espace disponible. Une photo de dommage, un contrat et une pièce d’identité n’ont pas le même besoin. Le manifeste de purge liste contenu, miniatures, index et liens, puis conserve la preuve de l’action sans garder le fichier. Une obligation de gel suspend la suppression de façon ciblée et datée.
Les sauvegardes et environnements de test font partie du périmètre. La restauration réapplique les suppressions nécessaires. Les développeurs n’utilisent pas les pièces réelles pour reproduire un bug sans procédure. Une pièce exportée pour une enquête possède destinataire, date et expiration. Cette discipline empêche le portail de devenir une archive indéfinie de données client.
Cas concret : colis endommagé
Un client signale trois produits cassés sur une commande de vingt lignes. Il joint deux photos et le bon de livraison. Le portail crée un dossier, rattache commande et expédition, puis place les pièces en analyse. Le support ouvre un ticket seulement après vérification de l’identité et du périmètre.
La logistique constate le dommage, une nouvelle expédition est créée et la finance émet un avoir sur une ligne non remplaçable. Le dossier reste ouvert tant que ces deux sous-processus ne sont pas terminés. Le client voit les décisions publiées et les documents auxquels il a droit.
Le pilote couvre cinquante dossiers, dont double soumission, photo rejetée, deux commandes proches et événement logistique tardif. Le go local exige zéro pièce visible avant analyse, zéro objet d’un autre compte et une balance complète entre remplacements et lignes. Le support doit reprendre depuis le numéro de dossier sans parcourir trois outils.
Au-delà de 24 heures sans verdict de pièce, le dossier est escaladé plutôt que clôturé ; au-delà de 5 Mo, le fichier suit le canal prévu par la politique locale. Ces seuils viennent de la capacité d’analyse et du délai promis sur ce flux. L’équipe provoque aussi une indisponibilité de la GED : la demande reste créée, la pièce garde son état et aucune seconde expédition n’est autorisée sans la preuve requise.
Relier les systèmes sans copier le dossier
Le portail garde identifiants, relations et projection nécessaire. Le CRM possède la relation client, le support le ticket, l’ERP la commande et la GED le document émis. Une matrice d’autorité précise les champs. Les copies portent version et fraîcheur.
Les événements passent par boîte de sortie et les consommateurs sont idempotents. Un message doublonné ne crée pas un second lien. Un message ancien peut enrichir la chronologie sans faire reculer le statut synthétique. La réconciliation cherche liens orphelins, versions en retard et objets inconnus.
Définir les contrats d’erreur
Chaque intégration retourne code stable, ressource, corrélation et possibilité de reprise. Une absence temporaire se distingue d’un identifiant invalide ou d’un refus d’accès. Le dossier n’annonce pas « commande inexistante » lorsqu’une dépendance ne répond pas.
Implémenter graphe et événements
Les entrées sont dossier, objet source, type de relation, auteur, version et contexte ; les sorties sont lien créé, conflit ou refus avec corrélation. La responsabilité du domaine est de vérifier identité, droits et invariants. Les adaptateurs résolvent les références externes sans prendre la décision.
La journalisation conserve commandes et événements. Le monitoring suit liens en échec, pièces en quarantaine, projections en retard, doublons et dossiers sans prochaine action. Le retry est idempotent. Le rollback désactive un nouveau type de lien sans supprimer les relations déjà validées. Un manifeste permet de réparer un lot.
Les entrées de réconciliation sont fichier de manifeste, identifiants source, versions et compteurs ; les sorties sont liens confirmés, inconnus et refusés. La responsabilité de chaque catégorie est attribuée. Les dépendances et seuils sont vérifiés avant traitement. La journalisation relie ligne et décision, tandis que le monitoring alerte sur la distribution. Le rollback retire le lot depuis le manifeste et le retry rejoue la même commande idempotente sans dupliquer le graphe.
Tester par propriétés
Les tests affirment qu’aucune relation ne donne un droit par elle-même, qu’une pièce non saine reste inaccessible et qu’une commande ne change pas de compte. Les scénarios provoquent concurrence, retard, suppression, fusion et restauration. La recette compare le graphe aux sources.
Rendre le dossier retrouvable
L’utilisateur cherche par dossier, commande, facture, référence produit ou site selon ses droits. L’index ne doit pas révéler titres ou compteurs interdits. Chaque résultat affiche type, date, statut, relation et prochaine action. Les aliases anciens continuent à retrouver l’objet canonique.
Contre-intuitivement, indexer moins de contenu peut améliorer le diagnostic : les notes longues produisent du bruit et exposent des informations. Indexez identifiants, catégories, textes publiés et métadonnées autorisées. La recherche technique détaillée reste réservée aux équipes habilitées.
Pour qui cette structure est utile
Elle convient aux portails où une demande traverse support, logistique, finance ou opérations et où plusieurs objets fournissent la preuve. Elle mobilise produit, métier, sécurité, intégration, développeurs, data et support.
Un simple formulaire vers une seule équipe peut conserver un modèle plus léger. Le graphe devient pertinent quand les copies et recherches manuelles créent déjà une charge, des erreurs d’accès ou des décisions contradictoires.
Erreurs fréquentes de liaison
Copier tous les objets dans le ticket
La copie fige une vue et perd les mises à jour. Gardez identifiants, données nécessaires et version. L’autorité reste dans le domaine source.
Utiliser la pièce comme dossier
Un fichier sans objet, droit ni durée devient introuvable et dangereux. Reliez-le à une demande et classifiez-le avant publication.
Fermer depuis un seul sous-statut
Le ticket résolu n’implique pas l’avoir ou l’expédition terminés. Calculez la synthèse depuis des conditions explicites et affichez ce qui reste.
Décision : lien, copie ou agrégat
Priorisez un lien lorsque l’objet conserve son identité et son propriétaire. Copiez un attribut seulement pour une décision figée, comme l’adresse utilisée à la commande, avec provenance. Calculez un agrégat pour la synthèse. Refusez une duplication complète sans règle de rafraîchissement.
Si la relation ouvre argent, droit ou preuve, alors vérifiez identité et contexte. En revanche, une donnée de présentation peut venir d’une projection fraîche. À éviter : transformer la chronologie en suite de textes libres.
- Commencer par un dossier et trois objets sources.
- Documenter types de liens, autorités et droits.
- Tester doublons, retards, pièces et recherches croisées.
- Élargir après réconciliation des relations.
Plan d’action sur cinq semaines
Semaines un et deux : modéliser le dossier
Rejouez trente demandes traversant au moins deux équipes. Nommez les objets, propriétaires, décisions et preuves. Choisissez le dossier racine, les types de relations et la synthèse. Cartographiez identifiants, droits, pièces et chemins de recherche.
Écrivez les contrats d’événements, erreurs et visibilité. Préparez un graphe pilote avec doublons, objets déplacés et événements hors ordre. Définissez la quarantaine des fichiers, la réconciliation et les indicateurs de reprise.
Semaines trois à cinq : brancher et perturber
Reliez demande, ticket et commande sans changer l’autorité. Construisez la chronologie et l’index filtré. Ajoutez une famille de pièces. Provoquez doublon, analyse lente, lien invalide, source indisponible et événement tardif.
Faites suivre cinq dossiers par le client et le support. Vérifiez que chacun voit la bonne chronologie et que l’agent reprend sans ressaisie. Balancez liens, objets et actions. Le rollback ferme la nouvelle vue mais préserve les relations.
Activez un second type de dossier après un cycle. Étendez si les relations se réconcilient, si les droits tiennent et si la recherche réduit le diagnostic ; sinon, resserrez le graphe ou corrigez les identités.
La recette finale choisit dix dossiers sans préparation, dont un fusionné et un rouvert. Le client, le support et la logistique décrivent chacun la prochaine action depuis leur vue. Le compte rendu compare chronologie, relations et sources, puis attribue chaque écart. Une seconde équipe restaure l’accès à une pièce et reprend un événement bloqué depuis le runbook. Aucun go n’est donné si une connaissance orale reste nécessaire pour retrouver la preuve.
- Nommer le dossier et ses objets.
- Typiser relations, événements et visibilité.
- Tester pièces, ordre, accès et reprise.
- Réconcilier avant d’ajouter des parcours.
Approfondir support et autorisation
Gouverner les types de dossiers
Le catalogue des dossiers décrit objet racine, états, liens autorisés, pièces, droits et conditions de clôture. Une nouvelle équipe ne crée pas une variante uniquement pour modifier son tableau de bord. Elle réutilise le type si le sens reste identique ou propose un sous-processus. Les occurrences, exceptions et temps de reprise sont revus avant toute extension, afin que le graphe conserve un vocabulaire stable.
Après retrait d’un type, les dossiers historiques restent lisibles avec leur définition versionnée. Les nouveaux liens sont interdits et les intégrations averties. Mesurez encore les événements reçus sur l’ancien contrat : ils signalent un producteur oublié. Cette phase de sortie protège les migrations et évite qu’une nouvelle interface doive supporter indéfiniment toutes les conventions du passé.
Surveillez aussi les dossiers sans mouvement utile. Une chronologie peut recevoir des synchronisations techniques tout en restant bloquée côté client. Calculez la dernière action métier, le responsable attendu et l’échéance. Le tableau sépare attente normale, dépendance en retard et dossier sans propriétaire. Chaque catégorie déclenche une relance ou une correction connue. Cette mesure prévient l’illusion d’un portail actif alors que la demande réelle n’avance plus.
Automatiser sans perdre le dossier
Le guide du portail SAV automatisé utilise ce graphe pour diagnostiquer, agir et escalader.
Vérifier les périmètres
Poursuivez avec les droits par compte, site ou filiale afin de protéger chaque objet et chaque pièce.
- Des objets distincts.
- Des liens typés.
- Une chronologie vérifiable.
Conclusion : transmettre un dossier entier
Relier ne signifie pas recopier. La demande, le ticket, la commande et la pièce gardent leur identité, leur autorité et leur cycle. Le dossier fournit les relations et la synthèse nécessaires au parcours.
Les événements, droits et quarantaines protègent la chronologie. La recherche et la réconciliation permettent au support de reprendre depuis un numéro métier sans collecter à nouveau les preuves.
Commencez par le type de demande qui traverse le plus d’équipes. Nommez ses objets, fermez trois relations et jouez un cas hostile. Ce graphe étroit apportera plus de continuité qu’une fiche universelle.
- Une identité par objet.
- Un lien explicite.
- Une reprise complète.
Dawap peut accompagner ce portail de développement web sur mesure : modèle de dossier, intégrations, fichiers, recherche, sécurité, recette et run.
