Qu’est-ce que WordPress ? Le guide complet 2026 : fonctionnement, coûts, sécurité, IA et avenir du CMS

En août 2026, WordPress propulse 41,1 % de l’ensemble des sites web dans le monde, soit 59,1 % du marché des CMS identifiables (W3Techs). Le logiciel vient de vivre, avec la version 7.0 « Armstrong » sortie le 20 mai 2026, sa plus grosse mise à jour depuis l’arrivée de Gutenberg. Nous avons vu passer beaucoup de définitions approximatives de WordPress au fil des années. Voici la nôtre, sans survente, complète, et reliée à tout ce que nous avons déjà écrit de plus précis sur chaque sujet abordé : ce que c’est réellement, comment le logiciel s’articule, comment vous y mettre concrètement, et pourquoi il reste, en 2026, un choix par défaut solide pour construire un site.

WordPress, concrètement : un CMS, pas un « constructeur de sites »

WordPress est un CMS, un Content Management System (système de gestion de contenu) : un logiciel installé sur un serveur qui vous permet de créer, organiser et publier des pages, des articles et des médias, sans écrire de code pour chaque nouvelle page. Concrètement, il fait trois choses : il stocke votre contenu dans une base de données, il vous donne une interface d’administration pour le rédiger et le modifier, et il l’affiche sur le web selon la mise en page que vous avez choisie.

La différence avec un « constructeur de site » type Wix ou Squarespace : ces outils sont fermés, vous êtes locataire de leur plateforme. WordPress, lui, est libre et auto-hébergeable : vous décidez où il vit, qui y a accès, et vous pouvez en modifier le code si besoin. Cette distinction n’est pas cosmétique : elle détermine si vous possédez réellement votre site ou si vous en louez un accès révocable.

D’où vient WordPress : un bref historique

WordPress existe depuis 2003, né du fork d’un logiciel de blog plus ancien (b2/cafelog) par Matt Mullenweg et Mike Little. Ce qui, à l’origine, n’était qu’un outil de blog s’est transformé, version après version, en plateforme capable de faire tourner un site e-commerce, un média à fort volume de publication ou un site vitrine d’entreprise.

Deux ruptures ont marqué cette histoire plus que les autres. La première, en 2018 avec la version 5.0 : l’arrivée de Gutenberg, l’éditeur de blocs, qui a remplacé l’éditeur de texte classique (un grand champ de texte façon traitement de texte) par un système de blocs modulaires, chacun représentant un élément de contenu (paragraphe, image, citation, colonnes…). La transition a été mal accueillie sur le moment par une partie de la communauté, habituée à l’ancien éditeur, mais elle a posé les fondations techniques de tout ce qui a suivi. La seconde rupture, plus récente, est celle que nous détaillons plus loin dans ce guide : l’arrivée d’une infrastructure IA native dans le Core avec la version 7.0, en 2026.

Entre les deux, nous détaillons son extension logique, le Full Site Editing arrivé en version 5.9, qui a étendu cette logique de blocs à la mise en page entière du site (en-tête, pied de page, gabarits d’archive), pas seulement au contenu d’un article. C’est ce jalon qui a fait basculer WordPress d’un éditeur de contenu à un véritable éditeur de site dans son ensemble, sans dépendre systématiquement d’un thème figé pour la structure globale des pages.

Un logiciel libre et open source : ce que ça change vraiment pour vous

WordPress est distribué sous licence GPLv2 (ou ultérieure). Il est gratuit à télécharger, et son code source est ouvert : n’importe qui peut le lire, le modifier, le redistribuer. En pratique, pour vous, ça se traduit par trois choses concrètes :

• Pas de coût de licence. Le logiciel est gratuit ; vos seuls coûts réels sont l’hébergement, le nom de domaine et, éventuellement, des thèmes/extensions premium.
• Pas de fournisseur unique qui vous enferme. Vous pouvez migrer votre site d’un hébergeur à un autre sans perdre votre contenu, contrairement à un site construit sur une plateforme fermée.
• Un écosystème massif. Des dizaines de milliers de développeurs contribuent au noyau, aux thèmes et aux extensions ; c’est ce volume qui explique la richesse fonctionnelle du logiciel.

Cette licence libre a une conséquence directe et souvent sous-estimée : elle rend possible un écosystème de milliers de plugins et de thèmes tiers, gratuits ou payants, qui font la vraie force pratique de WordPress. C’est ce qu’on détaille dans la section suivante.

Un malentendu fréquent mérite d’être levé : « open source » ne veut pas dire « sans propriétaire » ni « sans règles ». Le nom WordPress, le logo et la marque appartiennent à la WordPress Foundation, qui les protège justement pour éviter qu’un acteur commercial ne s’approprie le nom du projet communautaire. Le code, lui, appartient à tout le monde au sens où chacun peut le réutiliser : c’est cette distinction entre la marque (protégée) et le code (libre) qui permet à la fois de préserver l’identité du projet et de garder un véritable écosystème ouvert autour de lui.

Comment ça s’articule : Core, thèmes, extensions

WordPress repose sur trois couches qu’il est utile de distinguer avant de vous lancer :

1. Le Core : le logiciel lui-même, maintenu par la fondation WordPress et sa communauté de contributeurs. C’est lui qui gère l’édition de contenu (l’éditeur de blocs Gutenberg), les utilisateurs, la sécurité de base, et depuis peu, une infrastructure IA native.
2. Les thèmes : ils définissent l’apparence de votre site (mise en page, typographie, couleurs). Vous pouvez changer de thème sans perdre votre contenu, celui-ci reste stocké indépendamment de l’habillage visuel. Même un détail technique comme le chargement des polices peut changer : nous expliquons pourquoi les polices Google des thèmes par défaut sont désormais servies en local, un changement discret mais réel pour la confidentialité et la performance.
3. Les extensions (plugins) : elles ajoutent des fonctionnalités que le Core n’a pas nativement (formulaire de contact, boutique en ligne, SEO, cache, sécurité renforcée…). C’est cette modularité qui permet à WordPress de servir aussi bien un blog personnel qu’un site e-commerce. Avant d’en installer un, mieux vaut savoir quels sont les pièges à éviter dans le choix d’un plugin WordPress, puis suivre le tuto complet pour l’installer étape par étape.

Deux notions techniques valent d’être connues avant d’aller plus loin, même sans coder soi-même. La première : le thème enfant (child theme), une petite extension d’un thème existant qui permet de personnaliser son apparence sans jamais toucher aux fichiers du thème d’origine. C’est ce qui évite qu’une mise à jour du thème n’écrase vos personnalisations. La seconde : les hooks (actions et filtres), le mécanisme interne qui permet à un plugin de « s’accrocher » à un moment précis du fonctionnement de WordPress pour en modifier le comportement, sans jamais éditer le Core lui-même. C’est ce système qui rend possible l’immense variété de plugins sans que chacun ait besoin de réécrire le logiciel.

Le revers de cette modularité : plus vous accumulez de plugins actifs, plus le risque de conflit entre deux extensions augmente (deux plugins qui modifient la même zone de l’administration, ou qui chargent des scripts incompatibles en front). La bonne pratique reste la même depuis toujours : n’installer que ce qui sert réellement, désactiver et supprimer ce qui ne sert plus, et tester un nouveau plugin sur un environnement de préproduction avant de l’activer sur un site en production.

WordPress.org ou WordPress.com : lequel choisir ?

Confusion fréquente à lever d’emblée : WordPress.org est le logiciel libre que vous installez vous-même chez l’hébergeur de votre choix, avec un contrôle total (thèmes, extensions, code). WordPress.com est un service d’hébergement géré construit par Automattic autour de ce même logiciel, avec des formules payantes et davantage de limites (thèmes/extensions restreints sur les offres d’entrée de gamme).

Pour un site professionnel où vous voulez garder la main sur vos choix techniques, WordPress.org auto-hébergé reste, dans l’immense majorité des cas, le bon point de départ. C’est aussi le prérequis pour tout ce qui suit dans ce guide : un accès complet à l’administration, aux fichiers et à la base de données.

Dans les faits, WordPress.com fonctionne par paliers : une offre gratuite très limitée (sous-domaine imposé, pas de nom de domaine personnalisé, quasiment aucune extension), puis des formules payantes croissantes qui débloquent progressivement le domaine personnalisé, l’installation de plugins tiers et un accès plus complet au thème. Le paradoxe : sur les paliers les plus hauts de WordPress.com, vous payez chaque mois pour retrouver, en partie seulement, la liberté qu’un hébergement WordPress.org classique offre nativement pour le prix d’un simple hébergement mutualisé. C’est la raison principale pour laquelle la quasi-totalité des sites professionnels que nous couvrons sur ce blog tournent en WordPress.org auto-hébergé.

Combien coûte réellement un site WordPress

« WordPress est gratuit » est vrai et trompeur à la fois : le logiciel ne coûte rien, mais un site qui tourne dessus a des coûts réels, répartis sur plusieurs postes qu’il vaut mieux connaître avant de se lancer plutôt qu’à la facture.

• L’hébergement : le poste incontournable, du mutualisé bas de gamme à quelques euros par mois jusqu’à l’hébergement managé WordPress haut de gamme, nettement plus cher mais optimisé spécifiquement pour ce logiciel (mises à jour gérées, cache serveur, support spécialisé).
• Le nom de domaine : un coût annuel modeste, mais à renouveler, et à surveiller pour éviter l’expiration accidentelle qui coupe le site du jour au lendemain.
• Le thème : gratuit dans le répertoire officiel WordPress.org, ou premium (souvent un paiement unique ou une licence annuelle) pour un design plus abouti ou un support dédié.
• Les extensions premium : la plupart des extensions gratuites couvrent l’essentiel, mais certains besoins (formulaires avancés, SEO poussé, sécurité renforcée, e-commerce complet) justifient un abonnement à une version payante.
• La maintenance : en temps si vous la faites vous-même, ou en budget si vous la déléguez (mises à jour, sauvegardes, surveillance de sécurité).

Le vrai piège budgétaire n’est presque jamais le coût de départ, toujours modeste : c’est la maintenance négligée qui, des mois plus tard, se traduit par un piratage, une extension abandonnée qui casse le site, ou une migration en urgence chez un nouvel hébergeur après un incident. Budgétiser la maintenance dès le départ, même modestement, coûte largement moins cher que de la gérer en réaction à un problème déjà survenu.

Trois profils de projet donnent une idée plus concrète de la répartition réelle de ces postes :

• Blog personnel ou petit site vitrine : hébergement mutualisé d’entrée de gamme, thème gratuit du répertoire officiel, quelques extensions gratuites. Le poste dominant reste le temps passé à rédiger le contenu, pas le budget technique.
• Site professionnel de PME : hébergement mutualisé de meilleure qualité ou managé WordPress, thème premium pour un rendu plus abouti, une à deux extensions payantes (formulaire avancé, SEO). La maintenance devient ici un vrai poste à budgétiser, en interne ou délégué à une agence.
• Site e-commerce : hébergement dimensionné pour encaisser le trafic et les transactions, WooCommerce (gratuit) complété par des extensions de paiement et de logistique souvent payantes, et une maintenance quasi obligatoire au vu de l’enjeu financier direct d’une indisponibilité.

Le point commun aux trois profils : le logiciel WordPress lui-même ne fait jamais grimper la facture, quel que soit le profil. Ce qui varie, c’est le niveau d’exigence sur l’hébergement, le thème et la maintenance, en fonction de ce que le site a réellement à perdre en cas d’incident.

Choisir son hébergement WordPress : les critères qui comptent vraiment

Tous les hébergeurs qui annoncent « compatible WordPress » ne se valent pas, loin de là : n’importe quel hébergement PHP/MySQL fait techniquement tourner WordPress, mais la qualité de l’expérience varie énormément d’un prestataire à l’autre. Quelques critères concrets à vérifier avant de choisir, plutôt qu’après avoir constaté un site lent ou instable :

• Version de PHP proposée : WordPress évolue vite, un hébergeur qui traîne sur une version de PHP ancienne freine à la fois la performance et la compatibilité avec les extensions récentes.
• Isolation sur le mutualisé : sur un hébergement mutualisé bas de gamme, un autre site du même serveur peut, dans le pire des cas, dégrader les performances ou la sécurité du vôtre. Une bonne isolation par compte limite ce risque.
• Sauvegardes automatiques incluses : et surtout, la possibilité réelle de les restaurer soi-même sans dépendre d’un ticket de support.
• Support technique qui connaît réellement WordPress, pas seulement l’hébergement générique : un support capable de diagnostiquer un conflit de plugin ou une erreur PHP fait gagner des heures face à un incident.
• Localisation des serveurs par rapport à votre audience cible : la latence réseau pèse dans le temps de chargement perçu, en particulier pour un public majoritairement situé dans un même pays ou une même région.

Le réflexe le plus utile reste de ne pas se fier uniquement au prix affiché en façade (souvent un tarif d’appel la première année) mais de vérifier ces critères sur la durée, au tarif de renouvellement réel.

Se lancer avec WordPress : les bases à maîtriser

Une fois WordPress installé, la première difficulté n’est presque jamais technique : c’est de savoir par où commencer. Voici, dans l’ordre où on les rencontre réellement, les gestes de base et où en apprendre le détail :

Se connecter à son espace d’administration. Première étape, souvent plus confuse qu’elle n’y paraît pour un débutant (URL de connexion, identifiants, gestion des sessions) : notre guide connexion à WordPress, comment enfin se connecter couvre les cas de blocage les plus fréquents.

Publier son premier article. L’éditeur de blocs Gutenberg a sa propre logique (un bloc = un élément de contenu). Notre tuto pour publier un article de blog sur WordPress détaille le flux complet, de la rédaction à la mise en ligne.

Ajouter et gérer ses images. Poids des fichiers, texte alternatif, mise en page : notre guide ultime pour ajouter des images à vos articles WordPress évite les pièges les plus courants (images non compressées qui plombent la vitesse du site en tête de liste).

Personnaliser un bloc au-delà de ce que propose l’éditeur natif. Pour aller plus loin que les blocs standards, la création d’un bloc Gutenberg personnalisé ouvre la porte à des mises en page sur mesure, sans dépendre d’un plugin tiers pour chaque besoin ponctuel.

Soigner ses URLs. Un détail qui pèse autant en lisibilité qu’en référencement : comment et pourquoi optimiser les « slugs » d’URL de vos pages et articles.

Gagner en efficacité au quotidien. Une fois les bases posées, les raccourcis clavier les plus utiles pour WordPress font gagner un temps réel sur la rédaction et la mise en forme au long cours.

Les erreurs de débutant qui reviennent le plus souvent

Au-delà des bases ci-dessus, un petit nombre d’erreurs reviennent sur la quasi-totalité des premiers sites WordPress. Les connaître à l’avance évite de les commettre :

• Installer trop de plugins d’un coup, souvent en double sur une même fonction (deux plugins de cache, deux plugins SEO), ce qui ralentit le site et multiplie les risques de conflit sans apporter de bénéfice supplémentaire.
• Choisir un thème pour son apparence plutôt que pour sa légèreté technique. Un thème visuellement impressionnant mais qui charge des dizaines de scripts inutilisés pèse sur la performance de chaque page, y compris celles qui n’utilisent jamais ces fonctionnalités.
• Ignorer les mises à jour en attendant « le bon moment ». Le bon moment n’existe pas dans l’absolu : chaque mise à jour de sécurité repoussée est une fenêtre ouverte de plus pour un attaquant automatisé.
• Modifier directement les fichiers d’un thème non enfant, perdus à la moindre mise à jour du thème. Le réflexe correct, décrit plus haut, est de passer par un thème enfant.
• Ne jamais avoir testé sa propre sauvegarde. Découvrir qu’une sauvegarde est corrompue ou incomplète au moment où on en a réellement besoin est, de loin, le scénario le plus coûteux de cette liste.

Sécuriser son site WordPress : la popularité a un revers

Être le CMS le plus utilisé au monde a une contrepartie directe : WordPress et son écosystème de plugins sont une cible de choix pour les attaquants automatisés. Ce n’est pas une raison pour éviter le logiciel, c’est une raison de prendre la sécurité au sérieux dès l’installation, pas après un incident.

Deux cas concrets que nous avons couverts récemment illustrent bien le mécanisme réel d’une faille de sécurité WordPress : wp2shell, une faille critique du noyau déjà activement exploitée, et XSS2Shell, où la page de connexion elle-même menait à la prise de contrôle totale du serveur. Le point commun de ces deux cas : la faille était corrigible rapidement une fois le correctif publié, mais uniquement pour les sites tenus à jour.

Le risque ne vient pas que du Core : les extensions tierces sont statistiquement la source la plus fréquente de failles. Nous l’avons documenté avec des chiffres à l’appui dans notre article sur l’augmentation de 328 % des bugs de sécurité détectés dans les plugins WordPress. Le spam, moins spectaculaire mais tout aussi chronophage, se traite en amont : voyez comment résoudre efficacement les problèmes de spam dans les formulaires WordPress. Et un geste simple, souvent négligé : cacher l’adresse de connexion par défaut de son site réduit mécaniquement le volume d’attaques automatisées qui ciblent l’URL /wp-admin par défaut.

Au-delà de ces deux cas, quelques réflexes de fond font l’essentiel du travail, et coûtent peu de temps une fois pris en habitude :

• Maintenir à jour Core, thèmes et plugins. La majorité des sites compromis le sont via une faille déjà corrigée dans une version plus récente, jamais appliquée. C’est, de loin, le geste de sécurité au meilleur rapport effort/protection.
• Des identifiants et une authentification robustes. Un mot de passe généré (pas un mot du dictionnaire, même modifié), et l’authentification à deux facteurs sur tous les comptes administrateur, si votre extension de sécurité ou votre hébergeur la propose.
• Limiter les comptes administrateur au strict nécessaire. Chaque compte avec les pleins droits est une porte d’entrée supplémentaire ; les rôles WordPress (éditeur, auteur, contributeur) existent justement pour ne donner à chacun que les droits dont il a réellement besoin.
• Un pare-feu applicatif (WAF) et un plugin de sécurité. Ils filtrent une bonne partie du trafic malveillant avant même qu’il n’atteigne le code de votre site, et alertent en cas de modification de fichier suspecte.
• La sécurité côté hébergeur compte autant que celle côté WordPress. Isolation entre comptes sur un mutualisé, certificat SSL/TLS à jour, sauvegardes automatiques côté serveur : un bon hébergeur absorbe une partie du risque avant même que WordPress n’entre en jeu.

Maintenance, sauvegardes et migration : ne pas attendre l’incident

Un site WordPress qui tourne bien un an peut casser du jour au lendemain après une mise à jour de plugin mal testée, ou perdre des données sur un incident d’hébergement. La sauvegarde régulière n’est pas une option de confort, c’est le filet de sécurité qui transforme un incident grave en contretemps de quelques minutes. Nous avons détaillé un outil qui couvre à la fois la sauvegarde et la migration (changement d’hébergeur, passage d’un site de test vers la production) dans notre article sur All in One WP Migration and Backup, l’une des extensions les plus fiables sur ce terrain précis.

Trois règles pratiques évitent la majorité des mauvaises surprises. D’abord, une sauvegarde n’est utile que si elle est stockée ailleurs que sur le serveur qu’elle protège : un incident qui touche l’hébergeur emporte aussi les sauvegardes qui y résident. Ensuite, une sauvegarde ne vaut que si elle a déjà été restaurée au moins une fois pour test : une sauvegarde jamais testée est une sauvegarde dont vous ne savez pas si elle fonctionne réellement. Enfin, avant toute mise à jour de version majeure de WordPress, d’un thème ou d’un plugin critique, un test sur un environnement de préproduction (souvent appelé staging, une copie du site inaccessible au public) permet de repérer un conflit avant qu’il n’atteigne les visiteurs, plutôt qu’après.

Pour qui WordPress est-il fait ? Cas d’usage détaillés

WordPress convient à des usages très différents, et c’est justement sa force :

• Blog ou site vitrine : c’est l’usage historique, toujours le plus simple à mettre en place. Un thème adapté et quelques articles suffisent à démarrer, ce qui en fait le point d’entrée naturel pour qui découvre WordPress.
• Site e-commerce : via l’extension WooCommerce, WordPress devient une boutique en ligne complète (catalogue, panier, paiement, gestion des stocks). L’avantage sur une plateforme e-commerce fermée : la boutique cohabite nativement avec un vrai contenu éditorial (guides d’achat, blog), ce qui sert directement le référencement.
• Média ou site à fort volume de publication : la gestion native des catégories, auteurs et flux éditoriaux tient la charge sans développement spécifique, même avec plusieurs rédacteurs qui publient en parallèle et des dizaines d’articles par mois.
• Site vitrine d’entreprise : formulaires de contact, pages de service, SEO natif ou via extension (Yoast, Rank Math) couvrent l’essentiel des besoins courants, sans nécessiter de développement sur mesure pour une présence professionnelle standard.
• Plateforme de formation en ligne : un usage moins connu mais solide, via des extensions de e-learning dédiées qui structurent cours, modules et suivi de progression. Nous détaillons la démarche complète dans comment créer un cours en ligne avec WordPress.

Ce qui rend ces cas d’usage très différents possibles avec le même logiciel de base, c’est précisément l’architecture décrite plus haut : Core, thèmes et extensions se combinent différemment selon le besoin, sans jamais nécessiter de réécrire WordPress lui-même. Un site e-commerce et un blog partagent le même noyau ; seule la couche d’extensions installée change radicalement leur usage final. C’est aussi ce qui explique pourquoi un site WordPress évolue rarement dans une seule direction dès le départ : un blog qui grossit ajoute souvent une boutique, un site vitrine ajoute un blog pour son référencement, sans migration de plateforme nécessaire.

Là où WordPress est moins adapté : une application web complexe avec une logique métier lourde (tableau de bord SaaS, application mobile native), où un framework applicatif dédié sera généralement un meilleur choix que de forcer WordPress hors de son terrain.

Les idées reçues sur WordPress qui ont la vie dure

Quelques affirmations reviennent régulièrement dans les conversations sur WordPress, sans toujours résister à l’examen :

« WordPress, c’est juste pour les blogs. » C’était vrai en 2003. Ça ne l’est plus depuis longtemps : les cas d’usage détaillés plus haut (e-commerce, média, formation en ligne, site vitrine d’entreprise) couvrent aujourd’hui l’essentiel des besoins professionnels, le blog n’étant qu’un usage parmi d’autres.

« WordPress est lent par nature. » Un WordPress mal configuré est lent ; le logiciel lui-même ne l’est pas. Les trois leviers de performance décrits plus loin dans ce guide (cache, images, hébergement) expliquent l’écart, pas une limite intrinsèque du CMS.

« Il faut coder pour utiliser WordPress. » Faux pour l’usage courant, comme détaillé dans notre FAQ plus bas : l’éditeur visuel et l’écosystème de thèmes/extensions couvrent la majorité des besoins sans une ligne de code.

« WordPress n’est pas sécurisé. » Le Core est activement maintenu et corrigé rapidement, comme n’importe quel logiciel sérieux. Le risque réel, détaillé dans la section sécurité de ce guide, vient presque toujours d’une extension obsolète ou d’une négligence humaine, pas du logiciel de base.

« Les mises à jour cassent toujours quelque chose. » Ça arrive, mais c’est évitable dans l’immense majorité des cas avec la bonne méthode : tester sur un environnement de préproduction avant de mettre à jour un site en production, exactement la règle posée dans notre section maintenance.

Auditer et optimiser son site WordPress

Un site WordPress installé n’est que le point de départ : encore faut-il qu’il charge vite, qu’il soit trouvable sur les moteurs de recherche, et qu’il ne traîne pas de dette technique invisible (plugins abandonnés, images non optimisées, erreurs 404 accumulées). Un audit régulier est le réflexe le plus rentable pour éviter que ces petits problèmes s’accumulent silencieusement ; nous expliquons la méthode dans pourquoi faire un audit de site Internet pour votre entreprise. Côté référencement, la question qui revient le plus souvent est moins « quel plugin SEO installer » que « comment se former sérieusement au sujet » : nous avons rassemblé nos recommandations dans comment se former au SEO, et trouver les bonnes ressources.

Côté performance pure, trois leviers concentrent l’essentiel du gain possible sur un site WordPress standard : la mise en cache (servir une version déjà générée d’une page plutôt que de reconstruire du PHP et interroger la base de données à chaque visite), l’optimisation des images (compression, format moderne, chargement différé des images hors écran), et le choix de l’hébergeur, qui détermine le temps de réponse serveur avant même que WordPress n’entre en jeu. Ces trois leviers, combinés, expliquent l’essentiel de l’écart entre un site WordPress qui charge en une seconde et un autre qui traîne sur cinq secondes avec un contenu comparable.

Multilingue, accessibilité, RGPD : les sujets transverses trop souvent oubliés

Trois sujets ne rentrent dans aucune des catégories précédentes, mais reviennent sur la majorité des projets professionnels sérieux.

Le multilingue n’est pas nativement géré par le Core : il passe presque toujours par une extension dédiée (Polylang ou WPML sont les deux références du marché), qui duplique chaque contenu par langue et gère le lien entre les versions. Le choix entre les deux dépend surtout du volume de contenu et du budget : Polylang a une offre gratuite solide, WPML est payant mais plus riche sur la traduction automatisée à grande échelle.

L’accessibilité (rendre un site utilisable par des personnes en situation de handicap, via lecteur d’écran notamment) dépend à la fois du thème choisi et de la rigueur de rédaction (texte alternatif sur les images, hiérarchie de titres cohérente, contraste suffisant). WordPress fournit les bases techniques nécessaires, mais l’accessibilité réelle d’un site dépend surtout des choix faits par qui le construit et le rédige, pas uniquement du logiciel.

Le RGPD, enfin, concerne tout site qui collecte des données de visiteurs européens (formulaire de contact, commentaires, statistiques de visite) : bannière de consentement pour les cookies non essentiels, politique de confidentialité claire, et hébergement des données cohérent avec les engagements pris. Plusieurs extensions couvrent la partie technique (gestion du consentement), mais la conformité de fond reste une responsabilité éditoriale, pas seulement un plugin à installer.

Pourquoi WordPress reste dominant en 2026 : l’IA entre dans le Core

Ce qui rend 2026 particulier pour WordPress, ce n’est pas seulement le maintien de sa part de marché : c’est l’arrivée, avec la version 7.0 « Armstrong » (875 contributeurs, dont plus de 200 pour la première fois), d’une infrastructure IA directement dans le noyau du logiciel. Concrètement, le Core embarque désormais un AI Client agnostique du fournisseur, une Abilities API qui standardise ce qu’un site peut « faire » de façon exploitable par un agent, et un écran Réglages > Connecteurs qui accepte par défaut Anthropic, Google et OpenAI. Nous avons détaillé ce que ça change concrètement (et ce que ça ne fait PAS) dans notre article dédié à l’AI Client, et comment ces briques s’articulent entre elles dans notre décryptage des 3 briques qui rendent WordPress agentique.

Avant de mettre à jour un site existant vers cette version, la prudence reste de mise : nous avons posé une checklist complète dans faut-il passer à WordPress 7.0 ?, et détaillé l’ensemble des nouveautés (au-delà du seul volet IA) dans notre tour d’horizon complet de la version Armstrong.

Concrètement, pour un site qui ne fait rien de particulier avec l’IA aujourd’hui, cette infrastructure ne change rien tant qu’aucune extension ne vient s’y brancher : le Core ne « génère » rien de lui-même, c’est une prise standard, pas un moteur IA activé par défaut. Ce que ça ouvre, en revanche, c’est un terrain commun pour les futurs plugins qui voudront proposer des fonctionnalités IA (génération de contenu assistée, résumé automatique, modération), sans que chacun ait à réinventer sa propre connexion à un fournisseur de modèle. C’est ce déplacement, du plugin isolé vers une brique standardisée du Core, qui justifie qu’on en parle comme d’un vrai changement structurel plutôt que d’une fonctionnalité de plus dans la longue liste des nouveautés de version.

Au-delà de cette nouveauté très commentée, ce qui explique surtout la longévité de WordPress reste plus terre-à-terre : une communauté immense qui documente, corrige et fait évoluer le logiciel en continu, et un écosystème de thèmes/extensions qui couvre à peu près tous les besoins sans qu’il soit nécessaire de développer sur mesure.

Quel avenir pour WordPress ? L’IA, le search agentique et le pari de la neutralité

Le détail le plus révélateur de la version 7.0, ce n’est pas l’AI Client en lui-même : c’est le MCP Adapter, qui transforme les capacités d’un site (exposées via l’Abilities API) en outils qu’un agent IA externe peut découvrir et actionner directement. Ce n’est plus seulement « un rédacteur humain utilise l’IA pour écrire plus vite » : c’est « un agent IA peut interagir avec le site comme avec une API », sans passer par un navigateur ni un humain devant un écran. C’est un changement de nature, pas un degré de plus sur une fonctionnalité déjà connue.

La logique probable derrière ce choix ressemble à un pari défensif face à un risque déjà mesuré ailleurs sur ce site : la chute du clic organique quand un résumé IA s’affiche en tête de recherche, jusqu’à -58 % en position 1 selon la dernière étude Ahrefs. Si une part croissante des requêtes se règle par un résumé généré plutôt que par un clic, la question qui se pose à n’importe quel site n’est plus seulement « suis-je bien classé ? » mais « un agent IA peut-il m’interroger et me citer correctement ? ». Rendre WordPress nativement interrogeable par un agent, plutôt que de laisser cette couche à un plugin tiers bricolé site par site, positionne le CMS pour ce scénario, avant que la question ne devienne pressante pour l’ensemble du web.

Le détail le plus délibéré, à nos yeux : le Core reste agnostique du fournisseur IA (Anthropic, Google, OpenAI en connecteurs interchangeables, aucun imposé par défaut). C’est la même logique que l’argument central de ce guide sur l’hébergement, « pas de fournisseur unique qui vous enferme », appliquée cette fois à la couche IA. Un WordPress lié contractuellement à un seul partenaire IA aurait fragilisé exactement ce qui a fait sa durée de vie face à des plateformes fermées : la neutralité.

Reste une menace que cette infrastructure ne couvre pas : la concurrence ne vient plus seulement d’autres CMS, mais d’outils qui génèrent un site ou une application entière à partir d’un simple prompt. Lovable, Base44 (racheté par Wix en 2025, désormais une division du groupe) ou v0 de Vercel produisent du code exportable (souvent React ou Next.js), une base de données et une authentification fonctionnelle en quelques minutes, sans thème ni plugin à assembler à la main. Le risque pour WordPress n’est donc pas seulement sur la couche contenu, déjà couverte par l’AI Client : il est sur la couche construction elle-même, celle que ce guide décrit depuis le début (Core, thèmes, extensions). Si demain la façon par défaut de démarrer un site passe par un agent qui génère directement l’application plutôt que par l’installation d’un CMS, la question n’est plus de savoir si WordPress gère bien l’IA, mais s’il reste le point de départ qu’on choisit du tout.

Aucune de ces deux trajectoires n’est tranchée à ce jour. Ce qu’on peut dire avec un niveau de confiance raisonnable : WordPress a pris ce virage plus tôt que la majorité de ses concurrents CMS historiques, avec une architecture cohérente sur le papier (agnostique, standardisée, ouverte à toute extension tierce). Ce qui reste à prouver, c’est l’exécution : l’adoption réelle par les développeurs de plugins, la richesse effective des « abilities » exposées par les sites du monde réel, et la capacité du projet à rester pertinent face à une génération d’outils qui ne proposent plus de construire un site, mais de le faire apparaître entièrement à la demande.

Comprendre les versions majeures récentes

Suivre les grandes versions de WordPress aide à comprendre où va le logiciel, même sans mettre à jour immédiatement. WordPress publie plusieurs versions majeures par an, chacune nommée d’après un musicien de jazz (Armstrong pour la 7.0, une tradition du projet qui remonte à ses débuts). Au-delà du duo fondateur déjà couvert plus haut, 5.9 (Full Site Editing) et 7.0 (infrastructure IA), la version 6.2 mérite le détour : une étape de consolidation moins spectaculaire, qui a stabilisé et affiné l’éditeur de blocs entre les deux ruptures majeures plutôt que d’introduire un changement de fond. C’est un pattern courant chez WordPress : les versions « .0 » posent les fondations, les versions intermédiaires les consolident avant la rupture suivante.

Pour situer ces jalons les uns par rapport aux autres, une chronologie resserrée aux ruptures qui ont vraiment compté :

• 2003 : première version, fork de b2/cafelog par Matt Mullenweg et Mike Little.
• 2004 : version 1.2, arrivée de l’architecture de plugins, le point de départ de l’écosystème d’extensions actuel.
• Décembre 2018 : version 5.0 « Bebo », arrivée de Gutenberg, l’éditeur de blocs.
• Janvier 2022 : version 5.9 « Joséphine », Full Site Editing, l’éditeur de blocs étendu à la mise en page entière du site.
• Mai 2026 : version 7.0 « Armstrong », infrastructure IA native dans le Core (AI Client, Abilities API, MCP Adapter).

Vu sur cette échelle de temps, le rythme des ruptures majeures s’accélère plutôt qu’il ne ralentit : environ quatorze ans entre l’architecture de plugins et Gutenberg, quatre ans entre Gutenberg et le Full Site Editing, un peu plus de quatre ans entre le Full Site Editing et l’infrastructure IA. Ce n’est pas une preuve en soi que WordPress a raison de parier sur l’IA maintenant, mais ça confirme que le projet n’a jamais été statique, contrairement à l’image parfois datée d’un simple outil de blog qui lui colle encore à la peau.

La communauté WordPress : WordCamps et contribution

Un des traits distinctifs de WordPress par rapport à un logiciel propriétaire, c’est sa communauté organisée en événements locaux gratuits ou à prix libre, les WordCamps, où développeurs, designers et utilisateurs se retrouvent pour partager pratiques et retours d’expérience. Nous avons couvert l’un d’eux dans notre reportage sur le WordCamp Suisse 2023 : au-delà du réseautage, ces événements sont souvent le meilleur endroit pour comprendre où va vraiment le logiciel, avant que ça n’atterrisse dans une note de version.

Au-delà des événements, la contribution au projet prend des formes multiples et accessibles, pas seulement l’écriture de code : traduction du logiciel dans d’autres langues, animation des forums de support officiels, rédaction de documentation, remontée et tri des rapports de bugs, organisation locale de WordCamps. C’est cette base de contributeurs bénévoles et d’entreprises qui « donnent » du temps de développement au projet qui explique la vitesse à laquelle WordPress corrige ses failles de sécurité et sort de nouvelles versions, sans dépendre d’un unique éditeur commercial.

WordPress côté développeur : REST API et usage headless

Pour un usage courant, WordPress affiche lui-même vos pages : le thème génère le HTML, le visiteur le reçoit directement. Mais le logiciel expose aussi une REST API publique (interrogeable en JSON, sans authentification pour du contenu public), qui permet à n’importe quelle application externe de lire, et sous conditions d’écrire, le contenu d’un site WordPress. C’est cette API que nous utilisons nous-mêmes, ailleurs sur le réseau, pour construire dynamiquement le maillage interne d’un article sans jamais tenir de liste de liens à la main.

Cette même API rend possible l’usage dit headless : WordPress ne sert alors plus que de back-office de gestion de contenu, tandis qu’un frontend entièrement différent (souvent un framework JavaScript moderne) affiche le site aux visiteurs, en interrogeant l’API plutôt qu’en utilisant le système de thèmes classique. L’intérêt : des performances et une flexibilité de design supérieures pour des équipes techniques capables de maintenir deux systèmes distincts. Le coût : on perd la simplicité d’un thème clé en main, et la maintenance devient plus complexe pour une petite structure. Pour l’immense majorité des sites que ce guide couvre, le mode classique (thème géré directement par WordPress) reste le bon choix ; le headless se justifie surtout à partir d’une taille d’équipe technique et d’exigences de performance que peu de sites atteignent réellement.

Deux autres outils structurent le quotidien d’un développeur WordPress, au-delà de la REST API. Les types de contenu personnalisés (custom post types) permettent de créer une structure de données propre à un besoin métier (un catalogue de produits, une base de recettes, un annuaire) plutôt que de tout forcer dans le format « article » ou « page » par défaut ; associés à des taxonomies personnalisées (des systèmes de catégorisation sur mesure, au-delà des catégories et étiquettes standards), ils transforment WordPress en véritable base de données structurée, pas seulement en outil de blog. WP-CLI, l’interface en ligne de commande officielle, permet de son côté d’administrer un site entier (installation, mises à jour, gestion des utilisateurs, requêtes sur le contenu) sans passer par l’interface web, ce qui devient indispensable dès qu’on gère plusieurs sites ou qu’on automatise une partie de la maintenance.

WordPress face aux alternatives : Wix, Shopify, Webflow, Ghost

WordPress n’est pas le bon choix par défaut absolu, et le comparer honnêtement à ses alternatives les plus citées aide à situer où il excelle vraiment :

• Wix / Squarespace : plus simples à démarrer pour un utilisateur non technique qui veut un résultat rapide et accepte les limites d’une plateforme fermée. WordPress demande un peu plus d’apprentissage au départ, mais ne vous enferme jamais dans une seule plateforme.
• Shopify : reste souvent plus adapté qu’un WordPress + WooCommerce pour un e-commerce pur qui veut une solution clé en main, sans se soucier de l’infrastructure. WordPress reprend l’avantage dès que le site combine contenu éditorial riche et boutique, ou que la personnalisation profonde du parcours d’achat devient un besoin réel.
• Webflow : un outil de choix pour un design sur-mesure très maîtrisé visuellement, en particulier pour des agences ou designers qui pensent d’abord en composition graphique. Il reste en revanche moins riche que WordPress dès qu’il s’agit de volume de contenu, de blog structuré ou d’extensions métier spécifiques.
• Ghost : une alternative intéressante et plus légère si le site est un pur blog ou une newsletter payante, sans besoin des fonctionnalités les plus larges (e-commerce, pages complexes, écosystème de plugins) que WordPress propose.

Le fil conducteur de cette comparaison : plus un projet a besoin de flexibilité, de contrôle total sur ses données, et de la capacité à faire évoluer son site dans une direction imprévue au départ, plus WordPress prend l’avantage sur des plateformes fermées, plus simples au démarrage mais plus limitantes une fois le site mature.

Glossaire WordPress : le vocabulaire de base

Un vocabulaire commun pour s’y retrouver dans le reste de ce guide et dans nos autres articles, sans redéfinir chaque terme à chaque fois :

• CMS : système de gestion de contenu, la catégorie de logiciel à laquelle appartient WordPress.
• Core : le logiciel WordPress lui-même, hors thème et extensions.
• Thème : le module qui définit l’apparence d’un site.
• Thème enfant : une personnalisation d’un thème existant, sans modifier ses fichiers d’origine.
• Extension (plugin) : un module qui ajoute une fonctionnalité au Core.
• Gutenberg : le nom de code de l’éditeur de blocs, introduit en version 5.0.
• Bloc : l’unité de contenu de base dans l’éditeur (paragraphe, image, colonnes…).
• Full Site Editing : l’extension de la logique de blocs à la mise en page entière du site, pas seulement au contenu.
• Hook (action/filtre) : le mécanisme technique qui permet à un plugin de modifier le comportement de WordPress sans toucher au Core.
• GPL : la licence libre sous laquelle WordPress est distribué.
• REST API : l’interface qui permet à une application externe d’interroger un site WordPress en JSON.
• Headless : un usage où WordPress ne sert que de back-office, un frontend distinct affichant le site via l’API.
• Custom post type : un type de contenu personnalisé, au-delà des articles et pages par défaut.
• WP-CLI : l’interface en ligne de commande officielle pour administrer WordPress.
• Staging : un environnement de préproduction, copie du site inaccessible au public, pour tester avant de mettre en production.
• WordCamp : un événement communautaire local, gratuit ou à prix libre, organisé autour de WordPress.
• AI Client : la brique du Core (depuis la version 7.0) qui standardise la connexion à un fournisseur de modèle IA.
• Abilities API : la brique qui standardise ce qu’un site peut « faire » de façon exploitable par un agent.
• MCP Adapter : le pont qui expose les « abilities » d’un site comme des outils utilisables par un agent IA externe.

Ressources officielles pour aller plus loin

Au-delà de nos propres articles, quatre ressources officielles couvrent l’essentiel pour qui veut creuser au-delà de ce guide. WordPress.org reste le point d’entrée pour télécharger le logiciel, parcourir le répertoire de thèmes et d’extensions, et consulter la documentation utilisateur. Make WordPress Core (make.wordpress.org) est le blog technique où se discutent les décisions de développement du Core, avant même qu’elles n’atterrissent dans une note de version. Les WordCamps et les Meetups locaux, recensés sur central.wordcamp.org, restent le meilleur endroit pour rencontrer la communauté en personne. Et pour toute question technique précise, les forums de support officiels restent, encore aujourd’hui, plus fiables qu’une réponse générique glanée au hasard d’une recherche : ils sont tenus par des bénévoles qui connaissent réellement le logiciel, contexte par contexte.

Migrer un site existant vers WordPress

Changer de CMS pour rejoindre WordPress est une décision qui revient régulièrement, en particulier pour qui part d’une plateforme fermée ou d’un développement sur mesure devenu trop coûteux à maintenir. Le chantier se découpe toujours dans le même ordre, quelle que soit l’origine :

1. Cartographier le contenu existant (pages, articles, médias) et l’exporter dans un format récupérable, idéalement avant même de choisir le thème d’arrivée.
2. Préparer les redirections de chaque URL existante vers sa nouvelle adresse sur WordPress, pour ne pas perdre le référencement déjà acquis : c’est l’étape la plus souvent négligée, et la plus coûteuse quand elle l’est.
3. Reconstruire la structure (catégories, menus, gabarits de page) sur l’environnement WordPress avant d’y importer le contenu, plutôt que d’improviser après coup.
4. Tester intégralement sur un environnement de préproduction avant de basculer le domaine principal, y compris les formulaires, la recherche interne et l’affichage mobile.
5. Surveiller l’indexation dans les semaines qui suivent la bascule (Google Search Console en premier réflexe), pour repérer rapidement une redirection manquante plutôt que de la découvrir des mois plus tard sur une chute de trafic.

La migration technique du contenu lui-même s’appuie souvent sur les mêmes outils que ceux évoqués plus haut pour la sauvegarde : ce n’est pas un hasard, sauvegarder et migrer un site WordPress sont, techniquement, deux usages du même mécanisme d’export/import.

Questions fréquentes sur WordPress

WordPress est-il vraiment gratuit ?
Le logiciel oui, intégralement. Un site WordPress a en revanche des coûts réels (hébergement, domaine, éventuellement thème/extensions premium), détaillés plus haut dans ce guide.

Faut-il savoir coder pour utiliser WordPress ?
Non, pour l’usage courant (rédiger, publier, personnaliser un thème existant via l’éditeur visuel). Coder devient utile pour aller au-delà de ce que proposent les thèmes et extensions existants, par exemple pour créer un bloc Gutenberg personnalisé.

WordPress est-il sécurisé ?
Le Core l’est, activement maintenu et corrigé rapidement. Le risque réel vient presque toujours d’une extension obsolète, d’un mot de passe faible ou d’une absence de mise à jour, pas du logiciel de base lui-même.

Peut-on migrer un site WordPress vers un autre hébergeur ?
Oui, sans perte de contenu, précisément parce que le logiciel est libre et auto-hébergeable. C’est l’un des arguments de fond en faveur de WordPress.org face à des plateformes fermées.

WordPress convient-il à un site e-commerce ?
Oui, via l’extension WooCommerce, jusqu’à des catalogues de taille sérieuse. Pour un besoin e-commerce pur et sans complexité éditoriale, une solution dédiée type Shopify peut toutefois être plus rapide à mettre en place.

Combien de temps faut-il pour créer un site WordPress ?
Un site simple (blog ou vitrine, thème existant, contenu prêt) se met en ligne en quelques heures à quelques jours. Un projet plus riche (e-commerce complet, contenu volumineux, design sur mesure) se compte plutôt en semaines, la majeure partie du temps allant à la préparation du contenu et aux tests, pas à l’installation du logiciel lui-même.

Quelle est la différence entre un thème et un plugin ?
Le thème contrôle l’apparence du site (mise en page, couleurs, typographie). Le plugin ajoute des fonctionnalités, indépendamment de l’apparence. Changer de thème ne devrait jamais faire disparaître une fonctionnalité fournie par un plugin, et inversement.

Peut-on utiliser WordPress en plusieurs langues ?
Oui, mais pas nativement : il faut passer par une extension dédiée (Polylang ou WPML sont les références), le Core seul ne gère pas la traduction ou la structure multilingue d’un site.

WordPress est-il adapté à un gros site à fort trafic ?
Oui, à condition de soigner l’hébergement (serveur dimensionné, cache correctement configuré) et de garder un nombre raisonnable d’extensions actives. La plupart des limites de performance rencontrées viennent d’un hébergement sous-dimensionné ou d’une accumulation de plugins mal optimisés, pas d’une limite intrinsèque du logiciel.

WordPress va-t-il être remplacé par des outils qui génèrent un site par IA ?
Pas dans l’immédiat pour les sites déjà en place : ces outils gagnent surtout des projets neufs démarrés de zéro, pas les millions de sites existants ni l’écosystème économique construit autour. Nous détaillons ce raisonnement dans la section dédiée plus haut.

Faut-il activer l’AI Client de WordPress 7.0 sur son site ?
Rien ne se déclenche automatiquement : le Core expose une infrastructure, mais aucune fonctionnalité IA active tant qu’aucune extension ou aucun réglage ne vient s’y brancher. Activer un connecteur (Anthropic, Google, OpenAI) reste un choix explicite, pas un défaut imposé.

Verdict : WordPress va-t-il tenir le coup face à l’IA ?

Après ce tour d’horizon, la question posée en ouverture de la section précédente mérite une réponse nette plutôt qu’un « ça dépend » de circonstance : oui, nous pensons que WordPress va tenir le coup dans un contexte d’IA, précisément parce qu’il n’est pas dénué d’atouts face aux nouveaux entrants. Le socle de cette conviction n’est pas l’AI Client ni le MCP Adapter, aussi bien pensés soient-ils : c’est ce qui a toujours fait la force du projet, sa communauté et son socle d’utilisateurs installés.

Un outil comme Lovable ou Base44 gagne un projet à la fois, à chaque prompt. WordPress, lui, part avec 41,1 % de l’ensemble des sites web déjà en place : des millions de sites existants, des agences qui en vivent, des hébergeurs spécialisés construits autour de ce socle, des développeurs formés sur ce logiciel depuis parfois vingt ans. Ce n’est pas une rente qui se défend par inertie : c’est un écosystème économique entier qui a intérêt à ce que WordPress reste pertinent, et qui a les moyens collectifs d’y contribuer. Personne ne migre un site e-commerce qui tourne, ni les compétences d’une agence entière, sur la promesse d’un outil plus rapide pour démarrer de zéro.

La communauté n’est pas qu’un argument sentimental, c’est une force de frappe mesurable : plus de 60 000 extensions gratuites dans le seul répertoire officiel, des centaines de contributeurs bénévoles et salariés qui ont livré l’AI Client et l’Abilities API en quelques mois à peine après leur proposition initiale. C’est cette même communauté qui a déjà absorbé, sans jamais disparaître, plusieurs ruptures technologiques qu’on annonçait fatales sur le moment : l’essor des page builders propriétaires, la vague du no-code, le hype du headless. À chaque fois, WordPress n’a pas gagné en étant le plus rapide à sortir la nouveauté : il a gagné en l’absorbant dans son Core, avec un temps de retard assumé mais une adoption massive derrière.

Le pari agnostique décrit plus haut joue exactement dans ce sens : WordPress n’a pas besoin de deviner quel fournisseur IA gagnera la bataille des modèles pour rester pertinent, il lui suffit de rester la couche neutre qui les connecte tous. C’est une position structurellement plus solide que celle d’un outil qui aurait parié tôt sur un seul partenaire.

Ce que ce constat n’efface pas : la partie construction de site neuf, elle, se joue davantage sur la rapidité de démarrage, terrain où les générateurs par prompt ont un avantage réel et immédiat. Mais un marché qui se scinde entre « sites qui existent déjà et qu’on fait évoluer » et « prototypes qu’on génère en quelques minutes » n’est pas un marché où WordPress disparaît : c’est un marché où sa position dominante sur le premier segment, le plus large en valeur cumulée, reste son meilleur atout.

Notre avis

WordPress reste, en 2026, un point de départ raisonnable pour la grande majorité des projets de site web : logiciel libre, écosystème mature, et désormais une vraie porte d’entrée IA native plutôt qu’une couche ajoutée par un plugin tiers. Ce guide a couvert volontairement large, du CMS aux fondations, jusqu’à des sujets plus pointus comme la REST API ou la migration, précisément parce qu’aucun de ces sujets n’existe vraiment isolé des autres sur un projet réel : choisir son hébergement conditionne la sécurité, la sécurité conditionne la maintenance, la maintenance conditionne la performance, et la performance conditionne le référencement.

Notre conseil reste le même qu’à chaque nouvelle version majeure : avant de vous lancer ou de migrer un site existant, vérifiez la compatibilité de votre hébergeur avec la dernière version stable et testez vos thèmes/extensions critiques sur un environnement de préproduction avant toute mise à jour en production. Si vous démarrez un projet neuf, la question n’est plus « faut-il utiliser WordPress ? » mais plutôt « quel thème, quelle extension, quel hébergeur correspondent à mon besoin ? », et c’est précisément le terrain que nous couvrons, article après article, sur ce site : chaque section de ce guide renvoie vers l’un de nos contenus les plus détaillés sur le sujet, à consulter au moment où vous en aurez concrètement besoin plutôt que tout d’un coup.