Durée d'intégration d'un agent IA sur Sylius
La durée d'intégration d'un agent IA sur Sylius dépend de quatre choses : la version de Sylius, le nombre de tâches confiées à l'agent, l'état de vos règles écrites et le nombre d'outils externes à brancher. Je ne donne pas de durée type sans avoir vu la boutique, car ce serait un chiffre inventé. Je donne une estimation tâche par tâche, après un diagnostic, et je commence toujours par une seule tâche.
Je suis développeur Sylius et Symfony indépendant, et j'intègre des agents IA dans des boutiques. La question du délai arrive souvent en premier, et elle est légitime : vous avez un pic à tenir, une personne débordée, une saison qui approche. Plutôt qu'un chiffre rassurant et faux, voici ce qui fait varier le délai et comment je l'estime. La démarche complète est décrite sur la page agents IA pour Sylius.
Qu'est-ce qui fait varier la durée d'un projet d'agent IA ?
Le modèle de langage n'est presque jamais le facteur limitant : on l'appelle par une API en quelques lignes. Ce qui prend du temps, c'est tout ce qui l'entoure. Voici les facteurs que je regarde, et leur effet.
| Facteur | Ce qui raccourcit | Ce qui allonge |
|---|---|---|
| Version de Sylius | Sylius 2 à jour | Sylius 1.x avec envie des plugins officiels, donc migration d'abord |
| Périmètre | Une tâche précise, comme le suivi de commande | Plusieurs tâches d'un coup : retours, échanges, litiges |
| Règles du commerçant | Procédures déjà écrites | Règles dans la tête d'une personne, à formaliser |
| Sources de données | Tout est dans Sylius | Boîte mail, transporteur, outil logistique externes à brancher |
| Cas de test | Historique de messages disponible | Pas d'historique, cas à reconstituer |
| Validation humaine | Une personne désignée qui relit | Circuit de validation à inventer |
| Personnalisations Sylius | Boutique proche du standard | Nombreuses surcharges et plugins maison |
Les sources externes méritent une précision. Brancher un transporteur suppose ses accès : pour La Poste, le portail développeurs Okapi propose une API de suivi, avec un compte et des offres gratuites ou payantes selon les besoins. Le temps d'ouvrir ces accès dépend aussi de tiers, et je l'intègre dans l'estimation.
Par quelles étapes passe l'intégration ?
Quel que soit le périmètre, je suis le même ordre, qui sert aussi à mesurer l'avancement.
1. Le cadrage. On choisit la première tâche, celle qui fait perdre le plus de temps, et on écrit les règles que l'agent appliquera, dans un prompt système versionné. On réunit des messages réels anonymisés.
2. La lecture seule. L'agent lit les commandes, les expéditions, les paiements et le client concerné, mais n'écrit rien. On vérifie qu'il retrouve les bonnes données, et seulement celles-là : c'est la couche des accès par rôle.
3. Les propositions. L'agent prépare des brouillons et des actions en attente. Un humain valide chaque proposition. On ajuste les règles là où il se trompe.
4. Les tests. On rejoue les cas réels avant chaque changement, et on trace chaque passage : c'est la couche tests et traces.
5. La mise en service progressive. L'agent traite d'abord une partie des messages, puis davantage, sous surveillance.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Comment j'estime la durée de votre projet ?
Je compte, je ne devine pas. Pour la tâche choisie, je liste les outils dont l'agent aura besoin : lire une commande, lire une expédition, chercher le client, préparer un brouillon, créer une action en attente. Pour chacun, je regarde s'il existe déjà, par l'API de Sylius ou par un serveur MCP officiel, ou s'il faut l'écrire. Je compte les règles à formaliser et les cas de test à réunir. Je repère les accès à demander à des tiers. L'estimation est la somme de ces postes, avec une marge pour ce que je ne vois qu'en cours de route sur une boutique personnalisée.
Pour donner un ordre d'idée de ce que contient un projet, voici l'agent de service client que je construis en ce moment pour une boutique sous Sylius 2. Il lit la boîte de contact, trie sans IA les notifications et les rebonds, retrouve le client par son adresse e-mail exacte, applique les règles écrites du commerçant en citant la règle, et prépare un brouillon dans Gmail plus une action logistique en attente de validation. Entre 40 et 60 cas réels anonymisés seront rejoués avant chaque changement. Une bonne part du travail est là : les règles et les cas, pas le code.
Comment aller plus vite sans prendre de risque ?
En réduisant le périmètre, pas les garde-fous. Commencer par une seule tâche, celle qui revient le plus, donne un agent utile plus tôt. Mettre vos règles par écrit avant le démarrage fait gagner du temps à tout le monde. Garder la validation humaine dès le début évite d'attendre une confiance totale pour mettre l'agent au travail. Ce que l'agent ne fait jamais seul, même pour aller plus vite : envoyer un mail, rembourser ou valider une action.
Pour choisir cette première tâche, lisez l'article sur le premier cas d'usage. Le budget suit les mêmes facteurs que la durée ; je le détaille dans l'article sur le budget d'un agent IA, et la suite après la mise en service dans l'article sur la maintenance.
Et si ma boutique doit d'abord migrer ?
Ce n'est pas toujours nécessaire : un agent sur mesure fonctionne aussi sur Sylius 1.x. Mais si vous tenez aux plugins officiels, la migration s'ajoute au calendrier. Je l'estime avec Sylius Upgrade Analyzer, l'outil open source que j'ai créé, et j'en parle dans l'article Sylius 1 ou migration.
Pour une estimation sur votre boutique, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je passe votre boutique au crible des huit couches d'un agent fiable, et je vous propose un découpage qui rentre dans votre budget.