+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
En 1984, le premier clic a tout changé
Quarante ans. C’est le temps qu’il a fallu pour que la question reste entière.
En 1984, Apple introduisait le Macintosh avec une promesse simple : ce que vous voyez à l’écran, c’est ce que vous obtenez sur le papier. Le paradigme WYSIWYG — What You See Is What You Get — était né. Quelques années plus tard, il envahissait la création web. Dreamweaver, FrontPage, puis WordPress, Wix, Webflow… La promesse n’a jamais changé : créer sans coder.
Quarante ans plus tard, le débat n’est toujours pas tranché. Et pourtant, quelque chose a fondamentalement changé dans les workshops et les agences web en 2024.
Voici ce qu’on voit réellement sur le terrain — et pourquoi la vraie question n’est plus “code ou interface visuelle”, mais “lequel pour quel usage, à quel moment du projet”.
L’histoire d’un faux duel
Posez la question à n’importe quel développeur web des années 2000 : Dreamweaver ou le Bloc-notes ? Vous obtiendrez une réponse tranchée, souvent passionnée, parfois méprisante.
Les développeurs “purs” regardaient les outils visuels comme des générateurs de code spaghetti. Les designers les adoraient parce qu’ils n’avaient pas à apprendre le CSS. Les deux camps se sont longtemps ignorés — ou combattus.
Ce qu’on oublie, c’est que ce duel a toujours été artificiel.
Un outil WYSIWYG n’a jamais prétendu remplacer un développeur senior sur une application complexe. Et un développeur qui écrit tout à la main n’a jamais été la solution idéale pour une TPE qui veut juste mettre à jour sa page “Nos services” une fois par mois — un arbitrage qu’on a déjà détaillé à propos des constructeurs visuels sous WordPress.
Le problème, c’est qu’on a longtemps présenté les deux approches comme mutuellement exclusives. Soit vous codez, soit vous utilisez un constructeur visuel. Soit vous êtes sérieux, soit vous faites du Wix.
Cette vision binaire a coûté cher à beaucoup de projets.
Ce que 15 ans de projets web m’ont appris
Sur les projets qu’on a menés chez GDM-Pixel, j’ai utilisé les deux approches. Et j’ai surtout appris quand chacune casse.
Les outils visuels cassent quand :
- Le client veut une fonctionnalité spécifique que le constructeur ne prévoit pas
- La performance devient critique (un Elementor chargé, c’est facilement 4-6 secondes de chargement)
- La structure de données est complexe (catalogue produit avec variantes, tarification dynamique, intégration ERP)
- Le projet doit évoluer sur 5 ans sans dépendre d’un éditeur tiers
Le code pur casse quand :
- Le client doit mettre à jour son contenu lui-même sans appeler l’agence
- Le budget ne justifie pas 3 semaines de développement pour 5 pages statiques
- Le time-to-market est critique et on n’a pas le luxe de tout construire from scratch
Ce n’est pas une question de religion. C’est une question de contexte.
Ce qu’on voit concrètement chez nos clients : les projets qui se passent le mieux sont ceux où on a choisi l’outil adapté à la contrainte dominante — pas l’outil qu’on préfère par défaut.
2024 : le vrai changement de paradigme
Voici où ça devient intéressant.
L’opposition code vs WYSIWYG était pertinente quand les deux camps étaient vraiment séparés. Ce n’est plus le cas.
Figma a cassé la frontière côté design. Vous dessinez visuellement, mais vous exportez des tokens de design, des variables, une structure qui parle directement au code. Les composants Figma se mappent sur des composants React ou Astro. Le gap entre “j’ai designé” et “c’est codé” s’est réduit de façon spectaculaire.
Webflow a fait pareil côté développement. Vous glissez des blocs visuellement, mais derrière, le code généré est propre, sémantique, maintenable. Ce n’est plus le code spaghetti de Dreamweaver 2003.
Et surtout — l’IA a changé les règles du jeu.
Aujourd’hui, avec Claude Code ou GitHub Copilot, un développeur qui écrit du code “à la main” ne l’écrit plus vraiment à la main. Il dirige. Il valide. Il architecture. L’IA génère les 70% de code répétitif. Ce qui reste, c’est la logique métier, les décisions d’architecture, les optimisations.
Du coup, la frontière entre “je code” et “j’utilise un outil visuel” est devenue floue dans les deux sens.
“The best interface is no interface — but until we get there, the best interface is the one your team actually uses.” — Golden Krishna, The Best Interface Is No Interface
Le vrai coût caché de chaque approche
Vous passez combien d’heures par semaine à gérer les mises à jour d’un site WordPress surchargé de plugins ?
C’est la question que personne ne pose quand on choisit un outil. On regarde le coût de création. Rarement le coût de possession sur 3 ans.
Un site sous constructeur visuel grand public :
- Création rapide, budget initial maîtrisé
- Mais : dépendance à l’éditeur, performance souvent dégradée, personnalisation limitée, migrations douloureuses
- Coût réel sur 3 ans : abonnement mensuel + temps passé à contourner les limitations + refonte quand les besoins évoluent
Un site développé sur mesure avec une stack moderne :
- Coût initial plus élevé, délai de livraison plus long (sauf si vous avez industrialisé, cf. notre workflow)
- Mais : performance maximale, zéro dépendance tiers, évolutivité totale, propriété complète du code
- Coût réel sur 3 ans : maintenance légère, évolutions ciblées, aucun abonnement parasite
Un site hybride (CMS headless + front-end moderne) :
- Le meilleur des deux mondes sur le papier
- Mais : complexité technique plus élevée, nécessite une équipe qui maîtrise les deux sides
- Coût réel sur 3 ans : dépend entièrement de la qualité de l’architecture initiale
Mon conseil pour une TPE avec un budget limité : ne choisissez pas en fonction de ce que vous voulez créer aujourd’hui. Choisissez en fonction de ce que vous devrez modifier dans 18 mois — c’est aussi ce qui détermine quand une refonte est vraiment nécessaire plutôt qu’une simple évolution.
Notre stack actuel — et pourquoi on a tranché
Chez GDM-Pixel, on a arrêté de débattre. On a choisi.
Notre stack de production pour les sites vitrines et e-commerce : Figma pour le design → Astro + Tailwind pour le front → CMS headless pour le contenu → Claude Code pour l’accélération du développement.
Pourquoi ce choix ?
Astro génère du HTML statique par défaut. Résultat : des scores Lighthouse au-dessus de 95 systématiquement. Aucun constructeur visuel ne peut rivaliser sur ce critère.
Tailwind supprime 80% des décisions CSS répétitives. On code plus vite, le code est plus cohérent, la maintenance est triviale.
Claude Code génère les composants répétitifs (cartes, sections, formulaires) en quelques secondes à partir de nos prompts standardisés. Ce qui prenait 2 heures prend maintenant 20 minutes.
Le CMS headless (Sanity ou Directus selon le projet) donne au client une interface d’édition claire et simple, sans qu’il touche jamais au code.
Résultat concret : on livre des sites 5-page en 3 jours. Des projets qui prenaient 3 semaines il y a 5 ans.
Ce n’est pas du WYSIWYG. Ce n’est pas du code pur non plus. C’est un workflow industrialisé qui prend le meilleur des deux mondes.
“Tools are only as good as the workflow they fit into.” — Anonyme, mais vrai dans tous les projets qu’on a menés.
Ce que ça change pour vous — chef d’entreprise ou décideur
Si vous êtes en train de choisir comment refaire votre site, voici les trois questions qui comptent vraiment :
1. Qui va maintenir le contenu au quotidien ? Si c’est vous ou un collaborateur non-technique, vous avez besoin d’une interface d’édition simple. Pas forcément d’un constructeur visuel complet — un CMS bien configuré suffit largement.
2. Quelles sont vos contraintes de performance ? Un site e-commerce lent perd des ventes. Google l’a mesuré : chaque seconde de chargement supplémentaire peut réduire les conversions de 7 à 12%. Si la performance est critique, le code sur mesure n’est pas un luxe — c’est un investissement.
3. Votre site doit-il évoluer dans 2 ans ? Si oui, l’architecture compte autant que l’esthétique. Un site beau mais bâti sur une stack fragile vous coûtera une refonte complète au lieu d’une simple évolution. C’est précisément ce qu’on sécurise dès la création de votre site internet.
Ces trois questions valent mieux que n’importe quel débat philosophique sur le code vs le visuel.
En résumé : trois points à retenir
Le débat code vs WYSIWYG est dépassé. La vraie question est : quelle combinaison d’outils correspond à votre contexte projet, votre budget de maintenance et vos contraintes d’évolution ?
L’IA a radicalement réduit le coût du développement sur mesure. Ce qui justifiait de choisir un constructeur visuel “pour aller vite” est en train de disparaître. Livrer vite avec du code de qualité est désormais accessible, à condition d’avoir industrialisé son workflow.
La performance n’est pas négociable en 2024. Les Core Web Vitals de Google sont un facteur de référencement direct. Un site lent, c’est moins de visibilité et moins de conversions — quel que soit l’outil utilisé pour le créer.
Vous refaites votre site en 2024 ?
Ne choisissez pas votre outil avant d’avoir défini votre contrainte principale.
Chez GDM-Pixel, on commence tous nos projets par un diagnostic de 30 minutes : quels sont vos vrais besoins, quelles sont vos contraintes réelles, et quelle stack y répond le mieux — sans survendre et sans idéologie.
Si votre projet nécessite un audit technique plutôt qu’une refonte complète, on vous le dit. Si un CMS standard suffit, on ne vous vend pas du développement sur mesure.
Quarante ans après le premier clic WYSIWYG, la meilleure interface reste celle qui vous fait atteindre vos objectifs business — pas celle qui impressionne en démo.
Contactez GDM-Pixel pour un diagnostic sans engagement. On vous dit ce qui marche vraiment pour votre cas.
Réseaux sociaux
Analyser avec l'IA
