Ce que les sites anciens traînent encore avec eux : repères pour avancer
Comme évoqué dans « Moderniser un projet Dreamweaver : comprendre avant d’agir« , Dreamweaver a longtemps permis de créer rapidement des sites complets grâce à des outils intégrés et des méthodes qui, à l’époque, répondaient aux usages du web. Ce qui était un gain de temps est devenu un frein. Certaines approches ne sont plus reconnues par les standards actuels, d’autres posent des problèmes de sécurité, et quelques-unes bloquent toute évolution sans remise à plat.
Dans cet article, on va revenir sur certains de ces points devenus problématiques :
- Des automatismes devenus des impasses : les comportements serveur encore fondés sur l’ancien connecteur MySQL natif
- PHP 5.6, entre faux confort et vrais risques : l’emploi généralisé de PHP 5.6 dans les anciennes versions de Dreamweaver
- Sécurité d’un site moderne, repartir sur une base saine : la version de PHP n’est pas le seul enjeu : toute la logique des échanges client/serveur doit être repensée
- Mise en page en tableau, entre héritage et verrou : l’affichage non optimisé sur les appareils mobiles, en particulier lorsque la mise en page repose encore sur des tableaux
- L’accessibilité web, dépasser l’héritage limité de Dreamweaver : une approche longtemps réduite à
alt, bien loin des normes actuelles - Abandon de Flash, nettoyer les vestiges invisibles : la présence éventuelle de contenus en Flash, désormais bloqués par tous les navigateurs et officiellement abandonnés
Ces héritages techniques ne sont pas des fautes, mais des reliques. Les corriger, ce n’est pas repartir de zéro : c’est permettre à un projet de se maintenir, d’évoluer et de retrouver sa marge de manœuvre dans un écosystème qui, lui, a continué d’avancer.
Des automatismes devenus des impasses
Pendant des années, Dreamweaver a offert aux développeurs une interface visuelle pour intégrer rapidement des fonctions serveur. Il suffisait d’ouvrir une boîte de dialogue, de renseigner les champs, et le code se générait tout seul : connexion à la base de données, insertion d’un enregistrement, mise à jour ou suppression. C’était pratique, rapide, et à l’époque, largement utilisé.
Ces fonctions, appelées comportements serveur (Server Behaviors – À propos des comportements de serveur personnalisés), s’appuyaient sur une logique rudimentaire mais efficace : une couche de scripts PHP générés automatiquement, construits autour d’un connecteur MySQL natif, sans passer par une couche d’abstraction. On retrouvait ainsi des blocs de code du type :
$hostname_conn = "localhost";
$database_conn = "ma_base";
$username_conn = "root";
$password_conn = "root";
$conn = mysql_connect($hostname_conn, $username_conn, $password_conn) or trigger_error(mysql_error(),E_USER_ERROR);Ce code était placé dans un fichier annexe (souvent Connections/conn.php) et appelé partout dans le site. Le reste s’enchaînait avec des requêtes directement injectées via mysql_query() :
mysql_select_db( $database_conn, $conn );
$query_datas = "SELECT * FROM datatable WHERE statut = 'actif'";
$datas = mysql_query( $query_datas, $conn ) or die( mysql_error() );
$row_datas = mysql_fetch_assoc( $datas );
$totalRows_datas = mysql_num_rows( $datas );À l’époque, cela faisait le travail. Mais aujourd’hui, cette méthode soulève plusieurs problèmes graves :
mysql_connect()** etmysql_query()sont supprimés depuis PHP 7**. Ce code ne fonctionne plus du tout sur un serveur à jour.- Aucune protection contre les injections SQL. La variable utilisateur est injectée directement dans la requête, sans filtre ni vérification.
- Séparation faible entre logique, données et affichage : le code PHP était souvent injecté directement au cœur de la page HTML, sans réelle distinction entre les appels à la base et leur restitution à l’écran, ce qui complique toute maintenance.
Le connecteur mysql_*, utilisé dans tous ces scripts, a été officiellement déclaré obsolète dès PHP 5.5, puis retiré complètement en PHP 7. Sa logique était trop basique : pas de support des connexions persistantes, aucune gestion native des jeux de caractères, et surtout aucun mécanisme intégré pour sécuriser les requêtes. Cette API ne permettait ni requêtes préparées, ni traitement propre des erreurs. Elle a donc été remplacée par deux alternatives modernes : mysqli (plus souple, mais encore assez proche de l’ancien modèle) et PDO, qui permet une gestion propre et unifiée des connexions, des requêtes, et de la sécurité. Why shouldn’t I use mysql_* functions in PHP?.
Cerise sur le gâteau, Dreamweaver ne propose plus ces comportements dans les versions récentes. Le panneau est désactivé, certaines extensions ne sont plus compatibles, et les projets qui reposent encore sur ce système sont bloqués dans le temps. Les situations concrètes où ces comportements ont été utilisés sont nombreuses et parfois très imbriquées. À tel point qu’un article unique ne suffirait sans doute pas à en couvrir toutes les déclinaisons.
Il ne s’agit pas simplement de réécrire une ligne de code. Il faut changer de modèle. Aujourd’hui, on travaille avec des solutions comme PDO ou MySQLi, on prépare les requêtes, on échappe les données, et surtout, on ne confie plus au logiciel la charge de générer des couches serveur invisibles. On sait ce que le code fait, on peut le relire, le modifier, et le maintenir.
Pour entamer cette transition
Il est conseillé de reprendre chaque fonction serveur (insertion, mise à jour, suppression, recherche), et de les réécrire à la main avec mysqli ou PDO. Mieux vaut commencer par une seule page, isoler le comportement souhaité, et reconstruire le code en utilisant une requête préparée. L’interface graphique ne fonctionnera plus : il faudra désormais écrire soi-même les connexions et les requêtes.
Voici un extrait de code ancien généré par Dreamweaver :
$insertSQL = sprintf("INSERT INTO users (name, email) VALUES ('%s', '%s')",
$_POST['name'], $_POST['email']);
mysql_query($insertSQL)Et son équivalent modernisé avec mysqli :
$conn = new mysqli("localhost", "root", "root", "ma_base");
$stmt = $conn->prepare("INSERT INTO users (name, email) VALUES (?, ?)");
$stmt->bind_param("ss", $_POST['name'], $_POST['email']);
$stmt->execute();
$stmt->close();
$conn->close();Ce n’est pas plus long, c’est juste plus explicite. Et surtout, bien plus sécurisé. Même sans être expert en PHP, cette approche reste lisible, logique, et proche du fonctionnement initial — ce qui en fait un bon point de départ pour celles et ceux qui migrent un ancien projet Dreamweaver.
PHP 5.6 : entre faux confort et vrai risque
Pendant longtemps, PHP 5.6 a servi de socle à la plupart des projets Dreamweaver. C’était la version supportée par défaut par les hébergeurs, les scripts tiers, les générateurs de code intégrés. Et ce n’était pas propre à Dreamweaver : les principaux éditeurs d’extensions tierces (DMX Zone, Project VII, Web Assist…) ont eux aussi bâti leur logique autour de cette version, qu’ils jugeaient stable, largement diffusée, et compatible avec leurs outils maison. Comme cette version fonctionnait bien, peu voyaient l’intérêt d’en changer. Mais aujourd’hui, nombre de ces extensions ne sont plus maintenues, ou bloquent toute montée en version. Les remplacer, ou s’en affranchir totalement, fait souvent partie du chantier. Et selon l’ampleur du projet, repartir sur une base propre peut s’avérer plus simple que de tout adapter.
Depuis décembre 2018, cette version n’est plus maintenue (Deprecated features in PHP 5.6.x). Ni corrections de bugs, ni mises à jour de sécurité, ni compatibilité garantie avec les bibliothèques modernes — excepté pour certains éditeurs d’extensions qui ont tenté de suivre leur communauté, parfois en adaptant leurs modules à des versions plus récentes de PHP, sans toujours pouvoir aller jusqu’au bout.
Le risque n’est pas théorique. Il suffit qu’un module soit mal isolé, qu’une entrée utilisateur soit mal filtrée, ou qu’un script ancien utilise une fonction dépréciée pour ouvrir une faille exploitable. L’usage de fonctions comme ereg() (remplacée depuis longtemps par preg_match()), par exemple, ne permet aucun contrôle rigoureux des formats ou caractères attendus. Couplé à une variable non échappée, cela peut conduire à des injections de code, des accès non autorisés ou des contournements de règles de validation. D’autres fonctions liées à l’ancienne gestion des sessions peuvent créer des collisions, ou maintenir actives des sessions invalidées. Beaucoup de sites fonctionnant encore sous PHP 5.6 tournent avec des extensions ou des librairies abandonnées, ce qui rend leur mise à jour encore plus compliquée.
Certains hébergeurs ont déjà désactivé PHP 5.6 ou facturent un supplément pour continuer à l’utiliser. D’autres hébergeurs maintiennent encore cette version, parfois avec des conditions, mais cette tolérance devient de plus en plus rare. Et au moindre basculement forcé vers PHP 8.x, tout le site peut se retrouver en panne.
Revenir sur le code, repérer ce qui pose problème, préparer une transition propre vers une version encore maintenue comme PHP 8.2 ou PHP 8.3, cela peut sembler simple, mais revoir les connecteurs, réécrire les expressions obsolètes ou corriger certaines logiques métiers peut représenter un travail conséquent selon la structure du site. PHP 7.4 et 8.0 sont déjà en fin de vie, et PHP 8.1 ne sera plus maintenu après janvier 2026. Mais cela suppose de ne plus ignorer le problème. Même si tout semble encore fonctionner, rester sur PHP 5.6 aujourd’hui revient à circuler sans assurance sur une route verglacée.
Comment s’y prendre ?
Il ne s’agit pas ici de détailler toute la migration, mais on peut au moins en esquisser les grandes lignes :
- repérer les fonctions obsolètes (
ereg(),mysql_*, etc.) et les remplacer par leurs équivalents modernes (preg_match(),PDO,MySQLi…) - tester progressivement les scripts existants sous PHP 8, pour identifier les comportements à risque ou les erreurs bloquantes
- revoir les gestionnaires de sessions, les encodages, et les variables globales encore présentes
- sécuriser chaque point d’entrée utilisateur, avec filtres, validations et requêtes préparées
- garder un environnement de test séparé pour appliquer les modifications sans risque pour le site en production
Mieux vaut avancer point par point, avec méthode, plutôt que d’attendre le crash. Vous pouvez également prendre appui sur les deux articles Migrating from PHP 5.6.x to PHP 7.0.x et Migrating from PHP 7.4.x to PHP 8.0.x.
Outils pour auditer, migrer et sécuriser votre code PHP
Migrer un projet Dreamweaver vers une base saine ne signifie pas obligatoirement d’avoir à tout refaire à la main. Plusieurs outils peuvent vous assister pour repérer les fonctions obsolètes, suggérer des corrections ou automatiser certaines vérifications. Voici quelques pistes utiles pour accompagner cette transition :
- PHP CodeSniffer
Analyse automatiquement votre code pour détecter les syntaxes dépassées (mysql_*, etc.) et vous alerter sur les violations de standards (PSR-1, PSR-12…). Très utile pour détecter des erreurs à grande échelle dans un projet Dreamweaver. - PHPStan
Outil d’analyse statique qui signale les erreurs potentielles, mauvaises pratiques ou usages obsolètes avant même l’exécution du code. Parfait pour fiabiliser un projet avant migration. - Psalm
Similaire à PHPStan, avec un moteur plus fin pour le typage. Permet d’anticiper des bugs subtils et d’améliorer progressivement la qualité du code. - php-parser (npm)
Pour les développeurs aguerris : transforme du code PHP en arbre syntaxique (AST), utilisable dans des outils de refactoring automatisé. Peut servir à créer des scripts d’analyse sur mesure. - Extensions VS Code : PHP Intelephense, PHP Tools, PHP Refactoring
Ces extensions facilitent la lecture et la correction du code PHP, en mettant en évidence les appels dépréciés et en proposant des alternatives modernes. Même si Dreamweaver ne propose pas ce type d’analyse, il est possible d’utiliser ponctuellement un éditeur externe comme Visual Studio Code pour reconstruire certaines portions de code, avant de revenir à une gestion classique du site dans Dreamweaver.
Sécurité d’un site modernisé, repartir sur une base saine
Quand on parle de sécurité sur un site ancien, on pense d’abord à la version de PHP utilisée. Et c’est vrai, comme nous venons de le voir, rester bloqué sur PHP 5.6 comporte des risques. Mais ce n’est là qu’un des symptômes parmi tant d’autres. Derrière une apparence de stabilité, beaucoup de projets créés avec de vieilles versions de Dreamweaver reposent sur du code généré automatiquement, souvent sans réelle logique de validation, de filtrage ou de protection.
Les anciennes méthodes de connexion à la base de données, qui étaient basées sur mysql_connect() ou d’autres fonctions dépréciées, laissent des portes ouvertes aux injections SQL. Les formulaires ne vérifient que rarement les données reçues, les fichiers uploadés (au travers de certaines extensions) ne sont pas systématiquement filtrés, les sessions sont quelques fois mal sécurisées, ou partagées sans restriction claire. À cela s’ajoutent des dépendances non mises à jour, des chemins d’accès exposés, ou des variables globales encore actives.
Reprendre en main la sécurité d’un tel site, ce n’est pas simplement ajouter un captcha ou un token. C’est revoir le fonctionnement complet des zones dynamiques, notamment :
- valider et filtrer chaque champ, à l’aide de fonctions comme
filter_var()ou d’expressions régulières adaptées ; - remplacer les requêtes directes par des requêtes préparées, via
PDOouMySQLi(voir nos articles Comprendre et utiliser MySQLi et Utiliser PDO pour gérer plusieurs types de bases de données en PHP) ; - isoler les fichiers critiques (scripts sensibles, clés d’accès, zones d’admin) pour éviter tout accès non autorisé ;
- restreindre les droits sur les fichiers et répertoires côté serveur (voir aussi MySQL : sécurisation des accès et des données) ;
- protéger contre les attaques XSS et CSRF, en encadrant strictement les entrées et les formulaires (voir aussi Protection de base pour un formulaire) ;
- assurer un suivi des sessions sécurisé, avec une gestion propre des identifiants, des durées et des invalidations (voir aussi Sessions PHP : sécuriser les identifiants, durées et invalidations).
Chaque point mérite une attention spécifique, car la sécurité ne repose jamais sur un seul verrou.
C’est une démarche progressive, mais indispensable. Un site modernisé ne peut pas rester vulnérable sous prétexte qu’il est « en place depuis des années ». Il faut s’assurer qu’il soit encore fiable demain, quelle que soit sa structure d’origine.
Mises en page en tableau, entre héritage et verrou
Pendant longtemps, Dreamweaver a proposé les tableaux HTML comme solution simple pour organiser la mise en page. En quelques clics, on structurait visuellement une page avec des cellules imbriquées, alignées, réparties selon des hauteurs ou des largeurs fixes. C’était pratique, visuel, rassurant. Fireworks ajoutait même un petit fichier transparent nommé shim.gif, souvent de 1 pixel sur 1 pixel, inséré dans les cellules vides pour éviter qu’elles ne s’effondrent. Une rustine discrète, mais révélatrice d’une époque où l’illusion de structure primait parfois sur la logique sémantique.
Mais cette approche, pensée pour des écrans fixes et homogènes, ne répond plus aux réalités actuelles. Sur mobile, ces mises en page cassent ou restent figées.
Avec la démocratisation des CSS, Dreamweaver a proposé une alternative au tableaux : le positionnement absolu via des balises DIV, qui permettait de placer visuellement chaque bloc un peu à la manière d’un logiciel de mise en page PAO. Là encore, le code généré reste figé, peu souple, et très dépendant des dimensions initiales. Le tout produit un ensemble difficile à maintenir, lourd, et rigide : toute tentative d’ajustement devient un casse-tête.
Migrer vers un design responsive ne se résume pas à changer deux balises. Il faut souvent tout repenser : structure HTML plus sémantique, usage du CSS pour les grilles ou flexbox, adaptation aux différentes tailles d’écrans, hiérarchisation des contenus selon leur importance. C’est précisément ce qui est exploré en détails dans la série LinkedIn “Why Responsive Websites Are Not Just a Simple Step for Website Construction…”.
Ce travail peut sembler coûteux, mais il est indispensable pour assurer une expérience de lecture fluide, moderne, et accessible. Et il offre un bénéfice inattendu : en s’éloignant de la logique des tableaux, on allège le code, on facilite l’accessibilité, et on prépare le site à toutes les évolutions futures, sans dépendance à une structure rigide et dépassée.
En adoptant les balises sémantiques introduites par HTML5 — comme <header>, <nav>, <main>, <section>, <article>, <aside> ou <footer> —, on redonne du sens au contenu. Ces éléments permettent aux navigateurs, lecteurs d’écran et moteurs de recherche de mieux comprendre l’organisation de la page. On ne se contente plus de “placer” des blocs : on les identifie clairement par leur rôle, ce qui favorise à la fois l’indexation, la navigation assistée, et la maintenabilité du code sur le long terme.
Et pour amorcer la transition ?
Pas besoin de tout refaire du jour au lendemain. Il est souvent possible de reconstruire la structure petit à petit, page par page, en gardant une version fonctionnelle du site tout au long du processus. Voici quelques points d’entrée concrets :
- Reproduire l’organisation existante dans une grille CSS moderne, en commençant par les grandes zones (entête, navigation, contenu, pied de page).
- Utiliser flexbox pour les blocs secondaires (cartes, colonnes, boutons alignés).
- Découper la page en sections claires, chacune avec un rôle sémantique (
<main>,<section>,<article>,<aside>…). - Ajouter progressivement des media queries pour adapter l’affichage selon les tailles d’écran.
- Tester chaque étape dans un navigateur récent avec les outils de développement intégrés.
Vous pouvez aussi vous appuyer sur les outils de développement intégrés aux navigateurs pour repérer visuellement les éléments problématiques. Dans Chrome ou Firefox, l’inspecteur (F12) permet par exemple de mettre en évidence les balises <table> utilisées pour la mise en page, ou les blocs <div> positionnés en absolute, souvent responsables de rigidités d’affichage. Un simple survol vous aide à comprendre la structure actuelle, et à cibler les éléments à reconstruire.
Pour aller plus loin, vous pouvez intégrer une feuille de style temporaire à votre navigateur pour surligner automatiquement les zones problématiques. Voici un extrait à insérer dans votre CSS ou dans l’onglet « Style » de l’inspecteur :
/* Mettez en évidence les tableaux de mise en page */
table {
outline: 2px solid red !important;
background-color: rgba(255, 0, 0, 0.05) !important;
}
/* Affichez les DIV en position absolue */
div[style*="position:absolute"] {
outline: 2px dashed orange !important;
background-color: rgba(255, 165, 0, 0.05) !important;
}Cette astuce visuelle ne remplace pas une vraie refonte, mais elle offre un bon point de départ pour repérer les priorités.
Ce sont des étapes simples, mais qui permettent d’enclencher une refonte solide sans tout casser d’un coup. Et surtout, elles replacent le site dans une dynamique actuelle, pérenne, lisible.
L’accessibilité web, dépasser l’héritage limité de Dreamweaver
Dans les versions historiques de Dreamweaver, l’accessibilité se limitait surtout à la gestion de l’attribut alt pour les images. Rien n’était prévu pour les autres aspects pourtant essentiels : respect des normes WCAG (même en version 1.0), balisage ARIA, navigation clavier, gestion des contrastes, repères sémantiques ou compatibilité avec les lecteurs d’écran.
Aujourd’hui, ces exigences ne sont plus optionnelles. Elles sont devenues des critères fondamentaux de qualité, de conformité et d’inclusivité. Migrer un site issu de Dreamweaver impose donc de revoir entièrement cette approche, en s’alignant sur les standards actuels : WCAG 2.1, structure claire, attributs ARIA bien utilisés, expérience fluide pour tous les utilisateurs.
Nous avons consacré plusieurs articles à ces questions, comme Accessibilité web : comprendre avant de coder, Qu’entend-on par accessibilité ?, Accessibilité web : penser un site dès la page blanche ou encore ARIA les bases… Rôles, repères, états et propriétés. Ces ressources peuvent guider pas à pas la remise à niveau d’un site ancien.
Abandon de Flash, nettoyer les vestiges invisibles
Fireworks n’est pas le seul à avoir rejoint les étagères de l’oubli, en fait Flash l’a précédé, et donc si votre site a été conçu à une époque où Macromedia Flash (puis Adobe Flash) faisait partie intégrante des outils proposés dans Dreamweaver, il est possible qu’il contienne encore des éléments .swf, des scripts AC_RunActiveContent.js, ou des appels à des objets object/embed liés à Flash. Ces éléments ne sont plus pris en charge par aucun navigateur depuis 2021, et peuvent créer des zones blanches, des comportements erratiques ou des erreurs de script.
La seule option viable aujourd’hui est de supprimer ces vestiges. Cela suppose :
- de scanner les pages HTML à la recherche de balises
<object>,<embed>, ou de fichiers.swf, - de retirer les scripts d’initialisation Flash intégrés automatiquement par Dreamweaver (
AC_RunActiveContent.js,expressInstall.swf…), - de vérifier si certains contenus critiques (animations, galeries, menus, contenus interactifs…) reposaient sur Flash, et si oui, de les reconstruire en HTML5, CSS3 et JavaScript natif.
Des bibliothèques comme GreenSock (GSAP), Anime.js, ou Lottie (pour des animations exportées depuis After Effects) permettent aujourd’hui de recréer des effets équivalents, mais de façon fluide, accessible, et compatible avec tous les supports.
En retirant Flash, on élimine une dépendance morte, on allège les pages, et on évite des messages d’erreur ou des incompréhensions pour les visiteurs. Cette étape est indispensable pour tout projet qui vise une remise en ligne fonctionnelle.
Conclusion
Les projets conçus avec Dreamweaver gardent en mémoire une époque précise du web. Certains choix techniques, longtemps considérés comme des standards, freinent aujourd’hui leur évolution : code figé, pratiques dépassées, dépendances à des technologies disparues. Ce premier article a posé les bases en identifiant ces freins d’origine technique.
Mais l’ancienneté n’est pas le seul verrou. Dans les articles suivants, nous aborderons les limites liées à la nature propriétaire de Dreamweaver, l’obsolescence de ses outils internes, et les pistes concrètes pour sortir de cette dépendance sans repartir de zéro.
Il ne s’agit pas d’effacer le passé, mais de mieux composer avec lui.
