Créer une personne depuis une preuve avec aperçu et OCR contrôlé des documents d’identité #109
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Contexte
Lors de la création d’une personne dans une enquête, l’utilisateur doit
actuellement renseigner les données manuellement et ne peut pas choisir
clairement la nature de la personne ni associer facilement une preuve.
Le parcours devient particulièrement long lorsque les noms de fichiers
ne permettent pas de savoir ce qu’ils contiennent.
Le cas des documents d’identité nécessite également un traitement
forensique strict :
l’authenticité du document.
Objectif
Créer un assistant fluide permettant, depuis la fenêtre de création d’une
personne :
Terminologie
Ne pas confondre :
Une personne peut par exemple avoir :
L’application ne doit jamais transformer automatiquement cette personne
en auteur identifié.
Fenêtre de création d’une personne
Ajouter un champ contrôlé :
Valeurs initiales proposées :
Ces valeurs doivent provenir du vocabulaire contrôlé du projet.
Le champ existant « Identification » reste distinct et conserve des états
tels que :
Association d’une preuve
Depuis la fenêtre de création d’une personne, proposer deux actions :
L’utilisateur ne doit pas être obligé de fermer la fenêtre, importer la
preuve ailleurs, puis recommencer la création de la personne.
Preuve existante
La sélection doit afficher au minimum :
Prévoir une recherche et un filtrage par type.
Nouvelle preuve
L’import déclenché depuis la fenêtre doit utiliser le mécanisme forensique
central du projet :
À la fin de l’import, la nouvelle preuve doit être automatiquement
sélectionnée dans la fenêtre de création de la personne.
Aperçu des preuves
La fenêtre de sélection et d’import doit fournir un aperçu suffisamment
grand pour identifier le contenu sans occuper toute la fenêtre.
Prévoir une zone responsive avec :
Prise en charge minimale :
L’aperçu est une représentation dérivée.
Il ne doit jamais modifier le fichier original.
Toute conversion, génération de miniature, rotation, amélioration,
redimensionnement ou rendu PDF doit être réalisée dans une zone de
travail temporaire contrôlée.
Qualification du type de preuve
Permettre de sélectionner ou confirmer un type contrôlé, par exemple :
La détection automatique peut proposer un type, mais l’utilisateur doit
toujours pouvoir le corriger avant validation.
Le type choisi détermine les analyses proposées.
Document d’identité
Lorsqu’une preuve est qualifiée comme document d’identité, proposer :
Le traitement doit être asynchrone et annulable.
Il doit :
Champs OCR proposés
Selon les informations réellement visibles, proposer notamment :
Ne jamais inventer une valeur absente ou illisible.
Chaque proposition doit posséder un état :
Validation et correction humaine
Avant la création de la personne, afficher côte à côte autant que possible :
Pour chaque champ, conserver séparément :
Une correction manuelle ne doit jamais écraser le résultat OCR brut.
L’utilisateur doit pouvoir :
Authenticité et identité usurpée
Ajouter un statut contrôlé pour le document :
Les statuts affirmatifs doivent nécessiter une validation explicite et
une justification.
L’OCR ne doit jamais conclure :
Dans le cas courant, le document doit pouvoir être enregistré comme :
avec une hypothèse séparée :
Création de la personne
Après validation, créer la personne avec uniquement les champs confirmés.
La personne doit être liée à la preuve par une relation factuelle, par
exemple :
Ne pas créer automatiquement une relation :
Les résultats OCR rejetés ne doivent pas devenir des attributs de la
personne.
Intégrité et provenance
Le fichier original doit rester immuable.
Avant chaque analyse :
Tous les fichiers dérivés doivent être identifiables comme tels :
Chaque dérivé doit conserver :
Interface
Le parcours doit rester possible depuis une seule fenêtre ou un assistant
cohérent :
Utiliser des boutons compacts avec icônes et infobulles.
Ne pas ajouter de gros boutons occupant inutilement l’interface.
La fermeture ou l’annulation ne doit créer ni personne partielle, ni
attribut partiel, ni relation partielle.
Transactions
La création finale doit être transactionnelle pour :
En cas d’échec :
Tests obligatoires
Ajouter des fixtures exclusivement synthétiques.
Couvrir au minimum :
Séparer autant que possible :
Critères d’acceptation
Le ticket est terminé seulement si :
Sécurité de développement
Codex et tout agent de développement doivent travailler uniquement avec :
Ils ne doivent jamais accéder à :
Le ticket #109 est terminé et peut être clôturé.
L’assistant de création de personne couvre désormais sept étapes distinctes :
L’OCR reste facultatif et entièrement contrôlé par l’utilisateur. Le texte brut
est préservé, les valeurs normalisées, corrigées et confirmées restent
distinctes, les révisions multi-run sont conservées et aucune projection n’est
effectuée automatiquement.
La projection OCR V19 est explicite, conservatrice, transactionnelle et
traçable. Les valeurs existantes sont conservées par défaut et tout remplacement
nécessite une décision humaine.
Les relations factuelles sont créées uniquement après un choix explicite. Leur
consultation est disponible depuis les fiches Personne et Preuve.
L’authenticité documentaire conserve un historique humain distinct. La V20
ajoute séparément l’évaluation humaine de l’usage d’identité avec les états
indéterminé, présumé et confirmé, une justification contrôlée, un OcrRun
facultatif et cohérent, ainsi qu’un historique append-only.
Le schéma courant V20 est autonome. Les migrations V18→V19→V20, leurs
rollbacks, la création directe et la réouverture SQLite sont validés.
Aucun rôle, auteur, relation, identité, authenticité, usage abusif d’identité
ou champ Personne n’est déduit automatiquement.
Validations finales réussies :
Proposition : clôturer le ticket #109.