SonarCloud itself creates no user – but we recommend using a technical user, as in the documentation you referenced: GitLab | SonarCloud Docs
SonarCloud requires that the access token have api scope. This gives SonarCloud more access rights than strictly necessary, but due to the lack of more fine-grained access control in GitLab, it is the only viable option.
To mitigate this potential security concern, we strongly encourage you to add a technical user to your organization, log in to SonarCloud using that technical user, and use the access token of that technical user to connect your GitLab group to SonarCloud.
SonarCloud will always limit its actions to those required for effective integration with GitLab and will never use the full access right provided by the api scope.
You can read a bit more about the requirement for api scope here.
What seems most likely is that your customer followed this guidance and created a technical user.
The GitLab docs showed, that GitLab seems to have created the bot user itself.
At least this doc suggests this (see last point):
It also says
Technically, an internal user is a type of user, but they have reduced access and a very specific purpose. They cannot be used for regular user actions, such as authentication or API requests.
I confirm the same behaviour : I follow the documentation (GitLab Integration | SonarQube Docs), I create a user and use it token to connect SonarQube to Gitlab (aka ALM Integration integration). This user is members of all my gitlab projects. SonarQube decorates correctly Merge Request from gitlab with this user.
But at some point Gitlab create a bot user with the sonarqube server name as name and “project_XXX_bot” as username. XXX is the id of one of my gitlab project.
In the create project from gitlab page (/projects/create?mode=gitlab) that’s the only project visible.
I finally ask my gitlab adminstrator to delete the bot user.
When I reload the add project page, Sonar ask for a user token (and provide a link to generate one from the current gitlab user).
I submit the token of the user used previously in SonraQube ALM Integration and it works as expected.
I don’t know why Sonar ask for a token that already exists in its configuration. Maybe I did something wrong or it’s a Sonar bug or a feature ?
Anyway, I don’t find any way to change this token, the only solution seems to revoke is on Gitlab side so Sonarqube will ask for a new one