Journal

Consommer une API de modèle dans un service Symfony

Journal du vendredi 9 octobre 2026, généré le 9 octobre à 11:22

Consommer une API de modèle dans un service Symfony

Intégrer directement un grand modèle de langage dans une application PHP repose sur la manipulation de clients HTTP standard. Plutôt que d'utiliser des SDK tiers instables, l'approche durable consiste à encapsuler les appels distants dans un service dédié, injecté via le conteneur de services de Symfony. Ce service gère la sérialisation des charges utiles et la gestion des erreurs réseau.

// src/Service/TextEnhancer.php
namespace App\Service;

use Symfony\Contracts\HttpClient\HttpClientInterface;

class TextEnhancer
{
    public function __construct(
        private HttpClientInterface $aiClient,
        private string $apiKey
    ) {}

    public function process(string $prompt): string
    {
        $response = $aiClient->request('POST', 'https://api.provider.com/v1/completions', [
            'headers' => ['Authorization' => 'Bearer ' . $this->apiKey],
            'json' => ['prompt' => $prompt, 'temperature' => 0.2],
        ]);
        return $response->toArray()['result'] ?? '';
    }
}

Critères de décision pour l'architecture

Le choix d'intégrer une API distante dépend de plusieurs variables techniques et opérationnelles qu'il faut arbitrer avant la mise en production :

  • La latence : Un appel synchrone bloque le thread PHP. Si le temps de réponse dépasse la seconde, l'architecture doit basculer sur un système de files d'attente asynchrones avec Messenger.
  • La fiabilité de la sortie : Sans contrainte stricte sur le format retourné, le code aval risque des erreurs de parsing. Il est indispensable de valider la réponse reçue avant de la persister.
  • La confidentialité des données : L'envoi de données sensibles ou personnelles à un fournisseur tiers impose de vérifier les clauses de non-réutilisation et de privilégier un traitement local si le cadre réglementaire l'exige.
  • Le coût unitaire : Le volume des requêtes doit être corrélé à la complexité réelle du besoin, une logique métier déterministe restant toujours préférable à un appel d'API.