diff --git a/pages/04.applications/10.docs/nextcloud/app_nextcloud.fr.md b/pages/04.applications/10.docs/nextcloud/app_nextcloud.fr.md
index b636b726..bc09f194 100644
--- a/pages/04.applications/10.docs/nextcloud/app_nextcloud.fr.md
+++ b/pages/04.applications/10.docs/nextcloud/app_nextcloud.fr.md
@@ -130,7 +130,7 @@ Lancez un scan du nouveau répertoire par Nextcloud:
 
 ```bash
 cd /var/www/nextcloud
-sudo -u nextcloud php7.3 occ files:scan --all
+sudo -u nextcloud php8.1 --define apc.enable_cli=1 files:scan --all
 ```
 
 C'est terminé. À présent testez si tout va bien, essayez de vous connecter à votre instance Nextcloud, envoyer un fichier, vérifiez sa bonne synchronisation.
@@ -274,7 +274,7 @@ Enregistrer le fichier (**CTRL** + **o**) et quitter nano (**CTRL** + **c**).
 Ensuite lancer un scan en tant que root :
 
 ```bash
-sudo -u nextcloud php /var/www/nextcloud/occ files:scan --all
+sudo -u nextcloud php8.1 --define apc.enable_cli=1 files:scan --all
 ```
 
 À présent, le problème est corrigé.
diff --git a/pages/04.applications/10.docs/nextcloud/app_nextcloud.md b/pages/04.applications/10.docs/nextcloud/app_nextcloud.md
index 98b6f7cf..45c0fe9a 100644
--- a/pages/04.applications/10.docs/nextcloud/app_nextcloud.md
+++ b/pages/04.applications/10.docs/nextcloud/app_nextcloud.md
@@ -130,7 +130,7 @@ Run a scan of the new directory by Nextcloud:
 
 ```bash
 cd /var/www/nextcloud
-sudo -u nextcloud php7.3 occ files:scan --all
+sudo -u nextcloud php8.1 --define apc.enable_cli=1 files:scan --all
 ```
 
 Update the YunoHost setting, so automatic upgrades and backups know where the datadir is located:
@@ -195,7 +195,7 @@ Save the file (**CTRL** + **o**) and exit nano (**CTRL** + **c**).
 Then run a scan by executing next command as root:
 
 ```bash
-sudo -u nextcloud php /var/www/nextcloud/occ files:scan --all
+sudo -u nextcloud php8.1 --define apc.enable_cli=1 files:scan --all
 ```
 
 Now the problem is fixed.
diff --git a/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md b/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md
index cb7ca20a..86a7e6e3 100644
--- a/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md
+++ b/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md
@@ -287,7 +287,7 @@ The script will rely on the code repo specified in the upstream section of the m
 `autoupdate.strategy` is expected to be one of :
 - `latest_github_tag` : look for the latest tag (by sorting tags and finding the "largest" version). Then using the corresponding tar.gz url. Tags containing `rc`, `beta`, `alpha`, `start` are ignored, and actually any tag which doesn't look like `x.y.z` or `vx.y.z`
 - `latest_github_release` : similar to `latest_github_tags`, but starting from the list of releases. Pre- or draft releases are ignored. Releases may have assets attached to them, in which case you can define:
-- `autoupdate.asset = "some regex"` (when there's only one asset to use). The regex is used to find the appropriate asset among the list of all assets
+- `autoupdate.asset = "some regex"` (when there's only one asset to use). The regex is used to find the appropriate asset among the list of all assets. Note that the regex must follow [Python's regex implementation](https://docs.python.org/3/howto/regex.html#regex-howto) (for instance a double backslash is to be used as escape character).
 - or several `autoupdate.asset.$arch = "some_regex"` (when the asset is arch-specific). The regex is used to find the appropriate asset for the specific arch among the list of assets
 - `latest_github_commit` : will use the latest commit on github, and the corresponding tarball. If this is used for the 'main' source, it will also assume that the version is YYYY.MM.DD corresponding to the date of the commit.