# Elementor V4 et Sentry : ce que l’atomique change pour le suivi d’erreurs

> L'architecture atomique testée dans les premières versions de l'éditeur V4 modifie la nature des données qu'un outil comme Sentry parvient à capturer côté front.

- Auteur : Clément Hadrot
- Publié le : 2025-03-03
- Mis à jour le : 2025-03-03
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/elementor-v4-sentry-atomique-suivi-erreurs/

## L’essentiel

- Les widgets V4 rendent en composants atomiques plutôt qu'en blocs monolithiques
- Le contexte d'erreur JS devient plus granulaire mais plus fragmenté
- Les tags Sentry doivent être adaptés au nouveau nommage des composants

« Le contexte d'erreur ne pointe plus vers le même endroit. » C'est la première remarque remontée par l'équipe qui instrumente Sentry sur un projet où l'alpha de l'éditeur V4 d'Elementor est testée en environnement de recette. Le constat mérite d'être creusé, parce qu'il touche à un changement d'architecture profond, pas à un simple détail de configuration.

Elementor V4, encore en accès anticipé au moment de la rédaction de cet article, repose sur une approche dite « atomique » : chaque widget n'est plus un bloc monolithique qui gère sa propre logique de rendu, de style et d'interaction, mais une composition de petits éléments indépendants, chacun responsable d'une seule responsabilité. Ce choix d'architecture a des conséquences directes sur ce qu'un outil de suivi d'erreurs comme Sentry parvient à observer côté navigateur.

## Comment Sentry capture le contexte en V3

Dans l'architecture V3 encore majoritaire à ce jour, un widget Elementor correspond à une seule classe PHP qui génère un unique bloc de balisage HTML, avec son propre script JS associé si nécessaire. Quand une erreur JavaScript survient dans ce script, Sentry la capture avec une pile d'appels relativement simple : le nom du fichier source, la fonction en cause, et éventuellement le sélecteur DOM concerné via l'intégration `Sentry.addBreadcrumb()`.

Ce modèle donne un contexte lisible mais assez pauvre : on sait qu'une erreur s'est produite « dans le widget Accordéon », sans savoir précisément quelle interaction ou quel sous-composant interne en est la cause.

## Ce que l'architecture atomique change concrètement

> L'essentiel à retenir : Les widgets V4 rendent en composants atomiques plutôt qu'en blocs monolithiques ; Le contexte d'erreur JS devient plus granulaire mais plus fragmenté ; Les tags Sentry doivent être adaptés au nouveau nommage des composants

Avec l'approche atomique testée en V4, un même widget se décompose en plusieurs composants, chacun avec son propre cycle de rendu et, potentiellement, sa propre gestion d'événements. Un widget Accordéon en V4 peut ainsi être composé d'un composant conteneur, d'un composant en-tête cliquable, et d'un composant panneau de contenu, chacun identifiable séparément dans l'arbre de rendu.

Pour Sentry, cela signifie un contexte d'erreur beaucoup plus granulaire : la pile d'appels peut désormais indiquer précisément quel sous-composant atomique a levé l'exception, ce qui facilite le diagnostic pour un développeur qui connaît la nouvelle architecture. En contrepartie, ce contexte devient aussi plus fragmenté et plus difficile à interpréter sans une bonne connaissance du nommage interne des composants V4, encore en évolution durant cette phase d'accès anticipé.

## Adapter le tagging Sentry au nouveau nommage

La configuration Sentry existante, pensée pour l'architecture V3, référence souvent les erreurs par nom de widget classique (`elementor-widget-accordion`, par exemple). Avec l'architecture atomique, ce tag perd de sa pertinence puisque plusieurs composants distincts peuvent porter des identifiants différents pour un même widget visible dans l'éditeur.

Un ajustement du code d'instrumentation devient nécessaire pour capturer un contexte plus fidèle :

```
Sentry.init({
  dsn: 'https://exemple.ingest.sentry.io/0000000',
  beforeSend(event) {
    const domNode = event.extra?.__sentry_dom_node;
    if (domNode && domNode.closest('[data-atomic-component]')) {
      event.tags.atomic_component = domNode
        .closest('[data-atomic-component]')
        .getAttribute('data-atomic-component');
    }
    return event;
  }
});
```

Cette approche suppose que les composants atomiques exposent un attribut de données identifiable dans le balisage rendu, ce qui reste à vérifier composant par composant tant que l'architecture V4 continue d'évoluer avant sa stabilisation.

## Les limites observées à ce stade

Il faut le dire clairement : cette granularité accrue ne s'accompagne pas encore d'une documentation stable, l'éditeur V4 étant toujours en phase d'accès anticipé au moment de la rédaction. Le nommage interne des composants atomiques a déjà changé une fois entre deux versions alpha testées, ce qui a cassé une partie du tagging Sentry mis en place la semaine précédente.

- Le contexte d'erreur est plus précis, mais dépend d'un nommage interne non garanti stable
- Les breadcrumbs Sentry doivent être revalidés à chaque montée de version alpha de l'éditeur V4
- Un widget qui semblait unique en V3 peut désormais lever des erreurs depuis plusieurs sources distinctes

> Notre conseil pour l'instant : ne pas figer un tagging Sentry trop fin sur des composants V4 tant que l'architecture n'est pas stabilisée. Mieux vaut un contexte un peu plus large mais qui survit aux mises à jour de l'éditeur.

## Notre verdict

L'architecture atomique de l'éditeur V4 promet un diagnostic d'erreur plus fin sur le long terme, une fois la structure interne des composants stabilisée. À ce stade d'accès anticipé, le bénéfice reste théorique : les noms de composants évoluent encore d'une version alpha à l'autre, ce qui oblige à revoir régulièrement l'instrumentation Sentry. Nous recommandons de conserver un tagging basé sur le widget parent plutôt que sur le composant atomique tant que l'API interne n'est pas figée.