Bonjour à toutes et tous, c'est cool de se retrouver.
Aujourd'hui, je vais vous faire une petite...
Alors, c'est ce que je disais, j'espère que vous avez prévu un peu de Doliprane.
Je vais vous faire une présentation un petit peu technique
sur un sujet qui, évidemment, parle à tout le monde,
c'est l'observabilité dans WordPress.
Et je vais commencer.
Est-ce que quelqu'un a une idée de ce que c'est que l'observabilité ?
Avant même de se poser la question de comment ça se fait dans WordPress,
est-ce que quelqu'un sait ce que c'est que l'observabilité ?
Personne ? Non, vraiment ?
Oui, non, c'est vrai, tu n'as pas le droit.
Quelqu'un d'autre ? Oui ?
Ok. Ça, c'est adapté à WordPress.
Mais oui, ok. C'est un bout de bonne réponse.
Pour être capable de caractériser un système,
pour le fonctionnement d'un système ?
Oui, oui, ça s'additionne avec la réponse précédente.
Monitorer les activités sur l'application web.
Oui, aussi, oui. Monitorer aussi.
Ça fait partie de l'observabilité.
Bon. Il y avait une autre réponse ?
Non, ok. Alors, l'observabilité, en fait, ça a déjà une définition.
Avant d'être dans WordPress, avant de parler de sites ou d'applicatifs,
parce que l'observabilité, ça ne s'applique pas qu'à des systèmes informatiques.
On peut même dire qu'il y a de l'observabilité dans une voiture.
C'est un système.
L'observabilité, c'est la capacité d'un système à rendre compte de son état
et à être inspecté de façon non intrusive.
Alors, rendre compte de son état, tout le monde voit ce que ça veut dire.
À être inspecté, ça va déjà un peu mieux.
De façon non intrusive, ça veut dire que le fait d'inspecter,
de produire des process pour inspecter,
ne modifie pas en soi le comportement du système.
Vraiment, ça a beaucoup moins d'intérêt.
Alors, l'observabilité, ça repose sur plusieurs choses.
Plusieurs choses et plusieurs piliers.
La première chose, c'est déjà qu'il y a des états.
C'est un système qui doit avoir des états.
Plusieurs de préférence.
Sans ça, ça n'a pas beaucoup de sens.
Et que ces états soient à la fois qualifiés,
c'est-à-dire qu'un état, ça ne soit pas juste quelque chose
qui soit différent d'avant, mais en quoi c'est différent d'avant.
Et qu'il soit quantifiable.
C'est-à-dire de combien de fois il est différent d'avant.
Alors, vous allez voir.
Je vois vos têtes.
On va faire une petite partie théorique.
C'est la partie théorique.
Rassurez-vous, après, on va faire des trucs vachement plus rigolos.
Mais on ne peut pas comprendre la suite, réellement,
si on ne fait pas la partie théorique.
Donc ça, c'est l'un des piliers.
C'est effectivement le fait que ça soit un système à état.
Ce qui n'est pas toujours le cas.
Ensuite, que ça soit mesuré, ces états.
Et donc, qu'on mesure à la fois les états et les transitions entre chaque état.
Comment je passe d'un état à un autre ?
Et évidemment, pour qu'on puisse dire que c'est mesuré,
ce n'est pas le tout d'avoir des choses mesurables.
Il faut que ça soit effectivement mesuré.
Donc, il y a un mécanisme quelconque pour capter à la fois ces états
et à la fois les transitions entre ces états.
J'adore.
Vous ne voyez toujours pas le rapport avec WordPress.
C'est génial.
Et troisième pilier de l'observabilité,
ce n'est pas le tout de les mesurer.
Il faut que ça soit d'une manière ou d'une autre,
que ça soit exposé.
Et quand on dit exposé, ça veut dire quoi ?
Ça veut dire que ces états et ces transitions d'état
soient exploitables, soient perceptibles
et donc exploitables à l'extérieur du système.
Normalement, un système qui est observable
ne rend pas de manière interne lui-même compte de son propre état.
C'est donc qu'il faut que ça soit publié d'une manière ou d'une autre
et qu'il y ait effectivement un mécanisme,
à minima un mécanisme de publication.
Généralement, il y en a plusieurs.
Ça va pour tout le monde ?
Super !
Alors, dans un système informatique,
parce que là, ce que j'ai décrit,
ça peut s'appliquer à n'importe quel système.
Ce que je disais, c'est une voiture, une fusée,
un quoi, hein ?
Ouais, tout à fait.
Tout à fait.
Un barrage, ça peut même...
Ouais, ouais, tout à fait.
Alors, maintenant, cette fois-ci,
appliqué au système informatique.
On se rapproche petit à petit de WordPress.
On est quand même sacrément loin,
mais on s'en rapproche.
Rassurez-vous.
Donc, un système informatique observable,
c'est un système qui est capable de fournir des observations
concernant son fonctionnement.
Et quand on parle de système informatique
et de fonctionnement d'un système informatique,
il y a trois types d'observations
qui sont des standards, des typologies d'observation.
Et une quatrième catégorie qui est un peu le fourre-tout
de tout ce qu'on n'a pas réussi à mettre dans les trois autres catégories.
C'est comme ça que ça marche, j'adore.
La première typologie d'observation, ce sont les événements.
Alors, les événements, ce sont des descriptions contextualisées,
c'est magnifique, des transitions.
Ça veut dire quoi ?
Ça veut dire qu'un événement, en fait,
il décrit quelque chose qui est une transition du système.
Le système est passé de tel état à tel autre état.
Voilà.
Il ne décrit que ça.
Et sans a priori sur la manière dont tout ça va être publié.
Donc, vraiment, c'est un événement.
Parce que là, tout de suite, vous pensez log d'erreur ou truc comme ça.
C'est un tout petit bout de ce que ça peut être.
Effectivement, l'activité, c'est les intlogging.
La deuxième typologie d'observation, c'est les métriques.
Donc, cette fois-ci, qu'est-ce qu'on mesure ?
On ne mesure pas des transitions d'état.
On mesure des valeurs chiffrées correspondant à ces états.
L'activité, c'est le monitoring.
Troisième typologie d'observation, avant de passer à la classe fourre-tout.
Troisième typologie d'observation.
Quelqu'un a une idée ?
Ok.
Ce sont les traces.
Les traces, c'est quoi ?
C'est la capacité.
Enfin, c'est la capacité.
C'est l'état des différents processus et sous-processus qui sont chronométrés et emboîtés de manière hiérarchique.
L'activité incroyable, quand on fait des traces, c'est du tracing.
Et ensuite, la fameuse catégorie fourre-tout, celle où il y a tout le reste.
Voilà, les auxiliaires.
Alors, c'est quoi ?
C'est, j'ai mis observation agrégée ou spécifique du système.
Et du coup, ça sert à quoi ?
Ça peut servir à faire de l'inspection et notamment en informatique, on appelle ça l'introspection d'un langage, par exemple, ou l'introspection d'une plateforme.
C'est-à-dire la capacité à décrire comment elle est constituée à un instant T.
Ça parle à tout le monde, l'introspection d'un langage ?
Par exemple, PHP ? Non, pas du tout.
Ok.
Bon, on verra si on a le temps, parce qu'en fait, c'est une présentation que je n'ai jamais chronométrée encore.
Donc, on verra si on a le temps d'en parler.
Parce que ce n'est pas vraiment le fond du projet.
Le profiling, c'est quoi ? C'est être capable de jouer un certain nombre de jeux de tests sur une application ou dans un système informatique.
Et d'être capable de mesurer un certain nombre de consommations.
Par exemple, de consommation de mémoire, de consommation de CPU, de choses comme ça, de l'application.
Le Crash Analytics, tout le monde connaît.
Même Google Analytics, d'ailleurs, a une entrée pour pouvoir faire du Crash Analytics.
Je suis sûr que vous l'utilisez tous dans vos applications.
Non, je rigole. Personne, je suis sûr.
Pourtant, c'est un super truc. Ça vous permet d'envoyer directement dans Google Analytics les Crashs de vos applications.
Et ensuite, tout ce qui est alerting.
Alors, alerting, ça se base sur quoi ?
Ça peut se baser sur des événements, sur des traces, sur du monitoring.
Mais ça peut aussi se baser sur de la corrélation de tout ça et générer des alertes avec des canaux d'alerte.
On va parler un petit peu des événements.
Vous avez vu mon beau flon d'écran avec plein de lignes de logs, là ?
C'est sympa, ça.
Alors, un événement, enfin, des événements.
Donc ça, c'est, je vous rappelle, le premier pilier.
On va parler des trois typologies standards de l'observabilité.
On ne parlera pas de la classe auxiliaire, sauf si on a vraiment le temps.
Alors, un journal d'événements, c'est quoi ?
C'est quelque chose qui présente une chronologie de ce qui s'est passé.
C'est toujours des transitions d'État.
C'est qu'est-ce qui s'est passé ?
Et chaque événement a un certain nombre de caractéristiques qui fait qu'il est réellement utilisable par la suite pour en faire quelque chose.
C'est parce que ce n'est pas le but du jeu, ce n'est pas juste de le regarder passer, en fait.
C'est que si on essaye de le lire, de le capter, c'est pour en faire quelque chose.
Il faut qu'il soit estampillé.
Alors, selon les systèmes, ça peut être plus ou moins précis.
Quand on dit estampillé, ça veut dire au moins à la seconde.
Enfin, au plus à la seconde.
Ça peut être à la milliseconde, à la microseconde, mais voilà, c'est à minima.
Il faut qu'il soit catégorisé et qu'il soit contextualisé.
Alors, catégorisé, ça veut dire que les événements ont des classes d'événements.
Les classes d'événements classiques, il y a sept classes classiques qui sont utilisées partout dans le domaine informatique.
Ça va de debug à alerte, je pense, en passant par warning, erreur, notice, info, critical, etc.
Ça, c'est la catégorie.
Et le contexte, c'est tous les éléments supplémentaires, on va dire, c'est les métadonnées de l'événement,
qui permettent de comprendre dans quelles conditions s'est passée cette transition d'état.
OK, pour tout le monde ?
J'adore, j'aime beaucoup.
Donc, alors, voilà, exemple d'événement.
Quel utilisateur, donc là, pour le coup, ramené à du WordPress.
Quel type d'événement on peut avoir dans du WordPress ?
Quel utilisateur a créé un contenu ?
Ça permet de répondre à cette question-là.
Voilà.
Quelle extension génère des erreurs ?
Ça, c'est le truc dont vous avez l'habitude, finalement, parce que c'est ce qu'on voit dans les logs d'erreurs.
Est-ce qu'un mail a été envoyé à la suite d'une vente avec WooCommerce,
ou est-ce que ça a foiré quelque part ?
Qui a modifié un menu dans l'interface, etc., etc., etc.
Alors, vous voyez que dans les questions auxquelles ça permet de répondre, dans le qui, l'événement ne dit pas, dans ce que je vous ai présenté, il n'y a pas par défaut le qui.
Le qui fait partie des métadonnées.
Donc, qui a modifié un menu ?
L'événement, ça serait, je ne sais pas, par exemple, une notice, de classe notice.
L'événement lui-même, ça serait modification de menu.
Et dans les métadonnées, vous pouvez trouver qui l'a fait, quel ID de menu, etc., etc.
Voilà.
Ça, c'est pour les événements.
Les traces.
Vous voyez là-haut, un petit zigoui-goui, là, c'est l'enchaînement de traces.
C'est ce que je vous disais.
On verra plus en détail tout à l'heure les traces quand on va faire des exemples.
Alors, les traces, qu'est-ce que c'est ?
C'est un chronogramme.
C'est-à-dire que là, si vous regardez ce que c'est qu'une trace,
je vais essayer de passer devant sans gêner tout le monde.
Grosso modo, vous avez le début de la requête,
enfin, le début du process, finalement, le début d'un process.
Et vous voyez que vous avez un certain nombre de choses qui vont conduire jusqu'à la fin du process.
Avec des sous-process, qui sont des phases,
et ça porte un nom quand on fait du tracing.
Une phase, ça s'appelle un span.
Et c'est donc chronométré.
Vous voyez, ça a une durée.
C'est catégorisé.
Alors là, on ne le voit pas, mais il y a bien une catégorie.
Et contextualisé, parce que là aussi, ça a des métadonnées.
Et qu'on peut refaire 20 fois la même requête.
Peut-être que cette phase-là prendra toujours le même temps,
mais aura des métadonnées différentes,
qui ont donc des significations différentes.
Et ça permet de répondre à quoi ?
Comment est décomposée une requête ?
Quand je parle d'une requête, c'est quelqu'un qui clique sur un lien interne du site,
et tout ce que ça va faire derrière,
jusqu'à générer la nouvelle page qui sera affichée aux visiteurs.
Ça permet de dire, évidemment, quelque chose qui sert un petit peu à tout le monde,
et qu'à la fin, vous n'allez retenir que ça, c'est quel temps prend la génération de ma page ?
Et où finalement, je perds du temps peut-être dans ma page ?
Le temps d'envoi d'un mail, est-ce que c'est admissible ?
Est-ce que ce n'est pas admissible ?
Il n'y a jamais de bonne ou mauvaise réponse.
Enfin si, 50 secondes pour envoyer un mail, c'est pas bon.
Pourquoi une tâche planifiée prend du temps ?
Et là, quand on dit pourquoi, parce que tout simplement en voyant la décomposition en span de ces traces,
on sait dire là où ça a pris du temps,
et donc potentiellement là où il y a des choses à modifier.
Voilà un petit peu pour les traces, là aussi, ça va à tout le monde ?
Nickel ? Nickel.
On va passer aux métriques.
Les métriques, c'est ce que je disais tout à l'heure,
c'est ce qu'on disait tout à l'heure, une métrique c'est quoi ?
C'est une valeur numérique, qui est donc relevée de manière régulière,
et qui permet de voir l'évolution de cette valeur.
En termes de représentation, ça peut être hyper varié,
parce que vous pouvez avoir un simple compteur,
qui juste est plus ou moins, ça c'est une métrique.
Ça peut être aussi la répartition dans des percentiles de requêtes, par exemple.
Là aussi, ça parle à tout le monde les percentiles ?
Ouais, super.
Là aussi, c'est une manière différente de voir, ça peut être une jauge aussi.
Il y a beaucoup, beaucoup de manières de type de métriques.
Celles qu'on va voir le plus souvent quand on s'intéresse à WordPress,
à peu de choses près.
Ce sont des métriques qui sont des relevés réguliers,
et qui sont des compteurs.
Et les compteurs, ça peut se représenter sous forme de courbes.
Ce sont des points qui sont des courbes,
des courbes plus ou moins raides, droites, etc., ou arrondies.
Mais globalement, c'est comme ça que ça marche.
Et donc, ça permet de dire quoi ?
Quelle est l'évolution du temps de génération d'une page ?
Je vais prendre un exemple qui va parler à tout le monde.
J'ai mon site avec Elementor.
Je fais mon relevé pendant une heure de combien de temps me prend ma génération de page.
Et puis, je décide de faire la mise à jour de février sur la 3.35.0 de Elementor.
Et je regarde après combien de temps ça prend de générer une page.
Et je m'aperçois que j'ai pris 30% dans la vue.
Voilà, c'est un exemple.
Quel tarif est la base de données ?
Peut-être parce que vous êtes chez un hébergeur
ou il ne vous avertira pas quand vous êtes en limite d'occupation de la base de données
et que peut-être que c'est sympa d'avoir quelque part un compteur qui vous dit ça.
Quel est le taux d'erreur PHP ?
C'est-à-dire que, par exemple, vous avez décidé tout d'un coup d'utiliser PHP 8.5
alors que vous avez des vieux plugins.
Vous regardez un petit peu ce que ça donne.
Et ça, les métriques peuvent vous le dire.
Combien de mails sont envoyés par heure, etc.
Enfin, après, vous allez voir dans les exemples,
vous avez toute l'attitude d'imaginer toutes les métriques
et toute l'analyse des métriques métiers, y compris métiers,
que vous pouvez bien vouloir.
Voilà.
Alors, on va reprendre les histoires de nos trois piliers de l'observabilité
et on va regarder si WordPress est observable.
Donc, le premier pilier, c'était, de mémoire, c'était les états.
Est-ce que WordPress est un système qui peut avoir plusieurs états ?
Et est-ce que ces états sont qualifiés et quantifiables ?
À votre avis ?
Ouais.
C'est le cas.
Est-ce qu'ils sont mesurés, ces états ?
Et est-ce que les transitions sont effectivement mesurées ?
Et est-ce qu'il y a bien un mécanisme de captation ?
Ben...
Non.
Et ensuite, est-ce que ces valeurs qui ne sont pas mesurées sont quand même exposées ?
Non, non plus.
Donc, WordPress n'est pas nativement observable.
Nativement, ça veut dire si vous prenez la version core distribuée et que vous ne faites que ça.
Maintenant, on va voir qu'il y a quelques moyens, quelques manières de résoudre ce sujet.
Parce que vous avez vachement envie de rendre votre WordPress observable
et que vous ne pouvez pas vous en passer.
Alors, la première des choses, c'est d'accepter l'état de fait.
WordPress n'est pas observable en l'état.
Je ne vais pas rajouter 50 plugins ou 50 trucs qui vont l'alourdir.
Je le laisse comme ça en l'état.
Bon, ok.
C'est une manière de voir le problème.
N'utiliser que des outils intégrés.
Donc, typiquement, des outils intégrés, c'est des choses qui vont se situer au niveau de PHP,
qui vont peut-être être même côté serveur.
Je pense à des choses comme PHP X-Ray ou des choses comme ça.
Sincèrement, si vous avez un hébergeur qui vous le propose, tant mieux.
Mais c'est rarissime.
Les outils sont très hétérogènes.
Ce n'est pas forcément la meilleure solution.
Maintenant, si vous avez l'habitude d'un outil et que vous êtes sur des environnements
où vous avez toujours cet outil, utilisez-le, c'est bien.
Vous pouvez aussi outiller certains sous-systèmes spécifiques.
Par exemple, dans WordPress, vous pouvez très bien vérifier que...
C'est un exemple qui est sorti hier en journée de contribution.
Vous pouvez très bien vérifier, faire un journal d'événements de l'envoi d'email
et vérifier à chaque fois ce que répond la fonction WP Mail.
Est-ce que c'est bon ? Est-ce que c'est pas bon ?
Vous n'en saurez pas beaucoup plus, mais au moins, vous savez que vous avez un taux d'erreur qui est mesurable.
Vous pouvez utiliser l'outillage d'un fournisseur de services.
Il y a un certain nombre de SaaS qui vous proposent d'outiller directement à un niveau plus ou moins bas
par rapport à l'OS et par rapport à votre WordPress.
D'outiller par exemple Sentry, il y en a d'autres.
Ils proposent des outils.
La plupart du temps, ce n'est pas visible directement dans votre WordPress.
Et puis après, vous pouvez utiliser un outil ouvert et conçu pour WordPress.
Donc là, quand je dis ça, c'est en fait, vous pouvez utiliser des plugins pour faire ça.
On va parler de trois...
Ça va pour tout le monde ? C'est bon ?
N'hésitez pas à m'interrompre.
Si à un moment, il y a un truc qui déconne complètement, n'hésitez pas.
Alors, quelques exemples d'outils.
Je vais vous les énumérer, les outils.
J'ai trois outils à vous montrer, qui sont des outils qui sont tous les trois présents sur le directory WordPress.org
et qui permettent de produire une forme d'observabilité plus ou moins forte, plus ou moins ciblée.
Le premier, c'est...
Alors, j'ai pris celui-là.
Il y en a plein qui sont dans cette classe d'outils-là.
C'est ceux qui permettent de rendre compte de l'activité qu'il y a sur un site web.
Quand on parle d'activité, c'est...
Donc là, celui-là, c'est WPActivityLog, qui existe en version gratuite, puis sur le repo.
Ça, voilà, ça journalise pour le cœur de WordPress les extensions et les thèmes, ce qui se passe.
Grosso modo, vous aurez effectivement...
Telle personne s'est connectée, telle personne a supprimé un item dans le menu, etc.
Il y a eu une commande WooCommerce, voilà.
En termes d'extensibilité, celui-là, ce type d'application-là, c'est très très faible.
Parce que ça n'a pas été prévu pour être totalement étendu.
Il y a très peu d'API, il y a très très peu de hook.
Et donc, vous aurez du mal à aller au-delà de ce que vous fournit l'outil.
Il vous fournit l'outil, vous le prenez en l'état, ou alors c'est pas l'outil qu'il vous faut, globalement.
Et en termes d'exposition, ces outils-là permettent deux choses.
Soit d'avoir des visualiseurs internes à WordPress, on verra tout à l'heure dans le back-office.
Soit en mode push, notamment avec WP Activity Log.
Dans la version payante, cette fois-ci, permet de pusher vers...
Je crois qu'il y a deux exemples, il y a deux services vers lesquels ça permet de pusher.
Quand je parle de service, c'est un service SaaS, qui est à l'extérieur,
et qui permet de stocker, qui gère lui-même ses propres soucis de taille de stockage,
d'ingestion des événements, etc.
C'est-à-dire qu'en fait, vous déchargez WordPress de tous ces sujets-là.
Qui sont des sujets, hein.
Faut pas se leurrer à certains moments, faire de l'observabilité.
Si c'est mal fait, ça peut rajouter de l'overhead à ce que vous faites dans WordPress.
Ensuite, vous avez un second...
Alors, le premier outil, c'est un outil qui fonctionne tout le temps,
quand vous avez de l'activité sur votre site, évidemment.
Autrement, il ne se passe pas grand-chose.
Le second, c'est Query Monitor.
J'imagine que là, tout le monde connaît.
Magnifique.
Donc celui-là, c'est à la fois un petit outil d'observabilité,
mais c'est aussi un très, très bon outil d'introspection.
C'est ce que je disais tout à l'heure.
L'introspection, c'est d'être capable, pour un langage ou pour un framework,
de dire de quoi il est constitué,
et vers quoi il va, et ce qu'il a pu faire pour arriver là.
Donc là aussi, c'est WordPress.
Là, ça rajoute PHP et base de données, par rapport au précédent,
ce qui est plutôt pas mal.
Et ça fait aussi extension et thème.
Là, en termes d'extensibilité, c'est très chouette,
puisque Query Monitor, il a non seulement des API,
mais en plus, il a aussi une bibliothèque d'add-ons,
et n'importe quel éditeur de plugin ou de solution
peut développer un add-on spécifique pour Query Monitor à son outil, à lui.
Par exemple, on pourrait imaginer, je pense,
qu'Automatique fasse pour WooCommerce un add-on spécifique Query Monitor
qui soit uniquement sur les sujets WooCommerce.
Et par contre, vous allez le voir,
l'exposition, c'est uniquement des visualiseurs internes.
Et même, en fait, ça va même plus loin que ça,
puisqu'en fait, Query Monitor, c'est uniquement lié à la session de l'utilisateur
et à ceux qui ont les capabilities pour voir Query Monitor.
C'est-à-dire que ça ne vous rendra jamais compte de ce qui se passe
dans la session des autres, d'un utilisateur lambda,
de quelqu'un qui n'a même pas créé de compte
et qui est en train de faire un achat, par exemple, sur un site.
Vous ne l'aurez pas.
Et dans ce sens-là, Query Monitor est plutôt un outil de debug ou de dev,
vous l'appelez comme vous voulez,
mais c'est quelque chose qui vous permet de vous dire,
voilà, je suis admin du site, je vois ce qui se passe quand je vais sur cette page, etc.
Mais ça ne dit rien de ce qui se passerait sur cette page
si je n'étais pas administrateur.
Et ça, il faut le garder en tête quand même.
Donc après, vous êtes des grands, des grandes et grands,
et vous savez dire à peu près où ça peut déconner,
sur les cookies, sur le fait que vous n'avez forcément pas les mêmes droits
qu'un utilisateur, etc.
Et ensuite, troisième outil, que je trouve le meilleur en toute modestie.
Je dis ça parce que c'est un outil que je développe,
donc forcément la blague est facile.
C'est Décalog, qui lui est un outil de journalisation,
de surveillance et de traçage,
pour tout WordPress, PHP et la base de données.
Vous allez me dire, mais c'est super, il remplace tous les autres.
Oui, mais il est beaucoup plus complexe et lourd à mettre en œuvre.
Donc il n'est peut-être pas non plus adapté à tous les cas de figure.
Il est extensible puisqu'il a des API, lui aussi.
Et en plus, il a un SDK transparent.
Alors, petit détail sur un SDK transparent.
Un SDK, ça veut dire que vous pouvez l'incorporer
à vos développements pour rendre compte de choses particulières
au sein de vos propres développements.
Vous développez un plugin, vous embarquez le SDK.
Transparent, ça veut dire que une fois que vous l'avez incorporé
à vos développements, vous pouvez le publier comme ça
et ça fonctionnera de manière transparente,
qu'il y ait Décalog ou non sur le site où il s'exécutera en cible.
Ça ne va pas générer des erreurs parce qu'il n'y a pas Décalog.
C'est ça que ça veut dire.
Et en termes d'exposition, c'est POOL, PUSH et visualiseur interne.
Même si toujours, le principe du visualiseur interne, c'est que toujours,
c'est prendre un risque que le fait de le visualiser en interne soit une forme d'intrusion,
finalement, dans les process qu'on est en train de mesurer.
Voilà pour cette partie-là.
Voilà.
Donc, ici, voilà.
Et maintenant, on va passer à regarder un petit peu quelques outils.
Alors, premier outil.
Donc, je vais vous expliquer un petit peu comment j'ai fait ça pour que tout le monde comprenne.
J'ai créé, il y a trois semaines, un site de démo.
Et j'ai scripté, en fait, l'activité de ce site.
Donc, c'est un site avec WooCommerce, avec un template, je ne sais pas quoi, un thème, je ne sais plus exactement ce que c'est,
avec un certain nombre de produits, et je l'ai scripté pour que, régulièrement, il y ait des nouveaux commentaires,
il y ait des nouveaux utilisateurs, il y ait des ventes qui soient faites, etc., etc.
Donc, c'est un site, vous pourrez presque croire que c'est un site qui a une vraie activité, en fait.
Un peu de choses près.
Là, ici, vous avez comme exemple ce que donne, donc, Activity, WP Activity, je ne sais plus son nom, WP Activity Log.
Vous avez un visualiseur interne qui vous permet de voir, alors, on va rafraîchir un petit peu,
qui vous permet de voir de façon antéchronologique ce qui se passe dans votre site.
Alors, ne soyez pas surpris, l'adresse IP ici sera toujours 127.001, puisque c'est mes scripts qui tournent pour faire croire qu'il y a des choses qui se passent.
Ce ne sont pas des vrais visiteurs.
Et vous avez donc ici la liste des événements qui se sont passés, donc, dans l'ordre inverse de la chronologie.
Vous voyez qu'ici, par exemple, vous savez que le 6 à 3h00.45, vous avez eu une commande qui a été marquée comme Fade,
et vous avez l'order ID.
Voilà.
Et vous pouvez, vous voyez que vous avez, c'est ce que je disais, voilà, ça, ça fait partie des metadata.
Ça permet de préciser ce qu'est cet événement.
Cet événement, c'est bien un changement de transition, comme vous pouvez le voir.
Il est passé d'un état qui était avant je ne sais pas lequel, je ne sais pas quel est le...
Peut-être en cours, par exemple, à échouer.
Et vous allez avoir, comme ça, toute la liste de ce qui se passe.
Et vous aurez, enfin, la réponse, voilà, qui...
Quel est le client qui est quand même un peu admin de son site, qui est allé supprimer un menu et qui dit qu'il n'a jamais rien fait.
Voilà.
Ça permet de répondre, par exemple, à ce genre de questions.
C'est rigolo.
Voilà ce qu'on peut dire sur WP Activity Log, parce que finalement, c'est un outil qui est, c'est ce que je disais, qui est en mode gratuit.
Et il vous permet ça.
Il ne vous permettra pas beaucoup plus.
Mais déjà, c'est un vrai... une vraie réussite en termes d'observabilité.
Deuxième outil dont on a parlé, c'est le fameux Query Monitor.
Alors, là, je suis admin, donc j'y accès.
Et j'y accès comment ?
Donc ici.
Et ça, c'est quoi ?
Ça va être toutes les informations qui concernent la requête que je viens de faire.
C'est-à-dire que si je recharge ma page, voilà.
Vous voyez que j'ai pris soin de faire un site qui tourne lentement, qu'on voit bien les choses.
Il me dit que, bah, il y a eu une seconde pour générer la page, que ça a consommé 24 mégas de mémoire, etc.
Mais surtout, tous les éléments que vous allez trouver là, par exemple, les queries dans la base de données, etc.
C'est unique.
Ça ne concerne que la requête que je viens de faire.
Ça ne dit rien d'autre de ce qui se passe à l'extérieur.
Par contre, vous vous dites, ok, c'est quand même...
Ok, l'intérêt est quand même relativement faible.
En fait, c'est pas vrai.
L'intérêt n'est pas relativement faible.
L'intérêt est extrême quand vous faites du dev.
Sincèrement, parce que vous avez...
Vous pouvez aller voir l'empilement des hooks qui ont été appelés, les filtres qui se sont appliqués, qui ne se sont pas appliqués.
Enfin, c'est vraiment un outil magique pour faire du dev spécifique à WordPress.
Mais, ça ne reste que dans la session de l'administrateur.
Et là, pour le coup, pour enregistrer quelque chose ou pour toucher des choses, il y a pas mal de choses à mettre en place.
Donc, ça, c'est le deuxième outil.
Donc, vous voyez, on peut regarder.
Voilà, on peut voir la pile des documents qui ont été appelés ou qui ont été en queue, etc.
C'est très chouette pour faire du développement.
Vraiment, je vous conseille de l'essayer un jour.
Vous verrez, vous ne pourrez plus vous en passer.
Mais, ah oui, une chose.
Ce n'est pas fait pour être en prod, cet outil-là.
Parce que, pensez que vous n'êtes pas, peut-être, potentiellement le seul admin du site.
Et que le client ou les clients ou je ne sais pas, il peut y avoir plusieurs administrateurs.
Et que ça va saouler tout le monde d'avoir ce truc-là.
Et qu'en plus, ça va vous générer du support.
Parce que les clients qui ne sont pas forcément tech et qui voient ça dedans,
ils vont aller trifouiller là-dedans.
En plus, des fois, ça vous génère des erreurs.
Parce qu'ils montrent toutes les erreurs qui se produisent.
Et donc, vous allez voir des listes d'erreurs qui vont apparaître.
Ne le laissez pas en prod.
C'est le conseil que je vous donne.
Et enfin, le troisième outil,
qui là est un petit peu plus complexe à mettre en œuvre.
Déjà, sur Query Monitor, est-ce que vous avez des questions, peut-être, éventuellement ?
Oui.
C'est un peu comme des bugs-là ?
Un petit peu, oui.
Oui.
Exactement.
Oui.
Ah, pardon.
Oui.
Je me posais la question sur WP Activity Log.
Est-ce que ça ne génère pas trop de données en base de données ?
Moi, j'ai envie de te poser la question.
C'est quoi trop ?
Ça génère de la donnée en base de données.
Oui.
Est-ce que c'est trop ?
Ça dépend de ce que tu es prêt à recevoir.
Ça dépend de ce que tu es prêt à purger, de la manière dont tu le fais, de manière régulière ou pas régulière.
Oui, ça génère de la donnée en base de données parce que WP Activity Log, par défaut, quand tu n'as pas la version payante, ça stocke en base de données tout à fait.
Et il y a un moyen de purger ça de temps en temps ?
Oui, oui, oui.
Tu peux le purger, oui, oui.
Ok.
Effectivement, oui.
De toute manière, ce genre d'informations-là, alors après, ça dépend un petit peu pour quel usage tu veux t'en servir.
Mais généralement, ce genre de choses, plus d'une semaine d'historique, je ne vois pas trop l'intérêt.
Ok.
Mais ça peut servir quand même néanmoins.
Je pense que dans ce truc-là, dans cet outil, il y a même une manière de filtrer pour permettre de supprimer certaines classes d'événements et de ne garder que certaines autres.
Pour avoir un historique, alors du coup, tu n'as plus un historique complet, mais tu as un historique à trous sur les événements les plus importants, par exemple.
Ok.
Ok, merci.
Et il y avait Eddy qui avait une question.
C'est juste pour dire que Query Monitor, ça marche en fond.
Parce que c'est ce qui est intéressant.
Voilà, évidemment, Query Monitor, je ne l'ai pas précisé.
Mais tant que vous êtes admin, en fait, ça marche partout sur le site où vous allez.
C'est-à-dire que ça marche effectivement en front et dans le back-office.
Par contre, évidemment, ça ne fonctionnera pas réellement, je pense, en crone, pas sur d'autres manières d'accéder au site.
Oui, une autre question sur WP Activity Log.
Alors, ce n'est pas technique, c'est juste au niveau de la confidentialité.
Est-ce qu'on doit demander le consentement du client ou des utilisateurs qui vont être, du coup, identifiables via l'outil ?
Eh bien, écoute, je ne sais pas parce que je n'ai pas l'impression qu'il y ait d'option d'anonymisation des adresses IP.
Et donc, je te laisse cette réflexion-là et je sais que tu as déjà la réponse.
La réponse, en théorie, est oui.
Alors, oui et non, parce que tu vas invoquer le sacro-saint log technique que le RGPD dit qu'on a le droit de les garder un an, etc.
Ce n'est pas des logs techniques, ça.
Non, non, non, non. Tu peux voir, il y a les noms, il y a tout.
Non, non, ce n'est pas des logs techniques.
C'est vraiment, c'est du...
Mais tu as raison, ça ne serait que du log technique, normalement.
Tu n'as pas un à les avertir et tu n'as pas besoin...
Tant que tu ne conserves pas plus de 364 jours, tu n'as pas de choses à remplir dans ton registre de traitement ou de choses comme ça.
Une bonne partie, c'est quand tu es logué sur l'application.
Une bonne partie de...
Les logs qui sont enregistrés, c'est à ce moment où tu es connecté à l'application.
Oui, tout à fait, oui.
Donc, pareil, il y a les gbd, c'est différent, puisque dans les conditions de l'application, en général, il y a cette partie que c'est des logs essentiels pour l'utilisation.
Et donc, il y a moyen de...
C'est plus facilement facile de...
Que si la personne n'est pas connectée.
Si c'est un simple visiteur, là, clairement, il faut absolument au bac de l'application.
Ou alors, très bien, si ils sont logués...
Ok.
Bon, de toute manière, on fera quelques petites questions, si vous voulez, après.
Ensuite, je vais vous parler du dernier outil, rapidement.
C'est Décalogue.
Où est-ce qu'il est ?
Hop.
Voilà.
Décalogue.
Alors là...
Non, c'est pardon.
Décalogue, c'est un outil qui est certes plus complexe, mais qui est beaucoup plus complet.
Tout simplement parce que, grosso modo, pour résumer ce qu'il va faire, sur la partie événements et métriques, il va être capable de faire ce que fait Query Monitor, mais pour tous les utilisateurs.
Et pas uniquement en front et en back.
Il va le faire aussi sur Chrome, sur les API, etc.
Je ne vais pas rentrer dans la théorie d'Ecalog.
Il y a beaucoup de choses dans Décalogue.
Simplement, sachez que le principe, c'est que vous avez ce qu'on appelle des loggeurs, des journaliseurs.
Les journaliseurs, c'est quoi ?
C'est quelque chose qui capte sa classe de journalisation.
Ça peut être de la métrique, de l'event ou de la trace.
Et ça en fait quelque chose.
La plupart du temps, ça en fait quoi ?
Ça l'envoie vers un service extérieur qui peut être hébergé chez vous, hébergé ailleurs, etc.
On va voir quelques exemples.
Et donc, ça veut dire que, grosso modo, dans les journaliseurs, il y a trois grandes classes de journaliseurs.
Il y a les journaliseurs qui sont faits pour les traces, les journaliseurs pour les métriques et les journaliseurs pour les events.
Là, en l'occurrence, j'en ai mis quelques-uns pour qu'on puisse voir à quoi ça ressemble.
Par exemple, on peut voir des traces.
Là, je les ai prises directement.
Alors, vous voyez le logo WordPress.
Le logo WordPress, ça ne veut pas dire que ça prend les traces de WordPress.
C'est des journaliseurs.
Donc, ça veut dire que ça prend les traces de tout ce que vous faites et ça les met dans une base de données WordPress ou dans APCU,
puisque, en l'occurrence, on peut choisir aussi APCU.
Et donc, vous voyez que vous avez ici la liste des traces qui ont été...
Avec des belles données.
C'est un site qui ne met plus de six secondes à charger en front.
Et ça vous permet de voir ce qui se passe dans le chargement de votre WordPress.
Bah ouais, c'est possible, mais après, du coup, on perd...
Voilà.
Et donc, vous avez évidemment, c'est ce qu'on disait tout à l'heure, ça vous permet d'avoir aussi les métadonnées qui correspondent à ça.
Donc ça, c'était le...
On va remettre ça en attendant.
Vous avez comme autre type d'éléments, de catégories, d'observabilité qui sont stockés.
Et là, on va faire appel à quelque chose d'autre.
Dans le réglage de Décalogue, je lui ai dit d'envoyer tous les événements de ce site, donc World Company, ce débo là.
Je lui ai demandé de l'envoyer sur un outil externe qui s'appelle Locky.
Locky, en fait, c'est un outil qui va avec Grafana, pour ceux qui ont déjà entendu parler de ça.
C'est une stack Grafana, Locky, etc.
Je lui ai demandé d'envoyer les métriques vers une base de données InfluxDB.
Et pour ceux qui adorent Prometheus, sachez qu'en plus, Décalogue permet aussi de publier au format Prometheus les données de métrique.
Et donc, ça donne quoi, tout ça ?
Alors, on va aller voir, on va aller voir, ah pardon, attendez, on va aller voir ça, hop, c'est où ?
C'est là, on va aller voir les logs.
Voilà, c'est ce que je suis.
Donc, on va aller voir, on va chercher tout de suite.
Comment je l'ai appelé ? Démo.
Comment je peux retrouver tous ces logs-là ?
Par contre, on va aller voir, c'est ça.
Voilà.
C'est pas les labels.
Voilà.
On va chercher, je sais comment on va faire.
Par service, peut-être.
Voilà.
Et on doit avoir quelque part.
Donc ça, c'est de la catégorisation de services.
C'est pas de chance, on l'a pas non plus.
Non plus.
Hop.
Voilà.
Et là, on sait que...
Non, pardon.
Bon, en fait, pour tout vous dire, j'avais préparé un écran juste pour vous.
Et en fait, voilà.
Ouais, bon, on l'aura pas.
Ouais, si, voilà.
On va l'avoir comme ça, je pense.
Voilà.
On va l'avoir sous forme de...
Donc là, vous avez...
Si je fais ça, pardon.
Vous avez des calogues qui vous disent qu'il a généré des événements.
Donc ça, c'est des événements.
Et si vous voulez accéder à la liste d'événements, vous l'aurez à la fois dans Grafana.
Mais je ne vous ferai pas la démo, la Grafana, puisque je ne sais plus où est passé l'écran que j'avais programmé.
Mais voilà.
Mais vous l'avez aussi ici.
De la même manière.
Donc vous pouvez la voir dans WordPress.
Vous l'avez comme ça.
C'est...
Alors par contre...
Ouais, excusez-moi.
Je vais...
Hop.
Ça va ?
Tout le monde voit bien ?
Ouais.
Donc là, c'est des calogues qui chopent les événements au fur et à mesure où ils arrivent.
Et vous voyez par exemple que là, Maria DB, elle a dit qu'il y avait un insert qui avait dépassé le temps maximal.
Que vous avez ici des pages qui n'ont pas été trouvées.
À chaque fois, vous avez le canal sur lequel ça se produit.
Et vous voyez avec intérêt que vous pouvez effectivement voir aussi ce qui se passe dans vos crônes avec les événements.
Ce qui n'est pas le cas normalement avec Query Monitor.
Et enfin, le dernier exemple que je voulais vous montrer cette fois-ci, c'est un dashboard.
Donc cette fois-ci avec les métriques.
Donc là, par exemple...
Voilà.
Ça, c'est des métriques qui sont récupérées depuis le site.
Donc là, j'ai fait quatre catégories vite fait comme ça.
Là, celui-là, il a été enregistré.
C'est sympa.
Merci, Grafana.
Là, par exemple, j'ai pris un exemple.
Là, c'est le nombre d'événements, de commentaires qui sont créés par heure.
Vous avez les fichiers joints, les produits, le nombre d'utilisateurs actifs, etc.
Vous avez aussi des sujets plus tech.
Par exemple, là, vous voyez ici, celui-là est vachement intéressant.
Ça, c'est ce genre de truc qui est vachement intéressant à produire.
C'est le temps que met un crône à que c'est exécuté.
Et vous voyez tout de suite les pics.
Les pics qui sont là, ceux-là.
C'est assez typique, ces pics-là.
Ceux-là, ceux-là, ceux-là.
C'est ceux qui sont liés à Action Scheduler.
Action Scheduler, c'est le moteur de crône qui est intégré à WooCommerce.
Enfin, qui n'est pas intégré qu'à WooCommerce.
Mais qui permet de faire du WooCommerce.
Enfin, de gérer les tâches en stock.
Alors ensuite, vous avez des choses plutôt sympas.
Tout ça, après, c'est à vous d'imaginer ce que vous pouvez faire avec les métriques, bien sûr.
Vous pouvez, par exemple, savoir combien vous avez de tables dans votre installation WordPress.
Quelle est l'évolution du volume de données dans le temps.
L'évolution du volume d'index.
Enfin, voilà, vous avez...
Combien vous générez de requêtes SQL par heure.
Ça, c'est un indicateur qui est vachement intéressant.
Parce qu'en fait, quand vous activez du cache-objet, c'est censé faire diminuer de manière drastique le nombre de requêtes.
Et vous voyez tout de suite si le cache-objet fonctionne ou pas.
Et s'il est correctement paramétré.
Voilà, vous avez d'autres indicateurs.
Oui, il est caché là.
Ici, voilà.
On va le faire remonter.
Vous voyez, par exemple, ici.
Vous voyez ici, par exemple, l'activité de la REST API de WordPress.
Vous voyez les temps de latence.
Donc, les temps de latence, c'est à chaque fois une exécution de l'API.
Voilà, ça prend tant de temps.
Par exemple, la réportation post, get, etc.
En entrée et en sortie.
Les volumes de données qui sont échangés.
Enfin, c'est tout un tas de...
Voilà.
Et tout ça, c'est à vous de vous faire vos propres dashboards avec ces données-là.
Et évidemment, faire des dashboards pour faire des dashboards, c'est sympa parce que ça vous permet de suivre.
Surtout, l'intérêt de faire, par exemple, avec Grafana, mais avec d'autres outils comme Datadog ou des choses comme ça, c'est que vous pouvez fabriquer des alertes sur ces dashboards.
Et du coup, vous n'avez plus besoin de regarder vos dashboards.
Vous attendez simplement de recevoir les alertes quand il y a quelque chose qui ne va pas ou quand il a détecté qu'il y a quelque chose qui va déraper.
Est-ce que c'était clair pour tout le monde ?
Ou pas ?
Parce que ce n'était pas trop long.
Ouais, il y a des questions.
Super.
Merci.
Donc, il y a une API qu'on peut réutiliser pour fabriquer notre propre système.
de board où on n'est pas obligé de se connecter à Datadog ou à un service extérieur qui serait payant.
Il n'y a pas que Datadog ou Grafana.
Décalog permet d'envoyer vers...
Ta question, ça concerne vers quel type de service il peut envoyer ?
Ouais, ou même développer le neutre.
Ah, tu peux développer le tien.
Alors ça, oui, tu peux le faire.
Par contre, sache que la plupart des gens qui développent le leur, ce sont des boîtes.
C'est des gens qui ont des...
Je ne dis pas ça pour toi, mais qui ont des très grosses capacités techniques,
qui fabriquent des outils qui sont monstrueux.
Et à la fin, c'est leur propre activité de vendre ce service-là, parce qu'ils ne font plus que ça.
Donc, je te conseille d'utiliser des trucs existants et qui sont éventuellement gratuits.
Qu'est-ce qui existe en solution gratuite ?
En solution gratuite, Grafana, par exemple.
C'est une première chose, mais on peut regarder, si tu veux, là, Décalog, il te permet d'envoyer des logs vers tous ces services-là.
Il y en a qui sont inclus au navigateur.
Il y en a qui se lancent, notamment.
Il y en a un qui est vachement sympa, qui s'appelle Ray, par Spati.
C'est une boîte belge qui fait des outils absolument fantastiques pour le dev,
qui permet d'avoir une petite fenêtre dans macOS ou dans Windows,
sur le côté de tes trucs de dev.
Et en fait, le site envoie en permanence les logs d'événements
et tu vois défiler les logs au fur et à mesure où tu fais des conneries dans ton code source.
Ça, j'adore.
Ça, c'est top.
Ça répond un peu à ta question ?
Parfait.
Ok, super.
Merci pour cette conférence.
C'était très, très intéressant.
De rien.
Ma petite question se pose sur les performances.
Est-ce que rendre un site observable, du coup, demande plus de ressources au serveur
et donc nuit quelque part à la performance de l'applicatif ?
Alors, c'est une super bonne question.
Tout dépend comment c'est fait.
Query Monitor, clairement, comme ça s'affiche au fur et à mesure dans ta requête.
T'as de l'overhead.
Et oui, ça consomme des trucs, effectivement.
WP Activity Log, ça consomme de la ressource.
Ça consomme de la base de données si tu es fâché avec la purge, etc.
Décalogue, ça consomme de la ressource CPU.
Maintenant, la plupart de ces outils-là, notamment ceux qui sont bien faits, comme Query Monitor ou Décalogue,
vont en fait faire le plus gros du travail dans le hook de shutdown de WordPress.
Et donc, en fait, quand tu es en front ou quand tu es sur de l'utilisation courante,
le temps de génération de la page pour l'utilisateur ne va pas changer,
puisque tout va être fait après, une fois que la page aura déjà été envoyée.
Enfin, que ce que doit générer WordPress a déjà été envoyé à l'utilisateur.
C'est l'intérêt de le mettre dans le shutdown.
Ma question, elle rejoint un peu la précédente,
mais c'est, est-ce qu'il ne vaudrait pas mieux, au lieu d'avoir un plugin,
d'avoir un outil directement collé au serveur ?
Je pense par exemple à Blackfire, qui, il me semble, fait des choses similaires.
Et est-ce que, du coup, les perfs seraient encore meilleurs ?
Alors, honnêtement, Décalogue et Query Monitor ont des impacts sur les perfs qui sont...
C'est inférieur à une milliseconde.
Donc, enfin, on va dire en temps.
Après, en cycle CPU, sans doute que ça fait des choses, mais c'est très, très faible.
Après, ce qu'il faut voir, c'est qu'un outil qui est externe à WordPress,
il ne va pas te faire de l'observabilité de WordPress,
il va te faire de l'observabilité de ta stack PHP.
Et si WordPress n'est pas capable, ou PHP n'est pas capable de capter des choses
qui se passent dans WordPress ou réciproquement, ce qui est le cas,
puisque, finalement, WordPress, c'est un framework qui est au-dessus de PHP,
ça ne te servira à rien.
Malheureusement.
Et donc, c'est pour ça que, finalement, soit tu le fais au niveau du core,
soit tu le fais au niveau des plugins qui vont juste choper les bons hooks du core
pour faire la même chose.
Mais ça ne sera jamais aussi riche que si tu le fais, effectivement,
avec un plugin au niveau du core.
C'est là où tu as la richesse des métadonnées, notamment.
Il y a Elasticsearch ? OpenSearch, c'est bientôt ?
Peut-être.
On n'a plus de sous.
On n'a plus de sous pour Elasticsearch.
Il faut que je demande aux développeurs bénévoles de cet outil.
En plus, c'est un fork, normalement, c'est qu'il y a Elasticsearch.
Pour bientôt, je ne sais pas, mais oui, c'est dans les tuyaux.
Merci pour la conf.
Qu'est-ce que tu penses de l'intégration de Sentry dans WordPress ?
Je ne suis pas super fan.
Ou ailleurs.
Pour ailleurs, je n'ai pas trop d'avis.
Je ne suis pas super fan, parce que je trouve ça extrêmement intrusif.
Ils s'en défendent.
Mais c'est très intrusif.
Et en plus, tu ne maîtrises pas vraiment les flux de données vers où ça va
pour avoir observé un serveur avec du Sentry dans tous les sens.
Ça fait un peu peur.
Tu as l'impression qu'il y a des flux qui partent partout et que ce n'est pas hyper bien.
Alors, je vais dire pas bien maîtrisé, ce n'est pas vrai.
Mais je ne lui accorde pas une grande confiance, en fait.
Par contre, ça produit des résultats sympas.
C'est typiquement le genre d'outils qui ne sont pas au niveau de l'OS,
mais qui ne sont pas au niveau de WordPress, qui sont un petit peu entre les deux.
Et donc, il y a certaines choses que ça va rater dans WordPress, de manière évidente.
Par contre, il y a certaines choses de l'OS que ça va capter,
qui ne seraient pas captées par un plugin WordPress.
Voilà.
Enfin bon, un plugin...
Je veux dire, quand on est à essayer de savoir
quels sont les logs de ton Linux dans ton WordPress,
c'est que tu as fait un problème de conception.
Donc, de toute manière, tu vois, c'est...
Peu probable.
Là, déjà, ces outils-là, ça permet,
que ce soit Query Minitor ou des Klogs,
ça permet quand même de capter, par exemple,
des changements d'activation ou de désactivation de modules PHP.
Ça te capte tout ce qui va sur la base de données.
Enfin, ça capte ce qui est vraiment utile à du WordPress, quoi, tu vois.
Même un changement de version de PHP, il va le voir passer, quoi.
Après, si derrière, au niveau du file system,
il y a des trucs un peu particuliers,
côté Linux, il ne le verra pas, ça, non.
Voilà.
Merci, Pierre.
Merci à vous.
Applaudissements.