Ce qu’il reste à sécuriser
avant la présentation client

Décision de préparation

Présentation accompagnée possible avec un scénario préparé; livraison finale déconseillée en l’état. Corriger en premier les deux risques critiques et les blocages d’inscription, d’enregistrement et de conservation des données.

Le socle visuel et les principaux écrans sont en place. Le parcours contrôlé acheteur → demande → sélection d’un fournisseur → réponse entreprise à 74,95 CAD avec PDF → consultation acheteur → fermeture a été exécuté. Les défauts ci-dessous empêchent néanmoins de qualifier le projet de terminé.

1. Le catalogue public expose les données complètes des entreprises et contacts
2. La permission manageUsers permet de créer un administrateur
3. Un code postal du référentiel est refusé
4. L’inscription acheteur échoue sur des champs entreprise masqués
5. Le propriétaire ne peut pas enregistrer sa propre fiche
6. L’édition peut effacer quatre attributs produit existants
7. Un brouillon enregistré ne peut être repris ni envoyé
8. La pièce jointe d’une réponse n’est pas accessible dans la vue acheteur
9. La déconnexion ouvre l’accueil dans une fenêtre d’erreur Inertia

Priorités : P0 = traiter avant exposition à de vraies données; P1 = avant recette finale; P2 = stabilisation des parcours et usages; P3 = finition. Les propositions fondées uniquement sur le code sont explicitement distinguées des reproductions dans Chrome.

Ce qui fonctionne et preuves disponibles

Tests existants : 58 réussis, 2 ignorés, 289 assertions. Sondes d’audit : 14 réussies, 39 assertions, dans SQLite en mémoire. Ces sondes réussissent parce qu’elles reproduisent les défauts attendus; elles ne prouvent pas leur correction. TypeScript : vue-tsc --noEmit réussi. Aucun correctif applicatif n’a été appliqué.

Serveurs : Laravel 127.0.0.1:8088, Vite 127.0.0.1:5173. Le port 8000 était refusé par Windows. Mailer local log; deux notifications de test traitées par queue:work --stop-when-empty vers les journaux. Aucun envoi externe prouvé.

Couverture et limites par écran

Ouvrir une page valide son chargement; cela ne prouve pas toutes ses mutations. Les imports destructifs, suppressions et modifications de sécurité des comptes existants ont été évités. Les cas invalides et permissions ont été exercés dans la base de test isolée.

Données d’audit conservées

Acheteur : audit.acheteur.20261020@example.test, utilisateur 15. Entreprise : audit.entreprise.20261020@example.test, utilisateur 16, Ferme AUDIT 2026-10-20, entreprise 13. Les deux comptes ont été préparés directement en base avec vérification technique du courriel, car les inscriptions publiques étaient bloquées. Cela ne valide pas l’activation réelle.

Le compte entreprise03@raca.test, déjà fourni par les données locales, a reçu et répondu à la demande. Le nouveau compte entreprise est préparé; sa connexion séparée n’a pas été achevée en raison d’une nouvelle interception de NordPass. Le mot de passe de test des deux nouveaux comptes est présent dans les scripts de préparation locaux; ne jamais reprendre ces identifiants en production.

Demande 1 : brouillon créé, puis annulé. Demande 2 : envoyée à l’entreprise 3, réponse à 74,95 CAD avec offre-audit.pdf, puis fermée. Données conservées pour relecture; aucun compte métier existant supprimé. Les recherches d’audit peuvent apparaître dans les statistiques locales.

Les fenêtres NordPass et les blocages de l’extension sont des limites de l’environnement navigateur, distinctes des bugs RACA. Les captures qui en contiennent le signalent; elles ne constituent pas un défaut applicatif.

Captures utiles pour la revue

Ordre de correction et recette finale

1. Fermer les fuites de données et l’élévation de rôle, puis ajouter les tests de non-régression.
2. Rétablir les inscriptions, la sauvegarde propriétaire et la conservation de tous les attributs produit.
3. Terminer brouillon/reprise/envoi, pièces jointes, pagination, dates et déconnexion.
4. Rendre toutes les erreurs et confirmations compréhensibles, puis harmoniser menus et libellés selon le rôle.
5. Valider en environnement de recette les courriels réels, liens d’activation, worker supervisé, fichiers publics/privés, gestionnaire MRC, gros volumes, responsive et scénarios d’échec.
6. Préparer un jeu de démonstration crédible et répéter le scénario client avec des comptes créés par le vrai parcours.

Vérifications restantes : Safari/Firefox, appareils réels, tests d’accessibilité complets, charge, rétention des pièces jointes et sauvegardes, réelle délivrabilité des courriels, activation de bout en bout, import de gros fichiers, publication avec image et restauration de version. Le risque de PUT multipart dans l’éditeur de contenu mérite aussi une reproduction spécifique avec une image avant livraison.

Inventaire machine : constats.json. Sondes reproductibles : output/playwright/audit-2026-10-20/AuditProbeTest.php. Lancer : php artisan test output/playwright/audit-2026-10-20/AuditProbeTest.php.