La note est enregistrée. Pourquoi le diagnostic corrigé a-t-il disparu ?

Le technicien corrige le diagnostic d’une intervention : le défaut vient d’un connecteur desserré, pas de la pompe. Un gestionnaire garde le même rapport ouvert dans un autre onglet et ajoute « client rappelé ». Il enregistre, obtient une confirmation, puis découvre que l’ancien diagnostic est revenu. Les deux personnes ont utilisé la bonne fiche ; la seconde sauvegarde a néanmoins effacé la première correction.

Le vrai enjeu est de vérifier la version que la personne avait sous les yeux avant d’appliquer sa proposition. Recharger le dossier depuis la base au moment du clic ne suffit pas : le serveur peut recevoir un ancien formulaire, lire une fiche récente, puis lui recopier des valeurs périmées. La réussite de l’enregistrement prouve alors une écriture, sans prouver qu’elle respecte le travail déjà réalisé.

Commencez par conserver la révision du rapport avec chaque ouverture du formulaire, puis faites porter cette référence par la commande d’enregistrement. Ne la remplacez pas par celle que le serveur vient de relire. Neuf situations fictives et 31 contrôles SQLite comparent refus, mauvaise comparaison et reprise explicite. Ils montrent aussi ce qui doit rester disponible lorsqu’une saisie ne peut pas encore être enregistrée.

Dawap développe des outils en développement web sur mesure, avec des applications métier qui relient les gestes des équipes aux règles du dossier. Le cas étudié porte sur l’édition d’un rapport SAV partagé. Il permet de cadrer un défaut de formulaire et son traitement serveur sans supposer qu’un changement d’interface ou d’ERP résoudrait seul la perte de données.

Pour qui : des équipes modifient un rapport déjà ouvert ailleurs

Reconnaître une correction disparue après un enregistrement réussi

Le symptôme concerne les responsables SAV, les techniciens, l’ADV et le support qui complètent un dossier commun. Une fiche peut rester ouverte pendant un appel, une recherche de pièce ou une intervention. Entre son affichage et sa sauvegarde, une autre personne change le diagnostic, ajoute une réserve ou valide le rapport. La durée de lecture appartient au travail normal ; elle ne doit pas rendre les corrections interchangeables.

Deux signaux faibles méritent une enquête : une note récente apparaît avec une ancienne valeur technique, ou l’historique montre des alternances sans correction volontaire reconnue par les auteurs. Examinez aussi les demandes de verrouiller toute la fiche et les consignes de fermer les autres onglets avant d’écrire. Ces contournements peuvent révéler une comparaison de versions absente plutôt qu’un manque de discipline de l’équipe.

Délimiter le conflit d’édition avant de refaire le workflow

Le parcours étudié concerne un rapport modifiable, identifié et partagé. Il ne décide pas comment annuler un rapport validé, corriger une facture ou modifier une pièce transmise à un client. Ces actions suivent leurs propres autorisations. Une saisie refusée doit garder sa proposition et son motif ; elle ne peut pas rouvrir un document engagé sous prétexte que le diagnostic avait été renseigné dans un autre onglet.

Une page de consultation sans écriture n’exige pas ce mécanisme de sauvegarde. Une fiche dont chaque intervention crée un événement indépendant peut aussi présenter d’autres règles. Vérifiez l’objet réellement modifié et les invariants avant de choisir une version globale. Le diagnostic commence par une paire d’enregistrements et leurs valeurs, sans réclamer une collaboration en temps réel ou une refonte complète du produit.

Anatomie de l’écrasement : deux formulaires issus de la révision 37

Conserver ce que chaque onglet a réellement lu

Exemple concret A : notre rapport fictif 71 commence en révision 37 avec « pompe suspectée ». Les onglets A et B reçoivent cette même représentation. A change le diagnostic en « connecteur desserré » et enregistre ; le dossier passe en révision 38. B conserve encore son formulaire initial. Il ajoute seulement une note à l’écran, mais son envoi peut contenir tous les champs, dont le diagnostic qu’il n’a pas voulu corriger.

La commande de B doit donc garder l’identité du rapport, son périmètre, la révision 37 et la proposition. Le backend compare cette référence à l’état courant. L’auteur peut être la même personne dans deux onglets : son identité ne remplace pas celle de la lecture. Une session partagée qui conserve seulement « la dernière version ouverte » ne permet pas nécessairement de distinguer les deux formulaires.

Lire l’intention au-delà du formulaire complet

Le gestionnaire voulait ajouter une note, pas revenir à une hypothèse technique abandonnée. Pourtant, le serveur peut considérer l’ensemble du formulaire comme une nouvelle vérité. Pour reconstituer l’incident, comparez représentation ouverte, valeurs envoyées, état avant écriture et état obtenu. Le simple journal « rapport modifié » ne montre pas pourquoi un diagnostic ancien a accompagné une information nouvelle.

Cette lecture aide à choisir entre édition complète et commande plus étroite. Une note ajoutée comme ressource indépendante peut suivre un contrat différent d’un remplacement du rapport. Cela reste une décision de modèle : elle doit conserver les droits, le contexte et les conséquences. Retirer arbitrairement un champ du payload pour corriger le dernier incident ne garantit pas que les autres modifications gardent leur sens.

Pourquoi relire une entité récente ne protège pas l’ancien formulaire

Distinguer l’ouverture utilisateur de la lecture pendant le POST

Une application Symfony peut relire le rapport en révision 38 avant d’appliquer l’envoi de B. Si elle utilise cette nouvelle révision comme référence attendue, le contrôle semble cohérent : 38 est comparée à 38. L’ancien diagnostic entre ensuite dans l’entité et la sauvegarde passe à 39. Le serveur a protégé son état récemment chargé, mais il a oublié que les valeurs proposées venaient de la révision 37.

Le défaut n’exige donc pas deux transactions simultanées. Une correction peut être entièrement terminée avant que l’ancien formulaire soit envoyé. Le test de concurrence doit inclure cette séquence, en plus des écritures rapprochées. Mesurer uniquement les verrous de base ou les erreurs de flush laisserait passer une perte provoquée pendant le temps de lecture et de réflexion de l’utilisateur.

Transporter la référence originale jusqu’au verrouillage optimiste

La documentation Doctrine sur la concurrence distingue la transaction d’une requête et le temps de travail entre requêtes. Ses notes de mise en œuvre demandent de conserver la version de l’ouverture pour la vérifier lors de la mutation. Le projet confirme ensuite le mapping et les méthodes de la version installée ; le laboratoire de cette page n’exécute pas Doctrine.

La référence attendue doit rester liée à la ressource et au formulaire concernés. Elle n’accorde aucun droit d’écriture et ne remplace ni l’autorisation ni la validation métier. Un champ caché n’est pas une valeur sûre par nature ; le serveur en contrôle le type et l’usage. Surtout, une référence manquante ne doit pas être complétée depuis l’état récent pour rendre le traitement compatible.

Comparer et écrire sans laisser une correction passer entre les deux

Garder la condition au moment de la mutation

Un contrôle applicatif peut d’abord constater que le rapport est encore en révision 37, puis attendre avant d’écrire. Une autre commande enregistre sa correction pendant cet intervalle. Si la sauvegarde suivante n’a plus de condition sur la révision, l’examen initial ne protège rien. Le cas H du témoin place précisément une écriture entre la vérification et la tentative conditionnelle.

Le laboratoire utilise un UPDATE SQLite qui cible ensemble périmètre, rapport, révision attendue et statut modifiable. La correction A fait passer 37 à 38 ; l’écriture B attend toujours 37 et ne modifie aucune ligne. La référence SQLite de l’opération UPDATE explique la sélection des lignes par sa condition. Cette exécution locale démontre le témoin SQL, sans certifier les transactions de votre application.

Interpréter l’absence d’écriture sans produire une réussite trompeuse

Une tentative qui ne touche aucune ligne ne doit pas déclencher « enregistré », puis une notification ou une génération de rapport. Le service retrouve la cause dans le périmètre autorisé : révision différente, état fermé ou ressource indisponible. Le parcours restitue un refus compréhensible. Il évite d’afficher des données d’un autre compte simplement pour expliquer pourquoi une condition n’a pas trouvé de cible.

Les effets suivent la mutation confirmée. Une erreur de concurrence n’est pas une demande de répéter automatiquement le même formulaire avec une nouvelle référence. Le traitement conserve sa corrélation, sa proposition et son état. Le contrat précise également comment retrouver une sauvegarde dont la réponse manque après acceptation ; ce résultat inconnu ne doit pas être confondu avec le refus démontré par le témoin.

Présenter le conflit sans effacer la note que l’utilisateur vient de saisir

Montrer valeur lue, proposition et donnée courante

Le refus de B doit expliquer que le rapport a changé depuis son ouverture. Pour le diagnostic, le gestionnaire peut comparer « pompe suspectée », sa proposition inchangée et « connecteur desserré » dans le dossier courant. La note « client rappelé » reste disponible dans sa saisie. Cette présentation permet de comprendre le conflit sans demander au support de reconstituer les écrans depuis des captures.

Le bouton d’enregistrement ne doit pas laisser croire que la note est déjà durable. Le parcours peut proposer une relecture du rapport, la sélection d’une correction à réappliquer ou l’abandon de la proposition. La décision reste explicite. Une fenêtre qui remplace discrètement tous les champs par ceux du serveur perd le travail local ; une fenêtre qui conserve tous les champs anciens puis retente perd potentiellement celui des autres.

Réappliquer une modification choisie depuis une nouvelle lecture

Dans le cas concret C, le gestionnaire relit la révision 38 et confirme que le diagnostic corrigé doit rester. Il réapplique sa seule note à cette représentation, puis enregistre vers 39. Le résultat conserve « connecteur desserré » et « client rappelé ». Cette reprise diffère du cas B : ce dernier avait seulement remplacé la révision attendue tout en renvoyant l’ancien contenu complet.

La recette doit éprouver cette différence avec une personne qui comprend le dossier. Des champs modifiés séparément ne sont pas forcément indépendants : diagnostic, pièce proposée et état de réparation peuvent former une décision commune. Le produit ne doit pas généraliser une fusion automatique depuis une égalité de noms de champs. Il qualifie les rapprochements autorisés et maintient un parcours assisté pour les autres.

Exercice corrigé : neuf situations sur l’ancien formulaire et la révision courante

Les rapports, diagnostics et notes suivants sont fictifs. Le script exécute des écritures conditionnelles dans des bases SQLite en mémoire, avec un ordre fixé. Il ne lance aucun utilisateur, navigateur de formulaire, EntityManager Doctrine ou worker concurrent. Avant chaque cas, choisissez si la proposition doit être enregistrée, refusée ou relue ; le résultat ne doit jamais dépendre du seul dernier clic.

Lire les résultats qui prouvent une protection ou un défaut

Le cas A commence par deux lectures en 37, puis une correction vers 38. Le second formulaire est refusé et sa proposition reste conservée séparément. Le cas B reproduit volontairement la mauvaise référence : il remplace 37 par la version courante, sauvegarde l’ancien diagnostic et expose une perte. Le cas C reprend après examen du dossier récent, avec la note choisie et le diagnostic maintenu.

Les 31 contrôles passent. Le cas B est attendu comme démonstration d’un défaut, pas comme sauvegarde admissible dans la méthode retenue. Les autres observations comprennent les valeurs préservées, la révision obtenue et l’absence de modification des ressources voisines. Le seuil du témoin refuse toute proposition ancienne qui remplace silencieusement une correction déjà enregistrée.

Ajouter la recette native que le tableau ne remplace pas

Le projet doit encore vérifier le formulaire construit, son mapping, les transactions réelles, les droits et les effets qui suivent l’enregistrement. Le test local n’exécute ni un verrou ORM ni une précondition HTTP. Il ne mesure pas le débit, les deadlocks ou la tenue de plusieurs workers. Ses tentatives sont ordonnées pour rendre le mécanisme inspectable, sans présenter ce scénario comme une campagne sous charge.

Le seuil d’ouverture proposé demande zéro correction écrasée dans les scénarios retenus et zéro confirmation de sauvegarde après refus. La recette ajoute maintien de la saisie, explication de la différence et nouvelle proposition choisie. Un résultat conforme côté SQL ne suffit pas si le frontend perd la note ou invite à forcer l’enregistrement ; l’utilisateur doit retrouver un parcours utilisable au bout du conflit.

Choisir une révision de dossier ou une précondition HTTP avec un contrat précis

Ne pas confondre numéro affiché et preuve de la représentation

Le numéro du témoin change à chaque sauvegarde admise. Il n’est pas calculé depuis l’heure affichée ni depuis le nombre d’onglets. Le cas I fournit volontairement deux affichages temporels identiques, avec des révisions distinctes. Cette comparaison ne simule aucune horloge de base ; elle montre pourquoi une valeur de présentation trop grossière ne doit pas être utilisée comme référence d’édition.

Le projet définit aussi ce que couvre la révision : rapport complet, section ou autre ressource. Une granularité fine peut éviter certains refus, mais elle exige de préserver les règles qui traversent les sections. Le technicien doit savoir quel contenu est validé ensemble. Multiplier les compteurs sans modèle de décision peut rendre une correction partiellement acceptée et pourtant incompréhensible dans le rapport final.

Rendre la condition effective à l’origine de l’API

La sémantique HTTP d’If-Match décrit une précondition avec comparaison forte pour éviter notamment des écrasements. Une condition fausse interdit la mutation demandée ; 412 peut signaler ce refus, avec les nuances du protocole pour une action déjà appliquée. Le contrat du projet doit relier le validateur reçu à la représentation modifiée et à la décision durable.

Un en-tête ajouté au frontend ne protège rien si le service l’ignore ou le remplace par une valeur courante. Pour une application existante, la migration peut commencer par un formulaire pilote et un endpoint explicite. Les autres auteurs d’écriture doivent ensuite être recensés. Une ancienne API, un import ou une commande d’administration qui remplace le rapport sans révision peut encore contourner la protection du nouvel écran.

Préserver les droits et le statut du rapport après le conflit

Refuser une modification lorsqu’une validation a fermé l’édition

Dans le cas G, le rapport passe de brouillon à validé avant la seconde tentative. L’ancienne proposition est refusée, mais une version fraîche ne suffit pas non plus à rouvrir l’écriture. Le droit de voir la donnée actuelle et le droit de la modifier restent distincts. Le gestionnaire doit retrouver la procédure prévue pour demander ou effectuer une correction après validation.

Le backend revérifie acteur, périmètre, état et règle au moment de la commande. L’interface peut expliquer le refus sans afficher un bouton de force qui neutralise tous les contrôles. La version détecte une modification depuis la lecture ; elle ne certifie pas que le nouveau contenu est acceptable. Cette distinction permet de conserver un diagnostic corrigé tout en refusant une prochaine transition devenue incompatible.

Garder le compte et l’objet associés à la référence attendue

Le témoin F place un rapport 71 dans deux comptes et conserve un rapport 72 voisin. Une mutation sous le compte A ne change ni le rapport homonyme du compte B ni l’autre intervention. Ce contrôle examine la sélection SQL fournie. Il ne prouve pas une autorisation native : la recette de l’application doit également empêcher un acteur de choisir un périmètre auquel il n’a pas accès.

Une référence de révision peut être valide pour une ressource et sans sens pour une autre. Le contrat transporte donc la relation complète, pas seulement le nombre 37. Le support retrouve la fiche et la lecture concernées avec une corrélation. Il ne doit pas changer de dossier pour faire accepter une proposition ni diffuser la saisie complète dans les logs pour expliquer un refus de version.

Plan d’action : éprouver une correction et une note dans deux onglets

Fermer le contrat de lecture et d’enregistrement sur une fiche pilote

Le responsable SAV choisit un rapport représentatif ; le produit décrit les valeurs comparées et la reprise ; l’équipe technique suit la référence depuis l’ouverture jusqu’à la mutation. Les entrées comprennent objet, périmètre, révision attendue et proposition. Les sorties distinguent sauvegarde connue, conflit, refus métier et résultat à retrouver. Les dépendances couvrent formulaire, API, base et effets documentaires réellement utilisés.

Les tests d’intégration ajoutent deux ouvertures, une écriture terminée entre elles, puis une tentative ancienne. Ils provoquent aussi une mutation après le premier contrôle serveur. La CI vérifie les valeurs obtenues et les effets absents lors d’un refus. Le monitoring relie conflit, ressource et résultat ; la journalisation garde les références utiles sans capturer indistinctement diagnostic, pièces et données personnelles.

• Faire d’abord : reconstituer une correction perdue et vérifier quelle révision chaque formulaire transmet.
• Tester ensuite : comparer référence originale, référence remplacée et reprise depuis un contenu relu.
• Différer : la fusion automatique de sections dont les dépendances métier restent inconnues.
• Refuser : une nouvelle tentative qui change seulement la version pour forcer un ancien contenu.

Mesurer la récupération avant de généraliser le contrôle

Le coût caché inclut recherche du diagnostic, appel au technicien et correction du rapport. Dans une hypothèse fictive, quatre recherches à dix minutes et deux arbitrages à quinze minutes représentent 70 minutes. Ce calcul aide à nommer la charge que le pilote observera ; il ne décrit ni un client de Dawap ni une économie acquise. Le nombre de conflits affichés doit être relu avec les pertes réellement évitées et les reprises réussies.

Le runbook indique comment retrouver la proposition, expliquer le contenu courant et rouvrir un parcours autorisé. Le repli suspend l’édition concernée ou propose un traitement assisté sans effacer les données déjà sauvegardées. Un rollback de l’interface ne doit pas réactiver l’ancien écrasement. L’extension attend une recette comprise par le SAV et le support, puis les autres chemins d’écriture sont couverts avec leur contrat propre.

Erreurs fréquentes : confondre réussite technique et respect de la saisie

Remplacer la version, retenter ou réserver la fiche pendant tout l’appel

Actualiser seulement le numéro attendu fait disparaître le conflit sans expliquer les valeurs proposées. Un retry automatique peut alors enregistrer exactement l’ancien contenu que la protection devait refuser. À l’autre extrême, réserver la ligne en base pendant la durée du travail utilisateur transforme une attente ordinaire en blocage pour les autres auteurs. Le projet choisit une transaction courte et une conversation d’édition récupérable.

Contre-intuitivement, un enregistrement refusé peut témoigner d’un meilleur parcours qu’une confirmation immédiate. La correction du technicien reste intacte et la note du gestionnaire attend une décision explicite. Cela ne dispense pas d’améliorer la reprise : un message technique sans contenu conservé déplacerait le problème vers le support. Le veto porte sur les pertes et les confirmations fausses, pas sur l’absence de tout refus.

Fusionner des champs sans vérifier le sens de la décision

Deux champs différents peuvent décrire la même décision technique. Conserver le diagnostic récent tout en reprenant automatiquement une pièce choisie d’après l’ancien peut produire un rapport contradictoire. La recette compare base de lecture, proposition et dossier courant, puis demande les arbitrages nécessaires. Une différence de champ n’est pas une preuve que les changements se combinent sans conséquence.

Évitez également de traiter tout refus comme une panne. Un rapport validé, un accès retiré ou un dossier introuvable ne demandent pas tous un rechargement. Le message indique ce qui a été conservé et l’action possible dans le contexte autorisé. La supervision distingue ces motifs afin que l’équipe corrige une vraie erreur de contrat sans supprimer une protection utile à l’exploitation.

Lectures complémentaires : relier formulaire, ORM et décision métier

Préserver le dossier et rendre la reprise compréhensible

Le guide du back-office qui prévient les erreurs situe version, droits et confirmation dans le parcours complet. Le témoin SAV ajoute ici la comparaison précise entre version de l’ouverture et version relue pendant l’enregistrement. Il permet de tester un défaut que le seul succès du bouton ne révèle pas.

Le dossier des formulaires complexes et de leur reprise traite brouillon, sections, validation et soumission. Il aide à conserver la saisie et à distinguer un conflit d’une erreur de format. L’ancien rapport étudié ici ne doit pas perdre sa note pendant que l’utilisateur examine la correction déjà enregistrée.

Fermer la transaction sans perdre l’explication à l’écran

La lecture de Doctrine, ses transactions et ses verrous approfondit les frontières SQL, les unités de travail et leurs reprises. Elle complète la vérification de la version installée. La référence originale reste toutefois une donnée de la conversation utilisateur ; relire une entité ne recrée pas cette observation passée.

Le guide sur la lecture des écrans métier complexes aide à rapprocher état, provenance et conséquence. Le conflit doit montrer les valeurs utiles à la décision sans déverser toutes les métadonnées techniques. Le gestionnaire retrouve le diagnostic et sa note, puis choisit la reprise avec les permissions actuelles.

Conclusion : vérifier la version vue avant de remplacer le rapport

Le second onglet peut effacer une correction sans aucun chevauchement de transactions. Le défaut apparaît lorsque le serveur associe des valeurs anciennes à la version qu’il vient de relire. La protection conserve la révision de l’ouverture, vérifie la mutation sur le bon objet et refuse de la remplacer pour rendre l’écriture acceptable.

Les 31 contrôles locaux distinguent refus, mauvais numéro attendu, reprise choisie et changement de statut. Ils conservent les valeurs du dossier et la proposition non enregistrée. Leur portée reste un témoin SQLite avec ordre explicite ; le formulaire, Doctrine, les autorisations et les effets documentaires de votre application doivent encore être éprouvés ensemble.

Un pilote d’application métier peut commencer par un rapport, deux ouvertures et une correction volontaire. Vous faites examiner les valeurs obtenues, le message de conflit et la reprise par le SAV. Ce périmètre permet de qualifier les changements nécessaires avant d’étendre une règle d’édition à toutes les fiches.

Dawap peut vous accompagner dans ce parcours de développement web sur mesure. Nous relions contrat d’enregistrement, logique du dossier et reprise utilisable, afin qu’une note ajoutée après un appel ne remette pas silencieusement en cause le diagnostic déjà corrigé par l’équipe.