Ce que les outils AI design ont changé pour vos clients

Il y a deux ans, un client arrivait avec un brief et attendait que vous conceviez. Aujourd'hui, il arrive avec une maquette. Parfois plusieurs. Générées en 20 minutes avec v0, Galileo AI ou Midjourney couplé à un prompt soigné. La maquette est propre, les couleurs sont cohérentes, le layout tient la route.

La conséquence directe : la phase de conception ne vous appartient plus. Le client ne vous demande plus "comment ça devrait ressembler", il vous demande "est-ce que vous pouvez coder exactement ça ?". Ce glissement de rôle paraît anodin. Il ne l'est pas.

Parce que les maquettes générées par IA ne sont pas contraintes par la réalité technique d'un CMS. Elles ne connaissent pas WordPress, WooCommerce, les hooks, les Custom Post Types ni les limites d'un constructeur de pages. Elles montrent ce qui est visuellement possible. Pas ce qui est facilement implémentable.

Le paradoxe : plus d'IA design, plus de dev custom

On aurait pu penser que des maquettes plus rapides et plus abouties réduiraient le temps de développement. C'est l'inverse qui se produit sur le terrain. Les maquettes générées par IA sont souvent trop ambitieuses pour ce que Gutenberg ou Elementor peuvent produire nativement.

Un layout avec un scroll horizontal sur une section, une animation de reveal par ligne, un grid asymétrique avec images en fond : tout ça est faisable, mais rien de ça ne sort d'un thème standard. Ce sont des heures de dev custom, de CSS sur-mesure, parfois des blocs Gutenberg développés de zéro.

Le problème de l'écart visuel

Le client a vu sa maquette IA rendue avec des polices parfaites, des ombres précises, des animations fluides. Il attend un résultat identique. L'écart entre la maquette et ce que sort un thème par défaut crée une insatisfaction immédiate. Combler cet écart, c'est du dev custom : pas une option, une nécessité.

Pour les agences qui géraient surtout des sites semi-standard, c'est un changement de nature des missions. Là où vous livriez un thème configuré, vous livrez maintenant un thème enfant avec 400 lignes de CSS custom, trois blocs Gutenberg sur-mesure et des scripts d'animation.

Ce que Figma exporte, et ce qu'il ne peut pas produire

Figma, même augmenté par des plugins IA, génère des assets et des specs. Il ne génère pas de code WordPress fonctionnel. Les outils comme Locofy ou Anima peuvent produire du HTML/CSS statique, parfois du React. Ce n'est pas du WordPress. Ce n'est pas du WooCommerce.

Les éléments que les maquettes IA incluent systématiquement et qui demandent du dev custom une fois dans WordPress :

01
Les animations d'entrée et scrolling
Reveal au scroll, éléments qui glissent, compteurs animés : rien de ça dans Gutenberg natif. Nécessite soit un plugin dédié (GreenSock, AOS), soit du JavaScript custom enqueued proprement via wp_enqueue_scripts.
02
Les layouts qui sortent de la colonne centrale
Sections pleine largeur avec contenu qui déborde, grids asymétriques, éléments positionnés par rapport à la fenêtre : l'éditeur de blocs les déteste. Il faut des blocs custom avec align="full" et du CSS qui casse le conteneur parent.
03
Les typographies variables et effets de texte
Dégradés sur les titres, polices variables avec optical sizing, mix de weights dans un même titre : CSS custom, chargement de polices variable via @font-face, et souvent un conflit avec les polices déjà chargées par le thème.
04
Les composants interactifs sans plugin
Tabs, accordéons custom, sliders avec logique spécifique, filtres AJAX sur un catalogue : les solutions plugin (Swiper, ACF + custom template) fonctionnent, mais ne produisent jamais exactement le rendu de la maquette. Le dernier kilomètre est toujours du custom.

Ce que ça implique concrètement pour l'estimation

Quand un client arrive avec une maquette IA, le premier réflexe est souvent de trouver le thème le plus proche et d'espérer que la configuration suffira. C'est rarement le cas. La bonne démarche est d'auditer la maquette avant d'estimer : identifier chaque élément visuel et classer chacun en "natif", "plugin", ou "dev custom".

La règle approximative sur les projets qu'on traite : une maquette IA bien léchée génère en moyenne 30 à 50% de dev custom en plus qu'une maquette livrée par un designer qui connaît les contraintes WP. Non pas parce que la maquette est mauvaise : parce qu'elle n'a pas été conçue avec les contraintes du CMS en tête.

Pour vos estimations

Ajoutez systématiquement un poste "dev custom UI" dans vos devis sur les projets avec maquette IA. Même si la maquette semble simple. Ce poste couvre le CSS sur-mesure, les animations, les blocs Gutenberg qui n'existent pas en natif. Ne pas le prévoir, c'est le payer sur votre marge.

Conclusion : l'IA design est une opportunité, pas un raccourci

Vos clients qui utilisent v0 ou Galileo ne cherchent pas à vous court-circuiter. Ils veulent aller plus vite sur la phase de vision et passer directement à l'exécution. C'est légitime. Ce que ça crée côté agence, c'est davantage de missions de réalisation pure, plus techniques, moins de conseil design.

Si votre équipe est à l'aise avec le dev custom WordPress, c'est une bonne nouvelle : les maquettes IA génèrent plus de travail, pas moins. Si vous gérez surtout de la configuration et de l'intégration standard, c'est le bon moment pour identifier les missions à externaliser plutôt que de les sous-estimer.

L'IA ne code pas ce que Figma dessine. Quelqu'un doit encore le faire.