Quelle différence entre un intégrateur et un développeur WordPress ?

Sur un projet WordPress, l’intégrateur transforme une maquette graphique en pages, en modèles et en styles : il travaille en HTML et en CSS, dans un thème, avec un constructeur de pages ou dans l’éditeur de blocs. Le développeur écrit le code qui crée les fonctionnalités (PHP, JavaScript, hooks, extensions, API) et il en répond dans la durée : sécurité, performance, compatibilité avec les mises à jour. Autrement dit, l’intégrateur assemble avec des outils existants, le développeur fabrique ce qui manque. Sur WordPress, la frontière est plus floue qu’ailleurs, parce que les constructeurs et l’éditeur de site permettent d’aller loin sans écrire de code.

Je suis développeur WordPress depuis quatorze ans et je fais aussi de l’intégration, sous Avada et sous Elementor. Je compare ici les deux métiers du point de vue de celui qui fait réaliser son site : un tableau comparatif, la définition de chaque métier, des tâches concrètes classées, puis les questions à poser pour choisir le bon profil.

Intégrateur et développeur WordPress : la différence en un coup d’œil

Les deux rôles sur un projet WordPress, résumés ligne par ligne :

Qu’est-ce qu’un intégrateur web ?

Un intégrateur web transforme une maquette graphique en pages lisibles par un navigateur, en HTML et en CSS, sans changer le design ni inventer de fonctionnalité. On l’appelle aussi intégrateur HTML, intégrateur front-end ou développeur front-end.

Dans un projet, il intervient après le designer et avant le développeur qui programme les fonctionnalités plus complexes, ou en même temps que lui. La fiche métier de l’Onisep le présente aussi comme l’un des garants de l’accessibilité sur le web. Ses responsabilités vont au-delà de la ressemblance avec la maquette :

• Le responsive : des pages qui s’adaptent aux différentes tailles d’écran, du smartphone au grand écran, vérifiées sur de vrais appareils ;
• La compatibilité entre navigateurs : un rendu cohérent sur Chrome, Safari, Firefox et Edge ;
• L’accessibilité : hiérarchie des titres, contrastes suffisants, navigation au clavier, textes alternatifs des images, en s’appuyant sur les règles WCAG ;
• Le poids des pages : images compressées et redimensionnées, polices limitées, pas de CSS inutile.

L’intégrateur WordPress aujourd’hui : constructeurs, thèmes blocs et theme.json

Sur WordPress, l’intégrateur écrit moins de HTML à la main qu’il y a dix ans. Il travaille surtout dans trois environnements :

• Les constructeurs de pages : Avada Builder, Elementor (son Theme Builder, dans la version Pro, gère en-têtes, pieds de page et modèles), Divi. Je réalise ce type de travail, par exemple l’intégration d’une maquette Figma sous Elementor Pro : la maquette devient des pages et des modèles réutilisables, réglés pour chaque taille d’écran.
• L’éditeur de site et les thèmes blocs : les modèles et les compositions (patterns) se construisent dans l’éditeur, tandis que les réglages et les styles globaux (couleurs, typographies, espacements) se déclarent dans le fichier theme.json.
• Le thème enfant : sur un thème classique, les fichiers de modèle modifiés et le CSS personnalisé vont dans un thème enfant, jamais dans le thème parent, dont les fichiers sont remplacés à chaque mise à jour.

Voici, par exemple, la déclaration d’une palette de couleurs dans le fichier theme.json d’un thème blocs (version 3 du format, celle de WordPress 6.6 et des versions suivantes) :

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 3,
	"settings": {
		"color": {
			"palette": [
				{ "slug": "nuit", "color": "#05233e", "name": "Bleu nuit" },
				{ "slug": "menthe", "color": "#4fd8c1", "name": "Menthe" }
			]
		}
	}
}

C’est de la configuration déclarative : un intégrateur la maîtrise sans écrire une ligne de PHP. Les deux couleurs apparaissent ensuite dans le sélecteur de couleurs de l’éditeur, pour tous les blocs qui gèrent la couleur.

Ce qu’un intégrateur livre, et où il s’arrête

Un bon intégrateur livre des pages fidèles à la maquette, des modèles réutilisables plutôt que des pages copiées-collées, un rendu testé sur mobile, les bases du référencement (un seul titre principal, des titres hiérarchisés, des images légères avec texte alternatif) et des formulaires montés avec une extension éprouvée. Une intégration peut aller loin sans code : voyez cet exemple de modèle de page produit WooCommerce sous Elementor, avec des modèles distincts selon le type de produit et leurs conditions d’affichage.

L’intégrateur ne s’occupe généralement pas du codage complexe ni des fonctionnalités avancées, laissant ces tâches aux développeurs. La limite arrive quand aucune extension ne fait exactement ce qu’il faut, ou quand il faudrait en empiler plusieurs pour s’en approcher. À ce stade, continuer à « assembler » coûte souvent plus cher qu’écrire le bon code.

Qu’est-ce qu’un développeur WordPress ?

Un développeur WordPress écrit du code PHP et JavaScript qui s’appuie sur les API de WordPress pour créer des thèmes, des extensions, des blocs et des connexions avec d’autres logiciels, et il répond de ce code dans la durée. Il s’occupe du développement de fonctionnalités personnalisées et de la résolution de problèmes complexes.

Il intervient idéalement dès le début du projet, pour définir les exigences techniques et décider ce qui sera confié à des extensions existantes ou écrit sur mesure. Je décris mon travail de développeur WordPress sur une page dédiée.

Ce qu’il écrit : thèmes, extensions, blocs et connexions

• Des hooks : les actions et les filtres permettent d’intervenir sur le comportement de WordPress, d’un thème ou d’une extension. Exemple détaillé : comment modifier une extension avec des hooks, sans toucher à son code.
• Des extensions sur mesure : les fonctionnalités propres au site, rangées hors du thème pour survivre à un changement de thème.
• Des thèmes sur mesure, écrits en respectant les standards de codage et les bonnes pratiques de WordPress.
• Des types de contenu et des champs personnalisés : réalisations, événements, fiches de produits techniques.
• Des blocs pour l’éditeur, en JavaScript et en React, avec les outils officiels de WordPress.
• Des connexions à des services externes par l’API REST de WordPress ou l’API du service concerné : paiement en ligne, CRM, ERP, logiciel de réservation.

Exemple : une petite extension qui déclare un type de contenu « Projet ».

<?php
/**
 * Plugin Name: Mon site – fonctionnalités
 * Description: Déclare le type de contenu « Projet ».
 * Text Domain: monsite
 */

defined( 'ABSPATH' ) || exit;

add_action( 'init', 'monsite_register_projet_post_type' );

function monsite_register_projet_post_type() {
	register_post_type(
		'monsite_projet',
		array(
			'labels'       => array(
				'name'          => __( 'Projets', 'monsite' ),
				'singular_name' => __( 'Projet', 'monsite' ),
			),
			'public'       => true,
			'has_archive'  => true,
			'show_in_rest' => true,
			'menu_icon'    => 'dashicons-portfolio',
			'supports'     => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
			'rewrite'      => array( 'slug' => 'projets' ),
		)
	);
}

Comme toute fonctionnalité propre au site, ce code vit dans une extension : il reste actif si le thème change. Ses fonctions et son type de contenu sont préfixés (monsite_) pour éviter toute collision. L’option show_in_rest rend le type de contenu utilisable dans l’éditeur de blocs. Après l’activation, il faut enregistrer à nouveau les permaliens (Réglages > Permaliens) pour que l’adresse /projets/ réponde. Tous les paramètres sont décrits dans la documentation officielle des types de contenu.

Ce dont il répond : sécurité, performance et mises à jour

Écrire du code qui fonctionne ne suffit pas. Le développeur répond de ce code tant que le site vit :

• Sécurité : vérifier les droits de l’utilisateur (current_user_can()), protéger les formulaires par des nonces, nettoyer les données reçues et échapper les données affichées, comme le demandent les règles de sécurité de WordPress.
• Performance : des requêtes à la base de données mesurées, du cache là où il sert, des scripts et des styles chargés seulement sur les pages qui en ont besoin.
• Compatibilité : en octobre 2026, WordPress en est à la version 7.1.3, et wordpress.org recommande PHP 8.3 ou plus. WordPress fonctionne encore avec PHP 7.4, mais cette version ne reçoit plus de correctifs de sécurité, pas plus que PHP 8.0 et 8.1. D’après le calendrier de php.net, PHP 8.2 n’en reçoit que jusqu’au 31 décembre 2026. Le code doit donc fonctionner sur les versions encore maintenues.
• Méthode : un code versionné (avec Git), documenté et remis au client. Sur les sites que je maintiens, chaque mise à jour passe d’abord par une préproduction, une copie du site, avant d’atteindre le site en ligne.

Intégrateur web ou développeur web : où passe la frontière sur WordPress ?

Sur un projet complet, l’ordre classique reste valable : le designer crée la maquette, l’intégrateur la transforme en pages, et le développeur ajoute les fonctionnalités dynamiques nécessaires. Mais la meilleure façon de voir la frontière est de partir des tâches. Voici des demandes fréquentes sur un site WordPress, et le profil qui s’en charge :

• Changer les couleurs, les polices et les espacements : intégrateur, dans les styles globaux, le kit Elementor ou les options globales d’Avada.
• Créer le modèle des articles ou des pages produit : intégrateur, avec le constructeur de modèles d’Avada ou d’Elementor, ou dans l’éditeur de site.
• Ajouter un formulaire de contact : intégrateur, avec une extension de formulaires reconnue.
• Afficher des champs personnalisés : intégrateur, avec ACF et les balises dynamiques du constructeur ; développeur dès qu’une logique entre en jeu (calcul, condition, tri).
• Calculer un tarif, connecter un CRM ou un ERP, ajouter une règle de commande WooCommerce : développeur.
• Corriger une erreur critique ou un site devenu lent : développeur, parce qu’il faut lire les journaux d’erreurs, mesurer les requêtes et comprendre le code des extensions.

Après la mise en ligne, le partage reste le même : l’intégrateur peut effectuer des mises à jour visuelles mineures, tandis que le développeur se concentre sur les mises à jour de sécurité et les nouvelles fonctionnalités.

La différence tient aussi aux réflexes. Devant un besoin, l’intégrateur cherche d’abord l’extension qui le couvre ; le développeur se demande d’abord s’il vaut mieux l’écrire. Les deux réflexes sont sains. Le bon choix dépend du coût sur la durée : une extension maintenue par d’autres, mais qui ajoute du code inutile et une dépendance, contre un code plus léger, mais qu’il faudra maintenir soi-même.

Les profils hybrides : intégrateur-développeur, front-end, webmaster

Les intitulés se recouvrent, et ils ne disent pas toujours ce que la personne fait vraiment :

• Le développeur front-end est souvent un intégrateur qui va plus loin en JavaScript.
• Le développeur back-end travaille côté serveur (PHP, base de données, API) ; le développeur full stack couvre les deux côtés.
• Le webmaster fait vivre le site au quotidien (contenus, mises à jour, statistiques) sans forcément coder.
• Dans les petites structures, une seule personne cumule souvent ces rôles.

C’est mon cas : je suis développeur, et une partie de mes projets relève de l’intégration, sous Avada, ma spécialité, ou sous Elementor. L’intérêt de faire appel à un développeur WordPress freelance qui intègre aussi est simple : il sait quand un réglage suffit et quand du code se justifie. Il évite ainsi de forcer un constructeur à faire ce que quelques lignes de PHP feraient mieux, et inversement d’écrire du code pour ce qu’un réglage fait déjà.

Comment choisir entre un intégrateur et un développeur pour votre site WordPress

Selon votre projet

• Site vitrine à partir d’une maquette, avec des extensions courantes : un intégrateur suffit, tant que le design prime et que les fonctionnalités se limitent à ce que proposent le thème et les extensions.
• Boutique WooCommerce standard : un intégrateur pour la mise en page, un développeur dès qu’une règle sort du standard (tarifs par client, livraison particulière, synchronisation de stock).
• Fonctionnalité métier, connexion à une API, extension sur mesure : un développeur.
• Thème sur mesure : un développeur. Si vous hésitez sur la base du site, voyez d’abord comment choisir entre un thème WordPress gratuit, premium ou sur mesure.
• Reprise d’un site existant, lent ou cassé : un développeur d’abord, pour le diagnostic ; l’intégration vient ensuite.

Les questions à poser avant de confier le projet

• Quelle part du site sera faite avec le constructeur ou l’éditeur, et quelle part en code ?
• Où sera rangé le code personnalisé : dans un thème enfant, dans une extension dédiée ?
• Quelles extensions seront installées, et pourquoi chacune ?
• Comment les mises à jour seront-elles testées avant d’arriver sur le site en ligne ?
• Qui détiendra les accès, les licences et le code à la fin du projet ?
• Pourrai-je modifier mes contenus moi-même, et avec quel outil ?
• Le rendu mobile et l’accessibilité seront-ils testés ?
• Le site tournera-t-il sur une version de PHP encore maintenue ?

Les signaux d’alerte

• Une extension pour chaque besoin, même minime.
• Des modifications faites directement dans le thème parent ou dans une extension tierce : elles disparaissent à la mise à jour suivante.
• Aucun environnement de test : les mises à jour se font directement sur le site en ligne.
• Du code, des comptes ou des licences qui restent au nom du prestataire.

Questions fréquentes sur l’intégrateur et le développeur web

En résumé

L’intégrateur transforme une maquette en site WordPress avec les outils existants : thème, constructeur, éditeur de site et extensions. Le développeur écrit ce qui manque et répond de la sécurité, de la performance et de la compatibilité de ce code. Un site vitrine bien conçu peut ne demander que de l’intégration ; dès qu’une règle métier, une connexion à un autre logiciel ou un diagnostic entre en jeu, il faut un développeur. Et rien n’empêche que les deux rôles soient tenus par la même personne.

Vous ne savez pas si votre projet relève de l’intégration ou du développement ? Décrivez-le-moi : je vous dirai ce qui peut se faire avec les outils existants et ce qui demande du code.

Mis à jour en octobre 2026 par un développeur WordPress freelance senior.