Discussion :

[Kush Creates]

Pourquoi les développeurs et les entreprises devraient réfléchir à deux fois avant d'utiliser des éditeurs « WYSIWYG », par Kush Creates

Une plongée profonde dans les raisons pour lesquelles le codage manuel de HTML/CSS reste pertinent en 2025, explorant les défis du développement web moderne, l'intégration de l'IA et les raisons pour lesquelles de nombreux géants de la technologie préfèrent encore le contrôle direct du code.

Pour information, WYSIWYG : What You See Is What You Get (Ce que vous voyez est ce que vous obtenez)

L'état du WYSIWYG en 2025 : Pas l'éditeur de votre grand-père

Commençons par une bonne nouvelle : Les éditeurs WYSIWYG ont parcouru un long chemin depuis l'époque de Microsoft FrontPage (versez-en un pour ce soldat tombé au combat).

Les éditeurs modernes sont dotés de l'assistance de l'IA, d'une collaboration en temps réel et même d'une sortie de code décente. Mais avant de sauter dans le train WYSIWYG plus vite qu'un framework JavaScript n'atteint la version 1.0, voyons pourquoi de nombreux développeurs professionnels et entreprises choisissent encore de coder leur contenu à la main.


La pile de développement moderne face à la réalité du WYSIWYG

Aujourd'hui, le développement Web ne consiste pas simplement à ajouter du HTML/CSS sur une page et à s'arrêter là. Nous avons affaire à :

• SSR avec des frameworks comme Next.JS et Remix
• Composants Web et éléments personnalisés
• Encapsulation Shadow DOM
• CSS Container Queries et Cascade Layers
• React Server Components
• Progressive Web Apps (PWAs)
• Edge Computing et CDN first architectures

Bien sûr, les éditeurs WYSIWYG modernes prétendent gérer ces technologies, un peu comme je prétends que je commencerai à aller à la salle de sport la semaine prochaine. En réalité ? Ils génèrent souvent du code qui lutte contre ces paradigmes modernes au lieu de travailler avec eux.


Le grand paradoxe du Paywall

Parlons du sujet sensible : les caractéristiques absolument ahurissantes des paywalls qui existent encore en 2025. Si les éditeurs WYSIWYG étaient des jeux vidéo, ils remporteraient des prix pour les microtransactions les plus agressives de l'histoire, juste un peu derrière Electronic Arts (EA).

Le paquet "Fonctionnalités de base ? Jamais entendu parler"

Vous voulez savoir ce qu'il y aura encore derrière les paywalls en 2025 ? Attachez vos ceintures, car la course va devenir folle :

1. Génération de tables des matières
   
   
   • En 2025, les éditeurs WYSIWYG facturent encore un supplément pour la fonctionnalité de table des matières. Oui, vous avez bien entendu ! Quelque chose qui peut être créé avec des balises <ul> et <li> et une pincée de JavaScript est enfermé derrière un paywall. C'est comme si on vous faisait payer un supplément dans un restaurant pour vous fournir... un menu.
     
     
   • Éditeur WYSIWYG : "Ce sera seulement 29,99 $/mois pour notre 'Premium Navigation Package'"
     
     
   • Vous pouvez faire cela gratuitement avec JavaScript :
     
     

     Code :

     Sélectionner tout - Visualiser dans une fenêtre à part

     1
     2
     const headers = document.querySelectorAll('h2, h3, h4');
     const toc = headers.map(h => `<li>${h.textContent}</li>`).join('');

     
     
   • Moi : "Je viens de vous faire économiser 360 $/an avec 2 lignes de code"
   
   
2. Suivi de l'historique des versions
   
   
   • Vous voulez suivre vos modifications dans un éditeur WYSIWYG ? Soyez prêt à payer pour une fonction de suivi de l'historique. Sérieusement, même en 2025, ces éditeurs font payer ce que Git et GitHub font depuis des décennies - gratuitement.
     
     
   • Éditeur WYSIWYG : "Seulement 49,99 $/mois pour notre “Professional History Suite”".
     
     
   • En attendant, utilisez Git :
     
     

     Code :

     Sélectionner tout - Visualiser dans une fenêtre à part

     1
     2
     3
     git add .
     git commit -m "Changed a comma to a period. Very important."
     git push

   • Imaginez que vous l'expliquiez à votre supérieur :
     
     
     • Directeur : "Pourquoi le budget est-il dépassé ?"
     • Vous : "Oh, nous l'avons dépensé pour une fonctionnalité que Git offre gratuitement."
     • Le manager : Annule l'abonnement à l'éditeur WYSIWYG.
     
     
   • Coût : Gratuit (plus la possibilité inestimable d'écrire des messages de validation sarcastiques)
   
   
3. Systèmes de numérotation avancés
   
   
   • WYSIWYG Editor : "Vous débloquerez la numérotation hiérarchique pour seulement 39,99 $/mois !"
     
     
   • Devinez quoi ? Vous devrez débourser de l'argent supplémentaire pour cette fonctionnalité "premium". C'est presque risible, comme si l'on demandait à quelqu'un de payer un supplément pour compter jusqu'à 10. Pendant ce temps, les codeurs manuels s'amusent à créer ces listes avec <ol> et type="1"
   • Vous pouvez obtenir une "numérotation hiérarchique" en utilisant simplement quelques feuilles de style CSS.
     
     

     Code :

     Sélectionner tout - Visualiser dans une fenêtre à part

     1
     2
     3
     4
     5
     6
     7
     8
     9
     10
     11
     12
     <style>
        body { counter-reset: section; }
        h1 { counter-reset: subsection; }
        h1::before {
         counter-increment: section;
         content: counter(section) ". ";
        }
        h2::before {
         counter-increment: subsection;
         content: counter(section) "." counter(subsection) " ";
        }
     </style>

   • Le coût : Le temps qu'il faut pour boire un café en écrivant ce CSS

Le paradoxe de l'intégration de l'IA

"Mais attendez !" Je vous entends vous écrier : "Les éditeurs WYSIWYG modernes sont dotés de l'IA ! Ils peuvent générer un code parfait !"

Ah oui, la promesse de l'IA. Bien que l'intégration de l'IA ait effectivement amélioré la production de code, elle a créé son propre ensemble de défis. De plus, les outils d'IA pour blogueurs sont un peu coûteux et, après avoir payé pour cela, les défis ne sont pas résolus.

Le problème de la sur-optimisation

Les éditeurs WYSIWYG modernes alimentés par l'IA essaient parfois d'être trop intelligents, de générer :

• Des sélecteurs CSS trop complexes qui entrent en concurrence avec vos styles existants
• Des polyfills JavaScript inutiles "juste au cas où"
• Des correctifs d'accessibilité automatisés qui brisent en fait les relations ARIA
• Des "optimisations" SEO qui entrent en conflit avec la stratégie SEO existante de votre site

C'est comme si vous aviez un stagiaire trop enthousiaste qui en a appris juste assez pour être dangereux. Bien sûr, il essaie d'aider, mais soudain votre simple article de blog contient suffisamment de JavaScript pour lancer une navette spatiale qui est sur le point de s'écraser dans un océan.

La réalité multiplateforme en 2025

Le paysage moderne du développement web est plus complexe que jamais.

Nous ne construisons plus seulement pour les navigateurs Web, mais aussi pour Windows, Mac, Linux, Android et iOS.

Le cauchemar des plates-formes multiples

Lorsque votre contenu doit fonctionner sur plusieurs plates-formes :

• les navigateurs Web traditionnels
• les navigateurs Web modernes
• les applications mobiles natives
• les applications Web progressives
• les assistants vocaux
• les lecteurs d'écran
• les appareils portables
• les écrans intelligents

les éditeurs WYSIWYG génèrent souvent un code qui est à peu près aussi portable qu'un gilet de sauvetage en béton. Bien qu'ils puissent offrir des options de "conversion vers le mobile", le résultat nécessite généralement plus de nettoyage que la chambre d'un adolescent.


La taxe sur les performances

En 2025, les performances du web ne se limitent pas aux temps de chargement des pages :

• Les fondamentaux du web
• L'optimisation de l'Edge Computing
• L'efficacité de l'utilisation des données
• Les performances d'exécution
• La gestion de la mémoire
• L'empreinte carbone (oui, ça existe maintenant)

Les coûts cachés

Les éditeurs WYSIWYG modernes incluent souvent :

• Des bundles JavaScript gonflés pour des fonctionnalités de base
• Des CSS redondants qui s'opposent à votre système de conception
• Des requêtes HTTP supplémentaires pour des fonctionnalités dont vous n'avez pas besoin
• Des éléments DOM inutiles qui ont un impact sur les performances de rendu
• Des fuites de mémoire dues à des fonctions de collaboration en temps réel mal optimisées

C'est comme si vous commandiez une salade mais que l'on vous livrait une ferme entière à votre porte.


La question sensible sur la sécurité

La sécurité des sites web modernes n'est pas une plaisanterie, et les éditeurs WYSIWYG peuvent être comme si vous laissiez votre porte d'entrée ouverte avec un panneau "Biscuits gratuits à l'intérieur".

Préoccupations modernes en matière de sécurité

Le paysage de la sécurité en 2025 comprend :

• Conformité CSP
• Prévention XSS
• Attaques de la chaîne d'approvisionnement par le biais d'intégrations tierces
• Réglementations sur la confidentialité des données (RGPD, CCPA, et tout autre nouvel acronyme tombé cette ANNÉE)
• Modèles de sécurité zéro confiance

De nombreux éditeurs WYSIWYG exigent une relaxation CSP qui ferait faire une poussée d'urticaire à votre équipe de sécurité.

Conclusion

D'ici 2025, il est clair que si les éditeurs WYSIWYG ont beaucoup progressé en termes d'accessibilité et de facilité d'utilisation, ils restent une option coûteuse pour le support multiplateforme. Qu'il s'agisse de code surchargé ou de fonctionnalités qui devraient être gratuites, les coûts cachés s'accumulent rapidement.

Pour les développeurs qui accordent de l'importance au contrôle, à la flexibilité et, surtout, à leur compte en banque, le codage manuel reste la meilleure solution. Après tout, rien ne vaut la satisfaction de construire quelque chose à partir de zéro, sans le moindre paywall en vue.

L'avenir ne consiste pas à éviter complètement le WYSIWYG, mais à utiliser le bon outil pour le bon travail. Cela signifie parfois coder manuellement votre contenu, parfois utiliser une interface WYSIWYG, et parfois créer votre propre solution d'édition de contenu.

Article sous licence Creative Commons Attribution 4.0 International.


Source : Why Developers and Companies Should Think Twice Before Using WYSIWYG Editors

Et vous ?

Pensez-vous que cet avis est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Pourquoi le « Vibe Coding » me donne envie de vomir, par Kush Creates

Pourquoi vous ne devriez pas supprimer des fonctionnalités : Lettre d'amour d'un développeur au code « impopulaire », par Kush Creates

[FrancoisA]

Pour rendre cet article compréhensible il faudrait donner des exemples d'éditeurs WYSIWYG (What Yous See Is What You Get) actuels ?

Car cela fait des années que FrontPage n'est plus vendu par Microsoft.

[IGY-Francia]

J’ai tellement de choses à dire sur ce sujet parce que ça touche pas mal de mes expériences mais je vais essayer de faire court.

Je pense que le titre ne devrait pas contenir “développeurs” mais juste “entreprises”. Avez-vous déjà entendu un dev dire: “Bon je vais opter pour Wordpress ou Squarespace !” Même un développeur PHP voudra quelque chose fait main avec ses lignes de code, au lieu de se contenter de Wordpress. A mon avis, convaincre un développeur à préférer le codage manuel c’est comme demander à un peintre d’utiliser ses pinceaux (alors oui il peut utiliser ses doigts mais là n’est pas le sujet).

En revanche, une entreprise pourrait bien avoir besoin d’aide pour comprendre les enjeux d’un WYSIWYG . Après, tout est dit dans votre introduction lorsque vous visez les “nombreux géants de la technologie”.

“Le contrôle direct du code” est pratique lorsque l’entreprise a une équipe interne de devs prêts à travailler dessus à tout moment et pas juste un webmaster qui gère le site de temps en temps. Je dirai donc que c’est surtout une question de budget, influencée par la taille de l’entreprise et ses priorités.

Et wow j’adore la comparaison avec EA et ses extensions. Pour avoir travaillé sur Shopify, WIX et Wordpress je confirme que les plugins et applications payants sont assez frustrants.

“Des sélecteurs CSS trop complexes qui entrent en concurrence avec vos styles existants”

Le nombre de fois où j’ai dû “coder” pour gérer ce genre de problème sur Shopify ...

“Des bundles JavaScript gonflés pour des fonctionnalités de base” et “Des CSS redondants qui s'opposent à votre système de conception”

Pour ceux qui seraient tentés d’utiliser Wordpress/Elementor, préparez-vous à rencontrer ce genre de problèmes.

Sinon juste pour information, les WYSIWYG visent les Web Designer qui ne s’arrêtent pas juste aux maquettes et prototypes et non pas les développeurs à proprement parler. Le premier argument de vente des WYSIWYG tourne autour de la même idée: pas besoin de savoir coder (le no code). D’ailleurs je ne pense même pas qu’un vrai développeur s’attardera sur des WYSIWYG à moins que le client l’impose.

J'ai créé et optimisé plusieurs sites avec ces CMS et j’admets que c’est la solution de facilité (par excellence). Cela dit, je préfère de loin m’occuper du SEO d’un site construit à partir de ces plateformes plutôt que de demander à un dev de modifier le site à chaque fois.