Une fonction d’intelligence artificielle peut être utile tout en étant trop lente ou trop coûteuse pour une opération donnée. Le risque apparaît lorsque chaque appel est traité comme s’il répondait aux mêmes besoins : résumer un texte en arrière-plan n’a pas le même impact que répondre à une demande pendant le paiement. Pour maîtriser le coût et la latence de l’IA en PHP, il est utile de définir un budget opérationnel pour chaque cas d’usage et de décider à l’avance de ce qui se passera lorsqu’il sera atteint.
Ce budget n’est ni une promesse de qualité ni une garantie que le fournisseur répondra dans un délai donné. Il s’agit d’un ensemble de limites et de décisions produit qui permet de contenir l’impact, d’informer l’utilisateur et de garder le comportement de l’application sous contrôle.
Un budget différent pour chaque opération
Un budget opérationnel regroupe les ressources qu’une fonction peut consommer et la durée pendant laquelle il est pertinent d’attendre. Il peut inclure une durée maximale, une limite de dépense estimée, un nombre de tentatives, une quantité de texte traité ou une combinaison de ces contrôles. Il doit être associé à une opération identifiable dans le produit, et non correspondre à une configuration abstraite partagée par tous les appels.
Par exemple, une suggestion facultative dans un tableau de bord peut être omise si le système met trop de temps à la fournir. En revanche, si une fonction fait partie d’un processus essentiel, il peut être nécessaire de proposer une solution de repli permettant de terminer le parcours sans IA. Un travail de classification par lots peut accepter une file d’attente et un état en attente, tandis qu’une réponse interactive nécessite un délai d’attente plus strict.
Pour choisir les limites, précisez d’abord le résultat dont l’utilisateur a besoin, s’il est indispensable à ce moment-là et ce qui se passe s’il n’est pas disponible. Distinguez également le budget de l’évaluation de la qualité : une réponse rapide et peu coûteuse peut être incorrecte, et une réponse correcte peut arriver trop tard pour être utile. Ces deux aspects nécessitent des mesures et des critères qui leur sont propres.
Mesurer avant de fixer les seuils
Sans référence de départ, les limites ne sont que des suppositions. Enregistrez des métriques par type d’opération et observez leurs variations en fonction du volume, de la taille des entrées et des conditions d’utilisation. Il convient au minimum de mesurer la durée totale, le délai avant le premier résultat utile le cas échéant, la fréquence d’utilisation et le coût estimé. Pour les opérations asynchrones, enregistrez également le temps passé en file d’attente et le temps de traitement.
Associez chaque mesure à un identifiant d’opération, à un résultat et à des données contextuelles non sensibles, comme la taille approximative de la requête ou le mode d’exécution. Évitez d’enregistrer le texte de l’utilisateur, des secrets, des données personnelles ou des réponses complètes s’ils ne sont pas nécessaires au diagnostic. Lorsqu’il faut examiner un cas, appliquez des contrôles d’accès, des règles de conservation et des mesures de minimisation appropriés.
Le coût estimé doit s’appuyer sur les informations disponibles pour le service utilisé et tenir compte de ses limites. Ne le confondez pas avec un montant facturé confirmé : les prix, les unités comptabilisées et les éléments facturables peuvent varier. Si l’application ne peut pas calculer un coût fiable avant l’appel, utilisez d’autres contrôles, comme des limites de fréquence, une taille maximale, des quotas par utilisateur ou un suivi des dépenses agrégées.
Traduire le budget en limites vérifiables
Définissez le périmètre d’application de chaque contrôle. Une limite par requête empêche une exécution individuelle de durer trop longtemps ou de consommer trop de ressources. Un quota par utilisateur ou par compte limite les usages répétés. Un plafond par processus protège une tâche regroupant plusieurs opérations. Pour maîtriser les dépenses globales, surveillez également la consommation agrégée ; une limite individuelle n’empêche pas de nombreuses requêtes simultanées de dépasser le budget du système.
Décidez aussi du comportement des nouvelles tentatives. Répéter automatiquement une requête peut doubler le coût ou accroître la latence, en particulier lorsqu’on ignore si le service a traité la demande. Définissez le nombre de tentatives autorisées, les erreurs concernées et le délai d’attente entre les tentatives. Utilisez des clés d’idempotence lorsqu’elles sont compatibles et pertinentes afin d’éviter les effets en double dans les opérations qui modifient des données.
Lorsqu’un seuil est atteint, les options comprennent l’arrêt de la requête, la réduction de sa portée, son report dans une file d’attente ou son transfert à une personne chargée de la vérification. Le choix dépend du cas d’usage. Une réponse partielle n’est acceptable que si l’interface l’identifie clairement et si le résultat reste sûr et utile. Si la tâche est sensible ou ne tolère pas les résultats incomplets, il peut être préférable de ne pas afficher de réponse générée.
Appliquer les contrôles dans une couche d’intégration PHP
Centralisez les appels externes dans une couche d’intégration qui reçoit l’opération et son budget, applique les contrôles correspondants et renvoie un résultat explicite. Ainsi, la logique métier ne dépend pas directement d’un fournisseur et n’interprète pas différemment les délais d’attente et les erreurs à chaque endroit de l’application.
L’extrait suivant nécessite PHP 8.0 ou une version ultérieure, car il utilise la promotion de propriétés dans le constructeur et les arguments nommés. Il s’agit d’un exemple partiel : il valide la taille de l’entrée et transmet un délai d’attente au client, mais n’implémente ni quotas, ni limites de dépenses, ni file d’attente. Ces contrôles doivent être ajoutés séparément selon les besoins de l’application.
final class AiOutcome
{
public function __construct(
public string $status,
public ?string $content = null,
public ?string $reason = null,
) {}
}
function runAiOperation(
AiClient $client,
string $input,
int $timeoutSeconds
): AiOutcome {
if (strlen($input) > 12000) {
return new AiOutcome('rejected', reason: 'input_limit');
}
try {
$response = $client->generate($input, $timeoutSeconds);
return new AiOutcome('completed', $response->text);
} catch (TimeoutException $e) {
return new AiOutcome('timed_out', reason: 'timeout');
} catch (ProviderException $e) {
return new AiOutcome('unavailable', reason: 'provider_error');
}
}Le client et les exceptions dépendent de l’intégration choisie. En production, configurez également le délai maximal dans le client HTTP et validez la taille avant d’envoyer les données. L’état timed_out indique que le délai d’attente de la requête a expiré ; il ne signifie pas que celle-ci a été mise en file d’attente ni qu’elle va se poursuivre. Ne renvoyez l’état deferred que si l’application a enregistré la tâche dans une file d’attente et dispose d’un processus capable de la reprendre et d’en communiquer le résultat.
Pour compléter la couche de contrôle, appliquez des limites de fréquence ou des quotas à l’aide d’un compteur coordonné entre les processus et surveillez les dépenses agrégées. Si vous devez imposer un plafond de coût avant chaque appel, calculez la consommation estimée de la requête et comparez-la au budget disponible ; si cette estimation n’est pas suffisamment fiable, utilisez d’autres limites et des alertes de consommation. Les quotas partagés ne devraient pas dépendre uniquement de la mémoire d’une requête PHP.
Renvoyez des états distincts, comme terminé, rejeté en raison d’une limite, délai d’attente dépassé ou indisponible. La couche métier peut ainsi décider de ce qu’il faut afficher sans confondre une réponse lente avec une réponse de mauvaise qualité, ni une limite opérationnelle avec une défaillance du fournisseur.
Concevoir un mode dégradé clair et utile
Le mode dégradé ne consiste pas à cacher une erreur ni à présenter un résultat de remplacement comme s’il était équivalent. Il s’agit de préserver une expérience compréhensible lorsque la fonction ne peut pas terminer son travail. Pour une action facultative, il peut suffire d’indiquer que la suggestion n’est pas disponible et de permettre à l’utilisateur de continuer. Pour une tâche longue, affichez qu’elle est en attente et proposez un état consultable, à condition que l’application puisse le maintenir de manière fiable.
Si la portée peut être réduite, expliquez ce qui a été omis. Si la tâche est transférée pour vérification, ne laissez pas entendre que le résultat a déjà été validé. Et si une solution de repli déterministe est utilisée, comme une règle métier existante, précisez sa fonction lorsque la différence influe sur la décision de l’utilisateur. Évitez les messages qui promettent une livraison ultérieure si aucune file d’attente ni aucun processus ne sont en mesure de tenir cette promesse.
La solution de repli en cas de défaillance est distincte du contrôle du budget : elle s’active dans des situations telles qu’une indisponibilité, des erreurs réseau ou des réponses invalides. Le budget peut être épuisé alors même que le service fonctionne correctement. Ces deux mécanismes doivent être définis et testés séparément, avec des états et des messages adaptés à chaque cause.
Tester, déclencher des alertes et ajuster sur la base de données
Testez les seuils avec des charges représentatives et des scénarios défavorables : grandes entrées, requêtes répétées, réponses lentes, concurrence, erreurs du fournisseur et limites de quota. Vérifiez ce que voit l’utilisateur et ce qui est enregistré. Incluez des cas d’annulation et vérifiez qu’une requête arrêtée ne continue pas inutilement à consommer des ressources en arrière-plan.
Configurez des alertes pour les anomalies opérationnelles : augmentation de la latence, hausse des requêtes rejetées, progression des dépenses estimées ou accumulation des tâches en attente. Une alerte doit signaler une situation qui nécessite une investigation, et non se substituer à l’analyse. Segmentez les données par opération afin qu’un flux problématique ne soit pas masqué par une moyenne générale.
Réexaminez les limites lorsque le volume, l’expérience produit, la taille des entrées ou l’intégration technique évoluent. Ne les assouplissez pas uniquement pour faire disparaître une alerte : déterminez d’abord si le problème vient d’une attente mal définie, d’une charge inattendue, d’une défaillance réseau ou d’une opération à repenser.
Liste de contrôle pour la production
- Objectif : l’opération correspond à un cas d’usage et à un utilisateur identifiés, et prévoit une solution de repli si l’IA ne répond pas.
- Mesure : la durée, la fréquence, le résultat et le coût estimé sont enregistrés sans collecter inutilement de données sensibles.
- Limites : des plafonds adaptés sont définis par requête et, le cas échéant, par utilisateur, processus et système.
- Comportement : les nouvelles tentatives, l’annulation, la mise en file d’attente et la réponse à chaque seuil sont définies.
- Expérience : les états et les messages distinguent l’attente, le rejet dû à une limite et la défaillance du service.
- Exploitation : des tests et des alertes sont en place, et une personne ou une équipe est chargée de réexaminer les limites.
Maîtriser le coût et la latence de l’IA en PHP ne consiste pas à choisir un délai d’attente unique pour toute l’application. Il s’agit d’associer chaque limite à un besoin concret, d’en mesurer l’impact et de décider à l’avance de la solution de repli qui permettra au produit de rester compréhensible et sûr lorsque la fonction ne peut pas être menée à bien.
