ERP, CRM et logistique : toujours connectés à Sylius 2 ?
Oui, vos ERP, CRM et outils logistiques peuvent continuer à communiquer avec Sylius 2, mais rarement sans adaptation. Ce ne sont pas ces outils qui changent : c'est la façon dont Sylius expose ses données et déclenche ses événements. Selon que la liaison passe par l'API, par un plugin, par du code branché sur les commandes ou par la base de données, le travail va d'un simple contrôle à une réécriture du connecteur. La règle est de cartographier chaque flux et de le retester sur une copie avant la bascule.
Je suis Pierre-Arthur Demengel, développeur Sylius indépendant, et sur les boutiques que j'ai migrées, les intégrations sont le poste que l'on sous-estime le plus. Elles ne se voient pas dans la boutique, mais une synchronisation de stock qui s'arrête un lundi matin coûte davantage qu'un bouton mal placé.
Pourquoi les intégrations sont-elles concernées par Sylius 2 ?
Parce que trois briques sur lesquelles elles s'appuient ont changé. D'abord l'API : Sylius 2 abandonne API Platform 2.7 pour une version récente, et le guide officiel UPGRADE-API-2.0 liste des adresses modifiées et des réponses enrichies ou allégées. Ensuite la machine à états : la gestion des états de commande, de paiement et d'expédition passe par défaut de winzou/state-machine à Symfony Workflow. Enfin le socle : services privés par défaut, identifiants de services renommés, classes déplacées ou supprimées. Une intégration qui touchait à l'une de ces briques doit être relue.
Comment savoir si votre ERP ou votre CRM est concerné ?
Tout dépend du mode de liaison. Je les range en quatre familles, parce que chacune a sa propre conséquence.
| Mode de liaison | Ce qui change avec Sylius 2 | Ce que je vérifie |
|---|---|---|
| API Sylius appelée par l'outil | Adresses et réponses modifiées, authentification sur des pare-feux renommés | Chaque appel du connecteur, rejoué sur la recette |
| Plugin d'intégration installé dans Sylius | Version compatible Sylius 2 nécessaire | Disponibilité, maintenance et alternative |
| Code maison réagissant aux états de commande | Callbacks winzou à réécrire en écouteurs Symfony Workflow | Chaque transition qui déclenche un envoi |
| Lecture ou écriture directe en base, exports planifiés | Schéma ajusté par la migration Doctrine | Requêtes, colonnes et tables utilisées |
Pour l'API, les changements sont précis. Les lignes de commande se consultent désormais sous la commande, à l'adresse /api/v2/admin/orders/{orderToken}/items/{id}, les prix par canal sous la variante, les images sous le produit, les provinces sous le pays. Côté boutique, la réponse d'une commande n'expose plus son identifiant numérique mais ajoute son état, son canal et l'e-mail du client. Un connecteur qui s'appuyait sur l'ancien format casse silencieusement. Le détail technique est dans l'article sur la migration d'API Platform.
Stocks, commandes, expéditions et retours resteront-ils synchronisés ?
Ils le resteront si chaque déclencheur est retrouvé. En Sylius 2, la réservation du stock à la commande, sa restitution à l'annulation et sa sortie au paiement sont portées par des écouteurs Symfony Workflow, que le guide UPGRADE-2.0 liste parmi les nouveaux services. Beaucoup de boutiques Sylius 1 avaient ajouté leurs propres callbacks winzou sur ces mêmes transitions : envoyer la commande payée à l'ERP, pousser l'expédition au logisticien, mettre à jour le CRM quand un client passe sa première commande. Ces callbacks ne sont plus appelés par défaut. Ils doivent être réécrits, sinon la boutique tourne normalement mais l'ERP ne reçoit plus rien. Je détaille ce passage dans l'article sur la fin de winzou state machine.
Les expéditions suivent la même logique : un numéro de suivi renvoyé par le transporteur passe par l'API ou par un plugin, à vérifier dans les deux cas. Pour les retours, il faut savoir comment ils sont gérés aujourd'hui, car ils reposent le plus souvent sur un plugin ou un développement spécifique, dont la compatibilité se contrôle comme le reste. Le pire scénario n'est pas l'erreur visible, c'est le flux qui s'interrompt sans message.
Quelle méthode pour migrer les intégrations sans casse ?
Cartographier les flux
Pour chaque outil, j'écris une ligne : quelle donnée circule, dans quel sens, à quel moment, par quel moyen, et qui s'en aperçoit si elle s'arrête. Stocks de l'ERP vers Sylius toutes les quinze minutes, commandes payées de Sylius vers l'ERP en temps réel, clients vers le CRM chaque nuit, expéditions vers le logisticien à la validation. Cette carte est plus utile qu'un schéma d'architecture, parce qu'elle nomme les conséquences.
Repérer le code concerné
Je lance Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Il signale les callbacks winzou, les ressources API Platform personnalisées, les plugins sans version 2 et les services appelés par un identifiant disparu. Je recoupe ensuite avec la carte des flux, car un script externe qui interroge la base n'apparaît dans aucun code Sylius.
Tester sur des environnements de test
La recette Sylius 2 se branche sur les environnements de test de l'ERP, du CRM et du logisticien, jamais sur leur production. On y rejoue des commandes réelles de bout en bout : commande, paiement, réservation et sortie de stock, envoi à l'ERP, expédition, retour. Le jour de la bascule, les synchronisations sont suspendues puis relancées dans un ordre défini, comme je l'explique dans l'article sur les commandes en cours pendant la bascule.
Si vous voulez cette carte des flux pour votre boutique avant de lancer quoi que ce soit, elle fait partie du diagnostic de migration offert.
Ce que je vous propose
Je lance l'analyseur sur votre projet, je liste avec vous chaque outil connecté et son mode de liaison, et je vous remets un rapport commenté avec les flux à adapter et une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Les intégrations demandent souvent de coordonner un éditeur ou un logisticien : avec la fin du support de sécurité de Sylius 1.14 le 31 décembre 2026, c'est le poste à identifier en premier.