Méthode
PHP et Drupal : moderniser sans tout réécrire
Un site PHP ou Drupal peut avoir besoin d’évoluer sans que tout son contenu, ses parcours et ses intégrations soient à remplacer. Avant de parler de refonte, il faut comprendre ce qui fonctionne, ce qui expose le site à un risque et ce que les utilisateurs attendent réellement. Voici une méthode de cadrage, pas le récit d’une mission client.
Commencer par les usages et les dépendances
Quels formulaires doivent continuer à fonctionner ? Qui publie les contenus ? Quels échanges avec le CRM, les outils métiers ou le moteur de recherche sont indispensables ? Cet inventaire permet de définir ce qu’une évolution doit préserver et ce qu’elle doit améliorer.
Côté technique, relever les versions de PHP, du cœur Drupal, des modules et des bibliothèques, puis vérifier leur compatibilité et leur maintenance. Le calendrier dépend de cet état des lieux : une mise à jour de maintenance et une migration majeure ne se traitent pas comme le même chantier. Une réécriture peut se justifier ; elle doit résulter du diagnostic, pas d’un réflexe.
En PHP, rendre les contrats du code plus explicites
PHP permet de déclarer les types des paramètres et des valeurs de retour. Ces déclarations rendent les attentes d’une fonction plus lisibles et permettent de détecter certaines incohérences à l’exécution. Elles ne remplacent ni la validation des données reçues ni les tests du comportement métier.
Pour un code existant, mieux vaut choisir un périmètre limité : un formulaire, un traitement ou une intégration. Comprendre son comportement, écrire les vérifications utiles, puis clarifier ses interfaces évite d’élargir inutilement une première intervention.
Avec Drupal, suivre le code et la configuration
Le code ne décrit pas tout un site Drupal. La configuration participe aussi à son fonctionnement. La documentation officielle prévoit de versionner la configuration exportée et le fichier composer.lock, puis de reconstruire les dépendances et d’appliquer les mises à jour et la configuration lors du déploiement.
Cette distinction compte : livrer les fichiers PHP en oubliant une modification de configuration peut laisser deux environnements dans des états différents. Il faut donc documenter les étapes et les vérifier sur un environnement de préproduction avant la mise en ligne.
Définir un premier lot que l’on peut vérifier
Un premier lot utile peut être la correction d’un parcours de candidature, la remise à niveau d’un module ou la simplification de la publication d’un contenu. Pour chaque lot, préciser les critères de réussite, les tests, la sauvegarde nécessaire et la marche à suivre si la mise en ligne échoue.
Comparer ensuite le résultat aux usages recensés : contenus accessibles, formulaires utilisables au clavier, droits cohérents et échanges avec les autres systèmes préservés. Une modernisation se juge sur ces comportements, pas seulement sur une liste de fichiers modifiés.
Construire cette expertise chez Popixa
Popixa est en construction et ouvre une recherche de développeur PHP / Drupal. Nous souhaitons bâtir cette activité avec des personnes qui aiment comprendre un existant, expliquer leurs choix et travailler avec des missions claires. Les conditions de collaboration seront discutées ensemble.