Quand le site dépend de l’outil : comprendre l’héritage Dreamweaver
Cet article s’inscrit dans la série dédiée à la modernisation des projets développés avec Dreamweaver, souvent sur de longues périodes. Après avoir abordé les blocages techniques liés à l’ancienneté des sites, nous examinons ici un autre facteur limitant : les mécanismes propriétaires propres à l’éditeur.
Dreamweaver a toujours combiné une liberté d’édition directe (HTML, CSS, JS, PHP) avec des fonctionnalités internes spécifiques — templates, bibliothèques, widgets, extensions — qui ont facilité la création de sites, mais enfermé peu à peu les projets dans des formats liés au logiciel lui-même. Ces mécanismes, souvent invisibles à l’usage, rendent les sites dépendants de l’environnement Dreamweaver, et compliquent toute tentative de migration ou d’évolution.
Comprendre ces dépendances — comment elles fonctionnent, pourquoi elles posent problème aujourd’hui, et comment en sortir sans tout casser — est indispensable pour garantir la pérennité d’un projet web. C’est ce que nous allons explorer dans cet article.
- Les templates DWT : un cadre rigide à dépasser : montrer comment les modèles DWT enferment la structure des pages et compliquent leur migration.
- SPRY : des comportements interactifs devenus obsolètes : expliquer le rôle de la bibliothèque Spry et pourquoi elle est désormais incompatible avec les standards modernes.
- Widgets propriétaires : entre confort passé et impasse actuelle : rappeler l’usage des widgets intégrés, utiles à l’époque mais bloquants aujourd’hui.
- Éléments de bibliothèque : quand la modularité dépend du logiciel : souligner la fausse impression de modularité créée par les fragments
.lbi. - Extensions Dreamweaver : des ajouts qui figent les usages : mettre en garde contre les extensions héritées, souvent non mises à jour et liées à l’écosystème DW.
- Creative Cloud : des ressources liées à un écosystème fermé : pointer le risque de rupture si l’on sort de l’abonnement Adobe, notamment pour les bibliothèques partagées et les polices.
- Export et import DW : une portabilité souvent illusoire : décrire les limites des mécanismes d’import/export et la prudence à adopter lors d’une migration.
- Fichiers PNG liés à Fireworks : la fin d’un cycle invisible : évoquer le flux de travail disparu entre Fireworks et Dreamweaver et ses traces encore présentes.
- Dépendances croisées : anticiper ce que l’outil cache encore : montrer comment l’imbrication des dépendances rend la migration plus complexe et nécessite un audit.
Les templates DWT : un cadre rigide à dépasser
Une des dépendances les plus marquées mises en place par Dreamweaver est celle des Design Web Templates (DWT). Ils permettent de créer une structure commune à plusieurs pages, avec des zones figées et des zones modifiables, mais reposent sur un système entièrement propriétaire. Le logiciel gère ces modèles dans un dossier dédié, nommé Templates, qui centralise tous les fichiers DWT du site. Si votre dossier racine contient un dossier Templates, c’est le signe que votre site s’appuie sur des modèles Dreamweaver.
Chaque fichier .dwt est un modèle maître qui définit la structure globale et les zones éditables des pages qui en héritent. Lorsqu’une page est créée à partir d’un .dwt, elle reste liée à ce modèle : toute modification du fichier .dwt se répercute automatiquement sur toutes les pages associées, tant que cette liaison est maintenue dans Dreamweaver. Le code qui suit est typique d’une page issue d’un template, ou du moins associée à un template actif, car on y retrouve les balises spécifiques gérées par l’éditeur.
<!-- InstanceBegin template="/Templates/basePChron.dwt.php" codeOutsideHTMLIsLocked="false" -->Les templates Dreamweaver utilisent des commentaires HTML spécifiques pour identifier les zones qu’ils contrôlent. La plus connue est la zone modifiable, qui se présente généralement ainsi :
<!-- TemplateBeginEditable name="nom_zone" -->
... contenu modifiable ...
<!-- TemplateEndEditable -->Ces balises ne sont reconnues et interprétées que par Dreamweaver, et restent invisibles pour les navigateurs. Au-delà des régions modifiables, Dreamweaver propose aussi :
- Régions facultatives : affichées ou masquées selon des conditions (
<!-- TemplateBeginIf -->/<!-- TemplateEndIf -->). - Régions répétées : permettant de dupliquer un bloc de contenu (
<!-- TemplateBeginRepeat -->/<!-- TemplateEndRepeat -->). - Variables de modèle : insérant des valeurs prédéfinies dans plusieurs pages (
<!-- TemplateParam -->).
Ces mécanismes, bien que pratiques dans l’éditeur, enferment la mise en page dans un cadre propriétaire et compliquent toute migration vers un système standard. Ce verrouillage complique l’adoption de solutions plus souples, comme les includes PHP, les composants Vue.js ou les modèles de CMS. Lorsqu’on veut sortir du cadre DWT, il faut souvent réécrire la structure, supprimer ou remplacer ces commentaires spécifiques, et revoir l’organisation des fichiers.
La difficulté se renforce lors de l’export ou de la suppression de cette dépendance : des liens internes peuvent se rompre, et des parties figées doivent être réintégrées manuellement. Pour une migration sereine, il est conseillé de planifier la conversion vers un système standard dès le début du projet.
Dans cet extrait simplifié qui suit, les commentaires TemplateBeginIf, #BeginLibraryItem et les zones de contenu montrent clairement à quel point l’imbrication entre instructions de template et contenu peut rendre complexe la sortie de cette dépendance. Ces balises, totalement inactives en dehors de l’éditeur, doivent être retirées ou remplacées pour que le code devienne pleinement autonome.
<!-- TemplateParam name="environnement" type="text" value="" -->
<div class="container">
<h1>
<!-- TemplateBeginEditable name="zone_haut" -->
Ce texte sera modifiable pour chaque enfant issu de ce template
<!-- TemplateEndEditable -->
</h1>
<nav role="navigation">
<ul>
<!-- TemplateBeginIf cond="(environnement == 'etablissements')" -->
<!-- #BeginLibraryItem "/Library/__GLB_THM_ETB.lbi" -->
<!-- Contenu du menu établissements -->
<!-- #EndLibraryItem -->
<!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="(environnement == 'domicile')" -->
<!-- #BeginLibraryItem "/Library/__GLB_THM_DOM.lbi" -->
<!-- Contenu du menu domicile -->
<!-- #EndLibraryItem -->
<!-- TemplateEndIf -->
<!-- Autres éléments du menu -->
</ul>
</nav>
</div>Pistes pour réduire la dépendance aux DWT
Sortir de cette logique propriétaire demande une stratégie progressive. Il s’agit de remplacer les zones figées par des includes ou composants standard, de migrer les variables vers des fichiers de configuration classiques et de réintégrer manuellement les contenus des régions facultatives ou répétées. La tâche est complexe : un article entier ne suffirait pas à couvrir toutes les étapes, tant elles varient selon la structure du site et son historique.
Sans clarification sur la pérennité de Dreamweaver au sein de la Creative Cloud, il devient risqué de maintenir un site sur une telle mécanique : si l’éditeur venait à être retiré de l’offre, l’accès et la modification des zones dépendantes pourraient devenir problématiques et nécessiter un traitement dans l’urgence.
SPRY : des comportements interactifs devenus obsolètes
Spry était une bibliothèque JavaScript intégrée par Adobe dans Dreamweaver pour ajouter rapidement de l’interactivité aux sites : menus déroulants, onglets, panneaux dynamiques, formulaires enrichis… Elle combinait HTML, CSS et JavaScript avec une structure propre, souvent associée à des fichiers XML, un format de données aujourd’hui largement supplanté par JSON dans les développements web modernes pour gérer les données (voir aussi « What is the difference between JSON and XML » ou « JSON ou XML, quel format choisir ?» pour approfondir la comparaison).
Longtemps pratique pour éviter d’écrire tout le code à la main, Spry est aujourd’hui totalement abandonné. La librairie n’a reçu aucune mise à jour depuis des années, ce qui entraîne des incompatibilités avec les navigateurs modernes et pose des problèmes de performance ou d’accessibilité.
On peut reconnaître facilement un site utilisant Spry par la présence de dossiers ou fichiers nommés SpryAssets, ou encore par des appels à des fichiers tels que :
<link rel="stylesheet" href="SpryAssets/SpryMenuBarHorizontal.css" type="text/css" />
<script src="SpryAssets/SpryMenuBar.js" type="text/javascript"></script>Ces références indiquent que les menus, onglets ou autres effets interactifs reposent sur cette bibliothèque propriétaire. Il est également courant de trouver, en bas de page, un script d’initialisation propre à Spry, par exemple :
<script type="text/javascript">
var MenuBar1 = new Spry.Widget.MenuBar("MenuBar1", {imgDown:"SpryAssets/SpryMenuBarDownHover.gif", imgRight:"SpryAssets/SpryMenuBarRightHover.gif"});
</script>Sa présence confirme l’usage actif de la bibliothèque, car les simples liens vers les fichiers ne garantissent pas que le code soit effectivement utilisé dans la page.
Migrer un site utilisant Spry implique donc de remplacer ces composants par des solutions maintenues et standardisées comme Bootstrap, Vue.js ou jQuery UI. Cette étape demande de réécrire la structure HTML et de mettre à jour les styles et scripts associés, tout en conservant les mêmes fonctionnalités. C’est une tâche qui peut rapidement devenir complexe, surtout si plusieurs pages partagent les mêmes composants Spry. Anticiper un mécanisme de mutualisation des ressources permet d’éviter des complications supplémentaires lors de la migration.
Sans cette transition, le risque est d’accumuler des problèmes d’affichage et de compatibilité, au point de bloquer toute évolution future du site.
Widgets propriétaires : entre confort passé et impasse actuelle
Au-delà de Spry, Dreamweaver a longtemps proposé ses propres widgets intégrés : menus dynamiques, formulaires enrichis, effets interactifs prêts à l’emploi. Leur objectif était de simplifier la vie de l’utilisateur en ajoutant des fonctionnalités sans écrire trop de code. Ces composants ont perduré plusieurs années avant d’être abandonnés. Ils étaient disponibles via la plateforme Adobe Exchange, qui permettait de charger ou de télécharger des widgets. Bien que la majorité aient été gratuits, certains étaient proposés sous forme payante.
Techniquement, ces widgets reposaient souvent sur un mélange de JavaScript maison et de structures HTML spécifiques à Dreamweaver. Le problème, c’est que ces implémentations ne respectaient pas toujours les standards du DOM, rendant le code difficile à maintenir ou à faire évoluer.
On pouvait par exemple insérer un menu ou un formulaire interactif directement depuis le panneau « Insertion » de Dreamweaver, qui générait automatiquement les balises et scripts nécessaires. Pour illustrer ce fonctionnement, on peut encore retrouver des exemples tels que Utilisation du widget Panneaux à onglet Spry ou Utilisation des widgets d’interface jQuery pour créer une page, voire Utilisation de widgets jQuery UI et Mobile dans Dreamweaver.
Leur absence de mises à jour et leur dépendance à l’éditeur posent un vrai problème : plus le temps passe, plus la compatibilité avec les navigateurs modernes se dégrade. Migrer ces widgets nécessite de réécrire les composants à l’aide de solutions standardisées (JavaScript natif, Bootstrap, Vue.js…) afin de s’affranchir de cette couche propriétaire.
Détecter et remplacer les widgets
Pour identifier un widget propriétaire, il suffit de repérer dans le code les classes ou attributs générés automatiquement par Dreamweaver (dwMenu, dwForm…), ou encore des inclusions de scripts estampillés Adobe. Ces traces permettent aujourd’hui de détecter qu’un site dépend encore de ces widgets.
Une fois repérés, ces blocs doivent être supprimés ou remplacés par des équivalents modernes adaptés au projet, en veillant à conserver les fonctionnalités attendues. Ce travail peut être progressif, mais il est essentiel pour assurer la compatibilité et la maintenabilité du site.
Éléments de bibliothèque : quand la modularité dépend du logiciel
Dreamweaver propose depuis longtemps un système d’éléments de bibliothèque, centralisés dans un dossier Library. L’idée est séduisante : placer des fragments de code HTML, des blocs d’interface ou des morceaux de mise en page dans des fichiers distincts, puis les réutiliser à volonté dans plusieurs pages du site. À chaque mise à jour, Dreamweaver se charge de répercuter automatiquement les changements sur l’ensemble des pages qui les utilisent.
Exemple : contenu d’un fichier .lbi et insertion dans une page
Un élément typique, par exemple __GLB_PIWIK.lbi, pouvait contenir un simple fragment HTML. Il débutait parfois par une balise meta comme :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!-- puis le fragment HTML utile (ex. code de suivi, balise script, etc.) -->Lorsqu’il était inséré dans une page, Dreamweaver encadrait ce contenu par des commentaires spécifiques, similaires à ceux utilisés pour les templates, sans reproduire la balise meta :
<!-- #BeginLibraryItem "/Library/__GLB_PIWIK.lbi" -->
<!-- ici le fragment HTML réutilisé -->
<!-- #EndLibraryItem -->Ces marqueurs indiquent au logiciel qu’il s’agit d’un élément de bibliothèque, afin de propager les modifications ultérieures vers toutes les pages qui l’emploient.
En apparence, cela donne une impression de modularité et de maintenance simplifiée. Mais cette mécanique repose entièrement sur Dreamweaver : sans l’éditeur, les mises à jour ne se propagent plus. Le code inséré dans les pages devient figé et difficile à maintenir, car les liens entre les fragments et les pages ne sont pas gérés en dehors du logiciel.
Ce paradoxe est important à comprendre : ce qui ressemble à une solution moderne de réutilisation n’est en réalité qu’une dépendance supplémentaire. Migrer ces contenus demande de transformer les fragments en includes côté serveur (PHP, ASP…) ou en composants modulaires (par exemple avec Vue.js), afin qu’ils puissent être mis à jour et maintenus indépendamment de Dreamweaver.
En clair, les éléments de bibliothèque offrent une fausse modularité. Ils fonctionnent tant que l’on reste dans l’écosystème Dreamweaver, mais deviennent un frein dès que l’on souhaite s’en affranchir.
Extensions Dreamweaver : des ajouts qui figent les usages
Dreamweaver a toujours permis d’étendre ses fonctionnalités par le biais d’extensions. Certaines provenaient d’éditeurs tiers connus comme Project Seven, DMXZone ou WebAssist, que nous avons évoqués précédemment dans Dreamweaver : fin d’un règne… mais pas de la communauté. Mais la plateforme Adobe Exchange regorgeait également de nombreuses autres extensions, parfois proches des widgets intégrés, que l’on pouvait télécharger et installer directement via l’Extension Manager.
Pour l’anecdote, la capture d’écran jointe illustre ici des extensions de Fireworks plutôt que de Dreamweaver, un clin d’œil à cette application sœur de la Creative Suite, qui elle aussi reposait sur un système d’extensions téléchargeables via Exchange.
Ces extensions avaient pour but de simplifier la création de fonctionnalités : formulaires avancés, galeries, effets interactifs, intégration de scripts serveurs… En pratique, elles reposaient souvent sur des techniques spécifiques à l’écosystème Dreamweaver, sans réelle garantie de compatibilité future. Certaines allaient même jusqu’à modifier les préférences internes ou les menus du logiciel pour s’intégrer pleinement à son environnement.
À titre d’illustration, on peut citer l’extension 960 Grids, qui offrait un mode de travail simplifié avec des grilles de 12, 16 ou 24 colonnes. Si cet outil facilitait la mise en page à l’époque, il restait limité car il ne proposait aucune adaptation responsive, un critère devenu incontournable aujourd’hui.
Aujourd’hui, dans les dernières versions de Dreamweaver, la gestion des extensions ne passe plus par l’Extension Manager mais directement par l’interface de l’application Creative Cloud, ce qui change le mode d’installation et de suivi de ces plugins. Il est également possible, via le menu Fenêtre > Rechercher des extensions sur Exchange, d’accéder directement au catalogue des extensions disponibles.
Le problème est que beaucoup de ces extensions n’ont jamais bénéficié de mises à jour. Résultat : elles peuvent aujourd’hui s’appuyer sur des versions obsolètes de PHP ou de MySQL, ou bien sur des bibliothèques JavaScript qui ne sont plus adaptées aux standards actuels des navigateurs. Utiliser ces composants revient donc à figer un projet dans une logique technique périmée.
Il convient également de souligner que l’ancienne extension des comportements serveurs reste disponible et installable dans les dernières versions de Dreamweaver. Cette option peut faciliter la maintenance ou la migration de sites qui s’appuient encore sur ce mécanisme hérité. Pour un éclairage plus complet, voir l’article Ce que les sites anciens traînent encore avec eux : repères pour avancer – Puce et Média.
Avant de poursuivre avec un site qui dépend encore de certaines extensions, il est indispensable de réévaluer chacune d’entre elles :
- Vérifier si elle dispose encore d’une version maintenue.
- Contrôler si le code repose sur des technologies compatibles (PHP, MySQL, JavaScript modernes).
- Planifier son remplacement si elle n’est plus à jour.
Dans bien des cas, il sera plus sûr et plus pérenne d’intégrer la fonctionnalité autrement, en recourant à des solutions standards et maintenues.
En clair, ces extensions pouvaient être utiles pour gagner du temps à une époque, mais leur dépendance à Dreamweaver et leur absence de suivi en font désormais un frein à la modernisation des projets.
Creative Cloud : des ressources liées à un écosystème fermé
Avec l’intégration croissante d’Adobe Creative Cloud, Dreamweaver a ouvert la possibilité de partager et de réutiliser des ressources communes : images, styles, couleurs, polices ou encore éléments graphiques. Ces bibliothèques permettent de travailler plus efficacement en centralisant les ressources et en les rendant disponibles dans plusieurs applications comme Photoshop, Illustrator ou InDesign.
Ce fonctionnement apporte une réelle souplesse tant que l’on reste dans l’écosystème Adobe. Mais il cache aussi un risque : dès que l’abonnement Creative Cloud est interrompu, ces bibliothèques peuvent ne plus être accessibles. Certaines polices hébergées par Adobe, par exemple, disparaissent automatiquement des projets si l’accès est coupé. Cette dépendance doit donc être considérée comme un facteur de verrouillage technique.
Pour sécuriser ses projets, il est recommandé d’anticiper :
- Sauvegarder localement les images, icônes et éléments graphiques essentiels.
- Exporter les palettes de couleurs, styles et typographies pour pouvoir les réutiliser en dehors d’Adobe.
- Remplacer les polices hébergées par des alternatives auto-hébergées lorsque cela est possible.
En pratique, il s’agit de traiter ces bibliothèques partagées comme un confort de travail et non comme une garantie de pérennité. Les projets doivent rester indépendants de la plateforme : c’est la seule manière d’assurer leur continuité même si Adobe décide de modifier ou de restreindre l’accès à certains services.
Export et import DW : une portabilité souvent illusoire
Dreamweaver propose des fonctions d’export et d’import pour certains de ses éléments propriétaires : templates et bibliothèques (copie depuis la palette des actifs), extensions (.zxp, .mxp). En théorie, cela devait permettre de réutiliser facilement ces ressources d’un projet à l’autre. En pratique, ces échanges sont souvent peu documentés et peuvent générer des pertes de liaisons, des dégradations de styles ou des comportements imprévisibles.
Cette relative fragilité impose de tester chaque export ou import sur une copie du site, plutôt que sur l’original. Dans certains cas, il est même plus fiable de procéder à une migration manuelle, en reconstruisant les éléments essentiels au lieu de s’appuyer sur ces mécanismes internes.
Il existait également des formats spéciaux d’import, notamment pour intégrer du contenu provenant d’autres outils Adobe comme Animate. Ces fichiers .oam, générés par Edge Animate ou Animate, pouvaient être insérés directement dans Dreamweaver (voir Importation de compositions animées sous Dreamweaver). Bien que pratiques à l’époque, ils posent aujourd’hui question : leur compatibilité n’est pas garantie dans les versions récentes, et leur usage reste source d’incertitude.
Par ailleurs, Dreamweaver permet d’exporter ou d’importer un site via des fichiers .ste (qui ne concernent que la configuration et non les fichiers eux-mêmes). Ces fichiers contiennent la configuration du site au format XML, utile pour transférer un projet d’un poste à un autre. Cependant, si l’on décide de quitter Dreamweaver pour un éditeur tierce comme Visual Studio Code ou Sublime Text, il faut s’assurer que ces données puissent être récupérées et traduites de manière intelligible, afin de ne pas perdre d’informations clés sur la structure ou les paramètres du projet.
En somme, les outils d’import/export de Dreamweaver offrent une portabilité pratique en apparence, mais ils nécessitent malgré tout une vigilance accrue et un travail de vérification systématique pour garantir une migration fiable et éviter toute dépendance involontaire.
Fichiers PNG liés à Fireworks : la fin d’un cycle invisible
Pendant des années, Dreamweaver a fonctionné en tandem avec Fireworks pour la création et l’optimisation des interfaces et des images, Fireworks, chaud devant ! L’utilisateur préparait ses visuels dans Fireworks, souvent en conservant des fichiers PNG non flattenés contenant calques, tranches (slices) et métadonnées. Ces fichiers étaient ensuite automatiquement exportés pour Dreamweaver, avec des formats optimisés pour le web (GIF, JPEG ou PNG aplatis avec transparence).
Mais Fireworks n’est plus. Progressivement abandonné, il a été remplacé dans les workflows Adobe par Photoshop, directement intégré à l’interface de Dreamweaver pour prendre le relais sur certaines fonctions de traitement. Pourtant, dans de nombreux sites anciens, ces fichiers PNG intermédiaires liés à Fireworks sont encore présents, parfois appelés par erreur comme images finales, avec des poids excessifs et des rendus non maîtrisés.
Corriger cela passe par une vraie reprise des visuels. Cela suppose de :
- repérer les anciens PNG source (non aplatis, souvent trop lourds) et les remplacer par des exports propres, ou leur équivalence au format PSD
- vérifier les dimensions d’affichage réelles dans les pages HTML pour ajuster les visuels à la bonne taille,
- rebasculer sur des formats modernes (WebP, JPEG progressif, Ancien Fireworks PNG optimisé),
- adopter des icônes vectorielles (SVG) pour remplacer les anciennes images PNG utilisées comme pictogrammes (loupe, enveloppe, flèche…),
- recourir à des polices d’icônes telles que Font Awesome ou Material Icons, stylisables via CSS et maintenues activement,
- intégrer une stratégie responsive avec
srcset,<picture>ousizespour adapter le visuel à l’appareil, - activer le lazy loading (
loading="lazy") pour éviter de charger les images non visibles immédiatement.
Des outils comme Squoosh, ImageOptim, TinyPNG ou même Photoshop (en export manuel) permettent d’obtenir un rendu léger et net. Cette étape est essentielle, non seulement pour alléger le site et en améliorer les performances, mais aussi pour répondre aux exigences actuelles en matière de SEO, d’accessibilité et d’affichage mobile.
C’est une migration discrète, souvent négligée, mais qui transforme profondément l’expérience utilisateur et la longévité du projet.
Dépendances croisées : anticiper ce que l’outil cache encore
Au fil du temps, les sites réalisés avec Dreamweaver ont souvent accumulé plusieurs couches de dépendances : modèles DWT, éléments de bibliothèque, widgets, extensions, Spry… Chaque mécanisme a pu sembler pratique isolément, mais leur combinaison crée une imbrication complexe et difficile à démêler.
Cette situation est accentuée par les liens croisés avec d’autres logiciels Adobe. Un site pouvait par exemple intégrer des PNG enrichis depuis Fireworks, utiliser des polices Typekit (aujourd’hui Adobe Fonts) ou dépendre de bibliothèques Creative Cloud partagées avec Photoshop et Illustrator. Ces ressources, invisibles en apparence, constituent autant de points de fragilité dès que l’on sort de l’écosystème Adobe.
Lors d’une migration, un simple correctif peut révéler un effet boule de neige : corriger un widget Spry peut exposer une dépendance à une bibliothèque, qui elle-même s’appuie sur un template propriétaire. Ce maillage rend parfois la refonte plus lourde que prévu.
Pour limiter les risques, il est indispensable de commencer par un audit complet du projet. Identifier tous les éléments propriétaires, cartographier leurs interactions et hiérarchiser les priorités permet d’anticiper la charge réelle de travail. Cette approche évite de découvrir trop tard des dépendances cachées et prépare une transition plus sereine vers un environnement moderne.
Conclusion
Les mécanismes propriétaires de Dreamweaver ont longtemps offert un confort indéniable : gagner du temps, centraliser certaines ressources, simplifier la mise en place d’interactivités. Mais ce confort s’accompagnait d’un prix caché : une dépendance forte à l’éditeur et à son écosystème. Aujourd’hui, ces choix techniques pèsent sur la pérennité des projets et compliquent leur évolution.
Identifier ces dépendances, qu’elles concernent les modèles DWT, les bibliothèques, les widgets, Spry ou les extensions, est une étape indispensable pour planifier l’avenir d’un site. Il ne s’agit pas de renier l’apport de Dreamweaver, mais de reconnaître que certains de ses outils appartiennent désormais au passé.
En adoptant une démarche méthodique — audit, hiérarchisation, migration progressive — il est possible de transformer cette contrainte en opportunité : rendre un projet plus indépendant, plus robuste et mieux armé pour s’inscrire dans un environnement moderne. Ce travail n’est pas toujours simple, mais il assure la continuité et la valeur des sites au-delà de l’histoire de Dreamweaver lui-même.
