Laravel 13 : SDK IA natif, recherche vectorielle et zéro rupture

Un framework PHP qui intègre nativement un SDK d'intelligence artificielle compatible avec quatorze fournisseurs, et la recherche vectorielle dans son ORM. Cette description ne correspond ni à un projet expérimental ni à un fork ambitieux. C'est Laravel 13, sorti le 17 mars 2026 dans la continuité directe de la version 12.

Le calendrier annuel du framework s'est imposé comme une routine depuis plusieurs cycles. Une version majeure au premier trimestre, dix-huit mois de correctifs, deux ans de mises à jour de sécurité. La compatibilité ascendante est tenue avec une discipline rare dans l'écosystème web : la quasi-totalité des applications passent de la version 12 à la 13 en quelques minutes, sans toucher au code applicatif. C'est précisément cette stabilité qui rend le contenu de Laravel 13 intéressant. Quand la montée de version n'est plus un risque à gérer, il devient possible de s'attarder sur ce que la nouvelle version permet de construire.

Et là, le saut est net. Laravel 13 introduit deux briques qui ne sont pas des améliorations d'API ou des helpers de plus. Le SDK IA officiel rebat les cartes pour toute équipe qui veut intégrer l'IA dans un produit web. La recherche vectorielle dans le query builder fait entrer la recherche sémantique dans l'outillage standard. Ces deux nouveautés méritent qu'on s'y attarde, parce qu'elles redéfinissent ce qu'il est possible de construire en partant d'une stack Laravel ordinaire, sans dépendre d'un service tiers spécialisé. Le reste de la version, présenté plus brièvement dans cet article, va dans la même direction : moins de configuration, plus d'expressivité, des valeurs par défaut plus strictes.

Laravel 13 en bref

Laravel 13 est sorti le 17 mars 2026. Le framework exige désormais PHP 8.3 minimum, et supporte officiellement les versions 8.4 et 8.5. Cette montée de plancher était attendue : PHP 8.3, stable depuis novembre 2023, apporte les constantes typées, la fonction json_validate(), l'attribut #[Override] et plusieurs optimisations du JIT qui se traduisent par des gains réels sur les charges de travail web.

Le cycle de support suit la politique standard du framework. Les correctifs de bugs sont garantis jusqu'au troisième trimestre 2027, soit dix-huit mois après la sortie. Les correctifs de sécurité courent eux jusqu'au 17 mars 2028. Toute application en production encore en Laravel 10 ou 11 a donc une bonne raison de planifier la migration directement vers la 13 : la fenêtre de support y est plus longue, et la marche technique entre les deux versions reste faible.

La philosophie est explicite : Laravel 13 ne contient aucun changement cassant volontaire pour les applications standards. Taylor Otwell, le créateur du framework, et l'équipe cœur traitent les ruptures de compatibilité comme un coût à éviter quand l'API peut évoluer de façon additive. Concrètement, pour un projet bien tenu, la mise à jour consiste à modifier la contrainte de version dans composer.json, lancer composer update, vérifier les tests. Le reste tient dans les nouvelles fonctionnalités que l'équipe choisit d'adopter à son rythme.

Le SDK IA, sans s'attacher à un fournisseur

Jusqu'à Laravel 12, brancher une intelligence artificielle générative dans une application Laravel passait par un paquet communautaire ou par l'écriture d'un client HTTP sur mesure. Plusieurs bibliothèques solides existaient, comme Prism côté multi-fournisseur ou OpenAI-PHP côté monoprovider, ainsi que divers paquets dédiés à chaque grand acteur. Chacune avait sa propre API, son propre rythme de mises à jour et sa propre stratégie de gestion des erreurs. Changer de fournisseur signifiait réécrire la couche d'intégration. Pour une agence qui livre des projets à plusieurs clients ayant des préférences différentes, le coût de cette diversité devenait significatif.

Laravel 13 répond par un SDK officiel, le paquet laravel/ai, intégré directement à l'écosystème du framework. Ce n'est pas un wrapper de plus. C'est un effort d'unification, conçu pour que le code applicatif ne dépende plus du fournisseur sous-jacent.

Pourquoi un SDK officiel arrive maintenant

Le moment n'est pas un hasard. Entre fin 2024 et début 2026, le marché des modèles génératifs s'est suffisamment stabilisé pour qu'une API commune devienne réaliste. Les patrons d'usage se sont décantés : génération de texte avec ou sans outils (tool calling), embeddings pour la recherche sémantique, génération d'images, synthèse et transcription audio, structuration de sorties via des schémas. Chaque grand fournisseur expose désormais ces capacités, avec des variations sur les paramètres et le format de réponse, mais sur des fondations comparables.

Au même moment, l'écosystème a vu émerger plusieurs SDK unifiés côté JavaScript et Python, et le Model Context Protocol côté outillage agentique. La logique de standard ouvert que nous décrivions dans notre article sur le MCP joue ici à un autre niveau. Laravel 13 capitalise sur cette maturation : le framework ne cherche pas à inventer un standard, il offre une couche d'abstraction propre à l'écosystème PHP, alignée sur les conventions Laravel, qui rend le code applicatif indépendant du fournisseur.

Pour une agence comme MtoM Création, cela signifie qu'un même code peut tourner sur Claude pour un client qui privilégie Anthropic, sur GPT-5 pour un autre qui a déjà ses crédits OpenAI, et sur un modèle local hébergé via Ollama pour un troisième qui a des contraintes de souveraineté de données. La bascule se fait dans la configuration, pas dans le code métier.

Quatorze fournisseurs sous une API

La liste des fournisseurs supportés au lancement est large. Le SDK couvre Anthropic (Claude), OpenAI et Azure OpenAI, Google Gemini, xAI (Grok), DeepSeek, Mistral, Groq, Cohere, OpenRouter, Ollama pour les modèles locaux, ElevenLabs pour la synthèse vocale, Jina et VoyageAI pour les embeddings. Le SDK gère pour chacun les capacités disponibles : un fournisseur d'embeddings spécialisé comme VoyageAI ne propose pas de génération d'images, le SDK le sait et ne propose que ce qui a du sens.

Le mécanisme de configuration repose sur des variables d'environnement classiques (ANTHROPIC_API_KEY, OPENAI_API_KEY, OLLAMA_API_KEY...) et un fichier de configuration qui définit le fournisseur par défaut pour chaque capacité. Les URL de base peuvent être personnalisées pour OpenAI, Anthropic, Gemini, Groq, Cohere, DeepSeek, xAI et OpenRouter, ce qui permet de pointer vers une instance privée ou un proxy interne. Pour les entreprises soumises à des contraintes de localisation des données, cette flexibilité est déterminante.

L'approche est volontairement provider-agnostic mais ne masque pas tout. Quand un comportement spécifique à un modèle a besoin d'être configuré (paramètres de raisonnement, modes de génération particuliers, options de sortie structurée), le SDK le laisse passer via des options nommées. C'est l'équilibre classique d'une bonne abstraction : tenir la promesse de portabilité sur le cas courant, et laisser un échappatoire propre pour les cas qui justifient l'attachement à un fournisseur précis.

Trois lignes pour générer du texte, des embeddings ou une image

L'API est conçue pour rester courte. La génération de texte via un agent métier tient en quelques lignes :

use App\Ai\Agents\SalesCoach;

$response = SalesCoach::make()
    ->prompt('Analyse cet appel commercial et identifie les trois objections principales : ...');

return (string) $response;

L'agent SalesCoach est une classe applicative qui hérite des conventions du SDK. Elle déclare son fournisseur préféré, son modèle, son prompt système, ses outils disponibles. À l'usage, on l'invoque comme n'importe quel service Laravel. Les outils éventuels (tool calling) sont des méthodes typées de la classe, que l'agent appelle automatiquement quand le modèle le décide. Cette logique d'agent rapproche Laravel d'écosystèmes comme LangChain ou le SDK IA de Vercel, mais avec une API beaucoup plus proche du style de code que les équipes Laravel écrivent déjà.

La génération d'embeddings est encore plus directe, parce qu'elle s'intègre aux helpers natifs du framework :

use Illuminate\Support\Str;

$embeddings = Str::of('La vallée de Napa produit d\'excellents vins.')
    ->toEmbeddings();

Cette intégration via la classe Str n'est pas un détail cosmétique. Elle signale que les embeddings sont traités comme une opération de base sur du texte, au même titre que slug() ou lower(). Le code applicatif n'a pas à connaître le détail du fournisseur d'embeddings ni le nombre de dimensions du vecteur retourné. Cette information existe et reste accessible, mais elle est rangée à sa place dans la configuration.

Pour les contenus média, la grammaire est la même :

use Laravel\Ai\Image;
use Laravel\Ai\Audio;

$image = Image::of('Une boutique parisienne sous la pluie, photographie réaliste')->generate();
$audio = Audio::of('Bonjour, voici votre message vocal automatisé.')->generate();

Cette uniformité d'écriture est ce que le SDK apporte au-delà du simple regroupement. Quand quatre capacités différentes (texte, image, audio, embeddings) partagent la même grammaire et le même cycle de configuration, la barrière à l'expérimentation tombe. L'article 53 du plan éditorial de MtoM Création couvrira en détail la construction d'agents avec outils, la gestion des erreurs et l'interrogation sécurisée de bases de données via le SDK. Pour cet aperçu, retenons que la surface d'API est minuscule, les conventions Laravel sont préservées, et le code métier reste portable.

La recherche vectorielle entre dans le query builder

La deuxième nouveauté structurante de Laravel 13 ne fait pas autant de bruit, mais elle change tout autant le paysage. Le query builder, c'est-à-dire l'outil qui sert à écrire des requêtes SQL fluides dans Laravel, gagne une clause whereVectorSimilarTo() qui permet d'interroger une base de données par similarité sémantique au lieu de correspondance exacte.

pgvector, le prérequis qu'il faut nommer

La recherche vectorielle dans Laravel 13 s'appuie sur PostgreSQL et l'extension pgvector. Pour les projets qui tournent déjà sur Postgres, l'activation de l'extension est une commande SQL d'une ligne et une modification de la configuration de l'hébergeur. Pour les projets sur MySQL ou MariaDB, cette nouveauté impose un choix : migrer la base, gérer un Postgres secondaire dédié aux embeddings, ou s'appuyer sur un service vectoriel externe via le SDK IA.

pgvector est une extension open source maintenue depuis 2021, désormais largement adoptée. Elle ajoute un type de colonne vector(n) où n est le nombre de dimensions, et des opérateurs d'indexation (<-> pour la distance euclidienne, <=> pour la distance cosinus, <#> pour le produit scalaire négatif). Les hébergeurs gérés modernes la proposent en standard : Laravel Cloud, Supabase, Neon, RDS Aurora Postgres, et la plupart des offres Postgres infogérées exposent désormais pgvector en option d'activation. Côté self-hosted, l'installation se résume à CREATE EXTENSION vector; dans la base.

Pour la création de la colonne vectorielle, Laravel 13 expose un helper de migration dédié, accompagné d'une méthode Schema::ensureVectorExtensionExists() qui active l'extension dans Postgres si elle ne l'est pas encore :

Schema::ensureVectorExtensionExists();

Schema::create('documents', function (Blueprint $table) {
    $table->id();
    $table->text('contenu');
    $table->vector('embedding', dimensions: 1536);
    $table->timestamps();
});

L'indexation vectorielle (HNSW ou IVFFlat selon les besoins de précision et de volume) reste à déclarer en SQL brut via DB::statement(), ce qui est cohérent avec la façon dont Laravel laisse passer la main pour les optimisations spécifiques à un moteur.

Le nombre de dimensions (1536) correspond ici aux embeddings d'OpenAI text-embedding-3-small. Pour Anthropic, VoyageAI ou Jina, la valeur diffère et doit correspondre exactement au modèle utilisé pour générer les vecteurs. C'est l'une des rares erreurs de cohérence à surveiller en pratique : un mismatch entre la colonne et le modèle d'embeddings produit des résultats inexploitables, parfois sans message d'erreur explicite, ce qui peut faire perdre des heures avant que l'origine du problème ne saute aux yeux.

whereVectorSimilarTo() : du SQL à la recherche sémantique

Une fois la colonne et les vecteurs en place, l'interrogation se résume à :

$documents = DB::table('documents')
    ->whereVectorSimilarTo('embedding', 'meilleures caves dans la vallée de Napa')
    ->limit(10)
    ->get();

Trois choses se passent en arrière-plan. Le SDK IA convertit la phrase de recherche en vecteur via le fournisseur d'embeddings configuré. Le query builder traduit la clause whereVectorSimilarTo en opérateur de distance sur pgvector. PostgreSQL renvoie les dix lignes les plus proches sémantiquement, classées par distance.

Le développeur n'a écrit ni SQL spécifique, ni appel d'API séparé, ni couche de mapping. La clause s'intègre dans une chaîne d'appels Eloquent ou Query Builder classique : elle se combine avec des where() traditionnels, des jointures, du select(), de la pagination. Le code reste lisible et le pattern reste celui que tout développeur Laravel connaît déjà. Aucun nouveau langage à apprendre, aucun service externe à brancher, aucun pipeline d'indexation à maintenir en parallèle de la base applicative.

Pour les cas plus avancés, la clause accepte des options : distance maximale, seuil de similarité, choix explicite de l'opérateur de distance. La couverture est suffisante pour la grande majorité des cas d'usage applicatifs. Pour les besoins vraiment spécifiques (recherche hybride lexicale et sémantique, reranking par un modèle dédié, indexation multi-champs), Laravel laisse le développeur écrire du SQL brut via DB::raw(). La promesse n'est pas d'absorber toute la complexité du domaine vectoriel, mais d'enlever 80 % du frottement dans les cas courants.

Ce que ça débloque sur un projet réel

Plusieurs cas d'usage que nous croisons régulièrement chez MtoM Création passent du statut « projet ambitieux dédié » à « fonctionnalité raisonnable d'un site Laravel standard ».

La recherche de FAQ intelligente d'abord. Au lieu de chercher des mots-clés exacts dans des questions préenregistrées, l'utilisateur pose sa question en langage naturel, et l'application retourne la FAQ la plus proche sémantiquement. Le classement ne dépend plus de la correspondance des termes mais du sens. La même logique s'applique aux pages d'aide d'un site e-commerce, à la documentation interne d'un outil métier, ou à un moteur de recherche de produits décrits en langage marketing libre.

La recommandation de contenu connexe ensuite. Plutôt que de configurer manuellement des liens entre articles ou produits, l'application indexe le contenu sous forme d'embeddings et retourne automatiquement les éléments les plus proches. Cette approche tient compte du sens du texte, pas seulement des tags ou des catégories. Pour un blog d'agence comme celui de MtoM Création, cela permet de proposer des suites de lecture qui correspondent au sujet réellement traité, pas au regroupement éditorial du moment.

Enfin, et c'est le plus structurant, la recherche augmentée par génération (RAG). Le pattern consiste à retrouver les passages pertinents d'un corpus via la recherche vectorielle, à les injecter dans le contexte d'un modèle génératif via le SDK IA, puis à demander une réponse qui synthétise ces passages. Construire un assistant qui répond aux questions des clients à partir de la documentation produit demande désormais quelques centaines de lignes de Laravel, pas un projet de plateforme dédiée. L'article 54 du plan éditorial de MtoM Création détaillera ce pattern en pratique, avec gestion du découpage des documents, indexation incrémentale et évaluation des réponses.

Le reste, à doses concentrées

Au-delà de ces deux pivots, Laravel 13 amène une série d'améliorations qui méritent d'être citées même si chacune ne justifie pas une section dédiée. Plusieurs feront l'objet d'articles à part entière dans la série Laravel du plan éditorial de MtoM Création.

Les attributs PHP natifs s'étendent à presque tous les composants du framework. Là où Laravel 12 imposait encore des propriétés de classe pour configurer un modèle Eloquent, un job, une commande Artisan ou un contrôleur, Laravel 13 propose une grammaire déclarative. Un modèle Eloquent peut désormais se décrire avec #[Table('clients')], #[Fillable('nom', 'email')], #[Hidden('mot_de_passe')] directement à côté de la classe. Un job en file d'attente déclare #[Tries(3)], #[Backoff(60)], #[Queue('high')] en attributs au lieu de surcharger des propriétés. Une commande console pose sa signature et sa description via #[Signature] et #[Description]. Les contrôleurs gagnent #[Middleware] et #[Authorize] au niveau de la classe ou de la méthode. Les factories, seeders, ressources API et formulaires suivent la même logique. Le code applicatif gagne en lisibilité, et l'analyse statique progresse. L'article 57 du plan éditorial creusera ce changement de paradigme.

Le routage des files d'attente sort de la configuration globale pour entrer dans une API dédiée. Queue::route(ProcessPodcast::class, connection: 'redis', queue: 'podcasts') centralise dans un seul endroit les règles de dispatch par classe de job. Fini les dispatch()->onQueue() éparpillés dans le code applicatif : la politique d'orchestration des jobs devient une déclaration de configuration. C'est le genre de changement qui paraît mineur sur un petit projet et qui devient structurant sur une application qui pousse des dizaines de types de jobs vers plusieurs files distinctes.

Le JSON:API natif entre dans les ressources Eloquent. La spécification jsonapi.org, qui standardise la sérialisation des ressources, les relations, les filtres et la pagination dans les API JSON, est désormais supportée nativement. Pour une équipe qui livre une API à un front Vue.js ou React, ou qui ouvre une API publique à des partenaires, c'est plusieurs centaines de lignes de sérialisation manuelle ou de paquets tiers qui disparaissent. L'article 58 du plan éditorial reviendra dessus, en parallèle du routage de files d'attente.

Cache::touch() permet de prolonger la durée de vie d'un élément en cache sans relire ni réécrire sa valeur. C'est utile pour les sessions actives, les paniers d'achat, le rate limiting glissant. La méthode renvoie true si la clé existe et a été prolongée, false sinon. Elle fonctionne sur tous les drivers, du Redis au fichier en passant par DynamoDB, Memcached ou la base de données. Une ligne de code économise un aller-retour réseau à chaque rafraîchissement.

Le middleware PreventRequestForgery succède au mécanisme CSRF historique en y ajoutant une vérification de l'origine de la requête. La compatibilité avec les tokens existants est préservée, mais la sécurité de fond est renforcée. Pour un site exposé à des scénarios de cross-site request forgery sophistiqués, c'est une défense supplémentaire qui se déclenche sans configuration applicative particulière.

Laravel Reverb, le serveur WebSocket officiel du framework lancé en 2024 avec Laravel 11, gagne un driver Database. Cette option permet d'utiliser la base de données comme broker de messages pour les petits et moyens trafics (jusqu'à environ 10 000 connexions simultanées). Pour les projets qui n'ont pas Redis disponible, ou qui veulent simplifier leur infrastructure de production, c'est une bascule appréciable. Au-delà du seuil, Redis reste la bonne réponse, et le code applicatif reste identique.

Le routage par sous-domaine est centralisé dans un fichier de configuration config/domains.php qui définit les domaines, leurs middlewares dédiés, et l'injection automatique de modèles (par exemple un sous-domaine client.example.com qui injecte automatiquement l'instance Client correspondante). Pour les applications multi-tenant, cette centralisation supprime beaucoup de code conditionnel dispersé.

Enfin, et c'est plus une politique qu'une fonctionnalité : la stabilité contractuelle. Laravel 13 confirme que la version majeure annuelle n'est plus un événement à craindre. La mise à jour est une formalité pour les projets bien tenus, ce qui change le calcul de retour sur investissement de la maintenance. Pour un client qui demande pourquoi son site doit suivre les montées de version, la réponse devient simple : parce que la marche est faible et la fenêtre de support se renouvelle.

Comment nous utilisons déjà Laravel 13 chez MtoM Création

Nous sommes convaincus que notre valeur ajoutée réside autant dans l'accompagnement, les conseils, la pédagogie et la confiance que vous nous témoignez, que dans les solutions techniques que nous mettons à votre disposition. Sur Laravel, cela se traduit par un usage quotidien du framework pour les projets sur mesure de nos clients, et par une montée de version dès qu'elle apporte une amélioration tangible.

Nos premiers projets sous Laravel 13 nous ont fait basculer sur le SDK IA pour deux fonctionnalités jusque-là gérées avec des paquets tiers : la génération assistée de descriptions produits pour un client e-commerce, et un assistant de FAQ contextuelle sur un site institutionnel. La portabilité entre fournisseurs nous a permis de proposer un mode local via Ollama pour les données les plus sensibles, et un mode cloud via Anthropic ou OpenAI pour le reste, sans dupliquer le code métier. La recherche vectorielle dans Postgres a remplacé une intégration externe d'Algolia sur un cas où le volume ne justifiait pas le coût mensuel. Les attributs PHP natifs ont commencé à apparaître dans les nouveaux modèles que nous écrivons, et nous les rétrofittons progressivement sur les projets actifs au gré des autres interventions.

La suite, dans la même direction

Laravel 13 est une version qu'on apprivoise sans drame. La promesse de stabilité tient, la montée de version se fait en arrière-plan, et le contenu nouveau est celui que l'équipe ajoute à son rythme dans des projets qui tournent déjà. Le SDK IA et la recherche vectorielle ne sont pas des cases à cocher : ce sont des primitives à utiliser quand un cas d'usage le justifie, et qui rendent abordables des architectures qui réclamaient hier un effort significatif d'intégration ou un service tiers spécialisé.

La direction prise par le framework est cohérente avec ce que nous observons dans l'écosystème web depuis dix-huit mois. L'IA générative s'intègre dans les outils standards plutôt que de rester un domaine spécialisé, et les frameworks matures absorbent ces primitives au rythme où elles se stabilisent. Pour une PME qui construit un projet web aujourd'hui, ce mouvement réduit le coût d'entrée et la dépendance à des fournisseurs spécialisés. Pour une agence comme MtoM Création, il aligne notre stack quotidienne avec les attentes du marché sans casser ce qui fonctionne déjà.

La série Laravel du plan éditorial poursuivra avec des deep dives sur les briques évoquées ici : SDK IA et construction d'agents, recherche vectorielle et pgvector en pratique, attributs PHP natifs, routage de files d'attente et JSON:API natif. Si vous démarrez un projet PHP, ou si vous envisagez de moderniser une stack existante, la conversation est ouverte.