Usage should be discussed, maybe add a -D/--debug option that takes the config file as an argument or pass it as an env var.

Good idea ^^
If it's a simple usage, I think we can add the used variable TDP_LOG_LEVEL in the environment file.
If it's a usage like log4j, I think we can use a config file as documented in your link.

Little questions :

• if we use a config file, do we preserve the --log-level option ?
• is the --debug option mandatory ?
• In case --debug is optional, what is the default level or file config ?

This answer is only sharing my opinion, I'm open to suggestions.

if we use a config file, do we preserve the --log-level option ?

No.

is the --debug option mandatory ?

No, it should be optional.

In case --debug is optional, what is the default level or file config ?

Here are some thoughts:

• The core lib should display WARNING, ERROR and CRITICAL by default. It can then be enhanced by using a configuration file.
• I'm not sure that the CLI should display logs as we're using click.echo() to provide meaningful informations.
• We could have 2 config files: one with "default" config (with warning, error, critical in particular) and one that is activated when the --debug option is set.
• We could even have more configs and use -v, -vv, -vvv instead of --debug to switch between them but I'm not sure that we need that much granularity.

Be aware that CLI logs must be sent to stderr while the information requested by the user is sent to stdout. For example, a tdp browse displays a table, this must be displayed on stdout and all log lines must be in stderr.

This is necessary so that the tdp command can be used via the "pipe" (|) to do parsing for example.

The content of the config file is described on this site
I think that if we implement this feature, it would be up to the user to define the behaviour he wants.