Deux ans, c’est long dans la vie d’un site web. En général, on ne le voit pas tout de suite: le site se charge toujours, les formulaires fonctionnent la plupart du temps et le CMS permet encore d’ajouter de nouvelles pages. Les problèmes s’accumulent là où ils sont plus difficiles à repérer: dans l’indexation, la vitesse, la sécurité, l’analytics, l’accessibilité et la visibilité dans les moteurs de recherche basés sur l’IA.
Dans cet article, je vous montre ce qu’il faut vérifier si votre site a plus de deux ans et n’a pas fait l’objet d’une revue technique depuis longtemps. Il ne s’agit pas de construire tout de suite un nouveau site. Souvent, un audit, une liste de priorités et quelques corrections bien choisies suffisent.
Dans cet article:
- 1. SEO technique et indexation
- 2. Contenus, intention de recherche et anciennes pages
- 3. GEO/AEO: la visibilité dans les résultats de recherche IA
- 4. Core Web Vitals et vitesse réelle du site
- 5. Scripts, consent mode et analytics
- 6. Mises à jour de sécurité du CMS et du framework
- 7. Accessibilité numérique
- 8. Formulaires, conversions et intégrations
- 9. Monitoring, sauvegardes et plan de réponse aux incidents
- Que faire après l’audit?
- SEO technique et indexation
Le premier domaine, ce sont les bases du SEO, qui peuvent se dérégler discrètement en deux ans. Quelqu’un a modifié la structure du menu, quelqu’un a supprimé une ancienne rubrique, quelqu’un a ajouté de nouveaux filtres aux listes de produits ou d’articles, et quelqu’un d’autre a redirigé la landing page d’une campagne sans en vérifier les conséquences. Après quelques changements de ce type, Google voit un autre site que l’équipe marketing.
Google insiste toujours sur les bases: une page doit être accessible aux robots des moteurs de recherche, indexable et compréhensible. Commencez donc par Google Search Console, une exploration de tout le site avec un crawler et la liste de vos URL les plus importantes.
Vérifiez avant tout:
- si les pages importantes sont indexées,
- si des pages inutiles sont entrées dans l’index,
- si les URL canoniques (canonical) pointent vers les bonnes pages,
- si robots.txt et les balises meta robots bloquent des pages importantes,
- si le plan de site XML (sitemap.xml) est à jour,
- si les redirections 301 forment des chaînes,
- si les titres, les meta descriptions et les titres H1 sont dupliqués à grande échelle,
- si des pages importantes sont enfouies trop profondément dans la structure du site et si des liens internes y mènent.
L’erreur la plus fréquente après deux ans: l’équipe compare seulement le trafic organique d’un mois sur l’autre. Ce n’est pas suffisant. Il faut vérifier si le site est toujours en ordre sur le plan technique, car les baisses viennent souvent de nombreux petits oublis, et non d’une seule panne spectaculaire.
Si votre site fonctionne sous Drupal, lisez aussi notre article 10 fonctionnalités SEO qu’un CMS moderne devrait avoir, exemple avec Drupal.
- Contenus, intention de recherche et anciennes pages
Le deuxième domaine, ce sont les contenus. Après deux ans, certains articles, landing pages et descriptions de services peuvent rester exacts, mais ne plus répondre aux questions que vos clients se posent aujourd’hui. C’est particulièrement visible en B2B et dans des secteurs comme l’informatique, la finance, l’éducation, la santé et l’e-commerce.
Les produits changent, tout comme l’offre, les concurrents, le vocabulaire des clients et les résultats de recherche eux-mêmes. Un article qui attirait beaucoup de trafic en 2024 peut perdre face à la concurrence en 2026, parce qu’il ne couvre pas les nouvelles variantes de requêtes ou ne tient pas compte de la façon dont les clients prennent leurs décisions aujourd’hui.
Lors d’un audit de contenu, vérifiez:
- les pages dont les clics ou le CTR ont fortement baissé,
- les pages avec beaucoup d’impressions, mais peu de clics,
- les anciens articles de blog qui se classent encore bien dans les résultats de recherche, mais contiennent des CTA obsolètes,
- la cannibalisation de mots-clés, c’est-à-dire plusieurs pages qui répondent à la même intention de recherche,
- les liens internes manquants vers les pages de services et les études de cas,
- les pages sans auteur, sans date de mise à jour ou sans exemples réels,
- les contenus qui ressemblent à une description neutre de catégorie plutôt qu’à la réponse d’un expert.
Il n’est pas nécessaire de réécrire chaque ancien texte. Parfois, il suffit d’ajouter un contexte actuel, une section FAQ, un nouveau CTA et un lien vers un contenu plus récent, et de supprimer les liens cassés. Mais la décision doit être prise en connaissance de cause: mettre à jour, fusionner, conserver ou supprimer.
- GEO/AEO: la visibilité dans les résultats de recherche IA
Si votre site a été créé il y a plus de deux ans, personne ne l’a probablement conçu en pensant à AI Overviews, AI Mode, Perplexity ou ChatGPT search. En 2026, ce n’est plus une curiosité. C’est un canal à part entière, dans lequel les clients découvrent des marques, des services et des guides.
Les consignes de Google sont claires: les bases du SEO comptent toujours dans les résultats génératifs. Une page doit être indexée, le contenu doit être original, précis et utile, et les informations importantes doivent être disponibles sous forme de texte. Google n’exige ni fichier spécial comme llms.txt, ni données structurées supplémentaires pour qu’une page apparaisse dans AI Overviews ou AI Mode.
Cela ne veut pas dire que rien n’a changé. Ce qui a changé, c’est la façon dont les utilisateurs arrivent aux contenus et dont ils les évaluent. Les moteurs de recherche basés sur l’IA affichent plus souvent des pages qui répondent clairement aux questions, montrent une expérience réelle, ont des sections bien organisées et permettent aux systèmes d’IA de déterminer qui est l’auteur, de quoi parle le contenu et pourquoi on peut lui faire confiance.
Lors d’un audit GEO/AEO, vérifiez:
- si les pages clés répondent à des questions précises de vos clients,
- si le texte contient des définitions, des comparaisons, des critères de choix et des exemples,
- si l’auteur et l’expérience de votre entreprise sont visibles,
- si les données structurées correspondent au contenu visible sur la page,
- si les images et les vidéos complètent le texte au lieu de seulement décorer la mise en page,
- si votre entreprise est décrite de façon cohérente sur votre site, dans les études de cas, sur les profils et dans les mentions externes,
- comment évoluent les impressions, les clics et le CTR dans le rapport Performances de Search Console. Google y inclut aussi le trafic issu d’AI Overviews et d’AI Mode, mais ne propose pas de rapport séparé pour ces fonctionnalités.
Sur Reddit, les avis sur le GEO sont très partagés. Certains constatent une baisse des clics à cause d’AI Overviews, d’autres estiment que le « GEO » n’est rien d’autre qu’un SEO bien fait, avec des contenus mieux structurés. Ma recommandation pratique est simple: ne cherchez pas d’astuces visant uniquement l’IA. Créez des contenus que l’on peut citer, comprendre et vérifier.
Nous décrivons précisément ce que nous vérifions sur les sites Drupal dans l’article Au-delà du SEO: ce que nous vérifions dans un audit Drupal AI-readability.
- Core Web Vitals et vitesse réelle du site
Un site peut être rapide le jour de sa mise en ligne et nettement plus lent deux ans plus tard. Il suffit de quelques campagnes, de nouveaux pixels publicitaires, d’un widget de chat, d’un outil tiers intégré, de grandes photos téléversées par un rédacteur et d’un plugin de formulaire supplémentaire. Il n’y a pas de grosse panne unique. Le site ralentit progressivement.
En 2026, surveillez les trois indicateurs Core Web Vitals:
- LCP, le temps d’affichage du contenu principal – objectif: 2,5 secondes maximum,
- INP, le temps de réaction de la page à une action de l’utilisateur – objectif: 200 ms maximum,
- CLS, la stabilité visuelle de la mise en page – objectif: 0,1 maximum.
Important: un score PageSpeed Insights pour une seule URL ne suffit pas. Vérifiez différents types de pages: la page d’accueil, une liste de produits ou d’articles, un article, une landing page, un formulaire, la page de connexion, le panier ou l’espace client. Le problème se trouve souvent dans un modèle de page, et non dans une URL isolée.
Causes typiques des problèmes:
- une image non optimisée dans la section hero,
- trop de JavaScript au-dessus de la ligne de flottaison,
- des fichiers CSS et JS qui bloquent le rendu de la page,
- des scripts tiers chargés sans contrôle,
- des polices web qui décalent le texte pendant le chargement de la page,
- des publicités ou des bannières qui modifient la mise en page,
- des composants frontend qui bloquent le thread principal du navigateur.
Si votre site fonctionne sous Drupal, vérifiez le cache, l’agrégation des fichiers CSS et JS, le lazy loading des images, la prise en charge des formats WebP et AVIF, le CDN, et si un thème sur mesure ajoute trop de code sur chaque page. Vous trouverez d’autres conseils pratiques dans l’article CMS le plus rapide: comment améliorer ses performances et accélérer le site? Il est utile de combiner un audit de performance avec le support et la maintenance Drupal, pour que les corrections recommandées ne restent pas dans le rapport.
- Scripts, consent mode et analytics
Après deux ans, l’analytics fait souvent partie des éléments les plus négligés d’un site. GA4 a été mis en place dans l’urgence, les définitions de conversion ne correspondent plus depuis la refonte des formulaires, et la bannière cookies a été configurée une fois sans que personne n’y revienne. Résultat: l’équipe prend des décisions à partir de données auxquelles elle ne devrait pas se fier.
En 2026, un audit doit couvrir non seulement GA4, mais aussi le consent mode, Google Tag Manager, les événements, les campagnes payantes et le fait que les balises ne se déclenchent qu’après le consentement de l’utilisateur. Google décrit le consent mode comme un mécanisme qui adapte la collecte de données pour la publicité et l’analytics aux consentements donnés par les utilisateurs. Un consent mode mal mis en place peut entraîner à la fois une perte de données et un risque de non-conformité à la réglementation sur la vie privée.
Vérifiez:
- si les événements GA4 correspondent à vos formulaires et CTA actuels,
- si Google Ads compte comme conversions des clics qui ne mènent à aucune action réelle,
- si GTM charge des balises inutilisées,
- si le consent mode v2 est correctement mis en place,
- si les scripts publicitaires dégradent l’INP et le LCP,
- si les rapports montrent les données dont vous avez besoin pour décider, et pas seulement de jolis graphiques,
- si l’information sur la source du lead arrive correctement dans votre CRM.
Dans ce domaine, le marketing et l’équipe de développement doivent travailler ensemble. Le marketing sait quoi mesurer. Les développeurs savent si une mise en œuvre précise a du sens et si elle ralentit le site.
- Mises à jour de sécurité du CMS et du framework
Si votre site fonctionne avec un CMS ou un framework open source, il faut vérifier l’état des mises à jour après deux ans. Pas « on fera la mise à jour un jour », mais concrètement: la version du cœur, les modules, les plugins, les paquets Composer et npm, PHP, la base de données, le serveur, la configuration du cache, le panneau d’administration et les intégrations.
L’édition 2025 de l’OWASP Top 10 montre toujours que les applications web rencontrent les mêmes catégories de risques. La communauté Drupal publie des avis de sécurité pour le cœur et les modules contribués. La CISA tient un catalogue des vulnérabilités connues activement exploitées dans des attaques. Ce ne sont pas des listes théoriques pour auditeurs. Suivre régulièrement ces sources fait partie de la maintenance courante d’un site.
Lors d’un audit de sécurité, vérifiez:
- si la version de votre CMS ou framework est toujours prise en charge,
- si les modules et plugins ont des mainteneurs actifs,
- si le projet contient des bibliothèques abandonnées,
- si Composer et npm signalent des vulnérabilités connues,
- si le panneau d’administration est protégé par une authentification multifacteur (MFA) et si les rôles des utilisateurs ont des droits limités,
- si les formulaires sont protégés contre le spam et les abus,
- si les sauvegardes peuvent réellement être restaurées,
- si l’on sait qui réagit aux avis de sécurité critiques et dans quel délai.
Pour Drupal, vérifiez aussi si le site est resté sur une ancienne version mineure qui ne reçoit plus de correctifs de sécurité, et si du code sur mesure bloque les mises à jour. Nous expliquons pourquoi il faut aujourd’hui réagir plus vite qu’avant aux avis de sécurité dans l’article Mises à jour de sécurité Drupal à l’ère de l’IA. Si vous prévoyez une mise à jour plus importante, découvrez aussi ce que comprend une mise à niveau vers Drupal 11.
- Accessibilité numérique
L’accessibilité n’est plus un sujet « pour quand on aura le temps ». L’European Accessibility Act s’applique depuis le 28 juin 2025 et concerne certains produits et services, notamment l’e-commerce, les services bancaires, les transports, les services de télécommunications et les livres numériques. La version la plus récente des règles est WCAG 2.2, et il vaut la peine de l’appliquer même si votre organisation n’a pas encore d’obligation légale formelle.
Après deux ans, l’accessibilité se dégrade souvent à cause de l’édition quotidienne des contenus. On voit apparaître des textes alternatifs manquants, une hiérarchie de titres incorrecte, du texte placé dans des images, des bannières impossibles à utiliser au clavier, de nouvelles couleurs ajoutées sans vérification du contraste et des formulaires sans messages d’erreur clairs.
Vérifiez:
- le contraste du texte et des boutons,
- la navigation au clavier,
- un indicateur de focus visible sur l’élément actif,
- les textes alternatifs des images,
- la structure des titres,
- les libellés des champs de formulaire,
- les messages d’erreur,
- l’accessibilité des menus, des fenêtres modales et des composants dynamiques,
- l’accessibilité des fichiers PDF publiés sur le site.
Ce n’est pas seulement une exigence légale. Un site accessible est généralement plus facile à utiliser pour tout le monde, surtout sur un téléphone, avec une faible luminosité, dans la précipitation ou avec une connexion plus lente. Nous décrivons comment aborder l’accessibilité dans Drupal dans l’article Comment créer un site web inclusif? Conseils et astuces pour l’accessibilité sur Drupal.
- Formulaires, conversions et intégrations
Beaucoup d’entreprises jugent un site sur son trafic plutôt que sur ce que les utilisateurs y font. Après deux ans, parcourez les principaux parcours utilisateur comme le ferait un client: l’arrivée depuis Google, la lecture d’une page de service, le clic sur un CTA, le remplissage d’un formulaire, la réception d’une confirmation, l’enregistrement du lead dans le CRM et la notification de l’équipe commerciale.
Cela paraît évident. En pratique, c’est justement là que les lacunes apparaissent: le formulaire fonctionne, mais le lead arrive dans le CRM sans source. Un CTA mène à une ancienne page. Une notification automatique part vers une personne qui ne travaille plus dans l’entreprise. Le message affiché après l’envoi d’un formulaire n’indique pas ce qui va se passer ensuite. La version anglaise du formulaire n’a pas les mêmes champs que la version française.
Lors de l’audit, vérifiez:
- si tous les formulaires envoient les données au bon endroit,
- si les messages de validation des champs sont compréhensibles,
- si les consentements marketing sont à jour,
- si les e-mails de confirmation ont toujours le bon contenu,
- si la source, la campagne et la page d’entrée sont enregistrées pour chaque lead,
- si les CTA correspondent à votre offre actuelle,
- si toutes les versions linguistiques guident l’utilisateur de la même manière,
- si vos principales landing pages indiquent clairement l’étape suivante.
Si votre site fonctionne sous Drupal, ces problèmes peuvent souvent être corrigés sans reconstruire tout le site, grâce à des modifications du module Webform, des intégrations CRM, des vues (Views), des blocs CTA et de la structure des contenus. Pour des changements plus importants, prévoyez la suite du développement Drupal afin de traiter la cause du problème, et pas seulement ses symptômes.
- Monitoring, sauvegardes et plan de réponse aux incidents
Le dernier domaine est le moins spectaculaire, mais le négliger coûte souvent le plus cher. Après deux ans, votre site devrait avoir un plan clair: ce que vous surveillez, qui reçoit les alertes, qui réagit, où se trouvent les sauvegardes, combien de temps prend leur restauration et ce qui est considéré comme un incident.
Le minimum à vérifier:
- la surveillance de disponibilité (uptime) du site et des principaux parcours utilisateur,
- la surveillance de l’expiration des certificats SSL et des domaines,
- les alertes sur les erreurs 5xx,
- les logs de l’application et du serveur,
- les sauvegardes de la base de données et des fichiers,
- un test de restauration des sauvegardes,
- une liste de contacts pour l’escalade,
- une procédure de réponse aux vulnérabilités critiques,
- un environnement de préproduction (staging) séparé.
Sans cela, l’équipe ne réagit que lorsqu’un client ou la direction remarque le problème. Cette façon de travailler est risquée. Un site d’entreprise, surtout en B2B, dans la finance, l’éducation, la santé ou l’e-commerce, doit être traité comme un système métier, et non comme un ensemble de pages. Si vous n’avez pas encore de plan de ce type, commencez par la surveillance des serveurs et des applications.
Que faire après l’audit?
Un bon audit ne se termine pas par un rapport PDF. Il doit aboutir à une décision: ce que nous faisons maintenant, ce que nous planifions pour plus tard et ce que nous ne faisons pas du tout. Après deux ans, les sujets ne manquent généralement pas. Ce qui manque, ce sont les priorités.
Je propose une répartition simple:
- critique: sécurité, formulaires en panne, erreurs d’indexation sur des pages importantes,
- corrections rapides: métadonnées, CTA, redirections, images trop lourdes, balises inutilisées,
- travaux planifiés: refactorisation du thème, corrections d’accessibilité, nettoyage des contenus,
- décisions stratégiques: mise à jour du CMS, changement d’architecture, refonte de certains parcours utilisateur.
Un audit montre rarement qu’il faut reconstruire le site de zéro. Le plus souvent, il montre quels éléments il vaut la peine de faire évoluer par étapes. Nous décrivons cette approche dans l’article « Ne pas reconstruire, faire évoluer: un cadre de modernisation CMS par phases ».
Si votre site fonctionne sous Drupal et que personne ne l’a audité depuis longtemps, commencez par une revue technique: SEO, performance, sécurité, accessibilité, analytics et processus de publication des contenus. Chez Droptica, nous aidons les équipes à maintenir et à faire évoluer leurs sites Drupal, du support au quotidien jusqu’aux changements d’architecture plus importants. Si vous souhaitez d’abord vérifier l’état de votre système et fixer des priorités, découvrez notre audit de code Drupal.
Si vous préférez obtenir une liste concrète des risques et des actions recommandées plutôt que de deviner, contactez-nous. Nous vérifierons ce qui doit vraiment être corrigé et ce qui peut attendre.
