diff --git a/content/maintainers-guide/processes/reviewing-pull-requests.md b/content/maintainers-guide/processes/reviewing-pull-requests.md
index 2299cbe..bbb4e5a 100644
--- a/content/maintainers-guide/processes/reviewing-pull-requests.md
+++ b/content/maintainers-guide/processes/reviewing-pull-requests.md
@@ -111,6 +111,7 @@ As a general rule, all Pull Requests undergo the QA verification, except for the
 
 * Version branch merges
 * Changes that have no functional impact (e.g. code comments), cannot be manually verified, or are verified by automated tests.
+* Highly technical changes or changes without user-facing behavior, which may be validated by the maintainer team.
 
 The Pull Request can proceed to merge once the QA verification is successful.
 
@@ -232,7 +233,9 @@ If it has the right number of approvals (Pull Requests submitted to the [PrestaS
 
 You can add `Waiting for QA` label to request a validation from QA team. Some PRs do not need QA testing, for example fixing a typo or a code change that only impacts CI.
 
-Some other PRs may require QA by a developer, for example if the PR is very technical and does not change the behavior of the software. In that case, you can add `Waiting for QA` and `Waiting for dev` label. This should be discussed with QA functional team.
+Some other PRs may require QA by a developer, for example if the PR is very technical and does not change the behavior of the software. In that case, the maintainer team may validate the change.
+
+The decision to validate a Pull Request through developer QA is driven by the maintainer team, based on the technical nature and testability of the change. The QA team may be consulted when clarification is needed. Appropriate labels such as `Waiting for QA` and `Waiting for dev` can be applied accordingly.
 
 If the PR behavior is confirmed by QA Team (or a developer, for the "Waiting for dev PRs), the PR can be merged. See above section `Merging Pull Requests` for the different actions needed following the merge.
 
diff --git a/content/maintainers-guide/summary-github-lifecycle.md b/content/maintainers-guide/summary-github-lifecycle.md
index d592e66..8c0cb81 100644
--- a/content/maintainers-guide/summary-github-lifecycle.md
+++ b/content/maintainers-guide/summary-github-lifecycle.md
@@ -106,7 +106,7 @@ When the Pull Request has been approved (it needs two approvals on the Core repo
 
 On regular Pull Requests, the QA team is in charge of testing the Pull Request. They will use the "How to test" part of the Pull Request description to validate the behavior implemented, and also run some more tests to validate there are no regressions.
 
-Some Pull Requests however cannot be tested by QA team, the Developers team might validate them.
+Some Pull Requests cannot be tested by the QA team, typically because they are highly technical in nature or do not involve user-facing behavior. In such cases, the maintainer team may validate them. The decision on who performs the validation is made by the QA team or the maintainers.
 
 PrestaShop project has UI tests. These tests can be executed on each Pull Request thanks to [`ga.tests.ui.pr` tool](https://github.com/PrestaShop/ga.tests.ui.pr/). Please read the README file of this tool and fill the Pull Request description with the execution URL. 
 
@@ -114,7 +114,7 @@ If the Pull Request is tested successfully, the label "QA approved" is applied.
 
 ### Merging the Pull Request
 
-Pull Requests that have been validated by QA can be merged. They must also be milestoned, and if they fix an issue, the issue must be labelled, milestoned, and closed.
+Pull Requests that have been validated and tested can be merged. They must also be milestoned, and if they fix an issue, the issue must be labelled, milestoned, and closed.
 
 [how-pull-requests]: {{< devdocs "contribute/contribution-process/how-pull-requests-are-processed/" >}}
 [code-review]: ({{< relref "reviewing-pull-requests" >}})