L'IA intégrée aux outils métier : de l'option au standard
Pendant longtemps, l'intelligence artificielle dans les outils CRM rimait avec chatbot basique ou suggestion automatique de texte. Aujourd'hui, la donne change radicalement : il est possible d'intégrer un véritable agent IA capable de lire et d'écrire dans un CRM, avec validation humaine à chaque action sensible. C'est exactement ce que l'équipe derrière Relaticle a mis en production avec la version 3.3 de leur CRM open-source Laravel/Filament.
Cet article décrypte les choix architecturaux et les enseignements techniques de cette intégration, à travers le prisme du package first-party laravel/ai — un retour d'expérience précieux pour tout développeur PHP souhaitant aller au-delà des démos.
Pourquoi un agent intégré plutôt que MCP seul ?
Relaticle expose déjà un serveur MCP (Model Context Protocol) avec une trentaine d'outils sécurisés via Laravel Sanctum et une isolation par équipe. Cela permet à des clients comme Claude Desktop ou ChatGPT de piloter le CRM à distance — une solution idéale pour les utilisateurs avancés.
Mais la réalité du terrain commercial est autre : le commercial lambda n'ouvrira jamais Claude Desktop. En revanche, il appuiera volontiers sur Cmd+J et tapera "crée la société et ajoute le contact" directement dans son interface habituelle. C'est pour cette majorité silencieuse que la fonctionnalité "Ask Relaticle" a été construite.
La règle architecturale qui a permis de garder le projet maintenable est simple mais fondamentale :
L'API REST, les outils MCP et l'agent intégré appellent tous les mêmes classes d'action.
Une seule source de vérité pour la logique métier, les logs d'activité, les notifications et le scoping multi-tenant — peu importe que la requête vienne d'un formulaire Filament, d'un client HTTP ou d'un modèle de langage.
laravel/ai en pratique : ce que le package apporte vraiment
Le package laravel/ai (officiellement maintenu par l'équipe Laravel) simplifie considérablement la définition d'un agent grâce à un système d'attributs PHP et de contrats. L'agent complet tient en une seule classe :
#[Provider(['anthropic', 'openai'])]
#[MaxSteps(15)]
class CrmAgent implements Agent
{
use HasTools;
#[Tool('List contacts in the CRM')]
public function listContacts(string $query = ''): Collection { ... }
#[Tool('Create a new company')]
public function createCompany(CreateCompanyData $data): Company { ... }
}
Le provider peut être anthropic ou openai — la compatibilité multi-fournisseur est native. Le paramètre MaxSteps limite le nombre d'itérations de l'agent pour éviter les boucles infinies en production, un garde-fou essentiel.
Là où le package brille vraiment, c'est dans la gestion transparente du cycle outil : injection des définitions d'outils dans le prompt système, parsing de la réponse du modèle, exécution des appels et réinjection des résultats — tout cela sans code boilerplate.
Où réside la vraie complexité : au-delà des prompts
L'auteur de l'article original est direct sur ce point : la difficulté ne vient pas des prompts. Voici les vrais défis rencontrés en production.
1. La validation humaine sur les opérations d'écriture
Laisser un LLM modifier des données métier sans supervision est inenvisageable dans un contexte professionnel. L'approche retenue consiste à différencier les outils en lecture (exécution immédiate) et les outils en écriture (soumis à approbation explicite de l'utilisateur). L'interface affiche un diff lisible des changements proposés avant toute validation.
2. L'isolation multi-tenant
Dans une application SaaS, chaque requête de l'agent doit être strictement scopée à l'équipe de l'utilisateur connecté. L'avantage de passer par les mêmes classes d'action que le reste de l'application est que le scoping tenant est appliqué automatiquement — pas de surface d'attaque supplémentaire.
3. La gestion du contexte et des tokens
Un agent qui peut faire jusqu'à 15 étapes consomme rapidement la fenêtre de contexte. La solution passe par une sélection rigoureuse des données renvoyées par chaque outil (éviter de retourner des objets Eloquent complets) et par une pagination intelligente des résultats de recherche.
4. La fiabilité des appels d'outils
Les LLMs actuels ne sont pas infaillibles sur le respect des schémas JSON pour les appels d'outils. L'utilisation de Data Transfer Objects (DTO) typés avec validation Laravel permet de rejeter proprement les appels malformés et de renvoyer un message d'erreur exploitable par le modèle pour se corriger.
Ce que cela signifie pour les équipes PHP/Symfony
Même si cet exemple est construit sur Laravel, les principes s'appliquent directement à un contexte Symfony :
- Centraliser la logique métier dans des services ou des commandes dédiées, indépendants du transport (HTTP, CLI, agent IA). C'est la condition sine qua non pour intégrer un agent sans dupliquer le code.
- Adopter une approche human-in-the-loop sur toutes les opérations d'écriture dès le début, pas en retrofit.
- Exposer MCP en parallèle pour les intégrations avancées, tout en construisant l'UX intégrée pour les utilisateurs standards.
- Monitorer les coûts et la latence par type d'opération dès le premier jour de production.
L'écosystème PHP dispose désormais de packages matures pour cette intégration (laravel/ai côté Laravel, des bridges Symfony commencent à émerger). La question n'est plus technique, elle est architecturale : êtes-vous prêts à concevoir vos services métier comme des outils appelables par un LLM ?
Conclusion
Relaticle démontre qu'intégrer un agent IA dans un outil métier existant est aujourd'hui accessible à une équipe PHP standard, à condition d'avoir une architecture propre et une vision claire de la place de l'humain dans la boucle. Le package laravel/ai réduit le boilerplate à son strict minimum, mais la valeur réelle vient des décisions d'architecture prises en amont.
Pour les équipes qui construisent des outils SaaS sur PHP/Symfony, c'est le moment d'auditer votre couche de logique métier : est-elle suffisamment découplée pour être invoquée par un agent demain matin ?
Source originale : Making an open-source CRM AI-native (laravel/ai in production) par Manuk Minasyan sur DEV Community.
