Surveillance et maintenance de votre instance Adobe Experience Manager monitoring-and-maintaining-your-aem-instance

Une fois vos instances AEM déployées, vous devez surveiller et maintenir leur fonctionnement, leurs performances et leur intégrité.

L’un des facteurs clés est que, pour identifier les problèmes potentiels, vous devez connaître l’apparence et le comportement de votre système dans des conditions normales. Cette fonctionnalité est mieux réalisée en surveillant le système et en collectant des informations au fil du temps.

Sauvegardes backups

Il est recommandé de sauvegarder les éléments suivants :

Votre entreprise applique probablement une politique de sauvegarde. Voici quelques considérations supplémentaires sur le contenu à sauvegarder et la fréquence de sauvegarde :

Souvent, une sauvegarde complète est effectuée à intervalles réguliers (par exemple, tous les jours, toutes les semaines ou tous les mois), et des sauvegardes incrémentielles sont réalisées entre chaque (par exemple, toutes les heures, tous les jours ou toutes les semaines).

Sauvegarde de votre installation logicielle backing-up-your-software-installation

Après l’installation ou des modifications importantes de la configuration, créez une sauvegarde de votre installation logicielle.

Pour accomplir cette tâche, sauvegardez tout votre référentiel, puis :

Sauvegarde du référentiel backing-up-your-repository

La section Sauvegarde et restauration de la documentation CRX couvre tous les problèmes liés aux sauvegardes du référentiel CRX.

Pour obtenir toutes les informations sur la réalisation d’une sauvegarde « à chaud » en ligne, consultez Création d’une sauvegarde en ligne.

Purge de version version-purging

L’outil Purge de version est destiné à purger les versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son objectif premier est de vous aider à réduire la taille de votre référentiel en supprimant les anciennes versions de vos nœuds.

Cette section traite des opérations de maintenance liées à la fonctionnalité de création de versions d’AEM. L’outil Purge de version est destiné à purger les versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son objectif premier est de vous aider à réduire la taille de votre référentiel en supprimant les anciennes versions de vos nœuds.

Vue d’ensemble overview

L’outil Purge de version est disponible sous la forme d’une tâche de maintenance hebdomadaire. Avant de commencer à l’utiliser, il faut l’ajouter et le configurer. Ensuite, vous pouvez l’exécuter sur demande ou de manière hebdomadaire.

Purge des versions d’un site web purging-versions-of-a-web-site

Pour purger les versions d’un site web, procédez comme suit :

Exécution d’essai - Analyse de la console analyzing-the-console

L’interface utilisateur classique fournit une option d’Exécution d’essai à partir de :

Le processus répertorie tous les nœuds qui ont été traités. Au cours du processus, un nœud peut avoir l’un des statuts suivants :

Par ailleurs, la console affiche des informations utiles sur les versions :

Dans l’exemple suivant :

Utilisation des enregistrements d’audit et des fichiers journaux working-with-audit-records-and-log-files

Les enregistrements d’audit et les fichiers journaux relatifs à Adobe Experience Manager (AEM) se trouvent à différents emplacements. Les éléments suivant donnent un aperçu de ce que vous pouvez trouver et où vous pouvez le trouver.

Utiliser des journaux working-with-logs

AEM WCM enregistre des journaux détaillés. Une fois que vous avez décompressé et démarré Quickstart, vous pouvez trouver les journaux dans :

Rotation des fichiers journaux log-file-rotation

La rotation de fichiers journaux fait référence au processus qui limite la croissance du fichier par la création périodique d’un nouveau fichier. Dans AEM, la rotation d’un fichier journal appelé error.log est activée une fois par jour, selon les règles en place :

Recherche des fichiers journaux finding-the-log-files

Divers fichiers journaux sont conservés sur le serveur de fichiers sur lequel vous avez installé AEM :

Activation du niveau de journalisation DÉBOGUER activating-the-debug-log-level

Le niveau de journalisation par défaut (Configuration de la journalisation Apache Sling) est Information, par conséquent, les messages de débogage ne sont pas consignés.

Pour activer le niveau de journalisation de débogage pour un journal, définissez la propriété org.apache.sling.commons.log.level pour le débogage dans le référentiel. Par exemple, sur /libs/sling/config/org.apache.sling.commons.log.LogManager pour configurer la journalisation globale Apache Sling.

Une ligne dans le fichier de débogage commence généralement par DEBUG, puis fournit le niveau de journalisation, l’action du programme d’installation et le message du journal. Par exemple :

DEBUG 3 WebApp Panel: WebApp successfully deployed

Les niveaux de journal sont les suivants :

Créer un fichier journal personnalisé create-a-custom-log-file

Dans certains cas, vous pouvez créer un fichier journal personnalisé avec un niveau de journalisation différent. Dans le référentiel, procédez comme suit :

La console Felix fournit également des informations sur la prise en charge du journal Sling à l’adresse ../system/console/slinglog ; par exemple, https://localhost:4502/system/console/slinglog.

Recherche des enregistrements d’audit finding-the-audit-records

Les enregistrements d’audit sont conservés pour indiquer qui a fait quoi et quand. Différents enregistrements d’audit sont générés pour les événements WCM et OSGi AEM.

Les enregistrements d’audit WCM AEM affichés lors de la création de pages aem-wcm-audit-records-shown-when-page-authoring

Enregistrements d’audit WCM AEM dans le référentiel aem-wcm-auditing-records-within-the-repository

Dans le dossier /var/audit, les enregistrements d’audit sont conservés selon la ressource. Vous pouvez analyser en profondeur jusqu’à afficher les enregistrements individuels et les informations qu’ils contiennent.

Ces entrées contiennent les mêmes informations que celles affichées lors de la modification d’une page.

Enregistrements d’audit OSGi à partir de la console web osgi-audit-records-from-the-web-console

Les événements OSGi produisent également des enregistrements d’audit pouvant être affichés dans l’onglet Statut de la configuration  > Fichiers journaux dans la console web Adobe AEM :

Surveillance de vos agents de réplication monitoring-your-replication-agents

Vous pouvez surveiller vos files d’attente de réplication pour détecter lorsqu’une file d’attente est arrêtée ou bloquée, ce qui peut à son tour indiquer un problème avec une instance de publication ou un système externe :

Pour surveiller un agent de réplication :

Vous pouvez toujours développer une solution pour détecter tous les agents de réplication (situés sous /etc/replication/author ou /etc/replication/publish), puis vérifier le statut de l’agent (enabled, disabled) et de la file d’attente sous-jacente (active, idle, blocked).

Surveillance des performances monitoring-performance

L’optimisation des performances est un processus interactif qui reçoit une attention particulière pendant le développement. Après le déploiement, il est examiné après des intervalles ou des événements spécifiques.

Les méthodes utilisées lors de la collecte des informations pour le ciblage peuvent également être utilisées pour une surveillance continue.

Vous trouverez ci-après une liste des problèmes de performances qui surviennent de temps à autre, ainsi que des solutions potentielles sur la façon de les repérer et de les résoudre.

Les problèmes de performances peuvent provenir de diverses causes qui n’ont rien à voir avec votre site web, notamment des ralentissements temporaires de la vitesse de connexion, de la charge du processeur, etc.

Cela peut également avoir un impact sur tous vos visiteurs et visiteuses, ou seulement sur un sous-ensemble d’entre eux.

Toutes ces informations doivent être obtenues, classées et analysées avant de pouvoir optimiser les performances générales ou résoudre des problèmes spécifiques.

Outils de surveillance et d’analyse des performances tools-for-monitoring-and-analyzing-performance

Vous trouverez ci-dessous un bref aperçu de certains outils disponibles pour surveiller et analyser les performances.

Certains de ces outils dépendent de votre système d’exploitation.

Interprétation de request.log interpreting-the-request-log

Ce fichier permet d’enregistrer des données de base sur chaque demande envoyée à AEM. Vous pouvez en tirer des conclusions précieuses.

request.log fournit une méthode intégrée pour identifier la durée des demandes. À des fins de développement, il est utile d’utiliser tail -f sur request.log et d’observer les temps de réponse lents. Pour analyser un request.log plus volumineux, Adobe recommande l’utilisation de rlog.jar, qui permet de trier et de filtrer les temps de réponse.

Adobe recommande d’isoler les pages « lentes » de request.log, puis de les régler individuellement pour de meilleures performances. Incluez des mesures de performances par composant ou utilisez un outil de profilage des performances tel que [yourkit](https://www.yourkit.com/).

Surveillance du trafic sur votre site web monitoring-traffic-on-your-website

Le journal des requêtes enregistre chaque requête effectuée, ainsi que la réponse apportée :

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

En totalisant toutes les entrées GET de périodes spécifiques (par exemple, plusieurs périodes de 24 heures), vous pouvez tirer des conclusions sur le trafic moyen sur votre site web.

Surveillance des temps de réponse avec request.log monitoring-response-times-with-the-request-log

Le journal des demande est un point de départ intéressant pour l’analyse de performances :

<cq-installation-dir>/crx-quickstart/logs/request.log

Le journal se présente comme suit (les lignes sont raccourcies par souci de simplicité) :

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Ce journal comporte une ligne par requête ou réponse :

En utilisant de petits scripts, vous pouvez extraire les informations requises du fichier journal et assembler les statistiques de votre choix. Ces statistiques vous permettent de déterminer les pages ou les types de pages lents et de savoir si les performances globales sont satisfaisantes.

Surveillance des temps de réponse de la recherche avec request.log monitoring-search-response-times-with-the-request-log

Les demandes de recherche sont également enregistrées dans le fichier journal :

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Ainsi, comme indiqué ci-dessus, vous pouvez utiliser des scripts pour extraire les informations pertinentes et créer des statistiques.

Cependant, une fois que vous avez déterminé le temps de réponse, analysez les raisons pour lesquelles la requête prend autant de temps et ce qui peut être fait pour améliorer la réponse.

Surveillance du nombre et de l’impact des utilisateurs simultanés monitoring-the-number-and-impact-of-concurrent-users

request.log peut encore être utilisé pour surveiller les accès simultanés et la réaction du système dans cette situation.

Des tests doivent être effectués pour déterminer le nombre d’utilisateurs et utilisatrices simultanés que le système peut traiter avant qu’une incidence négative ne survienne. Là encore, des scripts peuvent être utilisés pour extraire les résultats du fichier journal :

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilisation de rlog.jar pour rechercher des requêtes avec des durées longues using-rlog-jar-to-find-requests-with-long-duration-times

AEM comprend divers outils d’assistance dans les cas suivants :
<cq-installation-dir>/crx-quickstart/opt/helpers

L’un de ces outils, rlog.jar, peut être utilisé pour trier rapidement request.log afin que les requêtes soient affichées selon la durée, c’est-à-dire de la plus longue à la plus courte durée.

La commande suivante affiche les arguments possibles :

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Par exemple, vous pouvez l’exécuter en spécifiant le fichier request.log en tant que paramètre et afficher le premières requêtes ayant la plus longue durée :

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Concaténez individuellement les fichiers request.log si vous devez effectuer cette opération sur un important échantillon de données.

Apache Bench apache-bench

Pour minimiser l’impact des cas particuliers (tels que la récupération de l’espace mémoire), il est recommandé d’utiliser un outil tel que apachebench (par exemple ab pour obtenir plus d’informations) pour vous aider à identifier les fuites de mémoire et à analyser de manière sélective le temps de réponse.

Apache Bench peut être utilisé de la manière suivante :

$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Les chiffres ci-dessus sont extraits d’un ordinateur portable MacBook Pro standard (mi-2010) avec accès à la page d’entreprise Geometrixx, comme inclus dans une installation d’AEM par défaut. Cette page est très simple mais n’est pas optimisée en terme de performances.

Le apachebench affiche également la durée par requête comme la moyenne de toutes les requêtes simultanées ; voir Time per request: 54.595 [ms] (moyenne de toutes les requêtes simultanées). Vous pouvez modifier la valeur du paramètre d’accès simultané -c (nombre de demandes multiples à exécuter à un moment donné) pour voir si cela produit un effet.

Compteurs de requêtes request-counters

Les informations sur le trafic de requêtes (nombre de requêtes pendant une période spécifique) vous donnent une indication de la charge sur votre instance. Ces informations peuvent être extraites de request.log à l’aide des compteurs, automatisant ainsi la collecte de données pour vous permettre de constater :

Pour automatiser la collecte des informations, vous pouvez également installer un RequestFilter afin d’incrémenter un compteur pour chaque requête. Plusieurs compteurs peuvent être utilisés pour différentes périodes.

Les informations collectées peuvent être utilisées pour indiquer :

Commentaires HTML html-comments

Nous vous recommandons d’inclure des html comments sur la performance du serveur pour chaque projet. De nombreux bons exemples publics peuvent être trouvés. Sélectionnez une page, ouvrez la source de la page pour l’afficher, puis faites défiler la page vers le bas. Un code comme celui-ci s’affiche :

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Surveillance des performances à l’aide de JConsole monitoring-performance-using-jconsole

La commande d’outil jconsole est disponible avec JDK.

Surveillance de la performance à l’aide de (J)VisualVM monitoring-performance-using-j-visualvm

Pour le JDK 6-8, la commande d’outil visualvm est disponible. Après avoir installé un JDK, vous pouvez effectuer les opérations suivantes :

Vous pouvez utiliser cet outil pour générer des vidages de thread et des vidages de mémoire. Ces informations sont souvent demandées par l’équipe d’assistance technique.

Collecte des informations information-collection

La connaissance d’un maximum d’informations sur votre installation peut vous aider à déterminer ce qui a pu causer un changement dans les performances et à déterminer si ces changements sont justifiés. Collectez ces mesures à intervalles réguliers afin de visualiser facilement les modifications importantes.

Les informations suivantes peuvent s’avérer utiles :

Combien d’auteur(e)s travaillent avec le système ? how-many-authors-are-working-with-the-system

Pour afficher le nombre d’auteurs et d’autrices qui ont utilisé le système depuis l’installation, utilisez la ligne de commande :

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Pour afficher le nombre d’auteurs et d’autrices travaillant à une date donnée :

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Quel est le nombre moyen d’activations de page par jour ? what-is-the-average-number-of-page-activations-per-day

Pour afficher le nombre total d’activations de page depuis l’installation du serveur, utilisez une requête de référentiel ; par le biais de CRXDE - Outils - Requête :

Calculez ensuite le nombre de jours écoulés depuis l’installation pour calculer la moyenne.

Combien de pages maintenez-vous actuellement sur ce système ? how-many-pages-do-you-currently-maintain-on-this-system

Pour afficher le nombre de pages actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Si vous utilisez MSM, quel est le nombre moyen de déploiements par mois ? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Pour déterminer le nombre total de déploiements depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Calculez le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Quel est le nombre moyen de Live Copies par mois ? what-is-the-average-number-of-live-copies-per-month

Pour déterminer le nombre total de Live Copies effectuées depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Utilisez toujours le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Si vous utilisez AEM Assets, combien de ressources maintenez-vous actuellement ? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Pour voir le nombre de ressource de gestion des ressources numériques que vous conservez actuellement, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Quelle est la taille moyenne des ressources ? what-is-the-average-size-of-the-assets

Pour déterminer la taille totale du dossier /var/dam :

Combien de modèles sont actuellement utilisés ? how-many-templates-are-currently-used

Pour afficher le nombre de modèles actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Combien de composants sont actuellement utilisés ? how-many-components-are-currently-used

Pour voir le nombre de composants actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

Combien de demandes par heure recevez-vous sur le système de création lorsque le niveau d’activité est élevé ? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Pour déterminer le nombre de demandes par heure que vous recevez sur le système de création lorsque le niveau d’activité est élevé :

Combien de demandes par heure recevez-vous sur le système de publication lorsque le niveau d’activité est élevé ? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Répétez la procédure ci-dessus sur votre instance de publication.

Analyse de scénarios spécifiques analyzing-specific-scenarios

Voici une liste de suggestions des éléments à vérifier si vous commencez à rencontrer certains problèmes de performance. La liste n’est (malheureusement) pas tout à fait complète.

Processeur à 100 % cpu-at

Si le processeur de votre système fonctionne constamment à 100 %, reportez-vous aux sections suivantes :

Mémoire insuffisante out-of-memory

Bien que de telles erreurs doivent être détectées pendant le développement et les tests, certains scénarios peuvent passer.

Si la mémoire de votre système est insuffisante, ce problème peut être détecté de différentes manières, notamment par une dégradation des performances et des messages d’erreur, notamment le sous-texte :

java.lang.OutOfMemoryError

Dans ce cas, vérifiez les éléments suivants :

E/S de disque disk-i-o

Si votre système manque d’espace disque ou vous constatez une fragmentation du disque, reportez-vous à la section :

Détérioration régulière des performances regular-performance-degradation

Si les performances de votre instance se détériorent après chaque redémarrage (parfois une semaine ou plus tard), vérifiez les éléments suivants :

Réglage JVM jvm-tuning

La machine virtuelle Java™ (JVM) a été améliorée en termes de réglage (notamment depuis Java™ 7). Ainsi, la spécification d’une taille JVM fixe raisonnable et l’utilisation des valeurs par défaut sont souvent indiquées.

Si les paramètres par défaut ne conviennent pas, il est important d’établir une méthode pour surveiller et évaluer les performances du GC. Effectuez cette opération avant de tenter de régler JVM. Ce processus peut impliquer des facteurs de surveillance, notamment la taille du tas, l’algorithme et d’autres aspects.

Les plus courants sont les suivants :

Le rapport résultant peut être assimilé par un visualiseur GC comme :

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Ou JConsole :

Cela vous aidera à déterminer la quantité de mémoire utilisée, les algorithmes GC utilisés, leur durée d’exécution et l’impact de ce processus sur la performance de l’application. Si vous ne suivez pas ce processus, le réglage consistera simplement à « manipuler des boutons de façon aléatoire ».