Prestataire migration Sylius 2 : comment choisir
Pour choisir un prestataire de migration vers Sylius 2, exigez d'abord un inventaire écrit de votre projet, puis comparez les candidats sur trois points : des montées de version 1.x vers 2.x déjà livrées en production, une méthode découpée en étapes vérifiables, et un plan de bascule sans coupure de vente. Le statut, la taille de la structure et le prix journalier viennent après. Un bon prestataire sait vous dire ce qu'il ne sait pas encore et comment il va le découvrir.
Je suis développeur Sylius et Symfony indépendant à Metz. J'ai déjà mené des montées de version Sylius 1.x vers 2.x de boutiques en production pour mes clients, et j'ai créé un outil open source qui audite ces migrations. Voici la grille que je conseillerais à un dirigeant qui ne veut pas se tromper, y compris si au final il ne travaille pas avec moi.
Pourquoi le choix du prestataire est-il si risqué sur cette migration ?
Parce que le passage de 1.14 à 2.0 n'est pas une mise à jour mais une refonte partielle. Le guide officiel UPGRADE-2.0 liste le remplacement de Semantic UI et jQuery par Bootstrap 5 et Symfony UX, la suppression des template events au profit des Twig Hooks, le passage de winzou à Symfony Workflow, l'arrivée des Payment Requests, le saut d'API Platform 2.7 à la version 4 et la disparition de FOSRest et JMS Serializer. Chaque personnalisation de votre boutique est potentiellement touchée.
Il n'existe pas non plus de raccourci automatique pour le cœur : sylius/sylius-rector ne propose pas de jeu de règles pour migrer une application 1.14 vers 2.0. Le travail dépend donc de l'expérience du développeur. Et le calendrier ne laisse pas beaucoup de marge : selon le cycle de versions publié par Sylius, la 1.14 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Un mauvais choix de prestataire coûte des mois, et ces mois se passent sans filet.
Quelles questions poser à un prestataire avant de lui confier la migration ?
Sur son expérience réelle
Demandez combien de montées de version 1.x vers 2.x il a livrées en production, pas en démonstration. Demandez vers quelle version cible : un projet arrivé en 2.0 et laissé là n'a pas la même valeur qu'un projet porté jusqu'à une branche encore maintenue. Demandez enfin quelle a été la difficulté principale du dernier chantier. Quelqu'un qui l'a vécu vous répondra tout de suite, avec un exemple précis sur les gabarits, le paiement ou l'API.
Sur sa méthode
Le chemin officiel est connu : monter en 1.14, supprimer les dépréciations, passer en 2.0, puis suivre les fichiers UPGRADE jusqu'à la cible. Demandez comment il l'applique chez vous. Où s'arrête la phase d'audit ? Que fait-il de chaque plugin tiers ? Comment traite-t-il vos surcharges de gabarits ? Comment migre-t-il les machines à états winzou personnalisées ? Je détaille ces points dans la checklist d'audit en 49 points.
Sur la bascule et l'après
Posez trois questions simples. Comment se passe la mise en production, et combien de temps la boutique est-elle indisponible ? Comment revient-on en arrière si un problème apparaît le jour J ? Qui corrige les anomalies dans les semaines qui suivent, et dans quel délai ? Une réponse floue ici est plus inquiétante qu'un tarif élevé. La méthode de bascule est détaillée dans l'article sur la mise en production sans coupure.
Quelles preuves exiger plutôt que des promesses ?
Un logo de client ou une mention sur une page de partenaires ne prouve pas qu'une migration a été menée. Les preuves utiles sont vérifiables. Un livrable d'audit anonymisé montre comment il inventorie un projet. Un projet public ou une étude de cas documentée montre qu'il a livré quelque chose de réel. Du code public, comme une contribution ou un plugin, montre sa façon d'écrire du PHP. Un échange technique de trente minutes avec votre développeur actuel montre s'il comprend votre existant.
Pour être transparent sur les miennes : les noms des boutiques que j'ai migrées restent confidentiels, mais vous pouvez consulter le projet public de la boutique Coucouroucoucou, avec la reprise d'environ 15 000 commandes et 14 écrans d'administration sur mesure (nouvelle version en recette), ainsi que le code de Sylius Upgrade Analyzer, publié sous licence MIT.
Agence, freelance, équipe interne ou audit officiel Sylius : que choisir ?
Aucune option n'est bonne dans l'absolu. Le bon choix dépend de la taille de votre projet, de vos équipes et de qui assurera la maintenance ensuite.
| Option | Points forts | Limites | Adaptée quand |
|---|---|---|---|
| Agence Sylius | Plusieurs profils, capacité à absorber un gros périmètre, continuité en cas d'absence | Interlocuteur qui change parfois entre la vente et le développement, coûts de structure | Projet large avec front, back et intégrations ERP à mener en parallèle |
| Développeur indépendant spécialisé | Un seul interlocuteur qui code, décisions rapides, connaissance fine du sujet | Capacité limitée, dépendance à une personne si rien n'est documenté | Boutique de taille moyenne, ou renfort d'une équipe existante sur la partie délicate |
| Équipe interne | Connaissance du métier et du code, pas de transfert de connaissances | Migration menée en plus du quotidien, souvent sans expérience préalable de la 2.x | Équipe déjà solide en Symfony, avec du temps réellement libéré |
| Audit officiel Sylius | Regard de l'éditeur, référence sur le cœur du framework | Ni prix ni délai publiés, l'exécution reste à organiser | Projet critique où vous voulez un avis de l'éditeur avant de choisir qui exécute |
L'éditeur propose en effet un « Migration audit » sur sa page de services, sans tarif ni durée affichés. Les combinaisons fonctionnent bien : un audit externe puis une exécution par l'équipe interne, ou un indépendant qui traite le cœur de la migration pendant que l'agence historique garde la maintenance.
Quels signaux d'alerte doivent vous faire fuir ?
Un devis forfaitaire ferme rendu sans avoir lu une ligne de votre code. Personne ne peut chiffrer sérieusement une migration 1.x vers 2.x sans connaître vos surcharges, vos plugins et votre version de départ.
Une promesse de migration « automatique ». Les outils accélèrent l'inventaire et certaines corrections, mais le front et les intégrations de paiement demandent du travail humain.
L'absence de version cible. Un prestataire qui vise la 2.0 sans en parler vous fait migrer vers une branche dont le support de sécurité a pris fin le 28 février 2026.
Aucune mention des plugins tiers. Ce sont souvent eux qui bloquent : certains n'ont pas de version compatible et doivent être remplacés ou réécrits. Voyez à ce sujet le guide de vérification des plugins.
Aucun plan de retour arrière, aucune recette sur une copie de production, aucune question sur votre référencement. Enfin, le refus de vous remettre le code et les accès au fil du projet. Votre boutique doit rester à vous, quoi qu'il arrive au prestataire.
Que doit contenir un bon devis de migration vers Sylius 2 ?
Un bon devis ressemble moins à un montant qu'à un plan. Voici les lignes que j'attends d'un document sérieux, et ce qu'elles vous permettent de vérifier.
| Élément du devis | Ce qu'il doit préciser | Ce qu'il vous évite |
|---|---|---|
| Point de départ et version cible | Votre version actuelle, la branche visée et sa date de fin de support | Une migration vers une version déjà en fin de vie |
| Inventaire | Gabarits surchargés, plugins tiers, machines à états, API, passerelles de paiement | Les découvertes en cours de route facturées en plus |
| Lots chiffrés en jours | Montée en 1.14, nettoyage des dépréciations, cœur 2.x, front, paiement, API | Un forfait opaque impossible à contrôler |
| Hypothèses et exclusions | Ce qui n'est pas compris, par exemple une refonte graphique | Les désaccords sur le périmètre à mi-projet |
| Recette | Tests du tunnel de commande, de l'administration et des emails sur une copie | Les régressions découvertes par vos clients |
| Bascule et retour arrière | Date, fenêtre, sauvegarde, procédure de retour | Une coupure de vente non maîtrisée |
| Garantie et suite | Durée de correction après mise en ligne, maintenance proposée | Un prestataire injoignable une fois le projet payé |
Si deux devis n'ont pas le même inventaire, ne les comparez pas encore. Demandez à chacun de partir de la même liste. L'estimation en jours se construit d'ailleurs à partir de cet inventaire, comme je l'explique dans l'article sur la durée d'une migration Sylius 2.
Comment obtenir un inventaire fiable avant de comparer les devis ?
C'est précisément pour cela que j'ai créé Sylius Upgrade Analyzer. Cet outil en ligne de commande s'exécute en local sur votre projet, sans envoyer votre code ailleurs. Ses 49 analyseurs couvrent les gabarits, les dépréciations, les plugins, les grilles et API Platform. Il vérifie vos plugins sur le Sylius Store et Packagist, propose plus de 40 corrections automatiques avec un niveau de confiance, et exporte un rapport en Markdown, JSON, CSV ou SARIF. Votre développeur peut le lancer lui-même ; le rapport devient alors la base commune que vous transmettez à chaque prestataire.
Il ne remplace pas un prestataire : il ne prend pas les arbitrages métier, ne teste pas vos paiements et ne pilote pas la bascule. Mais il rend les devis comparables et les promesses vérifiables.
Si vous préférez que je m'en charge, je lance l'analyse sur votre projet et je vous remets un diagnostic offert : inventaire, points bloquants, version cible conseillée et estimation en jours. Vous pourrez le comparer aux devis reçus et choisir en connaissance de cause, avec moi ou avec un autre prestataire.