It’s probably nonsense but I don’t know and I can’t find it here.
What I want is that when the Ubuntu Server starts (which I have in my case), I do this manually with this instruction: $ trytond -c /etc/tryton/trytond.conf
How can I make it automatic?
Just a few hints 
The internal webserver of Tryton is only for development purposes, so you need something like uwsgi or gunicorn to run Tryton. When you have that running, you can create a systemd service file which starts it all automatically on boot.
Personally I prefer gunicorn it’s a more general purpose wsgi server.
You can start trytond as a service or as a daemon.
Check your OS documentation.
A quick a dirty solution is to start it as a detached process in /etc/rc.local.
Because I have a dynamic list of trytond servers to start and I want so start them sequentially, I end up by using crontab to activate a specific script.
Also be sure postgresql is fully started before you start trytond service.
I will follow your suggestion.
Once I have Gunicorn installed, how should I proceed?
Which limitations did you find with out-of-the-box server ?
None, but the internal werkzeug wsgi server of Tryton is NOT to be used in production and only for development. In order to test properly in a more automated manner just install Gunicorn and a systemd file to start Tryton on boot. The internet is full of examples how to do this.
It depends on your configuration. How you installed Tryton and Gunicorn. Buth search for Flask and Gunicorn and you should be able to get it running (Gunicorn - WSGI server — Gunicorn 21.2.0 documentation).
Currently the docker images are using µwsgi (Replace µwsgi (#1) · Issues · Tryton / Tryton Docker · GitLab).
So we have an example of configuration in 6.8/uwsgi.conf · branch/default · Tryton / Tryton Docker · GitLab.
Same for me. If someone knows, any new argument would be useful.
It explained here: Serving WSGI Applications — Werkzeug Documentation (2.3.x)
Do not use the development server when deploying to production. It is intended for use only during local development. It is not designed to be particularly efficient, stable, or secure.
Under specific conditions like high load, concurrency, etc. you will encounter errors with the development server.
You can have a look at tryton-server not accepting new connections (#10921) · Issues · Tryton / Tryton · GitLab, which was the reason for tryton-server: Should provide a ready-to-use production-grade server config, which then yielded Recent improvements to Tryton’s Debian Packaging.