Pièce manquante ou non requise : décider avant de mesurer la complétude

Un client choisit une livraison hors site. Le portail lui réclame pourtant un plan d’accès et bloque son dossier à 50 %. Le support conseille de joindre un PDF vide pour passer l’étape. Ce contournement résout le blocage visuel, mais introduit un faux justificatif et rend le prochain contrôle moins fiable.

Le vrai enjeu est de décider quelles pièces sont requises avant de mesurer ce qui manque. Un choix absent ne vaut pas « non », un choix « non » ne rend pas tous les documents obligatoires, et une référence de fichier ne prouve pas que la pièce est recevable. Ces distinctions doivent guider la règle, le message et l’action autorisée.

Vous allez construire une règle conditionnelle à partir de six dossiers fictifs, vérifier son schéma et corriger le calcul de complétude. Le résultat sépare une obligation inconnue, une pièce requise manquante, une pièce en analyse et une section sans document requis. Aucun test de compréhension auprès de clients réels n’est revendiqué.

Dawap relie ce modèle au développement web sur mesure. Pour un portail client ou extranet B2B, la recette vérifie pourquoi chaque pièce est demandée, quelle preuve la satisfait et ce que l’utilisateur doit faire lorsque l’information nécessaire reste inconnue.

Pour qui une pièce facultative peut bloquer un dossier

Ce problème apparaît dans les portails qui adaptent leurs documents à un service, un site ou une option choisie. Une liste fixe de pièces est alors insuffisante. La pertinence d’un document dépend d’un fait qui peut être confirmé, absent, invalide ou modifié pendant le brouillon.

Reconnaître le coût d’une obligation mal calculée

Les premiers indices sont les fichiers nommés « non concerné », les documents vides et les tickets demandant quoi déposer pour débloquer l’étape. Ils montrent que le système impose une présence sans savoir expliquer son besoin. Les utilisateurs apprennent à satisfaire le contrôle informatique plutôt qu’à fournir une preuve utile au service.

Le support doit ensuite distinguer ces contournements des vraies pièces. Une vérification documentaire devient plus longue et le reporting compte un dépôt comme une résolution. Le cadrage du self-service dans un portail client traite ce coût global ; la méthode présente qualifie le déclencheur précis de l’obligation.

Paradoxalement, accepter davantage de fichiers peut dégrader la qualité du dossier. Le PDF vide déposé pour une exigence sans objet gonfle le compteur, puis oblige l’équipe à l’ouvrir et à reconstituer le choix initial. Le coût caché vient de cette fausse preuve : elle transforme une décision automatique possible en vérification manuelle inutile.

Définir une règle interne sans inventer une obligation réglementaire

Dans notre scénario, une entreprise demande un plan d’accès uniquement pour une livraison sur site. Ce choix est une règle de service fictive, destinée à préparer une intervention. Il ne décrit ni une obligation légale ni une exigence applicable à toutes les livraisons B2B. Le métier doit définir et posséder sa règle réelle.

Le périmètre est la section documentaire de ce service. Une section satisfaite ne prouve pas que le contrat, la commande ou l’ensemble du dossier est complet. D’autres conditions peuvent encore commander l’instruction. Le produit conserve ces frontières pour qu’un badge de pièce ne devienne pas une autorisation générale.

Déterminer l’applicabilité avant de chercher la pièce

La première réponse porte sur la nécessité du plan. La seconde porte sur sa présence et son état. Le système doit pouvoir répondre à la première sans disposer du document, et refuser de fabriquer cette réponse lorsqu’il manque le choix qui la détermine.

Conserver trois réponses métier à la condition

Lorsque livraisonSurSite vaut vrai, le plan est requis. Lorsque la valeur vaut faux, le plan n’est pas requis pour cette règle. Lorsque le choix manque, son applicabilité reste inconnue. La prochaine action consiste alors à demander le choix de livraison, et non à réclamer immédiatement un document.

Un défaut de type constitue une quatrième situation technique à corriger. La valeur null, une chaîne « non » ou le nombre zéro ne doivent pas être convertis silencieusement en faux dans ce contrat booléen. La référence JSON Schema sur null distingue explicitement une valeur nulle d’une propriété absente.

Séparer la pièce non requise de la pièce interdite

Une pièce non requise n’entre pas dans le dénominateur de cette obligation. Elle peut néanmoins exister dans le dossier si le modèle autorise les documents facultatifs. Son existence ne lui donne aucun droit de téléchargement et ne justifie pas de la montrer à un autre compte. Applicabilité documentaire et autorisation restent deux contrôles séparés.

Si la condition devient fausse après un dépôt, la pièce cesse de satisfaire une exigence active, mais elle ne doit pas disparaître automatiquement de l’historique. Son traitement suit la politique du dossier. Le produit explique que le changement porte sur l’obligation, sans confondre cette décision avec une suppression physique du fichier.

Écrire une condition qui teste la valeur, pas seulement la présence

La documentation JSON Schema des conditions distingue les dépendances déclenchées par la présence d’une propriété et les branches if, then, else. Ces mécanismes ne représentent pas automatiquement la même règle métier.

Pourquoi dependentRequired réclamerait le plan après un choix faux

Une dépendance dependentRequired entre livraisonSurSite et planAccesRef s’active lorsque la première propriété existe. Elle ne signifie pas « uniquement quand la valeur est vraie ». Dans le dossier B, le client a bien répondu faux : la propriété existe et une telle dépendance réclamerait malgré tout le plan.

Le bon modèle utilise une condition sur la valeur vraie. Cette branche doit aussi exiger la présence du choix dans son propre test. Un bloc properties seul ne suffit pas à rendre la propriété obligatoire. La référence JSON Schema des objets précise le rôle distinct de required.

Vérifier le schéma structurel de soumission

Le schéma ci-dessous décrit uniquement la forme des données fictives à soumettre. Il exige le choix booléen et demande une référence non vide quand le choix vaut vrai. Il ne vérifie ni existence du fichier, ni analyse, ni propriété, ni autorisation. Ces preuves appartiennent au domaine et au stockage documentaire.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "livraisonSurSite": { "type": "boolean" },
    "planAccesRef": { "type": "string", "minLength": 1 }
  },
  "required": ["livraisonSurSite"],
  "if": {
    "properties": { "livraisonSurSite": { "const": true } },
    "required": ["livraisonSurSite"]
  },
  "then": { "required": ["planAccesRef"] }
}

Dans A, le choix manque. Le contrôle racine rejette la soumission sur ce choix, tandis que la condition protégée n’ajoute pas une erreur de plan. Sans le required dans le test if, cette branche pourrait aussi s’appliquer à un objet sans choix et produire une demande documentaire hors contexte.

Permettre un brouillon incomplet sans accepter sa soumission

Le client peut encore chercher une information ou un fichier. Sauvegarder son travail et accepter sa soumission n’impliquent donc pas les mêmes préconditions. Utiliser directement le schéma final pour chaque sauvegarde empêcherait le parcours de conserver les dossiers que l’on souhaite précisément aider à compléter.

Distinguer les commandes de sauvegarde et d’instruction

Le contrat de brouillon permet un choix absent et une référence de plan absente. Il vérifie le type des valeurs effectivement fournies, les droits et la version. La commande de soumission ajoute le choix requis, l’exigence conditionnelle et les contrôles documentaires. Un brouillon sauvegardé ne devient pas « prêt à instruire » par la seule réussite de son enregistrement.

La conception des formulaires à reprise détaille les étapes et les sauvegardes. Ici, leur contrat porte une différence vérifiable : C peut être conservé avec un plan encore manquant, tout en restant refusé pour instruction. Le même dossier reçoit deux décisions cohérentes selon la commande demandée.

Ne pas utiliser un PDF vide comme exception de domaine

Une exception légitime doit posséder un motif et une autorité définis, distincts de la pièce attendue. Si le métier accepte un autre mode de préparation, il peut créer une règle de dispense ou une preuve alternative. Un fichier factice n’est pas une dispense : il rend les deux situations indiscernables dans le dossier.

L’interface offre donc « conserver mon brouillon » quand la pièce manque, puis explique ce qui bloque la soumission. Le support peut orienter vers l’alternative prévue si elle existe. Il ne doit pas rendre le document « valide » uniquement pour effacer un compteur rouge, car cette modification affecterait le contrôle aval sans trace de la décision réelle.

Exercice : six dossiers pour une seule règle de plan d’accès

Les données et états qui suivent sont synthétiques. Tous les dossiers appartiennent à la même organisation autorisée et utilisent la règle R1. Cette règle demande un plan seulement lorsque la livraison se fait sur site. Les références PLAN-D et PLAN-E désignent des pièces internes fictives ; leur nom ne fournit aucune preuve sur un fichier réel.

Lire les données avant d’appliquer le badge

A n’a pas encore de choix. B possède le choix faux. C possède le choix vrai sans référence. D possède le choix vrai et une pièce acceptée dans le registre de test. E possède le choix vrai et une référence dont l’analyse reste en attente. F transmet une valeur nulle à la place du booléen.

Pour chaque dossier, décidez l’applicabilité du plan, l’état documentaire, la possibilité de sauvegarde et la possibilité de soumission. Le statut « accepté » de D est une hypothèse de la fixture, pas un résultat produit par JSON Schema. La recette doit pouvoir retirer cette preuve et constater que la décision de soumission change.

Changer une preuve à la fois

La première variante remplace le choix vrai de D par faux : l’obligation disparaît, mais le dépôt reste dans l’historique. La deuxième retire l’acceptation de PLAN-D : la référence reste présente, mais elle ne suffit plus à soumettre. La troisième retire le détail documentaire de E : le verdict devient inconnu, sans demander un second upload automatique.

Ces contre-tests empêchent une règle d’apprendre le nom des dossiers ou le nombre de fichiers. Le résultat doit dépendre du choix, de la preuve et de la version concernée. Si retirer une preuve ne change aucune décision alors qu’elle est censée être obligatoire, le contrôle n’est probablement qu’une validation de présence.

Corrigé : quatre messages avant tout pourcentage de dossier

Une même absence de référence conduit à des actions différentes dans A, B et C. Le client doit choisir son mode de livraison dans A, ne doit rien joindre pour cette exigence dans B et doit déposer le plan dans C. Un message unique « document manquant » ferait travailler deux clients sur une obligation qui n’est pas établie.

Relier la prochaine action à la preuve manquante

La matrice distingue également E, où le client a déjà fourni sa pièce, de C, où elle n’a pas été déposée. L’attente d’un traitement ne doit pas devenir une demande de ressaisie. Les messages proposés sont des exemples de microcopie à éprouver avec vos utilisateurs, sans résultats de test utilisateur inventés.

Vérifier la structure puis la recevabilité

Le schéma final accepte la forme de B, D et E. Le contrôle documentaire accepte la section de B et D seulement dans cette fixture. E prouve la différence : la référence existe et possède le bon type, mais le verdict métier reste en attente. A, C et F échouent structurellement pour des raisons différentes.

Pour la sauvegarde, le contrat de brouillon accepte A à E et rejette le type nul de F. Un rejet de cette valeur ne doit pas détruire les autres éléments déjà enregistrés. L’interface conserve la saisie autorisée et oriente la correction sur le choix concerné, sans demander de recommencer le dossier.

Calculer la complétude sur un ensemble de pièces connu

La mesure documentaire dépend de l’ensemble des exigences applicables. Elle ne prend pas comme dénominateur toutes les cartes de document que le design connaît. Une pièce facultative ne doit pas réduire le score d’un client qui n’a pas à la fournir.

Refuser un taux lorsque la condition reste inconnue

Dans A, l’ensemble requis n’est pas encore calculable. Le résultat n’est ni zéro pièce sur une ni zéro sur zéro. Le produit affiche « mode de livraison à préciser ». Dans B, l’ensemble est connu et vide : il peut afficher « aucun plan requis » sans présenter une division 0/0 ni déduire que tout le dossier est terminé.

Dans C, le résultat documentaire est zéro pièce acceptée sur une requise. Dans D, il est une sur une. Dans E, il est zéro acceptée sur une, avec une pièce reçue en attente. Le libellé d’attente doit accompagner le résultat, sinon le client peut croire qu’il n’a pas encore fourni son document.

Séparer la progression de dépôt de la progression d’acceptation

E a terminé son geste de dépôt pour cette pièce, mais pas l’instruction documentaire. Deux indicateurs peuvent être utiles s’ils ont des noms explicites : pièces reçues et pièces acceptées parmi les requises. Leur unité reste la pièce, et non le nombre de fichiers, de pages PDF ou de tentatives d’upload.

Une nouvelle version du même plan ne crée pas une deuxième exigence satisfaite. Le dossier conserve la version retenue et l’état de chaque tentative. La règle de complétude doit ainsi pouvoir expliquer pourquoi deux fichiers déposés ne valent qu’une pièce attendue, tandis qu’un seul fichier refusé ne satisfait aucune exigence.

Expliquer ce qui change lorsque la règle évolue

La décision conserve la version de règle et les faits qui déterminent l’obligation. Le besoin n’est pas une nouvelle machine à états générale : il s’agit de rendre reproductible l’ensemble de pièces demandé à un dossier à un instant donné.

Qualifier une nouvelle exigence avant de redemander une pièce

Exemple concret fictif : R2 ajoute une photo du site pour les livraisons sur site. D possède toujours un plan accepté, mais aucun document correspondant à cette nouvelle exigence. S’il entre dans la population à laquelle R2 s’applique, la section passe d’une pièce acceptée sur une requise à une sur deux. Ce changement ne signifie pas que le plan a été perdu.

Le produit explique la nouvelle pièce, sa raison et sa date d’application. Il ne compare pas directement des taux calculés sous R1 et R2 comme s’ils mesuraient la même charge documentaire. Les dossiers déjà soumis conservent leur décision antérieure ou suivent une migration explicitement décidée par le responsable du service.

Préserver la version utilisée au moment de la soumission

Deux onglets peuvent afficher des choix ou versions différents. La soumission transmet la version lue et le backend vérifie le dossier courant. Si le choix est devenu vrai pendant que l’autre onglet affiche encore faux, la soumission ne doit pas contourner l’exigence par un ancien écran. Le conflit renvoie un résultat qualifié et conserve le travail récupérable.

Le modèle d’états partagé entre les vues approfondit la cohérence générale du dossier. La règle de pièces en est une précondition précise. Elle produit un ensemble explicable et un motif de refus ; elle ne remplace pas les autres transitions et capacités du workflow.

Ne pas déduire un droit d’accès du résultat documentaire

Le serveur doit vérifier la relation entre la pièce, le dossier et l’acteur avant d’utiliser la référence fournie. Une chaîne non vide peut désigner un objet inexistant ou un document appartenant à un autre compte. Le schéma structurel accepte sa forme sans connaître cette relation.

Éprouver une référence dont l’acteur n’a pas le droit

La méthode OWASP d’autorisation recommande de contrôler les permissions sur chaque requête et de refuser par défaut ce qui n’est pas autorisé. Dans la recette, remplacer PLAN-D par une référence d’un autre compte ne doit ni satisfaire l’obligation ni révéler le nom ou l’état de cette pièce.

Le message public reste adapté au droit de l’acteur : la référence ne peut pas être utilisée pour ce dossier et une action autorisée lui est proposée. Les détails nécessaires à l’enquête sont conservés dans le circuit habilité. « Non requis » et « inaccessible » restent distincts dans ce circuit, même si l’interface externe limite volontairement ce qu’elle peut expliquer.

Revalider la pièce lorsque le geste engage l’instruction

Un résultat de validation mis en cache ne doit pas autoriser une soumission après révocation de l’accès ou remplacement de la pièce. Le backend contrôle à nouveau les préconditions du geste et conserve la version acceptée. Le frontend reçoit le résultat utile à son parcours au lieu de reconstruire la recevabilité depuis une couleur de carte.

Un lecteur peut être autorisé à connaître l’avancement sans pouvoir télécharger le plan. La politique de consultation détermine cette projection. Les tests négatifs portent donc aussi sur les titres, compteurs et historiques exposés, pas seulement sur le fichier final. La preuve de complétude ne doit pas devenir un canal de révélation documentaire.

Tester la compréhension du message avant d’optimiser le badge

Un message sert à faire comprendre la prochaine action. Demandez à une personne de qualifier A, B, C et E sans connaître la règle interne : doit-elle choisir, déposer, attendre ou poursuivre ? Cette recette de compréhension est à mener sur votre produit ; les phrases proposées n’ont pas été validées par un panel réel.

Observer les erreurs de décision plutôt que les préférences de couleur

Le test échoue si la personne cherche un plan dans A, dépose un faux document dans B ou renvoie le fichier de E. Une hésitation sur le prochain geste mérite une correction du texte ou de la hiérarchie avant une animation de progression. L’observation conserve le scénario, la consigne, le choix effectué et la raison exprimée.

Les chiffres de temps sont mesurés localement et servent à comparer deux versions du message sur des scénarios équivalents. Une explication mémorisée après plusieurs passages ne représente pas la première compréhension d’un client. Séparez les personnes familières du processus et celles qui découvrent l’obligation documentaire.

Rendre perceptible le changement d’état utile

La référence W3C des messages de statut couvre les changements pertinents qui peuvent être annoncés sans déplacer le focus. Une pièce passée d’analyse à acceptation doit pouvoir être comprise au-delà d’un changement de couleur. Le parcours réel demande des tests clavier et lecteurs d’écran.

La suppression d’une obligation après un choix faux doit aussi rester explicable. Le client sait pourquoi il n’a plus à déposer le plan et retrouve son choix. La recette vérifie ce comportement sur mobile et lors d’une reprise de session. Aucun score de contenu ni schéma JSON ne peut, à lui seul, certifier l’accessibilité de cette interface.

Plan d’action : fermer le contrat de pièces conditionnelles

Le premier atelier inventorie les documents et leurs déclencheurs réels. Pour chaque règle, le métier précise le fait nécessaire, ses valeurs admises, la preuve documentaire acceptable et la commande concernée. Une condition qui ne possède aucun responsable reste hors de l’automatisation.

Livrer ensemble obligation, preuve et message

Les entrées du contrôle réunissent dossier, acteur, version de règle, choix et références de pièces. La sortie distingue applicable, non applicable, inconnu et donnée invalide, puis les pièces attendues et leur état. Le backend porte les responsabilités de décision ; le frontend présente les actions autorisées. La traçabilité relie la demande de document à son déclencheur.

La mise en œuvre peut séparer un service de règles métier, un registre de pièces et la projection de portail. Les API fournissent les états nécessaires ; les traitements d’analyse asynchrones conservent leur corrélation. En Symfony, le cas d’usage de soumission recontrôle les préconditions du dossier ; la sauvegarde du brouillon conserve son contrat plus souple.

Le monitoring suit les obligations inconnues, les références refusées et les analyses en attente au-delà du seuil interne. Si une dépendance ne permet plus de qualifier la pièce, alors le repli suspend l’instruction dépendante et conserve les observations précédentes avec leur âge. Le rollback retire la nouvelle règle des dossiers concernés selon une décision versionnée, sans effacer les pièces ni les soumissions passées.

Ouvrir une cohorte après les contre-tests

Rejouez A à F, puis changement de choix, nouvelle règle, document d’un autre compte et deux onglets. La CI peut vérifier schémas et invariants ; la QA de parcours contrôle messages, sauvegarde et gestes. Une erreur ne doit ni fabriquer une dispense ni forcer un document factice pour atteindre un statut vert.

La première cohorte compare demandes de support et décisions documentaires à leur cause. Le go exige des obligations expliquées, des refus localisés et des pièces protégées dans le périmètre testé. Une régression de droits ou une soumission acceptée sans preuve requise maintient le veto, même si le taux de dépôt augmente.

Pour ce scénario, le seuil de recette est zéro obligation de plan déduite dans A ou B et zéro soumission documentaire acceptée dans C ou E. Si B réclame un plan, alors la condition est incorrecte. Si E autorise l’instruction, alors la réception a été confondue avec l’acceptation. Ces critères portent sur les résultats attendus de la fixture, pas sur une mesure de production.

Mesurer les demandes évitées sans promettre un gain

La mesure commence par les demandes injustifiées : plan réclamé après un choix faux, fichier redemandé pendant l’analyse et document demandé avant qualification. Ces populations ne sont pas interchangeables. Chaque correction doit être reliée à sa règle et à la prochaine action réellement obtenue.

Calculer une charge de reprise explicite

Dans une hypothèse fictive, quinze tickets de sept minutes à 45 euros par heure représentent 78,75 euros de charge : 15 × 7 ÷ 60 × 45. Cette estimation décrit le travail de réponse ; elle ne compte pas un chiffre d’affaires perdu ni une économie déjà réalisée. Le coût de maintien des règles et des contrôles doit également être suivi.

Après correction, mesurez les dossiers concernés, les dépôts factices et les tickets par motif sur une période comparable. Une baisse liée à un moindre volume ne démontre pas l’amélioration de la règle. Vérifiez aussi que les équipes d’instruction ne reçoivent pas davantage de dossiers incomplets parce que l’interface a simplement supprimé un blocage.

Prolonger le contrôle avec les modèles du dossier

Le workflow des formulaires complexes approfondit sauvegarde, reprise et soumission. Le modèle d’états métier relie les décisions aux vues internes. Ces deux prolongements complètent l’obligation conditionnelle sans en reconstruire le test de valeur dans chaque écran.

La pièce possède aussi son cycle propre. Le rattachement des pièces au dossier traite les relations et la chronologie. La règle de complétude consomme une preuve qualifiée de ce cycle ; elle n’absorbe pas toutes les décisions de stockage, de remplacement ou de clôture.

Erreurs fréquentes : trois raccourcis qui changent le verdict

La règle perd son sens lorsque l’interface remplace une information métier par une commodité d’affichage. Les trois raccourcis suivants produisent chacun une décision différente de celle attendue dans l’exercice. Ils se vérifient séparément pour localiser la régression.

Refuser les conversions qui inventent une réponse

Initialiser le choix absent à faux masque la question à poser dans A. Convertir null en faux fabrique une réponse dans F. Ces transformations facilitent le rendu d’un bouton ou d’une case, mais empêchent le serveur de distinguer une décision client d’un défaut de saisie.

La revue du parcours vérifie les valeurs réellement envoyées à la sauvegarde et à la soumission. Un affichage initial ne doit pas devenir une réponse enregistrée sans geste explicite. Les vérifications suivantes restent indépendantes, car les fusionner dans un unique badge cacherait leur cause.

• Choix absent : demander sa qualification avant de calculer l’ensemble requis.
• Choix faux : ne pas exiger un plan au seul motif que la propriété existe.
• Référence présente : vérifier l’autorisation et l’acceptation avant d’autoriser l’instruction.

Projets liés : les documents dans le portail B2B de 1UP

La règle conditionnelle de l’exercice est fictive. Un portail effectivement livré peut néanmoins montrer comment documents, compte et action restent liés dans un parcours métier. Le point de comparaison porte sur cette relation, sans attribuer au client notre exigence de plan d’accès.

Relier la consultation documentaire au compte autorisé

Le portail client B2B de 1UP Distribution rassemble commandes, factures et avoirs dans le contexte du compte sélectionné. Les factures et avoirs proviennent d’Odoo ; leurs PDF sont servis à partir des pièces stockées et contrôlées. Un identifiant de document ne suffit pas à ouvrir celui d’un autre compte.

Cette réalisation illustre la frontière entre une interface autonome et la source qui porte la preuve documentaire. Elle ne démontre ni une règle JSON Schema de plan conditionnel chez 1UP, ni le gain chiffré de notre exercice. Pour votre portail, le même travail de cadrage consiste à préciser qui possède la pièce, quel compte peut la consulter et quel geste sa qualification autorise.

Conclusion : demander une preuve dont la nécessité est établie

Un document absent n’est pas nécessairement manquant. Il peut être non requis ou dépendre d’un choix encore inconnu. Calculer cette applicabilité avant la complétude évite de faire déposer des fichiers sans valeur pour satisfaire l’interface.

Le schéma teste la forme et la condition ; le domaine qualifie la pièce et les droits. Les six dossiers montrent pourquoi faux diffère d’absent, pourquoi une référence diffère d’une acceptation et pourquoi une attente ne réclame pas forcément une nouvelle action client.

La recette d’un portail client B2B doit rendre ces décisions compréhensibles, puis revalider la règle lors du geste qui engage le dossier. Le résultat conserve version, preuve et prochaine action, avec une mesure limitée à l’ensemble documentaire réellement connu.

Dawap vous accompagne en développement web sur mesure pour modéliser ces préconditions, construire les parcours et éprouver les contre-tests. Le produit demande alors la bonne pièce au bon moment, sans déléguer sa propre incertitude au client ou au support.