Valider les propositions d’IA avant d’exécuter des actions en PHP

Une réponse d’IA peut sembler précise et, malgré cela, être inadaptée pour intervenir sur un système. Qu’elle classe une demande comme urgente, suggère de remplir un champ ou recommande de démarrer un flux ne signifie pas qu’elle y est autorisée, qu’elle dispose d’un contexte suffisant ni qu’elle respecte les règles métier. Le risque apparaît lorsqu’une suggestion textuelle ou structurée est transformée en ordre exécutable sans barrières indépendantes.

Pour valider les sorties structurées d’IA en PHP, il convient de traiter le modèle comme un composant qui prépare des propositions, et non comme une autorité qui modifie des enregistrements, assigne des responsables, envoie des communications ou démarre des processus. L’application conserve la décision, applique ses propres règles et enregistre pourquoi une proposition a été acceptée, corrigée ou rejetée.

Une sortie plausible n’est pas une instruction valide

Les modèles peuvent renvoyer un JSON correct du point de vue syntaxique et, malgré cela, inclure une priorité inexistante, un identifiant qui ne correspond pas au client, une date impossible ou une action que l’utilisateur ne peut pas demander. Ils peuvent également compléter des données absentes de l’entrée, mal interpréter une ambiguïté ou suivre un ancien format après un changement de contrat.

La limite opérationnelle doit être explicite : l’IA peut proposer une action et expliquer les données qu’elle a utilisées ; le système décide si cette proposition devient un brouillon, requiert une révision ou peut être exécutée dans des conditions très limitées. Cette séparation protège à la fois l’intégrité des données et la responsabilité de la décision.

Un bon point de départ consiste à classer chaque action selon son impact :

• Faible impact : étiqueter un brouillon, suggérer une catégorie ou extraire des champs non critiques.
• Impact moyen : créer une tâche en attente, proposer un responsable ou préparer une réponse à réviser.
• Fort impact : modifier des statuts contractuels, attribuer un travail irréversible, modifier des montants, supprimer des données, communiquer à l’extérieur ou activer des processus sensibles.

L’autonomie admissible ne dépend pas du fait que l’IA affiche un niveau de confiance élevé. Elle dépend de la réversibilité, du coût d’une erreur, de la qualité vérifiable des données et de l’existence de contrôles extérieurs au modèle.

Définir un contrat de proposition avant d’intégrer le modèle

Le contrat de sortie définit ce que le composant d’IA peut proposer et ce qui reste hors de son périmètre. Il doit être restreint, typé et versionné. Au lieu de demander « décide quoi faire avec cette demande », spécifiez une liste fermée d’actions et les champs nécessaires pour chacune d’elles.

{
  "version": "1",
  "action": "create_task_draft",
  "category": "billing",
  "priority": "normal",
  "summary": "Revoir une divergence sur une facture",
  "sourceReferences": ["message:123"],
  "confidence": 0.82
}

La liste des actions doit utiliser des valeurs contrôlées, par exemple create_task_draft, request_more_information ou no_action. Il n’est pas recommandé d’accepter des noms de méthodes, des requêtes, des fragments de code, des destinataires libres ni des instructions du type « mets à jour la commande ». L’application traduit une action autorisée en une opération interne concrète.

Champs, états et éléments de preuve

Outre les types et les valeurs autorisées, le contrat doit indiquer quels champs sont obligatoires, quelles combinaisons sont incompatibles et quels éléments de preuve la proposition doit fournir. Une catégorie peut être valide, mais exiger au moins une référence au message ou au document source. La confiance, si elle est collectée, est une donnée auxiliaire pour ordonner les révisions ; elle ne remplace pas une validation.

Versionner le schéma permet de rejeter en toute sécurité les sorties provenant de contrats retirés. Si une modification ajoute un champ obligatoire ou retire une action, l’adaptateur doit reconnaître la version et éviter les interprétations implicites.

Appliquer quatre barrières avant tout effet

La validation doit s’effectuer dans des couches séparées. Une défaillance dans une couche n’est pas compensée par une réponse apparemment raisonnable dans une autre.

1. Format : vérifier que la réponse peut être décodée, qu’elle respecte le schéma attendu, qu’elle ne contient pas de champs critiques inattendus et que chaque valeur a le bon type. Un JSON invalide, une énumération inconnue ou un champ obligatoire absent sont rejetés.
2. Domaine : vérifier les règles propres à l’application. Par exemple, que la catégorie existe, que la priorité s’applique au type de demande, que le compte concerné est actif et que la référence source appartient au contexte traité.
3. Autorisation : vérifier ce que l’acteur qui a initié le flux peut faire et quelles autorisations l’opération exige. L’IA n’hérite pas de privilèges illimités et ne décide pas de la portée des accès. Le serveur applique l’identité, le tenant et les politiques en vigueur.
4. Conditions opérationnelles : examiner la concurrence, les états actuels, les limites, les dépendances et l’idempotence. Une proposition valide peut ne pas pouvoir être exécutée si le cas a déjà été clôturé, si un autre processus a modifié l’enregistrement ou si un seuil de charge a été dépassé.

La validation sémantique doit consulter des sources de vérité internes. Il ne suffit pas que le modèle renvoie un identifiant bien formé : le référentiel ou le service de domaine doit vérifier son existence, son appartenance et son état. Évitez que la réponse du modèle transporte des données d’autorisation que l’application peut résoudre elle-même.

Architecture PHP : proposition, décision et exécution séparées

Une architecture maintenable sépare les responsabilités. L’adaptateur d’IA prépare la requête, applique des limites de taille et obtient une sortie ; il n’écrit pas dans la base de données métier. Un DTO représente la proposition déjà analysée. Le validateur de domaine transforme cette proposition en une décision avec des erreurs explicites. Enfin, un exécuteur autorisé applique uniquement les décisions approuvées.

final class ActionProposal {
    public function __construct(
        public string $action,
        public string $category,
        public string $priority,
        public array $sourceReferences,
    ) {}
}

$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);

if (!$validation->isApproved()) {
    $auditLog->recordRejected($proposal, $validation->reasons());
    return $validation;
}

return $decisionService->route($validation->approvedProposal(), $context);

Le service de décision peut créer un brouillon, le placer dans une file de révision ou demander une approbation humaine. L’exécuteur final doit recevoir un objet de décision interne, et non la réponse brute ou le JSON de l’IA. Cela évite qu’une extension accidentelle du contrat ne devienne une nouvelle capacité opérationnelle.

Utilisez des transactions pour les modifications liées, des clés d’idempotence pour les tentatives répétées et des contrôles de concurrence lorsque plusieurs personnes ou processus peuvent agir sur le même cas. Distinguez également le déploiement de l’activation : le code peut être déployé sans exposer le flux à de vrais utilisateurs. Une activation progressive permet d’observer les rejets, les délais et les corrections avant d’élargir le périmètre.

Choisir la révision humaine, l’automatisation limitée ou le rejet

La révision humaine est appropriée en cas d’ambiguïté significative, de données sensibles, de conséquences externes, d’exceptions de politique ou de coûts de correction élevés. L’interface de révision devrait afficher la proposition, les éléments de preuve source autorisés, les règles satisfaites et les motifs d’alerte, sans présenter la recommandation comme un fait.

L’automatisation limitée peut être raisonnable pour des opérations réversibles et circonscrites : créer un brouillon non attribué, appliquer une étiquette provisoire ou acheminer une demande vers une file générale. Elle doit comporter des limites de fréquence, une possibilité d’annulation et une supervision ultérieure. Si des données manquent, s’il existe un conflit entre les règles ou si l’action est hors de la liste autorisée, le comportement sûr consiste à rejeter ou à escalader, et non à improviser.

Avant d’utiliser l’IA, évaluez une alternative déterministe. Si les entrées suivent des modèles stables, des règles, des formulaires guidés, des listes de sélection ou un classificateur conventionnel peuvent être moins coûteux, auditables et prévisibles. Lorsque l’IA est utilisée, définissez le cas d’usage, un ensemble d’évaluation représentatif, des seuils opérationnels, le coût par volume et un mode dégradé si le fournisseur échoue ou dépasse le délai attendu.

Exemple : transformer une demande en brouillon de tâche

Supposez une demande entrante qui mentionne une divergence sur une facture. L’IA peut proposer la catégorie billing, une priorité normale et le résumé d’une tâche. Le validateur vérifie que le message appartient au tenant actuel, que la catégorie est activée et qu’il n’existe pas déjà de dossier ouvert avec la même référence. Si tout est correct, le système crée un brouillon sans attribuer de responsable ni modifier le statut de la facture.

Un opérateur examine le brouillon, confirme ou corrige la catégorie et décide de l’attribution conformément à la charge et aux autorisations en vigueur. Cette distinction évite qu’une inférence plausible sur un responsable ou un montant ne devienne une modification erronée. Si le contrat exige un numéro de facture et que celui-ci n’apparaît pas dans le message, la proposition doit demander des informations supplémentaires, et non l’inventer.

Traçabilité, confidentialité et tests avant d’élargir le flux

Enregistrez un identifiant de corrélation, la version du contrat, l’empreinte ou la référence de l’entrée minimisée, la proposition normalisée, les résultats de chaque validation, la décision finale, l’acteur approbateur lorsqu’il existe et le motif du rejet. Le journal doit être utile pour enquêter sur les incidents sans dupliquer inutilement des données personnelles ou du contenu sensible. Appliquez une rétention, un accès restreint et des techniques de minimisation adaptés au risque du processus.

Testez le flux avec des cas représentatifs et adverses : entrées incomplètes, instructions contradictoires, valeurs inventées, références provenant d’un autre tenant, changements d’état concurrents, réponses dans un ancien format, latence et indisponibilité du service d’IA. Les critères d’acceptation doivent mesurer si les opérations non autorisées sont bloquées, si les brouillons sont récupérables, si les rejets sont compréhensibles et si le système maintient une alternative fonctionnelle en cas de défaillance.

Une exploitation sûre ne consiste pas à faire en sorte que le modèle réponde toujours. Elle consiste à garantir que, lorsqu’il répond mal, tarde trop ou ne répond pas, l’application PHP conserve le contrôle et ne produise pas d’effets qu’elle ne peut pas justifier.