Laravel AI : SDK, Boost ou MCP : comment choisir (et ne pas sur-architecturer) ?

Le piège classique quand on “ajoute de l’IA” à une app Laravel, ce n’est pas la qualité des réponses. C’est l’architecture. Tu peux très vite te retrouver avec des prompts planqués partout, des appels LLM non traçables, et une surface de risque PII impossible à auditer.

Laravel te propose aujourd’hui trois briques qui n’ont pas le même job : Laravel AI SDK (IA dans ton code), Boost (accélérer ton produit/ton équipe), et MCP (connecter des agents à des outils). Si tu choisis la mauvaise, tu vas soit under-builder, soit over-builder.

On va trancher avec une grille de décision “feature-by-feature”, puis deux architectures types, puis des règles de sécurité non négociables pour un SaaS.

Les 3 outils, sans blabla marketing

Laravel AI SDK : intégrer un LLM proprement dans ton application

Le SDK, c’est quand ton application appelle un modèle (génération, extraction, classification, résumé, etc.) et que tu veux le faire de façon structurée : services dédiés, gestion des providers, tests, observabilité, garde-fous.

Si ton besoin ressemble à “l’utilisateur clique → on génère X → on stocke Y → on affiche Z”, tu es dans le bon outil.

Laravel Boost : accélérer la construction, pas l’architecture runtime

Boost, c’est un accélérateur. L’idée n’est pas de te faire déployer une armée d’agents en prod. C’est de livrer plus vite (scaffolding, aide au développement, conventions, intégrations) sans réinventer la roue.

Si ton besoin principal est “on doit shipper une feature IA sans y passer 3 semaines”, Boost est un choix pragmatique.

MCP (Model Context Protocol) : brancher des agents sur des outils

MCP, c’est le monde “agent + outils” : un modèle qui peut découvrir et appeler des capacités exposées par des serveurs (ex : lire un CRM, créer un ticket, interroger un dataset, exécuter une recherche, etc.).

Tu choisis MCP quand tu veux un système plus “opératif” : l’IA ne répond pas seulement, elle agit via des outils que tu contrôles.

La grille de décision : quel outil pour quel besoin ?

Utilise cette grille comme une check-list. Si tu coches majoritairement une colonne, tu as ton choix. Et si tu coches plusieurs colonnes… tu vas probablement combiner, mais proprement.

1) Le flux est-il déterministe ?

• SDK : oui. Tu as un flux clair (entrée → traitement → sortie), tu veux juste “augmenter” une étape avec un LLM.
• Boost : pas applicable (c’est un accélérateur de livraison).
• MCP : pas forcément. Un agent peut planifier, choisir des outils, itérer. Puissant, mais plus dur à borner.

2) Est-ce que l’IA doit exécuter des actions (tools) ?

• SDK : possible, mais tu vas souvent coder toi-même le “tooling” (fonctions, endpoints internes, politiques d’accès).
• Boost : non (ou indirectement via des templates/recettes).
• MCP : oui, c’est l’objectif. Exposer des outils de manière standardisée et contrôlée.

3) L’intégration doit-elle être strictement auditée (SaaS, conformité, support) ?

• SDK : bon fit. Tu peux centraliser les appels, logger, versionner les prompts, gérer les erreurs, mesurer le coût.
• Boost : utile pour partir sur de bonnes bases, mais l’audit reste ton travail.
• MCP : audit indispensable. Tu dois tracer chaque outil appelé, chaque paramètre, et imposer des politiques (sinon c’est ingérable).

4) Ton problème ressemble-t-il à “copilot interne” ?

• SDK : ok si tu fais un assistant simple (FAQ, recherche, rédaction). Mais dès que l’assistant doit “agir”, tu vas bricoler.
• Boost : non.
• MCP : excellent : l’assistant devient un orchestrateur d’outils (support, ops, admin, data).

5) Ton principal risque est-il la complexité (et pas la qualité IA) ?

• SDK : le plus simple à garder sous contrôle. Tu peux l’encapsuler comme n’importe quel service métier.
• Boost : réduit la friction au départ.
• MCP : le plus “système”. À réserver aux cas où l’agent-outillé est réellement nécessaire.

Architecture type #1 : IA “in-app” avec le SDK (simple, solide)

Objectif : ajouter une ou plusieurs features IA (résumé, extraction, scoring, rédaction assistée) sans modifier la nature de ton app. L’IA est un service, pas un deuxième cerveau qui pilote tout.

Le schéma

• Controller/Job → AIService (unique point d’entrée)
• AIService → Provider LLM (via SDK) + prompt templates versionnés
• AIService → stockage (résultat, coûts, métadonnées, traces)
• UI → affiche + permet de corriger (human-in-the-loop)

Ce que tu gagnes

• Centralisation : pas d’appels LLM “dans un coin du code”.
• Testabilité : tu peux mocker le provider et figer des fixtures.
• Observabilité : un seul endroit pour logs, métriques, coûts.

Exemple minimal : encapsuler un appel IA

<?php

namespace App\Services;

use App\Models\AiCall;

class AiService
{
    public function summarizeTicket(string $text, int $userId): string
    {
        // 1) Redaction minimale / suppression PII si nécessaire (voir section sécurité)
        $input = $this->redactIfNeeded($text);

        // 2) Appel LLM via ton intégration (SDK)
        $result = app('ai')->chat()->prompt(
            system: 'Tu es un assistant support. Réponds court et actionnable.',
            user: "Résume ce ticket en 3 puces :\n\n{$input}"
        );

        // 3) Trace persistée (audit + coût + debug)
        AiCall::create([
            'user_id' => $userId,
            'use_case' => 'ticket_summary',
            'input_hash' => hash('sha256', $input),
            'output' => $result->text(),
            'meta' => $result->meta(),
        ]);

        return $result->text();
    }

    private function redactIfNeeded(string $text): string
    {
        return $text; // à remplacer par une stratégie de redaction réelle
    }
}

Architecture type #2 : agents + outils avec MCP (quand l’IA doit “opérer”)

Objectif : un assistant qui ne se contente pas de répondre, mais qui agit : créer un remboursement, analyser des logs, ouvrir un incident, générer un export, mettre à jour une fiche client…

Le point clé : tu n’exposes pas ta base de données au modèle. Tu exposes des outils explicites, versionnés, limités, avec des politiques.

Le schéma

• Client (web, Slack, support backoffice) → “Agent Runner” (ton app)
• Agent Runner ↔ LLM (raisonnement + choix d’outils)
• Agent Runner ↔ MCP servers (outils : CRM, billing, logs, recherche, etc.)
• Politiques : auth, scopes, quotas, allow-list d’outils, validations

Quand MCP est justifié (et quand il ne l’est pas)

• Justifié : workflows multi-étapes, besoin de chercher/agir/itérer, intégrations multiples, assistant interne ops/support.
• Overkill : génération de texte simple, extraction ponctuelle, enrichissement de formulaire. Là, le SDK suffit.

Règle d’or : un outil MCP doit être plus strict qu’un endpoint “normal”

Pourquoi ? Parce que l’appelant (un agent) n’a pas ton bon sens métier. Il exécute. Donc tu dois coder les garde-fous que ton équipe mettrait “implicitement” en UI.

• Validation stricte des entrées (types, plages, formats)
• Idempotence (clé de déduplication)
• Politiques d’accès par rôle + par tenant
• Limites : max results, timeouts, pagination forcée
• Journaux d’audit : qui a appelé quoi, quand, avec quel résultat

Boost : comment l’utiliser sans te raconter d’histoires

Boost, tu le sors quand tu veux réduire le temps entre “on a eu l’idée” et “c’est en prod”. Mais ne lui demandes pas de résoudre le choix d’architecture à ta place.

Une utilisation saine, c’est :

• Démarrer vite une feature IA cadrée (MVP) avec une structure propre
• Appliquer des conventions (où vivent les prompts, comment on trace, comment on teste)
• Éviter le “prompt spaghetti” et le code dupliqué

Une utilisation toxique, c’est :

• Multiplier les features IA sans métriques (coût, latence, taux d’échec)
• Laisser l’IA s’éparpiller dans le codebase, sans point d’entrée unique

Ne pas sur-architecturer : la règle des 3 niveaux

Tu peux décider vite en posant cette question : “À quel niveau l’IA intervient ?”

• Niveau 1 — Fonction : une feature isolée (résumé, extraction). → SDK.
• Niveau 2 — Produit : plusieurs features IA, besoin de standardiser et shipper vite. → SDK + Boost.
• Niveau 3 — Système : un assistant qui opère via des outils, multi-étapes, multi-sources. → SDK + MCP (Boost en support).

Sécurité & fiabilité : les règles non négociables (SaaS Laravel)

Que tu sois en SDK ou en MCP, si tu ignores ça, tu vas le payer : en incident, en coût, ou en confiance client.

1) PII : décider explicitement ce qui peut sortir

• Classifie : PII (email, téléphone), données sensibles (facturation), secrets (tokens).
• Stratégie : redaction (masquage) ou allow-list (seul ce qui est autorisé sort).
• Par défaut : le modèle n’a pas besoin de tout. Envoie le minimum utile.

2) Logs : tracer sans stocker n’importe quoi

• Stocke des hash d’input + métadonnées (use case, modèle, latence, tokens), pas forcément le texte brut.
• Si tu stockes le texte : chiffrement au repos + rétention courte + accès restreint.
• En MCP : loggue chaque tool call (nom, paramètres validés, résultat, erreurs).

3) Quotas & coûts : l’IA est une dépendance payante

• Quotas par tenant / par user / par use case.
• Timeouts stricts et retries contrôlés.
• Dégradation : si LLM down ou trop lent, fallback (réponse standard, feature désactivée, file d’attente).

4) Prompting : versionner, tester, mesurer

• Versionne les prompts comme du code (ou dans une table versionnée).
• Tests : fixtures d’entrées et assertions sur la structure de sortie (pas sur la poésie).
• Mesure : taux de correction utilisateur, précision, et “time-to-value”.

5) Sorties structurées : force le format

Pour tout ce qui touche à ton métier (catégorisation, extraction), impose une sortie JSON stricte. Tu veux réduire l’ambiguïté, pas l’augmenter.

<?php

$schema = [
    'type' => 'object',
    'properties' => [
        'category' => ['type' => 'string'],
        'priority' => ['type' => 'string', 'enum' => ['low','medium','high']],
        'summary' => ['type' => 'string'],
    ],
    'required' => ['category','priority','summary'],
];

$result = app('ai')
    ->chat()
    ->expectJson($schema)
    ->prompt(
        system: 'Tu classifies des tickets support. Réponds uniquement en JSON valide.',
        user: $ticketBody
    );

$data = $result->json();

Combinaisons réalistes (et recommandées)

• SDK seul : 80% des cas (features IA dans un SaaS, in-app).
• SDK + Boost : tu industrialises, tu scales l’équipe, tu veux shipper sans chaos.
• SDK + MCP : tu as un assistant qui agit (support/ops/admin) avec des outils stricts.
• Boost + MCP sans SDK : rare. En pratique, tu auras quand même besoin d’une couche “SDK-like” pour normaliser appels, logs, quotas.

Conclusion : la décision en une phrase

Si l’IA “répond” dans ton produit → SDK. Si tu veux livrer plus vite → Boost. Si l’IA “agit” via des outils → MCP. Le reste, c’est de la discipline : point d’entrée unique, audit, quotas, et PII sous contrôle.

Sources

• Laravel — “Laravel AI SDK, Boost, or MCP: Which Tool Do You Need?”