Développement web

Laravel AI SDK : le toolkit first-party pour PHP

Laravel publie son premier SDK IA officiel : agents autonomes, output structuré, RAG, embeddings. Ce que ça change concrètement pour vos projets PHP.

Jusqu'à présent, intégrer l'IA dans une application Laravel revenait à choisir un SDK tiers — celui d'Anthropic, d'OpenAI ou une abstraction comme LangChain PHP — et à assembler les pièces soi-même. Laravel publie désormais laravel/ai, un SDK first-party qui standardise ces intégrations directement dans le framework.

Ce n'est pas un wrapper de plus. L'objectif est d'apporter dans l'écosystème Laravel les primitives IA de la même façon que Laravel a standardisé les queues, le cache ou le stockage : une API cohérente, indépendante du provider, avec les conventions habituelles du framework.

Installation

composer require laravel/ai

Le package s'installe comme n'importe quel composant Laravel. Il expose plusieurs classes orientées fonctionnalité — génération de texte, agents, images, audio, embeddings — chacune avec sa façade et sa configuration provider.

La documentation officielle est disponible sur laravel.com/docs/ai-sdk.md et le code source sur github.com/laravel/ai.

Génération de texte et output structuré

La génération de texte est le cas d'usage de base. Ce qui est plus intéressant pour la production, c'est l'output structuré : la capacité à demander au modèle de répondre dans un format typé et validé.

Concrètement, au lieu de parser manuellement du JSON sorti d'un prompt, vous définissez une classe ou un tableau de types et le SDK valide la réponse avant de vous la rendre. C'est ce qui rend l'intégration fiable — plus besoin de gérer les cas où le modèle répond « voici le JSON demandé : ```json... » au lieu du JSON brut, ni d'écrire des fallbacks pour chaque champ manquant.

Pour quiconque a déjà maintenu une intégration IA en production, c'est le changement le plus utile.

Agents autonomes

La partie la plus avancée : les agents. Un agent est un modèle IA auquel vous donnez des instructions (system prompt), des outils (fonctions qu'il peut appeler), une mémoire de contexte, et éventuellement un format de sortie structuré. Il décide seul quand et comment utiliser les outils pour accomplir la tâche.

Le SDK inclut trois outils natifs :

  • WebSearch — recherche web
  • WebFetch — lecture d'une URL
  • FileSearch — recherche dans des documents uploadés

Vous pouvez y ajouter vos propres outils : interroger votre base de données, appeler une API interne, exécuter un calcul métier. L'agent choisit l'outil pertinent selon le contexte, appelle la fonction, intègre le résultat dans sa réponse — sans que vous orchestriez chaque étape manuellement.

Exemple concret : un agent qui reçoit une demande de devis en texte libre, extrait les informations structurées (nature du besoin, budget indicatif, délai), consulte votre catalogue de services pour évaluer la faisabilité, et retourne un objet typé que votre application traite directement.

Autre point notable : le SDK gère le failover automatique entre providers. Si le modèle principal est indisponible ou dépasse un seuil de latence, il bascule sur un fallback configuré sans que votre code en soit affecté.

RAG — Retrieval Augmented Generation

Le SDK inclut une couche native pour le RAG : embeddings, vector stores et reranking.

Le pipeline standard :

  1. Vous découpez vos documents en chunks
  2. Vous générez des embeddings vectoriels pour chaque chunk via le SDK
  3. Vous les stockez dans un vector store
  4. À chaque requête, vous récupérez les chunks les plus proches sémantiquement et les injectez dans le contexte du modèle

Ce que le SDK apporte : une API unifiée pour ces trois étapes, indépendante du provider de vecteurs. Vous changez de provider sans réécrire votre pipeline.

Le reranking est l'étape souvent négligée : une fois les premiers candidats récupérés par similarité vectorielle, un second modèle les reordonne par pertinence réelle vis-à-vis de la question. Sur les cas où la base documentaire est large, ça améliore sensiblement la qualité des réponses.

Images, audio, transcription

Le SDK couvre également la génération d'images (text-to-image), la synthèse vocale (text-to-speech) et la transcription audio (speech-to-text). Ces fonctionnalités sont moins centrales pour la plupart des applications métier, mais l'API unifiée est utile : vous switchez de provider (DALL·E, Whisper, ElevenLabs…) sans modifier votre code applicatif.

Tests

Le SDK inclut des fakes pour chaque fonctionnalité — agents, images, audio, transcriptions, embeddings, reranking, vector stores. C'est souvent la partie la plus frustrante à implémenter soi-même quand on intègre des APIs IA. Avec les fakes natifs, vous testez vos workflows complets sans consommer de tokens et sans dépendre de la disponibilité des APIs externes.

Ce que ça change — et ce que ça ne change pas

Avant ce SDK, intégrer l'IA dans Laravel de façon robuste demandait de maintenir plusieurs packages tiers, gérer les formats de réponse manuellement, implémenter le retry et le failover, et écrire ses propres fakes pour les tests. laravel/ai standardise tout ça avec les conventions du framework.

Ce n'est pas une raison de migrer si vous avez déjà une intégration en place et qui fonctionne — le coût de migration doit se justifier. En revanche, pour un nouveau projet Laravel avec des besoins IA, c'est le point de départ naturel.

Ce que le SDK ne fait pas : il n'embarque pas de logique métier, n'impose pas de provider, et ne remplace pas la réflexion sur l'architecture de votre pipeline. Il donne les briques — à vous de les assembler correctement.


Pour les projets qui combinent automatisation de flux métier et intégration IA, lisez aussi notre comparatif n8n vs Zapier pour automatiser vos processus.