Lecture : 8 min · Yoan Gwizdala

Audit PrestaShop : ce que je regarde avant de toucher à quoi que ce soit

Personne ne peut chiffrer une migration PrestaShop en regardant la page d'accueil. Le prix d'une migration ne se lit pas sur la vitrine, il se lit dans le back-office et sur le serveur — et c'est exactement ce que fait un audit.

Un audit, ce n'est pas un rapport automatique de trente pages sorti d'un outil en ligne. C'est quelqu'un qui ouvre la boutique, compte ce qu'il y a dedans, et vous dit ce que ça implique. Voici la liste, dans l'ordre où je la parcours.

Ce que je demande pour commencer

• Un accès back-office, sur un profil dédié — pas votre compte personnel.
• Un accès FTP/SFTP ou SSH, en lecture : le back-office ment par omission, le serveur non.
• Un export de la base, ou l'accès pour le faire moi-même.
• Le nom de l'hébergeur et l'offre souscrite.
• La liste, même approximative, des personnes qui ont touché au code depuis la création.

Ce dernier point vaut souvent les quatre autres. « Un développeur nous avait fait un truc pour les stocks en 2019 » est le genre de phrase qui déplace un devis de plusieurs milliers d'euros.

Les douze points

1. La version exacte, au patch près

Pas « une 1.7 » — une 1.7.6.9 ou une 1.7.8.11, ce n'est pas la même histoire. Le numéro de patch dit quels correctifs de sécurité sont passés et lesquels ne sont jamais arrivés.

2. La version de PHP réellement exécutée

Celle que le serveur exécute, pas celle qui est écrite dans le contrat d'hébergement. Et surtout : les versions que l'hébergeur propose encore, et celles qu'il a annoncé retirer. Le calendrier de votre migration est souvent fixé par cette réponse-là, pas par vous.

3. La base de données

Taille, moteur, encodage, tables orphelines laissées par des modules désinstallés. Une base de 12 Go dont 4 en tables de statistiques inutiles change la durée de chaque opération, donc le prix.

4. Les modules

Combien sont installés, combien sont actifs, combien sont encore vendus et maintenus par leur éditeur, et lesquels sont indispensables au chiffre d'affaires. La différence entre le nombre affiché en back-office et le contenu réel du dossier modules/ est toujours instructive.

5. Les overrides et le cœur modifié

Le dossier override/, et surtout les fichiers du cœur modifiés directement — ce qui est la pire pratique et la plus fréquente. On les trouve en comparant les fichiers de la boutique avec l'archive officielle de la même version. Tout ce qui diffère est du code que quelqu'un devra reprendre.

6. Le thème

Thème par défaut, thème enfant propre, thème acheté sur une place de marché, ou création sur mesure ? Est-il encore vendu ? Son auteur publie-t-il encore des versions ? C'est la deuxième ligne la plus lourde d'un devis de migration.

7. Les branchements extérieurs

Webservice ouvert, logiciel de gestion, caisse en magasin, marketplaces, flux Google Shopping, outil d'emailing, transporteurs avec suivi. Chacun est un fil qui part de la boutique et qu'il faudra rebrancher — et tester.

8. La performance

Temps de réponse serveur, cache activé ou non, images non redimensionnées, nombre de requêtes par page. À ce stade je ne cherche pas à optimiser : je cherche à savoir si la lenteur vient de la version, de l'hébergement, ou d'un module qui interroge la base à chaque affichage.

9. Le référencement

Structure des URL, redirections déjà en place, pages réellement indexées, sitemap, balises canoniques, pages de filtres ouvertes à l'indexation. C'est l'état des lieux qui rendra possible la table de correspondance le jour de la migration. Le détail est ici.

10. La sécurité

Correctifs manqués, comptes employés encore actifs après le départ des personnes, mots de passe partagés, page de connexion au back-office laissée à l'adresse par défaut, fichiers d'installation restés sur le serveur, sauvegardes accessibles publiquement. Ça, ça se corrige tout de suite, migration ou pas.

11. Le paiement et les transporteurs

Quel module de paiement, quelle version, encore maintenue ? Ce sont eux qui lâchent en premier sur une vieille boutique, et une boutique qui n'encaisse plus n'est plus une boutique.

12. La réversibilité

Qui possède le nom de domaine, qui a le compte d'hébergement, où sont les licences des modules et du thème, existe-t-il des sauvegardes et ont-elles déjà été restaurées une fois. Cette question n'est pas technique : elle décide de ce que vous pouvez faire si un prestataire — moi compris — disparaît demain.

Ce que l'audit produit

• Un état des lieux écrit, lisible sans être développeur, avec ce qui va, ce qui ne va pas, et ce qui est urgent.
• Une recommandation claire : mettre à jour, migrer sur une installation neuve, refaire, ou attendre.
• Un devis forfaitaire pour la suite, avec ce qui est dedans et ce qui n'y est pas.
• La liste des décisions qui vous appartiennent : racheter la licence d'un module, abandonner une fonctionnalité, changer d'hébergeur.

Le prix de l'audit, je vous le donne avant de commencer, une fois que je sais combien de modules et combien de sur-mesure il y a à regarder. Ce que je ne fais pas : annoncer un montant de migration au téléphone, avant d'avoir ouvert quoi que ce soit.

Un audit peut conclure « ne touchez à rien »

C'est arrivé, et ça arrivera encore. Une boutique en 1.7.8 qui vend correctement, sur un hébergement qui propose encore le PHP qu'elle exige, avec des modules de paiement à jour, peut parfaitement attendre le prochain trimestre — à condition de savoir ce qu'elle attend et combien de temps il reste.

Ce qui n'est jamais raisonnable, c'est de ne pas savoir. Une boutique dont personne ne connaît la version, les modules ni les sauvegardes est un risque, quel que soit son chiffre d'affaires.

Demander un audit de ma boutique

Questions fréquentes

À quoi sert un audit PrestaShop ?

À savoir ce qu'il y a réellement dans la boutique avant d'engager le moindre euro : version exacte, PHP, modules actifs, code sur-mesure, état du référencement et de la sécurité. C'est ce qui permet de donner un prix ferme pour une migration, au lieu d'une fourchette qui doublera en cours de route. C'est aussi ce qui permet de conclure qu'il ne faut rien faire tout de suite.

Faut-il donner un accès administrateur complet ?

Un profil dédié suffit, et c'est même préférable à votre compte personnel : il se supprime en un clic quand le travail est fini. Un accès fichiers en lecture est en revanche indispensable — les overrides et les fichiers du cœur modifiés ne sont visibles que là. Un audit fait uniquement depuis l'extérieur ne voit que la vitrine, et manque précisément ce qui coûte cher.

Un audit est-il nécessaire si je veux juste mettre à jour ?

Il est proportionnel. Sur une 1.7.8 récente avec quelques modules d'éditeurs connus, l'inventaire prend quelques heures et se fond dans le projet. Sur une boutique de dix ans, avec du code écrit par plusieurs prestataires successifs, c'est un travail à part entière — et le sauter revient à signer un devis en espérant qu'il tienne.

Combien de temps prend un audit ?

De quelques heures pour une boutique récente et standard à deux ou trois jours pour une boutique ancienne et très personnalisée. Ce qui prend du temps n'est pas de lister les modules, c'est de comprendre ce que fait le code sur-mesure et d'estimer honnêtement ce qu'il coûtera à reprendre.

Que contient le rapport ?

Un état des lieux écrit en français lisible, une recommandation argumentée, un devis forfaitaire pour la suite, et la liste des décisions qui vous reviennent — racheter une licence, abandonner un module, changer d'hébergeur. Le rapport vous appartient : si vous le faites exécuter par quelqu'un d'autre, il reste utilisable.

Peut-on auditer une boutique qui a déjà un prestataire ?

Oui, et c'est fréquent avant une reprise ou pour obtenir un deuxième avis. Je regarde l'état de la boutique, pas le travail d'un confrère : mon rapport dit ce qui est, pas ce qui aurait dû être. Il faut simplement que vous ayez le droit de donner les accès, ce qui est le cas si la boutique et l'hébergement sont à votre nom.