Brancher une app Symfony sur une base PrestaShop, sans tout casser

De plus en plus, on construit un outil Symfony à côté d'une boutique PrestaShop : portail client, tableau de bord métier, passerelle vers un ERP. Première question qui tombe à chaque fois : comment lire les données de la boutique sans dupliquer la logique ni risquer de corrompre la base ?

Une connexion DBAL dédiée, en lecture seule

On n'ajoute aucune entité Doctrine sur la base PrestaShop. On déclare juste une seconde connexion DBAL, qu'on traite comme une source en lecture seule.

# config/packages/doctrine.yaml
doctrine:
    dbal:
        connections:
            prestashop:
                url: '%env(PRESTASHOP_DATABASE_URL)%'
                # Aucune entité mappée ici : lecture seule par convention.

Requêter proprement

On injecte la connexion par son nom et on requête avec des paramètres liés — jamais de concaténation.

use Doctrine\DBAL\Connection;
use Symfony\Component\DependencyInjection\Attribute\Autowire;

final class PrestashopStats
{
    public function __construct(
        #[Autowire(service: 'doctrine.dbal.prestashop_connection')]
        private readonly Connection $ps,
    ) {}

    public function countValidOrders(int $idShop = 1): int
    {
        return (int) $this->ps->fetchOne(
            'SELECT COUNT(*) FROM ps_orders WHERE valid = 1 AND id_shop = ?',
            [$idShop],
        );
    }
}

Les pièges

• Le préfixe (ps_) n'est pas garanti : récupérez-le depuis la config plutôt que de le coder en dur si vous distribuez le code.
• Le multiboutique : filtrez toujours sur id_shop, sinon vous additionnez les boutiques sans le savoir.
• L'écriture : pour modifier la boutique, passez par le webservice PrestaShop ou un module dédié — écrire en SQL direct contourne les hooks et casse les invalidations de cache.

Bien cadré, ce pont vous donne le meilleur des deux mondes : la robustesse de Symfony pour vos outils métier, sans toucher au cœur de la boutique.