Extraction assistée en PHP : accepter, réviser ou mettre en quarantaine

L’extraction assistée de données en PHP transforme des documents, formulaires, e-mails ou enregistrements entrants en champs structurés. Toutefois, détecter un nom, un montant ou une date n’implique pas que cette valeur puisse déclencher un paiement, créer une commande ou modifier un dossier sans intervention. Le résultat de l’extraction est une proposition : il doit être confronté aux règles métier, aux preuves disponibles et à l’impact d’une erreur.

Une conception utile ne vise pas à automatiser 100 % des cas dès le premier jour. Elle définit quelles données peuvent être acceptées en toute sécurité, lesquelles exigent une décision humaine et lesquelles doivent être arrêtées jusqu’à ce que des informations supplémentaires soient disponibles. Cette séparation protège les opérations et permet d’améliorer le système à partir de corrections réelles, plutôt que d’hypothèses sur un score de confiance.

Définir la donnée, sa provenance et le coût de l’erreur

Avant de choisir un fournisseur, une bibliothèque ou un modèle d’IA, décrivez chaque champ comme un objet métier. Il ne suffit pas d’indiquer qu’une date sera extraite ; il faut déterminer s’il s’agit de la date d’émission, d’échéance, de prestation ou de livraison. L’ambiguïté sémantique est un risque distinct d’une erreur de lecture.

• Finalité : quel processus consommera le champ et s’il peut déclencher une action irréversible.
• Provenance : document original, page, section, étiquette, coordonnées ou extrait qui étaye la valeur.
• Contraintes : type, format, caractère obligatoire, plage, devise, catalogue autorisé et relations avec d’autres champs.
• Impact : conséquence de l’acceptation d’une valeur erronée, absente ou attribuée au mauvais document.
• Source de vérification : système maître, règle contractuelle, base de fournisseurs ou révision humaine pouvant confirmer la donnée.

Un identifiant fiscal peut avoir une expression formelle correcte tout en appartenant à une entité non autorisée. Un total peut être numérique et positif, sans pour autant correspondre à la somme des lignes, taxes et remises. La validation doit donc inclure à la fois la forme du champ et sa signification opérationnelle.

Classez également la sensibilité des données. Les documents contenant des informations personnelles, financières ou contractuelles exigent de définir qui peut consulter l’original, combien de temps il est conservé et quelles informations sont envoyées à des services externes. L’utilité de l’automatisation ne supprime pas les obligations de minimisation et de contrôle d’accès.

Concevoir une sortie structurée et vérifiable

L’extraction devrait produire une structure stable, et non du texte libre qu’un autre composant devrait réinterpréter. Le contrat peut inclure la valeur normalisée, la valeur littérale, l’état de présence, les preuves et les avertissements détectés. Conserver les deux valeurs évite de masquer une transformation importante : par exemple, convertir 1.250,00 en décimal dépend de la convention identifiée.

{
  "invoice_number": {
    "raw": "F-01842",
    "normalized": "F-01842",
    "evidence": {"page": 1, "label": "Facture"},
    "warnings": []
  },
  "total": {
    "raw": "1.250,00 EUR",
    "normalized": 1250.00,
    "currency": "EUR",
    "evidence": {"page": 1, "label": "Total"},
    "warnings": ["sum_not_verified"]
  }
}

Le schéma doit rejeter les champs inattendus, les types incompatibles et l’absence de champs obligatoires. En PHP, une couche spécifique peut valider le résultat avant qu’il n’atteigne le domaine de l’application. Les règles techniques incluent les formats, les longueurs et les conversions ; les règles métier incluent les doublons, les périodes admises, les limites d’approbation et la correspondance avec des enregistrements existants.

Ne traitez pas le pourcentage de confiance comme une décision. Son calibrage varie selon le type de document, la qualité de l’image, la langue et le champ. Il peut être utilisé comme un signal supplémentaire, mais ne remplace pas une vérification telle que l’existence du fournisseur, la plausibilité de la date ou la cohérence du total.

Séparer l’acceptation, la révision et la quarantaine

Les trois destinations doivent être des états explicites du flux, avec des autorisations, des responsables et des transitions contrôlées. Ce ne sont pas des étiquettes visuelles sur une même file.

• Acceptation automatique : elle est utilisée lorsque le schéma est valide, que les règles métier sont respectées, que les preuves sont suffisantes et que le risque résiduel est dans le seuil défini. Les règles respectées doivent être persistées.
• Révision humaine : elle s’applique si le cas est compréhensible mais exige une confirmation, par exemple une divergence mineure, une faible confiance localisée ou une correspondance non concluante avec un système maître.
• Quarantaine : elle arrête les cas incomplets, potentiellement frauduleux, dupliqués, illisibles, incompatibles avec le schéma ou affectés par une règle critique. Elle ne doit pas permettre qu’une nouvelle tentative automatique transforme un blocage délibéré en acceptation.

Une matrice de décision pratique combine criticité et vérifiabilité. Un champ à faible impact peut être accepté s’il respecte le format et le catalogue. Une donnée qui détermine un paiement exige en outre un rapprochement avec la commande, un fournisseur autorisé et un calcul cohérent. Si l’original est absent, si les preuves sont contradictoires ou si une possible manipulation est détectée, la sortie raisonnable est la quarantaine, même si d’autres champs semblent corrects.

Flux de référence en PHP et persistance sécurisée

Un flux robuste sépare les responsabilités afin que l’extraction ne soit pas mélangée à la décision métier. La réception attribue un identifiant immuable, vérifie le type et la taille du fichier, et stocke l’original dans un emplacement à accès restreint. Ensuite, un processus asynchrone prépare le document, invoque l’extracteur et valide la réponse par rapport au schéma.

La décision est prise sur des données normalisées et des règles déterministes. Le service peut renvoyer un objet de décision contenant l’état, les motifs, les champs concernés et la version des règles. Ce n’est qu’après cette décision que l’enregistrement métier est persisté ou qu’une tâche de révision est créée. L’idempotence est essentielle : un même fichier ou événement répété ne doit pas générer d’enregistrements ni d’actions dupliqués.

$result = $extractor->extract($document);
$validated = $schemaValidator->validate($result);
$decision = $decisionEngine->decide($validated, $businessContext);
$repository->saveDecision($documentId, $decision);

Lorsqu’une IA est utilisée, définissez le cas d’usage de manière circonscrite : classification documentaire, localisation de champs ou interprétation de texte difficile, par exemple. Évaluez la qualité sur un ensemble représentatif avant d’activer toute automatisation, maintenez une révision humaine pour les cas définis et limitez les données envoyées. Calculez également le coût par document, la latence tolérable et le comportement face à des réponses partielles. Une démonstration convaincante ne prouve pas que le flux est exploitable à l’échelle.

Rendre efficaces la révision humaine et la quarantaine

La personne chargée de la révision ne devrait pas devoir reconstruire le document depuis zéro. L’interface doit afficher la valeur proposée avec ses preuves, l’original ou un extrait autorisé, les règles non respectées et les alternatives disponibles. Elle doit permettre de corriger, confirmer, rejeter ou demander des informations, en laissant un motif structuré.

Enregistrez la correction comme un événement distinct du résultat initial. Cela permet de savoir si l’échec provient de la lecture, de la normalisation, d’une règle ou du document source. N’utilisez pas automatiquement chaque correction comme donnée d’entraînement : examinez d’abord la qualité, les autorisations, la représentativité et l’éventuelle incorporation de données sensibles.

La quarantaine nécessite un propriétaire, une priorité et un délai de résolution. Les nouvelles tentatives doivent avoir une cause concrète, une limite et une traçabilité : réessayer après une panne transitoire n’est pas la même chose que retraiter un fichier illisible. Les cas non résolus doivent être escaladés ou clôturés avec un motif explicite, sans jamais disparaître de la file.

Traçabilité, tests et dégradation contrôlée

Pour expliquer une décision, conservez l’identifiant du document, l’empreinte ou la référence de l’original, la version du schéma et des règles, le résultat des validations, les preuves minimales par champ, l’état, l’acteur ayant effectué la révision et les horodatages. Évitez de dupliquer le document entier dans chaque journal ou de stocker du texte sensible lorsqu’un identifiant et une référence sécurisée suffisent.

Testez avec des documents représentatifs et des cas limites : pages tournées, images floues, champs absents, devises multiples, étiquettes ambiguës, doublons, formats régionaux et documents dont la structure est inattendue. Mesurez séparément les taux d’extraction, de validation, d’acceptation automatique, de révision, de quarantaine, de correction humaine et le temps de résolution. Un taux d’acceptation élevé n’est pas un signal positif si les rectifications ou incidents augmentent ensuite.

Définissez la dégradation avant le déploiement. Si l’extracteur ne répond pas, dépasse la latence ou renvoie une structure invalide, le document doit être conservé et dirigé vers une file manuelle ou un mécanisme alternatif autorisé. Ne renseignez pas les valeurs critiques avec des estimations silencieuses. Activez progressivement les changements de règles ou d’extracteur, comparez les résultats et maintenez une voie de réversion.

Liste de contrôle avant d’automatiser un champ

• Le champ possède-t-il une définition métier sans ambiguïté et un consommateur identifié ?
• Existe-t-il des règles de format, de plage, de catalogue et de cohérence avec d’autres données ?
• Peut-on afficher des preuves suffisantes pour confirmer la valeur ?
• L’impact d’un faux positif est-il connu et un seuil de risque a-t-il été défini ?
• Existe-t-il un parcours de révision, de quarantaine, de nouvelle tentative limitée et une alternative manuelle ?
• La traçabilité permet-elle d’expliquer la décision sans conserver de données inutiles ?
• Les tests incluent-ils les erreurs prévisibles et l’activation progressive prévoit-elle une réversion ?

Un champ passe de l’assistance à l’automatisation lorsqu’il démontre sa cohérence dans ces conditions, et non uniquement parce qu’un extracteur réussit habituellement. Ainsi, PHP coordonne un processus vérifiable où la vitesse de traitement ne remplace pas la responsabilité à l’égard de la donnée.