Nehos Groupe

L'essentiel sur l'intégration IA dans Symfony

Symfony 7.x (stable en 2026) reste le framework PHP de référence pour les applications métier B2B en France. On estime que plus de 45 000 applications Symfony sont en production dans les entreprises françaises (source : Symfony blog, enquête communauté 2025). Ces applications représentent des années de développement — ERP internes, CRM custom, back-offices métier, plateformes SaaS B2B — avec une logique métier validée et des données accumulées. Réécrire ces applications en Python ou en Node.js pour profiter de l'IA serait un non-sens économique. La bonne approche : intégrer des briques IA dans le Symfony existant, sans réécriture.

Les quatre briques IA intégrables dans Symfony. (1) LLM API services : des services Symfony qui encapsulent les appels aux APIs des LLMs (OpenAI, Anthropic, Mistral, Ollama) avec retry, rate limiting, caching, et logging — intégrés proprement dans l'architecture Symfony via l'injection de dépendances. (2) RAG back-office : un assistant IA dans le back-office Symfony qui répond aux questions des utilisateurs internes en s'appuyant sur les données de l'application (base de données, documents, historiques) — le RAG (Retrieval-Augmented Generation) connecte le LLM aux données métier. (3) Agents IA Symfony Messenger : des tâches IA asynchrones (classification de documents, extraction d'informations, génération de rapports, enrichissement de fiches) exécutées via le système de messaging de Symfony — Messenger dispatche les messages vers des workers IA qui traitent les tâches en background. (4) Semantic search : remplacement des requêtes SQL LIKE et FULLTEXT par une recherche sémantique vectorielle — les utilisateurs trouvent les résultats même quand les mots exacts ne correspondent pas.

Pourquoi Symfony est un excellent hôte pour l'IA. L'architecture Symfony (services, injection de dépendances, événements, Messenger, Serializer, HttpClient) est parfaitement adaptée à l'intégration d'APIs IA. Le HttpClient Symfony avec retry et timeout gère les appels aux APIs LLM de manière robuste. Symfony Messenger gère les tâches IA asynchrones avec retry, dead letter queue, et monitoring via Symfony Profiler. Le Serializer Symfony sérialise et désérialise les réponses LLM structurées. Le système d'événements permet de déclencher des traitements IA sur des événements métier (création d'entité, mise à jour, import). L'écosystème PHP 8.3+ avec les enums, les readonly properties, les fibers (asynchrone), et le match expression rend le code IA en PHP 8 aussi lisible que du Python.

Tarification : à partir de 13 k€ HT pour une brique IA unique (LLM API service ou semantic search), jusqu'212 k€ HT pour une intégration IA complète (RAG back-office + agents Messenger + semantic search + LLM services). ROI typique : gain de 2 à 5 heures/semaine par utilisateur back-office avec le RAG, réduction de 60-80 % du temps de traitement sur les tâches automatisées par agents IA.

Intégration IA dans Symfony — LLM API, RAG Back-Office, Agents IA Messenger

Symfony est le framework PHP le plus utilisé en France par les ETI et les éditeurs SaaS B2B. Vos applications Symfony en production contiennent des années de logique métier et de données — les réécrire pour intégrer l'IA n'est ni nécessaire ni souhaitable. Nehos intègre des briques IA directement dans vos applications Symfony existantes : appels LLM API via des services Symfony dédiés, RAG dans le back-office pour l'assistance à la décision, agents IA asynchrones via Symfony Messenger pour les tâches automatisées, et semantic search vectorielle pour remplacer les recherches SQL classiques à partir de 4,8 k€ HT.

Adapté à toute taille de structure

Artisan
Startup
PME / TPE
ETI
Grand Groupe

#LLM API Services Symfony — Appeler OpenAI, Anthropic, Mistral proprement

Le premier besoin quand on intègre l'IA dans une application Symfony est d'appeler des APIs de LLMs de manière fiable et maintenable. En PHP/Symfony, il n'y a pas d'équivalent direct de LangChain Python — mais l'écosystème Symfony fournit tout ce qu'il faut pour construire une intégration robuste.

#Architecture des services LLM dans Symfony

On crée un LlmClientService qui encapsule les appels HTTP vers les APIs LLM via le HttpClient Symfony. Ce service gère : le choix du provider (OpenAI, Anthropic, Mistral, Ollama) via configuration YAML (injection de dépendances), le retry automatique avec backoff exponentiel (les APIs LLM ont des rate limits et des indisponibilités temporaires), le timeout adapté (les LLMs peuvent mettre 2-10 secondes à répondre, le timeout HTTP par défaut de 30 secondes est ajusté), le caching des réponses (pour les requêtes identiques, on cache la réponse LLM dans Redis via le Cache Symfony), le logging structuré (chaque appel LLM est loggé avec le prompt, le modèle, la latence, le coût en tokens, et la réponse — pour le monitoring et le debugging).

Le service expose des méthodes typées : complete(string $prompt, array $options): LlmResponse, embed(string $text): array, chat(array $messages, array $options): LlmResponse. Les réponses sont désérialisées via le Serializer Symfony en objets PHP typés (LlmResponse, EmbeddingResult), pas en tableaux associatifs bruts.

#LLM Symfony Bundle — symfony-llm

Nehos a développé un bundle Symfony interne (nehos/symfony-llm-bundle) qui packagise cette intégration : configuration YAML des providers, services auto-wirés, commandes console pour tester les prompts (bin/console llm:chat "Bonjour"), intégration Symfony Profiler (un panel dédié qui affiche les appels LLM de la requête avec les prompts, réponses, latences, et coûts). Ce bundle est déployé sur les projets clients et maintenu par l'équipe Nehos.

#Streaming des réponses LLM

Pour les interfaces utilisateur qui affichent les réponses LLM en temps réel (chatbot dans le back-office, assistant de rédaction), on utilise le Server-Sent Events (SSE) de Symfony combiné avec le streaming des APIs LLM. Le contrôleur Symfony retourne un StreamedResponse qui proxie le stream du LLM — l'utilisateur voit la réponse s'afficher mot par mot, comme dans ChatGPT. L'implémentation utilise le HttpClient Symfony en mode chunk streaming avec les fibers PHP 8.1+ pour un traitement asynchrone léger.

#RAG dans le back-office Symfony — L'assistant IA qui connaît vos données

Le RAG (Retrieval-Augmented Generation) est la brique IA la plus impactante dans un back-office Symfony. L'idée : donner au LLM l'accès aux données de l'application (base de données, documents, historiques) pour qu'il puisse répondre à des questions métier spécifiques, pas seulement à des questions générales.

#Architecture RAG sur Symfony

Le pipeline RAG Symfony comprend trois étapes. Étape 1 — Indexation : les données métier de l'application Symfony (entités Doctrine, documents PDF/Word stockés dans le système de fichiers, emails archivés) sont encodées en embeddings et stockées dans un vectorstore (Qdrant, Weaviate, ou pgvector si on veut rester sur PostgreSQL). L'indexation est déclenchée par des événements Doctrine (PostPersist, PostUpdate, PostRemove) et par un cron job pour la réindexation complète périodique. Étape 2 — Retrieval : quand l'utilisateur pose une question dans le back-office, la question est encodée en embedding et les documents les plus similaires sont récupérés du vectorstore (top-K retrieval, K configurable). Étape 3 — Generation : les documents récupérés sont injectés dans le prompt du LLM comme contexte, et le LLM génère une réponse en langage naturel basée uniquement sur ces documents (pas d'hallucination ses connaissances générales).

#Cas d'usage RAG back-office concrets

Assistant support client : les agents support dans le back-office Symfony posent des questions en langage naturel ("Quel est le statut de la commande 45678 ?", "Quelles sont les conditions de retour pour le client Dupont ?", "Résume l'historique des interactions avec le compte XYZ") et l'assistant RAG répond en s'appuyant sur les données de la base (commandes, clients, tickets, contrats). Gain mesuré : 2 à 4 heures/semaine/agent support.

Assistant RH : le service RH interroge la base documentaire (contrats, avenants, fiches de poste, accords d'entreprise) en langage naturel. "Quel est le préavis pour un cadre ayant 5 ans d'ancienneté ?" — l'assistant trouve le passage pertinent dans l'accord d'entreprise et répond avec la source citée.

Assistant commercial : les commerciaux interrogent le CRM interne Symfony pour préparer leurs rendez-vous. "Résume les échanges avec le prospect ABC et identifie les pain points mentionnés" — l'assistant compile l'historique des emails, des notes CRM, et des propositions commerciales.

#pgvector — Vectorstore intégré à PostgreSQL

Pour les applications Symfony qui utilisent déjà PostgreSQL (la majorité), pgvector est une option intéressante qui évite d'ajouter un service supplémentaire (Qdrant, Pinecone). pgvector est une extension PostgreSQL qui ajoute un type de colonne vector, des index HNSW et IVFFlat pour la recherche vectorielle, et des opérateurs de similarité (cosine, L2, inner product). On stocke les embeddings directement dans les tables Doctrine existantes (une colonne embedding vector(1536) ajoutée aux entités indexées) et on requête via des DQL custom ou des requêtes SQL natives. Performances : pgvector gère efficacement des tables de 1 à 5 millions de vecteurs — suffisant pour la majorité des applications métier Symfony.

#Agents IA Symfony Messenger — Automatisation intelligente en background

Symfony Messenger est le système de messaging/queuing natif de Symfony. Il permet d'exécuter des tâches en arrière-plan de manière fiable, avec retry automatique, dead letter queue, et monitoring. C'est le socle idéal pour des agents IA qui traitent des tâches asynchrones.

#Architecture agent IA avec Messenger

Un agent IA Symfony est un MessageHandler qui reçoit un message (une tâche à traiter) et utilise un LLM pour la traiter. Exemple : un ClassifyDocumentMessage contient l'ID d'un document uploadé → le ClassifyDocumentHandler récupère le document, l'envoie au LLM pour classification (facture, contrat, devis, courrier), et met à jour l'entité Doctrine avec la classification. Le message est dispatché via MessageBusInterface, transporté via RabbitMQ ou Redis (configurable), et exécuté par un worker Symfony (bin/console messenger:consume).

#Cas d'usage agents IA Messenger

Classification automatique de documents : les documents uploadés dans l'application (factures, contrats, courriers) sont automatiquement classifiés par type, extraits (montant, date, fournisseur, numéro de contrat) et indexés. Le traitement prend 3 à 8 secondes par document via un LLM, exécuté en background sans bloquer l'interface utilisateur.

Enrichissement automatique de fiches : quand une fiche client, produit, ou fournisseur est créée avec des informations minimales, un agent IA l'enrichit automatiquement : recherche d'informations complémentaires (SIRET, site web, secteur d'activité), résumé du profil, et suggestions de tags. Dispatché via Messenger à la création de l'entité (événement Doctrine PostPersist).

Génération de rapports : un agent IA génère des rapports périodiques en langage naturel à partir de s données de l'application (résumé hebdomadaire des ventes, analyse des tendances, alertes sur les anomalies). Le message est dispatché par un cron job Symfony (ScheduledMessage ou bundle cron), le handler génère le rapport via le LLM, et l'envoie par email via le Mailer Symfony.

Traitement de la boîte de réception : un agent IA analyse les emails entrants (via un transport Messenger connecté à la boîte email), classifie le sujet, extrait les informations clés (nom du client, référence commande, urgence), et route vers le bon service ou crée automatiquement un ticket dans le back-office.

#Semantic search Symfony — Remplacer LIKE par des embeddings

La recherche dans les applications Symfony B2B est souvent implémentée via des requêtes SQL LIKE '%terme%' ou via le FULLTEXT search de MySQL/PostgreSQL. Ces approches sont limitées : elles ne trouvent que des correspondances textuelles exactes, ne gèrent pas les synonymes, et retournent des résultats non pertinents quand les termes de recherche sont vagues ou en langage naturel.

#Implémentation semantic search dans Symfony

La semantic search dans Symfony utilise pgvector (extension PostgreSQL) ou un vectorstore externe (Qdrant) pour stocker les embeddings des entités de l'application. Le pipeline : les entités Doctrine ciblées (produits, clients, documents, tickets) sont encodées en embeddings lors de leur création/modification (via un EventSubscriber Doctrine ou un MessageHandler Messenger). La recherche encode la requête utilisateur en embedding et effectue une recherche de similarité dans le vectorstore. Les résultats sont ordonnés par similarité sémantique et retournés à l'interface.

Intégration dans le front Symfony : le champ de recherche existant est modifié pour envoyer la requête au service de semantic search (au lieu d'un contrôleur qui fait un LIKE en SQL). Le résultat est identique côté front — une liste d'entités ordonnées — mais la pertinence est radicalement supérieure. L'implémentation est transparente pour l'utilisateur final.

Exemple concret : dans un CRM Symfony, un commercial tape "client industriel Toulouse qui a eu un problème de livraison récemment". La recherche LIKE ne trouve rien (trop de mots, trop vague). La semantic search trouve les clients du secteur industriel basés à Toulouse ayant des tickets ouverts dans la catégorie "livraison" sur les 3 derniers mois. Le gain de temps est immédiat.

#MCP + Symfony — Exposer l'application comme outil IA

Le Model Context Protocol (MCP) permet d'exposer les fonctionnalités d'une application Symfony comme des outils accessibles aux agents IA. Nehos développe des serveurs MCP en PHP/Symfony qui exposent les entités, les actions CRUD, et les requêtes métier de l'application.

Concrètement : un serveur MCP Symfony expose des outils comme search_clients(query: string), get_order(id: int), create_ticket(subject: string, body: string, priority: string). Un agent IA (Claude, GPT-4) peut alors interroger et agir sur l'application Symfony via le protocole MCP, de manière structurée et sécurisée (authentification, autorisations, audit trail). C'est le socle pour construire des agents IA qui ne se contentent pas de répondre à des questions mais qui exécutent des actions métier dans l'application. Voir notre page MCP pour les détails techniques du protocole.

#Providers IA et confidentialité — Le choix PHP-friendly

OpenAI (GPT-4o, GPT-4o-mini) : via l'API REST avec le HttpClient Symfony. Meilleur rapport qualité/prix pour les cas d'usage courants (RAG, classification, génération). Le SDK PHP officiel OpenAI (openai-php/client) est une alternative au HttpClient brut.

Anthropic (Claude Sonnet 4, Claude Haiku) : contexte de 200K tokens idéal pour le RAG avec documents longs. SDK PHP via anthropic-php/client ou appels REST directs.

Mistral (Mistral Large, Codestral, Mistral Embed) : hébergé en France, conforme RGPD sans discussion. Idéal pour les applications métier sensibles (données clients, données financières). API REST compatible OpenAI — le même HttpClient Symfony change juste l'URL de base.

Ollama on-premise (Llama 3.1, Mistral 7B, Gemma 2) : le LLM tourne sur l'infrastructure du client. Aucune donnée ne quitte le réseau interne. Performances suffisantes pour la semantic search et la classification, limitées pour la génération de texte long. API compatible OpenAI — même intégration Symfony, URL pointant vers le serveur Ollama interne.

#Tarification —à partir de 48 k€ HT

Brique IA unique —à partir de 48 k€ HT, 4 à 8 semaines. Un module parmi : LLM API services, semantic search, ou agent IA Messenger (classification, enrichissement). Inclut l'intégration dans l'architecture Symfony existante, les tests, et 2 semaines de monitoring post-déploiement.

RAG back-office — 415 k€ HT, 8 à 12 semaines. Assistant RAG dans le back-office Symfony avec indexation des entités Doctrine et des documents, interface conversationnelle, et fine-tuning des prompts sur les données métier.

Intégration IA complète —à partir de 19 k€ HT, 12 à 18 semaines. Combinaison RAG + agents Messenger + semantic search + LLM services. Backend IA unifié, dashboard monitoring, et optimisation continue sur 1 mois post-déploiement.

Estimation en 30 minutes : Prendre RDV IA Symfony.

Questions & Réponses

Questions fréquentes sur l'intégration IA dans Symfony

PHP est parfaitement adapté pour intégrer l'IA dans une application existante — ne réécrivez pas votre Symfony en Python. L'IA dans une application métier consiste principalement à appeler des APIs de LLMs (OpenAI, Anthropic, Mistral) via HTTP, à gérer des embeddings (stockage et recherche vectorielle via pgvector ou Qdrant), et à orchestrer des tâches asynchrones (Symfony Messenger). Tout cela se fait nativement en PHP/Symfony avec les mêmes performances qu'en Python — les LLMs tournent côté serveur chez le provider, pas dans votre PHP. Le seul cas où Python est pertinent : si vous développez vos propres modèles ML (entraînement, fine-tuning) — mais 95 % des projets d'intégration IA utilisent des modèles pré-entraînés via API. Garder Symfony pour l'application et intégrer l'IA via des services Symfony est le choix économiquement rationnel. Voir notre page [Symfony](/services/development/symfony) pour l'expertise Symfony Nehos.
Le RAG Nehos s'intègre nativement avec Doctrine ORM. Les entités Doctrine ciblées (clients, commandes, tickets, documents) sont indexées dans le vectorstore via un EventSubscriber qui écoute les événements Doctrine PostPersist, PostUpdate et PostRemove. À chaque création ou modification d'entité, le subscriber encode les champs pertinents en embeddings (via l'API du provider IA configuré) et les stocke dans pgvector (colonne vector sur la table existante) ou dans un vectorstore externe (Qdrant, Weaviate). Un cron job de réindexation complète tourne quotidiennement pour rattraper les éventuels écarts. L'indexation ne bloque pas la requête utilisateur — elle est dispatchée via Symfony Messenger en asynchrone. Le RAG n'accède jamais directement à la base SQL pour répondre aux questions — il passe par le vectorstore, ce qui garantit des temps de réponse constants quelle que soit la taille de la base.
Oui, Symfony Messenger est conçu pour les tâches longues. Les workers Messenger (`bin/console messenger:consume`) sont des processus PHP long-running qui traitent les messages de la queue un par un. Pour les tâches IA qui prennent 30 secondes à 2 minutes (génération de rapports, analyse de documents longs, enrichissement de fiches), Messenger gère nativement : le timeout configurable par transport (on augmente le timeout au-delà des 30 secondes par défaut), le retry automatique en cas d'erreur transitoire (API LLM indisponible temporairement), la dead letter queue pour les messages qui échouent après N tentatives, et le monitoring via Symfony Profiler et Prometheus/Grafana. On configure généralement 2 à 4 workers Messenger dédiés aux tâches IA, séparés des workers métier classiques, pour que les tâches IA longues ne bloquent pas les autres traitements. Chaque worker est supervisé par Supervisor ou systemd pour un restart automatique en cas de crash.
pgvector s'installe comme une extension sur votre PostgreSQL existant (`CREATE EXTENSION vector;`). Pas besoin d'un service séparé — les embeddings sont stockés dans des colonnes des tables Doctrine existantes ou dans des tables dédiées. pgvector est supporté par les managed PostgreSQL de la plupart des hébergeurs (OVHcloud, AWS RDS, Scalingo, Platform.sh) et s'installe en une commande sur un PostgreSQL self-hosted. Pour les applications Symfony qui utilisent déjà PostgreSQL, c'est la solution la plus simple et la moins coûteuse — pas de service supplémentaire à gérer, pas de réseau supplémentaire, et les requêtes vectorielles s'intègrent dans les requêtes SQL existantes. Limitation : pgvector est performant jusqu'à environ 5 millions de vecteurs avec un index HNSW. Au-delà, un vectorstore dédié (Qdrant, Weaviate) est recommandé pour les performances de recherche. Pour 95 % des applications métier Symfony, pgvector suffit largement.
L'hallucination est le risque principal d'un RAG mal configuré. Notre approche en trois couches. (1) Prompt engineering strict : le system prompt du RAG Symfony indique explicitement au LLM de répondre UNIQUEMENT à partir des documents récupérés ("Si l'information n'est pas dans les documents fournis, réponds que tu ne sais pas"). (2) Grounding with sources : chaque réponse du RAG cite les documents sources utilisés (nom du document, section, date) — l'utilisateur peut vérifier la source. Si le RAG ne trouve pas de documents pertinents (score de similarité en dessous d'un seuil configurable), il répond explicitement qu'il n'a pas trouvé d'information plutôt que de générer une réponse non sourcée. (3) Évaluation continue : on mesure le taux d'hallucination via un dataset de test (questions-réponses attendues) et on ajuste les paramètres (seuil de similarité, nombre de documents K, température du LLM) pour maintenir un taux d'hallucination sous 5 %. En pratique, nos RAG Symfony en production ont un taux de réponse correcte de 90-95 % sur les questions dans le périmètre de la base de connaissances.
Notre intégration IA est compatible avec Symfony 5.4+ (LTS), Symfony 6.x, et Symfony 7.x. Symfony 5.4 est le minimum requis car il apporte le HttpClient avec retry, Messenger avec les transports async, et le Serializer avec les attributs PHP 8. Pour les applications sur Symfony 4.x ou antérieur, une mise à jour vers Symfony 5.4 LTS est recommandée avant l'intégration IA — cette mise à jour est un projet en soi, que Nehos peut conduire en amont. PHP 8.1+ est requis (pour les enums, readonly properties, fibers, et les types d'intersection utilisés dans notre bundle LLM). Si votre application tourne sur PHP 7.x, la mise à jour vers PHP 8.1+ est un prérequis. Voir notre offre [migration Symfony → Next.js](/services/development/migration-symfony-nextjs) si une refonte plus large est envisagée.
Réserver un audit