Une fonctionnalité d’IA intégrée à une application PHP peut prendre trop de temps, être indisponible ou renvoyer un résultat inutilisable par le processus. Le problème ne se résout pas en considérant chaque réponse comme valide ni en répétant indéfiniment la requête : ces deux décisions peuvent compromettre l’expérience, les données et les coûts. Un fallback pour l’intégration de l’IA en PHP définit ce que fera le système en cas de défaillance de la dépendance, ainsi que les opérations qui ne doivent pas se poursuivre sans réponse acceptable.
La solution de repli appropriée dépend de l’impact de la fonctionnalité. Une suggestion de texte peut être temporairement omise ; une décision qui affecte un paiement, un droit d’accès ou une mise à jour des données ne devrait pas être exécutée à partir d’informations incomplètes ou supposées. L’objectif est de maintenir un comportement prévisible, et non de dissimuler toutes les erreurs.
Définir ce qui constitue une défaillance
Avant de mettre en œuvre des solutions de repli, précisez les conditions dans lesquelles une réponse est inutilisable. Distinguer les cas facilite le choix d’une politique et permet de mesurer son efficacité :
- Timeout : la requête dépasse le délai d’attente de l’application.
- Indisponibilité ou erreur de transport : la connexion échoue ou le fournisseur renvoie une erreur.
- Réponse vide : l’appel aboutit, mais ne contient pas le contenu attendu.
- Format invalide : le résultat ne peut pas être analysé ou ne respecte pas le schéma requis, par exemple un JSON auquel il manque des champs.
- Résultat inacceptable : la sortie est lisible, mais ne satisfait pas aux règles métier, aux validations ou aux critères de sécurité.
Il ne faut pas assimiler une réponse techniquement correcte à une décision valide. Si l’application attend une catégorie appartenant à un ensemble fermé, elle doit vérifier que la valeur en fait partie. Si elle attend des champs obligatoires, elle doit les valider avant de les transmettre à un autre composant. Les vérifications déterministes doivent être effectuées dans le code PHP ; elles ne doivent pas être déléguées à nouveau au même modèle.
Limiter le délai d’attente et les tentatives
Définissez un timeout adapté à l’opération et au temps total que l’utilisateur ou le processus peut attendre. Tenez également compte des limites du serveur web, de la file d’attente et de tout client HTTP intermédiaire : un timeout local qui dépasse la limite de la requête n’offre aucun contrôle réel. Une tâche en arrière-plan peut tolérer un délai d’attente différent, à condition qu’une politique explicite soit définie pour les tâches en attente.
Les nouvelles tentatives doivent être limitées et ne s’appliquer qu’aux défaillances susceptibles d’être temporaires. Une interruption du réseau peut justifier une tentative supplémentaire ; une réponse qui ne respecte pas le schéma nécessite généralement une validation, un fallback ou une révision, et non une répétition aveugle. Limitez le nombre de tentatives et la durée totale. En cas d’attente progressive, fixez également une durée maximale.
Gardez à l’esprit que répéter un appel peut entraîner une consommation ou des effets en double. Évitez les nouvelles tentatives automatiques sans limite et vérifiez si l’opération est idempotente. Une génération de texte sans effets secondaires n’équivaut pas à une action qui passe une commande ou envoie une notification. Pour les opérations sensibles, séparez la génération d’une proposition de son exécution et prévoyez des contrôles spécifiques pour cette dernière.
Choisir une solution de repli en fonction de l’impact
Un fallback n’est pas une réponse générique applicable à toutes les défaillances. Il doit préserver les règles métier et indiquer clairement ce que l’application peut faire :
- Dégrader le service : si l’IA apporte une commodité, autorisez la poursuite sans cette fonctionnalité. Par exemple, affichez le formulaire classique lorsqu’aucune suggestion n’est générée.
- Différer : si le résultat peut être produit ultérieurement, enregistrez la tâche avec un statut en attente et permettez une nouvelle tentative via une file d’attente, avec des limites et un suivi.
- Demander une révision : si un jugement humain est nécessaire, affichez la proposition sous forme de brouillon ou transmettez le cas à une personne. Ne présentez pas une sortie non validée comme une décision finale.
- Refuser ou interrompre : s’il est impossible de vérifier une condition nécessaire à l’opération, bloquez l’action et expliquez comment poursuivre ou demander de l’aide.
La décision doit reposer sur le risque d’agir incorrectement, et pas seulement sur le coût d’une interruption. Un moteur de recherche avec suggestions peut continuer à utiliser la requête d’origine. En revanche, un flux qui modifie des données client ne devrait pas compléter les champs manquants par des suppositions. Si la sortie de l’IA influe sur une décision métier, préservez une voie manuelle ou une règle déterministe lorsque c’est réalisable.
Protéger l’intégrité des processus
Traitez la réponse du modèle comme une entrée externe : analysez sa structure, validez chaque valeur et limitez les opérations qu’elle peut déclencher. Ne l’insérez pas directement dans des requêtes SQL, des commandes, du HTML ou des instructions destinées à d’autres systèmes. Utilisez des requêtes paramétrées, un encodage approprié et des listes de valeurs autorisées, ainsi que les vérifications propres au domaine.
Définissez une frontière entre la suggestion et l’exécution. Par exemple, l’IA peut proposer une classification ; le code vérifie qu’elle est admissible et, selon la politique du produit, elle est appliquée automatiquement ou reste en attente. Lorsqu’une donnée obligatoire manque, la solution de repli sûre consiste généralement à la demander, à laisser le cas incomplet ou à interrompre le processus, et non à l’inventer. Le comportement en cas de défaillance doit également respecter les droits d’accès, les validations et les règles d’autorisation habituelles.
Enregistrer les défaillances sans conserver d’informations inutiles
Les journaux doivent faciliter le diagnostic sans devenir une copie des conversations. Enregistrez des événements techniques tels que l’opération, le type de défaillance, la durée, le nombre de tentatives, le résultat de la validation et un identifiant de corrélation. Ajoutez suffisamment d’informations pour distinguer, par exemple, un timeout d’un JSON mal formé, mais évitez d’enregistrer par défaut les prompts complets, les réponses, les identifiants ou les données personnelles.
Si le contenu doit être conservé pour une révision ou un audit, définissez au préalable l’objectif, les accès, la durée de conservation et les mesures de protection. Dans les métriques, suivez la fréquence des timeouts, des réponses invalides, des fallbacks et des tâches en attente, ainsi que la latence et les nouvelles tentatives. Une hausse peut signaler un problème opérationnel ou une évolution du comportement de la sortie. Les métriques permettent de détecter des tendances ; elles ne remplacent pas l’examen du cas et ne prouvent pas à elles seules qu’une réponse est correcte.
Tester les scénarios et convenir de critères
Testez l’intégration avec des réponses contrôlées et vérifiez à la fois le résultat visible et les effets sur le système. Incluez une latence élevée, une interruption de connexion, une réponse vide, un format invalide, une donnée non conforme aux règles et la reprise après une défaillance. Vérifiez qu’aucune action n’est exécutée en double, que les nouvelles tentatives respectent leurs limites et que les journaux ne révèlent aucun contenu sensible. Testez également ce qui se passe lorsqu’une tâche reste en attente ou nécessite une intervention.
Avant de mettre une fonctionnalité en production, convenez des décisions suivantes avec les équipes produit et technique :
- La fonctionnalité est-elle indispensable pour terminer l’opération, ou améliore-t-elle seulement l’expérience ?
- Quel délai d’attente total est acceptable pour chaque canal ?
- Quelles défaillances autorisent une nouvelle tentative et combien sont-elles permises ?
- Quelle est la solution de repli sûre : poursuivre sans IA, différer, demander une révision humaine ou interrompre ?
- Quelles validations doivent réussir avant l’utilisation de la réponse ?
- Quelles données sont enregistrées, qui peut y accéder et combien de temps sont-elles conservées ?
- Comment l’équipe est-elle alertée et qui traite les cas en attente ?
Une politique utile permet de dégrader les fonctionnalités accessoires et d’interrompre les opérations qui dépendent de données non vérifiées. S’il est impossible d’expliquer précisément ce qui se passe lorsqu’une réponse arrive tardivement, est invalide ou est absente, l’intégration ne dispose pas encore d’un fallback opérationnel. Documentez ces règles à côté du flux et testez-les à nouveau lorsque le produit, les validations ou la manière d’utiliser le service évoluent.
