Sylius 2 : comment ne pas dépendre d'un prestataire ?

Pour ne pas devenir dépendant d'un prestataire sur Sylius 2, il faut exiger trois choses dès le début de la migration : détenir vous-même le code, les accès et les comptes ; obtenir une documentation et des tests qui permettent à n'importe quel développeur Sylius de reprendre le projet ; et demander des adaptations qui suivent les mécanismes standard de Sylius 2 plutôt que des contournements maison. La migration est le meilleur moment pour poser ces règles, parce que presque tout le code personnalisé est de toute façon repris.

Je suis développeur Sylius indépendant, et je reprends des projets écrits par d'autres. Je vois vite la différence entre une boutique qu'on peut confier à quelqu'un d'autre en quelques jours et une boutique dont un seul prestataire détient les clés. Voici ce qui fait cette différence, y compris si vous travaillez avec moi.

D'où vient la dépendance à un prestataire Sylius ?

Rarement d'une mauvaise intention. Elle s'installe par accumulation : un dépôt de code hébergé sur le compte du prestataire, un serveur à son nom, des personnalisations que lui seul sait expliquer, aucune documentation et aucun test. Au bout de quelques années, changer de prestataire signifie redécouvrir le projet à tâtons, et personne n'ose le faire.

La migration vers Sylius 2 accentue le problème ou le règle. Le guide officiel UPGRADE-2.0 remplace l'interface, les gabarits, la machine à états des commandes, la couche API et l'envoi des e-mails. Si ces reprises sont faites sans méthode, la dépendance augmente. Si elles sont faites proprement, vous en sortez avec un projet plus lisible qu'avant.

Quels accès et quels droits garder pour vous ?

Commencez par la base, qui ne demande aucune compétence technique. Le dépôt de code doit être sur un compte de votre entreprise, avec le prestataire invité, et non l'inverse. L'hébergement, le nom de domaine, les comptes de paiement et les outils de mesure doivent être à votre nom. Les mots de passe et clés d'accès doivent être stockés dans un coffre que vous contrôlez.

Vérifiez ensuite le contrat. Il doit préciser à qui appartiennent les droits sur le code développé pour vous et prévoir une remise complète du projet en fin de mission. Si vous travaillez aujourd'hui avec une agence, l'article sur la migration quand on dépend d'une agence externe détaille les questions à poser avant de lancer le chantier.

Comment faire des adaptations Sylius 2 que d'autres pourront reprendre ?

Rester proche des mécanismes standard

Sylius 2 apporte des points d'extension officiels. Les Twig Hooks permettent d'ajouter ou de remplacer un morceau d'écran sans copier le gabarit entier. Symfony Workflow décrit les étapes d'une commande dans une configuration lisible. Une adaptation qui utilise ces mécanismes se comprend en lisant la documentation de Sylius. Une adaptation qui les contourne ne se comprend qu'en appelant son auteur. Je montre la méthode dans le guide pratique des Twig Hooks.

Isoler le code métier

Le code qui fait la spécificité de votre boutique, vos règles de prix, vos exports vers l'ERP, vos étapes de commande particulières, doit être rangé dans des classes ou des plugins clairement nommés, séparés du reste. Un développeur qui arrive sait alors où chercher, et une future montée de version touche moins de fichiers.

Préférer des plugins maintenus

Chaque plugin abandonné vous lie à celui qui sait encore le faire tourner. Pendant la migration, c'est le moment de remplacer ceux qui n'ont pas de version compatible par une solution maintenue, ou de reprendre leur code dans votre dépôt. La méthode est dans l'article sur les plugins compatibles Sylius 2.

Pourquoi la documentation et les tests vous rendent libre ?

Un projet documenté se reprend en jours, un projet muet en semaines. Il n'est pas question de rédiger un roman : un fichier qui explique comment installer le projet en local, la liste des personnalisations et de leurs raisons, et la procédure de mise en production suffisent à changer la donne.

Les tests jouent le même rôle. La documentation de Symfony recommande dans ses bonnes pratiques de vérifier automatiquement que chaque URL importante répond, ce qu'elle appelle des smoke tests. C'est peu coûteux à écrire et cela donne à n'importe quel développeur un filet de sécurité dès son premier jour sur votre projet. Demandez que la migration en laisse au moins sur vos parcours qui rapportent de l'argent : catalogue, panier, paiement, compte client.

Si vous voulez savoir où en est votre projet sur ces points avant de choisir comment migrer, le diagnostic de migration offert vous donne une première image, avec une estimation en jours.

Comment garder la main sur l'estimation et le suivi ?

La dépendance la plus coûteuse est celle de l'information : vous ne savez pas ce qu'il reste à faire, donc vous ne pouvez pas comparer. C'est l'une des raisons pour lesquelles j'ai publié Sylius Upgrade Analyzer en open source, sous licence MIT, sur GitHub et sur le Sylius Store. Votre responsable technique peut l'installer et l'exécuter lui-même, sans moi. Il obtient un rapport en Markdown ou en PDF qui liste les points incompatibles avec Sylius 2 et une estimation en heures par problème.

Ce rapport devient une référence partagée. Vous pouvez le relancer en cours de chantier pour voir ce qui reste, le transmettre à un autre prestataire ou l'utiliser pour discuter d'un devis. La migration ne s'arrête d'ailleurs pas à la 2.0 : selon le cycle de publication de Sylius, les versions mineures de Sylius 2 ont chacune leur propre durée de support. Une boutique qui suit ce rythme avec un code standard reste facile à confier à quelqu'un d'autre.

Ce que je vous propose

Je mène les migrations avec une règle simple : à la fin, vous détenez tout, et un autre développeur Sylius peut reprendre le projet sans m'appeler. Le point de départ est un diagnostic offert : je lance Sylius Upgrade Analyzer sur votre code et je vous remets un rapport commenté, avec une estimation en jours. Il vous appartient, quelle que soit la suite. Avec la fin des correctifs de sécurité de Sylius 1.14 au 31 décembre 2026, c'est aussi le moment de reprendre la main.