Pourquoi mysql_* en PHP est un mal : analyse complète avec exemples

Histoire d'une erreur : pourquoi mysql_* est une relique du passé

Imaginez : vous écrivez un site en PHP, vous vous connectez à une base de données MySQL et vous utilisez la fonction familière depuis l'université mysql_query(). Tout fonctionne, le site vit, les utilisateurs sont satisfaits. Mais un jour, vous remarquez un étrange avertissement dans les logs : « Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future ». Ce n'est pas simplement une plainte de l'interpréteur — c'est un drapeau rouge à ne pas ignorer.

Sur Stack Overflow, la question « Why shouldn't I use mysql_* functions in PHP? » a rassemblé des milliers de vues et des centaines de commentaires. Et ce n'est pas un hasard. Dans cet article, nous allons comprendre pourquoi les fonctions mysql_* (mysql_connect, mysql_query, mysql_fetch_array et autres) sont devenues l'ennemi numéro un des développeurs PHP, montrer avec des exemples de code réels par quoi les remplacer, et donner un plan de migration étape par étape.

Qu'est-ce que mysql_* et pourquoi ont-elles été supprimées ?

L'extension mysql_* (MySQL original) est apparue dans PHP 2.0 en 1997. Elle était simple et intuitive : on appelait mysql_connect(), on exécutait une requête via mysql_query(), on obtenait un résultat. Mais cette simplicité avait un côté obscur.

À partir de PHP 5.5.0, toutes les fonctions mysql_* ont été marquées comme obsolètes (deprecated), et dans PHP 7.0, elles ont été complètement supprimées. Si vous essayez d'utiliser mysql_connect() sur PHP 7+, vous obtiendrez une erreur fatale : Call to undefined function mysql_connect(). La raison n'est pas un caprice des développeurs de PHP, mais des problèmes fondamentaux de sécurité et d'architecture.

Trois raisons principales d'abandonner mysql_*

\n
• Injections SQL sans protection — les fonctions ne supportent pas les requêtes préparées (prepared statements), ce qui rend l'échappement manuel obligatoire, mais souvent oublié.
\n
• Architecture obsolète — pas de support du style orienté objet, des procédures stockées, des requêtes multiples et des transactions.
\n
• Absence d'évolution — l'extension n'a pas été mise à jour depuis des années, tandis que MySQL évoluait (par exemple, nouveaux types de données, encodages, mécanismes d'authentification).
\n

Exemple concret : comment mysql_* tue votre site

Regardons le code classique que l'on trouve encore dans les vieux tutoriels et forums :

<?php\n// CODE OBSOLÈTE - NE PAS UTILISER !\n$link = mysql_connect('localhost', 'root', 'password');\nmysql_select_db('users_db', $link);\n\n$user_input = $_GET['username']; // l'utilisateur saisit : ' OR 1=1 --\n$query = "SELECT * FROM users WHERE username = '$user_input'";\n$result = mysql_query($query, $link);\n\nwhile ($row = mysql_fetch_assoc($result)) {\n    echo "Bonjour, " . $row['username'] . "<br>";\n}\n?>

Quel est le problème ? Si un attaquant transmet dans le paramètre username la valeur ' OR 1=1 --, la requête devient :

SELECT * FROM users WHERE username = '' OR 1=1 --

Le double tiret -- commente le reste de la requête, et la condition 1=1 est toujours vraie. En conséquence, vous obtenez tous les utilisateurs de la base de données, y compris les mots de passe, les emails et autres informations confidentielles. Ce n'est pas de la théorie — c'est une vulnérabilité réelle qui casse des milliers de sites chaque jour.

Bien sûr, on peut utiliser mysql_real_escape_string(), mais :

\n
• Les développeurs oublient souvent de l'appeler.
\n
• Il ne protège pas contre tous les types d'attaques (par exemple, les attaques utilisant les encodages).
\n
• Le code devient sale et difficile à lire.
\n

Par quoi remplacer mysql_* : deux approches modernes

Dans le PHP moderne, il existe deux extensions dignes pour travailler avec MySQL : mysqli (MySQL Improved) et PDO (PHP Data Objects). Les deux supp