I eventually figured it out. My mistake was that I defined my secrets within an environment and, by default, workflows do not run in any specific environment. For this to happen, I have to explicitly name the environment in the job description as follows:

jobs:
  publish:
    environment: CI    # <--- /!\ Here is the link to the environment
    needs: build
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/tags/v')
    steps:
    - uses: actions/checkout@v2
    # Some more steps here ...
    - name: Publish to Test PyPI
      env:
        TWINE_USERNAME: "__token__"
        TWINE_PASSWORD: ${{ secrets.TEST_PYPI_API_TOKEN }}
        TWINE_REPOSITORY_URL: "https://test.pypi.org/legacy/"
      run: |
        echo KEY: '${TWINE_PASSWORD}'
        twine check dist/*
        twine upload --verbose --skip-existing dist/*

The documentation mentions it actually.

Thanks to those who commented for pointing me in the right direction.

According to GitHub’s official docs, the recommended way is to use Environment Secrets, because they allow you to: keep secrets isolated per environment (dev, staging, prod), take advantage of environment protections (reviewers, approvals, restrictions), avoid having a long list of duplicated repository secrets. In practice, you can define the environment in your workflow with the environment: key, and GitHub will automatically use the right secrets for that environment. If your “environments” are more like internal variants, then using prefixes in repository secrets can work too but for long-term scalability, environment secrets are usually the best choice.