Rédigé par Rédaction CyberSDF / 17 septembre 2026

Développement web open source : PHP, MySQL et Laravel

Verdict : PHP, MySQL et Laravel forment une pile cohérente pour un service que vous voulez comprendre et maintenir vous-même. PHP exécute le code côté serveur, MySQL organise les données et Laravel apporte des conventions. La limite tient au suivi des versions, des dépendances et des sauvegardes.

Au 17 septembre 2026, j’ai compté quatre branches dans la table officielle des versions PHP supportées : 8.2, 8.3, 8.4 et 8.5. Ce relevé donne un filtre concret : reprendre une application ancienne ne consiste pas à changer le nom du langage, il faut aussi vérifier ses extensions, ses dépendances et sa base de données.

Si votre hésitation porte d’abord sur le coût, les formats ou la possibilité de sortir d’un outil, commencez par la grille pour choisir un logiciel. Ici, le sujet est plus précis : comprendre ce que chaque couche prend en charge avant de construire.

Open source désigne des droits, pas seulement un téléchargement gratuit

Un logiciel open source ne se définit pas par son prix affiché. L’Open Source Definition de l’OSI énumère dix critères, dont l’accès au code source, la possibilité de créer des versions dérivées et la redistribution sans redevance obligatoire. La licence indique donc ce que vous pouvez étudier, modifier et partager ; l’hébergement, le support, le temps de maintenance et les services autour du logiciel peuvent, eux, être payants.

Avant de cloner un dépôt ou d’installer un paquet, cherchez son fichier de licence et la version exacte concernée. Un code visible sans droits de modification clairement accordés n’est pas automatiquement open source. À l’inverse, une licence permissive ou copyleft ne promet ni documentation parfaite ni application exempte de défauts.

Le code ouvert vous donne des droits de contrôle, pas une maintenance gratuite.

PHP, MySQL et Laravel ne jouent pas le même rôle

Le critère technique à regarder avant de comparer des noms est simple : quelle couche produit le résultat, quelle couche conserve les données et quelle couche organise le projet ? PHP, MySQL et Laravel ne sont pas trois concurrents. Ils peuvent former une pile, avec des responsabilités différentes.

Une page statique peut fonctionner sans base de données. Une application qui enregistre des utilisateurs ou des commandes ne devrait pas traiter ses données comme une collection de fichiers dispersés. Un framework ne remplace pas PHP et ne stocke pas lui-même vos données : il encadre le code qui les manipule.

PHP exécute, MySQL conserve et Laravel structure : les choisir ensemble commence par séparer ces trois responsabilités.

Quand PHP seul suffit, et quand Laravel paie sa complexité

Pour une petite interface, un script d’import ou un service avec peu de routes, PHP sans framework peut rester le choix le plus lisible. Vous contrôlez le cycle de la requête, les fichiers et les dépendances. Le prix à payer est ailleurs : il faut décider vous-même de l’organisation, de la validation des entrées, de la gestion des erreurs et de la stratégie de test.

Laravel devient intéressant lorsque la répétition de ces décisions ralentit le projet. Sa documentation d’installation prévoit PHP, Composer et l’installateur Laravel, puis décrit un chemin d’application full-stack ou de backend d’API. Les migrations, les routes, la configuration par environnement et la couche d’accès aux données donnent alors un langage commun à l’équipe.

Cette structure a une contrepartie : il faut suivre le framework, ses paquets et la version de PHP attendue. Avant de démarrer, lisez la documentation officielle d’installation Laravel, notez les versions réellement proposées et choisissez une base que votre hébergement saura maintenir.

Choisissez Laravel pour réduire les décisions répétées, pas pour donner à une petite page une architecture qu’elle n’exige pas.

MySQL devient le contrat des données

La base de données mérite une décision séparée du choix du framework. Définissez les entités, leurs relations, les champs obligatoires, les index et la manière de restaurer une sauvegarde. Une migration versionnée décrit l’évolution du schéma ; elle ne remplace pas une sauvegarde et ne prouve pas qu’une restauration a réussi.

La page officielle de MySQL Community Edition la présente comme une version téléchargeable sous licence GPL et décrit des fonctions SQL et NoSQL ainsi que plusieurs moteurs de stockage. Vérifiez toutefois l’édition que vous utilisez, le contrat de l’hébergeur et la version réellement installée : le mot MySQL ne suffit pas à décrire les conditions d’un service géré.

Pour faire un premier état de la machine ou d’un projet existant, relevez les versions sans les confondre avec une validation complète :

php -v
composer --version
mysql --version

Conservez ensuite le résultat avec la liste des extensions PHP, des paquets Composer et des moteurs de tables utilisés. C’est cette combinaison qui permet de préparer une mise à jour ou un changement d’hébergeur, pas la seule présence d’un nom connu.

Une pile ouverte reste un système à entretenir

La liberté de lire le code ne dispense pas de surveiller les avis de sécurité, les branches supportées, les dépendances transitives, les droits des comptes de base et la restauration des sauvegardes. Décidez qui lit les journaux, qui applique les mises à jour et comment vous revenez à une version précédente si une extension casse le service.

La table PHP rappelle que le support actif et les correctifs de sécurité n’ont pas la même durée. Utilisez-la avec le fichier de verrouillage de votre projet et les notes de version du framework. Une branche encore installée n’est pas forcément une branche encore corrigée.

Le navigateur et l’interface méritent aussi leur propre contrôle. Si votre application produit du HTML et du CSS, vérifiez leur structure et leur usage avec la page Standards du Web, HTML, CSS et validation, au lieu de demander à PHP ou à MySQL de répondre à une question de présentation.

Une pile durable est une pile dont les versions, les données et le retour arrière ont un propriétaire clair.

Le bon premier choix est celui qui reste réversible

Écrivez d’abord le résultat attendu : publier, enregistrer, chercher, exposer une API ou automatiser un traitement. Listez les données à conserver et les personnes qui devront intervenir dans six mois. Puis choisissez la plus petite combinaison qui couvre ce besoin, en gardant le code, le schéma et les fichiers de déploiement dans un format que vous pouvez relire.

Pour un projet existant, commencez par l’inventaire des versions et des dépendances avant d’ajouter Laravel ou de changer MySQL. Pour un projet neuf, un petit prototype qui crée une donnée, la relit et la sauvegarde vaut mieux qu’une pile complète installée par habitude. Le choix reste solide quand vous pouvez expliquer ce que chaque couche fait et comment vous en sortez.

Le meilleur choix open source n’est pas le plus vaste : c’est celui dont vous pouvez comprendre le code, protéger les données et organiser la maintenance.